© ginasanders, 123RF

Auch wer im Admin-Alltag alles richtig macht, kann jederzeit Opfer einer Attacke werden. Peer Heinlein, Ralf Spenneberg und Christoph Wegener schildern im Interview, was Systemverantwortliche tun und was sie besser lassen sollen, wenn in ihrem Netzwerk alles zu spät ist.

Laut einer Umfrage des Branchenverbands Eco [1] beklagten 18 Prozent der befragten deutschen Unternehmen im Jahr 2017 mindestens einen gravierenden Sicherheitsvorfall. Die größten Bedrohungen gingen demnach von Ransomware und DDoS-Attacken aus. Naturgemäß fließen in solche Zahlen die unbemerkt gebliebenen Angriffe nicht ein.

Ein angemessener Grundschutz, für den jedes Unternehmen selbst sorgen muss, bildet die beste Prävention gegen ungebetene Besucher. Dazu gehören tägliche Datensicherungen, zügig eingespielte Software-Updates, starke Passwörter, Schutz vor unbefugtem Zugriff auf personenbezogene und andere sensible Daten sowie Berechtigungsmanagement und Verschlüsselungen.

Linux-Rechner mit ihren ebenso stringenten wie leicht verständlichen Berechtigungen sind gegen Angriffsversuche vergleichsweise im Vorteil, wenn alle Aktualisierungen eingespielt sind. Eine Gewähr auf Unverwundbarkeit besteht aber auch bei ihnen nicht. Also muss jeder Admin mit einer Kompromittierung eines oder mehrerer Systeme rechnen.

Aber woran merkt er, dass etwas nicht stimmt? Und wie soll er darauf reagieren? Wann und wem muss er den Vorfall melden? Das Linux-Magazin hat drei ausgewiesenen Sicherheitsexperten dieselben drei Fragen gestellt.

Peer Heinlein

Peer Heinlein ist E-Mail-Spezialist, Gründer des sicheren E-Mail-Dienstes Mailbox.org und Autor zahlreicher Fachbücher zum Thema Linux-Server und Sicherheit. Er berät Unternehmen und Internetprovider in allen Fragen rund um elektronische Kommunikation: als Consulting vor Ort oder in Berlin an der Heinlein Akademie. Linux-Magazin: An welchen Merkmalen oder Effekten erkennst Du, dass ein Linux-Server vermutlich kompromittiert ist?

Peer Heinlein: Es gibt verschiedene Arten von kompromittierten Servern: Hat der Angreifer durch eine Lücke eigenen PHP-Code im Webspace abgelegt? Hatte er Shellzugriff durch einen unprivilegierten User-Account? Oder ist es ihm am Ende gelungen, tatsächlich echten Rootzugang zu bekommen?

Jedes Szenario äußert sich in anderen Symptomen, aber in der Regel tut der Rechner fortan irgendwas, und das äußert sich zuerst in zusätzlichem oder ungewöhnlichem Datenverkehr. Versendet er Spam-Mails, ist der damit erzeugte Traffic offensichtlich. Aber auch wenn er nur Phishing-Webseiten hostet, wird dies bereits im Logfile durch ungewöhnlich viele Aufrufe als Anomalie erkennbar.

Konnte der Angreifer hingegen eigene Programme starten – zum Beispiel weil der Systemverantwortliche in PHP entsprechende »exec()«-Aufrufe nicht unterbunden hat –, zeigt die Prozessliste vielleicht “auffällig unauffällige” Prozesse, die sich mehr schlecht als recht unter einem harmlosen Namen zu tarnen versuchen: Wenn es angeblich einen Prozess namens »cron« gibt, der jedoch dem User »wwwrun« gehört, ist der Befund schon offensichtlich.

Keine Chance bei Rootkits

Nur wenn ihm echter Rootzugriff gelungen ist, kann sich der Angreifer tatsächlich unsichtbar machen. Rootkits modifizieren Systemtools oder den ganzen Kernel, sodass sie verräterische Prozesse, Dateien, offene TCP-Ports und den IP-Traffic das Angreifers ausblenden. Auf dem kompromittierten System ist es dann kaum möglich, den Angreifer zu finden, denn der Admin sieht alles durch die Filterbrille des Angreifers.

