nmap ist exponentiell langsam, wenn mehr Ports gescannt werden

nmap ist exponentiell langsam, wenn mehr Ports gescannt werden

Ich verwende manchmal nmap, um meine Hosts zu überprüfen. Beispiel: nmap -sS -p- example.com
Aber dieser Befehl wird nie abgeschlossen.

Also teile ich den Scan in kleine Teile auf: nmap -sS -p 0-999 example.com(12 Sekunden bis zum Ende)
Und dann nmap -sS -p 1000-1999 example.com(14 Sekunden bis zum Ende) usw. Das ist mühsam.

Bei Verwendung breiterer Teile nmap -sS -p 0-3999 example.com
dauert die Fertigstellung länger als 3 Minuten.

Und damit nmap -sS -p 0-7999 example.comist man nach 30 Minuten noch lange nicht fertig.

Also:
1000 Ports -> 12 Sekunden
4000 Ports -> 3 Minuten
9000 Ports -> 30 Minuten

Was ist das Problem?
Wie kann ich mit nmap offene TCP-Ports für einen Host finden?

Antwort1

Nmap versucht sein Bestes, die Geschwindigkeit zu finden, mit der es den Status (offen, geschlossen oder gefiltert) für jeden Port genau ermitteln kann. Das Zeitsystem ist komplex und es gibt einige Worst-Case-Szenarien, die zu sehr langsamen Scans führen können. Einer dieser Fälle ist, wenn das Ziel die Rate von TCP-Verbindungsresets (RST) begrenzt. Dies sind die Antworten, die Nmap erhält, wenn ein Port geschlossen wird. Die meisten Ports eines Systems sind normalerweise geschlossen, und um Ressourcen zu sparen oder möglicherweise Scan-Versuche zu verhindern, kann das Betriebssystem des Ziels beschließen, nur einmal pro Sekunde ein RST auszugeben.

Wenn Nmap eine RST-Ratenbegrenzung erkennt, muss es seine Tests verlangsamen, um diese Rate zu erreichen. Andernfalls kann ein geschlossener Port als „gefiltert“ markiert werden, da keine Antwort empfangen wurde, was damit übereinstimmt, dass eine Firewall den Verkehr zu diesem Port blockiert. Diese Verlangsamung erfolgt allmählich, sodass die ersten Ports nicht so stark betroffen sind wie die späteren. Außerdem betrifft es nur geschlossene Ports, sodass die häufig verwendeten Ports zwischen 1 und 1000 weniger wahrscheinlich zur Verlangsamung beitragen.

Es gibt eine Problemumgehung für dieses Problem, die jedoch mit einem Genauigkeitsverlust einhergeht. Wenn Sie den Unterschied zwischen gefilterten und geschlossenen Ports nicht kennen möchten, können Sie die --defeat-rst-ratelimitOption verwenden, um zu verhindern, dass ratenbegrenzte RSTs die Zeiteinteilung von Nmap beeinflussen. Nmap sendet weiterhin mit einer für das Netzwerk geeigneten Rate, erkennt verlorene Pakete und verlangsamt die Geschwindigkeit bei Bedarf, kennzeichnet geschlossene Ports jedoch vollkommen problemlos als gefiltert. Die Anzahl der offenen Ports sollte genau gleich sein, und das ist alles, was die meisten Leute wollen. Tatsächlich können Sie sogar hinzufügen, --opendass das Drucken von Informationen über geschlossene und gefilterte Ports ganz vermieden wird.

Antwort2

Sie können die -T5Option hinzufügen, um die Scangeschwindigkeit zu erhöhen.nmap Timing und LeistungEs wird empfohlen, -T4die folgende Option zu verwenden:

Ich würde empfehlen, immer -T4 zu verwenden. Manche Leute mögen -T5, obwohl es für meinen Geschmack zu aggressiv ist. Manche Leute geben -T2 an, weil sie denken, dass es weniger wahrscheinlich ist, dass Hosts abstürzen, oder weil sie sich im Allgemeinen für höflich halten. Sie erkennen oft nicht, wie langsam -T polite wirklich ist. Ihr Scan kann zehnmal länger dauern als ein Standardscan. Computerabstürze und Bandbreitenprobleme sind mit den Standard-Timing-Optionen (-T3) selten, daher empfehle ich diese normalerweise für vorsichtige Scanner. Das Weglassen der Versionserkennung ist weitaus effektiver, als mit Timing-Werten herumzuspielen, um diese Probleme zu reduzieren.

Antwort3

Versuchen Sie, nmap mit -v(verbose) auszuführen, um herauszufinden, warum es zu einer Verlangsamung kommt.

Der Betrieb nmap -sS -Pn -v -p 1-9999 myserver.comauf einem meiner eigenen Server führt irgendwo nach 3000 Ports zu folgendem Ergebnis:

Increasing send delay for (ip address) from 0 to 5 due to max_successful_tryno increase to 4
Increasing send delay for (ip address) from 5 to 10 due to 17 out of 55 dropped probes since last increase.
[...]
Increasing send delay for (ip address) from 160 to 320 due to 11 out of 31 dropped probes since last increase.
SYN Stealth Scan Timing: About 17.08% done; ETC: 13:17 (0:02:30 remaining)

Unterhalb von Port 1024 scheinen diese Nachrichten bei mir nicht zu erscheinen.

verwandte Informationen