Angriffssignaturen Netzwerk 1

  • Themenstarter Themenstarter friday0D
  • Beginndatum Beginndatum
F

friday0D

Guest
Hallo zusammen,

mal angenommen Ihr seid ein Securitytool welches schon ewig denn Datenverkehr in einem LAN mitbekommt.Ihr arbeitet rein passiv. Ihr könnte euch alles merken, was den Datenverkehr betrifft, was Ihr wollt.

Wie stellt Ihr eine man-in-the-middle-attack fest, die durch arp posion routing zwischen einem LAN Teilnehmer und dem Gateway des LAN's verübt wird ?
Mich interessiert, welche Möglichkeiten Ihr seht, aber bitte keine Tools nennen sondern Merkmale an Datenpaketen/Beziehungen !
 
Indem ich erkenne, dass auf einen ARP-Request 2 Antworten kamen?

mfg benediktibk
 
Original von benediktibk
Indem ich erkenne, dass auf einen ARP-Request 2 Antworten kamen?
mfg benediktibk
Zum Vergrößern anklicken....

Ok, Wie kann es sein, dass auf einen arp request 2 Antworten kommen ?
Oder meinst Du das der Angreifer in seinem Angriffswerkzeug mit einer Timerfunktion 2 Arp Pakete mit operation code 2, zum einen an den gateway und zum anderen an den Teilnehmer sendet und mehr oder weniger gleichzeitig zwei antwortpakete kommen ?
Oder meinst Du, das der Angreifer sich unter Umständen nicht in der Form geschützt hat, dass sein System gleichermaßen auf seine "fest" gespoofte MAC Adresse antwortet ?...Dies wäre in der Tat eine Interessante Möglichkeit...Wenn der Angreifer allerdings nur ein arpPaket mit einer manuell assemblierten MAC assembliert hat, nicht.
 
Ich denke da eigentlich viel simpler. Teilnehmer werden auf einen ARP-Paket reagieren, wenn sie was wissen wollen, also zuvor einen Request auf die Reise geschickt haben. Auf den antworten dann Angreifer und Zielobjekt, im glücklichen Fall für den Angreifer dieser schneller -> gefakte ARP-Tabelle. Die zweite Antwort kommt zwar noch, wird halt unglücklicherweise für das Zielobjekt nicht mehr beachtet. Der Sniffer hat aber beide mit bekommen.

So habe ich ARP-Spoofing verstanden. Korrigiert mich bitte, falls das falsch sein sollte.
http://de.wikipedia.org/wiki/ARP-Spoofing

mfg benediktibk
 
Original von benediktibk
Ich denke da eigentlich viel simpler. Teilnehmer werden auf einen ARP-Paket reagieren, wenn sie was wissen wollen, also zuvor einen Request auf die Reise geschickt haben.

So habe ich ARP-Spoofing verstanden. Korrigiert mich bitte, falls das falsch sein sollte.
http://de.wikipedia.org/wiki/ARP-Spoofing

mfg benediktibk
Zum Vergrößern anklicken....

Das Problem ist jedoch, dass ein arp poisoning Angriff meistens nicht über arp request sondern arp replies durchgeführt wird. D.h. ob der Computer gefragt hat oder nicht, er akzeptiert die Antwort. Somit antworten im Regelfall keine systeme, sondern verschmutzen Ihren arp cache mit falschen Daten



Desweiteren wird meistens wie in dem code snippet zu sehen, die Absender MAC gefälscht, um einen "virtuellen physischen host" zu simulieren.
Also was geht hier noch ? Denkt dran Ihr seid als tool der Allmächtigkeit schon immer hier und merkt euch was Ihr wollt
 
Das Tool muss nur eine eigene IP-MAC-Tabelle führen (z.B. durch Auswertung von DHCP-Requests und -Antworten), die unabhängig vom Switch läuft und mit dieser immer wieder abgeglichen wird. Taucht eine "unangemeldete" IP oder MAC auf oder eine ist doppelt vertreten, dürfte das als Hinweis für ein ARP-Poisoning ja ausreichen.
 
