Moin.
Nachdem nun endlich das Masquerading und der Paketfilter soweit klappt, ist nur noch FTP als letzte Hürde geblieben. Wie mache ich das ganze mit stateful filtering (das war einer der entscheidenden Gründe warum ich überhaupt zu iptables migriert bin)? Ich habe diverse Regeln aufgestellt. So sieht das ungefähr aus:
$IPT -N states $IPT -F states $IPT -A states -m state --state ESTABLISHED,RELATED -j ACCEPT $IPT -A states -m state --state NEW,INVALID -j LOG $IPT -A states -m state --state NEW,INVALID -j DROP $IPT -A states -j RETURN $IPT -A INPUT -i $EXT_IF -j states $IPT -A FORWARD -i $EXT_IF -j states
Dazu habe ich noch ein paar Verzweigungen gemacht, diese hier:
$IPT -N ext-in $IPT -N ext-fw $IPT -N ext-out
$IPT -N int-in $IPT -N int-fw $IPT -N int-out
$IPT -A INPUT -i $INT_IF -s $LAN_IP -j int-in $IPT -A INPUT -i $EXT_IF -j ext-in $IPT -A FORWARD -i $INT_IF -o $EXT_IF -s $LAN_IP -j int-fw $IPT -A FORWARD -i $EXT_IF -o $INT_IF -j ext-fw $IPT -A OUTPUT -o $INT_IF -j int-out $IPT -A OUTPUT -o $EXT_IF -j ext-out
Die Variablen EXT_IF und INT_IF enthalten das Interface zum Internet bzw. zum LAN. Dementsprechend sind die spezifischen Chains zu deuten.
Ich nehme an, daß der Datenkanal nicht als "related" erkannt wird (einloggen kann ich mich ja). Ich dachte aber, daß ich mit meiner Variante diesen Problemfall abgedeckt hätte. Hat jemand einen Ausweg?
Carsten
am Sat, dem 22.05.2004, um 12:14:24 +0200 mailte Carsten Friede folgendes:
Moin.
Nachdem nun endlich das Masquerading und der Paketfilter soweit klappt, ist nur noch FTP als letzte Hürde geblieben. Wie mache ich das ganze mit
In kurz: Du brauchst dazu die passenden Module:
ip_conntrack_ftp 3200 0 (unused) ip_conntrack 12684 3 [ipt_state ip_nat_ftp iptable_nat ip_conntrack_ftp]
In lang: RTFM, http://netfilter.org
Andreas
Andreas Kretschmer wrote:
am Sat, dem 22.05.2004, um 12:14:24 +0200 mailte Carsten Friede folgendes:
Moin.
Nachdem nun endlich das Masquerading und der Paketfilter soweit klappt, ist nur noch FTP als letzte Hürde geblieben. Wie mache ich das ganze mit
In kurz: Du brauchst dazu die passenden Module:
ip_conntrack_ftp 3200 0 (unused) ip_conntrack 12684 3 [ipt_state ip_nat_ftp iptable_nat ip_conntrack_ftp]
Die Module sind schon lange geladen, daran hatte ich schon gedacht. Es hat sich was geändert. Wenn ich aus dem LAN heraus mich auf einem FTP Server einlogge, geht das. Wenn ich dann dort ein "ls" ausführe, bekomme ich statt dem üblichen Timeout in etwa folgende Nachricht: "Illegal PORT command" "bind: port already in use"
So ungefähr. Was ich im Großen und Ganzen machen will, stateful inspection einmal zu definieren und fertig. Die Dienste, die nutzen will, sind als Portnummern in einem Array gespeichert. Dieses wird dann per for-loop ausgelesen und die entsprechenden Regeln erstellt. Deswegen wäre es gut, wenn ich das für sowas wie ftp nicht getrennt definieren müßte.
Carsten
Carsten Friede cfriede@wh8.tu-dresden.de at 2004-05-22 1303 +0200:
So ungefähr. Was ich im Großen und Ganzen machen will, stateful inspection einmal zu definieren und fertig. Die Dienste, die nutzen will, sind als Portnummern in einem Array gespeichert. Dieses wird dann per for-loop ausgelesen und die entsprechenden Regeln erstellt. Deswegen wäre es gut, wenn ich das für sowas wie ftp nicht getrennt definieren müßte.
Das geht mMn bei FTP wegen seperater Daten- und Controlconnection nicht. Nicht umsonst gibt es das FTP-Conntrack-Modul extra.
MfG, Jonas
On Sat, May 22, 2004 at 01:03:52PM +0200, Carsten Friede wrote:
Andreas Kretschmer wrote:
am Sat, dem 22.05.2004, um 12:14:24 +0200 mailte Carsten Friede folgendes:
[cut]
Wenn ich aus dem LAN heraus mich auf einem FTP Server einlogge, geht das. Wenn ich dann dort ein "ls" ausführe, bekomme ich statt dem üblichen Timeout in etwa folgende Nachricht: "Illegal PORT command" "bind: port already in use"
Hallo Carsten.
Leider ist das bei ftp etwas anders. Es ist aus meiner Sicht ein veraltetes Protokoll was nicht mehr benutzt werden sollte.
Ich gehe davon aus, dass du passives FTP benutzt, also der Datenkanal vom Client zum Server aufgebaut wird.
Auf dem schon funktionierenden Kanal sendest du das "ls" zum Server. Der Server schickt als Antwort zum Client: OK, hol dir die Daten von Port XYZ. Der Client versucht nun sich zu Port XYZ des Servers zu verbinden. Doch wenn der FTP-Server nicht auch gleichzeitig die Firewall ist, so lauscht auf diesem Port niemand, der die Pakete zum FTP-Server weiterleiten kann.
Es gibt bei Suse einen FTP-Proxy damit kannst du dieses Problem umgehen.
Aktives FTP (Verbindungsaufbau vom Server zum Client) sollte man nicht mehr verwenden, da ein Verbindungsaufbau zu einem Client in der Regel nicht erlaubt ist. Alle Browser verwenden passives FTP.
Gruß, Thomas
Thomas Guettler wrote:
Leider ist das bei ftp etwas anders. Es ist aus meiner Sicht ein veraltetes Protokoll was nicht mehr benutzt werden sollte.
Mag sein, aber es ist immer noch der komfortabelste Weg Daten auszutauschen.
Ich gehe davon aus, dass du passives FTP benutzt, also der Datenkanal vom Client zum Server aufgebaut wird.
Bei passivem FTP stört mich die Tatsache, daß ich die gesamten hohen Ports aufmache. Sobald die Regel für das passive FTP drinsteht, kann ich mir alle anderen sparen, die auch ihre Dienste auf hohen Ports haben.
Auf dem schon funktionierenden Kanal sendest du das "ls" zum Server. Der Server schickt als Antwort zum Client: OK, hol dir die Daten von Port XYZ. Der Client versucht nun sich zu Port XYZ des Servers zu verbinden. Doch wenn der FTP-Server nicht auch gleichzeitig die Firewall ist, so lauscht auf diesem Port niemand, der die Pakete zum FTP-Server weiterleiten kann.
Es gibt bei Suse einen FTP-Proxy damit kannst du dieses Problem umgehen.
Gibt's ein entsprechendes Debian-Package?
Carsten
am 26.05.2004, um 8:45:29 +0200 mailte Carsten Friede folgendes:
Thomas Guettler wrote:
Leider ist das bei ftp etwas anders. Es ist aus meiner Sicht ein veraltetes Protokoll was nicht mehr benutzt werden sollte.
Mag sein, aber es ist immer noch der komfortabelste Weg Daten auszutauschen.
Nein.
Ich gehe davon aus, dass du passives FTP benutzt, also der Datenkanal vom Client zum Server aufgebaut wird.
Bei passivem FTP stört mich die Tatsache, daß ich die gesamten hohen Ports aufmache. Sobald die Regel für das passive FTP drinsteht, kann ich mir alle anderen sparen, die auch ihre Dienste auf hohen Ports haben.
Dafür ist Connection Tracking da.
Andreas
am 26.05.2004, um 8:45:29 +0200 mailte Carsten Friede folgendes:
Ich gehe davon aus, dass du passives FTP benutzt, also der Datenkanal vom Client zum Server aufgebaut wird.
Bei passivem FTP stört mich die Tatsache, daß ich die gesamten hohen Ports aufmache. Sobald die Regel für das passive FTP drinsteht, kann ich mir alle anderen sparen, die auch ihre Dienste auf hohen Ports haben.
Ich habe es eben noch mal probiert: Ich sitze an einem genatteten Rechner. Lade ich auf dem Gateway ip_conntrack_ftp.o and ip_nat_ftp.o, so kann ich auch aktives FTP betreiben.
Es gibt bei Suse einen FTP-Proxy damit kannst du dieses Problem umgehen.
Gibt's ein entsprechendes Debian-Package?
Offensichtlich ja:
webserv:~# apt-cache search proxy | grep -i suse ftp-proxy - SuSE Proxy-Suite FTP-Proxy
Andreas
Andreas Kretschmer wrote:
Ich habe es eben noch mal probiert: Ich sitze an einem genatteten Rechner. Lade ich auf dem Gateway ip_conntrack_ftp.o and ip_nat_ftp.o, so kann ich auch aktives FTP betreiben.
Gut, das wollte ich wissen. Mein nächste Frage ist, wie die Regel in der FORWARD-Chain auszusehen hat. Ich habe eine STATE-Chain, in der geprüft, wird, ob ESTABLISHED oder RELATED und danach ist ein RETURN in die FORWARD. Trotzdem müßte ich doch jetzt bei Angabe der Regeln sowas in der Art machen: "enable --sport 1024: --dport 1024: -m state RELATED -j ACCEPT". Richtig?
Carsten
PS: @ Rainer Klapproth: Du wolltest doch mal dir Rules schicken.Danke.
am 27.05.2004, um 17:24:07 +0200 mailte Carsten Friede folgendes:
Andreas Kretschmer wrote:
Ich habe es eben noch mal probiert: Ich sitze an einem genatteten Rechner. Lade ich auf dem Gateway ip_conntrack_ftp.o and ip_nat_ftp.o, so kann ich auch aktives FTP betreiben.
Gut, das wollte ich wissen. Mein nächste Frage ist, wie die Regel in der FORWARD-Chain auszusehen hat. Ich habe eine STATE-Chain, in der geprüft, wird, ob ESTABLISHED oder RELATED und danach ist ein RETURN in die FORWARD. Trotzdem müßte ich doch jetzt bei Angabe der Regeln sowas in
Ich habe in FORWARD nur ACCEPT.
Wenn Du filtern willst, dann setze doch erst mal Deine Filterregeln und mache dann ein LOG und dann REJECT. Lies dann ganz einfach im Logfile nach.
Andreas
Hi Carsten,
On Wed, May 26, 2004 at 08:45:29 +0200, Carsten Friede wrote:
Leider ist das bei ftp etwas anders. Es ist aus meiner Sicht ein veraltetes Protokoll was nicht mehr benutzt werden sollte.
Mag sein, aber es ist immer noch der komfortabelste Weg Daten auszutauschen.
NACK scp/sftp existiert. Mit shfs[1] kann man sich den scp-Zugriff sogar ins Dateisystem einhaengen, komfortabler gehts nicht mehr. Fuer reinen sftp-Dateizugriff ohne ssh-Login gibts ausserdem noch sshjail[2] (chrooted sshd/sftp-server). Alles laeuft firewallfreundlich ueber eine TCP-Verbindung, die vom Client aus aufgebaut wird.
[1] http://shfs.sourceforge.net/ [2] http://chris.silmor.de/sshjail-0.2.tar.gz
bye, Chris
lug-dd@mailman.schlittermann.de
-
Andreas Kretschmer -
Andreas Kretschmer -
Carsten Friede -
Christian Perle -
Jonas Witt -
Thomas Guettler