All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd-Hendrik Mathias <arnd-hendrik.mathias@nefkom.net>
To: netfilter@lists.netfilter.org
Subject: Re: Debian 2.6.8/bridge/iptables/passive ftp
Date: Sat, 31 Mar 2007 15:41:57 +0200	[thread overview]
Message-ID: <460E6525.2070007@nefkom.net> (raw)
In-Reply-To: <351646215@web.de>

Hi Jo,
the first thing I am wondering about is that you open ports 1024:65535 
while I would expect the initial data connection at port 20.
Nevertheless, the main problem you are facing is that you try to 
conntrack FTP on your own. FTP is a little bit too complex for that so 
you'll get by with a little help from your friend: The helper module may 
be the solution for your problem.
I built my linux from scratch so I cannot tell you much about any 
distributions or util packages, but my PC serves as gateway for the both 
of my local home-networks to the internet and my ftp routing works well 
so I paste the corresponding section of my configuration in order to 
give an example. Since you don't seem to be masquerading you can omit 
the last rule and replace the IP-adresses and interface names. Note that 
these rules only accept outgoing FTP connections, so if you're driving a 
server you'll have to add NEW to the --ctstate of the second rule.



###########################
# forwarding tcp sessions to global net #
###########################
*filter
-A FORWARD -s 10.0.0.0/255.255.255.224 -d ! 10.0.0.0/255.255.255.224 -i 
! ppp0 -o ppp0 -p tcp --dport 21 -m conntrack --ctstate NEW,ESTABLISHED 
-j ACCEPT
-A FORWARD -d 10.0.0.0/255.255.255.224 -s ! 10.0.0.0/255.255.255.224 -i 
ppp0 -o ! ppp0 -p tcp --sport 21 -m conntrack --ctstate ESTABLISHED -j 
ACCEPT
-A FORWARD -d 10.0.0.0/255.255.255.224 -s ! 10.0.0.0/255.255.255.224 -i 
ppp0 -o ! ppp0 -p tcp -m helper --helper ftp-21 -m conntrack --ctstate 
RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.0.0.0/255.255.255.224 -d ! 10.0.0.0/255.255.255.224 -i 
! ppp0 -o ppp0 -p tcp -m helper --helper ftp-21 -m conntrack --ctstate 
RELATED,ESTABLISHED -j ACCEPT
COMMIT

*nat
-A POSTROUTING -s 10.0.0.0/255.255.255.224 -o ppp0 -p tcp --dport 21 -m 
conntrack --ctstate NEW -j MASQUERADE
COMMIT



Good luck

Arnd-Hendrik


spaminator@web.de wrote:

>Hi there,
>
>I'm experiencing a strange problem when trying to FTP through a firewalling bridge.
>
>My FTP client connects to the FTP server ok. But when the client switches to passive mode to get the directory's file list I get 
>
>stuck.
>
>The bridge is running on a Debian Sarge box with kernel 2.6.8-3, iptables 1.2.11-10 and bridge-utils 1.0.4-1. The bridge is built from the physical devices eth0 and eth1.
>
>The bridge is assigned an IP address too to be able to manage it remotely. Hence the INPUT and OUTPUT rules in my /etc/firewall.up.rules. As far as I understood, iptables only uses the FORWARD chain for the bridged packets.
>
>Here is my /etc/firewall.up.rules:
>#
># is invoked by /etc/network/interfaces as pre-up for br0
>#
>*filter
>#
>:INPUT DROP [0:0]
># some input rules
>#
>:FORWARD DROP [0:0]
>-A FORWARD -m state --state INVALID -j DROP
>-A FORWARD -p icmp -j ACCEPT
># client to server
>-A FORWARD -p tcp -s ! 217.17.69.18/255.255.255.224 --sport 1024:65535 \
>	-d 217.17.69.18/255.255.255.224 --dport 21 \
>	-m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
>-A FORWARD -p tcp -s ! 217.17.69.18/255.255.255.224 --sport 1024:65535 \
>	-d 217.17.69.18/255.255.255.224 --dport 1024:65535 \
>	-m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
># server to client
>-A FORWARD -p tcp -s 217.17.69.18/255.255.255.224 --sport 21 \
>	-d ! 217.17.69.18/255.255.255.224 --dport 1024:65535 \
>	-m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
>-A FORWARD -p tcp -s 212.117.69.128/255.255.255.224 --sport 1024:65535 \
>	-d ! 217.17.69.18/255.255.255.224 --dport 1024:65535 \
>	-m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
># logging
>-A FORWARD -j ULOG --ulog-nlgroup 1
>#
>:OUTPUT DROP [0:0]
># some output rules
>#
>COMMIT
>#
>
>
>These are all rules in the FORWARD chain. Using "! --syn" or "-m state --state RELATED,ESTABLISHED" instead of "-m conntrack --ctstate RELATED,ESTABLISHED" leads to the same result:
>
>When I look into the logfile I find an entry where my client:somehighport tries to tcp the server:somehighport. To me it looks like the client seems to want to establish a data-connection and iptables does not recognize these packet as RELATED or ESTABLISHED.
>
>Just for the crack of it I temporarily added NEW to the second "client to server"-rule. With that it works fine, but leaves the boxes behind the bridge open for any attack on the high ports.
>
>http, https or anything else is working properly, if I implement them in the FORWARD chain.
>
>Any suggestions out there?
>
>bye and TIA
>Jo
>
>
>
>
>_______________________________________________________________
>SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
>kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192
>
>
>
>
>  
>


  parent reply	other threads:[~2007-03-31 13:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-30 12:15 Debian 2.6.8/bridge/iptables/passive ftp spaminator
2007-03-30 14:56 ` Ray Leach
2007-03-31  8:10 ` Martijn Lievaart
2007-03-31 13:41 ` Arnd-Hendrik Mathias [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-04-04 10:18 spaminator
2007-04-04 10:29 ` Jan Engelhardt
2007-04-04 17:37 ` Martijn Lievaart
2007-04-04 17:44 ` Pascal Hambourg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=460E6525.2070007@nefkom.net \
    --to=arnd-hendrik.mathias@nefkom.net \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.