passiver ftp ipfw

heech

New Member
Hallo,

ich hoffe jemand kann mir bei meinem ftp-Problem helfen!
Seit 2 wochen versuche ich auf meiner FreeBSD-Kiste meine Firewall (ipfw-Packetfilter) richtig zu konfigurieren.
mein Problem: dazu erst mal mein netz

3 pc; 1. pc (firewall) 2. pc (dmz mit ftp-server) 3. pc private Netzadresse;
1.pc : natd, ipfw mit eigenen regeln, freeBSD, 3 Schnittstellen wobei nat auf der nach außen
2.pc : ftpd (Standard) freeBSD
3.pc : freeBSD

Ich möchte nun auf der firewall erlauben das alle Nutzer intern, ftp im passiven modus und im aktiven Modus nach außen (öffentliche ftp internet) nutzen können.
Im nächsten Schritt sollen alle Nutzer von außen, meinen ftp (in der dmz) sowohl im aktiven als auch im passiven Modus nutzen können.

Hier liegt auch mein Problem. ich habe es geschafft das alle von außen im aktiven Modus auf meinen ftp kommen und auch nutzen können, jedoch von
außen auf meinen ftp im passiven Modus das geht nicht.

Mir ist die Problematik bei dieser eingehenden passiven ftp-Verbindung bekannt (Eingehender Datenkanal von Client-außen auf meinen ftp (port >1024)).
Ich habe auch bei meiner tagelangen Suche im Netz unterschiedliche Lösungsansätze entdeckt.

1.die Ports von 1024-65535 offen lassen dann gibt es kein Problem (kann noch eingeschrenkt werden 49151-65535)
2.keinen ftp-server mit passivem Modus anbieten sondern nur aktiv
3.einen eigenen deamon schreiben der sich merkt welche Anfrage kamen und dann nur speziell die entsprechende Antwort durchlässt (irgendwie über divert in den firewall-rules möglich keine Ahnung wie).
4.Einen ftp-proxy realisieren
5.-punch_fw Option bei natd


Die 1. Variante ist mir zu unsicher und die 2. möchte ich nicht, da es ja irgendwie möglich sein muss!
Zur 3. und 4. Alternativen habe ich zwar einige Ansätze in Diskussionen gefunden jedoch keine genauen Hinweise der Umsetzung. Den 5. Punkt habe ich ausprobiert konnte aber nur aktiv lösen.
Ebenfalls habe ich viel zu "statful rules" gefunden konnte aber auch hier keine Lösung zu meinem Problem entdecken.


ich hoffe jemand kann mir Tips geben wie ich dieses Problem lösen kann

Mit freundlichen Grüßen

heech
 
Zuletzt bearbeitet:
Firewallregeln?

Hi,

mal dumm gefragt, mit welchen Firewall Regeln arbeitest Du?
Bei mir funktioniert das mit folgenden Regeln:

ipfw add 1 allow tcp from any to any out via tun0
ipfw add 2 allow tcp from any to any in via tun0 established
ipfw add 3 allow tcp from any to any 20-21 in via tun0 setup

Regel 1 erlaubt allen ausgehenden tcp Verkehr.
Regel 2 erlaubt allen eingehenden tcp Verkehr, der das established gesetzt hat, also die Verbindungsverhandlungen wurden erfolgreich abgeschlossen.
Regel 3 läßt alle Pakete zu den tcp Ports 20-21 durch, die eine Verbindungsanforderung (Setup Bit) enthalten.
Kommt die Verbindung zu Stande, greift Regel 2, die aufgebaute Verbindungen abhandelt.

Ach so, eine Regel hab ich vergessen:
ipfw add divert 8668 ip from any to any via tun0
Leitet allen Ip Verkehr der von außen kommt oder nach außen geht auf den Port des Natd um.
Diese Regel sollte als erste Regel in Deinem Skript stehen!
Meine Natd Konfig enthält keinerlei Umleitungen usw. die sich auf Ftp beziehen.

Bei mir funktionieren mit diesen Regeln alle Ftp Verbindungen, von innen nach aussen, von aussen nach innen, aktiv, passiv... was Du willst.
Ich verwende proftpd.

Gruß
StSch
 
getestet

Erstmal Danke für deine Mühen stsch,

ich habe deine 3 Regeln mal ausprobiert. Super mit diesen Regeln geht es wirklich!
Nur eines stört mich, nachdem ich die ftp-Geschichte getestet habe, lies ich auf die firewall und dem ftp-server
einen Portscann laufen.
Ich benutzte dazu nmap. Als Ergebnis sagte er mir, dass

