Gefahr von Exploits "rückwärts" in ausgehende TCP-Verbindungen

Question

Ich baue eine Server-Anwendung, die Verbindungen zu anderen Anwendungen durch Auslösen von TCP-Verbindungen über eine Firewall, die nur für ausgehenden Datenverkehr zu den entsprechenden IP-Ports der Anwendung geöffnet ist verbunden mit.

Was ist das Risiko, dass jemand die Maschine (n) übernommen hat, die wir verbinden, um unsere Anwendung durch die von uns hergestellte ausgehende Verbindung rückwärts ausnutzen zu können.

Das auf der Verbindung verwendete Protokoll ist nicht schwer herauszufinden, aber es basiert auf einem periodischen Herzschlag (Intervall 30 Sekunden). Wenn zwei aufeinander folgende Herzschläge verpasst werden, beendet der Initiator (us) die Verbindung und verbindet sich erneut.

Der Quellcode oder die Binärdateien für unsere Anwendung sind für die Orgination, mit der wir uns verbinden, nicht verfügbar.

Answer 1

Wenn Sie Ihre eigenen Anwendungsserver für alle eingehenden Daten nicht hört, dann gibt es nur sehr wenig Risiko

Answer 2

Sie können nichts tun Sie außer Ihrem Protokoll zu Ihnen zu sprechen. Das Risiko besteht darin, dass alles, was von Ihrem Ende bis zu Ihrem Ende mit Ihrem Protokoll getan werden kann, getan wird.

N.B. Ich meine nicht, dass sie eine wohlgeformte Version Ihres Protokolls zu Ihnen sprechen müssen. Wenn Ihr System eingehende Nachrichten mit fgets() in einen statischen Puffer liest, sind "Pufferüberläufe" Teil dessen, was Sie mit Ihrem Protokoll tun können.

Answer 3

Es ist für einen Angreifer einfach, den Netzwerkverkehr auf Ihrem Server zu erkennen, wenn er Zugriff auf den Computer oder das Netzwerk hat, mit dem Sie eine Verbindung herstellen. Dies könnte es ihm ermöglichen, Ihr Protokoll zurück zu entwickeln und dann entweder schädliche Daten in die Daten zu injizieren, die zurück zu Ihrem Server gehen, oder die clientseitige Anwendung vollständig zu ersetzen.

Da es sich anhört, als ob man der Client-seitigen Anwendung nicht trauen kann, spielt es keine Rolle, wer die Verbindung initiiert, sobald es abgelaufen ist, haben Sie einen bidirektionalen Kommunikationskanal. In diesem Fall empfiehlt es sich, alle vom Client eingehenden Daten zu überprüfen.

Wenn Sie dem Client, aber nicht dem Netzwerk vertrauen können, hilft das Hinzufügen einer Verschlüsselung zu Ihrem Netzwerkprotokoll.

Answer 4

Ihr Szenario ist ziemlich weit verbreitet, es ist sehr selten ein Netzwerk zu haben, das vollständig vom Internet isoliert ist. Berücksichtigen Sie die folgenden Faktoren:

• Dritte können Info-In basierend auf dem Protokoll unterstützen. Es ist eine ziemlich verlorene Schlacht, da man sich auf nichts verlassen kann, was sie komplett blockieren würde. Siehe unten.
• Wenn Sie sicherstellen möchten, dass die Informationen von der richtigen dritten Partei stammen, benötigen Sie unterschriebene Informationen. Einige höhere Protokolle können dies für Sie tun. Sie sind anfällig für Schwachstellen in der Implementierung, aber wenn das Protokoll es unterstützt, wird Ihr eigener Wille kaum weniger anfällig sein.
• Wenn Sie sicherstellen möchten, dass die Informationen privat sind, benötigen Sie eine Verschlüsselung. Einige höhere Protokolle können dies für Sie tun. Die gleichen Kommentare wie oben gelten.
• Sie sind in den verwendeten Protokollen der unteren Ebene (implizit oder explizit) einer Sicherheitslücke ausgesetzt. Es ist sowohl unmöglich als auch unpraktisch, alles selbst zu machen, und wenn Sie dies tun, werden Sie wahrscheinlich Schwachstellen einführen. Stellen Sie sicher, dass Sie die neuesten Patches haben.