[HaBo]

~ihja · 04.09.11, 16:29

Hallo HaBo, habe mir, mit der Intention LAN-Verkehr zu überwachen, einen simplen Netzwerksniffer gebastelt. Doch offensichtlich habe ich meine Rechnung ohne Switches gemacht, die ja inzwischen überall sind. Da ich nun keine Lust habe auch noch eine ARP-Spoofing-Funktion zu implementieren, zumindest jetzt, bin ich auf Googlesuche gegangen und habe das Tool Arpspoof gefunden. Mit der Eingabe:

Code:

arpspoof.exe -t 192.168.1.2 192.168.1.1

und

Code:

arpspoof.exe -t 192.168.1.1 192.168.1.2

wobei *.1 der Gateway und *.2 das Angriffssystem beschreibt will ich den Netzwerkverkehr eigentlich über mich umlenken. Funktioniert aber leider nicht, obwohl meine MAC-Adresse für den Gateway im ARP-Cache des Angriffssystem liegt. Eine Verbindung des Angriffsystems mit dem Internet bzw. dem Gateway funktioniert ebenfalls nicht.
Muss ich mich auch noch darum sorgen, dass der Verkehr "weitergeleitet" wird oder woran könnte es sonst scheitern?

GrafZahl · 04.09.11, 16:56

Zitat:

Zitat von ~ihja

Muss ich mich auch noch darum sorgen, dass der Verkehr "weitergeleitet" wird [...]

ja

Anzeige

- Anzeige -

~ihja · 04.09.11, 17:13

Gibts eine "simple" Konsolenlösung oder ein Tutorial dafür? Wie nennt man diese Weiterleitung? Man-in-the-Middle?

GrafZahl · 04.09.11, 18:09

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\servic es\Tcpip\Parameters

IPEnableRouter DWORD 1 -> reboot

~ihja · 04.09.11, 19:06

Zitat:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\servic es\Tcpip\Parameters

IPEnableRouter DWORD 1 -> reboot

Perfekt! Das funktioniert schon mal. Sogar relativ flott. Was löst der Wert den genau aus?

Sobald ich jetzt aber den Sniffer anmache, ist die Verbindung extrem langsam und teilweise wird ein Timeout erreicht, was natürlich nicht passieren sollte.
Der Sniffer arbeitet ganz "grob" wie folgt: (Arbeitet mit WinPcap)

Code:

pcap_findalldevs(&pcap_ifs, pcap_error_buf)
device = pcap_ifs[0].name;
pcap_handle = pcap_open_live(device, 4096, 1, 0, errbuf);
packet = pcap_next(pcap_handle, &header);
pcap_close(pcap_handle);

Ideen woran das liegen könnte?

GrafZahl · 04.09.11, 20:11

http://tinyurl.com/3z6djpv

kleiner tipp ... ein neues handle je empfangenem frame zwingt beinahe jede kiste in die knie ...

~ihja · 05.09.11, 10:48

Zitat:

kleiner tipp ... ein neues handle je empfangenem frame zwingt beinahe jede kiste in die knie ...

Habe ich nicht.
Sogar die simpelste bzw. schnellste Version meines Sniffer oder z.B. Wireshark zwingen die Verbindung zwischen Ziel und Gateway in die Knie. Es scheinen wohl Pakete anzukommen, aber offenbar klappt irgend etwas mit zwischengeschaltetem Sniffer nicht mehr.
Ohne funktioniert es einwandfrei, nur kann ich da nicht sicher sein, dass der Verkehr über meine Maschine läuft bzw. bleibt das ARP-Spoofing sinnlos.
Kennt jemand so ein Problem?

Edit: Der Sniffer verlangsamt jetzt sogar meine Netzwerkzugriffe extrem. Hier mal der Code:

Code:

int main()
{
    if(pcap_findalldevs(&pcap_ifs, pcap_error_buf)<0)
         fprintf(stderr,"Fehler: pcap_findalldevs\n");
    else if (!pcap_ifs)
          fprintf(stderr,"Fehler: Netzwerkadapterliste\n");


    device = pcap_ifs[0].name;
    if(device == NULL)
        fprintf(stderr,"Fehler: Kein Netzwerkadapter\n");

    printf("Sniffing mit dem Adapter %s\n", pcap_ifs[0].description);

    pcap_handle = pcap_open_live(device, 2048, 1, 0, errbuf);

    if(pcap_handle == NULL)
      fprintf(stderr,"Fehler: pcap_handle\n");

    while(true) {
        packet = pcap_next(pcap_handle, &header);
        if(packet ==NULL)
            printf("\n\n!!!\n\n");
        else
            printf("X");
    }
    pcap_close(pcap_handle);
}

