HowTo: Hackerangriffe erfolgreich abwehren/vorbeugen

In den letzten Wochen/Monaten ist eine auffallend hohe Anzahl an Einbruchsversuchen durchgeführt worden bzw. gelungen. Abseits von den offiziell bekannten gibt es eine Unzahl von Einbrüchen die entweder unerkannt blieben oder nur mit dem berühmten „Stecker ziehen“ beantwortet wurden. Aber es geht auch anders…..

Wenn ein Einbrecher mal erkannt wurde, ist einer der Erfolgsfaktoren eine gesundene Portion Besonnenheit. Den Stecker zu ziehen ist eine der validen Methoden – sei jedoch nur dem unbedarften Administrator empfohlen. Anschliessend sollte dieser einen Fachmann zu Rate ziehen, welcher feststellen kann welchen Grad der Infiltration der Eindringling schon erreicht hat.

Der sich auskennt wird erst einmal feststellen wie weit der Eindringling ist:

• Hat er schon ein Root-Kit installiert ?
• Sind schon Tools installiert worden die dem Eindringling helfen weiteren Zugriff zu erlangen ? (Keylogger; Austausch von Systemprogrammen gegen Programme die Informationen übertragen die eigentich nicht den Rechner verlassen sollten;…)
• Sind Benutzer angelegt/verändert worden ?
• Wie ist er eingedrungen ?

Besonders der letzte Punkt erscheint mit wichtig, da dies nach Bereinigung und der Wiederaufnahme des Servers hilft den selben Fehler nicht noch einmal zu machen….

Die Analyse kann von ein paar Minuten bis Stunden dauern – je nachdem wie weit der Eindrlingling schon ist.

Ist dieser Vorgang abgeschlossen, geht an den Gegenschlag. Ich würde diesen in folgender Reihenfolge durchführen:

• Sichern und entfernen der Tools des Angreifers (offene Dateien/Programme bleiben vorerst bestehen)
• Löschen aller Prozesse die auf diese Dienste zugreifen (kill -9 …..)
• Nach dem Löschen der Prozesse wirkt sich schlagartig die erste Aktion aus – er findet keine Dateien mehr die er aufrufen könnte 🙂
• Spätestens jetzt wird der Eindringling merken dass Sie etwas gegen ihn unternehmen – hier ist die Reihenfolge der Entfernung der Dienste wichtig !!
• beobachten der Prozesse und der Logdateien ob der Eindringling weiter versucht in das System zu kommen…..

Ich darf das an einem konkretem Beispiel darstellen, welches mir in der Nacht vom 8.7.2011 wiederfahren ist:

• Monitoring des NetzwerkAlarm schlägt gegen 21:14Uhr an dass die Prozessorlast ungewöhnlich hoch ist (siehe Bild)
• auf den betroffenen Webserver verbunden und festgestellt dass folgende Prozesse laufen (Auszug):

13018 ? S 0:00 _ sh -c perl udp.pl 72.47.223.97 0 600 2>&1 3>&1
13019 ? R 157:12 _ perl udp.pl 72.47.223.97 0 600
13224 ? S 0:00 /usr/sbin/httpd -DL
13225 ? S 0:00 _ sh -c perl udp.pl 72.47.223.97 22 600 2>&1 3>&1
13226 ? R 136:01 _ perl udp.pl 72.47.223.97 22 600
14708 ? S 0:00 /usr/sbin/httpd -DL
14709 ? S 0:00 _ sh -c perl udp.pl 92.83.253.39 0 600 2>&1 3>&1
14710 ? R 68:32 _ perl udp.pl 92.83.253.39 0 600
14762 ? S 0:00 /usr/sbin/httpd -DL
14763 ? S 0:00 _ sh -c perl udp.pl 213.239.216.200 22 600 2>&1 3>&1
14764 ? R 66:32 _ perl udp.pl 213.239.216.200 22 600
14846 ? S 0:00 /usr/sbin/httpd -DL
14847 ? S 0:00 _ sh -c perl udp.pl 213.239.216.200 22 600 2>&1 3>&1
14851 ? R 65:00 _ perl udp.pl 213.239.216.200 22 600
15075 ? S 0:00 /usr/sbin/httpd -DL
15076 ? S 0:00 _ sh -c perl udp.pl 88.30.205.164 22 600 2>&1 3>&1
15077 ? R 60:43 _ perl udp.pl 88.30.205.164 22 600

