Beispiel für ein gültiges UDP Paket

[Goldfalke (Gast)]

Ich quäle mich mit dem Senden über Netzwerk herum und habe auf dem 
wireshark keine Anzeige, was mein PHy abgibt. Blinken tut er, die TX-LED 
ist an und auch der switch zeigt Reaktion.

Ich brauche jetzt ein Beispiel für ein gültiges UDP-Paket mit allem drum 
und dran, dass ich hard raussenden kann, bzw das was gfs gesendet wird, 
checken kann.

Leider fehlt mir der Plan, ob ich richtig sende.

Wie komme ich da hin?

[Floh (Gast)]

Mit was willst du UDP-Pakete versenden?

[Stefan H. (Firma: dm2sh) (stefan_helmert)]

Du musst eh erst die MAC-Adresse des Empfängers wissen. Evt. musst du 
sogar erst eine ARP-Anfrage machen, dass der Switch auch diese 
MAC-Adresse lernt, wenn sie dir vom Empfänger mitgeteilt wird.

[(prx) A. K. (prx)]

Robustere Gemüter sparen sich solche Feinheiten wie gezielte 
Adressierung und verwenden die Broadcast-Adresse. ;-)

Wenn der Switch mangels MAC-Adresse in der Tabelle nicht gezielt 
forwarden kann, dann hat er die verdammte Pflicht und Schuldigkeit, den 
Frame zu broadcasten.

[Zuter (Gast)]

A. K. schrieb:
> Wenn der Switch mangels MAC-Adresse in der Tabelle nicht gezielt
> forwarden kann, dann hat er die verdammte Pflicht und Schuldigkeit, den
> Frame zu broadcasten

Was dann bei Switchen des großen Herstellers auf der CPU stattfindet, 
anstatt auf den ASICs. Und dein WLAN freut sich auch.

[(prx) A. K. (prx)]

Zuter schrieb:
> Was dann bei Switchen des großen Herstellers auf der CPU stattfindet,
> anstatt auf den ASICs.

Sicher. Aber es kommt nicht oft vor, dass solche Frames in Massen 
auftreten, ohne irgendeine Antwort, die dem Switch die Tabelle füllt. Es 
sei denn eine Komponente baut Mist. Bessere Switches erkennen das zudem 
und steuern gegen.

[Stefan H. (Firma: dm2sh) (stefan_helmert)]

A. K. schrieb:
> Wenn der Switch mangels MAC-Adresse in der Tabelle nicht gezielt
> forwarden kann, dann hat er die verdammte Pflicht und Schuldigkeit, den
> Frame zu broadcasten.

Ne, Sicherheitslücke! Er darf nur Pakete broadcasten, die auch eine 
broadcast-MAC im Ethernet-Rahmen drin haben. Das sind die ARP-Requests. 
Normale Ethernetrahmen mit eindeutiger MAC müssen verworfen werden, wenn 
sie nicht in der Tabelle sind.

Anstonsten gibt es einen Angriff. Ein PC wechselt ganz schnell die 
MAC-Adresse und sendet ARP-Requests aus. Die Tabelle füllt sich und 
läuft schließlich über. Dadurch werden alte Einträge gelöscht. Rahmen an 
dieses Adressen werden dann gebroadcastet und du kannst sie 
mitschneiden. Evtl. dann auswerten, verändern, MAC spoofen und wieder 
einspeisen...

[(prx) A. K. (prx)]

Seit wann gibts auf dieser Ebene routinemässig Sicherheitskriterien? 
Ethernet war vor dem Einsatz von Switches ein reines Broadcast-Medium. 
Da konnte jeder nach Belieben mithören, auch in Hubs war das nicht 
anders.

Du willst abhören oder stören? Nichts leichter als das: MAC-Adresse 
faken und irgendwas senden. Schon landen die Frames bei dir, bis der 
eigentliche Adressat auch mal wieder von sich hören lässt.

Wer sich auf dieser Ebene auf Sicherheit verlässt, der hat verloren.

Es gibt auch Protokolle ohne irgendeine Version von ARP. Welche, in 
denen die MAC-Adresse als Ziel direkt angegeben wird. SNA 
beispielsweise.

Folgendes Szenario: Switch wird neu gestartet oder löscht die Tabelle 
bei Überlauf oder ... PC hat Adresse noch im ARP. Muss der jetzt den 
ARP-Timeout abwarten, bis die Kommunikation wieder läuft? Nope. Der 
Switch muss sich so verhalten, als wär er ein gelbes Kabel.

Apropos Sicherheit: Einen kleinen Spass habe ich mal bei einem Switch 
erlebt. Der hatte VLANs rein auf Broadcast-Ebene implementiert. Ein ARP 
blieb dashalb im VLAN. Wenn man allerdings die Ziel-MAC schon kannte 
(ARP manuell) und die der Switch-Engine bekannt war, dann waren dem die 
verschiedenen VLANs völlig egal. Man konnte problemlos über die Grenze 
eines VLANs kommunizieren. Wär interessant, bei welchen Geräten sowas 
auch heute noch geht.

[Hans Ulli K. (Gast)]

Wenn beim Switch die MAC Tabelle "überlauf" wird er zum einfachen HUB, 
jedenfalls bei den billigen Dingern

Siehe  auch hier
http://hakipedia.com/index.php/CAM_Table_Overflow

Für das Senden von UDP Pakten kannst du netcat nehmen

[Simon K. (simon)]

Stefan Helmert schrieb:
> A. K. schrieb:
>> Wenn der Switch mangels MAC-Adresse in der Tabelle nicht gezielt
>> forwarden kann, dann hat er die verdammte Pflicht und Schuldigkeit, den
>> Frame zu broadcasten.
>
> Ne, Sicherheitslücke! Er darf nur Pakete broadcasten, die auch eine
> broadcast-MAC im Ethernet-Rahmen drin haben. Das sind die ARP-Requests.
> Normale Ethernetrahmen mit eindeutiger MAC müssen verworfen werden, wenn
> sie nicht in der Tabelle sind.

Heute ist wieder ein Tag wo viel Quatsch und Unsinn über Ethernet und Co 
hier gepostet wurde, hab ich das Gefühl. Das stimmt so einfach nicht. 
Die Pakete dürfen nicht gedroppt werden.

http://de.wikipedia.org/wiki/Switch_(Computertechnik)#Funktionsweise
----
Der Switch zeichnet in einer Tabelle auf, welche Station über welchen 
Port erreicht werden kann. Hierzu werden im laufenden Betrieb die 
Absender-MAC-Adressen der durchgeleiteten Pakete gespeichert. So werden 
Daten nur an den Port weitergeleitet, an dem sich tatsächlich der 
Empfänger befindet, wodurch Spionage durch Nutzung des Promiscuous Mode 
der Netzwerkkarte verhindert wird, wie sie bei Netzwerken mit Hubs noch 
möglich war. Pakete mit (noch) unbekannter Ziel-MAC-Adresse werden wie 
Broadcasts behandelt und an alle Ports mit Ausnahme des Quellports 
weitergeleitet.
----

[Ingenieur (Gast)]

Meines Erachtens würde es auch reichen, einfach eine unbekannte MAC zu 
zu nutzen, weil sie als broad cast läuft. Andererseits sollte der TE die 
MAC seines Zielrechners ja kennen.

Ein gültiges UDP-Paket ist letztlich abhängig von den Inhalten, weil der 
CRC gebildet werden muss. Damit sind neben den Daten auch die Ziel-MAc 
relevant (soweit ich weiss).

Du musst also wissen, wie die Ziel-MAC aussieht, um zu einem gültigen 
Paket zu kommen.

Oder Du schneidest eine wenig Kommunikation auf dem Netzwerk mit und 
wiederholst sie.

[(prx) A. K. (prx)]

Ingenieur schrieb:
> Ein gültiges UDP-Paket ist letztlich abhängig von den Inhalten, weil der
> CRC gebildet werden muss.

Die CRC vom Ethernet-Frame berechnet der Adapter. Die UDP-Checksum (das 
ist keine CRC) ist in IPv4 optional. Anfangs fährt man besser ohne 
Checksum, denn deren Erzeugung ist etwas eigenwillig.

> Du musst also wissen, wie die Ziel-MAC aussieht, um zu einem gültigen
> Paket zu kommen.

Insbesondere muss er sie kennen, damit der Frame gezielt ankommt und vom 
Empfänger auch angenommen wird. Wenn er keine Broadcast-Adresse 
verwendet.

[Martin B. (martin_b97)]

Probier mal http://packeth.sourceforge.net/sourceforge/Home.html

Damit kann man alle möglichen Ethernet-Pakete basteln und verschicken.

Grüsse,
Martin