ipfw port-mapping

[lupusoft]

OK, ich habe jetzt glaube ich genug in alten Beiträgen gesucht, um mich zu trauen diese wahrscheinlich triviale Frage zu stellen: Mit welcher rule in ipfw kann ich ein portmapping/portforwarding von einer WAN-IP an ein LAN-IP erreichen? In der man-page ist fwd aufgeführt, aber so wie ich es verstehe, ist das eher für eine transparente Weitergabe der externen IP an proxies gedacht.
Mein Netz besteht aus einem OSX 10.3.9 Rechner mit 3 NICs (1xextern, 1xLAN, 1x(pseudo-)DMZ. Die DMZ besteht aus einem Quadra700 mit NetBSD 3.0.1 , auf dem ein FTP-Server läuft. Der Rest ist wahrscheinlich klar, man soll halt von aussen mit der externen IP und port 21 den FTP-server mit seiner lokalen IP erreichen. Kann mir da mal wer von den Profis kurz unter die Arme greifen?

Danke, Lupus

 

[Toertel]

Hallo,

Wenn du eine DMZ hast, wozu dann noch die Firewall konfigurieren? DMZ bedeutet, dass alle Ports zu diesem Rechner offen sind.

Eine Weiterleitung eines externen zu einem internen Port erreichst du spielend leicht wenn du dein komplettes Netzwerk mit einem Router ausstattest. Das ist das mindeste was man für solch eine Konfiguration verwenden sollte.

Diese Portweiterleitung des FTP-Servers über eine normale ipfw eines deiner Rechner durchzuführen, hätte sowieso keinen rechten Sinn, da der FTP-Server neben dem Port 21 auch noch zahlreiche Kontroll-Ports verwendet die sich im höheren Bereich befinden, etwa zwischen 10000 und 65000. Für jeden Client wird zusätzlich einer davon benötigt um die Befehle und Abfragen zu senden und zu empfangen. Diese Ports werden vom Server erst direkt bei Anmeldung des Clients gewählt und sind daher weder in ihrer Nummer noch in der Reihenfolge vorherbestimmbar. Sie können also nie einzeln in einer Firewall freigegeben werden.

Also kurz und knapp gesagt: Ein FTP-Server und eine Firewall b.z.w. NAT vertragen sich überhaupt nicht und sind wenn - dann ganz schwierig zu konfigurieren.

Im Forum (Signatur) kannst du eine komplette FTP-Server-Konfig nachlesen die von mir getestet wurde.

 

[lupusoft]

Wenn du eine DMZ hast, wozu dann noch die Firewall konfigurieren? DMZ bedeutet, dass alle Ports zu diesem Rechner offen sind.

Will jetzt keine Diskussion darüber anfangen, wie eine DMZ aufgebaut ist, aber der Normalfall IMHO ist, dass sich eine DMZ tatsächlich sogar zwischen zwei firewalls befindet. Ist mir aber schnuppe, spielt hier keine Rolle.

Eine Weiterleitung eines externen zu einem internen Port erreichst du spielend leicht wenn du dein komplettes Netzwerk mit einem Router ausstattest. Das ist das mindeste was man für solch eine Konfiguration verwenden sollte.

Ähm, dann hab ich mich entweder unklar ausgedrückt, oder es ist wieder eine Definitionsfrage. Der Rechner mit den 3 NICs IST mein Router, jedenfalls ein NAT-Gateway.

Diese Portweiterleitung des FTP-Servers über eine normale ipfw eines deiner Rechner durchzuführen, hätte sowieso keinen rechten Sinn, da der FTP-Server neben dem Port 21 auch noch zahlreiche Kontroll-Ports verwendet die sich im höheren Bereich befinden, etwa zwischen 10000 und 65000.

Schon klar.

Für jeden Client wird zusätzlich einer davon benötigt um die Befehle und Abfragen zu senden und zu empfangen. Diese Ports werden vom Server erst direkt bei Anmeldung des Clients gewählt und sind daher weder in ihrer Nummer noch in der Reihenfolge vorherbestimmbar. Sie können also nie einzeln in einer Firewall freigegeben werden.

Müssen sie ja auch nicht, dafür ist der ftp-server ja in seinem eigenen LAN, für den ich die fw separat konfigurieren kann.

Also kurz und knapp gesagt: Ein FTP-Server und eine Firewall b.z.w. NAT vertragen sich überhaupt nicht und sind wenn - dann ganz schwierig zu konfigurieren.

Glaube mir, es geht.

Im Forum (Signatur) kannst du eine komplette FTP-Server-Konfig nachlesen die von mir getestet wurde.

Öhm, mag ja sein, aber was hat das bitte mit meiner Frage zu tun? Mein FTP-Server steht, und wie Du vielleicht gelesen hast, läuft er auf NetBSD und nicht OSX.
Tschuldige, wenn ich etwas angepisst reagiere, aber meine Frage war nicht: "Ist es Blödsinn einen ftp-server hinter einer firewall zu platzieren?"

Gruss, Lupus

 

[maceis]

Hey, locker bleiben!

 

[Toertel]

@lupusoft

Selbst wenn dir hier @maceis eine Konfiguration deiner ipfw aus seiner Anleitung anbietet, solltest du dennoch mal über die Frage nachdenken: "Ist es Blödsinn einen ftp-server hinter einer firewall zu platzieren?"

Und auch wenn dein FTP-Server wie du sagst "steht", bedeutet das ja nicht, dass du alles richtig eingestellt hast und die Funktionsweise ausreichend verstanden hast.

Die Kontroll-Ports werden vom FTP-Server beispielsweise nicht innerhalb einer ipfw-Firewall vergeben, sondern direkt an den Client, da eine Firewall diese Funktion blockiert. Ich möchte mich nicht gern wiederholen, aber der Zugriff von außen kann nicht durch eine Firewall kontrolliert werden.

Eine Möglichkeit gibt es allerdings um diese Sache zu umgehen, nicht aber den Grund zu beseitigen. Du trägst in der ftpd.conf "portrange all 49999 50000" ein. Damit erreichst du, dass nur insgesamt ein Kontroll-Port geöffnet wird. Du kannst nun den Port 49999 in deiner ipfw freigeben. Dafür kann aber auch nur ein Client zur selben Zeit auf deine FTP-Daten zugreifen. Ein schlechter Tausch finde ich. Mit nur einem User-Zugriff ist dein FTP-Server sinnlos.

Ich würde dir WebDAV empfehlen, da hast du die Probleme mit deiner Firewall nicht.

Aber du bist dir ja völlig sicher, dass es funktioniert. Solltest wissen, dass sich da ganz andere Leute schon die Zähne ausgebissen haben. Viel Spass noch.

 

[lupusoft]

@Toertel

@lupusoft
Selbst wenn dir hier @maceis eine Konfiguration deiner ipfw aus seiner Anleitung anbietet...

Die Anleitung von maceis ist sehr schön gemacht und gibt einen guten Einstieg für Leute, die sich das erste Mal mit der ipfw befassen. Wenn Du sie gelesen und verstanden hast, dann weisst Du auch, dass sich die Beispiele nicht auf eine Netzwerkinstallation mit NAT beziehen. Wie Du ja gesehen hast, geht es bei mir um etwas komplizierteres.

..., solltest du dennoch mal über die Frage nachdenken: "Ist es Blödsinn einen ftp-server hinter einer firewall zu platzieren?"
Und auch wenn dein FTP-Server wie du sagst "steht", bedeutet das ja nicht, dass du alles richtig eingestellt hast und die Funktionsweise ausreichend verstanden hast.

Was soll das hier eigentlich werden, kleiner Trollversuch? Grossen Macker spielen?

Eine Möglichkeit gibt es allerdings um diese Sache zu umgehen, nicht aber den Grund zu beseitigen. Du trägst in der ftpd.conf "portrange all 49999 50000" ein. Damit erreichst du, dass nur insgesamt ein Kontroll-Port geöffnet wird. Du kannst nun den Port 49999 in deiner ipfw freigeben. Dafür kann aber auch nur ein Client zur selben Zeit auf deine FTP-Daten zugreifen. Ein schlechter Tausch finde ich. Mit nur einem User-Zugriff ist dein FTP-Server sinnlos.

Mit Deinem Gefasel von Kontrollports disqualifizierst Du Dich langsam selber. Der Kontroll- oder besser Kommandoport ist Port 21, und je nachdem ob es passives oder aktives FTP werden soll, werden dann vom Server, respektive Client Datenports im hohen IP-Bereich geöffnet. Und selbstverständlich können mehrere Clients zugreifen, wenn man einen Portbereich in der fw freigibt. Aber eigentlich will ich mich gar nicht auf diese Diskussion einlassen. Offensichtlich geht es Dir ja nur darum, pseudoschlaue Halbwahrheiten in die Welt zu setzen.

Aber du bist dir ja völlig sicher, dass es funktioniert. Solltest wissen, dass sich da ganz andere Leute schon die Zähne ausgebissen haben. Viel Spass noch.

Jedenfalls bin ich mir sicher, dass mich Deine hochnäsige Besserwisserei nicht weiterbringt. Ich möchte Dich Dich daher freundlich bitten, Dich einfach aus dem Thread rauszuhalten.

-------------------------------------------------------------------------------------------------

@maceis

...wo Du schon gerade hier bist/warst, magst Du nicht mal einen Tipp geben? Momentan habe ich den Eindruck, dass ich das forwarding wohl doch in der natd.conf (bzw. natd.conf.apple bei meinem Panther Server) einbinden muss, etwa mit: redirect_port tcp Public_IP:21 21. Wenn ich das versuche und mit sudo natd -f /etc/nat/natd.conf.apple die Konfig neu laden will, bekomme ich ein Unable to bind divert socket.: Address already in use zurück. Gleiche Antwort, wenn ich es mit sudo natd -n en0 -redirect_port tcp Public_IP:21 21 versuche. Die Crux ist wahrscheinlich immer das Hin und Her zwischen der Server-GUI und dem Terminal. NAT und IPFW sind über die Server GUI aktiviert, die ipfw rules setze ich dann mit einem Skript ohne Probleme neu (nach einem flush). Ich muss gestehen, dass ich zu blöd bin, um das Knöpfchen-Interface der ipfw für alle Einstellungen zu benutzen. Darüber hinaus kann man bestimmte Sachen einfach nicht damit bewerkstelligen, z.B. separierte diverts für ein- und ausgehende Verbindungen, geschweige denn damit verbundene skiptos. Irgendein workaround für natd? Versucht er eine zweite Instanz von natd zu starten und deshalb die Fehlermeldung?

Danke, Lupus

 

[maceis]

...
...wo Du schon gerade hier bist/warst, magst Du nicht mal einen Tipp geben? Momentan habe ich den Eindruck, dass ich das forwarding wohl doch in der natd.conf (bzw. natd.conf.apple bei meinem Panther Server) einbinden muss,
...

Wenn ich genau wüsste, wo man da was machen muss, hätte ich schon längst einen Tip gegeben
Um ehrlich zu sein, weiss ich selbst nicht genau, wie Du Dein Anliegen umsetzen kannst.
Spontan hatte ich auch sofort an natd gedacht, aber da ich den unter Mac OS X noch nicht benutzt habe, hab' ich einfach mal die Klappe gehalten .

 

[lupusoft]

port-mapping -> so geht's

Als kleinen Nachtrag zu meiner eigenen Frage will ich mal meine Lösung an die Nachwelt hinterlassen. Vielleicht hat ja jemand ein ähnliches Problem.
Der Schlüssel zum port-mapping/port-forwarding liegt tatsächlich im nat-daemon. Wer sich in den Foren von Free-BSD umschaut, findet auch genügend Futter zu diesem Thema. Leider hat Apple natürlich einiges verschraubt, damit man durch den einfachen Klick auf die Knöpfchen NAT und die IPFW firewall unter der 10.3 Server Version konfigurieren/aktivieren kann. Die Konfigurationsmöglichkeiten für NAT unter dem GUI beschränken sich allerdings auf die Auswahl der Netzwerkkarte, die das public-interface repräsentieren soll. Was wir fürs port-mapping brauchen, ist eine Zeile in der Konfigurationsdatei für natd mit dem Befehl redirect_port tcp lokale_IP: port externe_IP: port. Alles nachzulesen unter man natd. FreeBSD hat normalerweise für diesen Zweck eine Datei namens natd.conf unter /etc liegen. Die gibt es unter OSX natürlich nicht. Hier findet man in /etc/nat/ drei Dateien, nämlich natd.conf.apple, natd.plist und natd.plist.default. Das GUI modifiziert natd.plist, eine Standard Parameterdatei in XML, und benutzt diese als Grundlage, um natd.conf.apple zu generieren, welche wiederum natd beim Starten als Alternativ-Konfigurationsdatei untergeschoben wird. natd.plist.default ist lediglich ein template zum Generieren von natd.plist und kommt nur dann zum Einsatz, wenn letztere nicht vorhanden ist.
Jetzt gibt es unterschiedliche Möglichkeiten, um zu erreichen, dass NAT unseren redirect_port Befehl erhält. Der direkteste Weg wäre NAT über das GUI zu deaktivieren, natd.conf.apple zu modifizieren (oder alternativ eine natd.conf Datei anzulegen) und natd anschliessend manuell zu starten, z.B. mit sudo natd -f /etc/nat/natd.conf.apple. Das hat allerdings den Schönheitsfehler, dass alles wieder dahin ist, sobald man wieder das Knöpfchen im Server-Administrationsprogramm benutzt.
Will man künftig NAT weiterhin über das Knöpfchen starten und stoppen, kommt man nicht umhin, natd.plist zu modifizieren, da hieraus wie gesagt jedesmal natd.conf.apple dynamisch erzeugt wird. Die XML-Syntax der verschiedenen Konfigurationsparameter für natd findet man in natd.plist.default. Beispielsweise steht da

redirect_port - array of redirect_port dictionaries; optional

und als Erläuterung zum Aufbau des dictionary

redirect_port dictionary keys:
proto - string; required
targetIP - string; required
targetPortRange - string; required
aliasIP - string; required
aliasPortRange - string; required

Laut man natd sind alias IP und Port zwar optional, aber die plist möchte es halt haben. Wenn man natd.plist mit dem PLIST-Editor aus den Developer tools editieren möchte, muss man wohl als echter root Nutzer eingeloggt sein, daher geht man besser den Weg über das Terminal. Mein bevorzugter Editor ist pico, also öffne ich mit sudo pico /etc/nat/natd.plist und füge folgenden Absatz ein:

<key>redirect_port</key>
<array>
<dict>
<key>aliasIP</key>
<string>193.175.25.xxx</string>
<key>aliasPortRange</key>
<string>21</string>
<key>proto</key>
<string>tcp</string>
<key>targetIP</key>
<string>192.168.102.xxx</string>
<key>targetPortRange</key>
<string>21</string>
</dict>
</array>

Die letzten Stellen der IPs sind wegen stetig wachsender paranoider Anwandlungen mal augeixt. ;-) Startet man NAT jetzt wieder über das Knöpfchen wird danach folgende Zeile in natd.conf.apple auftauchen:

redirect_port tcp 192.168.102.xxx:21 193.175.25.xxx:21

Übersetzt bedeutet dies, dass alle Anfragen an das externe Interface (193.175.25.xxx) auf port 21 (=ftp Kommandoport) umgeleitet werden auf den ftp-port vom internen Rechner mit der IP 192.168.102.xxx.
Damit ist von NAT-Seite eigentlich alles gelaufen. Jetzt muss man IPFW nur noch sagen, dass er NAT auch einsetzen soll und entsprechende Port-Freigaben setzen. Die Konfigurationsmöglichkeiten der firewall Regeln über das Server Administrationsprogramm sind leider ebenfalls nur halbherzig. Deshalb regele ich das auf anderem Wege. Allerdings würde das jetzt ein wenig den Rahmen sprengen. Falls es wirklich jemanden interessiert, kann er/sie ja mal nachhaken. Die Kurzform ist jedenfalls, einen divert der eingehenden Verbindungen über NAT, eine Freigabe von port 21 auf dem internen (nicht ! dem externen) Rechner und die Freigabe eines Portbereiches für die Datenverbindungen bei passivem FTP.

...
add 015 divert natd ip from any to any in via en0
...
add 350 allow log tcp from any to 192.168.102.xxx ftp,ftp-data in via en0
add 351 allow log tcp from any to 192.168.102.xxx 49000-49100 in via en0
add 352 skipto 30000 tcp from 192.168.102.xxx ftp,ftp-data to any out via en0
add 353 skipto 30000 tcp from 192.168.102.xxx 49000-49100 to any out via en0
...
add 2000 deny log all from any to any in via en0
...
add 30000 divert natd ip from any to any out via en0
add 30010 allow ip from any to any
...

Einiges ist jetzt aus dem Kontext gerissen und in statischen Regeln formuliert. Man kann das natürlich auch statefull mit dynamischen Regeln aufbauen. Wichtig ist nur noch, dass ftp-data (port 20) nur gebraucht wird, wenn der client aktives ftp einsetzen will. Aktives ftp scheitert allerdings, wenn der client auch hinter einer fw sitzt. In dem Fall geht es nur passiv, und der client kontaktiert den server auf einem port im Bereich von 49000 bis 49100. Der ftp-server ist natürlich so konfiguriert, dass er dem client nur diesen Bereich vorschlägt.
So, das tolle ist, dass es prima funktioniert. Wenn ich ehrlich bin, weiss ich allerdings nicht so genau, wieso eigentlich. Der Knackpunkt ist nämlich die Freigabe von den ports 49000-49100 auf dem internen Rechner. Diese Ports werden ja nicht durch einen entsprechenden Befehl in natd.conf.apple ge-forwarded. Aus der Sicht des Routers kommen neue Verbindungsanfragen an diese ports von einem externen Rechner auf en0 an. Woher weiss NAT/IPFW, dass es diese Verbindungen auf den internen ftp-server via en2 mappen muss? Ohne, dass ein Paket-Sniffer die Verhandlungen über den künftigen Datenport (die ja über port 21 serverseitig laufen) belauscht, kann NAT/IPFW doch gar nichts darüber wissen! Sowohl client wie auch server benutzen neue ports. Andererseits muss es so eine Funktionalität wohl geben, denn gerade für solche Fälle wie FTP gibt es die Konfigurationsanweisung punch_fw für den natd. Dabei werden in einem vorgegebenen Bereich der IPFW-Regeltabelle temporär neue Regeln eingefügt (ich meine nicht die dynamischen Regeln), die selektive Löcher für die Datenkanäle bohren. Supergeile Geschichte, aber zum Laufen hab ich's noch nicht gebracht. Hauptsächlich, weil es keine vollständige Apple-Dokumentation dazu gibt. Man findet zwar

punch_fw - punch_fw dictionary; optional

in der Beschreibung von natd.plist.default, aber leider nichts zum Aufbau des dictionary und der keys. Meine "best guess" Versuche mit "basenumber" und "count" als keys hat er schlichtweg ignoriert. Aber das ist eine andere Geschichte...
Hoffe, das mein Megaposting hier irgendwann jemandem hilft.

Gruss, Lupus