Re: ICMP types to allow

Re: ICMP types to allow

[Peter E. Fry]

----- Original Message -----
From: "Derick Anderson" <danderson@vikus.com>
To: <netfilter@lists.netfilter.org>
Subject: ICMP types to allow
Date: Wed, 21 Dec 2005 08:45:04 -0500

> I know that some networks just drop all ICMP to prevent
> traceroutes but recently I've been been seeing problems
> related to fragementation and MTU and wondering if
> dropping ICMP is causing some of that (since
> Fragementation Needed packets can't get through). On the
> flip side of that there's the Source Quench and
> Fragmentation Needed DoS attacks which have recently
> become mildly popular (I've gotten a few hits on Snort but
> not that many). 
> 
> I'd like to hear from the list what ICMP types firewall
> admins are allowing and why - what are the risks for
> allowing certain types vs. the risks of NOT allowing them?

  In Cisco terms, I always allow
"administratively-prohibited", "echo", "echo-reply",
"packet-too-big", "time-exceeded", "unreachable" (I'm too
lazy to pull out the actual types), with appropriate shaping
and rate-limits to avoid killing the small upstream on my
DSL and/or becoming a 1:1 reflector of any significance.  In
ten years (five with ISDN), I've never actually been
seriously attacked through ICMP -- if someone's going to
flood you, they'll flood you, and it'd take one lazy bastage
not to adapt to whatever filters you have in place.  The
most trash I've seen has not been ICMP, but UDP from berserk
M$ virii (in part because I'm a 'Net-nobody and I haven't
gotten the urge lately to hop on IRC and call all of the
2600 types a bunch of wusses who can't touch my mighty DSL).
 Me, I like ICMP -- I find it useful with little
risk/impact.  Your mileage may vary.

Peter E. Fry

RE: ICMP types to allow

[Derick Anderson]

 

> -----Original Message-----
> From: John A. Sullivan III [mailto:jsullivan@opensourcedevel.com] 
> Sent: Wednesday, December 21, 2005 1:49 PM
> To: Derick Anderson
> Cc: netfilter@lists.netfilter.org
> Subject: RE: ICMP types to allow
> 
> On Wed, 2005-12-21 at 13:36 -0500, Derick Anderson wrote:
> > After reading the ICMP state machine section of the 
> Netfilter tutorial 
> > 
> [http://iptables-tutorial.frozentux.net/iptables-tutorial.html#ICMPCON
> > NE CTIONS] it appears that ICMP traffic related to existing TCP and 
> > UDP connections falls under the RELATED,ESTABLISHED rules.
> > 
> > So someone correct me if I'm wrong, but this means that any 
> valid ICMP 
> > error message would get picked up by a '-A FORWARD -m state --state 
> > RELATED,ESTABLISHED -j ACCEPT' at the start of the chain, and so (as
> > lst_hoe01 stated) allowing type 8 is all you really need to 
> do, correct?
> > (and a little reading goes a long way... =)
> > 
> > Thanks,
> > 
> > Derick Anderson
> >  
> > 
> Somewhere I recall Microsoft documentation asking that all 
> ICMP traffic be allowed for Active Directory.  I never 
> bothered to find out what exactly was needed and why.  Does 
> anyone know if a properly functioning Active Directory needs 
> anything other than echo? - John
> --
> John A. Sullivan III
> Open Source Development Corporation
> +1 207-985-7880
> jsullivan@opensourcedevel.com
> 
> If you would like to participate in the development of an 
> open source enterprise class network security management 
> system, please visit http://iscs.sourceforge.net
> 


I think all AD requires is echo request (which is how it "determines"
whether domain controllers, DNS servers, gateways, etc. are up). Block
ICMP echo request at your firewall/gateway and netdiag will be very
unhappy. I don't believe they "require" any other types but you never
know with Microsoft. 

A google for "active directory 2003 icmp required" (no quotes) provides
the official story (the first two hits are hugely long TechNet articles
so search for ICMP within them), which is basically that ICMP echo
request is used by several services to determine whether hosts are up
and for tracert to work, and that Path MTU makes everybody happy.

Hope that helps,

Derick

RE: ICMP types to allow

[Derick Anderson]

After reading the ICMP state machine section of the Netfilter tutorial
[http://iptables-tutorial.frozentux.net/iptables-tutorial.html#ICMPCONNE
CTIONS] it appears that ICMP traffic related to existing TCP and UDP
connections falls under the RELATED,ESTABLISHED rules.

So someone correct me if I'm wrong, but this means that any valid ICMP
error message would get picked up by a '-A FORWARD -m state --state
RELATED,ESTABLISHED -j ACCEPT' at the start of the chain, and so (as
lst_hoe01 stated) allowing type 8 is all you really need to do, correct?
(and a little reading goes a long way... =)

Thanks,

Derick Anderson
 

RE: ICMP types to allow

[John A. Sullivan III]

On Wed, 2005-12-21 at 13:36 -0500, Derick Anderson wrote:
> After reading the ICMP state machine section of the Netfilter tutorial
> [http://iptables-tutorial.frozentux.net/iptables-tutorial.html#ICMPCONNE
> CTIONS] it appears that ICMP traffic related to existing TCP and UDP
> connections falls under the RELATED,ESTABLISHED rules.
> 
> So someone correct me if I'm wrong, but this means that any valid ICMP
> error message would get picked up by a '-A FORWARD -m state --state
> RELATED,ESTABLISHED -j ACCEPT' at the start of the chain, and so (as
> lst_hoe01 stated) allowing type 8 is all you really need to do, correct?
> (and a little reading goes a long way... =)
> 
> Thanks,
> 
> Derick Anderson
>  
> 
Somewhere I recall Microsoft documentation asking that all ICMP traffic
be allowed for Active Directory.  I never bothered to find out what
exactly was needed and why.  Does anyone know if a properly functioning
Active Directory needs anything other than echo? - John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

If you would like to participate in the development of an open source
enterprise class network security management system, please visit
http://iscs.sourceforge.net

Re: ICMP types to allow

[René Pfeiffer]

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

On Dec 21, 2005 at 1336 -0500, Derick Anderson appeared and said:
> 
> After reading the ICMP state machine section of the Netfilter tutorial
> [http://iptables-tutorial.frozentux.net/iptables-tutorial.html#ICMPCONNE
> CTIONS] it appears that ICMP traffic related to existing TCP and UDP
> connections falls under the RELATED,ESTABLISHED rules.

This is true. However you need some inbound ICMP in order to support
things like Path MTU discovery. I often allow the inbound ICMP message types
time-exceeded, destination-unreachable and parameter-problem. This
covers messages that deal with packet fragmentation. You might want to
disallow some of the destination-unreachable messages.

Best,
René.