In der Praxis kommt ein Großteil der Angreifer jedoch kaum so weit. Dort dominiert das Brot-und-Butter-Geschäft der Spammer, Phisher und Kreditkartenbetrüger: Über eine Sicherheitslücke in einschlägigen CMS-Webseiten installiert der Angreifer eigenen Content auf dem Webserver, versendet Spam oder hostet Malware – echten modifizierenden Zugriff auf das System erlangen die wenigsten.

Linux-Magazin: Welche sind die häufigsten Fehler, die Admins nach dem Erkennen eines erfolgreichen Angriffs auf ihre Systeme begehen?

Peer Heinlein: Wie so oft gilt: Keine Panik! Wenn der Geschädigte davon ausgehen darf, dass das Problem schon länger besteht und dass nicht gerade akut sensible Daten aus dem Netzwerk abfließen, besteht kein Grund zu blinder Hektik.

Wer das System gut gemeint neu installiert, aber am Ende das gleiche kaputte CMS ohne Bugfix wieder einspielt, wird wenige Stunden oder Tage später wieder infiziert sein. Sind alle Beweise zerstört, lässt sich auch kein Code mehr analysieren, der Rückschlüsse darauf zulässt, welche Ziele der Angreifer verfolgte und ob er beispielsweise Datenbanken kopiert oder ausgelesen hat. Am Ende ist diese Unwissenheit der größte Schaden.

Linux-Magazin: Welche Vorgehensweise empfiehlst Du? Betroffene Systeme abschalten und Festplatten- beziehungsweise VM-Images forensisch untersuchen? Oder weiterlaufen lassen und den Einbrecher beobachten? Lohnt es, Energie in die Attribution zu investieren?

Peer Heinlein: In jedem Fall sollte der Admin recherchieren und vor allem dokumentieren, um die Ursachen für den Einbruch aufzuklären. Denn er muss aus dem Vorfall lernen und Lücken schließen, sonst ist es nur eine Frage der Zeit bis zur Wiederholung. Das Dokumentieren sollte umfassend erfolgen, selbst in den Bereichen, die zunächst harmlos aussehen: Ein vollständiger Dump der Prozessliste, offener TCP-Verbindungen, neuralgischer Speicherorte wie dem »/tmp«-Verzeichnis und aller Logfiles.

Auch sollte der Admin mit »lsof« offene Dateien als Liste dokumentieren. So kommt er Angreifern auf die Spur, die eigene Dienste ins System kopiert und gestartet, dann aber die Programmdateien gelöscht haben, damit diese nicht mehr im Dateisystem zu finden sind. Offene, aber bereits als gelöscht markierte Dateien sollten argwöhnisch machen, und der Admin sollte den zugehörigen Prozess genau anschauen. Er kann dann über die Prozessnummer im »/proc«-Verzeichnis sogar noch auf den gelöschten Programmcode zugreifen (Abbildung 1).

Abbildung 1: Über die Prozessnummer im »/proc«-Verzeichnis ist der Zugriff auf Executables möglich, die nicht mehr auf der Festplatte liegen.

Leichter bei Virtualisierung

Von virtualisierten Servern ist in vielen Fällen ein Snapshot mitsamt allen Daten leicht anzufertigen – das hilft, wenn der Geschädigte erst später erkennt, wonach er eigentlich suchen muss. Gut ist es in diesen Fällen auch, wenn sich der Zustand des Servers zur Laufzeit, das heißt zusammen mit den aktiven Programmen, sichern lässt.

Am Ende muss der Administrator entscheiden, ob eine tiefgehende Analyse des Servers lohnt: War der Angriff zielgerichtet, ein echter Hack also, bei dem man mit allem rechnen muss? Oder handelt es sich nur um den üblichen Massenschaden im Webspace? Dazu zählt natürlich auch die Bewertung, wie sensibel das kompromittierte System war: Sind interne Daten oder nur eine Webvisitenkarte betroffen? Wie wahrscheinlich ist, dass sich neben dem Schadcode des Angreifers weitere Modifikationen auf dem System befinden?

