debianforum.de

Lohengrin hat geschrieben:War das nicht der Grund für HTTP/1.1? Wenn ein Torrent Client mehrere Sachen von demselbsen Torrent-Server holt, dann sollte der das doch auch in einer TCP-Verbindung machen.

Mehrere TCP-Verbindung zwischen demselben Client und demselben Server ist Ressourcenverschwendung. Ein Client, der sowas macht, ist böse.

Nein, auch HTTP/1.1 kann nicht parallelisieren. Lediglich mehrere Requests nacheinander über die gleiche Verbindung ziehen. Wenn die Seite nur ein Element eingebettet hat reicht das sonst kann man halt durch mehrere Verbindungen schneller werden.

Lohengrin hat geschrieben:Nochmal zu bild.de. Sind das wirklich 50 TCP-Verbindungen, oder sind das 50 "HTTP GET" in einer TCP-Vernbindung?

Ja, ich habe einfach nach syns gefiltert und gezählt wie viele das sind.

Lohengrin hat geschrieben:

wanne hat geschrieben:Was die meisten hie aber absolut nicht verstehen wollen ist, ja das dropen von Paketen braucht resourcen.

Das ist das Problem. Deswegen muss der Router die Annahme des IP-Pakets abbrechen, also nach /dev/null umleiten, sobald klar ist, dass das gedropt werden wird.

Das war ziemlich aus dem Zusammenhang gerissen.

Lohengrin hat geschrieben:

Six hat geschrieben:So läuft das nicht, die Entscheidung ist nicht routen oder droppen, sondern da wird eine strikte Reihenfolge eingehalten:
1) Wo solls hin?
2) Darf es das?

Genau diese Reihenfolge ist das Problem. Und um das zu lösen, muss man ganz tief im IP/TCP herumhacken, möglicherweise das Ding komplett neu machen.

Die Reihenfolge ist sinnvoll. Jede Firewall-Regel muss das Ziel kennen um festzustellen ob sie greift. Eine umkehrung wähhre Resourcenverschwendung. Da man für die Filter-Regeln nochmal testen müsste wohin. Es ist sinnvoll so. Und du bekommst einen Prozessor einfach nicht überlastet indem du Pakete in ne Firewall schickst.
(Wenn die Firewall nicht DPI oder ähnliches einsetzt.)
Und wie gesagt ich sehe halt einfach kein Problem.

Gunman1982 hat geschrieben:Was natürlich auch eine Möglichkeit wäre ist garkeine syn Pakete zu schicken sondern Pakete die die vollen 1500Byte Nutzlast drin haben und so tun als wären sie legitime Pakete. Ziel: Leitung verstopfen.

Das klinkt mir doch nach einem wesentlich realitätsnäheren Angriff.

Aber zum eigentlichen Thema: Ich wete was in die Richtung von meinem Vorchlag behebt das Problm.

wanne hat geschrieben:

Lohengrin hat geschrieben:War das nicht der Grund für HTTP/1.1? Wenn ein Torrent Client mehrere Sachen von demselbsen Torrent-Server holt, dann sollte der das doch auch in einer TCP-Verbindung machen.

Mehrere TCP-Verbindung zwischen demselben Client und demselben Server ist Ressourcenverschwendung. Ein Client, der sowas macht, ist böse.

Nein, auch HTTP/1.1 kann nicht parallelisieren. Lediglich mehrere Requests nacheinander über die gleiche Verbindung ziehen. Wenn die Seite nur ein Element eingebettet hat reicht das sonst kann man halt durch mehrere Verbindungen schneller werden.

Ok. Ich glaube ich habe es jetzt verstanden.
Die HTTP-Daten, die hin und her geschickt werden müssen, sind die gleichen. Wenn man das in einer TCP-Verbindung macht, hat man weniger TCP-Overhead als wenn man das in mehreren macht. Ich habe aber nicht bedacht, dass man, wenn man nur eine TCP-Verbindung verwendet, auf ein OK warten muss, um die zweite HTTP-Anfrage rauszuschicken. Da summiert sich Latenz. Um den TCP-Overhead für mehrere Verbindungen loszuwerden und gleichzeitig die Latenz loszuwerden, müsste HTTP verändert werden.
Ich habe gerede mal danach gesucht, und gefunden, dass HTTP/2.0 sich mit diesem Thema beschäftigt.

Ist das soweit richtig?

wanne hat geschrieben:

Lohengrin hat geschrieben:Nochmal zu bild.de. Sind das wirklich 50 TCP-Verbindungen, oder sind das 50 "HTTP GET" in einer TCP-Vernbindung?

Ja, ich habe einfach nach syns gefiltert und gezählt wie viele das sind.

Auweia! Du hast gewonnen.

wanne hat geschrieben:

Lohengrin hat geschrieben:

Six hat geschrieben:So läuft das nicht, die Entscheidung ist nicht routen oder droppen, sondern da wird eine strikte Reihenfolge eingehalten:
1) Wo solls hin?
2) Darf es das?

Genau diese Reihenfolge ist das Problem. Und um das zu lösen, muss man ganz tief im IP/TCP herumhacken, möglicherweise das Ding komplett neu machen.

Die Reihenfolge ist sinnvoll. Jede Firewall-Regel muss das Ziel kennen um festzustellen ob sie greift. Eine umkehrung wähhre Resourcenverschwendung. Da man für die Filter-Regeln nochmal testen müsste wohin. Es ist sinnvoll so. Und du bekommst einen Prozessor einfach nicht überlastet indem du Pakete in ne Firewall schickst.
(Wenn die Firewall nicht DPI oder ähnliches einsetzt.)

Ich dachte an ein Signal, das an das IP-Modul geschickt wird, worauf das IP-Modul das Speichern des ankommenden Pakets abbricht. Dieses Signal muss sehr schnell erzeugt werden können. Es darf nicht sein, dass erst das ganze Paket gespeichert worden ist, bevor das Signal erzeugt werden kann.

wanne hat geschrieben:Und wie gesagt ich sehe halt einfach kein Problem.

Ich will die Blockierung von Ressourcen beim von DoS Angegriffenen verringern.

Gunman1982 hat geschrieben:Was natürlich auch eine Möglichkeit wäre ist garkeine syn Pakete zu schicken sondern Pakete die die vollen 1500Byte Nutzlast drin haben und so tun als wären sie legitime Pakete. Ziel: Leitung verstopfen.

Kann ein Empfänger von unerwünschten IP-Paketen dem Router, von dem die Pakete kommen, sagen, dass er das sein lassen soll? Ein Allgemeines "Ich krieg zu viel, mach mal tucke tucke!" ist schlecht. Dann ist ja der DoS-Angriff erfolgreich. Geht so etwas auch spezifisch? Kann ein Empfänger mal eben um eine Änderung der Routing-Tabelle bitten?

Lohengrin hat geschrieben:

wanne hat geschrieben:

Lohengrin hat geschrieben:War das nicht der Grund für HTTP/1.1? Wenn ein Torrent Client mehrere Sachen von demselbsen Torrent-Server holt, dann sollte der das doch auch in einer TCP-Verbindung machen.

Mehrere TCP-Verbindung zwischen demselben Client und demselben Server ist Ressourcenverschwendung. Ein Client, der sowas macht, ist böse.

Nein, auch HTTP/1.1 kann nicht parallelisieren. Lediglich mehrere Requests nacheinander über die gleiche Verbindung ziehen. Wenn die Seite nur ein Element eingebettet hat reicht das sonst kann man halt durch mehrere Verbindungen schneller werden.

Ok. Ich glaube ich habe es jetzt verstanden.
Die HTTP-Daten, die hin und her geschickt werden müssen, sind die gleichen. Wenn man das in einer TCP-Verbindung macht, hat man weniger TCP-Overhead als wenn man das in mehreren macht. Ich habe aber nicht bedacht, dass man, wenn man nur eine TCP-Verbindung verwendet, auf ein OK warten muss, um die zweite HTTP-Anfrage rauszuschicken. Da summiert sich Latenz. Um den TCP-Overhead für mehrere Verbindungen loszuwerden und gleichzeitig die Latenz loszuwerden, müsste HTTP verändert werden.

Ich glaube, Googles Protokoll SPDY, welches von Google Chrome und neuerdings Firefox unterstützt wird, geht in diese Richtung:

http://de.wikipedia.org/wiki/SPDY

Lohengrin hat geschrieben:Kann ein Empfänger von unerwünschten IP-Paketen dem Router, von dem die Pakete kommen, sagen, dass er das sein lassen soll? Ein Allgemeines "Ich krieg zu viel, mach mal tucke tucke!" ist schlecht. Dann ist ja der DoS-Angriff erfolgreich. Geht so etwas auch spezifisch? Kann ein Empfänger mal eben um eine Änderung der Routing-Tabelle bitten?

Ja und nein. Nicht so, wie du dir das vorstellst, aber Router können static routes (z. B. null routes) an die umliegenden Hops propagieren und Router können das übernehmen. Das bringt natürlich ganz eigene Probleme mit sich und Ciscos iOS z. B. kennt deswegen sogar einen Gewichtungsparameter (administrative distance) in der path determination, der die Vertrauenswürdigkeit des propagierenden Routers misst.

getrennt....Alternativen zu TCP/IP, Routing usw. gehen hier weiter: viewtopic.php?f=30&t=137132

1. Ruhe bewahren!
2. Beweise sichern (/var/log/everything) Ganz wichtig
3. Experten hinzuziehen (Forensik, Firewall Rules etc.)
4. Fachanwalt konsultieren
Dem Gericht muss Alles nachvollziehbar dargelegt werden, um Klage zu eröffnen.

Gruß aus Spätzletown

Uli

Justizopfer und Linux Admin

… endlich, nach so vielen Jahren, schreibt’s mal jemand hin. Wozu eigentlich?

Na, er hat sieben Jahre lang Ruhe bewahrt ... *SCNR*