Beispielhack:

Hack #40 Blocken Sie OS-Fingerprinting

Halten Sie, was Ihre Betriebssysteme betrifft, Außenstehende auf einer Basis, auf der sie nur das wissen, was sie wissen müssen.

Wenn Netzwerk-Reconnaissance (Netzwerk-Aufklärung) durchgeführt wird, ist für die angehenden Angreifer das Betriebssystem, das auf den Systemen läuft, die ihre Scans entdeckt haben, ein sehr wertvoller Teil an Information. Aus Sicht des Angreifers ist das sehr hilfreich, um herauszufinden, welche verwundbaren Schwachstellen das System besitzen könnte oder welche Exploits auf einem System funktionieren könnten. Kombiniert mit dem Wissen über offene Ports, die während eines Port-Scans entdeckt wurden, kann diese Information verheerend sein. Schließlich ist es nicht sehr wahrscheinlich, dass ein RPC-Exploit für SPARC-Solaris auch für x86-Linux funktioniert - der Code für den portmap-Daemon ist auf beiden Systemen verschieden und sie besitzen unterschiedliche Prozessor-Architekturen. Bewaffnet mit dem Wissen über eine bestimmte Server-Plattform, können Angreifer diejenigen Techniken sehr wirksam ausprobieren, die ihnen am wahrscheinlichsten erweiterten Zugriff gewähren, ohne dabei Zeit mit Exploits zu verschwenden, die nicht funktionieren können.

Üblicherweise würden Individuen, die Netzwerk-Reconnaissance ausführen, sich einfach mit jedem Dienst verbinden, der von ihrem Port-Scan entdeckt wurde, um zu sehen, welches Betriebssystem auf dem entfernten System läuft. Das funktioniert, da viele Daemons, wie zum Beispiel Sendmail, Telnet und sogar FTP, bereitwillig das zugrunde liegende Betriebssystem und sogar ihre eigene Versionsnummer bekannt geben. Selbst wenn diese Methode einfach und unkompliziert ist, wird sie jetzt doch als lästig angesehen, weil es einfach ist, jemanden, der sich gerade verbindet, in den System-Protokolldateien zu entdecken. Zusätzlich können die meisten Dienste so konfiguriert werden, dass sie diese sensiblen Informationen nicht bekannt geben. Daraufhin wurden raffiniertere Methoden entwickelt, die keine vollständige Verbindung auf das Zielsystem benötigen, um festzustellen, welches Betriebssystem dort läuft. Diese Methoden verlassen sich auf die Verschrobenheiten des TCP/IP-Stacks der Host-Betriebssysteme und deren Verhalten, wenn sie auf bestimmte Arten von Paketen antworten. Da verschiedene Betriebssysteme auf diese Pakete auf eine bestimmte Art und Weise antworten, ist es möglich, basierend darauf, wie sie auf Sondierungspakete antworten, die normalerweise nicht in Protokolldateien angezeigt werden, eine gute Vermutung darüber anzustellen, welches Betriebssystem auf einem bestimmten Server läuft. Glücklicherweise können solche Sondierungspakete an der Firewall abgeblockt werden, um alle Versuche zu vereiteln, die Methoden wie diese zur Betriebssystemerkennung einsetzen.

Ein häufig benutztes Werkzeug, das solche Methoden zur Betriebssystemerkennung einsetzt, ist Nmap (http://www.insecure.org/nmap/), das es Ihnen nicht nur ermöglicht, das Betriebssystem zu ermitteln, das auf einem entfernten System läuft, sondern auch verschiedene Arten von Port-Scans durchführt.

Der Versuch, ein Betriebssystem mit Nmap festzustellen, ist so einfach wie desssen Ausführung mit dem Schalter -O. Hier sind die Ergebnisse des Scans eines OpenBSD 3.3-Systems:

# nmap -O puffy


Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-12-02 19:14 MST
Interesting ports on puffy (192.168.0.42):
(The 1653 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
13/tcp  open  daytime
22/tcp  open  ssh
37/tcp  open  time
113/tcp open  auth
Device type: general purpose
Running: OpenBSD 3.X
OS details: OpenBSD 3.0 or 3.3

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

Um die Bemühungen von Nmap zu durchkreuzen, können wir Firewall-Regeln einsetzen, die Pakete blocken, die für Betriebssystem-Untersuchungen verwendet werden. Diese sind ziemlich einfach auszumachen, da mehrere von ihnen ungültige Kombinationen von TCP-Flags besitzen. Einige der Tests, die Nmap durchführt, können nicht von PF geblockt werden, indem man einfach block-Regeln hinzufügt, sie können aber geblockt werden, wenn eine zustandsbezogene Filterung und eine Deny-Standardrichtlinie im Regelsatz implementiert wurden. Das liegt daran, dass einige der Tests Gebrauch von TCP-Optionen machen, die nicht von PF gefiltert werden können.

Um diese Fingerprinting-Versuche mit PF von OpenBSD zu blocken, können wir Regeln in unsere /etc/pf.conf stellen, die diesen hier ähnlich sind:

set block-policy  return
 

block in log quick proto tcp flags FUP/WEUAPRSF
block in log quick proto tcp flags WEUAPRSF/WEUAPRSF
block in log quick proto tcp flags SRAFU/WEUAPRSF
block in log quick proto tcp flags /WEUAPRSF
block in log quick proto tcp flags SR/SR
block in log quick proto tcp flags SF/SF
 

Dies hat auch den Nebeneffekt, dass alle Versuche auf das pflog0-Interface protokolliert werden. Selbst wenn wir nicht alle Tests von Nmap blocken können, so können wir doch zumindest einige der eindeutigeren Versuche blocken und Nmap möglicherweise dadurch verwirren, dass wir ein unvollständiges Bild über das Verhalten des TCP-Stacks unseres Betriebssystems liefern. Pakete, die diese Regeln ausgelöst haben, können mit tcpdump betrachtet werden, indem die folgenden Befehle ausgeführt werden:

# ifconfig pflog0 up
 
# tcpdump -n -i pflog0 
 

Lassen Sie uns jetzt einen Blick auf die Ergebnisse eines Nmap-Scans werfen, nachdem wir diese Regeln aktiviert haben:

# nmap -O puffy 
 

Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-12-02 22:56 MST
Interesting ports on puffy (192.168.0.42):
(The 1653 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
13/tcp  open  daytime
22/tcp  open  ssh
37/tcp  open  time
113/tcp open  auth
No exact OS matches for host (If you know what OS is running on it, 
see http://www.insecure.org/cgi-bin/nmap-submit.cgi).
TCP/IP fingerprint:
SInfo(V=3.48%P=i686-pc-linux-gnu%D=12/2%Time=3FCD7B3F%O=13%C=1)
TSeq(Class=TR%IPID=RD%TS=2HZ)
T1(Resp=Y%DF=Y%W=403D%ACK=S++%Flags=AS%Ops=MNWNNT)
T2(Resp=Y%DF=Y%W=0%ACK=S%Flags=AR%Ops=)
T3(Resp=Y%DF=Y%W=0%ACK=O%Flags=AR%Ops=)
T4(Resp=Y%DF=Y%W=4000%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=134%RID=E%RIPCK=F%UCK=E%UL
EN=134%DAT=E)
 

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

Wie Sie sehen können, war der Versuch diesmal nicht erfolgreich. Wenn Sie sich aber besonders gerissen vorkommen, dann könnte die einfache Verwirrung der Nmap-Versuche nicht genug sein. Was wäre, wenn Sie Angreifer tatsächlich glauben machen möchten, ein Server würde ein komplett anderes Betriebssystem betreiben? Dies könnte zum Beispiel nützlich sein, wenn Sie einen Honeypot [Hack #94] einrichten, um Schurken von Ihren wichtigen Servern abzulenken. Wenn das für Sie nach Spaß klingt, dann lesen Sie weiter.

O'Reilly Home | O'Reilly Partnerbuchhandlungen | Bestellinformationen
Kontakt | Über O'Reilly | Datenschutz

© 2004, O'Reilly Verlag GmbH & Co.KG
webmaster@oreilly.de