• udp.pl – ein „alter“ Bekannter den ich bei unzähligen Analysen schon gesehen hatte
• nun war klar dass der Angreifer noch am Anfang seiner Bemühungen stand – das Script scheiterte schlicht an den restriktiven Firewalleinstellungen die ich gesetzt hatte
• die Datei befindet sich normalerweise im TMP-Verzeichnis das für Apache-Dateien angegeben wurde (in diesem Falle /tmp )
• gesucht – gefunden – notiert zum löschen
• Daneben befand sich noch ein zweites PERL-Script das einen Reverse-Telnet-Dämon bereithält.
• in die Logs von Apache nachgesehen wie die Datei auf den Server kam
• Eintrag von einem EMB-Perl-Script gefunden über das die Datei offensichtlich hochgeladen wurde
• Die Senderadresse angefragt : Ein Server in Thailand war die Quelle dieser Datei – was nur heißt dass der Rechner in Thailand beteiligt war, aber nicht unbedingt dem Angreifer „gehört“
• Prozess-ID´s zum killen notiert
• Apache-Dienst gestoppt
• Dateien im /tmp auf einen sicheren Platz (anderer Rechner) übertragen und gelöscht
• die notierte Liste der Prozess-ID’s gelöscht.
• Siehe da – er bombartiert den Server mit unzähligen Anfragen die auf keinem Kommunikationsport mehr beantwortet wurden, da die entsprechenden Dienste entweder gestoppt oder durch die davor stehende Firewall blockiert wurden (gesehen hab ich das Bombartement im Log der Firewall – ich wusste ja nun wonach ich schauen musste)
• Nach einer halben Stunde war Ruhe eingekehrt und ich konnte mich ans aufräumen machen
• das in Verdacht stehende Verzeichnis mit den EMB-Perl-Scripten auf einen sicheren Platz verfrachtet und gelöscht (es handelte sich um Intranet-Dateien von dehnen ich eh nicht sicher bin ob die noch produktiv verwendet wurden)

Nach nunmehr 1,5 Tagen weitere Beobachtungen ist es fürs erste mal ausgestanden und der Angreifer abgewährt – die Analyse – Abwehr – Bereinigung kostete mich 9 Stunden Arbeit, brachten allerdings die Gewissheit dass er zumindest über diesen Weg nicht mehr eindringen kann. Ein Mehrwert der gar nicht hoch genug bewertet werden kann.

Ich darf zu guter Letzt noch auf die Summe der Faktoren für eine erfolgreiche Abwehr hinweisen (fast alle waren im obigen Szenario erfüllt – aber nur fast !!):

• Updates des Systemes (alle Programme !!!!) einspielen – bei Linux im Normalfall ein Klacks
• Tägliche Recovery-fähige Sicherung der (System-)Daten für den Fall das man zu spät kommt da das System massiv verändert wurde
• Ein aktives Monitoring das die (zumindest) wichtigsten Systemparameter checkt und im Falle des Falles zuverlässig alarmiert
• Jemanden der auf das Monitoring achtet (!!!)
• Jemanden der die installierten Scripts / Programme / Systeme kennt und aktuell hält ( <- hier war der Knackpunkt im obig beschriebenem Fall !! Das Intranet wurde einfach nicht mehr vom Programmierer gepflegt…)
• Jemanden der sich auskennt (nicht unbedingt notwendig – Gerne können Sie auch uns kontaktieren 🙂 )

Sollten Sie jemals in die Verlegenheit kommen sich gegen einen Eindringling zu wehren: Vergessen Sie bitte nicht auf die Protokolierung der Ereignisse – Sie müssen unter Umständen beweisen dass die abgelegten XXX-Videos nicht von Ihnen stammen ….