Netzwerklasten erzeugen (Studienarbeit)

FlopTazer

Cadet
Mitglied seit
23.03.2017
Beiträge
5
Renomée
0
Hi,

ich sitze momentan an meiner Studienarbeit und schreibe über Netzwerklasten.

Dazu habe ich mir ein eigenes Testnetzwerk aufgebaut und probiere nun Lasten zu erzeugen und das Testnetzwerk zu lähmen(DoS).
Ich habe die Last bisher über erzeugte ARP-Requests hergestellt. Da meine Überlegung war, dass das Netzwerk diese Request unter den Teilnehmern weitergibt und somit machen die Teilnehmer des Netzwerks sich selbst das Leben schwer.
Diesen Gedanken finde ich allerdings nirgends im Internet und ich frage mich warum?
Ist der Gedanke vll einfach dumm, weil die ARP-Request-Weitergabe schnell von Programmen unterbunden werden kann oder hab ich einen Denkfehler gemacht?

Im Netz wird eher über UDP-Flooding gesprochen, wobei ich dort nicht verstehe warum man UDP benutzt, denn der Empfänger muss da ja nichtmal antworten, sondern wird nur zu geballert von den UDP-Paketen. Das führt auch zu einer Lähmung aber nur durch die deutlich höhere Paketanzahl oder?

Ich hoffe Ihr könnt mir helfen :)

Vielen Dank schonmal :)
 
Es kommt drauf an, welche Art von DoS Du gegen das Netz fahren willst. Willst Du die Host CPUs der angeschlossenen Geräte überlasten oder willst Du die einzelnen Netzwerklinks zwischen den Switchen/Routern überlasten?

Wenn Du von ARP und UDP sprichst, dann geht es Dir vermutlich darum, die Host CPUs zu überlasten und nicht zwingend um eine Überlastung des Netzwerks selbst, oder?
 
ARP funktioniert nur in einer Broadcastdomäne und diese vorraussetzung ist im Internet normalerweise nicht gegeben.
UPD kennt keinen Verbindungsauf/abbau(im gegensatz zu TCP), ist daher einfacher zu misbrauchen
 
Erstmal Danke für die Antworten.

@Ulgorash deine Antwort hat mir sehr geholfen und zum weiterdenken angeregt :)
Ich muss ja definitiv zwischen dem überlasten der CPU und dem überlasten des Links unterscheiden. Und da das Switching meist auf Hardwareebene passiert wäre es klüger lediglich die Links zu fluten statt die CPU zu überlasten.

@binary du hast natürlich recht! Die meisten DoS Attacken richten sich ja, anders als bei mir, gegen fremde Server und Netzwerkteilnehmer. Da ich von einem privaten Netz spreche wäre es bei mir allerdings auch gut möglich eine ARP Flood zu benutzen!

Nochmals vielen Dank an euch :)
 
Wäre aber vom Angreifer ziemlich dämlich da dieser sehr schnell identifiziert werden kann.

Bei externen DoS oder DDoS Angriffen steckt ja auch nicht nur 1 Host dahinter
 
@Ulgorash deine Antwort hat mir sehr geholfen und zum weiterdenken angeregt :)
Ich muss ja definitiv zwischen dem überlasten der CPU und dem überlasten des Links unterscheiden. Und da das Switching meist auf Hardwareebene passiert wäre es klüger lediglich die Links zu fluten statt die CPU zu überlasten.

Gern geschehen. Es ist aktuell auch tatsächlich einfacher, einen Link zu fluten als eine CPU zu überlasten - zumindest wenn Du es auf aktuelle x86 CPUs abgesehen hast.