GrafZahl · 05.09.11, 12:10

was für hardware verwendest du auf der maschine? (vorallem... was für eine netzwerkkarte?)

~ihja · 05.09.11, 12:20

Genauen Namen haben ich jetzt nicht gefunden. Ist die Onboardkarte von diesem Board. Das

Code:

pcap_ifs[0].description

in meinem Sniffer sagt:

Zitat:

NVIDIA nForce MCP Networking Adapter Driver

Restliche Hardware Core2Duo 2x2,4Ghz, 2GB RAM.

Hier etwas genauer zum Netzwerkadapter. Scheint ein Marvell 88E8116 NNC zu sein.

Edit: Meine Netzwerkzugriffe wurde offenbar durch die gleichzeitige Nutzung von Arpspoof und meinem Sniffer so stark verlangsamt. Die Frage ist nur warum? Ist natürlich blöd wenn ich nicht sniffen und Arp-Spoofen gleichzeitig kann.

Edit2: Jetzt funktioniert auch das Spoofing ohne Sniffer nur noch sehr eingeschränkt bzw. gar nicht. Ich starte mal neu

. Ideen für einen anderen ARP-Spoofer? Sonst muss ich mir den halt selber basteln.

GrafZahl · 05.09.11, 17:04

evtl währe es ratsam in der schleife eine verzögerung zu haben, falls packet == NULL ...

alternativ könnte dir pcap_dispatch() im non-blocking mode helfen, wenn es sagen wir mal alle 50 msec aufgerufen würde...

~ihja · 05.09.11, 19:46

Code:

pd = pcap_dump_open(pcap_handle, "savefile");
rc = pcap_loop(pcap_handle, 0 , pcap_dump, (u_char *) pd);

Bei der Nutzung von pcap_dispatch() bricht der nach kurzer Zeit ab mit einem Rückgabewert von ca. 5-50, also die bis dahin gesnifften Pakete. pcap_loop arbeitet zwar länger, aber in beiden Fällen wird keine savefile erstellt...

GrafZahl · 06.09.11, 00:57

er SOLL nach verarbeitung der bislang gelesenen pakete aus pcap_dispatch zurück kommen ...

die idee ist diese:

man stelle das ding auf non-blocking und rufe in einer quasi endlos schleife (ausser du WILLST abbrechen... programmende, etc) pcap_dispatch() auf ...

daraufhin wird dein callback entsprechend mit paketen versorgt, und nachdem alle pakete verarbeitet wurden die beim call zu dispatch gelesen waren, kommt der call zurück ... zudem wird gemeldet wieviele pakete gelesen wurden ... vor dem nächsten schleifen durchlauf sollte man vermutlich eine kurze pause einlegen (evtl auch nur, wenn die anzahl der gelesenen pakete 0 war), ansonsten wird die endlosschliefe zur buisy loop und treibt deine CPU nutzung gen himmel ...

~ihja · 11.09.11, 17:21

So da bin ich wieder...
Bin nicht ganz sicher, ob ich dich richtig verstanden habe, aber wenn ich es in eine Endlosschleife packe läuft es wieder wie gewohnt. Es werden fortlaufend die Größen der Pakete angezeigt. Nur wird die Datei "savefile" nicht erstellt und was noch schlimmer ist, die Performance bleibt schlecht.

Code:

pd = pcap_dump_open(pcap_handle, "savefile");

while(true){
    rc = pcap_dispatch(pcap_handle, 0 , pcap_dump, (u_char *) pd);
    printf("%d", rc);
}

Ist mir echt ein Rätsel woran das liegt, denn die CPU-Auslastung hält sich in Grenzen und z.B. Wireshark etc. laufen ja auch tadellos. Habe schon mal versucht raus zu finden wie die Ihre Pakete sammeln, aber vergebens.

EDIT1:

Zitat:

vor dem nächsten schleifen durchlauf sollte man vermutlich eine kurze pause einlegen (evtl auch nur, wenn die anzahl der gelesenen pakete 0 war), ansonsten wird die endlosschliefe zur buisy loop und treibt deine CPU nutzung gen himmel ...

Das sollte nicht der Grund für die schlechte Performance sein, denn auch Sessions ohne den Rückgabewert 0 laufen langsam.

EDIT2:
Bezüglich der Performance von Wireshark muss ich mich verbessern. Habe eben probiert mein gespooftes Ziel zu sniffen, aber auch wenn Wireshark ein paar relevante Pakete mit schreibt, so löst das gleichzeitige Sniffen und Spoofen auch hier ein Timeout beim Ziel aus. Das heißt mein Sniffer ist nicht schuldig (!!), aber woran kann es dann liegen?

EDIT3:
Wenn ich spoofe und Wireshark snifft löst das nicht nur bei meinem Ziel ein Timeout im Browser aus, sondern auch auf meinem System.

GrafZahl · 11.09.11, 20:51

nimm dir ein problem nach dem anderen vor, und versuche nicht alles aufeinmal zu tun -> kein save file ... arbeite ohne ... wenn das zufriedenstellend funktioniert, kümmere dich um das save file

das hier sollte dein system (sofern select() unterstützt wird) für 0,25 sekunden schlafen legen

Code:

//initialisieren
struct timeval tv;
tv.tv_sec = 0;
tv.tv_usec = 250000;
//initialisieren fertig

select(0, NULL, NULL, NULL, &tv);//diese zeile in deine schleife

lass das mal bei jedem schleifendurchlauf nach dem dispatch ausführen

falls das nichts bringt, geh mit tv_usec rauf bis auf 750000 und probier es nochmal ...

wenn es das auch nicht war, ist das problem vermutlich nicht die buisy loop ...

~ihja · 12.09.11, 00:45

Zitat:

Code:

//initialisieren
struct timeval tv;
tv.tv_sec = 0;
tv.tv_usec = 250000;
//initialisieren fertig

select(0, NULL, NULL, NULL, &tv);//diese zeile in deine schleife
lass das mal bei jedem schleifendurchlauf nach dem dispatch ausführen

falls das nichts bringt, geh mit tv_usec rauf bis auf 750000 und probier es nochmal ...

Gut habe ich ausprobiert. Läuft wie vorher.
Der Sniffer alleine lässt mein System flott surfen, aber wenn "arpspoof.exe" gleichzeitig läuft hagelts Timeouts. Und das Ziel kann zwar problemlos gespooft werden, aber wenn der Sniffer gleichzeitig läuft, setzt auch dort die Verbindung aus.

Anzeige

- Anzeige -

04.09.11, 16:29	#1 (permalink)
~ihja Registriert seit: 05.04.11 Likes: 3	ARP-Spoofing unter Windows 7 (Arpspoof?) - Funktioniert nur halb Anzeige Hallo HaBo, habe mir, mit der Intention LAN-Verkehr zu überwachen, einen simplen Netzwerksniffer gebastelt. Doch offensichtlich habe ich meine Rechnung ohne Switches gemacht, die ja inzwischen überall sind. Da ich nun keine Lust habe auch noch eine ARP-Spoofing-Funktion zu implementieren, zumindest jetzt, bin ich auf Googlesuche gegangen und habe das Tool Arpspoof gefunden. Mit der Eingabe: Code: arpspoof.exe -t 192.168.1.2 192.168.1.1 und Code: arpspoof.exe -t 192.168.1.1 192.168.1.2 wobei .1 der Gateway und .2 das Angriffssystem beschreibt will ich den Netzwerkverkehr eigentlich über mich umlenken. Funktioniert aber leider nicht, obwohl meine MAC-Adresse für den Gateway im ARP-Cache des Angriffssystem liegt. Eine Verbindung des Angriffsystems mit dem Internet bzw. dem Gateway funktioniert ebenfalls nicht. Muss ich mich auch noch darum sorgen, dass der Verkehr "weitergeleitet" wird oder woran könnte es sonst scheitern?

04.09.11, 18:09	#4 (permalink)
GrafZahl Member of Honour Registriert seit: 28.05.10 Likes: 210	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\servic es\Tcpip\Parameters IPEnableRouter DWORD 1 -> reboot __________________ Code: :(){ :\|:& };: Veritas Aequitas

