Ok, ich weiß, diese Situation ist etwas ungewöhnlich, aber ich muss eine TCP-Verbindung (der 3-Wege-Handshake) nur mit rohen Sockets (in C, in Linux) einrichten - dh ich muss Konstruiere die IP-Header und TCP-Header selbst. Ich schreibe einen Server (also muss ich zuerst auf das eingehende SYN-Paket antworten), und aus welchem Grund auch immer, ich kann es scheinbar nicht richtig machen. Ja, ich weiß, dass ein SOCK_STREAM das für mich erledigen wird, aber aus Gründen, auf die ich nicht eingehen möchte, ist das keine Option.TCP-Handshake mit SOCK_RAW-Socket
Die Tutorials, die ich online bei der Verwendung von Raw-Sockets gefunden habe, beschreiben, wie man einen SYN flooder baut, aber das ist etwas einfacher als eine TCP-Verbindung aufzubauen, da man keine Antwort basierend auf dem Original erstellen muss Paket. Ich habe die SYN flooder Beispiele funktioniert, und ich kann das eingehende SYN-Paket gut aus dem Raw-Socket lesen, aber ich habe immer noch Probleme beim Erstellen einer gültigen SYN/ACK-Antwort auf ein eingehendes SYN vom Client.
Also, kennt jemand eine gute Anleitung zur Verwendung von Raw-Sockets, die über das Erstellen eines SYN-Flooders hinausgeht, oder hat jemand irgendeinen Code, der dies tun könnte (mit SOCK_RAW und nicht SOCK_STREAM)? Ich wäre sehr dankbar.
MarkR ist absolut richtig - das Problem ist, dass die Kernel-Reset-Pakete in Reaktion auf das erste Paket sendet, weil es der Hafen denkt geschlossen ist. Der Kernel schlägt mich auf die Antwort und die Verbindung stirbt. Ich benutzte tcpdump, um die Verbindung bereits zu überwachen - ich hätte aufmerksamer sein sollen und gemerkt haben, dass es ZWEI Antworten gab, von denen eine ein Reset war, der die Dinge durcheinander brachte, sowie die Antwort, die mein Programm erzeugte. D'OH!
Die Lösung, die am besten funktioniert, ist die Verwendung einer iptables-Regel, wie von MarkR vorgeschlagen, um die ausgehenden Pakete zu blockieren. Es gibt jedoch einen einfacheren Weg als die Verwendung der Markierungsoption, wie vorgeschlagen. Ich stimme nur überein, ob das Reset-TCP-Flag gesetzt ist. Im Verlauf einer normalen Verbindung wird dies wahrscheinlich nicht benötigt, und es ist für meine Anwendung nicht wirklich wichtig, wenn ich alle ausgehenden Reset-Pakete von dem verwendeten Port sperre. Dies blockiert effektiv die unerwünschte Antwort des Kernels, aber nicht meine eigenen Pakete. Wenn der Port mein Programm auf zuhört 9999 ist dann sieht das iptables-Regel wie folgt aus:
iptables -t filter -I OUTPUT -p tcp --sport 9999 --tcp-flags RST RST -j DROP
Ich weiß, es ist 4 Jahre alt Frage, aber Ihr Vorschlag sieht ziemlich interessant, so entschied ich, Sie um Klärung bitten. Die Frage ist: Gibt es ein Problem mit dem Router beim Routing Antwortpaket zu bestimmten Computer mit falschen MAC-Adresse des Geräts? Wird das Paket jetzt von einer Firewall oder einem Antivirenprogramm gefiltert? –
Eine gefälschte MAC-Adresse kann von Switches gefiltert werden, wenn sie für die Portsicherheit konfiguriert sind. Möglicherweise gibt es ACLs auf der MAC-Ebene, aber normalerweise hindert Sie nichts daran, MACs zu spoofen. Sie müssen nur sicherstellen, dass Ihre Netzwerkkarte Antworten auf diesen gefälschten Mac akzeptiert (indem Sie den Mac zur Tabelle der akzeptierten Pakete hinzufügen oder indem Sie ihn in den Promisc-Modus setzen). Dies ist eine schlechte Idee, dies zu tun, wenn Sie nicht autorisiert sind. – eckes