Forum: PC-Programmierung IP-Subsysteme im LAN effektiv finden?


von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

Ich stehe vor der Aufgabe, bestimmte Geräte, deren IPs zusammen mit 
anderen im LAN (Class C, Subnet 255.255.255.0) "verteilt" sind, schnell 
zu finden (die IP, die per DHCP verteilt wird).

Eine Reservierung anhand der MAC-Adresse im DHCP-Server oder eine 
Abfrage von dessen Lease-List sind nicht möglich, weil kein Zugang 
besteht.

Bisher habe ich einfach alle 254 Adressen (1-254) mit einem HTTP-Request 
durchgeleiert, denn die gesuchten Geräte antworten auf 
"http://a.b.c.d/?cmd=ident"; mit ihrem Gerätenamen, z.B. 
"<html>printmanager</html>". Fremde Gerät reagieren darauf nicht oder 
mit "Unsinn", so dass die Erkennung auf diese Weise kein Problem ist. 
Zumal sind die erwarteten Antworten bzw. Gerätenamen bekannt.

Das funktioniert sehr zuverlässig, aber eben langsam. Die MAC-Adressen 
der Subsysteme sind auch bekannt. Ich könnte natürlich auch schnell mal 
Alles durchpingen und dann den ARP-Cache aus einer Shell laden und darin 
herumparsen. Hier stört, dass die ARP-Resultate auf jeder Palttform 
(Win, Mac, Linux) anders formatiert sind ...

Hat jemand eine Idee, die er zum Besten geben möchte?

Auf die Insrallation zusätzlicher Tool soll verzichtet werden (z.B. 
"macping"), es muss mit Bordmitteln funktionieren.

Ansonsten bleibe ich halt einfach bei der trivialen Scan-Methode ...

: Bearbeitet durch User
von Mi. W. (mikuwi)


Lesenswert?

Frank E. schrieb:
> Ich stehe vor der Aufgabe, bestimmte Geräte, deren IPs zusammen mit
> anderen im LAN (Class C, Subnet 255.255.255.0) "verteilt" sind, schnell
> zu finden (die IP, die per DHCP verteilt wird).
>
> Das funktioniert sehr zuverlässig, aber eben langsam.

was ist "schnell" für Dich in einer üblichen SI-Einheit?

Programmausführung ohne Installationpipapo ist ok?

von Andreas M. (andreas_m62)


Lesenswert?

Ich benutze dazu das Programm NetSetMan in der kostenlosen Version.
Dazu einfach bei den Werkzeugen den Netzwerkscanner auswählen
und den zu durchsuchenden Netzwerkbereich eintragen und starten.

Mit dem Tool kann man auch viele verschiedene Netzwerkprofile anlegen
und mit eine Klick aktivieren.
Wenn man z.Bsp. in vielen verschiedenen Netzwerken arbeitet.

von Εrnst B. (ernst)


Lesenswert?

Multicast-DNS wurde genau für sowas gemacht, müssen deine Geräte im 
Netzwerk aber natürlich unterstützen.

von Rüdiger B. (rbruns)


Lesenswert?

NMap mit ZenMAp Gui. Sucht alle offene Ports im Subnet.

von Εrnst B. (ernst)


Lesenswert?

Rüdiger B. schrieb:
> NMap mit ZenMAp Gui. Sucht alle offene Ports im Subnet.

Will er ja garnicht. Er will nur die offenen Ports 80 (das kann man nmap 
noch mitteilen), und davon nur die, die auf seinen GET-Request korrekt 
antworten.

Sind 253 GET-Requests. Wenn er die parallel startet und nicht 
sequentiell, hat er in weniger als 0.1 Sekunden seine Liste fertig.

Schneller wird's mit einem externen Port-Scanning tool auch nicht.

von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

Εrnst B. schrieb:

> Sind 253 GET-Requests. Wenn er die parallel startet und nicht
> sequentiell, hat er in weniger als 0.1 Sekunden seine Liste fertig.

