ICMP types

ICMP types

[varun_saa]

Hello,
      As I understand there are more one 
type of ICMP ping.

What are these types and should they
all be allowed in iptables rules ?

Thanks

Varun

Re: ICMP types

[Sertys]

On Sat, 30 Apr 2005 14:53:23 +0500, <varun_saa@vsnl.net> wrote:

http://www.iana.org/assignments/icmp-parameters
Use this URL to learn more about the ICMP protocol. It's an interesting  
reading. I wouldn't consider forbidding ICMP at all unless you've go dDoS  
attacks on ICMP(like microsoft). It's a control message protocol anyway.

> Hello,
>       As I understand there are more one
> type of ICMP ping.
>
> What are these types and should they
> all be allowed in iptables rules ?
>
> Thanks
>
> Varun
>



-- 
www.supportivo.org

I can't stop myself checking for pigs in the outlets. Everybody thinks i'm  
a punk, cause of the hairstyle(220V).
end

RE: ICMP types

[Ken Hilliard]

In reading different firewall scripts/tutorials many of them recommend
filtering ICMP packets. I added ICMP filter in my firewall but was
unsure of the value as well. What is the consensus view out there?

-----Original Message-----
From: netfilter-bounces@lists.netfilter.org
[mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Sertys
Sent: Saturday, April 30, 2005 5:29 PM
To: Netfilter list
Subject: Re: ICMP types

On Sat, 30 Apr 2005 14:53:23 +0500, <varun_saa@vsnl.net> wrote:

http://www.iana.org/assignments/icmp-parameters
Use this URL to learn more about the ICMP protocol. It's an interesting

reading. I wouldn't consider forbidding ICMP at all unless you've go
dDoS  
attacks on ICMP(like microsoft). It's a control message protocol anyway.

> Hello,
>       As I understand there are more one
> type of ICMP ping.
>
> What are these types and should they
> all be allowed in iptables rules ?
>
> Thanks
>
> Varun
>



-- 
www.supportivo.org

I can't stop myself checking for pigs in the outlets. Everybody thinks
i'm  
a punk, cause of the hairstyle(220V).
end

Re: ICMP types

[Mogens Valentin]

Ken Hilliard wrote:
 > In reading different firewall scripts/tutorials many of them recommend
 > filtering ICMP packets. I added ICMP filter in my firewall but was
 > unsure of the value as well. What is the consensus view out there?

Not wanting to comment what the consensus are, but some types are 
generally considered nessesary to filter/allow.

But its really not just a matter of filtering this-or-that, also what's 
set in /proc . There's a lot to read...
A few ideas:

Filtering ICMP:

### Define icmp_packets chain:
     $IPT -F icmp_packets
     $IPT -X icmp_packets
     $IPT -N icmp_packets
     $IPT -A icmp_packets -p icmp --icmp-type echo-request -j ACCEPT
     $IPT -A icmp_packets -p icmp --icmp-type echo-reply -j ACCEPT
     $IPT -A icmp_packets -p icmp --icmp-type destination-unreachable -j 
ACCEPTlog
     $IPT -A icmp_packets -p icmp --icmp-type network-unreachable -j 
ACCEPTlog
     $IPT -A icmp_packets -p icmp --icmp-type network-prohibited -j 
ACCEPTlog
     $IPT -A icmp_packets -p icmp --icmp-type source-quench -j ACCEPTlog
     $IPT -A icmp_packets -p icmp --icmp-type parameter-problem -j ACCEPTlog
     $IPT -A icmp_packets -p icmp --icmp-type time-exceeded -j ACCEPTlog
     $IPT -A icmp_packets -p icmp --icmp-type fragmentation-needed -j 
ACCEPTlog
     #$IPT -A icmp_packets -p icmp -j ACCEPTlog
     $IPT -A icmp_packets -p icmp -j LOG



A few /proc settings:

### /proc settings:
     setup_procfs() {

       # Disable forwarding while setting up rules (needed for 
masquerading):
       # Note: this is now done in forwarding.def
           #echo "0" >/proc/sys/net/ipv4/ip_forward

       # Initially, disable ICMP echo-requests altogether (normally only 
used if DoSed):
       # Note: this is now done in forwarding.def
           #echo "1" >/proc/sys/net/ipv4/icmp_echo_ignore_all

       # Disable ICMP echo-request to broadcast addresses (Smurf amplifier):
           echo "1" >/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

       # Enable syn-cookies (prevent syn-flood attacks):
           echo "1" >/proc/sys/net/ipv4/tcp_syncookies

       # Reduce number of possible SYN Floods:
           echo "1024" >/proc/sys/net/ipv4/tcp_max_syn_backlog

       # Enable defrag error protection:
           echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

       # Enable time-wait assassination hazards in tcp (RFC 1337):
           echo "1" >/proc/sys/net/ipv4/tcp_rfc1337

       # Prevent remote digging of OS-type and uptime (RFC1323):
           #echo "1" >/proc/sys/net/ipv4/tcp_timestamps    # enable 
