Scan Technikeneinstein.informatik.uni-oldenburg.de/lehre/semester/rechnernetze/... · Wie FIN Scan,...

48
Scan Techniken Veranstaltung Rechnernetze II

Transcript of Scan Technikeneinstein.informatik.uni-oldenburg.de/lehre/semester/rechnernetze/... · Wie FIN Scan,...

Scan Techniken

Veranstaltung

➸ Rechnernetze II

Ü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 

ICMP Scans

➢ Echo Reply Scan

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.1LOG: Netmask: 255.255.255.255LOG: probing: 127.0.0.1 LOG: [send]­> UDP to 127.0.0.1:32132LOG: [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.1LOG: [68 bytes] sent, waiting for response.TREE: ICMP echo/echo reply are not filteredFINAL:[ 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 

➢ RFC 1700 Zuordnung der Dienste zu den Portnummern(aktuell unter www.iana.org)

➢ Unter UNIX/Linux auch in /etc/services zu finden

➢ Beispiele Dienst PortFTP-Data 20FTP 21Telnet 23HTTP 80X 6000

TCP Verbindungen

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

➢ Schnell

➢ Leicht zu entdecken

➸ TCP Wrapper, IDS, Connection Logger, Paketfilter

➸ Unterscheidet sich vom normalen Verkehr meist durch massives Auftreten (Sweep)

Einfluss von Paketfiltern

TCP SYN Scan (halb offen)

➢ SYN Scan auf offenen Port 

TCP SYN Scan

➢ SYN­ACK Scan

TCP SYN­ACK Scans

➢ Stealthy: Kein formeller  TCP Zustand 

➢ Durchdringung statischer  Paketfilter

➸ Wenn bei ein­ kommenden 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 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 localhostNo exact OS matches for hostTCP/IP fingerprint: 

T1(Resp=Y%DF=Y%W=7FFF%ACK=S++%Flags=AS%Ops=MNNTNW)T2(Resp=N) T3(Resp=Y%DF=Y%W=7FFF%ACK=S++%Flags=AS%Ops=MNNTNW)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 Scans

➢ UDP Scan

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 80get / http/1.0

➢ HTTP/1.1 501 Method Not ImplementedDate: Fri, 30 Apr 2004 13:23:47 GMTServer: Apache/1.3.12 (Unix)  (Red Hat/Linux) PHP/3.0.15 mod_perl/1.21Allow: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, TRACE...<ADDRESS>Apache/1.3.12 Server at websrv.uni­oldenburg.de Port 80</ADDRESS>

Version Queries

Connected to ftp.microsoft.com.220 Microsoft FTP ServiceName (ftp.microsoft.com:busch): ftp331 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> syst215 Windows_NT

IP Protocol Scans

➢ IP Protocol Scans

Koordinierte Scans

➢ Einzelscans bleiben  unterhalb IDS  Erfassungsgrenze

➢ Verteilung kompensiert  Geschwindigkeitsein­buß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

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  False Positives / Negatives akzeptabel für Angriffszwecke

Anwendungsbeispiel

 

NMAP

(The 1595 ports scanned but not shown below are in state: closed)Port State Service22/tcp open ssh111/tcp open sunrpc631/tcp open ipp804/tcp open unknown6000/tcp open X1110000/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?