Portscanning Grundlagen: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
 
(25 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
=Portscanner=
+
= Allgemein =
*Überprüft welcher Port auf einem System auf eingehende Verbindungen wartet
+
* Beim Portscanning werden die Ports des Ziels auf vorhandene Dienste geprüft.
*Zusatzfunktion der Dienstkennung
+
* Dadurch erhält der Angreifer Informationen über mögliche Angriffspunkte auf dem Zielsystem.
*Zusatzfunktion der Betriebssystemkennung
+
* Portscans dienen der Informationsgewinnung, verbrauchen aber auch Systemressourcen.
*TCP Scan oft über den 3 Way Handshake
+
* Portscanning gilt trotz dieser wichtigen Funktion als klassischer '''D'''enial '''o'''f '''S'''ervice Angriff.
 +
* Sie sind damit ein weiterer DoS-Angriff, wenn auch weniger effizient als andere Formen.
 +
* Portscans gehen häufig tatsächlichen Angriffen voraus.
 +
* Portscans beschränken sich oft auf wenige, ausgesuchte Zielports, auf denen verbreitete Netzwerkdienste laufen.
 +
* Diese Dienste hatten in der Vergangenheit oft Schwachstellen und sind ein idealer Ausgangspunkt für Angriffe.
 +
* Eine hohe Anzahl gleichzeitiger Scans kann den Zielrechner blockieren.
  
=Methoden=
+
= Portscanner =
==TCP-connect()-Scan==
+
* Überprüfen, welcher Port auf einem System auf eingehende Verbindungen wartet.
*Vollständiger 3 Way Handshake
+
* Zusatzfunktion der Dienstkennung:
*Sehr einfach zu programmieren
+
** Welcher Dienst läuft hier?
 +
** Um welches Produkt handelt es sich?
 +
** Welche Version wird eingesetzt?
 +
* Zusatzfunktion der Betriebssystemerkennung.
 +
* TCP-Scan oft über den 3-Way-Handshake.
  
==TCP-SYNScan==
+
= Port-Zustände =
*SYN Packet wird gesendet
 
*SYN/ACK wird vom gescannten Rechner angenommen
 
*Somit gilt der Port als offen
 
*RST wird zum Opfer geschickt
 
==TCP-FIN==
 
*Es wird ein FIN Paket gesendet
 
*Keine Antwort - open|filtered
 
*TCP RST packet - closed
 
*ICMP unreachable error (type 3, code 1, 2, 3, 9, 10, or 13) - filtered
 
  
==Xmas==
+
== offen ==
*Es wird ein FIN,URG,PUSH Paket gesendet
+
* Ein Programm ist bereit, TCP-Verbindungen oder UDP-Pakete auf diesem Port anzunehmen.
*Keine Antwort - open|filtered
 
*TCP RST packet - closed
 
*ICMP unreachable error (type 3, code 1, 2, 3, 9, 10, or 13) - filtered
 
==Null-Scan==
 
*Es wird ein Paket ohne Flags gesendet
 
*Keine Antwort - open|filtered
 
*TCP RST packet - closed
 
*ICMP unreachable error (type 3, code 1, 2, 3, 9, 10, or 13) - filtered
 
==UDP Scan==
 
*sehr unzuverlässig
 
*Keine UDP Antwort - open
 
*Keine UDP Antwort (even after retransmissions) - open|filtered
 
*ICMP port unreachable error (type 3, code 3) - closed
 
*Other ICMP unreachable errors (type 3, code 1, 2, 9, 10, or 13) - filtered
 
=Rechtliche Aspekte=
 
Die Legalität von Portscans ist umstritten, da sie als erste Instanz eines Eindringversuches gewertet werden können. In jedem Fall ist eine Benutzung auf eigenen Systemen legal. Unklarer ist die Rechtslage bei Portscans gegen fremde Systeme und Netzwerke. Da beispielsweise empfindliche Computer durch viele Verbindungsanfragen gestört werden können, kann dies als Angriff auf die Verfügbarkeit eines Systems gewertet und in Deutschland durch § 303b StGB Computersabotage bestraft werden. Das SANS-Institut bestätigt in einer Veröffentlichung ebenfalls den Zwiespalt von Portscans.
 
  
Portscanner werden jedoch aktuell nicht als Computerprogramm zum Ausspähen von Daten nach § 202c StGB (Hackerparagraf) angesehen, da sie keine Sicherheitsmechanismen umgehen oder Daten abfangen können, werden jedoch je nach Fall als Vorbereitung eines Angriffs angesehen und juristisch entsprechend behandelt.
+
== geschlossen ==
 +
* Ein geschlossener Port ist erreichbar (empfängt und antwortet), aber es gibt kein Programm, das ihn abhört.
 +
* Er kann genutzt werden, um zu zeigen, dass ein Host online ist und eine IP-Adresse benutzt wird.
  
=Quellen=
+
== gefiltert ==
*https://nmap.org/book/
+
* Es kann nicht festgestellt werden, ob der Port offen ist.
*https://de.wikipedia.org/wiki/Portscanner
+
* Paketfilterung verhindert, dass Testpakete den Port erreichen.
 +
* Die Filterung könnte durch Firewalls oder Router-Regeln erfolgen.
 +
 
 +
== ungefiltert ==
 +
* Der Port ist zugänglich, aber es kann nicht festgestellt werden, ob er offen oder geschlossen ist.
 +
 
 +
== offen|gefiltert ==
 +
* Klassifizierung, wenn nicht festgestellt werden kann, ob der Port offen oder gefiltert ist.
 +
* Tritt bei Scans auf, bei denen offene Ports keine Antwort geben (z. B. FIN-, Xmas-, Null-Scan).
 +
 
 +
== geschlossen|gefiltert ==
 +
* Der Zustand zeigt an, dass nicht festgestellt werden kann, ob ein Port geschlossen oder gefiltert ist.
 +
 
 +
= Methoden =
 +
* Hier werden verschiedene Techniken des Portscannings vorgestellt, basierend auf TCP- oder UDP-Verhalten.
 +
 
 +
== TCP-connect()-Scan ==
 +
* Vollständiger 3-Way-Handshake.
 +
* Sehr einfach zu programmieren.
 +
{{#drawio:tcp-connect}}
 +
 
 +
== TCP-SYN-Scan ==
 +
* SYN-Paket wird gesendet.
 +
* SYN/ACK wird vom gescannten Rechner zurückgeschickt → Port offen.
 +
* Danach wird RST gesendet, um die Verbindung zu beenden.
 +
{{#drawio:tcp-syn-scan}}
 +
 
 +
== TCP-FIN-Scan ==
 +
* FIN-Paket wird gesendet.
 +
* Keine Antwort → Port offen oder gefiltert (open|filtered).
 +
* RST-Paket → Port geschlossen.
 +
* ICMP-Unreachable-Fehler (Typ 3, Code 1, 2, 3, 9, 10 oder 13) → gefiltert.
 +
;Anmerkung:
 +
Laut RFC 793 antwortet ein offener Port auf ein FIN-Paket nicht.
 +
Geschlossene Ports senden RST. Firewalls können das Verhalten beeinflussen.
 +
{{#drawio:tcp-fin}}
 +
 
 +
== Xmas-Scan ==
 +
* Paket mit gesetzten FIN-, URG- und PSH-Flags wird gesendet ("leuchtet" wie ein Weihnachtsbaum).
 +
* Keine Antwort → Port offen oder gefiltert (open|filtered).
 +
* RST-Paket → Port geschlossen.
 +
* ICMP-Unreachable-Fehler → gefiltert.
 +
;Anmerkung:
 +
Verhalten gemäß RFC 793, aber viele Systeme (z. B. Windows) antworten abweichend.
 +
{{#drawio:tcp-xmas}}
 +
 
 +
== Null-Scan ==
 +
* Paket ohne gesetzte Flags wird gesendet.
 +
* Keine Antwort → Port offen oder gefiltert (open|filtered).
 +
* RST-Paket → Port geschlossen.
 +
* ICMP-Unreachable-Fehler → gefiltert.
 +
;Anmerkung:
 +
Verhalten wie beim FIN- und Xmas-Scan. Firewalls können Pakete blockieren und falsche Ergebnisse erzeugen.
 +
{{#drawio:tcp-null}}
 +
 
 +
== Idle Scan ==
 +
* Der Idle Scan nutzt die Vorhersagbarkeit der IP-ID-Feld-Inkremente eines Zombie-Hosts aus.
 +
* Der Angreifer selbst kommuniziert nie direkt mit dem Zielsystem.
 +
* Der Zombie sendet unbeabsichtigt die Reaktionen auf Anfragen, wodurch der Scan verdeckt bleibt.
 +
* Zielhost sieht ausschließlich Verbindungen vom Zombie, nicht vom Angreifer.
 +
* Ideal bei Firewalls oder wenn Anonymität wichtig ist.
 +
* Funktioniert nur, wenn der Zombie eine globale, sequentielle IP-ID verwendet und wenig andere Aktivitäten hat.
 +
 
 +
;Funktionsweise:
 +
* Angreifer sendet ein leeres Paket an den Zombie und liest die aktuelle IP-ID.
 +
* Angreifer sendet ein SYN-Paket an das Ziel, mit gefälschter Absenderadresse des Zombies.
 +
* Ziel antwortet:
 +
** Bei offenem Port: SYN/ACK wird an Zombie gesendet → Zombie antwortet mit RST → IP-ID wird erhöht.
 +
** Bei geschlossenem Port: Ziel sendet RST → Zombie muss nicht antworten → IP-ID bleibt gleich.
 +
* Angreifer liest erneut die IP-ID des Zombies und vergleicht:
 +
** Erhöhte IP-ID → Port offen.
 +
** Unveränderte IP-ID → Port geschlossen.
 +
 
 +
;Anforderungen:
 +
* Zombie muss IP-IDs sequentiell erhöhen.
 +
* Zombie sollte wenig eigener Verkehr haben (sonst verfälschte Ergebnisse).
 +
* Zielsystem muss auf SYN-Pakete erwartungsgemäß antworten (kein SYN-Proxy etc.).
 +
 
 +
<pre>
 +
+----------------+          +--------------+        +--------------+
 +
|    Angreifer  |          |  Zombie-Host |        |  Zielsystem  |
 +
+----------------+          +--------------+        +--------------+
 +
        |                        |                          |
 +
        | 1. IP-ID lesen          |                          |
 +
        +------------------------->                          |
 +
        |                        |                          |
 +
        |                        |                          |
 +
        |                        | 2. Angreifer sendet spoofed SYN |
 +
        |                        +--------------------------> |
 +
        |                        |                          |
 +
        |                        | 3. Ziel antwortet SYN/ACK oder RST |
 +
        |                        | <--------------------------+
 +
        |                        |                          |
 +
        | 4. IP-ID erneut lesen    |                          |
 +
        +------------------------->                          |
 +
        |                        |                          |
 +
        | Analyse:                |                          |
 +
        | - IP-ID unverändert: Port geschlossen (kein Paket empfangen) |
 +
        | - IP-ID erhöht: Port offen (Zombie antwortete auf SYN/ACK)  |
 +
        |                        |                          |
 +
</pre>
 +
 
 +
 
 +
{{#drawio:idle-scan}}
 +
 
 +
== UDP-Scan ==
 +
* Sendet UDP-Pakete an Zielports.
 +
* Keine Antwort → Port könnte offen sein.
 +
* Keine Antwort nach Wiederholungen → open|filtered.
 +
* ICMP Port Unreachable (Typ 3, Code 3) → Port geschlossen.
 +
* Andere ICMP-Fehler (Typ 3, Codes 1, 2, 9, 10 oder 13) → gefiltert.
 +
;Anmerkung:
 +
UDP-Scans sind sehr unzuverlässig. Paketverluste und Firewallfilter können zu Fehleinschätzungen führen.
 +
{{#drawio:udp-scan}}
 +
 
 +
= Rechtliche Aspekte =
 +
* Die Legalität von Portscans ist umstritten.
 +
* Sie könnten als Eindringversuch gewertet werden.
 +
* Auf eigenen Systemen sind sie uneingeschränkt legal.
 +
* Portscans auf fremden Systemen können problematisch sein.
 +
* Viele Verbindungsversuche könnten als Angriff auf die Verfügbarkeit eines Systems interpretiert werden.
 +
* In Deutschland können Portscans nach § 303b StGB (Computersabotage) strafbar sein.
 +
* Das SANS-Institut sieht die rechtliche Bewertung von Portscans als zwiespältig an.
 +
* Portscanner gelten derzeit nicht als Werkzeuge zum Ausspähen von Daten gemäß § 202c StGB (Hackerparagraf).
 +
* Sie umgehen keine Sicherheitsmechanismen und fangen keine Daten ab.
 +
* Portscans könnten jedoch als Vorbereitungshandlungen für einen Angriff juristisch relevant sein.
 +
 
 +
= Quellen =
 +
* https://nmap.org/book/
 +
* https://de.wikipedia.org/wiki/Portscanner
 +
* https://datenschutz-am-bodensee.com/ist-die-nutzung-eines-port-scans-strafbar/
 +
* https://www.bundestag.de/resource/blob/1005444/ed435cb1a5311bb688385a81f295c8a3/WD-7-104-23-pdf.pdf

Aktuelle Version vom 26. April 2025, 07:49 Uhr

Allgemein

  • Beim Portscanning werden die Ports des Ziels auf vorhandene Dienste geprüft.
  • Dadurch erhält der Angreifer Informationen über mögliche Angriffspunkte auf dem Zielsystem.
  • Portscans dienen der Informationsgewinnung, verbrauchen aber auch Systemressourcen.
  • Portscanning gilt trotz dieser wichtigen Funktion als klassischer Denial of Service Angriff.
  • Sie sind damit ein weiterer DoS-Angriff, wenn auch weniger effizient als andere Formen.
  • Portscans gehen häufig tatsächlichen Angriffen voraus.
  • Portscans beschränken sich oft auf wenige, ausgesuchte Zielports, auf denen verbreitete Netzwerkdienste laufen.
  • Diese Dienste hatten in der Vergangenheit oft Schwachstellen und sind ein idealer Ausgangspunkt für Angriffe.
  • Eine hohe Anzahl gleichzeitiger Scans kann den Zielrechner blockieren.

Portscanner

  • Überprüfen, welcher Port auf einem System auf eingehende Verbindungen wartet.
  • Zusatzfunktion der Dienstkennung:
    • Welcher Dienst läuft hier?
    • Um welches Produkt handelt es sich?
    • Welche Version wird eingesetzt?
  • Zusatzfunktion der Betriebssystemerkennung.
  • TCP-Scan oft über den 3-Way-Handshake.

Port-Zustände

offen

  • Ein Programm ist bereit, TCP-Verbindungen oder UDP-Pakete auf diesem Port anzunehmen.

geschlossen

  • Ein geschlossener Port ist erreichbar (empfängt und antwortet), aber es gibt kein Programm, das ihn abhört.
  • Er kann genutzt werden, um zu zeigen, dass ein Host online ist und eine IP-Adresse benutzt wird.

gefiltert

  • Es kann nicht festgestellt werden, ob der Port offen ist.
  • Paketfilterung verhindert, dass Testpakete den Port erreichen.
  • Die Filterung könnte durch Firewalls oder Router-Regeln erfolgen.

ungefiltert

  • Der Port ist zugänglich, aber es kann nicht festgestellt werden, ob er offen oder geschlossen ist.

offen|gefiltert

  • Klassifizierung, wenn nicht festgestellt werden kann, ob der Port offen oder gefiltert ist.
  • Tritt bei Scans auf, bei denen offene Ports keine Antwort geben (z. B. FIN-, Xmas-, Null-Scan).

geschlossen|gefiltert

  • Der Zustand zeigt an, dass nicht festgestellt werden kann, ob ein Port geschlossen oder gefiltert ist.

Methoden

  • Hier werden verschiedene Techniken des Portscannings vorgestellt, basierend auf TCP- oder UDP-Verhalten.

TCP-connect()-Scan

  • Vollständiger 3-Way-Handshake.
  • Sehr einfach zu programmieren.

TCP-SYN-Scan

  • SYN-Paket wird gesendet.
  • SYN/ACK wird vom gescannten Rechner zurückgeschickt → Port offen.
  • Danach wird RST gesendet, um die Verbindung zu beenden.

TCP-FIN-Scan

  • FIN-Paket wird gesendet.
  • Keine Antwort → Port offen oder gefiltert (open|filtered).
  • RST-Paket → Port geschlossen.
  • ICMP-Unreachable-Fehler (Typ 3, Code 1, 2, 3, 9, 10 oder 13) → gefiltert.
Anmerkung
Laut RFC 793 antwortet ein offener Port auf ein FIN-Paket nicht. 
Geschlossene Ports senden RST. Firewalls können das Verhalten beeinflussen.

Xmas-Scan

  • Paket mit gesetzten FIN-, URG- und PSH-Flags wird gesendet ("leuchtet" wie ein Weihnachtsbaum).
  • Keine Antwort → Port offen oder gefiltert (open|filtered).
  • RST-Paket → Port geschlossen.
  • ICMP-Unreachable-Fehler → gefiltert.
Anmerkung
Verhalten gemäß RFC 793, aber viele Systeme (z. B. Windows) antworten abweichend.

Null-Scan

  • Paket ohne gesetzte Flags wird gesendet.
  • Keine Antwort → Port offen oder gefiltert (open|filtered).
  • RST-Paket → Port geschlossen.
  • ICMP-Unreachable-Fehler → gefiltert.
Anmerkung
Verhalten wie beim FIN- und Xmas-Scan. Firewalls können Pakete blockieren und falsche Ergebnisse erzeugen.

Idle Scan

  • Der Idle Scan nutzt die Vorhersagbarkeit der IP-ID-Feld-Inkremente eines Zombie-Hosts aus.
  • Der Angreifer selbst kommuniziert nie direkt mit dem Zielsystem.
  • Der Zombie sendet unbeabsichtigt die Reaktionen auf Anfragen, wodurch der Scan verdeckt bleibt.
  • Zielhost sieht ausschließlich Verbindungen vom Zombie, nicht vom Angreifer.
  • Ideal bei Firewalls oder wenn Anonymität wichtig ist.
  • Funktioniert nur, wenn der Zombie eine globale, sequentielle IP-ID verwendet und wenig andere Aktivitäten hat.
Funktionsweise
  • Angreifer sendet ein leeres Paket an den Zombie und liest die aktuelle IP-ID.
  • Angreifer sendet ein SYN-Paket an das Ziel, mit gefälschter Absenderadresse des Zombies.
  • Ziel antwortet:
    • Bei offenem Port: SYN/ACK wird an Zombie gesendet → Zombie antwortet mit RST → IP-ID wird erhöht.
    • Bei geschlossenem Port: Ziel sendet RST → Zombie muss nicht antworten → IP-ID bleibt gleich.
  • Angreifer liest erneut die IP-ID des Zombies und vergleicht:
    • Erhöhte IP-ID → Port offen.
    • Unveränderte IP-ID → Port geschlossen.
Anforderungen
  • Zombie muss IP-IDs sequentiell erhöhen.
  • Zombie sollte wenig eigener Verkehr haben (sonst verfälschte Ergebnisse).
  • Zielsystem muss auf SYN-Pakete erwartungsgemäß antworten (kein SYN-Proxy etc.).
+----------------+          +--------------+         +--------------+
|    Angreifer   |          |   Zombie-Host |         |   Zielsystem  |
+----------------+          +--------------+         +--------------+
        |                         |                           |
        | 1. IP-ID lesen           |                           |
        +------------------------->                           |
        |                         |                           |
        |                         |                           |
        |                         | 2. Angreifer sendet spoofed SYN |
        |                         +--------------------------> |
        |                         |                           |
        |                         | 3. Ziel antwortet SYN/ACK oder RST |
        |                         | <--------------------------+
        |                         |                           |
        | 4. IP-ID erneut lesen    |                           |
        +------------------------->                           |
        |                         |                           |
        | Analyse:                |                           |
        | - IP-ID unverändert: Port geschlossen (kein Paket empfangen) |
        | - IP-ID erhöht: Port offen (Zombie antwortete auf SYN/ACK)   |
        |                         |                           |


idle-scan
empty app.diagrams.net chart

UDP-Scan

  • Sendet UDP-Pakete an Zielports.
  • Keine Antwort → Port könnte offen sein.
  • Keine Antwort nach Wiederholungen → open|filtered.
  • ICMP Port Unreachable (Typ 3, Code 3) → Port geschlossen.
  • Andere ICMP-Fehler (Typ 3, Codes 1, 2, 9, 10 oder 13) → gefiltert.
Anmerkung
UDP-Scans sind sehr unzuverlässig. Paketverluste und Firewallfilter können zu Fehleinschätzungen führen.

Rechtliche Aspekte

  • Die Legalität von Portscans ist umstritten.
  • Sie könnten als Eindringversuch gewertet werden.
  • Auf eigenen Systemen sind sie uneingeschränkt legal.
  • Portscans auf fremden Systemen können problematisch sein.
  • Viele Verbindungsversuche könnten als Angriff auf die Verfügbarkeit eines Systems interpretiert werden.
  • In Deutschland können Portscans nach § 303b StGB (Computersabotage) strafbar sein.
  • Das SANS-Institut sieht die rechtliche Bewertung von Portscans als zwiespältig an.
  • Portscanner gelten derzeit nicht als Werkzeuge zum Ausspähen von Daten gemäß § 202c StGB (Hackerparagraf).
  • Sie umgehen keine Sicherheitsmechanismen und fangen keine Daten ab.
  • Portscans könnten jedoch als Vorbereitungshandlungen für einen Angriff juristisch relevant sein.

Quellen