Fangfragen
Angriffe auf die IT-Infrastruktur von Unternehmen sind mit automatisierten Werkzeugen auch für relativ unbedarfte Anwender kein Problem. Das Gefahrenpotenzial von Portscannern & Co. lässt sich aber beruhigenderweise auch nutzbringend einsetzen.
- Jörg Fritsch
IT-Sicherheit ist, anders als die Hersteller von Firewall- und Verschlüsselungsprodukten gerne den Anschein erwecken, keine käufliche Hardware oder Konfiguration, sondern vielmehr ein komplexer, fließender Zustand. Für ein Maximum an Sicherheit sind zahlreiche Faktoren sorgfältig aufeinander abzustimmen. Firewalls zum Beispiel leisten einen beachtlichen Beitrag, aber sie sind bei weitem nicht der einzige wichtige Bestandteil der Unternehmenssicherheit.
So sorgfältig die präventiven Bausteine gängiger Sicherheitstechnik (zum Beispiel Systemhärtung, Firewalls, Intrusion Detection) auch ausgewählt und eingerichtet sind: Erst ein aktiver Test der Infrastruktur mit den Mitteln potenzieller Angreifer gibt einen Eindruck über die Wirksamkeit der Maßnahmen. Wie die Produkte eines Unternehmens sollte auch dessen IT-Sicherheit regelmäßigen Qualitätskontrollen unterliegen. Gängige Hilfsmittel sowohl für böswillige Eindringlinge als auch für offiziell beauftragte Security-Berater sind Programme, die automatisch nach netzfähigen Anwendungen suchen, so genannte Portscanner.
Im Internetprotokoll sind zwei Bytes für die Festlegung von Portnummern vorgesehen, entsprechend können die Anwendungen 65 536 verschiedene Werte einsetzen. Die Prüfung sollte sich nicht auf die Standardports unter 1024 beschränken, sondern je nach Relevanz der Dienste auch den dynamischen Portbereich darüber berücksichtigen. Trojaner und Instant-Messaging-Software, RPC-Services und Dienste wie Veritas’ Netbackup sind als sicherheitskritisch einzustufen und in diesem Bereich anzutreffen. Oft wird vergessen, dass Backup und Datendiebstahl technisch identisch sind.
Laut dem Bundesamt für Sicherheit in der Informationstechnik (BSI, [1]) liegt ein Portscan vor, wenn ‘ein Angreifer in schneller Folge Portnummern anspricht, um festzustellen, welche Dienste auf einem Rechner laufen.’ Als nächsten Schritt testet der Angreifer die erkannten Services auf bekannte Schwachstellen (engl. Vulnerabilities), um diese dann mit einer Attacke für seine Ziele zu nutzen (Abb. 1). Ein Angriff, der bekannte Schwachstellen von Diensten ausnutzt, heißt im Fachjargon ‘Exploit’. Auch im gemeinsamen Projekt der Zeitschriften iX und Impulse lässt sich zunächst ein Portscan durchführen und in einer zweiten Stufe eine Reihe von Exploits testen. Näheres siehe auf Seite 28.
Je nach dem Hintergrund des Täters können die Ziele seiner Angriffe auf Unternehmensressourcen variieren. Ein geschasster Mitarbeiter mit Rachegelüsten hat es vielleicht auf die Integrität oder Vertraulichkeit der gespeicherten Daten abgesehen oder möchte einfach nur die Funktion und Verfügbarkeit der Rechner beinträchtigen. Der Spion für die Konkurrenz (häufig ebenfalls ein ehemaliger Mitarbeiter) oder Geheimdienstler will eventuell Daten ‘abfließen lassen’ und danach die Spuren seiner Tat verwischen, damit sie spät oder nie offenbar wird. Für derlei Aktionen benötigen Angreifer in der Regel Administrator- beziehungsweise Rootrechte, die sie sich im Verlauf einer Attacke verschaffen.
Bekannte Schwachstellen lassen sich zum Beispiel bei der Übermittlung überlanger Zeichenketten ausnutzen (‘Buffer Overflow’). Ausführbarer Code darin kann dem Angreifer ‘Raising Conditions’ verschaffen; im schlimmsten Fall steigert er seine eigenen Zugriffsrechte auf die des Systemverwalters. Hat der Angreifer bereits (User-)Rechte auf dem Zielsystem (Local Root Exploit), kann er Schwachstellen beliebiger (auch nicht netzfähiger) Programme auf dem Zielrechner nutzen. Local Root Exploits ist einerseits sehr schwer beizukommen, doch andererseits sind sie nur von einem kleinen Kreis bekannter Anwender einsetzbar, typischerweise den Mitarbeitern eines Unternehmens.
Ferne Angreifer, die nicht über (User-)Rechte auf dem Zielsystem verfügen, benötigen Remote Root Exploits als Einfallstore. Theoretisch ist jeder netzbasierte Service auf dem Zielsystem ein potenzieller Kandidat. Zahlreiche Programme dienen allein dazu, den Überblick über möglicherweise etwas zu kommunikative Dienste zu bewahren, bei Unix-Derivaten zum Beispiel lsof und netstat. Portscans wiederum lassen sich plattformunabhängig und aus externen Netzen heraus einsetzen.
Portscans: gut oder böse?
Die Frage, wie mit Portscans und anderen ‘Hackertools’ umzugehen ist, wurde und wird bis hin zur politischen Ebene viel diskutiert. Jeder Administrator, der sich etwas mit Netzsicherheit auseinander setzt, kennt Argumente sowohl dafür als auch dagegen (siehe Kasten ‘Strafbarer Angriff ...’). Derlei Ansichten sind höchst subjektiv. Fakt ist jedenfalls, dass sich die Argumente nur auf Rechner unter fremder Administration beziehen; nichts spricht gegen die Nutzung potenzieller Angriffswerkzeuge zur Verbesserung der eigenen Sicherheit.
Strafbarer Angriff oder heilsamer Test?
Jeder Versuch, Sicherheitslücken in Unternehmensnetzen aufzudecken, etwa mit Hilfe von Portscannern, sollte wohl überlegt und in Abstimmung mit dem Betreiber des getesteten Netzes erfolgen. Zu leicht kann der gut gemeinte Scan als strafbare Vorbereitung eines Angriffs interpretiert werden. Schlecht eingestellte Portscanner benötigen zudem so viel Übertragungskapazität, dass deren bloßer Betrieb ein Netz lahm legen kann. Allein das könnten Strafverfolger als kriminelle Handlung interpretieren, selbst wenn gar keine Sicherheitslücke aufgedeckt oder genutzt wurde.
Da andererseits Server- und Netzbetreiber jederzeit mit mutwillig oder versehentlich ausgelösten Angriffen rechnen müssen, sollten extern bestellte oder selbst durchgeführte Sicherheitschecks der eigenen Infrastruktur zum Alltag jedes Systemadministrators gehören.
Verglichen mit komplexer kommerzieller Software zur Netzüberwachung sind Portscanner preisgünstige Werkzeuge, die es erlauben, in kurzer Zeit viele Rechner zu untersuchen und die Ergebnisse übersichtlich aufzubereiten. Es spricht nichts dagegen, sie im eigenen IT-Betrieb regelmäßig selbst einzusetzen oder jemanden von außerhalb damit zu beauftragen.
Der zurzeit meistverbreitete nicht kommerzielle, reine Portscanner ist Nmap [2], der unter Windows, Mac OS X und so gut wie allen wichtigen Unix-Derivaten läuft. Neben den reinen Portscannern gibt es eine Reihe von Werkzeugen (zum Beispiel Nessus [3] oder Satan/Saint), welche die per Portscan erkannten Services weiterführenden Prüfungen unterziehen können. Dazu gehören Remote Root Exploits oder Windows-Fileshares.
Nicht kommerzielle Werkzeuge
Ein Auditing mit Nessus verläuft nicht anders als ein böswilliger Angriff (Abb. 1). Für das Auffinden möglicher Zielrechner und den Portscan verfügt Nessus nicht über eigene Mittel, sondern nutzt eine Schnittstelle zum Portscanner Nmap. Die nächste Stufe, die eigentliche Schwachstellenanalyse, absolviert Nessus derzeit mit 1049 Plug-ins in 23 Kategorien von Schwachstellen und Angriffen, die mit einer Vielzahl an zu testenden (Server-)Betriebssystemen zurechtkommen. Für jeden Rechner lässt sich über die Plug-ins bestimmen, welche Schwachstellen in Frage kommen: Ein Cisco-Router braucht zum Beispiel nicht auf Windows-Fileshares hin untersucht zu werden.
Nessus kann die Reports in zahlreichen Formaten (HTML, ASCII, PostScript, Nessus-proprietär) darstellen. Sie enthalten neben den gefundenen Schwachstellen eine Risikoeinschätzung, Tipps zur Beseitigung und weiterführende Hinweise (in der Regel die CVE-Nummer, siehe Kasten ‘Namensgebung’).
Namensgebung: Common Vulnerabilities and Exposures
Hinter dem Schwachstellenkatalog CVE steht das Bestreben, bekannte Angriffe mit einheitlichen und vor allem eindeutigen Namen zu versehen. Die Anzahl der verschiedenen Namen, unter denen ein und derselbe Angriff in der Literatur behandelt wird, ist proportional zur Anzahl der Informationsquellen für Netzwerksicherheit (CERT, Securityfocus, Cisco und viele andere) angestiegen.
CVE deckt keine neuen Schwachstellen auf und verfasst auch keine Advisories. CVE ist Internet-basiert und versteht sich als Wörterbuch und Datenbank, das für jeden bekannten Angriff einen CVE-Namen zusammen mit einer kurzen, standardisierten Beschreibung des Angriffs enthält. Dadurch wird die Austauschbarkeit sicherheitsrelevanter Informationen zwischen den einzelnen Datenbanken und deren Anwendern gefördert und Fehler aufgrund von Verwechslungen vermieden. Für die Hersteller bietet CVE zudem die Chance, die Leistung ihrer Produkte genauer spezifizieren zu können.
Scans mit und ohne Verbindungsaufnahme
Egal ob allein oder in Kombination mit Nessus verwendet: Nmap hat die Aufgabe herauszufinden, welche Ports des zu prüfenden Systems ‘offen’ sind, wo also Anwendungen laufen, die sich über das Netz nutzen lassen. Zu diesem Zweck gibt es eine Reihe mehr oder weniger bekannter Verfahren.
Am einfachsten ist es, sequenziell zu allen Ports eine Standard TCP-Verbindung aufzubauen (TCP Connection Scan); der Scanner benutzt also die RFC-gemäßen Systemaufrufe zum Aufbau von TCP-Verbindungen, die jedes Betriebssystem mitbringt (Abb. 3). Einzelne TCP-Ports kann man auch manuell überprüfen: Man gibt auf der Konsole des Remote-Systems einfach telnet IP-Adresse Portnummer ein. Wenn eine Antwort wie die folgende kommt, ist der angesprochene Port offen. Ein Scanner im TCP-Modus automatisiert dieses Verfahren lediglich:
[XMan:~] joergfri% telnet dns3.belwue.de 53
Trying 131.246.119.18...
Connected to dns3.belwue.de.
Escape character is '^]'.
Etwas komplizierter ist der Umgang mit Ports, an die ein UDP-Service gebunden ist. Als verbindungsloses Protokoll ist UDP nicht verpflichtet, eine Rückmeldung über den Erfolg oder Misserfolg eines Kommunikationsversuchs zu geben. UDP-Scans nutzen die Tatsache aus, dass der zu prüfende Host in vielen Fällen freundlicherweise doch in Form eines ICMP-unreachable-Pakets antwortet, wenn an den überprüften Port kein Service gebunden ist. ICMP, das Internet Control Message Protocol, ergänzt IP um Verbindungsinformationen. Wenn die Firewall ICMP passieren lässt, können Portscanner im Ausschlussverfahren bestimmen, welche Ports offen sind. Am einfachsten lässt sich mit dem Diagnosewerkzeug ping testen, ob ICMP-Pakete durchkommen.
Weder für die Übermittlung von UDP- noch für die von ICMP-Paketen gibt es eine Garantie, was zu falschen Ergebnissen (‘False Positives’) führen kann. Weil Nmap bei allen Ports, die nicht sofort mit ICMP-unreachable antworten, auf einen Timeout warten muss und die Generierung von ICMP-Paketen auf dem Zielhost niedrig priorisiert ist, benötigt ein UDP-Scan sehr viel Zeit. Das ist allen Verfahren gemeinsam, die versuchen, über indirekte Methoden oder durch ein ‘Überlisten’ der Systeme zum Ziel zu kommen. Der zusätzliche Informationsgewinn (inklusive False Positives) steht oft in schlechtem Verhältnis zur eingesetzten Zeit.
Zu den indirekten Verfahren zählen die Stealth-Techniken. ‘Tarnkappen’-Scans waren zumindest in der Anfangszeit kommerzieller Firewalls unbemerkt möglich. Sie zeigen offene Ports eines Systems, zu dem aber laut Regelwerk (Policy) der vorgeschalteten Firewall eigentlich gar kein Verbindungsaufbau möglich sein sollte. Bei den im Ergebnisteil von Nmap (Abbildung 2) mit ‘filtered’ bezeichneten Ports handelt es sich um solche trotz Sicherheitsmechanismen als offen erkannte Ports.
Stealth Scans versuchen die Sicherheitssysteme entweder beim Verbindungsauf- oder -abbau zu überlisten. Meist werden IP-Pakete geschickt, die gar nicht zu einem korrekten Verbindungsaufbau führen können. Der Scanner setzt darauf, dass eine Firewall solche Pakete als unbedenklich passieren lässt, weil sie, um Systemressourcen zu sparen, nur SYN-Pakete, die zu einem korrekten Verbindungsaufbau führen können, mit dem Regelwerk oder der Access-Liste vergleicht. Der Zielhost könnte dann in einer Weise antworten, die indirekte Rückschlüsse auf den geprüften Port zulässt.
Bei der als ‘FIN Stealth’ bezeichneten Technik schickt der Scanner ein IP-Paket mit gesetztem FIN-Flag, das unter normalen Umständen den Abbau einer Verbindung einleitet. Ist der Port offen, wird das Zielsystem dieses unsinnige FIN-Paket nicht beantworten. Pakete (egal ob SYN oder FIN) an Ports, die nicht an einen Service gebunden sind, werden jedoch zwingend mit RST (TCP-Reset) beantwortet.
Auch das mit ‘SYN Stealth’ bezeichnete Verfahren basiert auf diesem Verhalten. Die Resultate des Scans aus Abbildung 2 sagen demnach lediglich aus, dass Pakete an Port 22 aus irgendwelchen Gründen nicht mit TCP Reset beantwortet wurden.
Die Grenzen der Portscans
Kommerzielle Firewalls verfolgen den Verbindungsauf- und -abbau genau. Check Points Firewall-1 etwa verwirft alle Pakete, die nicht zu einer bestehenden Verbindung oder deren Aufbau gehören. Der Abgleich mit einem Zwischenspeicher (State Table) führt zur Erkennung vorgetäuschter TCP-Sessions oder laut Regelwerk nicht zugelassener Pakete und beim potenziellen Angreifer zu False Positives.
Bei einigen Hosting-Plattformen gehört der Schutz durch Firewalls auch heute noch nicht zu den im Leistungspaket enthaltenen Merkmalen. Das beim Untersuchen eines realen Hosts auf allen Ports unter Ausnahme von Port 22 empfangene RST-Flag lässt zum Beispiel den Schluss zu, dass der Host lediglich mit Access Lists (ACLs) auf Routern geschützt ist oder mit Einträgen in die Dateien /etc/hosts/allow und /etc/hosts/deny. Wenn man voraussetzt, dass es sich nicht um ein False Positive handelt (womit man bei indirekten Rückschlüssen von nicht gesendeten Paketen auf vorhandene Services immer rechnen muss), könnte dieser Host nicht mit einer Firewall-1 geschützt sein und einen Service auf Port 22 betreiben.
Wenn man Portscans zur Qualitätskontrolle einsetzen möchte, ist Check Points Firewall-1 seit Version 4.1 für deren Aussagekraft ein echtes Problem, was natürlich bezüglich des Schutzes von Netzen gegen Hacker durchweg positiv zu sehen ist. Ab dieser Release lässt sich Check Points Malicious Activity Detection (CPMAD) konfigurieren, ein einfaches Intrusion Detection System (IDS), das einige wenige Angriffe, unter anderem Portscans, erkennt und darauf reagiert (siehe Kasten ‘Abschirmdienst’). Da die CPMAD nur über Konfigurationsdateien und nicht per grafischer Oberfläche zu aktivieren und einzurichten ist, ist sie wenig bekannt. Aber selbst wenn CPMAD nicht konfiguriert wurde, macht die Firewall-Software intern von deren Fähigkeiten Gebrauch und verwirft eigentlich erlaubte Verbindungsversuche zu einem Host, sobald es sich mit Sicherheit um einen Portscan handelt. Check Point steht mit derlei Abwehrmaßnahmen nicht allein da, ähnlich verhält es sich mit Ciscos IOS Firewall Featureset oder bei Radwares Loadbalancern mit der ‘Synapps’-Architektur.
Abschirmdienst: Malicious Activity Detection
Check Point stellt ab Firewall-1-Version 4.1 das Feature ‘Malicious Activity Detction’ (MAD) ohne Aufpreis zur Verfügung. Es handelt sich um ein rudimentäres Intrusion Detection System (IDS), das nicht über die bekannte grafische Oberfläche, sondern per Datei konfiguriert wird ($FWDIR/conf/cpmad_config.conf). MAD kann derzeit zehn verschiedene Angriffe erkennen und den Administrator in Echtzeit per E-Mail informieren.
Zu den Angriffen, die MAD derzeit erkennt, gehören Portscans, auffallend viele Verbindungen zu einem Host, Spoofing, SYN-Flooding und auffallend viele fehlgeschlagene Authentifizierungen an der Firewall selbst (Client- oder User-Authentifizierung). Für fast alle Angriffsarten lassen sich zahlreiche Parameter einstellen, um die Anzahl von Fehlalarmen niedrig zu halten.
Die Erkennungsrate von Portscans hängt vor allem davon ab, in welchem Tempo die Ports nacheinander angesprochen werden. In der Grundeinstellung versucht Nmap seine Arbeit so schnell wie möglich durchzuführen. Die Abstände zwischen den Prüfpaketen lassen sich aber auf 0,4 s, 15 s oder gar 5 min verlängern. Im Extremfall kann man sich für den kompletten Scan aller Ports eines Rechners rund 500 Jahre Zeit lassen.
Fazit
Auch wenn sich heute viele Systeme hinter intelligenten Netzkomponenten oder in demilitarisierten Zonen befinden und es schwer geworden ist, einen Portscan mit vertrauenswürdigen Ergebnissen in einem akzeptablen Zeitrahmen durchzuführen: Portscanner sind nützliche Werkzeuge und sollten einen festen Platz im IT-Betrieb jeder sicherheitsbewussten Firma haben. Gerade im Mittelstand sind häufig noch Firewall-1-Versionen 4.0, billigere Produkte oder lediglich ACLs im Einsatz, die nicht intelligent mit Portscans umgehen können. Um den Umfang eines Regelwerks beziehungsweise der ACLs gering zu halten, erarbeitet man häufig Konzepte mit sehr wenigen Regeln und Objekten, die aber anfällig für ungewollte Freischaltungen sind.
Nessus, kommerzielle Scanner und die in letzter Zeit hinzugekommenen Internet-Dienstleister (zum Beispiel www.foundscan.com) bieten zudem die Möglichkeit, durch regelmäßige Prüfungen (Differential Scans) die Entwicklung des Sicherheitsniveaus der geprüften (Sub-)Netze zu verfolgen. Schlechte Zeiten für Datenspione und Hostsaboteure brechen aber nicht zwangsläufig an: Die Werkzeuge und Dienstleister produzieren bunte Bilder, die unbestritten einen Informationswert haben. Aber sie bieten leider selten konkrete und vergleichbare Kennzahlen für das Sicherheitsniveau von Systemen, wie sie etwa im Bereich Verfügbarkeit und Service Level Agreements üblich sind. Die Preise kommerzieller Sicherheitsprodukte und -dienstleister sind im Gegensatz dazu überaus handfest.
Jörg Fritsch
ist Mitarbeiter von Tesion Telekommunikation und Autor zahlreicher Fachartikel zum Thema TCP/IP. Im Januar 2003 erscheint sein Buch ‘Firewalls illustriert’.
Webadressen
[1] www.bsi.de/literat/tagung/cebit99/
[3] www.nessus.org
iX-TRACT
- Automatisierte Angriffswerkzeuge lassen sich nicht nur gegen ein Unternehmensnetz, sondern auch zur Qualitätskontrolle der Sicherheitsmaßnahmen einsetzen.
- Das Testen der IT-Infrastruktur mit Methoden böswilliger Angreifer sollte in enger Abstimmung mit Netz- und Serverbetreibern erfolgen.
- Aktuelle kommerzielle Firewalls enthalten in der Regel bereits einen Schutz gegen die üblichen Einbruchsversuche.
(un)
