Port Forwarding - Sicherheitsaspekte

[CKid]

Hallo,

gegeben sei ein kleines Heimnetzwerk mit Anbindung nach draußen über einen Router. Auf dem Router ist Port Forwarding zu einem PC aktiviert, welches Betriebssystem läuft ist eher zweitrangig für die Fragestellung.

Inwiefern stellt das PF eigentlich ein Risiko für das OS dar, abgesehen von eventuellen Fehlern in der adressierten Anwendung selbst?

Könnte ein Angreifer z.B. auf eine Funktion im Betriebssystem zielen, die "tief" verankert ist und die ohne PF nicht so ohne weiteres erreichbar wäre? Er könnte doch z.B. ein Datenpaket senden, das einen fehlerhaften TCP/IP-Stack angreift?

Oder läuft ein Paket grundsätzlich ins Leere, wenn am entprechenden Port nichts lauscht?

Dass es grundsätzlich sicherer ist, wenn kein Port nach außen hin sichtbar wäre ist klar (Port Scanning).

Sorry für die möglicherweise Newbie-Frage.

 

[zabelhaft]

interessiert mich aber jetzt auch, hab ich mir noch nie wirklich Gedanken drüber gemacht

 

[CKid]

Nur zum Verständnis: Mit "Oder läuft ein Paket grundsätzlich ins Leere, wenn am entprechenden Port nichts lauscht?" meinte ich den Fall, in dem die Anwendung nicht läuft. Habe den Text einige Male umgeschrieben.

 

[jraf]

Natürlich ist das Sicherheitsrisiko schon abhängig vom Betriebssystem dahinter Aber erstmal ist natürlich auch entscheidend, wie der Router arbeitet sowie ob und welche Firewall vorhanden ist.

Wenn wir mal von 0815 Standardkomponenten ausgehen, leitet ein konfiguriertes Port Forwarding erstmal jede Anfrage, die auf diesem Port reinkommt an den entsprechenden PC weiter.

Wenn am anderen Ende nichts auf diesem Port lauscht sollte das Paket verworfen werden. Man sollte allerdings beachten, dass man über einen beliebigen Port auch Dienste tunneln kann. Es empfiehlt sich generell für die Aussenwelt keine Standardports freizugeben.

 

[CKid]

Gehen wir davon aus, dass keine Firewall vorhanden ist, weder auf dem Router noch auf dem PC, noch davor oder dazwischen.

Du schreibst das Paket wird verworfen, wenn nichts lauscht. Impliziert das nicht, dass der TCP/IP-Stack, oder wie immer die Betriebssystemkomponente heißt die dafür zuständig ist, grundsätzlich erst mal abarbeitet was da ankommt?

Und ist damit nicht schon eine Angriffsfläche vorhanden?

Ich will darauf hinaus: Wenn jemand ein (bösartig) manipuliertes Datenpaket schickt welche auf die TCP/IP-Komponente des Betriebssystems zielt, dann bietet es mir keine Sicherheitsgewinn, wenn ich aus Faulheit den Port offen lasse aber die Anwendung schließe um nicht jedes Mal den Router neu konfigurieren zu müssen.

Mittlerweile habe ich auch herausgefunden, dass sog. Port Triggering einen (vermeintlichen?) Sicherheitsvorteil ggü. PF darstellen könnte, da hier der Port nur geöffnet wird, wenn die Anwendung auf dem PC die Verbindung initiiert und ihn nach Ablauf einer zeitlichen Frist wieder schließt.

 

[jraf]

Impliziert das nicht, dass der TCP/IP-Stack, oder wie immer die Betriebssystemkomponente heißt die dafür zuständig ist, grundsätzlich erst mal abarbeitet was da ankommt?

Und ist damit nicht schon eine Angriffsfläche vorhanden?

Ja, vollkommen richtig.

Ich will darauf hinaus: Wenn jemand ein (bösartig) manipuliertes Datenpaket schickt welche auf die TCP/IP-Komponente des Betriebssystems zielt, dann bietet es mir keine Sicherheitsgewinn, wenn ich aus Faulheit den Port offen lasse aber die Anwendung schließe um nicht jedes Mal den Router neu konfigurieren zu müssen.

Nur eine leistungsfähige Firewall kann hier helfen

Mittlerweile habe ich auch herausgefunden, dass sog. Port Triggering einen (vermeintlichen?) Sicherheitsvorteil ggü. PF darstellen könnte, da hier der Port nur geöffnet wird, wenn die Anwendung auf dem PC die Verbindung initiiert und ihn nach Ablauf einer zeitlichen Frist wieder schließt.

Was du hier beschreibst ist die Technik, welche bei UPnP zum Einsatz kommt. Einen Sicherheitsgewinn erzielt man dadurch nicht, da man keine gute Kontrolle darüber hat, wann welche Anwendungen wie viele Verbindungen aufmacht. Lediglich die Konfiguration des manuellen Portforwarding entfällt, was für den unbedarften User einfacher ist.

 

[CKid]

Alle Unklarheiten beseitigt. Danke.

 

[ThunderWorm]

Wenn ein Port geschlossen ist, dann wird (abhängig vom BS und von der Art des empfangenen Paketes) eine Antwort generiert.
Also wenn eine Schwachstelle im Netzwerkstack vorhanden ist, könnte man die ausnutzen. Nur denke ich nicht, dass es da eine Schwachstelle gibt. Und falls eine entdeckt würde, dann wärst du bestimmt nicht das erste Angriffsziel .
Bei einer Firewall kann dies genauso passieren (ist auch schon vorgekommen!). Von dem her ist das Sicherheitsrisiko sehr klein wenn der Port geschlossen ist.

 

[ElGrande-CG]

Inwiefern stellt das PF eigentlich ein Risiko für das OS dar, abgesehen von eventuellen Fehlern in der adressierten Anwendung selbst?

Gar keins.

Oder läuft ein Paket grundsätzlich ins Leere, wenn am entprechenden Port nichts lauscht?

Ja. Ohne lauschende Anwendung oder Dienst wird ein Paket verworfen.

 

[ThunderWorm]

Ja. Ohne lauschende Anwendung oder Dienst wird ein Paket verworfen.

Nein.. Das Paket wird verarbeitet, das habe ich doch schon geschrieben.

 

[M_ars]

sollte in einer der oberen schichten im OSI-modell verworfen werden das "unbekannte" packet(falsch) bzw Daten. Um über Porttriggering was zu sagen: Es gibt Upnp und auch Porttriggering. Leider funktioniert letzteres nicht immer so gut bei mir. Upnp bleibt aus... NAT und Firewall machen den rest

 

[ElGrande-CG]

Nein.. Das Paket wird verarbeitet, das habe ich doch schon geschrieben.

Aha, und wovon? Wenn mit dem Port gar keine Applikation verknüpft ist?

 

[networker]

Aha, und wovon? Wenn mit dem Port gar keine Applikation verknüpft ist?

Naja, das ist wohl eine Frage der Definition. Die unteren Layer verarbeiten den Frames schon. Zuerst wird die MAC-Adresse geprüft. Stimmt diese mit der eigenen überein oder ist es ein Broadcast, wird der Frame gelesen. Bei IP wird als nächstes die IP-Adresse überprüft. Stimmt diese, wird die Portnummer gelesen. Erst dann fällt die Entscheidung.

Wenn es also ein Problem in den unteren Layern des Protokollstacks gibt, ist das schon problematisch.

HTH
Mirko