ip_conntrack_ftp and ip_nat_ftp

Pastorino · 07-19-2004, 09:46 AM

Hello everyone,

I'm using Fedora Core 1, and I'm trying to use ip_conntrack_ftp and ip_nat_ftp without success.

Here's an excerpt of the firewall script I'm using:

========== BEGIN

INT=eth0
DMZ=eth1
FTPSERVER=192.168.0.4

/sbin/modprobe ip_conntrack
/sbin/modprobe ip_conntrack_ftp
/sbin/modprobe ip_nat_ftp

iptables -A FORWARD -p tcp -i $DMZ -o $INT --sport 20 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p tcp -i $INT -o $DMZ --dport 20 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p tcp -i $INT -o $DMZ -s 0/0 -d $FTPSERVER --syn --dport 21 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -i $INT -d $VALID_IP --dport 21 -j DNAT --to-destination $FTPSERVER

========== END

When someone tries to connect to the FTP server using active mode, I get:

kernel: FORWARD blocked: IN=eth1 OUT=eth0 SRC=192.168.0.4 DST=(valid ip) (...) PROTO=TCP SPT=20 DPT=50918 WINDOW=65535 RES=0x00 SYN URGP=0

What am I doing wrong?

Thanks,

Carlos Pastorino

newpenguin · 07-19-2004, 02:41 PM

modify first rule and add a NEW

iptables -A FORWARD -p tcp -i $DMZ -o $INT --sport 20 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

then tell if it works or not

Pastorino · 07-19-2004, 05:55 PM

Yes, it does work. But the point is: it should work without the NEW state, as reported in this document:

http://www.sns.ias.edu/~jns/security...conntrack.html

Here's an excerpt:

"Enter the ip_conntrack_ftp module. This module is able to recognize the PORT command and pick-out the port number. As such, the ftp-data connection can be classified as RELATED to the original outgoing connection to port 21 so we don't need NEW as a state match for the connection in the INPUT chain. The following rules will serve our purposes grandly:

iptables -A INPUT -p tcp --sport 20 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 20 -m state --state ESTABLISHED -j ACCEPT "

Thanks,

Carlos Pastorino

newpenguin · 07-19-2004, 06:03 PM

as far as my little knowledge says
the server first sends the syn packet (src port 20) to establish the connection.

so state NEW is needed.

may be i am wrong.

check through tcpdump and tell.

radien · 08-15-2004, 11:25 PM

I do agree with, Pastorino, I tried such configuration before. Here is the script:

Code:

#!/bin/bash
# IPTABELES Configuration Script
# iptables.conf.sh
#
# Create:	March 27th 2004 - by ****
# Modify:
# 	not yet

#Interfaces
IF0='192.168.0.67'
IF1='192.168.10.67'

#LAN's
LAN0='192.168.0.0/24'
LAN1='192.168.10.0/24'

#Others
INFRA='192.168.0.12'
CONTROLLER='192.168.0.30'
ISA_SERVER='192.168.0.12'

###############################################
#Flush all the tables
service iptables stop
#iptables -F OUTPUT
#iptables -F FORWARD
#iptables -F INPUT

#allow everything go through
iptables -P INPUT DROP
iptables -P OUTPUT DROP

#suite 1 //not enough
#iptables -t filter -A FORWARD -i eth0 -o eth1 -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
#iptables -t filter -A FORWARD -i eth1 -o eth0 -p tcp --dport 21 -j ACCEPT

#suite 2 //works for passive and active data connection 
#iptables -t filter -A INPUT -i eth0 -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
#iptables -t filter -A OUTPUT -o eth0 -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
#iptables -t filter -A INPUT -i eth0 -p tcp --dport 21 -j ACCEPT

#suite 3  //incorrect
#iptables -t filter -A INPUT -i eth0 -p tcp -m state --state NEW,RELATED,ESTABLISHED --dport 21 -j ACCEPT

#suite 4  //just works for active data connections
#iptables -t filter -A INPUT -i eth0 -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
#iptables -t filter -A OUTPUT -o eth0 -p tcp -m state --state ESTABLISHED -j ACCEPT
#iptables -t filter -A INPUT -i eth0 -p tcp --dport 21 -j ACCEPT

#suite 5  //just works for passive data connections
iptables -t filter -A INPUT -i eth0 -p tcp -m state --state ESTABLISHED -j ACCEPT
iptables -t filter -A OUTPUT -o eth0 -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A INPUT -i eth0 -p tcp --dport 21 -j ACCEPT

###############################################################

#finally save eveything
#iptables-save

I tested this script with kernel 2.4(Redhat Shrike).
But about loading modules, I think some considerations should be applied that I do not know much about it.

siblin · 08-24-2004, 10:57 AM

Just a wild stab in the dark for you.

It looks like you are using modprobe before your first iptables command. Could it be that by this stage you do not have the required "parents" for these modules? my lsmod looks like -

ip_nat_ftp 3056 0 (unused)
ip_conntrack_ftp 3456 0 (unused)
ipt_LOG 3320 1 (autoclean)
ipt_REJECT 2712 1 (autoclean)
ipt_state 568 2 (autoclean)
iptable_filter 1644 1 (autoclean)
ipt_MASQUERADE 1240 1 (autoclean)
iptable_nat 13688 2 (autoclean) [ip_nat_ftp ipt_MASQUERADE]
ip_conntrack 14140 3 (autoclean) [ip_nat_ftp ip_conntrack_ftp ipt_state ipt_MASQUERADE iptable_nat]
ip_tables 11576 8 [ipt_LOG ipt_REJECT ipt_state iptable_filter ipt_MASQUERADE iptable_nat]

if you are using kernel module autoloader then running iptables will add most of these automatically.

Then again modprobe i think is supposed to load all of its children, but i use insmod after i have loaded my rules and mine works... and yes i use the rule

-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

may well allow some insecurities but really cuts down the latency of traversing the ruleset and any clients on the inside can access remote FTP servers with active FTP.

Oh by the way... you are looking in the right direction arn't you (i think by your rules and the error message that came back you are)? FTP connection usually tracking needs to be done on the CLIENTS firewall, not the firewall protecting the server (ok in your case the same thing i think), as the firewall protecting the server will usually be configured to allow traffic back out with little or no restrictions.