Kann meinen ftp- und webserver nicht über meine public IP erreichen

cabriofahrer

Well-Known Member
Ich habe auf meinem Notebook FreeBSD 9.0 instaliert, darauf laufen ftpd und apache, die ich intern problemlos über die IP 192.168.1.92 mit ftp://192.168.1.92 bzw. http://192.168.1.92 über einen Browser, sei es auf dem Notebook selbst oder vom Windows-PC, erreichen kann.

Jetzt würde ich gerne die Server von der Außenwelt aus erreichen können. Bei whatismyip.com bekomme ich meine public IP angezeigt. Die lautet 84.120.xxx.xxx und gehört laut Provider nur mir und wird nur alle paar Monate geändert.

Im Router habe ich sowohl Portforwarding für ftp und http eingestellt. LAN-Server IP ist natürlich 192.168.1.92, eine Firewall ist im Router nicht aktiviert, ich nutze auch keine in FreeBSD, jetzt müßte ich doch eigentlich mit ftp://84.120.xxx.xxx und http://84.120.xxx.xxx meine Server erreichen können, oder?

Aber es klappt nicht. Zumindest bei ftp://84.120.148.243 erscheint unten im Browser sekundenlang "connected to 84.120.xxx.xxx...", letztendlich erscheint aber ein Fenster mit der Meldung: "Connection Interrupted / The document contains no data. The network link was interrupted while negotiating a connection. Please try again."

Übersehe ich hier etwas? Ist bei FreeBSD etwas standartmäßig so konfiguriert, daß man nicht so einfach "von Außen" zugreifen kann? Liegt es am Router? Liegt es am Provider? Wie kann ich es herausfinden? Gibt es eine Art Diagnosetool, so daß mir durch Eingabe von ftp://84.120.xxx.xxx genau anzeigt wird, was passiert?
 
Danke, genau das war das Problem. Jemanden angerufen, um mit der Public IP von einem anderen Rechner aus zuzugreifen, beides hat geklappt. Der Router ist ein D-Link DCM-G202. Der Portscan ergibt, daß die Ports 21 und 80 offen sind und werden auf rotem Hintergrund dargestellt, während sämtliche andere Ports als grün und gefiltert dargestellt werden.
Die Firewall in dem Router ist deaktiviert. Was sollte ich jetzt nun unter dem Sicheheitsaspekt noch beachten? Firewall im Router aktivieren? Würde das Portforwarding für die Ports 21 und 80 / der Zugriff von außen noch funktionieren?
Oder auf dem FreeBSD-Rechner eine Firewall laden, damit die Ports 21 und 80 irgendwie geschützt sind?
 
Wenn man hinter einem NAT ist braucht man eigentlich keine Firewall, weil alle Verbindungen von innen initiiert werden müssen. Du könntest natürlich DPI auf Ports 21 und 80 machen aber das wichtigste ist, dass du keine Lücken in den von außen erreichbaren Diensten hast.
 
Wenn man hinter einem NAT ist braucht man eigentlich keine Firewall, weil alle Verbindungen von innen initiiert werden müssen. Du könntest natürlich DPI auf Ports 21 und 80 machen aber das wichtigste ist, dass du keine Lücken in den von außen erreichbaren Diensten hast.

Äh, was? Ohne Paketfilter könnte der erste Hop außerhalb des Routers eine Route für das interne LAN auf den Router setzen und fröhlich alle internen Rechner erreichen. Oder gespoofte Pakete bouncen einfach fröhlich in das LAN rein.

Dass man keine Firewall bei NAT braucht, will ich nie wieder hören. :> Oder dass NAT Sicherheit bringt oder so einen Blödsinn.
 
Äh, was? Ohne Paketfilter könnte der erste Hop außerhalb des Routers eine Route für das interne LAN auf den Router setzen und fröhlich alle internen Rechner erreichen. Oder gespoofte Pakete bouncen einfach fröhlich in das LAN rein.
Ich peile echt nicht wie das passieren soll. Wie soll eine route ins interne Netz entstehen, wenn das nicht mal von außen adressierbar ist?
 
Zugegeben, dass der erste Hop kompromittiert ist, ist nicht sehr wahrscheinlich, aber wenn, dann wollen wir doch richtig arbeiten, oder? Könnte ja auch einer am Hausanschluss sitzen.

<1st hop> --- <router> --- <lan>

Dass ein "route add <lan> <router>" auf dem ersten Hop das LAN für diesen erreichbar macht, siehst du, oder?
 
Nee. Jetzt echt nicht. Alles was vom 1st hop an Adressen des internen LANs geht würde vom router verworfen, weil es am falschen Interface ankommt, es sei denn das wäre eine Bridge.

Jedenfalls bin ich immer davon ausgegangen.
 
Nützliches Gimmick, wenn der Router OpenBSD hat:

Code:
pass  in quick on lan inet proto tcp to (ext) port 80 rdr-to $www_host tag MIRROR modulate state
pass out quick on lan tagged MIRROR nat-to (lan) modulate state

Das spiegelt bei Zugriff auf die externe Adresse die Verbindung zurück ins LAN. Für den Web-Server im LAN scheint die Verbindung dann vom Router zu kommen.
 
Nee. Jetzt echt nicht. Alles was vom 1st hop an Adressen des internen LANs geht würde vom router verworfen, weil es am falschen Interface ankommt, es sei denn das wäre eine Bridge.

Jedenfalls bin ich immer davon ausgegangen.

Das, was dich davor schützt, ist ein Paketfilter mit passenden Regeln. Wenn wirklich NUR NAT gemacht wird und der Router ungehindert routet, dann geht genau das, was ich oben geschrieben hab.

Warum sollte der Router Pakete verwerfen? Er ist ein Router. Er hat eine default route zum 1st hop und eine route fürs LAN. Damit kann er vom 1st hop zum LAN routen. Ganz einfach eigentlich.

Edit: Was anscheinend immer wieder und selbst mit Erklärung vergessen wird: NAT ist nur eine Adressänderung, wenn Pakete aus dem LAN ins Internet gehen. Jeglicher Schutz kommt vom Paketfilter. Da meistens Filter und NAT eine Softwarekomponente sind, glaubt man irgendwann, die Sicherheit käme von NAT.
 
Last edited:
Nun, mein FreeBSD routet nicht einfach so Pakete in der Gegend rum. Ich muss erst mal den Paketfilter einschalten und dafür eine Regel schreiben.
 
Dann hast du ein anderes FreeBSD als der Rest der Welt.

Ich habs extra mit der 9.1 LiveCD nachgebaut. Dort ist ja wohl kein Paketfilter aktiv.

routing.png
 
OK, jetzt frage ich mich warum ich immer PF Regeln gebraucht habe um meine Verbindung UMTS Verbindung zu teilen. Dann hätten die anderen Rechner doch einfach nur ihre Default-Route auf meinen Rechner setzen müssen.

Oder lag es etwa bloß daran, dass der Provider die Pakete von 192.0/16 oder 10/8 Adressen verwirft?
 
Du brauchst PF, weil es das NAT mit erledigt, welches du brauchst, weil dir sonst keiner im Internet antworten kann.

Das heißt nicht, dass du nur NAT machen brauchst, damit außerhalb deines Router gar keiner mit dir reden kann.

Wenn der erste Hop (oder alle weiteren danach, die passend konfiguriert sind) mit dir reden will, brauchst du kein NAT, nur passende Routen. Nur die passenden Filterregeln von PF verhindern das.

Wie gesagt, es braucht nur jemand an deinen Hausanschluss rangehen und einen PPPoE-Man-in-the-middle spielen. Dann hast du nur mit NAT und ohne passende Filterregeln verloren. Ich hatte zwar gesagt, dass das kein wahrscheinliches Szenario ist, aber wenn, dann richtig, oder?
 
Wenn jemand meinen Hausanschluss hopps nimmt, bringt mir der Paketfilter auch nichts mehr.
 
Alle Daten austauschen, SSL Verbindungen kapern. Die eine Warnung wegen dem ungülitgen Zertifikat wird doch weggeklickt … Software Updates austauschen und dabei eigenen Zertifikate unterschieben (die sind bei FreeBSD nämlich nicht signiert, aber Zertifikate sind eh wirkungslos, wenn sie über den gleichen Kommunikationsweg reinkommen). DNS umleiten, die Liste ist endlos.

Mal ehrlich im Grunde ist man doch jedem zwischen dem eigenen Rechner und dem Kommunikationspartner vollkommen hilflos ausgeliefert.
 
Back
Top