gehackt - hilfe

[johndoe]

hallo,

wende mich jetzt mal an euch, vielleicht habt ihr tipps..

unser server (strato) ist gestern gehackt worden..
von einem hacker namens psych@:
http://www.zone-h.org/component/option, ... 169.132.32

das macht mir ziemlich angst.. scheinbar hat der hacker tatsächlich root-rechte bekommen..

es ist nicht viel kaputt und im moment auch keine hacker-aktivität festzustellen..

was nicht mehr funktioniert ist der login über putty und ssh..
ich erhalte den fehler:
network error - connection refused

hingegen, über die remote console von strato habe ich gott sei dank noch zugriff.

geschafft hat das der hacker vermutlich über php globals on und einem bug im script 'phpmyprofiler'

was ich bisher getan habe:
globals off
root-passwort geändert
verdächtige scripte gelöscht

aber die angst steckt mir natürlich trotzdem noch im nacken..
was kann ich sonst noch tun??

und wie bekomme ich ssh wieder hin? bzw. eigentlich kann ich ja über die remote-console gut zugreifen. wie kann ich ssh für den hacker sperren?

danke für eure hilfe im voraus.

gruß,
johannes

[timeless2]

Logfiles sichern und dann unbedingt neu installieren lassen.
In den Logfiles findest du dann vielleicht noch Hinweise, wie er reingekommen ist, um das neue System besser abzusichern. Aber wenn der Angreifer Root-Rechte hatte, dann dringend neu installieren.

[johndoe]

hm, also neu installieren find ich gar nicht gut. wir haben viele kunden, emailadressen und so weiter am laufen..

gibt es keine lösung, ihn anderweitig auszusperren?

[cat]

nein, gibt es nicht, da Du zu 98% nicht alle Backdoors oder Rootkits finden wirst und somit derjenige immer wieder ins System kommen wird

regards
Cat

[sledge0303]

hm, also neu installieren find ich gar nicht gut. wir haben viele kunden, emailadressen und so weiter am laufen..

gibt es keine lösung, ihn anderweitig auszusperren?

Das solltest du im vornhinein machen. Lass jeden deiner Kunden im eigenen chroot laufen. Wird einer gehackt, brauchst dich nur um den einen zu kümmern und der Rest der Kunden kriegt davon überhaupt nicht mit...
Jetzt bleibt dir nur noch eins über: plattmachen und neu installieren.
Zu 99% installieren sich Hacker und sonstige Vögel kleine Hintertürchen für Übermorgen und du stehst wieder vor dem selben Problem.

[johndoe]

ok, auch damit kann ich nichts anfangen?:

http://pagehost.de/test.txt

[cat]

Hoi,

lesen kannste aber? ;)

Checking `ifconfig'... INFECTED
Checking `pstree'... INFECTED
Searching for t0rn's v8 defaults... Possible t0rn v8 (or variation) rootkit installed
Searching for suspicious files and dirs, it may take a while...
/usr/lib/perl5/5.8.7/i586-linux-thread-multi/.packlist /usr/lib/perl5/site_perl/5.8.7/i586-linux-thread-multi/auto/Image/Magick/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/Bootloader/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/Config/Crontab/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/Crypt/SmbHash/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/DBD/mysql/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/DBI/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/Data/ShowTable/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/Digest/HMAC/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/Digest/MD4/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/Digest/SHA1/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/Font/AFM/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/FreezeThaw/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/HTML-Format/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/HTML-Tree/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/HTML/Parser/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/HTML/Tagset/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/IO/Socket/SSL/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/Locale/gettext/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/MLDBM/Sync/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/MLDBM/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/Mail/SpamAssassin/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/Net/DNS/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/Net/Daemon/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/Net/IP/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/Net/SSLeay/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/Parse/RecDescent/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/RPC/PlServer/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/Text/Iconv/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/Tie/Cache/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/Tie/IxHash/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/TimeDate/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/URI/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/X500/DN/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/libwww-perl/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/mod_perl2/.packlist /usr/lib/perl5/vendor_perl/5.8.7/i586-linux-thread-multi/auto/ycp/.packlist /usr/lib/jvm/java-1.4.2-sun-1.4.2.11/jre/.systemPrefs /usr/lib/jvm/java-1.4.2-sun-1.4.2.11/jre/.systemPrefs/.systemRootModFile /usr/lib/jvm/java-1.4.2-sun-1.4.2.11/jre/.systemPrefs/.system.lock
/usr/lib/jvm/java-1.4.2-sun-1.4.2.11/jre/.systemPrefs
Searching for Showtee... Warning: Possible Showtee Rootkit installed
Searching for Romanian rootkit... /usr/include/file.h /usr/include/proc.h
Checking `bindshell'... INFECTED (PORTS: 465)
Checking `sniffer'... eth0: PF_PACKET(/sbin/dhcpcd)

Gratuliere, Du hast mehrere rootkits auf Deiner verseuchten Maschine! (ok, die letzten 2 Zeilen muessen nichts schlimmes bedeuten, der Rest ist eindeutig!)

Server vom Netz nehemen (rescue mode), Logfiles sichern und schnell neu installieren lassen.

Greetz
Cat

[traced]

Laut dem Log von chkrootkit is da mehr im Argen,
Du wirst warsch. nicht ums neu installieren rumkommen.

[johndoe]

na klar hab ich das gelesen.. dachte nur, wenn man schon weiß was es is kann man vielleicht auch konkret was dagegen tun..

ich danke euch, das wird ein langes wochenende..

ätzend..

gruß,
johannes.

[cirox]

Hallo,

du wirst doch wohl ein backup vom grundzustand deines Servers haben? Über Rescue schnell ein Image rauf, dann per rsync den Rest ( Kundendaten + deine eigene Konfiguration ( /etc/ .. )), neu booten -> fertig.

Und gleich an die Sicherheit denken ....

gruß cirox

[cat]

Aehem ..

und bei der Gelegenheit gleich die selbe Luecke haben?! ...

beim Neuaufsetzen sollte man eher noch die Ergebnisse aus den Logfiles beruecksichtigen, und ein neues Sicherheitskonzept, dass die einzelnen Praesenzen besser gegen den Rest des Systems abschirmt.

regards
Cat

[cirox]

Hallo,

nunja davon geh ich aus, aber in Anbetracht der Tatsache, dass da viele Kunden drauf sind, sollte man sich schon beeilen.

gruß cirox

[sledge0303]

Hallo,

nunja davon geh ich aus, aber in Anbetracht der Tatsache, dass da viele Kunden drauf sind, sollte man sich schon beeilen.

gruß cirox

Jau, aber was nutzt es dem Kunden wenn er spätestens in 14 Tagen wieder offline ist weil die Kiste erneut gerootet wurde???

Schöne Jails einrichten, Kernel aktuell halten und sich einen Newsletter bzüglich neu gefundener Sicherheitslücken abonnieren...

[cirox]

Hallo,

ok das wäre das beste, aber jails einrichten unter confixx, so dass alles läuft? Und das mit allen Änderungen die man vielleicht gemacht hat. Ja das ist ja ein richtiges Unterfangen.

[os-t]

ok das wäre das beste, aber jails einrichten unter confixx, so dass alles läuft? Und das mit allen Änderungen die man vielleicht gemacht hat. Ja das ist ja ein richtiges Unterfangen.

Hat jemand behauptet, dass Root-Server-Admin sein Spaß macht?

[cirox]

ich halte eine Jail Umgebung bei hundert anderen Sicherheitsmassnahmen zwar für sehr sinnvoll, aber eigntlich nur ein "extra" an Sicherheit und nicht absolut zwingend.

EDIT: Achso, wenns kein Spaß macht, dann ist das nicht der richtige Job -> nicht böse gemeint.

gruss cirox

[sledge0303]

ich halte eine Jail Umgebung bei hundert anderen Sicherheitsmassnahmen zwar für sehr sinnvoll, aber eigntlich nur ein "extra" an Sicherheit und nicht absolut zwingend.

Hundert anderen Sicherheitsmaßnahmen? Geiler Witz am frühen abend.
Ein Jail ist nicht zwingend erforderlich wenn du alleine auf der Kiste sitzt, genug Geld für überzogen Traffic hast und dir leisten kannst von 4 Wochen eine Offline zu sein weil die Kiste erneut gerootet wurde.
Dein Kunde zahlt für deine Leistungen und wird sicher sauer wenn er erfährt, alle 4 Wochen eine Offline zu sein weil du bestimmte Sicherheitsmechanismen für nicht zwingend hälst...
Hat ein Kunde "Mist" in sein htdoc gesteckt, dieses wird gehackt, hat es EIN Kunde zu verantworten das er ALLEINE Offline ist für ein paar Stunden oder einen Tag...

Ist auch nicht böse gemeint, aber aus Sicht anderer Admins und Kunden zutreffend, gell?

[cirox]

was meinst du mit "jail" apache2 chrooted oder andere restrictive Massnahmen?

gruss cirox

[sledge0303]

was meinst du mit "jail" apache2 chrooted oder andere restrictive Massnahmen?

Beides. Es kommt drauf an was der Kunde ins Netz stellen wird (Bewerbungsseite, XXX, Foren usw).
Bei XXX wird es noch restriktiver als bei Bewerberseiten ohnehin. Mir ist bislang nur ein einziger Einbruch vorgekommen, der Hacker ist aber nicht aus dem Jail gekommen und wenig später war auch dieser Kunde wieder ohne Störenfried online. Schuld war ein schlecht programmiertes Skript des Kunden.

[cirox]

na dann bräucht ich mal ein howto ausser "debian absichern....." und zwar für confixx mit suphp + fast-cgi mit php4 und php5 + apache2 chrooted, weil einfach nur apache2 chrooted geht ja noch, aber so ?

gruß cirox

[lucki2]

mit Perl kannst Du aus nem chroot jail ausbrechen.
Nicht das ich Jails für Sinnlos halte - gutes Werkzeug. Aber das sind schon sehr starke Worte, die hier fallen ... wer $luser eine Shell erlaubt bzw anderweitig das ausführen von selbst aufgespielten Datein(FTP,CGI...), hat von dem Cage um User herum u.u. wenig ...