-- 
  )\._.,--....,'``.      Let GNU/Linux work for you while you take a nap.
 /,   _.. \   _\  (`._ ,. R. Pfeiffer <lynx at luchs.at> + http://web.luchs.at/
`._.-(,_..'--(,_..'`-.;.'  - System administration + Consulting + Teaching -


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: ICMP types to allow

[Chris Brenton]

On Thu, 2005-12-22 at 01:29 +0100, René Pfeiffer wrote:
>
> This is true. However you need some inbound ICMP in order to support
> things like Path MTU discovery.

As mentioned, the only modern OS I'm aware of that uses straight ICMP
for MTU path is 3-4 year old AIX boxes. The sane way to do this is to
set Don't Fragment (DF) in the IP header and watch for returning type 3
code 4's. Also as mentioned, RELATED will pass these in without a
problem so no special rules are needed.

> In addition to that you can add some general size limits for ICMP
> packets. Theoretically ICMP packets can have 64 kB and there are tools
> out there that use oversized packets for tunneling data. 

I've run the following rules for about four years now on numerous
firewalls I maintain:
iptables -A FORWARD -p icmp -f -j LOG --log-prefix " ICMPFRAG "
iptables -A FORWARD -p icmp -f -j REJECT --reject-with
icmp-host-unreachable

In short, the rules look for fragmented ICMP datagrams. I've seen
exactly zero legitimate packets get picked up by this rule. Every time
its triggered its been because of an attack.

I agree that size limits could also be extremely useful. While the spec
says it can be as large as 65,535 bytes, in practice you should never
see anything larger than your local MTU. Further, I would even be
suspect of any ICMP larger than 100 bytes or so. Most legit ICMP will be
below this size.

HTH,
Chris

Re: ICMP types to allow

[René Pfeiffer]

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

On Dec 21, 2005 at 2108 -0500, Chris Brenton appeared and said:
> On Thu, 2005-12-22 at 01:29 +0100, René Pfeiffer wrote:
> >
> > This is true. However you need some inbound ICMP in order to support
> > things like Path MTU discovery.
> 
> As mentioned, the only modern OS I'm aware of that uses straight ICMP
> for MTU path is 3-4 year old AIX boxes. The sane way to do this is to
> set Don't Fragment (DF) in the IP header and watch for returning type 3
> code 4's.

Yes, you are right. We have some of these old AIX boxes that do exactly
this kind of ICMP behaviour and some of our servers have to talk to them.
That's why I used the conservative approach and allowing more ICMP
message types.

> I've run the following rules for about four years now on numerous
> firewalls I maintain:
> iptables -A FORWARD -p icmp -f -j LOG --log-prefix " ICMPFRAG "
> iptables -A FORWARD -p icmp -f -j REJECT --reject-with
> icmp-host-unreachable
> 
> In short, the rules look for fragmented ICMP datagrams. I've seen
> exactly zero legitimate packets get picked up by this rule. Every time
> its triggered its been because of an attack.

That's a good idea. You can also use the packet counters to see if you
have rules that are used and if certain packets appear at your
perimeter.

Best,
René.

-- 
  )\._.,--....,'``.      Let GNU/Linux work for you while you take a nap.
 /,   _.. \   _\  (`._ ,. R. Pfeiffer <lynx at luchs.at> + http://web.luchs.at/
`._.-(,_..'--(,_..'`-.;.'  - System administration + Consulting + Teaching -


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: ICMP types to allow

[lst_hoe01]

Zitat von René Pfeiffer <lynx@luchs.at>:

> On Dec 21, 2005 at 1336 -0500, Derick Anderson appeared and said:
>>
>> After reading the ICMP state machine section of the Netfilter tutorial
>> [http://iptables-tutorial.frozentux.net/iptables-tutorial.html#ICMPCONNE
>> CTIONS] it appears that ICMP traffic related to existing TCP and UDP
>> connections falls under the RELATED,ESTABLISHED rules.
>
> This is true. However you need some inbound ICMP in order to support
> things like Path MTU discovery. I often allow the inbound ICMP message types
> time-exceeded, destination-unreachable and parameter-problem. This
> covers messages that deal with packet fragmentation. You might want to
> disallow some of the destination-unreachable messages.

As far as i know path MTU discovery works by setting up the connection
with DF set and raise the packet size until a ICMP error comes back.
This case is covered fine by the RELATED stuff. Time-exceeded and
destination unreachable are also only valid as reply to some IP traffic.
So as the tutorial discribe there are only 4 types which could be really new :
"Echo request, Timestamp request, Information request and finally
Address mask request". For me only the first one makes sense to allow.
All the really critical stuff can be handeled by the ICMP state machine.

Regards

Andreas

ICMP types to allow

[Derick Anderson]

I know that some networks just drop all ICMP to prevent traceroutes but
recently I've been been seeing problems related to fragementation and
MTU and wondering if dropping ICMP is causing some of that (since
Fragementation Needed packets can't get through). On the flip side of
that there's the Source Quench and Fragmentation Needed DoS attacks
which have recently become mildly popular (I've gotten a few hits on
Snort but not that many). 

I'd like to hear from the list what ICMP types firewall admins are
allowing and why - what are the risks for allowing certain types vs. the
risks of NOT allowing them?

Thanks,

Derick Anderson

Re: ICMP types to allow

[lst_hoe01]

Zitat von Derick Anderson <danderson@vikus.com>:

> I know that some networks just drop all ICMP to prevent traceroutes but
> recently I've been been seeing problems related to fragementation and
> MTU and wondering if dropping ICMP is causing some of that (since
> Fragementation Needed packets can't get through). On the flip side of
> that there's the Source Quench and Fragmentation Needed DoS attacks
> which have recently become mildly popular (I've gotten a few hits on
> Snort but not that many).
>
> I'd like to hear from the list what ICMP types firewall admins are
> allowing and why - what are the risks for allowing certain types vs. the
> risks of NOT allowing them?
>
> Thanks,
>
> Derick Anderson


We allow icmp type 8 (echo request) incoming against our firewall and 
all "related" and "established" icmp traffic, which should cover the 
MTU problem and should be save against blind spoofing.

Regards

Andreas

Re: ICMP types to allow

[Georgi Alexandrov]

Derick Anderson wrote:

>I know that some networks just drop all ICMP to prevent traceroutes but
>recently I've been been seeing problems related to fragementation and
>MTU and wondering if dropping ICMP is causing some of that (since
>Fragementation Needed packets can't get through). On the flip side of
>that there's the Source Quench and Fragmentation Needed DoS attacks
>which have recently become mildly popular (I've gotten a few hits on
>Snort but not that many). 
>
>I'd like to hear from the list what ICMP types firewall admins are
>allowing and why - what are the risks for allowing certain types vs. the
>risks of NOT allowing them?
>
>Thanks,
>
>Derick Anderson
>
>
>  
>
Hello,

I generally allow at least those 3 icmp types: 3,11,12 - to ensure 
proper network functions.
refs: http://www.faqs.org/docs/iptables/icmptypes.html


regards,
Georgi Alexandrov

Re: ICMP types to allow

[Cedric Blancher]

Le mercredi 21 décembre 2005 à 08:45 -0500, Derick Anderson a écrit :
> I know that some networks just drop all ICMP to prevent traceroutes but
> recently I've been been seeing problems related to fragementation and
> MTU and wondering if dropping ICMP is causing some of that (since
> Fragementation Needed packets can't get through). On the flip side of
> that there's the Source Quench and Fragmentation Needed DoS attacks
> which have recently become mildly popular (I've gotten a few hits on
> Snort but not that many). 

ICMP is part of IP mechanisms. Break ICMP, you break IP. That's just as
simple as this. Regarding "recent" ICMP DoSes, protections have been
proposed (and added) to mitigate them, such as TCP sequence number check
in ICMP citation.

In addition to this, Netfilter, unlike some popular proprietary
products, provide a proper stateful ICMP filtering. Just use it. Valid
ICMP errors will fall into RELATED state, others will be INVALID.


-- 
http://sid.rstack.org/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: ICMP types to allow

[Chris Brenton]

On Wed, 2005-12-21 at 20:22 +0100, Cedric Blancher wrote:
>
> In addition to this, Netfilter, unlike some popular proprietary
> products, provide a proper stateful ICMP filtering. Just use it. Valid
> ICMP errors will fall into RELATED state, others will be INVALID.

Agreed. The payload on ICMP errors (which contains 28 bytes of the
packet which generated the error) is inspected and compared against the
state entry. This mean RELATED is more than capable of letting through
needed ICMP errors and dropping the bogus stuff. So you are cool with
types 3,4,5, & 11. The average perimeter does not need much more than
that.

For a while there AIX was using 1500 byte type 8's for MTU path
discovery instead of setting the DF flag in it's packets. They stopped
this by default a few years back however (although the operator still
has the option of turning this brain dead feature back on). So this may
be an exception if you are dealing with these systems.

Someone already mentioned the other condition which is permitting type
8's between Windows AD systems. Obviously you should only do this if you
need to and the range of permitted source IP's should be as restrictive
as possible.

HTH,
Chris

Re: ICMP types to allow

[René Pfeiffer]

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

On Dec 21, 2005 at 1701 -0500, Chris Brenton appeared and said:
> On Wed, 2005-12-21 at 20:22 +0100, Cedric Blancher wrote:
> >
> > In addition to this, Netfilter, unlike some popular proprietary
> > products, provide a proper stateful ICMP filtering. Just use it. Valid
> > ICMP errors will fall into RELATED state, others will be INVALID.
> 
> Agreed. The payload on ICMP errors (which contains 28 bytes of the
> packet which generated the error) is inspected and compared against the
> state entry. This mean RELATED is more than capable of letting through
> needed ICMP errors and dropping the bogus stuff. So you are cool with
> types 3,4,5, & 11. The average perimeter does not need much more than
> that.

In addition to that you can add some general size limits for ICMP
packets. Theoretically ICMP packets can have 64 kB and there are tools
out there that use oversized packets for tunneling data. 

Best,
René.

-- 
  )\._.,--....,'``.      Let GNU/Linux work for you while you take a nap.
 /,   _.. \   _\  (`._ ,. R. Pfeiffer <lynx at luchs.at> + http://web.luchs.at/
`._.-(,_..'--(,_..'`-.;.'  - System administration + Consulting + Teaching -


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: ICMP types to allow

[Jan Engelhardt]

>I'd like to hear from the list what ICMP types firewall admins are
>allowing and why - what are the risks for allowing certain types vs. the
>risks of NOT allowing them?

Well, I don't allow something, I block certain types so I can be sure that 
nothing is implicitly hindered:

    for j in redirect router-advertisement router-solicitation 30; do
        ipt -A INPUT -j DROP -p icmp --icmp-type "$j";
    done;

30 = UDP-traceroute, but iptables does not have a mnemonic name for it.




Jan Engelhardt
--