Danke, gute Idee - mein Programmierwerkzeug "Xojo" kann tatsächlich 
Threads, das hatte ich garnicht mehr auf dem Schirm ... naja klar: Der 
Wald und die Bäume oder ich werd alt :-(

Wenn es statt der bisherigen 30s nur 3 sind bin ich schon zufrieden. Ich 
werde berichten. Ich muss mal gucken, wieviel RAM so ein Thread braucht, 
muss auf einem Raspi mit 2GB laufen ... aber auch das könnte ich 
dynamisch anpassen, weil ich ja jederzeit abfragen kann, wieviel RAM 
noch frei ist ...

von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

Mi. W. schrieb:
> Frank E. schrieb:
>> Ich stehe vor der Aufgabe, bestimmte Geräte, deren IPs zusammen mit
>> anderen im LAN (Class C, Subnet 255.255.255.0) "verteilt" sind, schnell
>> zu finden (die IP, die per DHCP verteilt wird).
>>
>> Das funktioniert sehr zuverlässig, aber eben langsam.
>
> was ist "schnell" für Dich in einer üblichen SI-Einheit?
>
> Programmausführung ohne Installationpipapo ist ok?

Als single thread bzw. in einer ganz gewöhnlichen For-Schleife im 
Hauptprogramm bis zu 30 ... 35 Sekunden.

von Εrnst B. (ernst)


Lesenswert?

Frank E. schrieb:
> Danke, gute Idee - mein Programmierwerkzeug "Xojo" kann tatsächlich
> Threads,

Threads sind an dieser Stelle overkill und machen es nur langsamer.
Hunderte gleichzeitige TCP-Verbindungen kann Unix seit einem halben 
Jahrhundert auch ohne Threads problemlos ("select", "poll" &co).

Bei deinem Xojo läuft es darauf hinaus, einfach statt hintereinander 
jedesmal ein
"connection.SendSync" zu starten, eben "connection.Send" zu verwenden.
Das kannst du ohne Verzögerung 253mal aufrufen, die Verbindungen laufen 
parallel im Hintergrund, und du bekommst im Erfolgsfall ein 
"ContentReceived"-Event, sonst ein "Error".

von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

Εrnst B. schrieb:
> Frank E. schrieb:
>> Danke, gute Idee - mein Programmierwerkzeug "Xojo" kann tatsächlich
>> Threads,
>
> Threads sind an dieser Stelle overkill und machen es nur langsamer.

> "connection.SendSync" zu starten, eben "connection.Send" zu verwenden.
> Das kannst du ohne Verzögerung 253mal aufrufen, die Verbindungen laufen
> parallel im Hintergrund, und du bekommst im Erfolgsfall ein
> "ContentReceived"-Event, sonst ein "Error".

Ok, hab ich so noch nicht versucht, klingt einleuchtend.

von Pandur S. (jetztnicht)


Lesenswert?

Die Adressen 127 und 255 sind Multicast adressen. Die werden also von 
allen empfangen. Du kannst also dort einen algorithmus durchziehen, bei 
welchem dir schliesslich jeder antwortet. Und zwar schneller wie jeden 
einzeln abzufragen.

: Bearbeitet durch User
von Oliver S. (oliverso)


Lesenswert?

Pandur S. schrieb:
> Die Adressen 127 und 255 sind Multicast adressen.

Eine 255 als Host-Adresse wäre eine Broadcast-Adresse in einem C-Netz, 
aber 127?

Oliver

von Hmmm (hmmm)


Lesenswert?

Pandur S. schrieb:
> Die Adressen 127 und 255 sind Multicast adressen.

Die letzte Adresse im Netz ist die Broadcast-Adresse (Multicast ist noch 
eine andere Baustelle), bei einem /24 also die .255.

Die .127 ist in diesem Fall ein Host wie jeder andere.

von Rüdiger B. (rbruns)


Lesenswert?

Einen Ping auf die Broadcast Adresse und der ARP Cache ist gefüllt.

von (prx) A. K. (prx)


Lesenswert?

Rüdiger B. schrieb:
> Einen Ping auf die Broadcast Adresse und der ARP Cache ist gefüllt.

Schon ausprobiert?

von Oliver R. (orb)


Lesenswert?

Rüdiger B. schrieb:
> Einen Ping auf die Broadcast Adresse und der ARP Cache ist
> gefüllt.

Ja?
> arp -a

Schnittstelle: 10.10.10.1 --- 0x1
Internetadresse       Physische Adresse     Typ
10.10.10.2         54-a6-02-d1-02-e5     dynamisch
10.10.10.255       ff-ff-ff-ff-ff-ff     statisch

> ping 10.10.10.255

Ping wird ausgeführt für 10.10.10.255 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.

Ping-Statistik für 10.10.10.255:
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
    (100% Verlust),

> arp -a

Schnittstelle: 10.10.10.1 --- 0x1
Internetadresse       Physische Adresse     Typ
10.10.10.2         54-a6-02-d1-02-e5     dynamisch
10.10.10.255       ff-ff-ff-ff-ff-ff     statisch


ups.

Hmmm schrieb:
> Die .127 ist in diesem Fall ein Host wie jeder andere.

Aber nicht bei /25 ;-)

von Mario M. (thelonging)


Lesenswert?

Rüdiger B. schrieb:
> Einen Ping auf die Broadcast Adresse und der ARP Cache ist gefüllt.

"An ICMP Echo Request destined to an IP broadcast or IP multicast 
address MAY be silently discarded."

http://www.faqs.org/rfcs/rfc1122.html

von Hmmm (hmmm)


Lesenswert?

Mario M. schrieb:
> "An ICMP Echo Request destined to an IP broadcast or IP multicast
> address MAY be silently discarded."

Das ist heutzutage auch der Regelfall, bei mir antwortet gerade mal ein 
Drucker darauf.

In den 90ern war das noch anders, da wurden Unternehmen auch gerne mal 
zu unfreiwilligen DoS-Helfern, wenn die Admins "no ip 
directed-broadcast" nicht kannten.

von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

Ich mach das inzwischen mit einer Kombination aus Ping auf die IP und 
anschließendem arp mit der IP als Argument. Das ergibt als Antwort die 
MAC-Adresse für genau diese IP und keine meterlange Liste :-)

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Frank E. schrieb:

> Ich mach das inzwischen mit einer Kombination aus Ping auf die IP und
> anschließendem arp mit der IP als Argument. Das ergibt als Antwort die
> MAC-Adresse für genau diese IP und keine meterlange Liste :-)

So ein Blödsinn. Richtig wäre natürlich einfach ein ARP-WhoHas an die 
Broadcast-Adresse des interessierenden Netzes für jede IP-Adresse des 
interessierenden Netzes.

Und asynchron dazu einsammeln, was da an ARP-IsAt-Antworten eintrudelt. 
Also genau das tun, was ARP halt so tut (wenn eben auch normalerweise 
nur für gezielte Fragen).

Kein Ahnung, was Ping (also ICMP-Echo) dabei soll. Hat doch mit der 
Sache garnix zu schaffen. Kein Schwein interessiert sich dafür, ob das 
Target gewillt ist, auf ICMP-Echo zu antworten. Was interessiert ist: 
ist es überhaupt gewillt, irgendwie per IP zu kommunizieren.

Aber:
1. Es gibt Geräte, die ihre Bereitschaft, per IP zu kommunizieren, nicht 
so einfach verraten. Die wollen vorher erstmal noch einen anderen 
Broadcast sehen. Oder sogar eine ganz bestimmte Folge solcher 
Broadcasts. Bis sie die sehen, halten sie sich IP-mäßig bedeckt.
2. Es gibt sogar Geräte, die überhaupt niemals per IP kommunizieren, 
aber trotzdem das Netz benutzen. Halt nur auf Layer2.

von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

Ob S. schrieb:
> Frank E. schrieb:
>
>> Ich mach das inzwischen mit einer Kombination aus Ping auf die IP und
>> anschließendem arp mit der IP als Argument. Das ergibt als Antwort die
>> MAC-Adresse für genau diese IP und keine meterlange Liste :-)

> So ein Blödsinn. Richtig wäre natürlich einfach ein ARP-WhoHas an die
> Broadcast-Adresse des interessierenden Netzes für jede IP-Adresse des
> interessierenden Netzes.

Mag sein. Und wie starte ich das per CLI? ARP kennt keinen Befehl, mit 
"who". Aber vielleicht ist es ja das, was ich ohnehin mache?

> Kein Ahnung, was Ping (also ICMP-Echo) dabei soll. Hat doch mit der
> Sache garnix zu schaffen. Kein Schwein interessiert sich dafür, ob das
> Target gewillt ist ...

Doch. Die Targets, um die es MIR geht, abntworten definitiv auf Ping. 
Ich mache ja keinen allgemeinen Scan, sondern suche genau diese.

Aus Experimenten weiss ich, dass ich eine ARP-Antwort nur dann sicher 
erhalte, wenn vorher eine Kommuniktion stattfand, z.B. Ping.

von Mario M. (thelonging)


Lesenswert?

Ob S. schrieb:
> Kein Ahnung, was Ping (also ICMP-Echo) dabei soll.

Ping löst einen ARP-Request aus. Die MAC landet im ARP-Cache und kann 
mit arp -a angezeigt werden. Sozusagen ein "poor mans" arping.

von Εrnst B. (ernst)


Lesenswert?

Und 253-mal Ping (ggfs sogar auch per Kommandozeilen-Ping-Tool) und dann 
den arp-cache auslesen (per Kommandozeilen-Tool) soll schneller sein, 
als einfach aus deinem Programm die 253 IPs per HTTP-Get durchzutesten?
Kann ich mir nicht vorstellen. Und du brauchst den HTTP-Get nach dem ARP 
sowieso auch noch, für dein ?cmd=ident...

Und das Vorab-Filtern nach bekannter MAC kann dir bei etwas komplexeren 
Network-Setups auch auf die Füße fallen, Stichwort VPN, ProxyArp, usw...

von Jens B. (dasjens)


Lesenswert?

Εrnst B. schrieb:

> Sind 253 GET-Requests. Wenn er die parallel startet und nicht
> sequentiell, hat er in weniger als 0.1 Sekunden seine Liste fertig.
>

Wie kann ich über eine Serielle Leitung Parallel scannen? :P

von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

Jens B. schrieb:
> Εrnst B. schrieb:
>
>> Sind 253 GET-Requests. Wenn er die parallel startet und nicht
>> sequentiell, hat er in weniger als 0.1 Sekunden seine Liste fertig.
>>
>
> Wie kann ich über eine Serielle Leitung Parallel scannen? :P

Nur quasi: Threads.

von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

Εrnst B. schrieb:

> Und das Vorab-Filtern nach bekannter MAC kann dir bei etwas komplexeren
> Network-Setups auch auf die Füße fallen, Stichwort VPN, ProxyArp, usw...

Ich will kein universelles Werkzeug, ich brauche nur die Antwort der 
Clients im gleichen LAN/24. Und ich weiss, wie viele ich finden muss (4 
Stück), kann also aufhören, sobald alle erkannt sind.

Allzuviele Sockets gleichzeitig scheint mir auch keine so gute Idee, 
weil das Ganze am Raspi 4 mit 2GB laufen muss, keine Ahnung wie viele 
das Raspian  abkann. Vielleicht hat jemand dazu eine Idee.

Es ist ja nicht so, dass die biherige Methode nicht funktioniert, ich 
hätte sie nur gerne etwas beschleunigt. Deshalb alles komplett 
umzustellen lohnt sich allerdings auch nur in Grenzen.

von Franko S. (frank_s866)


Lesenswert?

Frank E. schrieb:
> Nur quasi: Threads.
So machen das DAUs wenn sie besonders schlau sein wollen.

von Εrnst B. (ernst)


Lesenswert?

Frank E. schrieb:
> Allzuviele Sockets gleichzeitig scheint mir auch keine so gute Idee,
> weil das Ganze am Raspi 4 mit 2GB laufen muss

Auf dem Raspi kriegst du locker 10000 gleichzeitige GET-Requests mit 
deinen Datenmengen hin, bevor der überhaupt auf 1% CPU-Auslastung 
kommt... Allerdings nicht wenn man das über 10000 gleichzeitig laufende 
Threads löst.
Ein einziger Aufruf des "arp"-Utilities aus deinem Programm heraus 
braucht schon mehr Ressourcen als der ganze Scan per TCP/HTTP... Und ist 
ja scheinbar auch kein Thema, was deinen RasPi irgendwie überfordert.

