* ICMP packets seeping through a DROP policy - security concern
@ 2012-03-04 22:25 jonetsu
2012-03-05 19:51 ` Kerin Millar
0 siblings, 1 reply; 3+ messages in thread
From: jonetsu @ 2012-03-04 22:25 UTC (permalink / raw
To: netfilter
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: ICMP packets seeping through a DROP policy - security concern
2012-03-04 22:25 ICMP packets seeping through a DROP policy - security concern jonetsu
@ 2012-03-05 19:51 ` Kerin Millar
2012-03-07 1:09 ` jonetsu
0 siblings, 1 reply; 3+ messages in thread
From: Kerin Millar @ 2012-03-05 19:51 UTC (permalink / raw
To: netfilter
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: ICMP packets seeping through a DROP policy - security concern
2012-03-05 19:51 ` Kerin Millar
@ 2012-03-07 1:09 ` jonetsu
0 siblings, 0 replies; 3+ messages in thread
From: jonetsu @ 2012-03-07 1:09 UTC (permalink / raw
To: netfilter
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-03-07 1:09 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-04 22:25 ICMP packets seeping through a DROP policy - security concern jonetsu
2012-03-05 19:51 ` Kerin Millar
2012-03-07 1:09 ` jonetsu
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.