ubuntuusers.de

Ganz abgesehen davon das Lunar recht hat ist nmap so ziemlich der lamste Portscanner den es gibt, wenn es nur darum geht festzustellen ob ein Port offen ist.

Außerdem würde mich wirklich interessieren wieso du auf 10.000 Hosts per SSH zugreifen kannst/willst? Ich kenne einige große Netze aber ich kenne keins bei dem eine Person Zugriff auf eine so große Zahl Hosts hätte. Der Hintergrund interessiert mich wirklich.

Hmm naja vllt kann man ja bei nmap -T insane mit ranhängen

aber ich weiß nicht ob das so viel bringt ,da es sich ja summiert bei 10000rechnern.

Aber ist schon ne obskure zahl soviel pc's und 1 mensch....

Warte, ich werde heute noch mal antworten. Ich muss leider weg =(

Ghaldez hat geschrieben:

Hmm naja vllt kann man ja bei nmap -T insane mit ranhängen

Wenn du ein nur einen einzige Portscan durchführst, ist diese Option absolut sinnlos, da nmap eh nur eine Verbindung aufbaut. Das grundsätzliche Problem ist eher, dass namp ohne Root-Recht nur einen TCP-Connect-Scan durchführen kann, der im Verhältnis extrem teuer ist. Eine schneller Alternative wären SYN-Scans, wofür nmap allerdings mit Root-Rechten laufen muss. Auch wird jedes IDS bei SYN-Scans Alarm schlagen.

Ghaldez hat geschrieben:

aber ich weiß nicht ob das so viel bringt ,da es sich ja summiert bei 10000rechnern.

Es würde etwas bringen, wenn man nmap nicht für jeden Host einzeln aufruft, sondern alle Hosts geschlossen an nmap übergibst. Dann allerdings sorgt die Option unter Garantie dafür, dass das Netzwerk überlastet wird. Selbst bei GBit-LAN erzeugt ein moderner Prozessor immer noch schneller Pakete, als die Karte sie verschicken kann.

nmap regelt die Sendeleistungs automatisch runter, wenn es merkt das es das Netzwerk verstopft. Die Algorithmen dazu sind aber wohl nicht so optimal und verlangsamen das ganze mehr als nötig.

Blattlaus hat geschrieben:

nmap regelt die Sendeleistungs automatisch runter, wenn es merkt das es das Netzwerk verstopft.

Was bleibt ihm auch anderes übrig 😉

Im Übrigen ist nmap nicht per se lahm. Jeder Scanner ohne erweiterte Privilegien ist lahm, weil er keine Raw-Sockets nutzen, sondern nur über den connect System-Call den vollen TCP-Handshake einleiten kann. Mit Root-Privilegien kann auch nmap sehr schnelle Scan-Techniken nutzen. Schon ein einfacher SYN-Scan wird wohl deutlich schneller sein als ein TCP-Connect-Scan.

Blattlaus hat geschrieben:

Die Algorithmen dazu sind aber wohl nicht so optimal und verlangsamen das ganze mehr als nötig.

Hast du dafür Quellen?

http://events.ccc.de/congress/2007/Fahrplan/events/2131.en.html

Blattlaus hat geschrieben:

http://events.ccc.de/congress/2007/Fahrplan/events/2131.en.html

http://www.computerdefense.org/2008/01/13/port-scanner-challenge-nmap-unicornscan-portbunny/ ← Die Statistik scheint den portbunny-Devs nicht unbedingt recht zu geben 😉

Den Vortrag der portbunny Entwickler sehe ich nicht wirklich als Quelle, die wollen auch nur ihr Projekt vermarkten 😉 Im Linux Magazin 05/08 gab es dazu auch zwei interessante Interviews mit den Entwicklern von portbunny und dem NMap-Entwickler, aus dem ich mehr oder weniger den Schluss gezogen habe, dass die Zeitvorteile bei portbunny eher akademischer Natur sind 😉

Hi Blatthaus,

Naja, mit 10.000 ist ja vielleicht übertrieben =P

Ich untersuche momentan ein Server-Client-Architechtur (Reliable Server Pooling, Siehe: http://tdrwww.iem.uni-due.de/dreibholz/rserpool/). Um es zu realisieren, soll PlanetLab (http://www.planet-lab.org/) genutzt werden. Planetlab bietet mehr als 850 virtuelle Maschine, die auf der ganzen Welt veteilt sind.

Die virtuelle Maschine in PlanetLab kann nur durch ssh oder scp zugegriffen werden.

Zuerst muss ich erst die Implementerung an die gewünschten Maschine übertragen. Jedes Mal, wenn ich die Implementierung geändert habe,muss ich die wieder an die VM übertragen.

Danach muss ich sowohl Server starten und Client (beide durch SSH). Die Log-Dateien, die aus Server und Client erzeugt sind, mussen auch an den lokelen Rechner zurück übertragt werden.

Das gilt nur für eine Messung. Aber ich messe anhands autmatische Skript mehrmals (mehr als 100 bestimmt, damit die Statistiken aussagekräftig sind).

Deshalb habe ich überlegt, wenn ich jetzt vom vorne schon weiß, dass die VM nicht aktiv sind, brauche ich dann überhaupt nicht zu versuchen, eine SSH-Verbindung aufzubauen.

edwin7 hat geschrieben:

Deshalb habe ich überlegt, wenn ich jetzt vom vorne schon weiß, dass die VM nicht aktiv sind, brauche ich dann überhaupt nicht zu versuchen, eine SSH-Verbindung aufzubauen.

Wenn du etwas mehr überlegt hättest, wäre dir aufgefallen, dass die ganze Aktion reichlich unsinnig ist. 🙄

nmap versucht, eine Verbindung zum Port 22 aufzubauen. Antwortet der Server mit ACK, sendet nmap sofort ein RST-Paket, um die eben aufgebaute Verbindung wieder zu schließen. Antwortet der Server dagegen mit RST, meldet nmap, dass der Port nicht offen ist.

Später versucht SSH dann erneut, eine Verbindung zum Port 22 aufzubauen. Antwortet der Server diesmal mit ACK, startet SSH die Protokollverhandlung und anschließend die Authentifizierung. Antwortet der Server dagegen mit RST, meldet SSH, dass der Port nicht offen ist.

Ich hoffe, dir fällt auf, dass du hier sinnloserweise doppelte Arbeit verrichtest...

Tut mir Leid, aber meine Frage bezieht sich nicht nur auf nmap.

edwin7 hat geschrieben:

Tut mir Leid, aber meine Frage bezieht sich nicht nur auf nmap.

Dann ersetze nmap durch einen beliebigen anderen Portscanner, das macht keinen Unterschied. Jeder Port-Scanner, der keine erweiterten Rechte besitzt, kann nur normale TCP-Connect-Scans durchführen, da für alles andere Raw-Sockets nötig wären, die unter Linux Root vorbehalten sind.

Zumal es auch keine Rolle spielt ob root oder nicht root. Mindestens 2 Pakete sind immer nötig und wenn man ohnehin hinterher eine SSH Verbindung aufbaut nützt das nix.

Was etwas bringen würde: Mehrere SSH Verbindungen gleichzeitig aufbauen lassen und so das Netzwerk besser auslasten. Das bekommt man aber mit einem simplen Bash Script aber nicht hin.

Nicht alle Scanner funktioniert gleich. Außerdem, wenn der Server nicht erreichbar ist, kann der Server überhaupt keine Antwort schicken.

Es ist natürlich keine doppelte Arbeit, sondern es spart die Arbeit.

Statt mehrere Verbindungenaufbau brauche ich nur einen einzigen Versuch.

genauer:

statt:
von A an B(SSH-Überprüfung)
A -B(für Server/Client starten)
A -B(Datenübetragung)
A-B(Server/Client stoppen)

--usw

brauche ich nur:

A-B(SSH-Überprüfung)
...Ende -wenn nicht möglich)

Server/Client Starten/ bedeutet nicht nur Verbindungsufbau von ssh, sondern der Server/Client wird gestarted durch SSH. D.h. SSH Verbindung wird aufgebaut, Server/Client gestartet. Nach der Messung wird der Server/Client wieder gestoppt, und SSH Verbindung wird aubgebaut.

Du kannst auch so vorstellen:

Du arbeitest in einer Firma. Alle in deiner Abteilung wollen Brot für Mittag essen kaufen. Dein Chef schickt Chef dich an die Bäckerei (du kannst auch anrufen). Du überprüft, ob die Bäckerei offen/zu. Wenn offen, können alle Brot kaufen. Wenn zu, warum sollen die in die Bäckerei gehen?

edwin7 hat geschrieben:

Nicht alle Scanner funktioniert gleich.

Jeder Scanner ist an die Grenzen gebunden, die das System ihm setzt. Ohne Root-Recht erlaubt ein Linux-System allerdings nur den connect Syscall, der einen vollständigen TCP-Handshake einleitet. Jede andere Art des Verbindungsaufbaus benötigt Raw-Sockets. Deswegen benötigt unter Linux sogar das ping-Tool Root-Rechte, weil ICMP-Pakete über Raw-Sockets manuell zusammengebaut werden müssen.

edwin7 hat geschrieben:

Außerdem, wenn der Server nicht erreichbar ist, kann der Server überhaupt keine Antwort schicken.

Das gilt für den Scanner und SSH gleichermaßen.

edwin7 hat geschrieben:

Es ist natürlich keine doppelte Arbeit, sondern es spart die Arbeit.

Das wiederrum ist schlicht falsch.

edwin7 hat geschrieben:

Statt mehrere Verbindungenaufbau brauche ich nur einen einzigen Versuch.

genauer:

statt:
von A an B(SSH-Überprüfung)
A -B(für Server/Client starten)
A -B(Datenübetragung)
A-B(Server/Client stoppen)

--usw

brauche ich nur:

A-B(SSH-Überprüfung)
...Ende -wenn nicht möglich)

