Hackversuche und -erfolge

[Touchy]

Hallo,

vielleicht hat hier ja der Eine ode Andere ein paar gute Hinweise wie ich meinem Problem Herr werde oder ähnliche Erfahrungen gesammelt.
Folgendes:
seit einigen Wochen belagern brasilianische Skriptkiddies meinen Debian Woody Server. Er läuft mit Kernel 2.6.5, Apache 1.3.26 und PHP 4.3.6 (2 Domains müssen im safe mode off laufen).
Das Webadmintool ist Confixx 3.01 (ja, ich weiss, aber für meine privaten Kunden ist es recht praktisch).
Auf dem Server laufen ca. 20 Domains, alle rein privater unkritischer Natur mit insg. ca. 500Besuche pro Tag.

Nun fing es alles an mit einigen Prozessen wie "cgi-bin", "bshell" o.ä. die vom User wwwdata ausgeführt werden. Durch diese ist es wohl möglich Ports zu öffnen und per Perl-Skripte andere Rechner zu DOSen oder zu scannen. Diese wurde einmal auch intensiv gemacht. Ansonsten war es trafficmässig eher ruhig und es kam zu keinerlei Datenschäden, auch konnten keine rootkits o.ä. von einem Security-Experten ausfindig gemacht werden.
Anfällige Skripte wurden testweise mal verschoben, es landen aber sporadisch weiterhin auffällige Skripte und TXT-Dateien in meinem /tmp oder /var/tmp Verzeichnis. Der Server scheint gelegentlich zum Scannen von anderen Systemen genutzt zu werden.
Nun ist mein Experte der Meinung die PHP-version ist dran schuld und schlägt vor auf Debian sarge zu gehen. Ich frage mich, was dies ändern soll.

Also hier meine Frage an die Runde:
Wer hat Tipps oder ähnliche Erfahrungen zu meinen Ausführungen?

Vielen Dank und Gruss,
Touchy

[C_A]

...und schlägt vor auf Debian sarge zu gehen.

Ist das nicht eher unschlau wenn es für Sarge nicht mal security updates gibt?

btw: würde ich es Crackversuche und -erfolge nennen...

[hupfdule]

Nun ist mein Experte der Meinung die PHP-version ist dran schuld und schlägt vor auf Debian sarge zu gehen. Ich frage mich, was dies ändern soll.

Die PHP Version in woody ist extrem alt und hat wohl diverse Schwachstellen, dir nur in einer neueren Version umgangen werden können. Ich kenn mich mit PHP nicht wirklich aus, aber so weit ich weiß ist es die Version aus unstable noch recht alt und aus Sicherheitsgründen eigentlich nicht zu empfehlen.

Allerdings solltest du beachten, dass nicht nur die Version von PHP ausschlaggebend ist. Auch wie du es konfiguriert hast, und nicht zuletzt wie die PHP-Anwendungen, die auf deinem Server laufen, geschrieben sind ist wichtig für die Sicherheit deines Systems.

[lobo]

... Nun ist mein Experte der Meinung die PHP-version ist dran schuld und schlägt vor auf Debian sarge zu gehen. ...

Ich hoffe du hast nicht zu viel Geld für diesen so genannten "Experten" ausgegeben Ein Umstieg auf Testing ist auf gar keinen Fall sinnvoll, da es vom Debian Security Team nicht unterstützt wird. Am besten bleibst du auf Stable und machst brav die Security updates, überdenkst deine Sicherheitsstrategie neu und analysierst öfter die Logdateien.
Du solltest mal deine Logfiles einem echten Spezialisten in die Hand geben oder an dein System lassen um herauszufinden, in wie weit der Rechner kompromittiert worden ist.

Wenn du regelmässig Updates machst und ausser dem Webserver kein Ports an dem Server anbietest, ist vielleicht eher eine Web Anwendung wie z.B. PHP-Nuke das Sicherheitsproblem.

Gruss

Jochen

[Friesi]

Also ich würde ja Apache+Mysql+PHP selbet kompilieren und dafür sorgen, dass diese immer auf den neusten Stand bleiben.