Kurz getestet: 254 sockets (NONBLOCK) aufgemacht, allen ein "connect" 
gegeben, alle per epoll_ctl(...EPOLL_ADD zu einem epoll-fd hinzugefügt.

Dann per epoll_wait warten, was auf den einzelnen sockets passiert, mit 
timeout.

Die Userspace-CPU-Zeit ist mit "time" nicht mehr messbar, 
system/kernel-Zeit liegt bei ~12millisekunden, "real"-Zeit hängt vom 
gewählten Timeout ab.
1
> time ./conn_test 192.168.23
2
Successful connection to 192.168.23.1
3
Successful connection to 192.168.23.8
4
Successful connection to 192.168.23.17
5
Successful connection to 192.168.23.120
6
Timeout reached. Stopping.
7
8
real    0m0,279s
9
user    0m0,000s
10
sys     0m0,012s

Das wird auch nicht mehr fett, wenn man dann die sowieso schon 
verbundenen Sockets nimmt um ein "GET /?cmd=ident HTTP/1.0\r\n\r\n" 
hinterherzuschicken, und die Antwort auszulesen.

von Εrnst B. (ernst)


Lesenswert?

Nachtrag: Das mit <1% CPU war etwas übertrieben.
Wenn ich auf die Weise 192.168.0.0/16 scanne (Also ~ 64k gleichzeitig 
verbindende TCP-Sockets)
dann lastet das für etwas über 2 Sekunden einen CPU-Kern aus.
d.H. da würde es dann langsam Sinn machen das Ganze auf 4 Threads zu 
verteilen.
1
Successful connection to 192.168.1.8
2
Successful connection to 192.168.1.10
3
Successful connection to 192.168.1.11
4
Successful connection to 192.168.1.182
5
Successful connection to 192.168.1.189
6
Successful connection to 192.168.1.125
7
Successful connection to 192.168.1.163
8
Successful connection to 192.168.1.254
9
Successful connection to 192.168.1.154
10
Successful connection to 192.168.1.190
11
Successful connection to 192.168.1.191
12
Successful connection to 192.168.23.8
13
Successful connection to 192.168.23.17
14
Successful connection to 192.168.1.188
15
Successful connection to 192.168.1.134
16
Successful connection to 192.168.23.1
17
Successful connection to 192.168.1.184
18
Successful connection to 192.168.1.124
19
Successful connection to 192.168.144.1
20
Successful connection to 192.168.144.22
21
Timeout reached. Stopping.
22
23
real    0m2,415s
24
user    0m0,048s
25
sys     0m2,105s

: Bearbeitet durch User
von Jens M. (schuchkleisser)


Lesenswert?

Du hast jetzt ernst mal eben einen Scanner zusammengehackt, der in 
"Nullzeit" alle in einem Netz erreichbaren Geräte findet?
Geilo!

Kannst du das für Windows bauen, gern auch als Kommandozeilendings? Oder 
kennst du ein "Fertigprodukt" das genau das macht?
Ich wüsste nämlich auch ganz gern mal, welche IPs hier besetzt sind, und 
diverse Scanner dauern ewig oder melden "7 denied" aber ohne IP bei 
Geräten die kein HTTP können/wollen, das nutzt mir nix, ich weiß das die 
da sind aber eben die Adresse nicht.

von Frank E. (Firma: Q3) (qualidat)


Angehängte Dateien:

Lesenswert?

So, ich hab mal was gebastelt (Xojo), das scannt ein /24-Netz in 3,5s. 
Was momentan fehlt, ist der Filter auf die speziell formatierte Antwort, 
weil ich die dazu nötigen Geräte (Automaten-Komponenten) gerade nicht im 
Zugriff habe. Was man hier sieht, sind die IPs und MACs, der Geräte, die 
in meinem privaten Netz auf einen schnöden HTTP-Request, auch ohne 
Parameter, antworten. Das genügt mir hinsichtlich der Geschwindigkeit 
vollkommen. Danke für die hilfreichen Tips.
1
Public Sub find_mac(ip_base as string) // ip_base like "192.168.10."
2
3
  var uc(255) as URLConnection //List of HTTP-Sockets
4
  var ff(255) as FolderItem //List of temporary files
5
  var path as string = SpecialFolder.Temporary.NativePath+"/uc." //path in tmp folder
6
  
7
  var ip, ret as string
8
  var t as TextInputStream
9
  var i  as integer
10
  
11
  list.RemoveAllRows //clear listbox table
12
  
13
  for i=1 to 254 // first loop to send the requests
14
    uc(i) = new URLConnection
15
    ff(i) = new FolderItem(path + str(i) + ".tmp")
16
    uc(i).send("GET" , "http://" + ip_base + str(i) , ff(i) , 3)
17
  next
18
  
19
  wait 300 //wait 3s for timeout
20
  
21
  for i=1 to 254 //second loop for reading the results
22
23
    if ff(i)<>nil then
24
      if ff(i).Exists then
25
        
26
        t = TextInputStream.Open(ff(i))
27
        
28
        if t.readall.Trim <> "" then //if temp file not empty
29
30
          var s as new shell
31
          ip = ip_base + str(i)
32
          s.Execute "arp " + ip
33
          
34
          while s.IsRunning //wait for termination of shell
35
            app.DoEvents
36
          wend
37
          
38
          list.addrow ip , mac_reform(s.Result) //result into the listbox
39
        end if
40
        
41
        t.close
42
        ff(i).Remove
43
        
44
      end if
45
    end if
46
  next
47
End Sub

: Bearbeitet durch User
von Rüdiger B. (rbruns)


Lesenswert?

Mario M. schrieb:
> "An ICMP Echo Request destined to an IP broadcast or IP multicast
> address MAY be silently discarded."
>
> http://www.faqs.org/rfcs/rfc1122.html

Oh, das ist eine Handvoll Jahre her das ich das gemacht hatte.
Mit dem Browser ( oder wget ) eine HTML Seite aufrufen die alle 253 IP 
Adressen hat und dann den ARP Cache auslesen.

: Bearbeitet durch User
von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Mario M. schrieb:

> Ping löst einen ARP-Request aus.

Ja klar, das tut jeder Versuch einer IP-Kommunikation (wenn die MAC der 
Zieladresse nicht schon im ARP-Cache ist).

Genau dafür ist ARP halt da. Und für den Fall, dass man sich dafür 
interessiert, welche Geräte im Netz sind, die gewillt sind, per IP zu 
kommunizieren, reicht es also logischerweise aus, für jede Adresse des 
Netzes eine ARP-Anfrage zu senden.

Das ist die kleinstmögliche und damit logischerweise auch 
schnellstmögliche Kommunikation zu diesem Thema. Genau dafür wurde ARP 
schließlich geschaffen.

Bei allen anderen hier genannten Ansätzen wird der Kanal mit Bullshit 
höherer Protokolle zugespammt, die mit der eigentlichen Aufgabe rein 
garnix zu tun haben.

von Εrnst B. (ernst)


Lesenswert?

Ob S. schrieb:
> Bei allen anderen hier genannten Ansätzen wird der Kanal mit Bullshit
> höherer Protokolle zugespammt, die mit der eigentlichen Aufgabe rein
> garnix zu tun haben.

Die eigentliche Aufgabe aus dem Eröffnungs-Beitrag war ein HTTP GET an 
alle Geräte im Subnetz, die Port 80 offen haben.
Der "Bullshit höherer Protokolle" wird also so oder so benötigt.
Und das "zuspammen" verhindert schon der Kernel. Wenn der beim 
TCP-Connect-Versuch keine ARP-Antwort erhält oder im Cache hat, dann 
wandert auch kein TCP-SYN über die Leitung. Wie auch.

Klar, man kann anfangen Teile des Kernel-Netzwerkstacks 
nachzuimplementieren, in der Hoffnung da etwas Zeit für einen speziellen 
Anwendungsfall rauszuholen. NMap macht das m.W. bei manchen Scan-Arten 
per Raw-Sockets. Aber will man sich das bei so einer kleinen Anzahl von 
möglichen Ziel-IPs antun?

von Εrnst B. (ernst)


Angehängte Dateien:

Lesenswert?

Jens M. schrieb:
> Du hast jetzt ernst mal eben einen Scanner zusammengehackt, der in
> "Nullzeit" alle in einem Netz erreichbaren Geräte findet?
> Geilo!

Das ist komplett Boiler-Plate-Code, den hat mir ChatGPT so fast korrekt 
zusammengestöpselt.

Für den TE bringt das nix. Die zentrale "epoll"-Event-Loop hat sein Xojo 
sowieso schon, Xojo packt auch die Sockets da von selber rein, und 
wandelt die epoll-events auf seine eigenen events am Connection-Objekt 
um.
d.H. mindestens 75% vom Code ist sowieso schon von seinem Framework 
erschlagen, das muss nicht als low-level C-Code implementiert werden...

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Εrnst B. schrieb:

> Die eigentliche Aufgabe aus dem Eröffnungs-Beitrag war ein HTTP GET an
> alle Geräte im Subnetz, die Port 80 offen haben.

Nein, das war nur, was der TO getan hat, weil er es nicht besser wusste 
oder konnte.

Wenn man das ganze Posting liest (und denken kann), stellt sich heraus: 
Er kennt das Netz und er kennt die die MACs der Geräte, nach denen er 
sucht.

Also: er benötigt genau nur eins: ARP. Kein IP und schon gar kein HTTP.

Das Zeug kommt dann erst zum Zuge, wenn er seine Ziele gefunden hat. Und 
dann eben auch nur für die.

> Der "Bullshit höherer Protokolle" wird also so oder so benötigt.

Aber doch nicht für jede verfickte Adresse im Netz, auf der irgendein 
Gerät bereit ist, IP zu sprechen...

> Und das "zuspammen" verhindert schon der Kernel. Wenn der beim
> TCP-Connect-Versuch keine ARP-Antwort erhält oder im Cache hat, dann
> wandert auch kein TCP-SYN über die Leitung. Wie auch.

Ja, aber wenn da ein Gerät ist, welches IP sprechen mag, aber eben 
NICHT mit der erwarteten MAC ausgestattet ist, dann geht der ganze 
Bullshit übers Netz. Natürlich mehr oder weniger erfolglos, aber er 
kostet Bandbreite und damit Zeit. Dein Argumunt passt als allerhöchstens 
dann, wenn das gesamte Netz bis auf die gesuchten Geräte unbenutzt 
ist...

> Klar, man kann anfangen Teile des Kernel-Netzwerkstacks
> nachzuimplementieren

Das braucht man sicher nicht, um ein Sack voll simple ARP-Abfragen 
rauszuschicken und nach einiger Zeit einen Blick auf den Bestand des 
ARP-Cache zu werfen...

DU kannst es nur nicht so. Das ist eigentlich schon alles.

von Εrnst B. (ernst)


Lesenswert?

Ob S. schrieb:
> Also: er benötigt genau nur eins: ARP.

Ne. Genau das braucht er nicht.
ARP findet zu einer bekannten IP-Adresse die unbekannte MAC-Adresse.
Das Problem des TE ist genau umgekehrt.

von Jens B. (dasjens)


Lesenswert?

Franko S. schrieb:
> Frank E. schrieb:
>> Nur quasi: Threads.
> So machen das DAUs wenn sie besonders schlau sein wollen.

MFA von Microsoft Azure kann man so umgehen.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Εrnst B. schrieb:

> Ne. Genau das braucht er nicht.
> ARP findet zu einer bekannten IP-Adresse die unbekannte MAC-Adresse.

Genau. Einen umgekehrten Weg gibt es nicht und kann es auch nicht 
geben. Das liegt in der Natur der Sache.

Genau deswegen ist es ja auch nötig, nach sämtlichen in Frage kommenden 
IP-Adressen zu fragen. Und das können bei größeren Netzen schon mal eine 
ganze Menge sein. Bei einem 10.x.x.x/8-Netz sind es eben mal so 
16.777.214 nötige Anfragen. Gerade dann zählt jedes gesparte Byte 
Traffic pro Anfrage...

Natürlich werden sich wenigsten so ein 8er-Netz anhängen. Aber 
10.x.x.x/16 oder 172.16..31.x.x/16 kommt durchaus häufiger mal vor. Da 
sind dann auch noch 65.534 Adressen zu befragen.

von Harry L. (mysth)


Lesenswert?

Ich hätte das ja mit nmap gemacht.
1
harry@harry-DT:~/Downloads$ sudo nmap -sP 10.17.67.0/24
2
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-12-15 21:10 CET
3
Nmap scan report for _gateway (10.17.67.1)
4
Host is up (0.000069s latency).
5
MAC Address: 50:91:E3:25:B8:D0 (Unknown)
6
Nmap scan report for 10.17.67.3
7
Host is up (0.00044s latency).
8
MAC Address: 14:49:BC:4B:F4:18 (DrayTek)
9
Nmap scan report for 10.17.67.5
10
Host is up (0.00014s latency).
11
MAC Address: 5E:2F:8F:64:0E:94 (Unknown)
12
Nmap scan report for 10.17.67.9
13
Host is up (0.00088s latency).
14
MAC Address: 9E:15:16:18:79:F2 (Unknown)

usw...
1
Nmap scan report for 10.17.67.146
2
Host is up (0.078s latency).
3
MAC Address: F0:A3:B2:EE:0C:31 (Hui Zhou Gaoshengda Technology)
4
Nmap scan report for harry-DT (10.17.67.8)
5
Host is up.
6
Nmap done: 256 IP addresses (22 hosts up) scanned in 2.10 seconds

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Harry L. schrieb:

> harry@harry-DT:~/Downloads$ sudo nmap -sP 10.17.67.0/24

'n 24er Netz ist doch absolut lächerlich. Da sind

> Nmap done: 256 IP addresses (22 hosts up) scanned in 2.10 seconds

2,1 Sekunden viel zu viel. Das kann man auch in ein paar zehn ms 
erledigen.

von Harry L. (mysth)


Lesenswert?

Ob S. schrieb:
> Das kann man auch in ein paar zehn ms
> erledigen.

Und das ist jetzt weshalb relevant?

von Hannes J. (Firma: _⌨_) (pnuebergang)


Lesenswert?

Ob S. schrieb:
> Genau deswegen ist es ja auch nötig, nach sämtlichen in Frage kommenden
> IP-Adressen zu fragen.

Nein, ist es nicht, wenn er seine Hosts richtig gebaut hätte. Nämlich 
so, dass sie ein Service-Discovery unterstützen. SSDP, WS-Discovery, 
etc. Gibt genug Protokolle.

So muss er ein ganzes Subnet scannen. Was in kommerziellen Installation 
schnell mal richtig Ärger mit den Admins einbringt. Zumindest wenn die 
entsprechende Überwachungsmechanismen im LAN haben.

Das Scannen ist weder toll noch clever, sondern Pfusch. Kein Grund sich 
zu feiern.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Hannes J. schrieb:

> Nein, ist es nicht, wenn er seine Hosts richtig gebaut hätte. Nämlich
> so, dass sie ein Service-Discovery unterstützen. SSDP, WS-Discovery,
> etc. Gibt genug Protokolle.

Ja klar. Und woher weißt du bei der Geräteentwicklung, welches dieser 
Protokolle im Zielnetz der Geräte "zugelassen" ist? Typisch weiß man ja 
bei der Geräteentwicklung noch nicht, wohin der Kram mal verkauft werden 
wird. Allenfalls hat man zu diesem Zeitpunkt gewisse Hoffnungen, an wen 
man das verkaufen könnte, aber man hat wohl kaum Detailinformationen zu 
den Netzen der gewünschten Kunden...

> So muss er ein ganzes Subnet scannen. Was in kommerziellen Installation
> schnell mal richtig Ärger mit den Admins einbringt. Zumindest wenn die
> entsprechende Überwachungsmechanismen im LAN haben.

Wenn das Netz derart restriktiv konfiguriert ist, dass es sogar 
ARP-Requests limitiert (ganz ausschalten kann man die heute wohl aus 
praktischen Gründen nicht mehr, fast alles spricht IP und braucht 
dementsprechend ARP), dann kannst du GANZ sicher davon ausgehen, dass 
auch nicht übermässig viele Discovery-Protokolle darin zugelassen und 
die zugelassenen im Detail auch wieder nur restriktiv zugelassen sind. 
Sprich: selbst wenn es z.B. WS-Discovery prinzipiell gibt (weil z.B. 
bestimmte Drucker verwendet werden sollen), dann wird trotzdem nicht 
jedes Gerät die Vollmacht haben, sich in das entsprechende Verzeichnis 
einzutragen. Wäre ja noch schöner...

Sprich: dieser Ansatz hilft dem TO in stark reglementierten Netzen auch 
nicht weiter. Sehr wahrscheinlich tut das dann aber überhaupt kein 
Ansatz. Typisch ist in solchen Netzen nämlich auch Port-Security 
durchgesetzt. D.h.: du kannst deine Geräte zwar an irgendwelche Dosen 
dranstöpseln, sie werden dort aber nichts weiter tun können als einen 
Alarm für den Admin auszulösen...

von Hmmm (hmmm)


Lesenswert?

Ob S. schrieb:
> Wenn das Netz derart restriktiv konfiguriert ist, dass es sogar
> ARP-Requests limitiert (ganz ausschalten kann man die heute wohl aus
> praktischen Gründen nicht mehr, fast alles spricht IP und braucht
> dementsprechend ARP)

Kann man (z.B. ifconfig <if> -arp), dann braucht man halt statische 
Einträge. Ist aber nur in seltenen Fällen sinnvoll.

Was mir hingegen schon in der Praxis begegnet ist, sind Geräte, die 
nicht auf ARP-Requests antworten, sondern ausschliesslich in festen 
Intervallen Gratuitous ARP (also unaufgeforderte Replies) verschicken. 
Da das Smartwatches waren, wohl aus Energiespargründen.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Hmmm schrieb:

> Was mir hingegen schon in der Praxis begegnet ist, sind Geräte, die
> nicht auf ARP-Requests antworten, sondern ausschliesslich in festen
> Intervallen Gratuitous ARP (also unaufgeforderte Replies) verschicken.

Huch...

Gibt es tatsächlich noch Geräte, die solche ARP-"Antworten" in ihren 
ARP-Cache aufnehmen?

Das sollte doch wegen des zeitweise sehr beliebten Angriffszenarios des 
ARP-Spoofing inzischen praktisch überall geblockt werden.

OK, ARP-Spoofing funktioniert auch mit Unicast-Antworten. Aber eben nur 
bei einem Peer, nicht gleich bei allen.

von Rolf M. (rmagnus)


Lesenswert?

Nochmal zurück nach oben:

Εrnst B. schrieb:
> Multicast-DNS wurde genau für sowas gemacht, müssen deine Geräte im
> Netzwerk aber natürlich unterstützen.

Das ist keine Option? Da kannst du einfach jedem Gerät einen Namen 
geben, über den du es dann unabhängig von seiner IP ansprechen kannst, 
genau wie mit klassischem DNS, nur dass man keinen Server braucht.

Jens B. schrieb:
> Εrnst B. schrieb:
>
>> Sind 253 GET-Requests. Wenn er die parallel startet und nicht
>> sequentiell, hat er in weniger als 0.1 Sekunden seine Liste fertig.
>>
>
> Wie kann ich über eine Serielle Leitung Parallel scannen? :P

Ich vermute, es bezog sich auf die Software, nicht auf die Leitung 
selbst. Wenn man einen GET-Request versucht, muss man ja so lange 
warten, bis eine Antwort kommt oder der Timeout abläuft. Also macht man 
mehrere Requests parallel, damit die alle gleichzeitig warten können 
statt nacheinander.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.