Ach und natürlich: Backs aufspielen und dann analysieren. Vielleicht ein paar Honigtöpfe dazustellen - Aber absichern parallel zum Betrieb. Ich weiß ja nicht, wie das bei Euch so ist, bei den meisten, die ich kenne ist dies eine betriebswirtschaftliche Entscheidung. Was kostet 1 Tag Ausfall bei Euch?

@cirox : Ja und ... Bei apache2 + modphp5 in getrennten jails interessiert mich dazu noch der Worker und die "Per User" Trennung....

[sledge0303]

mit Perl kannst Du aus nem chroot jail ausbrechen.
Nicht das ich Jails für Sinnlos halte - gutes Werkzeug. Aber das sind schon sehr starke Worte, die hier fallen ... wer $luser eine Shell erlaubt bzw anderweitig das ausführen von selbst aufgespielten Datein(FTP,CGI...), hat von dem Cage um User herum u.u. wenig ...

Jaein, es ist natürlich mehr zu tun als nur den Käfig um den/die User aufzubauen. Bei mir haben die User die Möglichkeit Ihre Inhalte per FTP hochzuladen. Befehle wie wget, make, gcc usw sind eh gesperrt für den Kunden. Alles andere wäre blauäugig.

[aubergine]

Manchmal frag ich mich echt wie man Kunden hosten kann ohne einen blassen Raff zu haben.

Ich mach ja als z.B. Gärtner auch keine Autowerkstatt auf.

Sorry aber musste ma sein


PS: Um an Root zu kommen (über eine Webapplikation) sind schonmal 3 Lücken nötig.

1. PHP Script
2. Webserver ohne Openbasedir, safemode, modsecurity... und weiß der kuckuck was es noch gibt.
3. Locales Root exploit


Dann weiste ja was du besser machen kannst, nämlich alles...

[pennywize]

mit Perl kannst Du aus nem chroot jail ausbrechen.
Nicht das ich Jails für Sinnlos halte - gutes Werkzeug. Aber das sind schon sehr starke Worte, die hier fallen ... wer $luser eine Shell erlaubt bzw anderweitig das ausführen von selbst aufgespielten Datein(FTP,CGI...), hat von dem Cage um User herum u.u. wenig ...

Ach und natürlich: Backs aufspielen und dann analysieren. Vielleicht ein paar Honigtöpfe dazustellen - Aber absichern parallel zum Betrieb. Ich weiß ja nicht, wie das bei Euch so ist, bei den meisten, die ich kenne ist dies eine betriebswirtschaftliche Entscheidung. Was kostet 1 Tag Ausfall bei Euch?

@cirox : Ja und ... Bei apache2 + modphp5 in getrennten jails interessiert mich dazu noch der Worker und die "Per User" Trennung....

100%ige Sicherheit wirst du nie in dein System reinbekommen. Man kann nur das Risiko minimieren und da sind CHROOT/JAILS ein guter Ansatz. Nicht mehr, nicht weniger. Wer seine Jails halbwegs gut absichert wird eher weniger Probleme bekommen als einer der sich auf *normale* Sicherheitsregeln verlässt.
Module á la mod_security, mod_chroot sowie mod_chroot bieten auch komfortablen Schutz.
Eine Frage wird auch immer außer Acht gelassen: Wie sieht die Performance des Servers am Ende aus? Was nützt es dem Kunden wenn der Admin sein persönliches Fort Knox geschaffen hat, die dem Kunden angebotenen Dienste dagegen lahmarschig sind ohne Ende?
Man sollte auch nur so viele Kunden auf der Büchse haben wie man deren Aktivitäten auch überwachen kann.
Weniger ist manchmal mehr im Gegensatz zur reinen acquisitiveness!

[sledge0303]

Manchmal frag ich mich echt wie man Kunden hosten kann ohne einen blassen Raff zu haben.

Ich mach ja als z.B. Gärtner auch keine Autowerkstatt auf.

Sorry aber musste ma sein


PS: Um an Root zu kommen (über eine Webapplikation) sind schonmal 3 Lücken nötig.

1. PHP Script
2. Webserver ohne Openbasedir, safemode, modsecurity... und weiß der kuckuck was es noch gibt.
3. Locales Root exploit


Dann weiste ja was du besser machen kannst, nämlich alles...

Ich geh mal von aus das du mich mit deinem Beitrag angesprochen hast:
in diesem Thread habe ich das Thema auf Jails gelenkt zwecks Vermeidung einer Kompromitierung des kompletten Systems wie beschrieben.
Die Absicherung der Jails und deren beinhalteten Dienste war nicht das Thema worauf ich angeschnitten hatte. Es wurden 3 von mir gesperrte Befehle genannt, ja und?... mod_security, evasive, PHP-Konfigurationen & Co KG waren nicht das Thema.
Das die chroots noch abgesichert werden müssen und wo Schwachstellen sind weiss ich alleine, da brauche ich keine freundlichen Hinweise darauf.

Sorry, aber auch das musste mal sein!!!