Original von bitmuncher
Das Tool muss nur eine eigene IP-MAC-Tabelle führen (z.B. durch Auswertung von DHCP-Requests und -Antworten), die unabhängig vom Switch läuft und mit dieser immer wieder abgeglichen wird. Taucht eine "unangemeldete" IP oder MAC auf oder eine ist doppelt vertreten, dürfte das als Hinweis für ein ARP-Poisoning ja ausreichen.
Zum Vergrößern anklicken....

Hallo Bitmuncher,

das Tool ist jetzt schon recht mächtig: Es schaut sich dhcp requests/responses an, um zu wissen, welche dynamischen IP Adressen vom DHCP Server(hier warscheinlich der Gateway) an welche MACs vergeben werden.
Dies ist eine tolle Sache, da ich als Tool nicht lernen muss und mir dann jemand sagen muss: So ist der ist-Zustand, alles was abweicht ist bedenklich, sondern live kontrolliere.
Fortan schaut man sich also alle arp Pakete an und überprüft, ob arppakete mit opcode 2 eine gelernte senderHwAdresse+senderIPAdresse Feldwerte enthalten. Jetzt gibt's noch ein Problem. Was machen wir mit statischen IP-Adressen. Hier können wir vergeblich auf dhcp requests warten, und noch schlimmer: der gateway selbst ist statisch. Was macht das Tool für diese Fälle, bzw. welche Möglichkeiten gibt's um die unumgängliche IP-MAC Tabelle zu pflegen?
 
Wenn das Netzwerk statische IPs nicht auf bestimmte Switch-Ports bindet, ist es sowieso unsicher. Da hilft dann auch das beste Tool nichts. Ansonsten muss das Tool nur prüfen, ob erlaubte statische IPs auf den richtigen Switch-Ports antworten.

Im übrigen finde ich als Admin diese Aufgabestellung lächerlich. Es gibt keine Aussage über die Struktur des Netzwerks, über die Möglichkeiten, die die Hardware bietet, über bereits vorhandene Sicherheitsmechanismen, über das Routing-Verhalten des Gateways usw. All das spielt für eine solche "Aufgabe" aber eine Rolle. :rolleyes: Die Aufgabe krankt damit an deinem scheinbar fehlendem Wissen über Netzwerke.
 
Original von bitmuncher
Wenn das Netzwerk statische IPs nicht auf bestimmte Switch-Ports bindet, ist es sowieso unsicher. Da hilft dann auch das beste Tool nichts. Ansonsten muss das Tool nur prüfen, ob erlaubte statische IPs auf den richtigen Switch-Ports antworten.
Zum Vergrößern anklicken....

Hallo nochmal bitmuncher,

Vielen Dank für Deine Kritik.


Wenn Du einen layer 3 switch, also eine firewall mit deinem switch meist, kann man ips binden. Bei einem normalen Switch nicht, denn der arbeitet auf layer 2 und kennt keine ips. Das was Du offenbar meinst ist portsecurity, also einen macadressenfilter ?
Wenn nicht wäre aus Deiner Aussage nicht erkennbar, was Du mit ip binden meinst.
Was wolltest Du sagen ?

Original von bitmuncher
Im übrigen finde ich als Admin diese Aufgabestellung lächerlich. Es gibt keine Aussage über die Struktur des Netzwerks, über die Möglichkeiten, die die Hardware bietet, über bereits vorhandene Sicherheitsmechanismen, über das Routing-Verhalten des Gateways usw. All das spielt für eine solche "Aufgabe" aber eine Rolle. :rolleyes: Die Aufgabe krankt damit an deinem scheinbar fehlendem Wissen über Netzwerke.
Zum Vergrößern anklicken....