Die "Überprüfung", ob SSH überhaupt möglich ist, macht SSH selbst auch. Mit einem vorherigen Scan sieht dein Ablauf eher so aus:

"SSH-Überprüfung" per Scanner
-> Ergebnis ohne jede Aussage, weil sich der Zustand des Netzwerks zwischen Scan und Verbindungsaufbau jederzeit ändern kann
zweite "SSH-Überprüfung" durch SSH
-> Abbruch, wenn nicht möglich
andernfalls:
A-B(für Server/Client starten)
A-B(Datenübetragung)
A-B(Server/Client stoppen)

edwin7 hat geschrieben:

Du arbeitest in einer Firma. Alle in deiner Abteilung wollen Brot für Mittag essen kaufen. Dein Chef schickt Chef dich an die Bäckerei (du kannst auch anrufen). Du überprüft, ob die Bäckerei offen/zu. Wenn offen, können alle Brot kaufen. Wenn zu, warum sollen die in die Bäckerei gehen?

Dieses Bild entspricht der Situation nicht wirklich. Es illusioniert, dass ein Portscan (einzelner Mitarbeiter) sehr billig ist, während ein SSH-Verbindungsaufbau (alle Mitarbeiter) sehr teuer ist. Diese Annahme ist für die gegebene Situation unzulässig:

Für den Fall, dass eine Verbindung nicht möglich ist, machen ein Scanner und SSH genau das gleich, und übertragen auch genau die gleiche Datenmenge. Sie schicken nämlich ein Packet für den Verbindungsaufbau, welches entweder im Nirvana verschwindet, wenn der Server nicht erreichbar ist, oder welches der Server mit RST beantwortet, wenn der Dienst nicht lauft. Ich kann mich nur wiederholen: Bis zu diesem Punkt macht ein Portscanner das gleiche wie SSH. Nur, dass der Portscanner die Verbindung abbricht, wenn sie zustande kommt, da er ja nicht an Kommunikation interessiert ist. SSH dagegen baut dann eine SSH-Verbindung auf. Das ist zwar sehr teuer verglichen mit dem Portscan, aber da du diese SSH-Verbindung eh aufbauen willst, ist das für die Betrachtung des Aufwands völlig irrelevant.

Ich werde das Gefühl nicht los, dass du eigentlich keine Ahnung hast, wovon du redest.