Skip to contentSkip to conversation

Debian 2.6.8/bridge/iptables/passive ftp

DISCUSSION [email protected] 4 participants 4 messages Mar 30, 2007 – Mar 31, 2007

lore
Share & tools
lore

[email protected]

author
#0 lore raw

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

#1 lore raw

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

Quoted 71 lines · On Fri, 2007-03-30 at 14:15 +0200, [email protected] 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]
(quoted diff) +0 -2
-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

Signature · 3 lines
Raymond Leach
RCHQ Hobbies (http://www.rchq.co.za/)
(T)+27-82-575-6975 (F)+27-86-652-2773
#2 lore raw
In reply to [email protected]
Quoted 9 lines · [email protected] 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

#3 lore raw
In reply to [email protected]

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

Quoted 73 lines · [email protected] 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]
(quoted diff) +0 -2
-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