timestamps
           echo "0" >/proc/sys/net/ipv4/tcp_timestamps    # disable 
timestamps

       # Disable RFC2018 TCP Selective Acknowledgements:
           echo 0 > /proc/sys/net/ipv4/tcp_sack


       # Sourcerouting and spoofing:
           for i in /proc/sys/net/ipv4/conf/*; do
               # Drop all source-routed packets:
               echo "0" >$i/accept_source_route

               # Deactivate normal ICMP redirect accept/send:
               echo "0" >$i/accept_redirects
               echo "0" >$i/send_redirects

               # Activate secure ICMP redirects (send only?) (on by 
default):
               echo "1" >$i/secure_redirects

               # Enable ingress + egress source-address verification 
(prevent spoofing):
               #echo "0" >$i/rp_filter   # disable
               echo "1" >$i/rp_filter   # enable
           done

       # Log spoofed, source routed and redirect packets:
           #echo 1 >/proc/sys/net/ipv4/conf/all/log_martians
           echo 0 >/proc/sys/net/ipv4/conf/all/log_martians

     }

-- 
Kind regards,
Mogens Valentin


Q: How does a hacker fix a function which doesn't
    work for all of the elements in its domain?
A: He changes the domain.
   -- unknown

Re: ICMP types

[Alexander Samad]

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

On Sat, Apr 30, 2005 at 02:23:24PM +0200, Mogens Valentin wrote:
> Ken Hilliard wrote:
> > In reading different firewall scripts/tutorials many of them recommend
> > filtering ICMP packets. I added ICMP filter in my firewall but was
> > unsure of the value as well. What is the consensus view out there?
> 
> Not wanting to comment what the consensus are, but some types are 
> generally considered nessesary to filter/allow.
> 
> But its really not just a matter of filtering this-or-that, also what's 
> set in /proc . There's a lot to read...
> A few ideas:
> 
> Filtering ICMP:
> 
> ### Define icmp_packets chain:
>     $IPT -F icmp_packets
>     $IPT -X icmp_packets
>     $IPT -N icmp_packets
>     $IPT -A icmp_packets -p icmp --icmp-type echo-request -j ACCEPT
>     $IPT -A icmp_packets -p icmp --icmp-type echo-reply -j ACCEPT
>     $IPT -A icmp_packets -p icmp --icmp-type destination-unreachable -j 
> ACCEPTlog
>     $IPT -A icmp_packets -p icmp --icmp-type network-unreachable -j 
> ACCEPTlog
>     $IPT -A icmp_packets -p icmp --icmp-type network-prohibited -j 
> ACCEPTlog
>     $IPT -A icmp_packets -p icmp --icmp-type source-quench -j ACCEPTlog
>     $IPT -A icmp_packets -p icmp --icmp-type parameter-problem -j ACCEPTlog
>     $IPT -A icmp_packets -p icmp --icmp-type time-exceeded -j ACCEPTlog
>     $IPT -A icmp_packets -p icmp --icmp-type fragmentation-needed -j 
> ACCEPTlog
>     #$IPT -A icmp_packets -p icmp -j ACCEPTlog
>     $IPT -A icmp_packets -p icmp -j LOG


why not use
-m limit --limit 1/s --limit-burst 5 
as well to limit them and then drop the rest!

> 
> 
> 
> A few /proc settings:
> 
> ### /proc settings:
>     setup_procfs() {
> 
>       # Disable forwarding while setting up rules (needed for 
> masquerading):
>       # Note: this is now done in forwarding.def
>           #echo "0" >/proc/sys/net/ipv4/ip_forward
> 
>       # Initially, disable ICMP echo-requests altogether (normally only 
> used if DoSed):
>       # Note: this is now done in forwarding.def
>           #echo "1" >/proc/sys/net/ipv4/icmp_echo_ignore_all
> 
>       # Disable ICMP echo-request to broadcast addresses (Smurf amplifier):
>           echo "1" >/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
> 
>       # Enable syn-cookies (prevent syn-flood attacks):
>           echo "1" >/proc/sys/net/ipv4/tcp_syncookies
> 
>       # Reduce number of possible SYN Floods:
>           echo "1024" >/proc/sys/net/ipv4/tcp_max_syn_backlog
> 
>       # Enable defrag error protection:
>           echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
> 
>       # Enable time-wait assassination hazards in tcp (RFC 1337):
>           echo "1" >/proc/sys/net/ipv4/tcp_rfc1337
> 
>       # Prevent remote digging of OS-type and uptime (RFC1323):
>           #echo "1" >/proc/sys/net/ipv4/tcp_timestamps    # enable 
> timestamps
>           echo "0" >/proc/sys/net/ipv4/tcp_timestamps    # disable 
> timestamps
> 
>       # Disable RFC2018 TCP Selective Acknowledgements:
>           echo 0 > /proc/sys/net/ipv4/tcp_sack
> 
> 
>       # Sourcerouting and spoofing:
>           for i in /proc/sys/net/ipv4/conf/*; do
>               # Drop all source-routed packets:
>               echo "0" >$i/accept_source_route
> 
>               # Deactivate normal ICMP redirect accept/send:
>               echo "0" >$i/accept_redirects
>               echo "0" >$i/send_redirects
> 
>               # Activate secure ICMP redirects (send only?) (on by 
> default):
>               echo "1" >$i/secure_redirects
> 
>               # Enable ingress + egress source-address verification 
> (prevent spoofing):
>               #echo "0" >$i/rp_filter   # disable
>               echo "1" >$i/rp_filter   # enable
>           done
> 
>       # Log spoofed, source routed and redirect packets:
>           #echo 1 >/proc/sys/net/ipv4/conf/all/log_martians
>           echo 0 >/proc/sys/net/ipv4/conf/all/log_martians
> 
>     }
> 
> -- 
> Kind regards,
> Mogens Valentin
> 
> 
> Q: How does a hacker fix a function which doesn't
>    work for all of the elements in its domain?
> A: He changes the domain.
>   -- unknown
> 
> 
> 

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

Re: ICMP types

[Mogens Valentin]

Alexander Samad wrote:
> On Sat, Apr 30, 2005 at 02:23:24PM +0200, Mogens Valentin wrote:
> 
>>Ken Hilliard wrote:
>>
>>>In reading different firewall scripts/tutorials many of them recommend
>>>filtering ICMP packets. I added ICMP filter in my firewall but was
>>>unsure of the value as well. What is the consensus view out there?
>>
>>Not wanting to comment what the consensus are, but some types are 
>>generally considered nessesary to filter/allow.
>>
>>But its really not just a matter of filtering this-or-that, also what's 
>>set in /proc . There's a lot to read...
>>A few ideas:
>>
>>Filtering ICMP:
>>
>>### Define icmp_packets chain:
>>    $IPT -F icmp_packets
>>    $IPT -X icmp_packets
>>    $IPT -N icmp_packets
>>    $IPT -A icmp_packets -p icmp --icmp-type echo-request -j ACCEPT
>>    $IPT -A icmp_packets -p icmp --icmp-type echo-reply -j ACCEPT
>>    $IPT -A icmp_packets -p icmp --icmp-type destination-unreachable -j 
>>ACCEPTlog
>>    $IPT -A icmp_packets -p icmp --icmp-type network-unreachable -j 
>>ACCEPTlog
>>    $IPT -A icmp_packets -p icmp --icmp-type network-prohibited -j 
>>ACCEPTlog
>>    $IPT -A icmp_packets -p icmp --icmp-type source-quench -j ACCEPTlog
>>    $IPT -A icmp_packets -p icmp --icmp-type parameter-problem -j ACCEPTlog
>>    $IPT -A icmp_packets -p icmp --icmp-type time-exceeded -j ACCEPTlog
>>    $IPT -A icmp_packets -p icmp --icmp-type fragmentation-needed -j 
>>ACCEPTlog
>>    #$IPT -A icmp_packets -p icmp -j ACCEPTlog
>>    $IPT -A icmp_packets -p icmp -j LOG
> 
> 
> 
> why not use
> -m limit --limit 1/s --limit-burst 5 
> as well to limit them and then drop the rest!

Yes, you're right. Actually thought about it awhile ago, but forgot.
Tnx for reminding me :-
And yes, I do start off dropping everything...

-- 
Kind regards,
Mogens Valentin

Re: ICMP types

[Taylor, Grant]

varun_saa@vsnl.net wrote:
> Hello,
>       As I understand there are more one 
> type of ICMP ping.

Yes, there are a LOT of different types ICMP packets.  It looks like there are ~28 of them in use (see http://www.iana.org/assignments/icmp-parameters).  You really don't want to just blindly drop ICMP packets as they are used to help control the internet or let you know when problems were encountered out on the wild surf of the net.  A common practice is to allow limited numbers of ICMP packets per a time period.  Usually this is system wide and not per destination IP.  Rather than doing this I would like to see some sort of limit per source IP.  A common accepted practice is to allow 1 ICMP (echo request and echo reply) packet per second as quite a few monitoring systems will ping (ICMP echo) a system expecting a response (ICMP echo reply) to see if a system is up and functioning.  (IMHO) Only in very rare / limited situation should ICMP be completely dropped.  Granted I have set up fi
 rewalls / servers in the past to do this but that was when I was just starting.  Some peop
le / institutions have made political decisions to DROP ICMP traffic in an attempt to not become part of a reflected ICMP DDoS attack on someone.  Rather than doing this I would be more tempted to rate limit the number of ICMP packets that could come from (and reply to) any given source.  There are obviously certain situations where certain types if ICMP packets are absolutely wrong, i.e. you should *NEVER* receive an ICMP error (Echo Reply (0), Destination Unreachable (3), Source Quench (4), Alternate Host Address (6), Time Exceeded (11), Parameter Problem (12), Timestamp Reply (14)*, Information Reply (16)*, Address Mask Reply (18)*, Datagram Conversion Error (31), Mobile Host Redirect (32), IPv6 I-Am-Here (34), Mobile Registration Reply (36), Domain Name Reply (38), etx.) from a system that you are not presently communicating.  Rule sets can be built to trap such things using the rece
 nt and / or set match extensions, but are rather complex and lengthy.  I personally have n
ot built such a rule set but see no problem doing so.  If you want help in this let me know and I'd be glad to do it, if for nothing else but the geek factor.  :)

* = This ICMP type is not an error, but same is the idea.



Grant. . . .
> What are these types and should they
> all be allowed in iptables rules ?

Re: ICMP types

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 30 Apr 2005, Taylor, Grant wrote:

> le / institutions have made political decisions to DROP ICMP traffic in an 
> attempt to not become part of a reflected ICMP DDoS attack on someone.


just deny pings to the broadcast address and this can be eliminated, and 
this can be done in sysctl, does not require iptables rules and overhead.


Thanks,

Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCdBNOst+vzJSwZikRAmcBAJ4vOhlII62xQqlT3E/J8qClhzTEpwCgrw2S
nzYG9/nCSrqD6gkdfonifvk=
=vWVU
-----END PGP SIGNATURE-----

Re: ICMP types

[Taylor, Grant]

> just deny pings to the broadcast address and this can be eliminated, and 
> this can be done in sysctl, does not require iptables rules and overhead.

This will take care of traffic that was destined to a broadcast address, but not traffic that was destined to your IP directly.  I have known many a person say that it is better to DROP the ICMP traffic coming in on your WAN / INet interface so that you don't become part of a DDoS.  Usually the idea behind this is for multiple owned boxen to ping some other box at random with a spoofed source address in the ICMP packet.  This effectively will cause the recipient of the ICMP packets to reply to the system that is to be DDoSed.  This is an issue on the internet at large still these days. It would not take too many owned boxen connected to cable modems or DSL modems (or higher speed connections) spewing out spoofed ICMP packets to ultimately cause a DDoS against an unwilling target.  If the average CM's upload is 512 kbps and you have a 1000 owned boxen spewing out spoofed ICMP echos as fas
 t as they can you would end up with approximately 500 Mbps worth of inbound ICMP echo repl
ies (if the packet that was sent was an ICMP echo request) destined to the one target (assuming that the owned boxen sent with the same spoofed IP).  A LOT of people want to prevent them selves from becoming a reflector in such a DDoS.



Grant. . . .

Re: ICMP types

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 30 Apr 2005, Taylor, Grant wrote:

>> just deny pings to the broadcast address and this can be eliminated, and 
>> this can be done in sysctl, does not require iptables rules and overhead.
>
> This will take care of traffic that was destined to a broadcast address, but 
> not traffic that was destined to your IP directly.  I have known many a 
> person say that it is better to DROP the ICMP traffic coming in on your WAN / 
> INet interface so that you don't become part of a DDoS.  Usually the idea 
> behind this is for multiple owned boxen to ping some other box at random with 
> a spoofed source address in the ICMP packet.  This effectively will cause the 
> recipient of the ICMP packets to reply to the system that is to be DDoSed.

I have never seen a DDOS like this function without reflecting off the 
broadcast address space.  In fact, there;'s perhaps still a list of the 
borked networks that have not blocked access to their broadcast space, 
maybe more then one.  But, I'd be interested in any such attack that works 
without ampliphying off the broadcast address.


Thanks,

Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCdBpjst+vzJSwZikRAsXkAJ4oaXh+eIT0tnHXAlLpczKSDDB9eACgz5xr
3oL0troG5bU0C2evvTcYgyI=
=tGjd
-----END PGP SIGNATURE-----

Re: ICMP types

[Dean Anderson]

Necessary messages: (never block)
        3 Destination Unreachable
                (block code 4 and break PATH MTU)
                (other codes are "Nice")

Good Messages: (never harmful)
        11 Time to live Exceeded

Nice messages: (sometimes harmful)
        4 Source Quench
        8/0 Echo Request/Reply
        12 Parameter Problem
        13/14 Timestamp Request/Reply
        15/16 Information Request/Reply


Dangerous (ought to be blocked, unless you know you need it;
                in that case tightly restricted)
        5 Redirect


There was also recently an IOS patch released that exploited type 3 code 4
(fragmentation needed--used in Path MTU Discovery) packets to reduce the
MTU size to nearly nothing.  To do this, one needs the correct port
numbers of a TCP connection, but this isn't all that hard to get in some
cases. I don't recommend blocking type 3 code 4, but the attack can still
be recognized, and the TCP stack can reject unrealisticly small PMTU 
sizes.

It might be handy to have a filter that recognizes this PMTU attack and 
blocks it dynamically.  

		--Dean

On Sat, 30 Apr 2005 varun_saa@vsnl.net wrote:

> Hello,
>       As I understand there are more one 
> type of ICMP ping.
> 
> What are these types and should they
> all be allowed in iptables rules ?
> 
> Thanks
> 
> Varun
> 
> 
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000