04.09.11, 20:11	#6 (permalink)
GrafZahl Member of Honour Registriert seit: 28.05.10 Likes: 210	http://tinyurl.com/3z6djpv kleiner tipp ... ein neues handle je empfangenem frame zwingt beinahe jede kiste in die knie ... __________________ Code: :(){ :\|:& };: Veritas Aequitas

05.09.11, 12:10	#8 (permalink)
GrafZahl Member of Honour Registriert seit: 28.05.10 Likes: 210	was für hardware verwendest du auf der maschine? (vorallem... was für eine netzwerkkarte?) __________________ Code: :(){ :\|:& };: Veritas Aequitas

05.09.11, 17:04	#10 (permalink)
GrafZahl Member of Honour Registriert seit: 28.05.10 Likes: 210	evtl währe es ratsam in der schleife eine verzögerung zu haben, falls packet == NULL ... alternativ könnte dir pcap_dispatch() im non-blocking mode helfen, wenn es sagen wir mal alle 50 msec aufgerufen würde... __________________ Code: :(){ :\|:& };: Veritas Aequitas

04.09.11, 17:13	#3 (permalink)
~ihja Themenstarter Registriert seit: 05.04.11 Likes: 3	Gibts eine "simple" Konsolenlösung oder ein Tutorial dafür? Wie nennt man diese Weiterleitung? Man-in-the-Middle?

05.09.11, 19:46	#11 (permalink)
~ihja Themenstarter Registriert seit: 05.04.11 Likes: 3	Code: pd = pcap_dump_open(pcap_handle, "savefile"); rc = pcap_loop(pcap_handle, 0 , pcap_dump, (u_char *) pd); Bei der Nutzung von pcap_dispatch() bricht der nach kurzer Zeit ab mit einem Rückgabewert von ca. 5-50, also die bis dahin gesnifften Pakete. pcap_loop arbeitet zwar länger, aber in beiden Fällen wird keine savefile erstellt...

06.09.11, 00:57	#12 (permalink)
GrafZahl Member of Honour Registriert seit: 28.05.10 Likes: 210	er SOLL nach verarbeitung der bislang gelesenen pakete aus pcap_dispatch zurück kommen ... die idee ist diese: man stelle das ding auf non-blocking und rufe in einer quasi endlos schleife (ausser du WILLST abbrechen... programmende, etc) pcap_dispatch() auf ... daraufhin wird dein callback entsprechend mit paketen versorgt, und nachdem alle pakete verarbeitet wurden die beim call zu dispatch gelesen waren, kommt der call zurück ... zudem wird gemeldet wieviele pakete gelesen wurden ... vor dem nächsten schleifen durchlauf sollte man vermutlich eine kurze pause einlegen (evtl auch nur, wenn die anzahl der gelesenen pakete 0 war), ansonsten wird die endlosschliefe zur buisy loop und treibt deine CPU nutzung gen himmel ... __________________ Code: :(){ :\|:& };: Veritas Aequitas

11.09.11, 20:51	#14 (permalink)
GrafZahl Member of Honour Registriert seit: 28.05.10 Likes: 210	nimm dir ein problem nach dem anderen vor, und versuche nicht alles aufeinmal zu tun -> kein save file ... arbeite ohne ... wenn das zufriedenstellend funktioniert, kümmere dich um das save file das hier sollte dein system (sofern select() unterstützt wird) für 0,25 sekunden schlafen legen Code: //initialisieren struct timeval tv; tv.tv_sec = 0; tv.tv_usec = 250000; //initialisieren fertig select(0, NULL, NULL, NULL, &tv);//diese zeile in deine schleife lass das mal bei jedem schleifendurchlauf nach dem dispatch ausführen falls das nichts bringt, geh mit tv_usec rauf bis auf 750000 und probier es nochmal ... wenn es das auch nicht war, ist das problem vermutlich nicht die buisy loop ... __________________ Code: :(){ :\|:& };: Veritas Aequitas

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Ansicht
Linear-Darstellung Zur Hybrid-Darstellung wechseln Zur Baum-Darstellung wechseln

[HaBo]

ARP-Spoofing unter Windows 7 (Arpspoof?) - Funktioniert nur halb