| (In)security allgemein Sicherheit, Anonymität im Netz. Schutz und Maßnahmen. Prävention und Konzepte. Sicherheitsarchitekturen allgemein und auf der Netzwerkebene. |
Diskussion: Angriffssignaturen Netzwerk 1 im Forum (In)security allgemein, in der Kategorie Security Area; Hallo zusammen, mal angenommen Ihr seid ein Securitytool welches schon ewig denn Datenverkehr in einem LAN mitbekommt.Ihr arbeitet rein passiv. ...
![]() |
| | #1 (permalink) |
| Guest Likes: | 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 ! |
|
| | #2 (permalink) |
| Registriert seit: 03.05.07 ![]() Likes: 17 | Indem ich erkenne, dass auf einen ARP-Request 2 Antworten kamen? mfg benediktibk
__________________ The essential prerequisite for building an expert system is to have an expert. - Frederick P. Brooks, Junior |
| | |
| HaBOT | |
| |
| | #3 (permalink) | |
| Guest Likes: | Zitat:
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. | |
|
| | #4 (permalink) |
| Registriert seit: 03.05.07 ![]() Likes: 17 | 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
__________________ The essential prerequisite for building an expert system is to have an expert. - Frederick P. Brooks, Junior |
| | |
| | #5 (permalink) | |
| Guest Likes: | Zitat:
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 | |
|
| | #6 (permalink) |
| Moderator ![]() Registriert seit: 30.09.06 ![]() ![]() ![]() ![]() ![]() ![]() Likes: 371 | 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.
__________________ Mein Blog - Mein Job - Diaspora Der Ring uns zu knechten besteht aus 12 Sternen auf blauem Grund. Neue Beiträge im Habo via Twitter - Das HaBo auf FB - Das HaBo bei G+ |
| | |
| | #7 (permalink) | |
| Guest Likes: | Zitat:
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? | |
|
| | #8 (permalink) |
| Moderator ![]() Registriert seit: 30.09.06 ![]() ![]() ![]() ![]() ![]() ![]() Likes: 371 | 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. Die Aufgabe krankt damit an deinem scheinbar fehlendem Wissen über Netzwerke.
__________________ Mein Blog - Mein Job - Diaspora Der Ring uns zu knechten besteht aus 12 Sternen auf blauem Grund. Neue Beiträge im Habo via Twitter - Das HaBo auf FB - Das HaBo bei G+ |
| | |
| | #9 (permalink) | ||
| Guest Likes: | Zitat:
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 ? Zitat:
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.... | ||
|
| | #10 (permalink) |
| 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. | |
| | |
| | #11 (permalink) | |
| Guest Likes: | Zitat:
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 ? | |
|
| | #12 (permalink) |
| Moderator ![]() Registriert seit: 30.09.06 ![]() ![]() ![]() ![]() ![]() ![]() Likes: 371 | 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".
__________________ Mein Blog - Mein Job - Diaspora Der Ring uns zu knechten besteht aus 12 Sternen auf blauem Grund. Neue Beiträge im Habo via Twitter - Das HaBo auf FB - Das HaBo bei G+ |
| | |
| | #13 (permalink) | ||||
| Zitat:
Zitat:
Zitat:
Zitat:
| |||||
| | |
| | #14 (permalink) |
| Guest Likes: | 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 ));
}
}
} |
|
![]() |
| | |
| |
| Themen-Optionen | |
| Ansicht | |
| |
Ähnliche Themen | ||||
| Thema | Autor | Forum | Antworten | Letzter Beitrag |
| [XP im Netzwerk] PC(s) im Netzwerk herunterfahren? | -Supernova- | Windows | 8 | 23.02.06 16:03 |
| Mit C im Netzwerk... | the-8 | Windows | 5 | 30.09.04 22:13 |
| Netzwerk | smitti | Network · LAN, WAN, Firewalls | 8 | 04.08.04 13:05 |
| netzwerk | dj179132 | Hardware Probleme | 5 | 02.06.03 19:15 |
| Netzwerk | Spacewolf | Die Problemzone | 5 | 05.08.02 10:21 |