Re: FTP Connection problems.

[Aleksandar Milivojevic <amilivojevic@pbl.ca>]

Vincent Blondel wrote:
> Hi all,
> 
> I a trying to initiate ftp connections to some of my servers but it
> doesn't work. You can find below a schema representing my three
> machines, client, firewall and ftp server. There is no NAT at the moment
> and the script I use on my firewall.

OK, let's go through it line by line...

> # Set the default policy to drop
> $fw --policy INPUT   DROP
> $fw --policy OUTPUT  DROP
> $fw --policy FORWARD DROP

These are OK, and recommended setting for firewall.

> $nat --policy PREROUTING  DROP
> $nat --policy OUTPUT      DROP
> $nat --policy POSTROUTING DROP
> 
> $mangle --policy PREROUTING  DROP
> $mangle --policy OUTPUT      DROP

With the above policies, you were dropping packets in PREROUTING chain 
before they ever had a chance to reach INPUT or FORWARD chains (same 
thing for POSTROUTING, packets are going there after (and if) they pass 
FORWARD or OUTPUT chains).  Also, make a note that packets will go 
through only one of INPUT (just before packet is delivered to local 
process), OUTPUT (as soon as packet is generated by local process), or 
FORWARD chains (packets that are not generated or to be delivered 
locally).  They will never go through two or all three of them.

Filter table is intended for general packet filtering, so that is the 
only table where (generally) you would set default policy to DROP.  (as 
a sidenote, you could use nat table for filtering if you don't care if 
origin and/or destination of packet is remote or local, but that isn't 
something you would generally do).

Nat table is intended for implementig NATed networks, and mangle is for 
general purpuse packet mangling (strange things you might want to do to 
packets).  They are not intended for packet filtering (although you can 
do it there too).  So you would leave those two with ACCEPT policy, and 
not implement any DROP rules there either.

There's a logic behind why all chains do not exist in all tables, and 
why you can't use all targets in all tables.  And basically the logic is 
based on for what the table was intended to be used.

> if [ "$CONN_TRACK" = "1" ]; then
> 	$fw -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> 	$fw -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> 	$fw -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> fi

I'd probably be more restrictive here, and allow only ESTABLISHED.  Than 
I would add separate generic rules for related ICMP packets (and you 
really want to add those if you remove RELATED from above lines), and 
then I would have rules for incoming related connections with helper 
module match for each one of them.  The ICMP thing would be something 
like (for INPUT, add similar for OUTPUT and FORWARD):

$fw -A INPUT -p icmp -m state --state RELATED -j ACCEPT

> # Incoming FTP requests
> iptables -A FORWARD -i eth0 -o eth1 -p tcp -s 192.168.124.1 --sport
> $UNPRIVPORTS -d 192.168.125.1 --dport 21 -m state --state NEW -j ACCEPT

This is OK.

> # Port Mode Data Channel Responses
> iptables -A FORWARD -i eth1 -o eth0 -p tcp -d 192.168.124.1 --sport 20
> --dport $UNPRIVPORTS -m state --state NEW -j ACCEPT

This is wrong.  The first packet of this connection will be in RELATED 
state, and the rest will be in ESTABLISHED state (if you load ftp helper 
module, as you should).  However, your generic rules for 
ESTABLISHED,RELATED will catch and accept this connection regardless of 
this line (read below why they are not working).  If you go with my 
advice of removing generic RELATED rule, than you would write it 
something like this (you'd need two lines):

# This will handle active FTP data transfers
iptables -A FORWARD -i eth1 -o eth0 \
    -p tcp -s 192.168.125.1 -d 192.168.124.1 \
    --sport 20 --dport $UNPRIVPORTS \
    -m helper --helper ftp \
    -m state --state RELATED -j ACCEPT

# This will handle passive FTP data transfers
iptables -A FORWARD -i eth0 -o eth1
    -p tcp -s 192.168.124.1 -d 192.168.125.1 \
    --sport $UNPRIVPORTS --dport $UNPRIVPORTS \
    -m helper --helper ftp \
    -m state --state RELATED -j ACCEPT

If you are going to have your generic RELATED,ESTABLISHED match, than 
you don't need any of those rules (you only need rule for allowing 
connection to FTP port 21).  Also, you can ommit specifying helper 
module, it's just that this way you are matching which helper marked the 
packet as related (security is paranoid by its nature ;-).

Also, for the related match, you will need to load FTP helper module (it 
doesn't get loaded automatically).  Without it, it isn't going to work. 
  The one you need is ip_conntrack_ftp.  You might also load ip_nat_ftp 
(which will in turn load ip_conntrack_ftp automatically, since it 
depends on it).  Add a line like this to your firewall script (anywhere 
in the script):

    modprobe ip_nat_ftp

You can even type it manually on command line (before or after you load 
the rules, doesn't matter).

After that, when you do lsmod | grep '^ip' you should see ip_nat_ftp and 
ip_conntrack_ftp loaded.

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7