ip_conntrack_ftp problem

ip_conntrack_ftp problem

[Budai Laszlo]

we use Redhat Linux 8 to connect our lan to the internet. Internally we 
are using private addresses which are SNAT-ed (MASQUERADE) by the linux box.

We set up a firewall which in the forward chain looks like:

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere           state RELATED
ACCEPT     tcp  --  192.168.101.25       anywhere           tcp dpt:telnet
ACCEPT     tcp  --  192.168.101.24       anywhere           tcp dpt:telnet
ACCEPT     tcp  --  192.168.101.0/24     anywhere           tcp dpt:ldap
ACCEPT     tcp  --  192.168.101.0/24     anywhere           tcp dpt:imap
ACCEPT     tcp  --  192.168.101.0/24     anywhere           tcp dpt:rtsp
ACCEPT     tcp  --  192.168.101.0/24     anywhere           tcp dpt:cvspserver
ACCEPT     tcp  --  192.168.101.0/24     anywhere           tcp dpt:cvspserver
ACCEPT     tcp  --  192.168.101.0/24     anywhere           tcp dpt:5190
ACCEPT     tcp  --  192.168.101.0/24     anywhere           tcp dpt:squid
ACCEPT     tcp  --  192.168.101.0/24     anywhere           tcp dpt:https
ACCEPT     udp  --  192.168.101.0/24     anywhere           udp dpt:domain
ACCEPT     udp  --  192.168.101.0/24     anywhere           udp dpt:7070
ACCEPT     tcp  --  192.168.101.0/24     anywhere           tcp dpt:7070
ACCEPT     tcp  --  192.168.101.0/24     anywhere           tcp dpt:https
ACCEPT     tcp  --  192.168.101.0/24     anywhere           tcp dpt:5050
ACCEPT     tcp  --  192.168.101.0/24     anywhere           tcp dpt:pop3
ACCEPT     tcp  --  192.168.101.0/24     anywhere           tcp dpt:http
ACCEPT     tcp  --  192.168.101.0/24     anywhere           tcp dpt:domain
ACCEPT     tcp  --  192.168.101.0/24     anywhere           tcp dpt:smtp
ACCEPT     tcp  --  192.168.101.0/24     anywhere           tcp dpt:ssh
ACCEPT     tcp  --  192.168.101.0/24     anywhere           tcp dpt:ftp
ACCEPT     tcp  --  192.168.101.0/24     anywhere           tcp dpt:ftp-data
DROP       tcp  --  192.168.101.0/24     anywhere


so we try to limit the access just to a few accepted services. We are 
loading the ip_conntrack_ftp and ip_nat_ftp modules:

# lsmod
Module                  Size  Used by    Not tainted
ipt_state               1080   1  (autoclean)
cls_u32                 6332   2  (autoclean)
sch_cbq                14912   2  (autoclean)
ip_nat_ftp              4240   0  (unused)
ip_conntrack_ftp        5088   0  (unused)
eepro100               22264   1
8139too                17736   1
mii                     2156   0  [8139too]
iptable_mangle          2776   1  (autoclean)
ipt_MASQUERADE          2200   0  (autoclean)
ipt_REDIRECT            1368   3  (autoclean)
iptable_nat            19960   2  (autoclean) [ip_nat_ftp ipt_MASQUERADE ipt_REDIRECT]
ip_conntrack           21244   3  (autoclean) [ipt_state ip_nat_ftp ip_conntrack_ftp ipt_MASQUERADE ipt_REDIRECT iptable_nat]
iptable_filter          2412   1  (autoclean)
ip_tables              15224   8  [ipt_state iptable_mangle ipt_MASQUERADE ipt_REDIRECT iptable_nat iptable_filter]
mousedev                5524   0  (unused)
keybdev                 2976   0  (unused)
hid                    22244   0  (unused)
input                   5920   0  [mousedev keybdev hid]
usb-uhci               26188   0  (unused)
usbcore                77024   1  [hid usb-uhci]
ext3                   70336   3
jbd                    52212   3  [ext3]
sym53c8xx              68240   4
sd_mod                 13552   8
scsi_mod              107176   2  [sym53c8xx sd_mod]


but ftp trough the firewall still does not work. :(
what is wrong?

Thanks,
Laszlo

Re: ip_conntrack_ftp problem

[Vincent Lim]

On Fri, 2003-03-28 at 15:40, Budai Laszlo wrote:

> Chain FORWARD (policy ACCEPT)

<snipped the rest>

> ACCEPT     tcp  --  192.168.101.0/24     anywhere           tcp dpt:ftp
> ACCEPT     tcp  --  192.168.101.0/24     anywhere           tcp dpt:ftp-data
> DROP       tcp  --  192.168.101.0/24     anywhere

<snipped more>

> but ftp trough the firewall still does not work. :(
> what is wrong?

I would think that the replying packets can't get back.
Try putting a:
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

-- 
Vincent Lim <vincent.lim@nestac.com>
NESTAC Solution Sdn Bhd

RE: ip_conntrack_ftp problem

[Michael K]

> -----Original Message-----
> From: netfilter-admin@lists.netfilter.org 
> [mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Budai Laszlo
> Sent: Friday, March 28, 2003 8:41 AM
> To: netfilter@lists.netfilter.org
> Subject: ip_conntrack_ftp problem
> 
> 
> 
> 
> we use Redhat Linux 8 to connect our lan to the internet. 
> Internally we 
> are using private addresses which are SNAT-ed (MASQUERADE) by 
> the linux box.
> 
> We set up a firewall which in the forward chain looks like:
> 
> Chain FORWARD (policy ACCEPT)
> target     prot opt source               destination
> ACCEPT     all  --  anywhere             anywhere           
> state RELATED
> ACCEPT     tcp  --  192.168.101.25       anywhere           
> tcp dpt:telnet
> ACCEPT     tcp  --  192.168.101.24       anywhere           
> tcp dpt:telnet
> ACCEPT     tcp  --  192.168.101.0/24     anywhere           
> tcp dpt:ldap
> ACCEPT     tcp  --  192.168.101.0/24     anywhere           
> tcp dpt:imap
> ACCEPT     tcp  --  192.168.101.0/24     anywhere           
> tcp dpt:rtsp
> ACCEPT     tcp  --  192.168.101.0/24     anywhere           
> tcp dpt:cvspserver
> ACCEPT     tcp  --  192.168.101.0/24     anywhere           
> tcp dpt:cvspserver
> ACCEPT     tcp  --  192.168.101.0/24     anywhere           
> tcp dpt:5190
> ACCEPT     tcp  --  192.168.101.0/24     anywhere           
> tcp dpt:squid
> ACCEPT     tcp  --  192.168.101.0/24     anywhere           
> tcp dpt:https
> ACCEPT     udp  --  192.168.101.0/24     anywhere           
> udp dpt:domain
> ACCEPT     udp  --  192.168.101.0/24     anywhere           
> udp dpt:7070
> ACCEPT     tcp  --  192.168.101.0/24     anywhere           
> tcp dpt:7070
> ACCEPT     tcp  --  192.168.101.0/24     anywhere           
> tcp dpt:https
> ACCEPT     tcp  --  192.168.101.0/24     anywhere           
> tcp dpt:5050
> ACCEPT     tcp  --  192.168.101.0/24     anywhere           
> tcp dpt:pop3
> ACCEPT     tcp  --  192.168.101.0/24     anywhere           
> tcp dpt:http
> ACCEPT     tcp  --  192.168.101.0/24     anywhere           
> tcp dpt:domain
> ACCEPT     tcp  --  192.168.101.0/24     anywhere           
> tcp dpt:smtp
> ACCEPT     tcp  --  192.168.101.0/24     anywhere           
> tcp dpt:ssh
> ACCEPT     tcp  --  192.168.101.0/24     anywhere           
> tcp dpt:ftp
> ACCEPT     tcp  --  192.168.101.0/24     anywhere           
> tcp dpt:ftp-data
> DROP       tcp  --  192.168.101.0/24     anywhere
> 
> 
> so we try to limit the access just to a few accepted services. We are 
> loading the ip_conntrack_ftp and ip_nat_ftp modules:
> 
> # lsmod
> Module                  Size  Used by    Not tainted
> ipt_state               1080   1  (autoclean)
> cls_u32                 6332   2  (autoclean)
> sch_cbq                14912   2  (autoclean)
> ip_nat_ftp              4240   0  (unused)
> ip_conntrack_ftp        5088   0  (unused)
> eepro100               22264   1
> 8139too                17736   1
> mii                     2156   0  [8139too]
> iptable_mangle          2776   1  (autoclean)
> ipt_MASQUERADE          2200   0  (autoclean)
> ipt_REDIRECT            1368   3  (autoclean)
> iptable_nat            19960   2  (autoclean) [ip_nat_ftp 
> ipt_MASQUERADE ipt_REDIRECT]
> ip_conntrack           21244   3  (autoclean) [ipt_state 
> ip_nat_ftp ip_conntrack_ftp ipt_MASQUERADE ipt_REDIRECT iptable_nat]
> iptable_filter          2412   1  (autoclean)
> ip_tables              15224   8  [ipt_state iptable_mangle 
> ipt_MASQUERADE ipt_REDIRECT iptable_nat iptable_filter]
> mousedev                5524   0  (unused)
> keybdev                 2976   0  (unused)
> hid                    22244   0  (unused)
> input                   5920   0  [mousedev keybdev hid]
> usb-uhci               26188   0  (unused)
> usbcore                77024   1  [hid usb-uhci]
> ext3                   70336   3
> jbd                    52212   3  [ext3]
> sym53c8xx              68240   4
> sd_mod                 13552   8
> scsi_mod              107176   2  [sym53c8xx sd_mod]
> 
> 
> but ftp trough the firewall still does not work. :(
> what is wrong?
> 
> Thanks,
> Laszlo
> 
I'm sure that active ftp works. Active FTP uses port TCP/20 for data
channel. Passive ftp uses > TCP/1023
So
Active FTP uses TCP port 21 and 20
Passive FTP uses TCP port 21 and > 1023

/Klintan

Re: ip_conntrack_ftp problem

[Budai Laszlo]

Thanks, this solved  my problem. However, if you check my first post you 
can see thet in the FORWARD chain I had :

ACCEPT     all  --  anywhere             anywhere           state RELATED

but seems it was not enough ... :(  and I don't  understand. isn't your 
rule more restrictiv (state RELATED, ESTABILISHED) than my old rule 
(just related)?

Thanks again,
Laszlo

Vincent Lim wrote:

>On Fri, 2003-03-28 at 15:40, Budai Laszlo wrote:
>
>  
>
>>Chain FORWARD (policy ACCEPT)
>>    
>>
>
><snipped the rest>
>
>  
>
>>ACCEPT     tcp  --  192.168.101.0/24     anywhere           tcp dpt:ftp
>>ACCEPT     tcp  --  192.168.101.0/24     anywhere           tcp dpt:ftp-data
>>DROP       tcp  --  192.168.101.0/24     anywhere
>>    
>>
>
><snipped more>
>
>  
>
>>but ftp trough the firewall still does not work. :(
>>what is wrong?
>>    
>>
>
>I would think that the replying packets can't get back.
>Try putting a:
>iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
>
>  
>

Re: ip_conntrack_ftp problem

[Vincent Lim]

On Fri, 2003-03-28 at 17:43, Budai Laszlo wrote:
> Thanks, this solved  my problem. However, if you check my first post you 
> can see thet in the FORWARD chain I had :
> 
> ACCEPT     all  --  anywhere             anywhere           state RELATED
> 
> but seems it was not enough ... :(  and I don't  understand. isn't your 
> rule more restrictiv (state RELATED, ESTABILISHED) than my old rule 
> (just related)?

RELATED is for the ftp-data connection that is established after initial
connection attempt.
ESTABLISHED is for the original replies, which I think the server would
first used until a second/other connection is negotiated.

My $0.02

-- 
Vincent Lim <vincent.lim@nestac.com>
NESTAC Solution Sdn Bhd

Re: ip_conntrack_ftp problem

[Cedric Blancher]

Le ven 28/03/2003 à 11:19, Vincent Lim a écrit :
> RELATED is for the ftp-data connection that is established after initial
> connection attempt.

To be precise, RELATED is only for the packet that initiates ftp-data
connection. Following ones will be ESTABLISHED.

A RELATED packet is similar to a NEW one, except that conntrack was
waiting for him.

-- 
Cédric Blancher  <blancher@cartel-securite.fr>
IT systems and networks security - Cartel Sécurité
Phone : +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: ip_conntrack_ftp problem

[Vincent Lim]

On Fri, 2003-03-28 at 18:43, Cedric Blancher wrote:
> Le ven 28/03/2003 à 11:19, Vincent Lim a écrit :
> > RELATED is for the ftp-data connection that is established after initial
> > connection attempt.
> 
> To be precise, RELATED is only for the packet that initiates ftp-data
> connection. Following ones will be ESTABLISHED.
> 
> A RELATED packet is similar to a NEW one, except that conntrack was
> waiting for him.

The below excerpt is taken from this url:
http://www.linuxsecurity.com/resource_files/firewalls/IPTables-Tutorial
/iptables-tutorial.html#STATEMACHINE
(url is wrapped)

RELATED
<snipped beginning>
..that it is RELATED. Some good examples of connections that can be
considered as RELATED are the FTP-data connections that are considered
RELATED to the FTP control port, and the DCC connections issued through
IRC. This could be used to allow ICMP replies, FTP transfers and DCC's
to work properly through the firewall. Do note that most TCP protocols
and some UDP protocols that rely on this mechanism are quite complex and
send connection information within the payload of the TCP or UDP data
segments, and hence require special helper modules to be correctly
understood.

So, initially..the replying packets need to match the ESTABLISHED?
(I'm asking this because Budai's initial rules only had RELATED and his
ftp wasn't working)

Then after establishing the RELATED ftp-data, subsequent packets match
the ESTABLISHED again?

-- 
Vincent Lim <vincent.lim@nestac.com>
NESTAC Solution Sdn Bhd

Re: ip_conntrack_ftp problem

[Jozsef Kadlecsik]

On 28 Mar 2003, Cedric Blancher wrote:

> Le ven 28/03/2003 à 11:19, Vincent Lim a écrit :
> > RELATED is for the ftp-data connection that is established after initial
> > connection attempt.
>
> To be precise, RELATED is only for the packet that initiates ftp-data
> connection. Following ones will be ESTABLISHED.
>
> A RELATED packet is similar to a NEW one, except that conntrack was
> waiting for him.

No, that's not true. Every packet handled by the helpers are RELATED.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: ip_conntrack_ftp problem

[blancher]

Re: ip_conntrack_ftp problem

[blancher]

Re: ip_conntrack_ftp problem

[Cedric Blancher]

Le ven 28/03/2003 à 13:17, Jozsef Kadlecsik a écrit :
> On 28 Mar 2003, Cedric Blancher wrote:
> > A RELATED packet is similar to a NEW one, except that conntrack was
> > waiting for him.
> No, that's not true. Every packet handled by the helpers are RELATED.

I may be wrong, but that's not what my experience says :

root@elendil:~# iptables --version
iptables v1.2.7a
root@elendil:~# iptables -F INPUT
root@elendil:~# iptables -A INPUT -m helper --helper ftp -m state --state RELATED -j LOG --log-prefix 'RELATED_FTP '
root@elendil:~# iptables -A INPUT -m helper --helper ftp -m state --state ESTABLISHED -j LOG --log-prefix 'ESTABLISHED_FTP '
root@elendil:~# iptables -L INPUT
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
LOG        all  --  anywhere             anywhere           helper match "ftp" state RELATED LOG level warning prefix `RELATED_FTP '
LOG        all  --  anywhere             anywhere           helper match "ftp" state ESTABLISHED LOG level warning prefix `ESTABLISHED_FTP '

Then I open a FTP connection, grabbing a file list via ls using active
FTP so I can see RELATED ftp-data opening :

root@elendil:~# tail -f /var/log/messages
[...]
Mar 28 13:38:50 elendil kernel: RELATED_FTP IN=eth0 OUT= MAC=xx SRC=192.168.1.4 DST=192.168.1.3 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=2955 DF PROTO=TCP SPT=20 DPT=34777 WINDOW=5840 RES=0x00 SYN URGP=0
Mar 28 13:38:50 elendil kernel: ESTABLISHED_FTP IN=eth0 OUT= MAC=xx SRC=192.168.1.4 DST=192.168.1.3 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=2956 DF PROTO=TCP SPT=20 DPT=34777 WINDOW=5840 RES=0x00 ACK URGP=0
Mar 28 13:38:50 elendil kernel: ESTABLISHED_FTP IN=eth0 OUT= MAC=xx SRC=192.168.1.4 DST=192.168.1.3 LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=2957 DF PROTO=TCP SPT=20 DPT=34777 WINDOW=5840 RES=0x00 ACK PSH URGP=0
Mar 28 13:38:50 elendil kernel: ESTABLISHED_FTP IN=eth0 OUT= MAC=xx SRC=192.168.1.4 DST=192.168.1.3 LEN=1500 TOS=0x00 PREC=0x00 TTL=64 ID=2958 DF PROTO=TCP SPT=20 DPT=34777 WINDOW=5840 RES=0x00 ACK URGP=0
Mar 28 13:38:50 elendil kernel: ESTABLISHED_FTP IN=eth0 OUT= MAC=xx SRC=192.168.1.4 DST=192.168.1.3 LEN=569 TOS=0x00 PREC=0x00 TTL=64 ID=2959 DF PROTO=TCP SPT=20 DPT=34777 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0
Mar 28 13:38:50 elendil kernel: ESTABLISHED_FTP IN=eth0 OUT= MAC=xx SRC=192.168.1.4 DST=192.168.1.3 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=2960 DF PROTO=TCP SPT=20 DPT=34777 WINDOW=5840 RES=0x00 ACK URGP=0
[...]

(stripped MAC stuff for convenience)

I can see RELATED packet from server:20 to my station:34770 (first
line). Following packets (line 2, 4, 5 and 6) for this connection are
ESTABLISHED. So, the way I understand this behaviour, is that a RELATED
packet is like a NEW one, but has an expectation on which it will be
matched.


I built iptables with POM from CVS.

-- 
Cédric Blancher  <blancher@cartel-securite.fr>
IT systems and networks security - Cartel Sécurité
Phone : +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: ip_conntrack_ftp problem

[Jozsef Kadlecsik]

On 28 Mar 2003, Cedric Blancher wrote:

> Le ven 28/03/2003 à 13:17, Jozsef Kadlecsik a écrit :
> > On 28 Mar 2003, Cedric Blancher wrote:
> > > A RELATED packet is similar to a NEW one, except that conntrack was
> > > waiting for him.
> > No, that's not true. Every packet handled by the helpers are RELATED.
>
> I may be wrong, but that's not what my experience says :

No, you are correct. My stupidity goes to infinity. Sorry.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: ip_conntrack_ftp problem

[Cedric Blancher]

Le ven 28/03/2003 à 11:59, Vincent Lim a écrit :
> So, initially..the replying packets need to match the ESTABLISHED?
> (I'm asking this because Budai's initial rules only had RELATED and his
> ftp wasn't working)
> Then after establishing the RELATED ftp-data, subsequent packets match
> the ESTABLISHED again?

You have two connections :

	ftp
	ftp-data

First ftp connection packet is NEW, others are ESTABLISHED. Then, a
ftp-data connection is built. First ftp-data connection packet is
RELATED, others are ESTABLISHED.

Problem with Budai's ruleset is that it does not accept ESTABLISHED
packet in FORWARD chain, as you told him at first with the rule that
fixes the issue.

-- 
Cédric Blancher  <blancher@cartel-securite.fr>
IT systems and networks security - Cartel Sécurité
Phone : +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE