soa
Goto Top

Webserver aus dem Intranet freigeben

Port 80 der Firewall freigeben

Hallo zusammen,

ich habe auf dem Port 80 der Firewall ein Forwarding auf einen Server im Intranet erstellt. Jetzt habe ich bedenken
bezüglich der Sicherheit. Welche Maßnahmen kann ich ergreifen, um das Netzwerk vor Gefahren zu schützen ?

Oder anders gefragt. Was kann alles passieren, wenn jeder über den Port 80 auf den Rechner xy im Netz gelangt.


Vielen Dank im Voraus.


Viele Grüße
SOA

Content-ID: 83910

Url: https://administrator.de/contentid/83910

Ausgedruckt am: 22.11.2024 um 20:11 Uhr

60734
60734 25.03.2008 um 19:08:27 Uhr
Goto Top
Also ich hab auch einen kleinen Webserver zu Hause, und ich hab mal gehört, solange ein Dienst bzw. Programm hinter dem Port aktiv ist, kann keiner durch diesen ins Netzwerk gelangen, nur dann wenn dieser einfach so offen ist, ohne dass ein Programm dahinter aktiv ist.
Arch-Stanton
Arch-Stanton 25.03.2008 um 20:52:15 Uhr
Goto Top
Moin,

solch eine Konstruktion ist nicht sinnvoll. Besser ist es, eine 3-Zonen Firewall, wie z.B. IP-COP einzusetzen. Da hängt dann der Server in de DMZ und das interne Netwerk wird geschützt.

Schaue doch mal unter http://m0n0.ch/wall/ oder www.ipcop.org nach.

Gruß, Arch Stanton
filippg
filippg 25.03.2008 um 21:29:19 Uhr
Goto Top
Also ich hab auch einen kleinen Webserver zu
Hause, und ich hab mal gehört, solange
ein Dienst bzw. Programm hinter dem Port
aktiv ist, kann keiner durch diesen ins
Netzwerk gelangen, nur dann wenn dieser
einfach so offen ist, ohne dass ein Programm
dahinter aktiv ist.
Das ist eher Unsinn. Wenn das Forwarding ins Leere zeigt, dann werden die Pakete vom Router ins Netz gestellt und verfallen bestenfalls einfach (außerdem werden sie nie Acknowledget, weswegen alleine schon der Verbindungsaufbau schwer ist). Wenn ein Dienst dahinter ist, dann wird er sie auch entgegennehmen und bearbeiten. Und da ergibt sich dann wieder das Problem mit Pufferüberläufen, unsaubern Protokollen.... Ist also deutlich gefährlicher.
Andere Frage ist natürlich: was bringt es, ein Forwarding zu haben, wenn kein konsumierender Dienst dahinter ist.

Zurück zur Frage: Das ist sehr relativ.
Sinnvoll ist es sicher, den Server in eine DMZ zu stellen. Letzlich einfach ein Netzbereich, in dem nur er steht, und von wo aus er nicht auf euer Intranet zugreifen kann. Hintergrund: Wenn der Server gehackt ist das Intranet noch geschützt. Das können selbst viele billige Router.
Nächster Schritt wäre dann, noch eine zweite DMZ aufzubauen, in der ein Proxy steht. Nur dieser darf mit dem Webserver sprechen, und nur dieser ist aus dem Internet zu errreichen. Und damit das auch Sinn macht, sollten die Firewall hin zum Internet und hin zur Webserver-DMZ getrennte Geräte sein. Und dann noch der Proxy-Server.. man legt da schon ein paar Euro auf den Tisch. Und natürlich lässt sich das beliebig weit fortsetzen. Das macht aber alles auch nur dann Sinn, wenn man das entsprechende Know-How für die Administration hat.

Also, für dich: Das mit der eigenen DMZ für den Webserver, und den immer auf aktuellem Patchstand halten. Daneben noch aufpassen, das darauf nur sichere Skripte laufen (SQL-Injection...). Und natürlich sicherstellen, dass wirklich nur Port 80 ins Netz geht. Damit hast du ein gutes Preis-/Leistungs-Verhältnis.
Wenn's was kosten darf dich nochmal wegen einer ordentlichen Firewall beraten lassen.

Gruß

Filipp
soa
soa 25.03.2008 um 22:00:09 Uhr
Goto Top
Hallo,

allen erst einmal ein herzliches Dankeschön. Vielen Dank für die Antworten.
@filipp : Sehr schön erklärt mit der DMZ. Das Netz läuft also z.B.

Intranet: 192.168.0.1 - 192.168.0.255
Firewall : 192.168.2.1 ?!
Webserver: z.B. 192.168.178.1

Die Firewall verbindet zum WebServer . Der WebServer kann nur über die Firewall ins Intranet.

Es soll ein Webserver mit Tomcat oder ein Tomcat Server als Standalone implementiert werden.
Das Servlet soll dann eine Verbindung zur DB bekommen. Ein Dienst also. Der darauf implementierte Server wird über ein POST aktiviert.

In Sachen Sicherheit des Tomcat wollte ich mich hieran halten :

www.bsi.de/literat/studien/tomcat/konfiguration.pdf


VG
SOA