Um sich vor Gefahren aus dem Internet zu schützen, braucht man eine Firewall. Doch wenn diese installiert ist und es passiert nichts, dann ist das mit den Hackern wohl bloß Übertreibung und alles nur rausgeschmissenes Geld. Oder?

Wie die neue unfreiwillige Open Source von Microsoft [1] zeigt, sind Hacker eine ernst zu nehmende Bedrohung. Der Angriff selbst legte jedoch nur die Lücken bloß, die – historisch gewachsen – immer schon da waren und aus Bequemlichkeit oder um den Arbeitsablauf nicht zu stören nicht geschlossen wurden. Dem Autor ist eine Reihe von – nicht so namhaften – Firmen bekannt, denen es durchaus ähnlich ergehen könnte und die bislang nur Glück gehabt oder den Besuch noch nicht bemerkt haben.

Die meisten werden durchschnittlich jeden Tag zweimal angegriffen und mehrmals pro Monat finden sich Viren auf den Rechnern, die Rate schwankt dabei von Kunde zu Kunde. Nach der Installation von Firewalls gibt es dann meist eine Überraschung: Es werden Angriffe gemeldet, die bislang wegen der laxen Einstellung gar nicht angezeigt wurden. In zwei Fällen kam der Angriff von innen, es handelte sich um Trojaner-verseuchte Workstations (der Chefs). Auf Anwendungsebene gibt es immer wieder den Versuch, die Firewall als SMTP-Relay zu missbrauchen.

Der Fall Microsoft: Viele kleine Löcher im Sicherheitskonzept

Der Fall Microsoft zeigt jedoch, dass allein der Einsatz von Firewalls für die Internet-Sicherheit noch nicht ausreicht und dass durch die Kombination von mehreren, eigentlich harmlosen Sicherheitsmängeln ein Sicherheitsloch entstehen kann:

Doch was für Lehren sind daraus zu ziehen und was hat das mit unserem Thema zu tun?

Beschränkung der Information: Nicht alle müssen alles wissen

Viele Angriffe auf ein Firmennetz werden langfristig vorbereitet. Es geht dem Gegner zunächst darum, Kenntnisse über den Aufbau und mögliche Schwachstellen des Netzes zu bekommen. Macht man es dabei schon dem Angreifer sehr schwer, verliert er unter Umständen die Lust am Einbruch oder versucht es ein Haus weiter, unser Nachbar möge es uns verzeihen. Für ein LAN mit Verbindung ins Internet heißt das:

Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Interesting ports on  ([Internetadresse gelöscht]):
(The 1520 ports scanned but not shown below are in state: filtered)
Port       State       Service
22/tcp     open        ssh
25/tcp     open        smtp
113/tcp    open        auth

TCP Sequence Prediction: Class=random positive increments
                         Difficulty=1580537 (Good luck!)
No OS matches for host (If you know what OS is running on it,
see http://www.insecure.org/cgi-bin/nmap-submit.cgi).

Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Interesting ports on [Name gelöscht] ([Internet-Adresse gelöscht]):
(The 1511 ports scanned but not shown below are in state: closed)
Port       State       Service
7/tcp      open        echo
9/tcp      open        discard
13/tcp     open        daytime
17/tcp     open        qotd
19/tcp     open        chargen
21/tcp     filtered    ftp
135/tcp    open        loc-srv
139/tcp    open        netbios-ssn
158/tcp    open        pcmail-srv
427/tcp    open        svrloc
5631/tcp   open        pcanywheredata
65301/tcp  open        pcanywhere

TCP Sequence Prediction: Class=trivial time dependency
                         Difficulty=16 (Easy)
Remote operating system guess: Windows NT4 / Win95 / Win98

Nmap run completed  1 IP address (1 host up) scanned in 19 seconds

Die (Zugangs)-Beschränkung macht den Meister

In vielen Fällen werden durch Bequemlichkeit, Personal- und Geldmangel oder einfach durch Zeitdruck riskante Kompromisse bei der Internet-Sicherheit in Kauf genommen. Lässt man dies zu oder will diesen Zustand erst später ändern, erweist sich das wegen der gewachsenen Strukturen häufig als beinahe undurchführbar. Ein sicherer Schutz des Gesamtnetzes ist meist nur bei einer grundsätzlichen Restrukturierung möglich.

Eine klare Netzwerktopologie schafft auch die Voraussetzung für eine durchschaubare Firewall-Policy. “Security by obscurity” gibt es nicht.

Was ist ein Angriff im Internet?

Die Antwort auf diese einfache Frage ist äußerst schwierig. In bestimmten Fällen ist sie nicht allgemein zu beantworten und kann sogar von Kunde zu Kunde variieren. Linux 2.4 mit netfilter hat auf der Paketebene einige entscheidende Verbesserungen bekommen, die sowohl die Sicherheit erhöhen, als auch in Zweifelsfällen eine Klassifizierung erlauben.

Beinahe jeder würde mir zustimmen, wenn ich behauptete, ein Ping (ICMP echo request) wäre aus sicherheitstechnischer Sicht harmlos. Ein Ping an mehrere aufeinander folgende IP-Adressen kann aber ein Host-Scan sein (man ermittelt, welche Hosts zwar im Internet erreichbar, aber nicht im DNS eingetragen sind), ein Ping auf eine Broadcast-Adresse (255.255.255.255) ist eine so genannte Smurf-Attacke, die wahre Paketstürme entfalten kann.

Viele Windows-Rechner sind vorkonfiguriert und versuchen, im Internet mit allen Rechnern, die auf den Zielports 137-139 antworten, Kontakt aufzunehmen und Informationen auszutauschen. Die Windows-Rechner haben als Quellport ebenfalls 137-139. Es gibt aber auch Implementierungen, die andere, meist unprivilegierte Quellports benutzen (zum Beispiel Samba).

Wenn dann ein wildfremder Rechner aus dem Internet heraus versucht, auf die SMP-Ports zuzugreifen, findet man den Quellport des spionierenden Rechners auch oft im unprivilegierten Bereich. Dabei handelt es sich offensichtlich nicht um eine Fehlkonfiguration, sondern um ein Ausspähen.

Besonders interessant wird die Frage bei Rechnern, die es noch gar nicht gibt. Bei einem meiner Kunden wurde ein Class-C-Netz zugeteilt, wobei in den ersten Tagen außer der Firewall und dem Router keine Adresse von ihm benutzt wurde. Hier kann man wunderschön sehen, dass sämtliche Adressen angesprochen werden, manchmal nur schwach durch eine Zufallsreihenfolge getarnt.

Manche Pakete benutzen Sicherheitslücken, die seit einigen Jahren bekannt und behoben sind, etwa überlange Pakete beim Ping (Ping of Death), so genannte XMAS-Pakete (spezielles TCP-Paket, bei dem alle Flags gesetzt sind) oder Pakete mit einem unzulässigen Ziel- oder Destination-TCP-Port (zum Beispiel Port 0).

Die zuletzt genannten Punkte sind darauf gerichtet, einen Denial-of-Service zu verursachen, also die Firewall (zeitweilig) unbrauchbar zu machen. Viel häufiger sind jedoch die Angriffe, die zunächst Informationen sammeln. In einem zweiten Schritt werden diese Informationen zu gezielten Attacken benutzt. Oft – und hier wird es für Firewall-Administratoren interessant – ist eine merkwürdige Quell- und Zielport-Kombination zu beobachten, um direkte Angriffe ohne zusätzliches Wissen vorzunehmen: beide Ports sind identisch, also zum Beispiel Quellport 21 bei FTP- oder 80 bei HTTP-Zugriffen.

Diese Vorgehensweise nutzt Sicherheitslücken bei Firewalls ohne SYN-Flag-Abfragen im TCP aus. Es gibt ein spezielles Flag bei TCP-Verbindungen, das den Aufbau einer neuen Verbindung kennzeichnet: das so genannte SYN-Flag. Nur beim ersten Paket ist dies gesetzt, das Antwortpaket vom Verbindungspartner hat zusätzlich noch das SYN-Flag gesetzt. Hat der Firewall-Administrator generell FTP oder HTTP ins Internet zugelassen (Zielport 21 beziehungsweise 80), aber den Rückweg nicht, öffnen Pakete mit Quell- und Zielport 21 respektive 80 natürlich FTP-Command oder HTTP nach innen. Ist die TCP-SYN-Abfrage nicht konfiguriert oder nicht konfigurierbar, ist der Weg ins LAN offen.

Viele Administratoren scheuen davor zurück, eine paranoide Sicherheitspolicy zu implementieren, nämlich jedes suspekte Paket anzuzeigen, da dadurch natürlich das Log sehr viel umfangreicher ausfällt (zumindest vorerst). Das ist aber die einzige Möglichkeit, einen Angriff nachzuweisen und daraus zu lernen. In einem Fall konnten wir erst durch die paranoide Einstellung einen fehlkonfigurierten Windows-PC mit eigener ISDN-Karte (und Internet-Verbindung an der Firewall vorbei) diagnostizieren und das Sicherheitsloch schließen.

Angriffe erkennen: Die Nadel im Heuhaufen

Das vorsichtige Vorgehen führt jedoch nach wenigen Versuchen bereits dazu, dass Konfigurationsfehler von PCs (zum Beispiel falsche Netzmaske) erkannt und ausgebessert werden können. Und der Administrator weiß, was tatsächlich in seinem Netz passiert. Jede Änderung in der LAN-Infrastruktur wird ihm nämlich in Form von Packet-Logs angezeigt (SMB-Falschkonfiguration und Multicast-Adressen – 224.x.y.z sind derzeit hier die Renner).

Nach wenigen Tagen bleiben dann nur noch Pakete übrig, die potenzielle Angriffe sein könnten. Ein nmap-Scan wie in den beiden Tabellen gezeigt, verursacht etwa 1 MByte Log, so dass alleine schon die Größe der Log-Datei Alarmklingeln schrillen lassen muss. Natürlich hat netfilter gegenüber seinem Vorgänger ipchains Vorteile, man kann derartige Pakete melden und nach einer selbst festgelegten Grenze zeitbegrenzt unterdrücken, so dass das Log nicht voll läuft.

Ein Hacker möchte so wenig wie möglich auffallen, deshalb ist es verkehrte Sicherheitspolitik, die Pakete zu unterdrücken und die Angriffe damit zu ignorieren.

Räuber und Gendarm: Die Verfolgung von Hackern

Drehen wir den Spieß um: Der Jäger wird zum Gejagten. Anhand seiner IP-Adresse können wir den Angreifer identifizieren. Normalerweise ist diese nicht gefälscht, denn er möchte ja Antwort auf seine Angriffe haben. Jetzt noch ein nslookup – und wir kennen den Provider und schicken diesem eine Mail, dass er seinen Kunden zur Räson bringt.

Leider führt das nur in den seltensten Fällen zum Erfolg. Die großen Provider sind zwar sehr wohl in der Lage zu sagen, wann wer mit welcher Dial-up-Adresse aktiv war und können den Kunden identifizieren, das kostet jedoch Geld und wird nur in Ausnahmefällen gemacht. Rechner mit festen IP-Adressen hingegen sind häufig gar nicht die Verursacher, sondern selbst nur Opfer, die zu den in Mode gekommenen verteilten Angriffen benutzt werden.

Will man sich diesem zeitaufwändigen Verfahren, vergleichbar mit dem Kampf gegen Windmühlen, aussetzen, empfiehlt es sich also, zunächst bei Rechnern mit festen IP-Adressen mit dem Administrator des Rechners Kontakt aufzunehmen. Bei Dialup-Adressen müssen wir den Provider informieren. Dem Autor ist es dabei aber passiert, dass der Provider (CC an Kunde) über einen Angriff (Port- und Host-Scan) informiert wurde und der Kunde später anrief, um mitzuteilen, dass er selbst die Qualität des Servicevertrags testen wollte und den Angriff vom heimischen Büro vorgenommen hatte.

Wegen der großen Anzahl von Angriffen ist es absolut aussichtslos, Angreifer allgemein zu verfolgen, es sei denn, durch internationale gesetzliche Regelungen, mit denen wahrlich nicht zu rechnen ist. Nur bei besonders krassen Fällen ist dies im Einzelfällen möglich.

Ausblick: Mit 2.4 wird vieles besser

Linux 2.4 bietet neben einem verbesserten Paketfilter noch weitere Möglichkeiten, etwa Gegenmaßnahmen gegen SYN-Flooding und IP-Spoofing. Durch Traffic Shaping (Bandbreitenbegrenzung) kann gewährleistet werden, dass auch bei einem Angriff der Betrieb noch aufrecht erhalten bleibt.

Auch im VPN ist eine Identifikation von Angriffen möglich, der Feind im eigenen Bett kann auch hier identifiziert werden. Der innere Schutz von Unternehmen gegen Bedrohung von innen wird in den nächsten Jahren immer mehr an Bedeutung gewinnen.

Firewalls sind nicht per se sicher, erst durch eine sichere Konfiguration und permanente Überwachung können Angriffe erkannt und potenzielle Sicherheitslücken geschlossen werden. Die Analyse der Situation erfordert dabei sehr gute Kenntnis der IP-Protokolle und permanente Weiterbildung des Analysten. In jedem Fall sollte mit den verfügbaren freien Tools ein Eigen-Angriff gefahren werden, getreu dem Motto: Wenn Sie es nicht tun, der Angreifer tut\’s bestimmt.

Internet-Sicherheit kostet Geld, mehr Geld, als manche Geschäftsführung ausgeben möchte. Eine Vogel-Strauß-Politik ist jedoch kurzsichtig und schadet dem Unternehmen langfristig mehr als eine Sicherheitslösung je gekostet hätte. ( tfr)

Copyright © 2000 Linux New Media AG