nicht angemeldet
Hi!
Mal ne Frage hierzu - woher weiß so ein Router ob er ein IP-Paket (z.B. einen HTTP-Response) durchleiten soll oder nicht?
Ich schmeiß mal zwei Begriffe in die Runde: Three-Way-Handshake und NAT *TABLE*. Viel Spaß mit Google. ;-)
HTTP läuft über TCP, und TCP simuliert/sichert eine permanente Verbindung, ganz ähnlich wie ein serielles Kabel.
HTTP benutzt für Request und Response eine einzige Verbindung, die (beim Surfen) vom LAN (innen) zum Internet (außen) aufgebaut wird. Du kannst von außen keinen Request faken.
Schon klar, aber Router können kein TCP udn schon gar kein HTTP also habe ich diese Ebenen außer Acht gelassen. Das problem muss sich auf IP Ebene lösen lassen, nur wie? Wie gesagt glaueb ich zu wissen dass es da so sequenzen gibt an der der Router eine "IP-Antwort" erkennt und entsprechend weiterleitet, aber eben da es auf IP Ebene läuft frage ich mich wieso das zuverlässig funktionieren soll!
wie unterscheidet er es von irgendeinem Request in welchem protokoll auch immer an so einen Port der ja nicht per Port-Forewarding weitergeleitet wird?
Der "Surf-Request" kommt von innen, die Connection-Daten (Source-IP, Source-Port, Dest-IP, Dest-Port, Translation-IPs und -Ports) werden gespeichert, bis die Connection abgebaut wird.
wie kann auf IP-Ebene eine Verbindung aufgebaut werden? IMHO gibt es doch nur auf TCP-Ebene eine echte Verbindung, oder?
Von außen kommende TCP-Verbindungen werden entweder abgelehnt oder an einen Server hinter dem Router weitergeleitet, je nach Konfiguration.
Der Router sieht doch nur ein IP-Paket mit Source IP und Dest. IP. Heißt also das Router die noch Paketfilter NAT... haben noch zusätzlich das TCP/UDP Protokoll implementiert haben.
OK, dann relativiert sich natürlich so einiges was ich geschrieben habe, hatte ich nicht dran gedacht ;-)
Aber wenn das TCP implementiert wird heitß das doch noch nicht dass der Router auch tatsächlich eine TCP Verbindung herstellt, oder? Das kann ich mir nämöoch nicht vorstelle. Ich würde vermuten dass der Router die TCP-Daten extrahieren und verstehn kann, um z.B. bestimmte Ports zu filtern, hm, aber wenn NAT funktionieren soll dann braucht er schon sowas wie eine echte TCP-Verbindung, oder er speichert die Daten irgendwie anders zwischen, er bedient sich also der Daten die seine Clients und der Host verwenden. Denn eine TCP-Verbindung ist ja eine logische Verbindung zw. 2 Rechnern, die Router dazwischen verwenden AFAIK nur das IP-Protokoll um die Daten weiterzureichen. IMHO kann der Router gar keien TCP-Verbinding aufbauen denn der Client will ja explizit eine TCP-Verbindung zu einem ganz anderen Rchner aufbauen, daher vermute ich dass der Riuter nur die Daten extrahiert und sich selbst irgendwo zwischenspeichert und kontrolliert.
ich meine IP wird ja normalerweise nicht verschlüsselt also könnte jemand ja so einen Response vortäuschen und in Wirklichkeit einen Request an einen offenen Trojaner-Port auf einem Rechner hinter dem Router leiten, oder?
Nein. Der Response kommt auf der selben Connection zurück, die schon für den Request benutzt wurde. Die Verbindung besteht bei einem Response schon, deswegen kannst Du keinen Response faken. Dem Router ist es übrigens egal, ob auf einer Connection HTTP, SSH oder sonstwas "gesprochen" wird. Der Router kümmert sich nur um Connections.
Gut, wenn ein Router TCP versteht kann er anhand der TCP-Header ja ne ganze Menge kontrollieren. Meinst Du also dass der Router dann die Aufgabe des eigentlichen Empfängers übernimmt und den TCP-Header auch tatsächlich auf entsprechende Daten wie Sequenznummer... überprüft? Würde ein Router nicht hoffnungslos überlastet wenn er wirklich wie ein echter Empfänger diese ganzen Angaben prüft?
Um gegen den von mir skizzierten Angriff gewappnet zu sein, muss der Router Daten des TCP-Requests(ich weiß hier nicht die genauen Bezeichnungen auswendig, ich nenne es jetzt einfach mal so) , und muss dann die TCP-Response mit zu erwartenden Daten vergleichen.
Aber ich frage mich ob er das überhaupt muss, denn wenn mit so einem Rsponse was nicht stimmt, sagen wir mal ich schicke dem Router ein Paket in einem Eigenen Protokoll für meinen bösen Trojaner, und packe das ganez in einen solchen TCP-Response, dann müsste doch theoretisch das Betriebssystem, wenn es eben diesen Response nicht erwartet dieses Paket verwerfen, und der Router bräuchte sich um sowas gar nicht kümmern, oder?
Hm, bin irgendwie etwas verwirrt wie man vermutlich merkt ;-)
AFAIK merkt sich ja der Router einen "IP-Request" eines seiner Clients und kann dann den "Response" entsprechend wieder zurückleiten,
Nein, Du würfelst HTTP und TCP durcheinander. Der Client baut eine TCP-Connection zum Server auf (Three-Way-Handshake), dabei verändert der NAT-Router klammheimlich die Connection-Daten in den IP-Paketen, so daß es von außen so aussieht, als käme die Connection vom Router.
Aha! Aber baut der Router jetzt wirklich eien TCP-Verbindung auf oder "fummelt" er nur ein bisschen in den Paketen rum?
also müsste bei dem von mir oben beschriebenen Vorgehen schonmal ein Request erfolgt sein auf den man dann antwortet. Oder scheitert das ganze dann endgültig beim Client da er das nicht erwartete IP-Paket verwerfen würde?
Trenne HTTP und TCP in deinem Kopf. Von außen kann ohne HTTP-Request kein HTTP-Response kommen.
Das trenne ich durchaus, die von mir fälschlicherweise verwendeten Begriffe verwirren Dich vermutlich :-)
TCP-Connections von außen werden überwiegend geblockt.
OK, ich denke ich habe es verstanden ;-) Mein Idee war es halt von außen so zu tun als ob man mitten in einer TCP-Verbindung wäre, aber vermutlich würde das dann spätestens beim Client scheitern da die TCP-Implementierung nichst mit solchen Paketen anfangen könnte, also vergiss es ;-)
Was ich jetzt noch nicht wirklich weiß - würden Router TCP-Pakete "blind" weiterleiten, oder prüfen sie tatsächlich wie der Client ob das Paket überhaupt "gültig" ist da angefordert?
Danke für die Erklärung
Grüße
Andreas