Wer sich als besonders gefährdet ansieht und annehmen muss, er wäre das echte Target des Angreifers gewesen, braucht professionelle Hilfe eines Forensikers, bevor er selbst den Tatort aufräumt und Beweise vernichtet.

Ralf Spenneberg

Ralf Spenneberg ist Geschäftsführer der Open Source Security GmbH. Sein Unternehmen berät Behörden und Unternehmen im Bereich Informationssicherheit. Hierbei prüfen seine Mitarbeiter und er im Auftrag von Kunden auch die Widerstandsfähigkeit von Industriesteuerungen und IoT gegenüber Angriffen. Linux-Magazin: An welchen Merkmalen oder Effekten erkennst Du, dass ein Linux-Server vermutlich kompromittiert ist?

Ralf Spenneberg: Das beste Anzeichen ist ungewöhnlicher und unerklärlicher Netzwerkverkehr. Somit ist auch eines der besten Erkennungsmittel eine sinnvolle und stark eingeschränkte Konfiguration der Gateways zum Internet. Fast sämtliche Malware ist darauf angewiesen, Code nachzuladen, oder sie versucht anschließend Command-and-Control-Server zu erreichen. Eine sinnvolle Netzwerksegmentierung mit starken ACLs kann dies verhindern und erkennen.

Befinden sich alle Drucker in einem eigenen Subnetz und baut ein Drucker plötzlich Verbindungen ins Internet auf, ist dies ein starker Hinweis. Viele Server kommunizieren nur LAN-intern und greifen regulär aufs Internet nur zu, wenn sie Updates beziehen wollen. Selbst diese Verbindungen lassen sich über einen lokalen Paketspiegel reduzieren.

Mit entsprechenden ACLs und mit Logging auf den Gateways erkennt der Admin ungewöhnliche Verbindungen. Eine geografische Auflösung der IP-Adressen anhand einschlägiger Datenbanken hilft bei der Identifikation.

Linux-Magazin: Welche sind die häufigsten Fehler, die Admins … begehen?

Ralf Spenneberg: Eigentlich werden die Fehler vorher begangen. Das häufigste Versäumnis ist fehlende Vorbereitung. Die Unternehmen beziehungsweise die Admins haben sich dann nicht gedanklich auf den Fall vorbereitet und entschieden, wie sie damit umgehen wollen. Hierdurch geraten sie in eine unvorbereitete Situation. Der einhergehende Stress und die scheinbare Dringlichkeit verführt sie häufig zu Handlungen, die sich im Nachgang als falsch erweisen.

Besonders wichtig ist es für den Admin, im Vorfeld geklärt zu haben, ob eine Weitergabe an die Strafverfolgungsbehörden gewünscht ist oder ob der Betrieb Vorrang hat. In vielen Geschäftsbereichen sind die Betreiber inzwischen dazu verpflichtet, bestimmte Ereignisse zu melden (KRITIS, DSGVO). Den Umgang mit gravierenden Sicherheitsvorfällen beobachten auch übergeordnete Regulierungsbehörden und die Öffentlichkeit genau.

Meldepflicht nach DSGVO

Sind durch den Einbruch personenbezogene Daten betroffen, muss das Unternehmen den Vorfall melden. Eine Meldepflicht gab es bereits zuvor durch das Bundesdatenschutzgesetz (BDSG), doch trat 2018 die Europäische Datenschutzgrundverordnung (DSGVO) und mit ihr die verschärfte Meldepflicht in Kraft. Unternehmen haben jetzt höchstens 72 Stunden Zeit, um eine Datenschutzverletzung der zuständigen Aufsichtsbehörde zu melden (Artikel 33).

Hierbei betrifft die Meldepflicht alle personenbezogenen Daten, und fast immer sind welche abhandengekommen. Daher ist es besonders wichtig, sich mit entsprechenden Vorbereitungen zu rüsten. Ein derartige Vorfall kann übrigens bereits simpel durch den Verlust eines Laptops oder USB-Sticks eintreten.

Linux-Magazin: Welche prinzipielle Vorgehensweise empfiehlst Du? …

Ralf Spenneberg: Dies hängt zunächst sehr stark von dem Unternehmen beziehungsweise dem betroffenen System ab. Wie eben erwähnt sind viele Geschäftsbereiche hier inzwischen auch gesetzlich reguliert. Daher sollte das Unternehmen immer prüfen, ob es solchen Regelungen unterworfen ist.

Ist dies nicht der Fall, hängt alles Weitere von den Zielen des Admin oder des Unternehmens ab. Plant der Geschädigte die Kosten für den Ausfall zivilrechtlich geltend zu machen? Auch dann sind eine saubere Planung und möglicherweise externe Unterstützung sinnvoll, damit die Attribution einwandfrei ist. In allen anderen Fällen darf der Admin dies ganz nach seinem Gutdünken entscheiden.

Eine genauere Analyse erscheint jedoch immer dann geboten, wenn der genutzte Angriffsweg nicht bekannt ist. Ansonsten läuft der Admin Gefahr, dass das System direkt nach dem Neuaufsetzen wieder kompromittiert wird.

Dr. Christoph Wegener

Christoph Wegener ist promovierter Physiker und seit 1999 mit der wecon.it-consulting als Berater und Gutachter für die Themen Informationssicherheit und Datenschutz unterwegs.

Christoph Wegener: Eine Kompromittierung ist nicht immer leicht zu erkennen. Am einfachsten ist es, wenn der Angreifer sich zu wenig Mühe gegeben hat, seine Aktivitäten zu verstecken. Dann liefern eine ungewöhnliche CPU-Auslastung oder unbekannte Netzwerkaktivitäten auffällige Hinweise, denen der Admin unbedingt nachgehen sollte. Ein Host Intrusion Detection System ([2], [3], [4])leistet bei der Erkennung von verdächtigen Aktivitäten gute Dienste.

Ein fähiger Angreifer wird sich aber eher unauffällig verhalten und versteht es auch, seine Aktivitäten beispielsweise mittels Rootkit-Technologien [5] so gut zu verstecken, dass der Administrator zumindest mit Bordmitteln des Betriebssystems keine Spuren finden wird.

Linux-Magazin: Welche sind die häufigsten Fehler, die Admins … begehen?

Christoph Wegener: Häufig fällen Betroffene in Panik eine falsche Entscheidung und installieren beispielsweise einfach alle Systeme neu. Damit gehen aber alle Informationen zur Art und Weise der Kompromittierung verloren, und keiner kann mehr aufklären, was alles betroffen war, und etwas für die Zukunft aus dem Vorfall lernen. Um Panikentscheidungen zu vermeiden, sollte sich eine Organisation bereits im Vorfeld auf den Fall des Falles vorbereiten und festlegen, was beim Verdacht einer Kompromittierung zu tun und wer zu involvieren ist.

Linux-Magazin: Welche prinzipielle Vorgehensweise empfiehlst Du? …

Christoph Wegener: Besteht der Verdacht auf eine Kompromittierung des Systems, ist zunächst zu klären, ob eine forensische Untersuchung des Vorfalls ansteht. Wenn ja, ist vor weiteren Maßnahmen eine forensische Kopie der Datenträger und des Hauptspeichers anzufertigen. Da die meiste Organisationen für diese Prozesse keine ausreichenden Erfahrungen besitzen, empfiehlt es sich in der Regel, einen Experten hinzuzuziehen. Dieser kann sicherstellen, dass die erzeugten Images technisch für eine weitere Untersuchung geeignet sind.

Gibt es keine weiteren Vorgaben, beispielsweise von einer Versicherung, sollte die geschädigte Firma im Einzelfall entscheiden, ob eine solche forensische Untersuchung überhaupt Sinn ergibt. Dabei sind die Kosten und der erreichbare Nutzen gegeneinander abzuwägen. Den Einbrecher zu beobachten ist üblicherweise keine sinnvolle Option, sondern potenziell sogar gefährlich, denn niemand kann sicher wissen, was dieser bereits an Mechanismen im System eingebaut hat und was er im weiteren Verlauf noch unternehmen wird.

Eine Attribution ist zwar interessant, bringt der betroffenen Organisation aber in der Regel keinen echten Mehrwert. Viel wichtiger dagegen ist es, die Ursache der Kompromittierung zu ermitteln und so eine Wiederholung eines solchen oder ähnlich gelagerten Vorfalls effektiv zu verhindern.