RE: non-standard FTP ports and connection tracking

RE: non-standard FTP ports and connection tracking

[Kim Leandersson]

Put the line:
ip_conntrack_ftp ports=2121 
In your modules.autoload, when it should work fine for you.

//kim


> -----Original Message-----
> From: Alexandros Papadopoulos [mailto:apapadop@cmu.edu] 
> Sent: Monday, December 09, 2002 10:46 PM
> To: netfilter@lists.netfilter.org
> Subject: non-standard FTP ports and connection tracking
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi. I have a small problem with ftp_conntrack module (I guess).
> 
> Scenario:
> ======
> I run iptables 1.2.6a and an ftp server (publicfile) on a machine 
> directly connected to the Internet. Connection tracking works 
> fine when 
> the ftp server listens on the standard port (21), but seems to break 
> when I set the ftp server to listen to a non-standard high port (say, 
> 2121).
> 
> I set both incoming and outgoing default action to DROP, load the 
> connection tracking modules in my firewall script:
> 
> /sbin/modprobe ip_conntrack
> /sbin/modprobe ip_conntrack_ftp
> 
> and try to allow traffic for my ftp server only.
> 
> What happens:
> =========
> 
> If the ftp server uses port 21 (standard setup), it works fine:
> 
> [] ftpd listening on port 21
> [] client connects -> connection from high port to my 21 is 
> established [] client requests directory listing -> 
> connection from my high port to 
> another high port of the client is established
> 
> Rules: (all defaults are DROP)
> =================
> 
> ## Allow connections to our ftp server
> /sbin/iptables -A INPUT -p tcp --dport 21 -j ACCEPT
> 
> ## Allow data for incoming FTP to return back to sender 
> /sbin/iptables -A OUTPUT -p tcp --sport 21 --dport 1024: -m state 
> - --state ESTABLISHED,RELATED -j ACCEPT
> 
> ## Allow outgoing FTP (data) + HTTP replies
> /sbin/iptables -A OUTPUT -p tcp --sport 1024: --dport 1024: -m state 
> - --state ESTABLISHED,RELATED -j ACCEPT
> 
> 
> The problem:
> ========
> 
> But, when I set the server to listen to port 2121...:
> 
> [] ftpd listens on 2121
> [] client connects -> connection from high port to my 2121 
> established [] client requests directory listing -> netfilter 
> drops packets for the 
> new (but related) connection that tries to be established, and user 
> never sees the directory listing. Last packets that gets 
> through is the 
> one that carries the "150 Making transfer connection..." message.
> 
> The rules in this case have only the port number changed, but 
> here they 
> are in case I'm doing something wrong:
> 
> ## Allow connections to our ftp server
> /sbin/iptables -A INPUT -p tcp --dport 2121 -j ACCEPT
> 
> ## Allow outgoing FTP (data) + HTTP replies!
> /sbin/iptables -A OUTPUT -p tcp --sport 1024: --dport 1024: -m state 
> - --state ESTABLISHED,RELATED -j ACCEPT
> 
> ## Allow data for incoming FTP to return back to sender 
> /sbin/iptables -A OUTPUT -p tcp --sport 2121 --dport 1024: -m state 
> - --state ESTABLISHED,RELATED -j ACCEPT
> 
> 
> Any ideas?
> 
> - -A
> - -- 
> http://andrew.cmu.edu/~apapadop/pub_key.asc
> 3DAD 8435 DB52 F17B 640F  D78C 8260 0CC1 0B75 8265
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
> 
> iD8DBQE99Q8ugmAMwQt1gmURApAKAJwJtYh0HFT9A5IX2xI8hVICwydt8QCeNLti
> lE569iwhEPzYdRw4zHnsWAQ=
> =TM8O
> -----END PGP SIGNATURE-----
> 
> 
> 
> 

Re: non-standard FTP ports and connection tracking

[Alexandros Papadopoulos]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 09 December 2002 17:01, Kim Leandersson wrote:
> Put the line:
> ip_conntrack_ftp ports=2121
> In your modules.autoload, when it should work fine for you.

Thank you for the prompt answers.

I changed my module-loading commands in the iptables script to:

/sbin/modprobe ip_conntrack_ftp ports=2121

and it works like a charm.

Caveat: One needs to first remove the module completely (/sbin/rmmod), 
and then reload it with the new parameter.

Thanks again!

- -A
- -- 
http://andrew.cmu.edu/~apapadop/pub_key.asc
3DAD 8435 DB52 F17B 640F  D78C 8260 0CC1 0B75 8265
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE99SGigmAMwQt1gmURAvtbAJ4pOHnqLPQP6IALPcGYoXO0s/1GuwCeM/sX
Tcd1x/gE468uFCofUPHKrOM=
=Av8y
-----END PGP SIGNATURE-----

Re: non-standard FTP ports and connection tracking (redux)

[Alexandros Papadopoulos]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Actually, it doesn't work like a charm. It seems that only active 
connections can be established. When the client switches to passive 
mode, the SYN packets it sends to my ftp server never make it through. 
:-(

I have the following in my script:

## Insert connection-tracking modules.
/sbin/modprobe ipt_state
/sbin/modprobe ip_conntrack
/sbin/modprobe ip_conntrack_ftp ports=2121
#/sbin/modprobe ipt_owner

## Flush all rules
/sbin/iptables -F
## Delete all custom tables
/sbin/iptables -X
## Zero all counters
/sbin/iptables -Z

## Set default policy to DROP for all chains
/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT DROP

#####################
#### CHAIN INPUT ####
#####################

## Accept everything incoming on loopback interface
/sbin/iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1 -i lo -j ACCEPT

## Accept all incoming traffic from related or established connections
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

## Allow connections to our ftp server
/sbin/iptables -A INPUT -p tcp --dport 2121 -j ACCEPT


..but still, the packets with the SYN flag set when the client tries to 
establish the new data connection are dropped. Someone please tell me 
what am I missing? I'm sure it's something obvious but I can't seem to 
find it!

In case it helps, here's the output of /sbin/lsmod ^ip :

iptable_filter          2412   1  (autoclean)
ip_conntrack_ftp        5088   0  (unused)
ipt_state               1048   5
ip_conntrack           21244   2  [ip_conntrack_ftp ipt_state]
ip_tables              14936   2  [iptable_filter ipt_state]

(I don't do NAT - this is a single-homed machine)

Thanks

- -A
- -- 
http://andrew.cmu.edu/~apapadop/pub_key.asc
3DAD 8435 DB52 F17B 640F  D78C 8260 0CC1 0B75 8265
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE99VWPgmAMwQt1gmURAh/WAJ9SSTwSq4W3vIV2ZY+75JNIqHGyCwCfUkPf
3vAEp5uSYj7mUdrZcC/oCPE=
=QDnL
-----END PGP SIGNATURE-----

Re: non-standard FTP ports and connection tracking (redux)

[Jozsef Kadlecsik]

On Mon, 9 Dec 2002, Alexandros Papadopoulos wrote:

> /sbin/iptables -P OUTPUT DROP
>
> #####################
> #### CHAIN INPUT ####
> #####################
>
> ## Accept everything incoming on loopback interface
> /sbin/iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1 -i lo -j ACCEPT
>
> ## Accept all incoming traffic from related or established connections
> /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> ## Allow connections to our ftp server
> /sbin/iptables -A INPUT -p tcp --dport 2121 -j ACCEPT
>
> ..but still, the packets with the SYN flag set when the client tries to
> establish the new data connection are dropped. Someone please tell me
> what am I missing? I'm sure it's something obvious but I can't seem to
> find it!

What about the rules in the OUTPUT chain?

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: non-standard FTP ports and connection tracking (redux)

[Alexandros Papadopoulos]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 10 December 2002 02:52, Jozsef Kadlecsik wrote:
> On Mon, 9 Dec 2002, Alexandros Papadopoulos wrote:
> > /sbin/iptables -P OUTPUT DROP
> >
> > #####################
> > #### CHAIN INPUT ####
> > #####################
> >
> > ## Accept everything incoming on loopback interface
> > /sbin/iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1 -i lo -j ACCEPT
> >
> > ## Accept all incoming traffic from related or established
> > connections /sbin/iptables -A INPUT -m state --state
> > ESTABLISHED,RELATED -j ACCEPT
> >
> > ## Allow connections to our ftp server
> > /sbin/iptables -A INPUT -p tcp --dport 2121 -j ACCEPT
> >
> > ..but still, the packets with the SYN flag set when the client
> > tries to establish the new data connection are dropped. Someone
> > please tell me what am I missing? I'm sure it's something obvious
> > but I can't seem to find it!
>
> What about the rules in the OUTPUT chain?

Oops, I'm sorry. I actually tested with a default ACCEPT policy in the 
output chain to rule problems from there out, but forgot to mention it. 

In any case, the relevant rules from the output chain are:

## Allow outgoing FTP (data) + HTTP replies
/sbin/iptables -A OUTPUT -p tcp --sport 1024: --dport 1024: -m state 
- --state ESTABLISHED,RELATED -j ACCEPT

## Allow data for incoming FTP to return back to sender
/sbin/iptables -A OUTPUT -p tcp --sport 2121 --dport 1024: -m state 
- --state ESTABLISHED,RELATED -j ACCEPT

I'd bet that the problem is that the SYN request sent from the client to 
my server gets dropped, though. Seems like a conntrack/INPUT thing.

Thanks

- -A
- -- 
http://andrew.cmu.edu/~apapadop/pub_key.asc
3DAD 8435 DB52 F17B 640F  D78C 8260 0CC1 0B75 8265
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE99aHdgmAMwQt1gmURApc8AJ4rhcf4LzELDQ399VEuunF8VBnWYwCcDNlN
oY6E1VBYAM/mHufJen5YrDk=
=xJ8w
-----END PGP SIGNATURE-----

Re: non-standard FTP ports and connection tracking (redux)

[Jozsef Kadlecsik]

On Tue, 10 Dec 2002, Alexandros Papadopoulos wrote:

> In any case, the relevant rules from the output chain are:
                   ^^^^^^^^^^^^^^
Isn't there a rule intented for other purposes, which blocks the passive
data channel?

> I'd bet that the problem is that the SYN request sent from the client to
> my server gets dropped, though. Seems like a conntrack/INPUT thing.

I'd setup logging rules to see where and why the connection gets blocked.

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: non-standard FTP ports and connection tracking (redux)

[Alexandros Papadopoulos]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 10 December 2002 03:46, Jozsef Kadlecsik wrote:
> On Tue, 10 Dec 2002, Alexandros Papadopoulos wrote:
> > In any case, the relevant rules from the output chain are:
>
>                    ^^^^^^^^^^^^^^
> Isn't there a rule intented for other purposes, which blocks the
> passive data channel?

The default behavior is DROP for all chains, so if these ones don't 
allow it, then it is blocked. I thought these ones were sufficient. I'm 
attaching the complete ruleset I'm using.

>
> > I'd bet that the problem is that the SYN request sent from the
> > client to my server gets dropped, though. Seems like a
> > conntrack/INPUT thing.
>
> I'd setup logging rules to see where and why the connection gets
> blocked.
>

I've monitored the packets with Ethereal and seen that the problem is 
the one mentioned -- the SYN packet from the client that tries to open 
the data connection (when in passive mode) never makes it through the 
firewall.

The question is, why doesn't connection tracking pick this up and allow 
the packet to go through? (since it's a RELATED connection to a 
preexisting FTP session)

Thanks

- -A
- -- 
http://andrew.cmu.edu/~apapadop/pub_key.asc
3DAD 8435 DB52 F17B 640F  D78C 8260 0CC1 0B75 8265
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE99hPtgmAMwQt1gmURAgCAAJwMh/18DnsMuY3Zp/401XU4itDNbACdEeSj
8vvn0n0ot+Dbc0QuANY4+rY=
=9dZt
-----END PGP SIGNATURE-----

[-- Attachment #2: rules.gz --]
[-- Type: application/x-gzip, Size: 1336 bytes --]

Re: non-standard FTP ports and connection tracking (redux)

[Jozsef Kadlecsik]

On Tue, 10 Dec 2002, Alexandros Papadopoulos wrote:

> The default behavior is DROP for all chains, so if these ones don't
> allow it, then it is blocked. I thought these ones were sufficient. I'm
> attaching the complete ruleset I'm using.

Your ruleset seems to be all right. At some places strange, but seems to
be OK.

> > I'd setup logging rules to see where and why the connection gets
> > blocked.
>
> I've monitored the packets with Ethereal and seen that the problem is
> the one mentioned -- the SYN packet from the client that tries to open
> the data connection (when in passive mode) never makes it through the
> firewall.
>
> The question is, why doesn't connection tracking pick this up and allow
> the packet to go through? (since it's a RELATED connection to a
> preexisting FTP session)

I can repeat only myself: I'd setup logging rules to see where and why the
connection gets blocked.

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: non-standard FTP ports and connection tracking (redux)

[Joel Newkirk]

On Tuesday 10 December 2002 11:18 am, Alexandros Papadopoulos wrote:

> The default behavior is DROP for all chains, so if these ones don't
> allow it, then it is blocked. I thought these ones were sufficient.
> I'm attaching the complete ruleset I'm using.
>
> > > I'd bet that the problem is that the SYN request sent from the
> > > client to my server gets dropped, though. Seems like a
> > > conntrack/INPUT thing.
> >
> > I'd setup logging rules to see where and why the connection gets
> > blocked.

This is always useful.  Almost every time something unexpected is 
happening you can look at the logging from an attempted connection or 
two and quickly see where the packet appears, and where it doesn't.  Set 
a log rule as the first in each chain for just long enough to try a 
connection, disable the logging, and check the logs.  Just trace the 
appearance of the packets, and compare to what SHOULD happen. IE: if it 
shows up in PREROUTING and INPUT, then response in OUTPUT but not 
POSTROUTING, then it's being blocked in OUTPUT.  The log can also turn 
up instances where the addresses or port numbers are not what you 
expected when you built the rules.

> I've monitored the packets with Ethereal and seen that the problem is
> the one mentioned -- the SYN packet from the client that tries to open
> the data connection (when in passive mode) never makes it through the
> firewall.
>
> The question is, why doesn't connection tracking pick this up and
> allow the packet to go through? (since it's a RELATED connection to a
> preexisting FTP session)

Two questions.

1 - What is this supposed to achieve?
#### CHAIN FORWARD ####
#######################

#/sbin/iptables -t nat -A POSTROUTING -p tcp --dport 55555 -j REDIRECT 
--to-port 80

REDIRECT isn't a valid target in nat-POSTROUTING.  If you are trying to 
redirect anything outbound from the local box with destport 55555 and 
loop it back to destport 80 on the local box, this should be nat-OUTPUT.  
I can't see anything else you would be trying to do with this.

2 - Are you sure that FTP and HTTP replies will have source ports of 1024 
or higher?

## Allow outgoing FTP (data) + HTTP replies
/sbin/iptables -A OUTPUT -p tcp --sport 1024: --dport 1024: -m state 
--state ESTABLISHED,RELATED -j ACCEPT

Try this with no --sport match at all and see what happens.  be careful 
that you are not TOO specific in the matches you require.

j