Eine Angriffsignatur existiert in allen definierbaren Netzwerkaufbauten. Eine genaue Beschreibung im Rahmen dieser Aufgabe ist irrelevant, da die freibleibenden Parameter eigentlich durch die Teilnehmer dieses Threads beantwortet werden sollten.
Denn interessant wäre hier, welche Netzwerklösungen allgemein, würde ein detection szenario denn in seiner Form verändern ?
[Edit] Ach und nochwas: Wenn Du meist der Einsatz von ospf hätte zum Beispiel andere Auswirkungen als rip auf das Szenario, dann beschreibe doch warum !
Das man portsecurity und ähnliches einsetzen sollte, und dann das apr sowiso nicht funktioniert wenn eine layer 2 komponente entsprechende Gegenmaßnahmen bietet, brauchst Du mir nicht zu erzählen. Und bitte unterstelle mir nicht, dass ich keine Ahnung hätte wovon ich rede, es kann sein, dass ich weniger Ahnung von Netzwerken habe als Du, aber das weiß ich nicht, und Du lieber bitmuncher weißt das auch nicht!

Falls dennoch Lösungen Ansätze zur Erweiterung des o.g. Konzeptes vorliegen, freue ich micht dennoch über Antworten.... 8)
 
Wie bereits angesporchen wenn satische IPs erlaubt sind wirds extrem schwierig - impossible.Ich denke eine Loesung waere das wir einfach mal sagen bei uns gibts kein gratuitious arp und jegliche arp replies die ohne Aufforderung gesendet werden sind halt mal verdaechtig und wenn mehr als eine daher kommt ebenso. Im prinzip haben wir in userem tool einfach eine liste mit Arp requests und sobald eine reply kommt loeschenw ir den q eintrag wieder jedesmal wenn eine reply kommt checken wir die liste bis wir einen Eintrag finden der passt wenn kein Eintrag gefunden wird dann haben wir eine potentielle Attacke. Zudem sollten wir wohl noch einen timeout einbauen wenn keine reply daher kommt.
 
Original von Ancient
Wie bereits angesporchen wenn satische IPs erlaubt sind wirds extrem schwierig - impossible.Ich denke eine Loesung waere das wir einfach mal sagen bei uns gibts kein gratuitious arp und jegliche arp replies die ohne Aufforderung gesendet werden sind halt mal verdaechtig und wenn mehr als eine daher kommt ebenso. Im prinzip haben wir in userem tool einfach eine liste mit Arp requests und sobald eine reply kommt loeschenw ir den q eintrag wieder jedesmal wenn eine reply kommt checken wir die liste bis wir einen Eintrag finden der passt wenn kein Eintrag gefunden wird dann haben wir eine potentielle Attacke. Zudem sollten wir wohl noch einen timeout einbauen wenn keine reply daher kommt.
Zum Vergrößern anklicken....

Hallo Ancient,

Deine Lösung mit der Tabelle mit requst/reply finde ich gut.
Wir machen also folgendes: Wir durchsuchen das DHCP und speichern in einer IP_MAC Tabelle welche dyn. Zuordnungen vergeben worden sind. Das bringt uns in die Lage zu wissen, welches der DHCP Server in diesem Netz ist. Wir bauen also eine Tabelle auf mit IPs und derer Funktionen. Dieser Ansatz würde uns später eine DHCP Spoothing Attacke erkennen lassen.
Zusätzlich bauen wir eine Tabelle mit Arp requestdaten auf, wir benötigen die Quell/Ziel ip.- Wenn von der Ziel ip ein reply Paket in einem Timewindow TW kommt, löschen wir den Eintrag. Wenn ein reply kommt, dem kein requst vorherging, ist das ein Indiz für ein arp poisoning. Wir halten dieses Reply Paket fest, denn wir warten auf die zweite Seite des posioning. D.h. wenn ein man-in-the-middle da ist, muss er ja beide Systeme zwischen denen er steht manipulieren. Am Ende wissen wir dann sogar wo zwischen er steht!

