Linux-Magazin_-_Januar_2019

(singke) #1
übernommen hat: Monitoring und In-
trusion Detection. Auch das BSI erwähnt
diese Maßnahmen explizit.
Weitere betreffen den OSI-Layer 8, also
den User vor dem Bildschirm [10]. Ihn
sollen nicht nur strenge Passwortricht-
linien erziehen. Admins sollen seinen
Fernzugriff aufs absolute Minimum ein-
schränken und die „verwendete Server-
software einem besonders intensiven Mo-
nitoring in Bezug auf ihre Schwachstellen
und Exposition“ unterziehen.
Jeder Hack stellt zugleich einen Anlass
dar, um geltende Regeln unter die Lupe
zu nehmen und etwa zu prüfen, ob die
verwendeten Container vielleicht doch
veraltete Software verwenden, die als
Einfallstor diente. Wer sich dann noch
fortlaufend weiterbildet und die aktuel-
len Schwachstellen kennt, dem jagt auch
Active Directory [11] weniger Angst ein,
weil er für das Schlimmste gewappnet ist.

Fehlerhafte Hardware und
Betriebssysteme

Der BSI-Bericht zieht auch all jenen den
Zahn, die glauben, hundertprozentige
Sicherheit sei möglich. Das betrifft so-

net Anleitungen für erste Hilfe nach dem
Hack. Grob zusammengefasst stehen am
Ende drei Aussagen:
n Vorbereitung ist alles: Ruhig blei-
ben und nur das Notwendigste für
die Suche nach dem Urheber auf-
wenden. Zum Thema Vorbereitung
gehören Monitoring, IDS und Backup
und Restore sowie das regelmäßige
Awareness-Training und Studium der
neuesten IT-Sicherheitslage. Nur wer
gut vorbereitet ist, kann auch dann
ruhig bleiben, wenn es brennt.
n Das Problem entfernen: Der gehackte
Server muss so schnell es geht vom
Netz. Hier kommt die erste wichtige
Entscheidung: Wer gerichtsfeste Be-
weise braucht, um den Urheber des
Angriffs dingfest zu machen, der sollte
auch gerichtsfeste Tools verwenden,
um einen Snapshot des gehackten Sys-
tems zu ziehen.
n Einfallstor ausfindig machen und
schließen: Die Analyse des befallenen
Systems (oder der Systeme) sollte ein-
zig dazu dienen, den Angreifer erfolg-
reich auszusperren, den Zugang zu
sperren und einen erneuten Einbruch
auszuschließen.
Diese drei Ratschläge decken die wohl
wichtigsten Punkte ab und können
Admins als Faustregeln dienen.

Ursachenforschung


Wer nach dem Hack – sei es wegen Scha-
denersatzforderungen oder ähnlichen
Gründen – forensische Nachforschungen
anstellen muss, dem stehen verschiedene
Tools zur Seite. Für die bitweise Kopie,
die das Original nicht verändert, bieten
sich Klassiker wie »dd« an. Eine Forensik-
Lektüre aus der Uni Washington [12], die
das nötige Vorgehen beschreibt, ist auch
heute noch relevant.
Vom kompromittierten Server zieht der
Admin eine Kopie, die er neu starten und
weiter untersuchen kann. Beim Entfer-
nen des Systems sollte der Admin natür-
lich betroffene Clients beziehungsweise
Kunden benachrichtigen – eine Rundmail
oder ein Platzhalter auf dem Webserver
sind unvermeidbar.
Dann gilt es, das mit »dd« erstellte Image
zu durchsuchen. Protokolldateien, tem-
poräre Dateien, Prozesslisten, offene
Ports, Serverdienste und E-Mail-Warte-

wohl Fehler in der Hardware als auch
in Betriebssystemen. Zu Spectre und
Meltdown schreibt das BSI: „Die Prob-
lemklasse bleibt, bedingt durch ihre tiefe
strukturelle Verwurzelung in der Hard-
ware, bis auf Weiteres erhalten.“
Zu Smartphone-Systemen wie Windows
Phone, I-OS und Android heißt es: „Ein
Produkt, welches zum Zeitpunkt des
Kaufs öffentlich bekannte Schwachstellen
enthält, muss aus IT-Sicherheitsgesichts-
punkten als mangelhaft angesehen wer-
den, wenn auf die Schwachstellen nicht
ausdrücklich hingewiesen wird oder kein
entsprechendes Sicherheitsupdate beim
Kauf zur Verfügung steht.“
Die Behörde wünscht sich gerade hierbei
auch, dass Verbraucher ihre Rechte of-
fensiver wahrnehmen und von den Her-
stellern verlangen, dass sie ihre Software
pflegen und Schwachstellen beheben.

Guter Rat


Wer sich, was gehackte Systeme angeht,
nicht nur beim BSI, sondern generell bei
IT-Experten und Security-Spezialisten
umhört, kommt meist zu ähnlichen Er-
gebnissen. Zugleich kursieren im Inter-

01 $ echo "stats" | netcat 192.168.45.67 11211
02 STAT pid 1090
03 STAT uptime 1808125
04 STAT time 1483622758
05 STAT version 1.4.14 (Ubuntu)
06 STAT libevent 2.0.21‑stable
07 STAT pointer_size 64

08 STAT rusage_user 57.424253
09 STAT rusage_system 54.322505
10 STAT curr_connections 5
11 STAT total_connections 643
12 STAT connection_structures 9
13 STAT reserved_fds 20

Listing 1: Memcached-Lücke finden

Abbildung 4: Sicherheitsmaßnahmen rund um Netzwerkabsicherung, Antivirus und organisatorische Maßnah-
men liegen auf Platz 1 bis 3 in Unternehmen.

Titelthema

28


http://www.linux-magazin.de

Maßnahmen
Free download pdf