So mache ich das und hatte bis jetzt noch keine Probleme.
Den Kernel und den LAMP Kompiliere ich eigentlich Grundsätzlich auf meinen Systemen selbst.
Ist vielleicht ein wenig mehr Administrativer Aufwand, doch vielleicht hilft das ja schon?

[cordovan]

auch wuerd ich mich nicht umbedingt auf den "experten" verlassen

was auf jedenfall leicht und ohne grossen aufwand zu machen waere:

root kit's suchen mit zb:

chkrootkit
RootkitHunter

als naechsten schritt:

mit aide zb die integritat deines dateisystems pruefen bzw mal anfange ueberhaupt zu erstellen. hilft zwar eher wenig wenn schon was passiert ist aber ....

als dritte und sicher anspruchsfollste moeglichkeit koenntest du forentische tools einsetzen. einen recht gut beschriebene anleitung findest du auf: http://www.heise.de/security/artikel/46297


ich schliess mich der meinung an das du solange woody stabel ist auch dabei bleiben solltest in anbetracht der sicherheitspatches. debian hat ein hervoragendes security team welches sehr regelmaessig und schnell patches liefert.

[Touchy]

Ok,
vielen Dank für Eure Tipps. Mein Experte ist aber wirklich ein solcher (für den ich aber nichts zahle). Er arbeitet für eine Firma, die damit ihr Geld verdient, in dem sie Firmen in Netzwerk-Sicherheitsfragen berät und unterstützt. Daher vertraue ich ihm schon und da ich selber eher weniger Ahnung in Sachen HAcking habe, kann ich mir auch nicht anders helfen. Eine Neuinstallaton möchte ich vermeiden, Chkrootkit habe ich schon laufen lassen: negativ.

Zum PHP: ich nutze Pakete von moolfreet.com, die doch eigentlich als sehr sicher gelten, oder?
Sollte ich vielleicht mal den Apache von 1.3.26 auf 1.3.29 updaten? Es gibt ja ein Paket auf unstable.Vorschlag meines Experten war dann noch den Apache "einzusperren", da die Hacker ja immer über den Apache reinkommen.

Gruss,
Touchy

[zyta2k]

Hast du den 2.6.5er selber installiert ??

Dann hau dir den grsecurity patch drauf !!

So wird es hackern erschwert/verunmöglicht durch Bufferoverflows o.Ä. auf andere User als www-data zu kommen.

Und als www-data kann man nicht wirklich viel anrichten

[sebast]

Testing incl. Security:

Code: Alles auswählen

deb ftp://ftp2.de.debian.org/debian/ sarge main contrib non-free
deb ftp://ftp2.de.debian.org/debian-non-US/ sarge/non-US main contrib non-free
deb http://security.debian.org/debian-secuirty/ sarge/updates main contrib non-free

Soweit ich weiss, gibt es nur fuer sid kein Security ... officel ist die testing auch nicht aber ich denke weil soviele entwickler sarge nutzen zurzeit, gibt es den.

[zyta2k]

Soweit ich weiss, gibt es nur fuer sid kein Security ... officel ist die testing auch nicht aber ich denke weil soviele entwickler sarge nutzen zurzeit, gibt es den.

*grmpf*
hört endlich mit diesen Märchen auf.

Es gibt KEINE security upgrades für Sarge/Testing !!

Wieso ich das behaupte ??

Schau dir das File an:
http://security.debian.org/debian-secur ... 6/Packages

Nach deiner Logik müssten da also die Updates für Sarge drin sein.

Da ist aber bspw folgendes drin:


Package: libc6
Priority: required
Section: base
Installed-Size: 12760
Maintainer: Ben Collins <bcollins@debian.org>
Architecture: i386
Source: glibc
Version: 2.2.5-9.woody.3
Replaces: ldso (<= 1.9.11-9), timezone, timezones, gconv-modules, libtricks, libc6-bin, netkit-rpc, netbase (<< 4.0)
Provides: glibc-2.2.5-9
Suggests: locales, glibc-doc


