Scan Techniken Veranstaltung Sicherheit in Rechnernetzen
Überblick Warum Scannen? Scan Techniken ICMP Scans TCP Scans UDP Scans Umgang mit Scans
Warum Scannen? Einbruchszyklus: Informationssammlung Öffentliche Informationen, z. B. Webseiten Passive Verfahren: Sniffing, Traffic Analysis Aktive Verfahren: Scans Einbruch: Exploits Verstecken und Festsetzen: Rootkits, Backdoors,... Mißbrauch: (D)DoS, Warez, Scans, weitere Einbrüche
Ziele von Scans Vorhandene Systeme bestimmen ICMP Scans (ping, hping, X (nicht X11!)) Aktive Dienste bestimmen Portscans: TCP und UDP (nmap) Schwachstellensuche Vulnerability Scans (nessus, ISS, NetRanger)
Einschub ICMP Internet Control Message Protocol RFC 792 (Request for Comments) Mechanismus zur Meldung von Fehlern an andere Hosts im Netz Fehler im ICMP verursachen keine weiteren Fehlermeldungen Bestimmung allgemeiner Charakteristika wie z.b. Überprüfung gültiger Adressmasken oder Round- Trip Zeiten zwischen zwei Rechnern
Beispiele für eigentliche Aufgabe Type 8 und 0 Echo request und reply Type 17 und 18 Adressmaske anfordern und liefern Type 13 und 14 Zeitstempel anfordern und senden Type 4 source quench Zu viele Daten Type 3 destination unreachable
Echo Reply Scan ICMP Scans
Weitere ICMP Scans Information Request: Type 15 / 16 Antwort nur von Konfigurationsserver Request nicht über Subnetz Grenzen Address Mask Request: Type 17 / 18 Antwort nur von Authorative Agent (Router) Request nicht über Subnetz Grenzen
ICMP Broadcast Scan Zieladdresse Broadcast Adresse des Subnetzes Response von allen Hosts im Subnetz Default heute: Keine Weiterleitung von Directed Broadcasts! Bei Erfolg: Kenntnis über Smurf Amplifier
ICMP Host Fingerprinting Methoden: ICMP Response Rate Packete (TCP/UDP) werden an geschlossene Ports gesendet Unreachable Antwortrate is BS-abhängig Datenmenge in ICMP Error Messages Ausführlichkeit der Antwortpakete auch BS-abhängig Änderungen im IP Header Fehlerhafte Header müssen möglichst exakt zurückgemeldet werden, einige BS missachten diese Vorschrift
ICMP Host Fingerprinting Methoden: Fehler im IP Header von ICMP Error Messages Einigie Implementierungen erzeugen fehlerhafte ICMP Antwortpaket, z.b. falsche Prüfsumme TOS Wert in ICMP Unreachable Einige BS setzten Type of Service Feld (TOS) in der ICMP Antwort auf Null, regulär sollte es aber beibehalten werden
ICMP Host Fingerprinting Methoden: Antwort auf ICMP Broadcasts Je nach BS gibt werden Broadcasts von Adress-Mask-, Information- und Timestamp-Request beantwortet oder verworfen Defaults für IP ID, IP TTL Für die Sequenznummern (ID) werden systemabhängig charakteristische Inkremente gewählt Time to live (TTL) enthält je nach BS verschiedene Startwerte (üblich sind 32, 60, 64, 128 und 255)
ICMP Host Fingerprinting Beispiel: xprobe 0.0.2 vs. Linux 2.4.10 host #./xprobe -v -i lo localhost LOG: Target: 127.0.0.1 LOG: Netmask: 255.255.255.255 LOG: probing: 127.0.0.1 LOG: [send]-> UDP to 127.0.0.1:32132 LOG: [98 bytes] sent, waiting for response. TREE: Cisco IOS 11.x-12.x! Extreme Network Switches.Linux 2.0.x!2.2.x!2.4.x. TREE: Linux kernel 2.0.x!2.2.x!2.4.x! Based. TREE: Linux kernel 2.2.x!2.4.x! Based. LOG: [send]-> ICMP echo request to 127.0.0.1 LOG: [68 bytes] sent, waiting for response. TREE: ICMP echo/echo reply are not filtered FINAL:[ Linux 2.2.x/2.4.5+ kernel ]
ICMP Informationen Ein ICMP Scan kann liefern: Ist ein Rechner aktiv bzw. ist die Adresse vergeben Hat der Rechner besondere Aufgaben, z.b. Router Durch Antwort auf eine Adressmasken Anfrage Hinweise auf das Betriebssystem des Zielrechners
Einschub TCP Transmission Control Protocol - RFC 793 Punkt-zu-Punkt Verbindung TCP überträgt Daten zwischen genau zwei Teilnehmern mit symmetrischen Rechten Zuverlässiger Verbindungsauf- und abbau Jede Station kann eigenständig Verbindungen abbauen Kurz nacheinander auf- und wieder abgebaute Verbindungen mit der gleichen Portnummer enthalten keine verfälschten Daten
TCP Kopf
TCP Code Bits URG (Urgent) Dient zur Kennzeichnung besonders dringender Daten Findet in der Praxis heutzutage jedoch keine Anwendung ACK (Acknowledge) Dient der Bestätigung empfangener Daten (meist im Piggyback-Verfahren) PSH (Push) Sender: Daten werden sofort gesendet Anwendung: Interaktionen wie z.b. Telnet
TCP Code Bits RST (Reset) Verbindung wird sofort beendet SYN (Synchronize) Dient dem Verbindungsaufbau FIN (Finish) Antrag auf Verbindungsabbau
TCP Ports Port Adressen Nachdem der Rechner über die IP Adresse zugeordnet wurde, wird ein Dienst auf diesem Rechner über eine 16 Bit Portadresse angesprochen. Konkatenation von IP Adresse und Port Adresse wird als Socket bezeichnet Die Ports sind gruppiert 0-1023 Well-Known Ports 1024-49151 Registered Ports 49152-65535 Dynamic/Private Ports
TCP Verbindungen RFC 1700 Zuordnung der Dienste zu den Portnummern (aktuell unter www.iana.org) Unter UNIX/Linux auch in /etc/services zu finden Beispiele Dienst Port FTP-Data 20 FTP 21 Telnet 23 HTTP 80 X 6000
TCP Connect Scans Connect Scan auf offenen Port Standard Drei-Wege Verfahren
TCP Connect Scans Connect Scan auf geschlossenen Port
TCP Connect Scans Implementierung einfach Std. Calls: socket(), connect(),... Keine Root Rechte Zuverlässig False Negative nur bei Paketfiltern Keine False Positive Leicht zu entdecken TCP Wrapper, IDS, Connection Logger, Paketfilter Unterscheidet sich vom normalen Verkehr meist durch massives Auftreten (Sweep) Schnell
Einfluss von Paketfiltern
TCP SYN Scan (halb offen) SYN Scan auf offenen Port
SYN-ACK Scan TCP SYN Scan
TCP SYN-ACK Scans Stealthy: Kein formeller TCP Zustand Durchdringung statischer Paketfilter Wenn bei einkommenden Paketen nur ACK Flag geprüft wird Mapping von Paketfilter- Regeln über ICMP Destination Unreachable Ergebnis-Invertierung: Anworten nur für geschlossene Ports False Positive bei Paketverlust / Drop False Negative bei RST von Paketfilter Einige OS antworten auch für offene Ports mit RST Z. B. Windows, Cisco,...
TCP FIN, XMAS, Null Scans FIN Scan Wie SYN-ACK Scan, aber nur FIN Flag gesetzt XMAS Scan (Chrismas tree) Wie FIN Scan, aber mit allen Flags gesetzt (mind. FIN, PSH, URG) Null Scan Dto., diesmal aber keine Flags gesetzt Fehlerpotential wie bei SYN-ACK Scans
TCP RST Scans RST Scan Scan mit Paketen bei denen nur RST Flag gesetzt Auf USENIX 99 zur Erklärung von RST/ RST-ACK Backscatter vorgeschlagen Seither kein Tool aufgetaucht Potential nicht größer als FIN oder SYN-ACK Scan Schlechter, da keine Antwort auf RST Pakete
TCP Host Fingerprinting Methoden Antworten von offenen Ports auf FIN Pakete RST Antwort auf RST Paket an geschlossenen Port ECN Unterstützung in TCP TCP Optionen: Reihenfolge, Unterstützung Wert der Acknowledgement Number im ersten Paket Muster bei der Generierung von ISNs Wert der Window Size
TCP Host Fingerprinting host#./nmap -st -vv -O localhost No exact OS matches for host TCP/IP fingerprint: T1(Resp=Y%DF=Y%W=7FFF%ACK=S++%Flags=AS%Ops=MNNT NW) T2(Resp=N) T3(Resp=Y%DF=Y%W=7FFF%ACK=S++%Flags=AS%Ops=MNNT NW) T4(Resp=Y%DF=Y%W=0%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=C0%IPLEN=164%RIPTL=148%RID=E% RIPCK=E%UCK=E%UL EN=134%DAT=E)
UDP Scan UDP Scans
UDP Scans Hohes Potential für False Positive Paketverlust, Drop durch Paketfilter Langsam wegen ICMP Rate Limiting auf Hosts Im Vergleich mit TCP Scans Zu schnell => False Positives wegen nicht versendeter ICMP Destination Unreachable / Port Unreachable
Banner grabbing Netcat 134.106.40.140 80 get / http/1.0 HTTP/1.1 501 Method Not Implemented Date: Fri, 30 Apr 2004 13:23:47 GMT Server: Apache/1.3.12 (Unix) (Red Hat/Linux) PHP/3.0.15 mod_perl/1.21 Allow: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, TRACE... <ADDRESS>Apache/1.3.12 Server at websrv.unioldenburg.de Port 80</ADDRESS>
Version Queries Connected to ftp.microsoft.com. 220 Microsoft FTP Service Name (ftp.microsoft.com:busch): ftp 331 Anonymous access allowed, send identity as password. Password: 230-This is FTP.Microsoft.Com. 230 Anonymous user logged in. Remote system type is Windows_NT. ftp> syst 215 Windows_NT
IP Protocol Scans IP Protocol Scans
Koordinierte Scans Einzelscans bleiben unterhalb IDS Erfassungsgrenze Verteilung kompensiert Geschwindigkeitseinbuße Zusammenführung der Ergebnisse noch manuell
Verteilte Scans Spoofing verschleiert Herkunft Der eigentliche Scan kann bemerkt werden
Scans erkennen Heuristik: N Versuche in Zeitraum T gegen Ziel Z (von Quelle Q) N: Anzahl IP Pakete T: Sekunden, Minuten, Stunden Z, Q: Menge von IP-Adressen, Portnummern Keine präzise Definition möglich Balance zwischen False Positive und False Negative Gruppieren bzgl. Arbeitserleichterung
Automatische Reaktionen Blockieren gescannter Ports, scannender IPAdressen Leicht für Denial-of-Service zu mißbrauchen Zudem leicht vom Angreifer zu erkennen Scan des Scanner Ebenfalls leicht zu mißbrauchen Wozu? Resourcenverbrauch vs. Sicherheitsgewinn?
Warum auf Scans achten? Erfahrung zeigt: Wo Rauch ist, ist auch Feuer Einem Scan folgt häufig ein Angriffsversuch Zunahme von Scans auf bestimmte Dienste gutes Anzeichen für neue Schwachstellen Informationsaustausch notwendig für Warnungen Oftmals Hinweis auf kompromittierte Hosts Die meisten Techniken erfordern root-rechte
Welche Scan-Technik ist die Beste? Zur Qualitätssicherung TCP Connect-Scan, UDP-Scan: Zuverlässig Andere nur zum Test von IDS oder Paketfilter Für Angreifer Gezielt: Stealth: Koordinierte Scans, Verteilte Scans Ungezielt: Beliebige Techniken, häufig Connect-Scan Oft schlechte Implementierungsqualität False Positives / Negatives akzeptabel für deren Zwecke
Anwendungsbeispiel
NMAP (The 1595 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 111/tcp open sunrpc 631/tcp open ipp 804/tcp open unknown 6000/tcp open X11 10000/tcp open snet-sensor-mgmt Nmap run completed -- 1 IP address (1 host up) scanned in 3 seconds
SAINT Konfiguration
Daten Analyse
Ergebnis des Scans
Problembeschreibung
Resümee Allgemeiner Überblick über die Techniken Beachten oder ignorieren Stetige Weiterentwicklung und Ausnutzung neu entdeckter Schwächen Gegenmaßnahmen?