[Firehol-support] FTP rule problem (bug?)

[Ian Duggan]

The FTP rules seem to be a bit too aggressive. I'm trying to block incoming 
FTP requests to a server, and it is having the effect of blocking a good 
amount of outbound traffic. Ie, I can't telnet to a mysql port from this 
machine when the rules are in place. Relevant firehol.conf:

# DMZ rules
interface eth+ dmz src "${dmz}"
        policy return
        protection strong

        server ssh        accept
        server dns        accept
        server http       accept
        server https      accept
        server smtp       accept
        server icmp       accept
        server zopehttp   accept
        server nfs        accept
        server portmap    accept
        server ftp        drop

        client all accept

        server ident reject with tcp-reset


This set of definitions produces the following iptables setup which appears to 
be faulty. The problem seems to be the last item in the out_dmz_ftp_s10 
chain, which causes a large swath of traffic types to be dropped. It is 
appearing before the out_dmz_ftp_c13 chain which looks like it would 
alleviate this effect. 

Chain out_dmz (1 references)
 pkts bytes target     prot opt in     out     source          destination
    1    60 out_dmz_ssh_s1  all  --  *      *    0.0.0.0/0       0.0.0.0/0
    1    60 out_dmz_dns_s2  all  --  *      *    0.0.0.0/0       0.0.0.0/0
    1    60 out_dmz_http_s3  all  --  *      *    0.0.0.0/0       0.0.0.0/0
    1    60 out_dmz_https_s4  all  --  *      *    0.0.0.0/0       0.0.0.0/0
    1    60 out_dmz_smtp_s5  all  --  *      *    0.0.0.0/0       0.0.0.0/0
    1    60 out_dmz_icmp_s6  all  --  *      *    0.0.0.0/0       0.0.0.0/0
    1    60 out_dmz_zopehttp_s7  all  --  *      *    0.0.0.0/0      0.0.0.0/0
    1    60 out_dmz_nfs_s8  all  --  *      *    0.0.0.0/0       0.0.0.0/0
    1    60 out_dmz_portmap_s9  all  --  *      *    0.0.0.0/0       0.0.0.0/0
    1    60 out_dmz_ftp_s10  all  --  *      *    0.0.0.0/0       0.0.0.0/0
    1    60 out_dmz_all_c11  all  --  *      *    0.0.0.0/0       0.0.0.0/0
    0     0 out_dmz_irc_c12  all  --  *      *    0.0.0.0/0       0.0.0.0/0
    0     0 out_dmz_ftp_c13  all  --  *      *    0.0.0.0/0       0.0.0.0/0
    0     0 out_dmz_ident_s14  all  --  *      *    0.0.0.0/0       0.0.0.0/0

Chain out_dmz_all_c11 (1 references)
 pkts bytes target     prot opt in     out     source     destination
    1    60 ACCEPT     all  --  *      *       0.0.0.0/0  0.0.0.0/0   state 
NEW,ESTABLISHED

Chain out_dmz_ftp_c13 (1 references)
 pkts bytes target     prot opt in     out     source     destination
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0  0.0.0.0/0   tcp 
spts:32768:61000 dpt:21 state NEW,ESTABLISHED
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0  0.0.0.0/0   tcp 
spts:32768:61000 dpt:20 state ESTABLISHED
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0  0.0.0.0/0   tcp 
spts:32768:61000 dpts:1024:65535 state RELATED,ESTABLISHED

Chain out_dmz_ftp_s10 (1 references)
 pkts bytes target     prot opt in     out     source     destination
    0     0 DROP       tcp  --  *      *       0.0.0.0/0  0.0.0.0/0   tcp 
spt:21 dpts:1024:65535 state ESTABLISHED
    0     0 DROP       tcp  --  *      *       0.0.0.0/0  0.0.0.0/0   tcp 
spt:20 dpts:1024:65535 state RELATED,ESTABLISHED
    0     0 DROP       tcp  --  *      *       0.0.0.0/0  0.0.0.0/0   tcp 
spts:32768:61000 dpts:1024:65535 state ESTABLISHED

I am going to work around this by moving my client definitions higher up in 
the chain, but this looks like it might be a bug.

--Ian