Komisch.
Denn in Sarge ist libc6 2.3.2.ds1-12

Ich wiederhole mich drum gerne nochmal:

Security upgrades gibts es nur für Stable !!!

[pdreker]

Security upgrades gibts es nur für Stable !!!

Für SID auch, allerdings sind das keine expliziten Security Updates sondern es erscheint einfach eine neue Version des Paketes, in der der Bug gefixed ist. Ist nicht ganz ein Security Update, passt aber schon, wenn man weiss, was man tut (!!!).

Nur so der Vollständigkeit halber.

Die Pakete aus SID sickern dann langsam nach Sarge durch. Aus diesem Grund gibt es keine Fixes für Sarge (resp. testing).

Patrick

[sebast]

Und wieso gibt es dann http://security.debian.org/debian-security/dists/sarge ?

Hmm irgend wie unlogisch einen ordner auf nehm server packen mit files drin, den es so garnicht geben darf ....

und das die version imoment auf sarge so neuer ist kann ja sein aber wofuer sag mir wofuer dann ueberhaupt der ordner sarge auf security?

[zyta2k]

Und wieso gibt es dann http://security.debian.org/debian-security/dists/sarge ?

Ist wohl ein Symlink

sarge -> woody

Grund: unbekannt.
Wenn's aber wirklich sein Security-Repos wär wär's bestimmt auch wo vermerkt, im Stile von "in dists/sarge fliessen auch changes ein... aber ....".
Ist's aber nirgends: Sonst her mit dem Link !

Hmm irgend wie unlogisch einen ordner auf nehm server packen mit files drin, den es so garnicht geben darf ....

Wie gesagt: In den sarge Ordner wurden keine Files reingepackt. Sondern wohl lediglich ein Symlink des Verzeichnisses woody nach sarge.
Grund: WasWeisIch

und das die version imoment auf sarge so neuer ist kann ja sein aber wofuer sag mir wofuer dann ueberhaupt der ordner sarge auf security?

Nicht sooo neuer:
Im sarge repos ist der security-fix für woody !

Ich wiederhole mich:

Wenn du woody hast, kannst du die die SecurityUpdate mit:

http://security.debian.org/debian-security/dists/sarge

holen,
denn das wird IMHO das selbe sein wie

http://security.debian.org/debian-security/dists/woody

Teste es aus

[cyberlussi]

Hallo,

ich hatte das gleiche Problem: Debian Woody und auf einmal war unter /var/tmp eine bshell vorhanden, dann war mein /var/log weg und dann konnte ich mich nicht mehr einloggen (weder local noch remote) - fuer chkrootkit war es da leider schon zu spät ... naja ...

Um die Diskussion mit Sarge abzuschließen - kann mir jemand gute Tipps geben, wie ich das Problem in Zukunft in den Griff bekomme?

Ich habe mal ein neues System aufgesetzt (war gezwungen Sarge zu nehmen) und manuall die aktuellsten Pakete fuer PHP (4.3.10-2), MySQL (4.1.7-4) und Apache (1.3.33-2) eingepflegt ... chkrootkit ist auch dabei und clamav auch gleich ....

Also gute Tipps für weitere Schutzmaßnahmen - bzw. kennt jemand die genaue Schwachstelle, wie die Jungs in den Server kamen (s.h. erster Post)

cu :: cyberlussi


ps. verwendet wurde auch phpBB 2.0.6 ...

[cyberlussi]

Hallo

fyi: Das loch war im phpBB zumindest mal offensichtlich da. Glücklicherweise hatte ich noch einen webalizer laufen, der von selbst apache loggte:

Code: Alles auswählen

200-232-210-138.dsl.telesp.net.br - - [19/Dec/2004:02:52:41 +0100] "GET /phpBB2/viewtopic.php?p=13441&sid=e2f4e2[..]855c&highlight=%2527%252esystem(chr(101)%252echr(99)  [..]  )%252e%2527 HTTP/1.0" 200 35498 "-" "Mozilla/4.0 (compatible; MSIE 6.0b; Windows NT 5.0)"

das war wohl ein böser php system() Aufruf - den sollte man also am besten deaktivieren in der php.ini :) Und auf keinen Fall phpBB 2.0.6 verwenden!

[DasSein]

Moinsen.

Sollte Dein Experte die folgenden Links nicht kennen, dann ist er *kein* Fachmann!

http://www.securityfocus.com/bid/10607
http://www.securityfocus.com/bid/9831
http://www.securityfocus.com/bid/9830

Nachzulesen im Linux Magazin 9/04, "Insecurity News" Seite 27.

Vielen Dank für das Gespräch.

[boa]

Hallo,

ich hatte das gleiche Problem: Debian Woody und auf einmal war unter /var/tmp eine bshell vorhanden, dann war mein /var/log weg und dann konnte ich mich nicht mehr einloggen (weder local noch remote) - fuer chkrootkit war es da leider schon zu spät ... naja ...

Um die Diskussion mit Sarge abzuschließen - kann mir jemand gute Tipps geben, wie ich das Problem in Zukunft in den Griff bekomme?

Ich habe mal ein neues System aufgesetzt (war gezwungen Sarge zu nehmen) und manuall die aktuellsten Pakete fuer PHP (4.3.10-2), MySQL (4.1.7-4) und Apache (1.3.33-2) eingepflegt ... chkrootkit ist auch dabei und clamav auch gleich ....

Also gute Tipps für weitere Schutzmaßnahmen - bzw. kennt jemand die genaue Schwachstelle, wie die Jungs in den Server kamen (s.h. erster Post)

cu :: cyberlussi


ps. verwendet wurde auch phpBB 2.0.6 ...

Das hier sollte helfen
http://www.phpbbstyles.com/viewtopic.php?t=1904

[rwetroja]

Hallo zusammen,

wenn ein server gehackt wurde ist ein nachträgliches Überprüfen auf rootkits unnütz, denn der Einbrecher könnte selbst kompilierte Tools auf den Server geladen haben und damit am kernel rumgepfuscht haben.

Man sollte Prüfsummen über alle Dateien mit z.B Tripwire erstellen, diese in eine Datei speichern und dann auf ein externes Medium auslagern und zwar bevor die Maschine ans Netz geht. Dann muss man sich wohl Gedanken über das mounten der Dateisysteme machen. Muss z.B /tmp exec gemountet sein, etc. Ein weiterer Schritt wäre das Entfernen aller Kompiler vom Server und eventuell sogar der docu. Dann suche man nach nicht benötigten Konten. Diese sind zu entfernen. Suche nach world readable/writable Verzeichnissen.

Erste Ansätze stehen in harden-debian doc. Dann http://www.rootforum.de
Eine Quelle für rpm basierende distris:ww.openna.com dort im Sektor--->books.

Dies sind aber nur Beispiele für das Härten der distri. Dazu käme dann das Härten der angebotenen Dienste.

Wenn man alles zusammmennimmt, ist das ein Haufen Arbeit, der einige Zeit und Tests erfordert. Eventuell sind vserver eine Alternative

gruss

rwetroja

[zyta2k]

Hallo,

ich hatte das gleiche Problem: Debian Woody und auf einmal war unter /var/tmp eine bshell vorhanden, dann war mein /var/log weg und dann konnte ich mich nicht mehr einloggen (weder local noch remote) - fuer chkrootkit war es da leider schon zu spät ... naja ...

Man nehme eine Knoppix CD, mounte die Platte und lasse chkrootkit drüberlaufen.

Man muss nur wissen wie

[cyberlussi]

Hallo,

klar ... wenn ich dazu komme, mache ich das ja auch noch Allerdings musste erstmal der Server wieder laufen. Dazu habe ich dann einfacherhalber ne neue/andere Platte genommen ... man weiß ja nie so, wo vielleicht noch so ein manipuliertes Progräm'chen liegt, deshalb alles neu auf neuem Grund und Boden ... aber ich habe mir auch ein netteres Weihnachtsgeschenk gewünsch

cu