zur firewall :
(The 1598 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
25/tcp open smtp
587/tcp open submission

zum Bastions-host (ftp-server):
(The 1594 ports scanned but not shown below are in state: closed)
Port State Service
21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
80/tcp open http
443/tcp open https
514/tcp open shell
587/tcp open submission

wenn ich das Ergebnis richtig interpretiere sind die Ports der Firewall und des ftp-Servers offen.

Daraufhin schaute ich nach welche Firewall-Regeln genutzt wurden.
Hier die Auswertung (ipfw -t list):

00050 Mon May 19 10:29:45 2003 divert 8668 ip from any to any via xl0
00100 Mon May 19 10:29:11 2003 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
00300 deny ip from 127.0.0.0/8 to any
00390 Mon May 19 10:29:36 2003 allow tcp from any to any setup
00400 Mon May 19 10:29:45 2003 allow tcp from any to any out via xl0
00401 Mon May 19 10:29:36 2003 allow tcp from any to any in via xl2
00402 Mon May 19 10:29:45 2003 allow tcp from any to any in via xl0 established
00403 Mon May 19 10:29:36 2003 allow tcp from any to any out via xl2 established
00404 allow tcp from any to any dst-port 20,21 in via xl0 setup
00405 allow tcp from any to any dst-port 20,21 out via xl2 setup

00800 deny tcp from any to any via xl0
00801 deny tcp from any to any via xl2
00900 Mon May 19 10:29:40 2003 allow udp from any to any

... hier noch die ip's die ich erlaube

65535 deny ip from any to any


Demnach kommen meine "Verbots-Regeln (800,801)" nachdem die established Zeile durchlaufen ist gar nicht mehr zur Anwendung.

Ich hätte eigentlich bei den portscann als Ergebnis in etwa so etwas erwartet:

(The 1594 ports scanned but not shown below are in state: filtered)
Port State Service
21/tcp open ftp
22/tcp open ssh

fällt dir dazu eine Lösung ein (dass die ports gefiltert sind und nicht offen)?

Mit freundlichen Grüßen
Heech
 
Hi Heech,

Die einfache und direkte Antwort auf Deine Frage wäre:
Es gibt vorher eine Regel oder Regeln, die allen Zugriff erlauben, die Deny Regeln werden niemals ausgeführt oder nur dann, wenn vorher keine Regel matched.
Anscheinend hast Du entweder noch keine Pakete bekommen, die auf keine Regel zutreffen, die vor den Deny Regeln liegen oder aber Du hast alles so freigeschaltet, daß die Regeln niemals zur Anwendung kommen.
Ipfw sucht, bis es eine matching rule gefunden hat und bearbeitet das Paket dann, es werden nicht alle Regeln für jedes Paket ausgeführt.
D.h. wenn Du irgendwo eine Regel hast, die, sagen wir mal, allen tcp Verkehr erlaubt, dann Regeln hast, die tcp Verkehr nur auf bestimmten Ports erlaubt und zum Schluß eine Regel hast,d ie allen tcp Verkehr verbietet, kommen die beiden letztgenannten niemals zum Einsatz, weil Du als erstes ja alles erlaubt hast.
Wenn Du als erste Regel in Dein Skript die Zeile "deny ip from any to any" einfügst, dann ist Deine Firewall komplett zu, egal was Du hinterher für "allow" Regeln definierst.

Außerdem, naja, ich will Dir ja nicht in Deine Konfig reinreden, aber bist Du Dir sicher, daß Du das so willst, wie Du das beschrieben hast?
Ich würde in dem beschriebenen Netz, wenn es nicht zwingende Gründe gibt, das anders zu machen, auf der Firewall per Nat oder per rinetd die Ports des Fw Rechners einfach auf die Ports des Ftp Rechners weiterleiten.
Die Firewall wäre im Fall eines berechtigten Ftp Zugriffs transparent und für den User von außen sieht es so aus, als ob er mit dem Firewall Rechner kommuniziert.
Ich denke mal, dadurch würde Deine Firewall Konfig auch einfacher.
Btw: Du brauchst nicht beide Regeln, 800 und 801, entferne eine der beiden Regeln und lösche bei der anderen den Teil via xl?.
Wenn Du keine Schnittstelle definierst, sind automatisch alle gemeint.

Ich würde andere Forumsteilnehmer bitten, zu meinem letzten Absatz Stellung zu nehmen.
Das ist nur eine Idee von mir, ernte ich dafür Zustimmung oder doch mehr Ablehnung?
Wenn Ablehnung: Warum?

Gruß
StSch
 
hallo zusammen,

Der Thread ist zwar schon zwei Jahre alt, aber ich beschäftige mich zurzeit mit dem selben Problem und habe da einige Fragen.
stsch schrieb:
...
ipfw add 1 allow tcp from any to any out via tun0
ipfw add 2 allow tcp from any to any in via tun0 established
ipfw add 3 allow tcp from any to any 20-21 in via tun0 setup

Regel 1 erlaubt allen ausgehenden tcp Verkehr.
Regel 2 erlaubt allen eingehenden tcp Verkehr, der das established gesetzt hat, also die Verbindungsverhandlungen wurden erfolgreich abgeschlossen.
Regel 3 läßt alle Pakete zu den tcp Ports 20-21 durch, die eine Verbindungsanforderung (Setup Bit) enthalten.
Kommt die Verbindung zu Stande, greift Regel 2, die aufgebaute Verbindungen abhandelt.
...

1. Ist in Regel 3 die Angabe von Port 20 wirklich erforderlich?
Bei aktivem FTP wird der Port 20 als Quellport des Servers für die ausgehende Verbindung benutzt. Das wäre aber IMHO aufgrund von Regel 2 ohnehin schon zulässig.

2. Bei passivem FTP baut der Client auf einem hohen Port den Datenkanal auf.
Bei diesem Verbindungsaufbau greift nach meinem Verständnis die Regel 2 nicht, da es sich um eine neue Verbindung handelt. established matcht aber nach meinem Kenntnisstand nur Verbindungen die entweder das ACK oder das RST Bit gesetzt haben.
Frage: warum funktioniert dann passives FTP mit diesem ruleset?

Würde mich über jedes Feedback freuen, da ich mich schon längere Zeit mit diesem Thema beschäftige. Habe aber im Augenblick leider keine Möglichkeit diese Konfiguration zu testen.

Gruß
D.Mon
 
Zurück
Oben