Für einige private Zwecke muss ich den HTTP-Header mit zusätzlichen Informationen anreichern (die von der App auf der HTTP-Serverseite verarbeitet werden). Die Grundidee bestand darin, das empfangene Paket zu ändern, es an das Ziel zu senden und sich nie um die Antwort zu kümmern. Das sehr vereinfachte Schema der Verkehrspfade ist
+---+ +------+ +---+
| +<<-----o MDFY +<<------o |
| R | +------+ | S |
| C | | N |
| V | | D |
| o--------------------->>+ |
+---+ +---+
Das Problem betrifft die TCP SEQ/ACK-Nummern. Nach dem TCP-Handshake sendet der Sender ein Paket mit einer Länge von 4 Bytes, das zum Modifikator gelangt, wo die Länge auf 22 geändert wird. Dann kommt das Paket beim Empfänger an und dieser sendet die ACK-Nummer +23, während der Sender +5 erwartet. Das verwirrt den Sender und die Sitzung wird nicht mehr synchronisiert. Ich sehe das beispielsweise, wenn ich netcat zum Testen ausprobiere – bei unveränderten Paketen wird die Sitzung sofort nach dem Datenaustausch geschlossen, während bei geänderten Paketen die Sitzung lange Zeit inaktiv bleibt (eigentlich stoppe ich sie durch Drücken von Strg-C).
Ich sehe keine einfache Möglichkeit, mit dieser Situation umzugehen. Es sieht so aus, als ob nach einer Änderung in der Mitte die gesamte Sitzung vom Modifizierer gehandhabt werden muss, da der Absender nichts über die Änderung der Sequenznummer weiß und sich auf seine eigenen Nummern verlässt. Dies würde sowohl die Leistung erheblich beeinträchtigen als auch die Komplexität erhöhen, da ich den Status jeder Sitzung aufrechterhalten und jedes von beiden Seiten kommende Paket ändern muss, um die SEQ/ACK-Nummern beizubehalten.
Vielleicht sehe ich keine andere Möglichkeit, als meine eigenen DPI zu schreiben? :-) Ich bin für alle Kenntnisse, Ideen und Vorschläge dankbar.
Danke schön.
Antwort1
Die einzige einfachere Option, die ich sehe, ist die Verwendung eines transparenten Proxys.
In diesem Fall sendet der Client die Anfrage an den Zielserver. Der Proxyserver erfasst die Anfrage, fügt den Header hinzu und erstellt eine weitere Anfrage an den Zielserver. Der Zielserver gibt die Antwort an den Proxy zurück, der sie dann an den Client zurücksendet.
Der Nachteil hierbei ist, dass der Server nicht die ursprüngliche IP-Adresse des Clients sieht, sondern die IP-Adresse des Proxys.
Für den MITM-Ansatz auf TCP-Ebene existieren möglicherweise Toolkits, die die erforderliche Funktionalität implementieren, sodass keine vollständige Implementierung erforderlich ist.
Antwort2
Dies sieht aus wie eine Art halbfertiges NAT; und das Problem liegt genau darin, dass es nur halbfertig ist.
Sie können nicht nur eine Richtung eines TCP-Paketflusses mit MITM steuern: Sie müssen beide Flüsse handhaben, um Situationen wie diese zu handhaben (Standard-NAT kümmert sich normalerweise nur um Quell- und Zieladressen/-Ports, aber das Prinzip ist dasselbe; wenn Sie Pakete während der Übertragung manipulieren möchten und diese Manipulation für beide Endpunkte transparent sein soll, müssen SieallesRechts).
Wenn Sie anfangen, alles zu berücksichtigen, verfügen Sie schon bald über ein vollwertiges NAT: Sie müssen das Rad dann nicht neu erfinden, es gibt zahlreiche Implementierungen, mit denen Sie Pakete nach Wunsch verstümmeln können.
Die tatsächlich verfügbaren Optionen hängen natürlich vom verwendeten Betriebssystem und der Routing-/Firewall-Software ab.