From: Martijn Lievaart <m@rtij.nl>
To: Cedric Blancher <blancher@cartel-securite.fr>
Cc: Mail List - Netfilter <netfilter@lists.netfilter.org>,
Grant Taylor <gtaylor@riverviewtech.net>
Subject: Re: Interesting article about punching holes in firewalls...
Date: Tue, 19 Dec 2006 19:53:19 +0100 [thread overview]
Message-ID: <4588351F.1040806@rtij.nl> (raw)
In-Reply-To: <1166526302.12238.12.camel@anduril.intranet.cartel-securite.net>
Cedric Blancher wrote:
>>It is possible netfilter does this to accomodate bridging setups. Anyone
>>can comment on this? If this opens up the connection for any other ICMP
>>traffic, I think that's a bug. But I cannot imagine netfilter does this,
>>anyone know for sure?
>>
>>
>
>We also have a protocol problem here. However, as Pascal stated before,
>you can explicitly deny ICMP redirects.
>
>As a more general matter, ICMP filtering is tricky:
>
> . ICMP filtering can (and do) break connectivity: PPPoE users
> with broken PMTUD knows about it...
> . ICMP messages authentication is weak.
>
>On one hand we have a protocol we have to implement because we need it
>for IP to work smoothly, and on the other hand, it's quite easy to
>abuse. And we have to cope with it.
>
>
ICMP filtering is not tricky. Just remember the rules.
1) NEVER, EVER, EVER filter out fragmentation needed.
2) You may filter out ping, and the various destination unreachables,
the consequences are yours.
3) Everything else can be filtered without consequences.
If you mean, it is hard for a firewall to filter malicious ICMPs but not
beneign ICMPs, the we agree. I have not heard of an fragmentation needed
attack yet, but I can imagine it happening (analogous to the zero
windowsize attack).
But as Jozsef explained, iptables does check what it is possible, for
the rest we mostly have to live with it.
M4
next prev parent reply other threads:[~2006-12-19 18:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-18 2:51 [LARTC] Interesting article about punching holes in firewalls Grant Taylor
2006-12-18 2:51 ` Grant Taylor
2006-12-18 7:26 ` Cedric Blancher
2006-12-19 9:42 ` Martijn Lievaart
2006-12-19 11:05 ` Cedric Blancher
2006-12-19 18:53 ` Martijn Lievaart [this message]
2006-12-20 3:42 ` Cedric Blancher
2006-12-19 11:07 ` Jozsef Kadlecsik
2006-12-19 11:46 ` Pascal Hambourg
2006-12-18 22:34 ` Martijn Lievaart
2006-12-18 22:50 ` Pascal Hambourg
2006-12-20 21:23 ` [LARTC] " Stephen Hemminger
2006-12-20 21:23 ` Stephen Hemminger
2006-12-21 7:10 ` [LARTC] " Peter Surda
2006-12-21 7:57 ` Carl-Daniel Hailfinger
2006-12-21 7:57 ` Carl-Daniel Hailfinger
2006-12-25 21:43 ` [LARTC] " Torsten Luettgert
2006-12-21 15:37 ` Grant Taylor
2006-12-21 15:55 ` /dev/rob0
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4588351F.1040806@rtij.nl \
--to=m@rtij.nl \
--cc=blancher@cartel-securite.fr \
--cc=gtaylor@riverviewtech.net \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.