Connection tracking FTP and ICMP

Connection tracking FTP and ICMP

[Csordás Csaba Ifj.]

Hi List,

I would like to ask you about the correctness of the information
published in a blog (www.sns.ias.edu/~jns/wp) around 2006.

The rules in the FTP part of the document seems too lazy for me and
the ICMP rules seems also "uncommon". But most probably _I'm wrong_
and need to further investigate.


Here is a copy of the webpage:
http://dl.dropbox.com/u/3715374/sns_ias_edu.pdf

Sorry for my bad English.

Regards,
Csord√°s Csaba Ifj.

Re: Connection tracking FTP and ICMP

[Neal Murphy]

On Sunday, November 04, 2012 04:23:59 PM Csordás Csaba Ifj. wrote:
> Hi List,
> 
> I would like to ask you about the correctness of the information
> published in a blog (www.sns.ias.edu/~jns/wp) around 2006.
> 
> The rules in the FTP part of the document seems too lazy for me and
> the ICMP rules seems also "uncommon". But most probably _I'm wrong_
> and need to further investigate.

When allowing conns, you need only specify port 21 when you have the FTP 
helper running. (These two rules normally include port 115 for sftp which is 
why I use 'multiport'.)

# Allow all outbound client ftp conns to remote servers (actually a
#   conn to anything listening on port 21, FTP or not).
iptables -A OUTPUT -o eth0 -p tcp -m multiport --dports 21 \
  -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

# Allow only related inbound (s)ftp conns to local clients
iptables -A INPUT -i eth0 -p tcp -m multiport --sports 21 \
  -m state --state RELATED,ESTABLISHED -j ACCEPT

The forward chain uses similar rules when passing packets between two 
interfaces. The FTP helper recognizes when the first packet of a new FTP DATA 
conn is related to an existing FTP CTRL conn, regardless of the DATA packet's 
src & dest ports.

This scheme works just great when allowing conns through the firewall.

[Digression]
The scheme falls down when using the 'time' functions to shut down existing 
conns. At least I haven't found a way to tell a rule to include *established 
conns related to this rule*. Once a conn becomes ESTABLISHED, the DATA conn's 
relation to its CTRL conn is lost; that is, it is no longer RELATED. Thus, 
these rules:

# Allow all outbound client ftp packets to remote servers. But first reject
#   them Mondays from 2AM to 5AM and reset the TCP conn.*
iptables -A OUTPUT -o eth0 -p tcp -m multiport --dports 21 \
  -m time --timestart 02:00:00 --timestop 05:00:00 --weekdays Mon \
  -m state --state NEW,RELATED,ESTABLISHED -j REJECT --reject-with tcp-reset
iptables -A OUTPUT -o eth0 -p tcp -m multiport --dports 21 \
  -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

# Allow only related/est'ed inbound ftp packets to local clients, but reject
#   them Mondays from 2AM to 5AM
iptables -A INPUT -i eth0 -p tcp -m multiport --sports 21 \
  -m time --timestart 02:00:00 --timestop 05:00:00 --weekdays Mon \
  -m state --state RELATED,ESTABLISHED -j REJECT --reject-with tcp-reset
iptables -A INPUT -i eth0 -p tcp -m multiport --sports 21 \
  -m state --state RELATED,ESTABLISHED -j ACCEPT

will reset only existing CTRL conns--and block new conn attempts--Mondays 
2AM-5AM. If you add port 20, they'll handle ACTV data conns. But while they 
can block new PASV conns, they can never see existing PASV data conns to reset 
them *because the ports in use cannot be known to the netfilter rules*.

Yes, I know I could use CONNMARKs to mark related conns, but that's a lot of 
extra rules. There should be a packet/conn state, perhaps something like 
RELCONN, that essentially says, "this rule also applies to packets belonging 
to conns that were RELATED to this rule." With such states, netfilter 
firewalls would become much more solid in that while it is important to allow 
and block unwanted new connections, it is also important to be able to 
implement time-based access controls that can allow new connections and 
immediately sever existing connections. This can't be done right now in all 
cases.

N


* Actually, the rejection process is more involved. If it's an established TCP 
conn, it gets reset. Otherwise (UDP/GRE/etc., SYN) it gets an ICMP admin-
prohibited packet.