Debian 2.6.8/bridge/iptables/passive ftp

Debian 2.6.8/bridge/iptables/passive ftp

[spaminator]

Hi out there,

thanks for your replies.

@Ray
I already stumbled over http://slacksite.com/other/ftp.html and built my ruleset accordingly. As far as I understand you should be able to cater just for passive ftp.

@Arnd-Hendrik
I am not opening the high ports on the ftp server box. The (passive) ftp client sends the first request from a highport to port 21 on the server box. Have a look at the diagrams at slacksite. Which helper module do you refer to?

@Martijn
Your hint pointing to ip_conntrack_ftp lead to the solution. lsmod showed me that the module had not been loaded. After loading my ruleset worked and the clients could ftp properly.

Rebooting the bridge box left me again with an unloaded ip_conntrack_ftp. So I made an entry in /etc/modules which caters for the module to be loaded on (re)boot. Strange thing that, because other modules related to iptables are being loaded automatically, although they are not compiled into the kernel too. Are there other "surprise"-modules that have to be loaded via /etc/modules?

cu
Jo

_______________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

Re: Debian 2.6.8/bridge/iptables/passive ftp

[Jan Engelhardt]

On Apr 4 2007 12:18, spaminator@web.de wrote:
>
>Rebooting the bridge box left me again with an unloaded ip_conntrack_ftp. So I
>made an entry in /etc/modules which caters for the module to be loaded on
>(re)boot. Strange thing that, because other modules related to iptables are
>being loaded automatically, although they are not compiled into the kernel
>too. Are there other "surprise"-modules that have to be loaded via
>/etc/modules?

ip_nat_*
ip_conntrack_*

* = irc, nat, h323, etc. look into your /lib/modules dir.


Jan
-- 

Re: Debian 2.6.8/bridge/iptables/passive ftp

[Martijn Lievaart]

spaminator@web.de wrote:
> Rebooting the bridge box left me again with an unloaded ip_conntrack_ftp. So I made an entry in /etc/modules which caters for the module to be loaded on (re)boot. Strange thing that, because other modules related to iptables are being loaded automatically, although they are not compiled into the kernel too. Are there other "surprise"-modules that have to be loaded via /etc/modules?
>   

All the ip_conntrack_* modules, so all the connection helpers. You could 
load them all, but I only load what I need.

These modules are what account for (most of the) -m state --state 
RELATED matches. Related in this case are all the data connections for 
ftp, so you don't need any rule for those data connections.

IOW to make ftp work you need:

- To load ip_conntrack_ftp
- Have a rule that allows ESTABLISHED,RELATED
- Have a rule that allows the initial SYN to port 21.


HTH,
M4

Re: Debian 2.6.8/bridge/iptables/passive ftp

[Pascal Hambourg]

Hello,

spaminator@web.de a écrit :
> 
> Rebooting the bridge box left me again with an unloaded
> ip_conntrack_ftp. So I made an entry in /etc/modules which caters for
> the module to be loaded on (re)boot. Strange thing that, because other
> modules related to iptables are being loaded automatically, although
> they are not compiled into the kernel too. Are there other
> "surprise"-modules that have to be loaded via /etc/modules?

Only modules related to iptables rules are loaded automatically, when 
needed by a table, target or match in a newly created rule. Conntrack 
and NAT helper modules for special protocols (FTP, IRC DCC, TFTP, H.323, 
SIP...) are not related to any rule, thus not loaded automatically.

Debian 2.6.8/bridge/iptables/passive ftp

[spaminator]

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

Re: Debian 2.6.8/bridge/iptables/passive ftp

[Ray Leach]

Hi

There are 2 kinds of ftp, viz. passive and active. You only cater for
one. See this link for the details: http://slacksite.com/other/ftp.html

Regards

Ray

On Fri, 2007-03-30 at 14:15 +0200, 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
> 
> 
> 
> 
-- 
Raymond Leach
RCHQ Hobbies (http://www.rchq.co.za/)
(T)+27-82-575-6975 (F)+27-86-652-2773

Re: Debian 2.6.8/bridge/iptables/passive ftp

[Martijn Lievaart]

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.
>
>   

Did you load ip_conntrack_ftp?

M4

Re: Debian 2.6.8/bridge/iptables/passive ftp

[Arnd-Hendrik Mathias]

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
>
>
>
>
>  
>