Weiter: Bei gratious arps können wir mit unserer DCHP_MAC Tabelle vergleichen und in eineigen Situationen hier Missstände aufdecken.
Jetzt die statischen IPs:
Sagen wir mal, die Gefahr eines mitm zwischen 2 LAN teilnehmern ist gering, da diese untereinander nichts Wichtiges zu bereden haben (so ist es ja oft). Schlimmer wäre wenn der Angriff zwischen dem Gateway und einem Teilnehmer stattfindet!
Mal angenommen, wir untersuchen jetzt jedes IP-Paket und legen mal betracht auf die SourceIP. Anhand der SourceIP können wir jetzt erkennen, das das Paket nicht aus dem LAN stammt, also über den/die Gateways gekommen sein muss. Anhand des Ethernetframes des ip-Paketes wissen wir jetzt, welche MAC Adresse(n) der/die (vielleicht router redundancy) Gateways haben. Daraus bauen wir auch eine Eth_IP_MAC Tabelle. Dadurch können wir indierekt jeden APR Angriff zwischen einem Teilnehmer und einem Gateway immer feststellen.
Oder nicht ? Weitere Ideen

Oder ziehen wir die Maschen enger: Wir sind in einem primitiven HomeLAN mit dsl router. Der dsl router verifiziert seine MAC nicht durch gratious arp. Die Teilnehmer sind Teilweise stat. oder dyn. Der router hat keinen MAC-Adressen filter. Wie könnt Ihr bei vorhandensein noch einen apr angriff unbemerkt durchführen, oder sind wir save ?
 
Das hat mit Zerreden nichts zu tun. Du stellst hier "Aufgaben", die fernab jeglicher Realität sind und grundlegende notwendige Spezifikationen missen lassen, und erwartest dann, dass man nicht darauf hinweist, dass schon die Aufgabe grundlegende Fehler enthält?

Egal welche Lösung hier genannt wird. Sie wird mit einem entsprechenden Tracefilter problemlos umgehbar sein, wenn bestimmte Bedingungen von der Hardware nicht erfüllt werden. Da spielt es keine Rolle, ob man nun die TTL prüft, ob da evtl. ein Hop zuviel drin ist, ob man MAC-IP-Tabellen hat, die unabhängig von der Switch-Hardware sind, oder ob man sämtliche Requests und Replies trackt. Deine Aufgabe ist also schlichtweg nicht lösbar, wenn das Netzwerk nicht bestimmten Anforderungen entspricht. So... bin raus, damit ich das hier ja nicht "zerrede". :rolleyes:
 
Original von friday0D

Hallo Ancient,

Deine Lösung mit der Tabelle mit requst/reply finde ich gut.
Wir machen also folgendes: Wir durchsuchen das DHCP und speichern in einer IP_MAC Tabelle welche dyn. Zuordnungen vergeben worden sind. Das bringt uns in die Lage zu wissen, welches der DHCP Server in diesem Netz ist. Wir bauen also eine Tabelle auf mit IPs und derer Funktionen. Dieser Ansatz würde uns später eine DHCP Spoothing Attacke erkennen lassen.
Zusätzlich bauen wir eine Tabelle mit Arp requestdaten auf, wir benötigen die Quell/Ziel ip.- Wenn von der Ziel ip ein reply Paket in einem Timewindow TW kommt, löschen wir den Eintrag. Wenn ein reply kommt, dem kein requst vorherging, ist das ein Indiz für ein arp poisoning. Wir halten dieses Reply Paket fest, denn wir warten auf die zweite Seite des posioning. D.h. wenn ein man-in-the-middle da ist, muss er ja beide Systeme zwischen denen er steht manipulieren. Am Ende wissen wir dann sogar wo zwischen er steht!
Zum Vergrößern anklicken....

Ja so hab ich mir das vorgestellt