Um für eine ordentliche Linkauslastung zu sorgen, schickst Du am Besten maximal große Ethernet Frames mit einem Paketgenerator ins Netz. Sofern Du keinen Zugriff auf einen echten Wirespeed Generator hast wie z.B. einen Ixia (die Dinger sind recht teuer) tut es auch ein halbwegs aktueller Rechner mit Linux und Packeth. Mit einem älteren Core i7 in einem Notebook schaffe ich es z.B. ganz gut, einen 1 Gbit/s Link voll zu bekommen. Allerdings musst Du maximal große Frames schicken (1518 bzw. 1522 Byte, einfach das Frame mit Padding vollschreiben) und die mit einem VLAN Tag versehen. Als VLAN Prio schreibst Du immer die 7 in das Prio-Feld. Als Destination Address kannst Du eine beliebige Multicast Adresse nehmen, Source ist eigentlich egal. So wird der Störverkehr in einem Switch immer in die höchste Priority Queue eingeordnet und normaler Best Effort Verkehr kommt quasi nicht zum Zug. Durch die Multicastadresse wird das Frame immer an allen Ports geflutet. Sofern Du keinen Multicastfilter irgendwo konfiguriert oder eine erweiterte Queueverwaltung irgendwo konfiguriert hast, kannst Du damit das Netz bestens lahmlegen.

Wenn Du Das Netz ungesteuert lahmlegen willst, dann kannst Du auch einfach (R)STP auf einem Switch deaktivieren, falls vorhanden, und einen Loop stecken. ;)
 
Im Moment erzeuge ich meine Netzwerkpakete mit dem Colasoft Paket Builder und lade Sie dann auf einen "Ethernet Generator". Der Ethernet Generator speißt mir die Pakete dann mit Wahnsinniger Geschwindigkeit ins Netz ein(Muss nochmal genau nachmessen sind aber grob 140.000 Pakete/s).
Colasoft selbst eignet sich nicht zum direkten "einspeisen". Zu langsam.
Aber deshalb Danke für die Idee mit Packeth über Linux.

Die bevorzugte maximale Framelänge liegt wohl daran, dass noch mehr "Verdrängung" der Pakete stattfindet oder?

Die Idee mit dem VLAN Tag werde ich mir auch nochmal anschauen. Klingt nämlich gut :)

Das Netzwerk ungesteuert lahmlegen über die Abschaltung von RSTP klappt bei mir nicht, da mein Testaufbau sowohl RSTP als auch MRP benutzt.
 
Im Moment erzeuge ich meine Netzwerkpakete mit dem Colasoft Paket Builder und lade Sie dann auf einen "Ethernet Generator". Der Ethernet Generator speißt mir die Pakete dann mit Wahnsinniger Geschwindigkeit ins Netz ein(Muss nochmal genau nachmessen sind aber grob 140.000 Pakete/s).
Colasoft selbst eignet sich nicht zum direkten "einspeisen". Zu langsam.
Aber deshalb Danke für die Idee mit Packeth über Linux.

NP, "packeth" ist nur eine Notlösung - wenn Du einen Paketgenerator hast, der das in Hardware macht nimmst Du natürlich den.

Die bevorzugte maximale Framelänge liegt wohl daran, dass noch mehr "Verdrängung" der Pakete stattfindet oder?
Das liegt eigentlich eher daran, das man bei einer Softwarelösung wie packeth in der maximalen Senderate (Pakete/s) durch die CPU limitiert ist. D.h. um einen Link voll zu kriegen ist es besser, große Pakete zu senden. Wenn Du einen HW Generator hast, ist es egal. Der kriegt die Leitung mit großen und kleinen Paketen voll.

Die Idee mit dem VLAN Tag werde ich mir auch nochmal anschauen. Klingt nämlich gut :)
Das "hilft" natürlich nur, wenn Du Switche einsetzt, die VLAN Prioritäten beachten. Aber das ist heutzutage eig. üblich, sogar bei unmanaged Switches.

Das Netzwerk ungesteuert lahmlegen über die Abschaltung von RSTP klappt bei mir nicht, da mein Testaufbau sowohl RSTP als auch MRP benutzt.
Okay - falls Du die Redundanzprotokolle direkt angreifen willst: Da kannst Du Dir die ein oder andere Protokolleigenheit nutzbar machen. Bei RSTP ist es eine feine Sache, den TxHoldCount mit Fake BPDUs zu füllen und danach einen echten Topology Change auszulösen. Bei MRP hilft jede Menge Querverkehr an möglichst vielen Switchen im Ring mit VLAN Prio 7. Wenn Du hier Details brauchst, schreib' mich per PM an.
 
Zurück
Oben Unten