Stateful firewalling via IPTABLES fails to track FTP passive connections?

Stateful firewalling via IPTABLES fails to track FTP passive connections?

[Hubris_1]

[-- Attachment #1: Type: text/plain, Size: 4007 bytes --]

All:

Hi and thanks in advance for any help you can provide.

I'm setting up a basic IPTables filter (IPTables v. 1.2.5 running on a RedHat Linux 7.3 machine).  Configuring the IPTABLES is pretty straightforward, except that IPTABLES does not detect the port change that occurs just after the server accepts the clients PASV request.  I've verified this is where the problem occurs via sniffer.  If I permit TCP to high unnumbered ports through the firewall (1024-65535), it works just fine.  Documentation I've read for IPTables implies that it should work for passive and for active ftp.

My firewall setup is listed below (its a work in progress for a test lab - thats why it only accepts the 10.x.x.x IPs).  The FTP server is tied to address 10.0.0.254, and is currently designed to accept connections from eth0.  Note the policy on chain OUTPUT is set to allow all packets, and FORWARD is set to statefully allow all traffic from eth0 to eth1 so I have not included them.  Line 30 is the config I've had to add to make passive ftp to the server work - but I would expect lines 13 and 11 to take care of it without having to add the final line.

So, my question boils down to this - does IPTables inspect the PASV request and reply to open the correct FTP data port if using stateful inspection?  Or do you essentially need to open all high-level ports to get passive FTP working?

I can provide the sniffs of what's occurring to any interested parties, but they clearly indicate that the FTP data channel (going to TCP port 1645 as I recall) is being blocked by the INPUT filter - the client tries several SYNs on this packet and never gets a SYN/ACK back.  I should note that this occurs after the FTP client has authenticated and directly after he performs an "ls" - it hangs at this point and eventually drops.


Chain INPUT (policy DROP 33404 packets, 2153K bytes)

num pkts bytes target prot opt in out source destination 

1 0 0 DROP all -- eth0 * 0.0.0.0/0 127.0.0.0/8 

2 0 0 DROP all -- eth1 * 0.0.0.0/0 127.0.0.0/8 

3 0 0 DROP all -- eth2 * 0.0.0.0/0 127.0.0.0/8 

4 18 10368 ACCEPT udp -- !eth2 * 0.0.0.0/0 255.255.255.255 udp spt:68 dpt:67 

5 4 2304 ACCEPT udp -- eth0 * 0.0.0.0/0 10.0.0.254 udp spt:68 dpt:67 

6 0 0 ACCEPT udp -- eth1 * 0.0.0.0/0 10.0.1.254 udp spt:68 dpt:67 

7 0 0 DROP all -- eth1 * !10.0.1.0/24 0.0.0.0/0 

8 63 4473 DROP all -- eth0 * !10.0.0.0/24 0.0.0.0/0 

9 0 0 DROP all -- eth2 * !10.0.2.0/24 0.0.0.0/0 

10 1996 166K ACCEPT all -- * * 127.0.0.0/8 127.0.0.0/8 

11 1802K 2418M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 

12 56 3308 ACCEPT tcp -- eth0 * 0.0.0.0/0 10.0.0.254 state NEW tcp dpt:22 

13 48 2758 ACCEPT tcp -- eth0 * 0.0.0.0/0 10.0.0.254 state NEW tcp dpt:21 

14 0 0 ACCEPT icmp -- eth2 * 0.0.0.0/0 10.0.2.254 icmp type 3 code 4 

15 0 0 ACCEPT icmp -- eth1 * 0.0.0.0/0 10.0.1.254 icmp type 3 code 4 

16 0 0 ACCEPT icmp -- eth0 * 0.0.0.0/0 10.0.0.254 icmp type 3 code 4 

17 0 0 ACCEPT icmp -- eth0 * 0.0.0.0/0 10.0.0.254 icmp type 0 

18 0 0 ACCEPT icmp -- eth1 * 0.0.0.0/0 10.0.1.254 icmp type 0 

19 0 0 ACCEPT icmp -- eth2 * 0.0.0.0/0 10.0.2.254 icmp type 0 

20 0 0 ACCEPT icmp -- eth2 * 0.0.0.0/0 10.0.2.254 icmp type 8 

21 4 280 ACCEPT icmp -- eth1 * 0.0.0.0/0 10.0.1.254 icmp type 8 

22 27 2004 ACCEPT icmp -- eth0 * 0.0.0.0/0 10.0.0.254 icmp type 8 

23 7297 466K ACCEPT udp -- !eth2 * 0.0.0.0/0 10.0.0.254 udp dpt:53 

24 0 0 ACCEPT udp -- eth0 * 0.0.0.0/0 10.0.0.254 udp dpts:137:139 

25 0 0 ACCEPT udp -- eth0 * 0.0.0.0/0 255.255.255.255 udp dpts:137:139 

26 0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 255.255.255.255 tcp dpts:137:139 

27 19 1020 ACCEPT tcp -- eth0 * 0.0.0.0/0 10.0.0.254 tcp dpts:137:139 

28 0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 10.0.0.255 tcp dpts:137:139 

29 13375 2387K ACCEPT udp -- eth0 * 0.0.0.0/0 10.0.0.255 udp dpts:137:139 

30 2260 136K ACCEPT tcp -- * * 0.0.0.0/0 10.0.0.254 tcp dpts:1025:65535 



Chris

[-- Attachment #2: Type: text/html, Size: 5275 bytes --]

Re: Stateful firewalling via IPTABLES fails to track FTP passive connections?

[Martijn Klingens]

On Sunday 06 October 2002 11:10, Hubris_1 wrote:
> So, my question boils down to this - does IPTables inspect the PASV request
> and reply to open the correct FTP data port if using stateful inspection?
> Or do you essentially need to open all high-level ports to get passive FTP
> working?

modprobe ip_conntrack_ftp
modprobe ip_nat_ftp

should do it.
-- 
Martijn

Re: Stateful firewalling via IPTABLES fails to track FTP passive connections?

[Antony Stone]

On Sunday 06 October 2002 10:10 am, Hubris_1 wrote:

> I'm setting up a basic IPTables filter (IPTables v. 1.2.5 running on a
> RedHat Linux 7.3 machine).  Configuring the IPTABLES is pretty
> straightforward, except that IPTABLES does not detect the port change that
> occurs just after the server accepts the clients PASV request.
>
> My firewall setup is listed below

Please post your ruleset in the form of the commands which create the rules.  
We don't have enough information from the listing output you've provided here.

Maybe it's just me, but I find understanding rulesets from the commands I 
would type in to make it work much easier than looking at the listing output 
from iptables -L

Thanks,

Antony.

-- 

KDE 3.0.3 contains an important fix for handling SSL certificates.  Users of 
Internet Explorer, which suffers from the same problem but which
does not yet have a fix available, are also encouraged to switch to KDE 3.0.3.

http://www.kde.org/announcements/announce-3.0.3.html