Weiter: Bei gratious arps können wir mit unserer DCHP_MAC Tabelle vergleichen und in eineigen Situationen hier Missstände aufdecken.
Jetzt die statischen IPs:
Sagen wir mal, die Gefahr eines mitm zwischen 2 LAN teilnehmern ist gering, da diese untereinander nichts Wichtiges zu bereden haben (so ist es ja oft). Schlimmer wäre wenn der Angriff zwischen dem Gateway und einem Teilnehmer stattfindet!
Zum Vergrößern anklicken....

Stimmt wir sollten daher unserem tool statisch sagen was die IP<-> mac des gateways ist da sich die ja nicht aendern sollten wenn jetzt jemand eine ARP reply schickt die ein mapping fuer den gateway enthaelt und die nicht mit der fix eingestellen uebereinstimmt ist mal was nicht ganz i.o

Mal angenommen, wir untersuchen jetzt jedes IP-Paket und legen mal betracht auf die SourceIP. Anhand der SourceIP können wir jetzt erkennen, das das Paket nicht aus dem LAN stammt, also über den/die Gateways gekommen sein muss. Anhand des Ethernetframes des ip-Paketes wissen wir jetzt, welche MAC Adresse(n) der/die (vielleicht router redundancy) Gateways haben. Daraus bauen wir auch eine Eth_IP_MAC Tabelle. Dadurch können wir indierekt jeden APR Angriff zwischen einem Teilnehmer und einem Gateway immer feststellen.
Oder nicht ?
Zum Vergrößern anklicken....
Was hindert den Sender daran die source zu spoofen. Sofern wir am gateway kein ingress filtering machen um zu checken das src netz != eigenes netz kann nach herzenslust source gespoofed werden (http://www.ietf.org/rfc/rfc2827.txt)




Weitere Ideen

Oder ziehen wir die Maschen enger: Wir sind in einem primitiven HomeLAN mit dsl router. Der dsl router verifiziert seine MAC nicht durch gratious arp. Die Teilnehmer sind Teilweise stat. oder dyn. Der router hat keinen MAC-Adressen filter. Wie könnt Ihr bei vorhandensein noch einen apr angriff unbemerkt durchführen, oder sind wir save ?
Zum Vergrößern anklicken....

tjo jetzt wirds spannend aber in diesem "primitiven" netzwerk wuerde ich halt das tool auf den router selben setzen da jeglicher traffic da durch fliesst und wenn der eine arp reply mit seiner mac sieht die er selber net geschickt hat -> attacke.
 
Hallo Ancient,

mit der Fälschung des IPHeader hast Du recht. Naja da kommen wir um eine stat. Definition der Gateways nicht umhin.....hmmm!

Ich hab Deine Lösung mal umgesetzt, funktioniert wirklich!
Zufrieden ?
Auszug :
Code: 
public pvampDB DB;
        Hashtable ARPRequest = new Hashtable();
        Hashtable StaticGatewayRecord = new Hashtable();
        int request_lifetime_sec = 5;
        public pvampARPInspector(pvampDB pDB)
        {
            DB = pDB;

            StaticGatewayRecord["192.168.0.1"] =
                PhysicalAddress.Parse("000102030405");
        }
        public void putPacket(ARPPacket  P)
        {
            // delete unresolved arp requests
            ArrayList Dumps = new ArrayList();
            foreach (DictionaryEntry DE in ARPRequest)
            {
                TimeSpan TW =DateTime.Now - (DateTime)DE.Value;
                if (TW.TotalSeconds > request_lifetime_sec)
                {
                    Dumps.Add(DE.Key);
                }
            }
            foreach (string dumpPK in Dumps)
            {
                ARPRequest.Remove(dumpPK);
                Console.WriteLine("handle: arp: request " + dumpPK + 
                    " could not be resolved");
            }

            if (P.ARPOperation == (int)ARPOperations.Request)
            {
                // case selection for gratious, direct arp requst
                if (P.ARPSenderProtoAddress == P.ARPTargetProtoAddress)
                {
                    Console.WriteLine("handle: arp: gratious arp from "
                        + P.ARPSenderProtoAddress.ToString() +
                        " is at " + P.ARPSenderHwAddress.ToString());
                    // in case of gateway participation, inspect validity of phys. address
                    if (StaticGatewayRecord[P.ARPSenderProtoAddress.ToString()] != null)
                    {
                        if (StaticGatewayRecord[P.ARPSenderProtoAddress.ToString()] != 
                            P.ARPSenderHwAddress.ToString())
                        {
                            Console.WriteLine(
                                string.Format("handle: arp: arp poisoning detected (gateway)"));
                        }
                    }
                }
                else
                {
                    // direct arp
                    Console.WriteLine(string.Format("handle: arp: {0}/{1} requests the hwaddress of {2}",
                        P.ARPSenderProtoAddress.ToString(),
                        P.ARPSenderHwAddress ,
                        P.ARPTargetProtoAddress.ToString()));
                    string PK = string.Format("{0}|{1}|{2}",
                        P.ARPSenderProtoAddress.ToString(),
                        P.ARPSenderHwAddress, P.ARPTargetProtoAddress.ToString());
                    ARPRequest[PK] =DateTime.Now ;

                }
            }
            else if (P.ARPOperation == (int)ARPOperations.Reply)
            {
                Console.WriteLine(
                    string.Format("handle: arp: {0}/{1} replies the hwaddress {2} to {3}",
                        P.ARPSenderProtoAddress.ToString(),
                        P.ARPSenderHwAddress,P.ARPSenderHwAddress,
                        P.ARPTargetProtoAddress.ToString()));
                 string PK = string.Format("{0}|{1}|{2}",
                        P.ARPTargetProtoAddress.ToString(),
                        P.ARPTargetHwAddress,P.ARPSenderProtoAddress.ToString());
                 // in case of gateway participation, inspect validity of phys. address
                 if (StaticGatewayRecord[P.ARPSenderProtoAddress.ToString()] != null )
                 {
                     if (StaticGatewayRecord[P.ARPSenderProtoAddress.ToString()].ToString() != 
                         P.ARPSenderHwAddress.ToString())
                     {
                         Console.WriteLine(
                             string.Format("handle: arp: arp poisoning detected (gateway)"));
                     }
                 }
                 if (ARPRequest[PK] != null)
                 {
                     // this is ok, remove arp request
                     ARPRequest.Remove(PK);
                     Console.WriteLine("handle: arp: cleaned up " + PK );
                 }
                 else
                 {
                     // Arp poisoning detected
                     Console.WriteLine(
                         string.Format("handle: arp: {0} seems to be polluted with {1}/{2}",
                         P.ARPTargetProtoAddress.ToString(),
                         P.ARPSenderProtoAddress.ToString(),P.ARPSenderHwAddress ));
                 }
            }
        }
 
Also,

was dieses Tool ist, ein ids-sensor in rein potetischer Form. Das schöne meiner Meinung hieran ist, dass man hier Angriffsignaturen theoretisch(eigentlich aber auch sehr praktisch) schön nachvollziehen kann und lernen kann wie man sich schützt und dies 100% stichhaltig. code läßt keine Interpretationslücken.

So eine Software kann eingesetzt werden wenn:

-es keine anderen Möglichkeiten gibt Angriffe auszuschließen durch Harwaremaßnahmen und man das einfach nicht will.
- man einen geswichtes lan hat sondern einen hub als bus
- man einen Switch hat, auf dem man mirror/span ports einrchten kann, welchen den gesamten Datenverkehr des Netzes auf den Sensor spiegelt, sofern es die gesamte Datenrate zulässt!

Sollen wir weiter machen, mehr Signaturen definieren?
Wenn jemand interessiert ist, machen wir weiter......wenn keiner interessiert ist....mache ich vielleicht trotzdem weiter :D
 
Wollte nur anmerken das ich im Moment im Rahmen meiner Diplomarbeit einen IDS/IPD fuer IPv6 schreibe. Da gibts zwar kein ARP aber dafuer NDP und Autoconfig mit dem man viel Spass haben kann.

MFG
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben