ICMP packets seeping through a DROP policy - security concern

ICMP packets seeping through a DROP policy - security concern

[jonetsu]

Hello all,

I have observed that there is a change of behaviour from kernel 2.6.26
and kernel 3.0 regarding the INPUT chain and ICMP traffic going
through it.  Kernel 2.6.26 will stop ICMP traffic as soon as the rules
below are applied whereas kernel 3.0 will not.  In both cases an
existing TCP connection (ssh) will be terminated, but the ICMP packets
will be allowed when kernel 3.0 is used, even though a very square
policy of INPUT DROP is applied.

As far as I can see, a policy of INPUT DROP should stop all traffic.
That the ICMP packets are still passing through is not expected and
can be considered as a security breach.

The setup is:

unit1  <--> eth4  unit3  eth1 <--> unit2

unit1 is continuously pinging unit2 via unit3. Rules are applied
on unit3.

1) Test passes

kernel: 2.6.26
iptables: 1.3.6.0

cat /proc/sys/net/ipv4/netfilter/ip_conntrack_icmp_timeout
30

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

-> continuous ping immediately stops

2) Test fails

kernel: 3.0.0
iptables: 1.4.8-3

cat /proc/sys/net/ipv4/netfilter/ip_conntrack_icmp_timeout
30

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

-> continuous ping does not stop


If a ip_conntrack_icmp_timeout of 1 is used, the ICMP packets will be
stopped when the rules are applied.  But that means modifying the
default ICMP conntrack timeout when establishing a firewal and putting
it back to default when the firewall is up, but moreover, it still
does not fix the basic problem of having a INPUT DROP policy and ICMP
packets seeping through.  A value of 2 will not work and will let ICMP
packets go through.

Would it be possible to confirm that there is a problem with the
handling of ICMP packets in this case or, if the tests that I'm doing
are not right ?

Thanks.

Re: ICMP packets seeping through a DROP policy - security concern

[Kerin Millar]

On 04/03/2012 22:25, jonetsu wrote:
> The setup is:
>
> unit1<-->  eth4  unit3  eth1<-->  unit2
>
> unit1 is continuously pinging unit2 via unit3. Rules are applied
> on unit3.

In that case, it's the FORWARD chain that matters. The behaviour of 
kernel 3.0.0 seems correct; ping continues to work because the ICMP is 
subjected to connection tracking and you are allowing 
RELATED/ESTABLISHED traffic in the FORWARD chain. To test the INPUT 
chain, you should be pinging unit3, not unit2.

Cheers,

--Kerin

Re: ICMP packets seeping through a DROP policy - security concern

[jonetsu]

On Mon, 05 Mar 2012 19:51:17 +0000,
Kerin Millar <kerframil@gmail.com> wrote :

> In that case, it's the FORWARD chain that matters. The behaviour of 
> kernel 3.0.0 seems correct;

Yes, but there are two different behaviours with the same rules.  One
behaviour when no conntrack module is loaded that specifies this ICMP
timeout, and one behaviour when it is loaded.

Same test as before:

1) Fresh reboot, no nf modules loaded

# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_icmp_timeout
No such file or directory

# lsmod
(no nf conntrack module loaded - no nf module for that matter)

-> ICMP pings stop immediately when the 3 rules are applied

-> nf conntrack modules are now loaded:

 nf_conntrack_ipv4       9995  1 
 nf_defrag_ipv4           879  1 nf_conntrack_ipv4
 xt_state                 859  1 
 nf_conntrack           47425  2 nf_conntrack_ipv4,xt_state


2)  Flush all rules, re-test, above modules already loaded

# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_icmp_timeout
30

-> ICMP pings continues

As observed, the nf conntrack modules are loaded automatically.  But
at least one value (in this case the ICMP conntrack timeout - maybe
there are others) is not taken into account when the rules are
established in this use case.

But, if the modules are previously loaded, then the values are taken
into account.  There seems to be something not right with this.
Shouldn't any module parameter be taken into account when they are
automatically loaded ?  Here we see that the ICMP param is not taken
into account in the first test - can there be any other parameters
like that ?

It can also question the automatic loading of modules.  Either they
are automatically loaded and all params taken into account, or admins
have to know to load the required modules manually before installing
any rules on a freshly rebooted unit (either by script or by
explicitly loading the needed modules at boot).

Can you confirm that this behaviour is what is intended, or is a bug ?

And let me know if the tests are not right.  It'd be appreciated.

As a side note, as shown previously, this observance of the ICMP
conntrack timeout was absent in kernel 2.6.26, module loaded or not,
so this aspect has changed.  I agree that by principle, if a timeout
is specified, then it should be observed.  Which is now the case in
the latest kernels ... that is, if the module is manually and
previously loaded before applying rules only.

Thanks for any comments/suggestions.