# ICMP attack



## FryShadow (Dec 8, 2009)

hi all 

One of my previous server(CentOS) suffering from icmp attack and currently I'm using freebsd 7.2 and blocking all icmp from outsiders (even the ping reply  )

is there any prevention or rules that can protect a little bit for this kind of attack ? 

icmp blocking rules :


```
block in quick on $ext_if proto icmp all
```

ps : any other regular attack that we can discussed ?

thanks all


----------



## SirDice (Dec 8, 2009)

What exactly is the ICMP attack? Unless they're sending huge volumes of ICMP there really isn't anything to worry about.

If they are sending huge volumes you're pretty much defenseless against it. Blocking it won't really matter as they are saturating your connection anyway.


----------



## phoenix (Dec 8, 2009)

You really, really, really don't want to block ICMP type 3, which is used to determine the smallest MTU used by all systems between two end-points.  Doing so will break IP connections.

You also shouldn't block ICMP type 4, or 11 (one of those is used for congestion control).

In fact, the only ICMP types you should block are 0/8 (echo/reply) and 5 (redirect).  The rest are useful, and used in almost every IP connection.


----------



## anomie (Dec 8, 2009)

And, IMO, you shouldn't be blocking icmp echo requests / echo replies either. I'd be interested to hear more precise details about this attack.


----------



## SirDice (Dec 8, 2009)

phoenix said:
			
		

> You really, really, really don't want to block ICMP type 3, which is used to determine the smallest MTU used by all systems between two end-points.  Doing so will break IP connections.


Besides that, it's good to know if a network isn't reachable 



> You also shouldn't block ICMP type 4, or 11 (one of those is used for congestion control).


Congestion is type 4. Type 11 is Time exceeded.



> In fact, the only ICMP types you should block are 0/8 (echo/reply) and 5 (redirect).


I'd allow echo/reply but I would block a redirect.



> The rest are useful, and used in almost every IP connection.


Few others you may want to block:

Type 13&14, timestamp request/reply
Type 17&18, address mask request/reply


----------



## phoenix (Dec 8, 2009)

On our routers/firewalls, we only allow ICMP types 0,3,4,8,11.  Those seem to be the most important for proper IP networking.


----------



## FryShadow (Dec 9, 2009)

nice all 

no much info I get from the provider, they just said our vps had been attacked by icmp packet. 

can we limit the ping reply ? I try to use max-src-conn but still failed to implement

is it crazy if we redirect all bad icmp to other host like google ?


----------



## Voltar (Dec 9, 2009)

FryShadow said:
			
		

> can we limit the ping reply ? I try to use max-src-conn but still failed to implement



You should be able to use max-src-conn, what rule did you come up with? Something like this might work...


```
pass in on $ext_if proto icmp all keep state (max-src-conn 100, max-src-conn-rate 5/5, overload <some_table> flush)
```

some_table being a table of hosts that you block/drop connections from. 

See this if you haven't already. 



> is it crazy if we redirect all bad icmp to other host like google ?



Yes, why waste your bandwidth and theirs? Rather pointless, and if you would be just as bad as whoever is attacking you then.


----------



## phoenix (Dec 9, 2009)

FryShadow said:
			
		

> can we limit the ping reply ? I try to use max-src-conn but still failed to implement



Just add the following to /etc/sysctl.conf:

```
net.inet.icmp.icmplim=200               # Limit ICMP packets to this many per second
```

And run that from the commandline [cmd=]sysctl -w net.inet.icmp.icmplim=200[/cmd] to enable it right away.



> is it crazy if we redirect all bad icmp to other host like google ?



That's a good way to have your VPS service terminated.


----------



## DutchDaemon (Dec 9, 2009)

[note to fellow mod: the `tag requires a qualifier, one of [FILE]$, #, or ' '[/FILE], e.g. [noparse][cmd=], [cmd=$], [cmd=#][/noparse]]`


----------



## phoenix (Dec 9, 2009)

D'oh!  Someday, I'll get all these tags figured out.    Thanks.


----------



## FryShadow (Dec 29, 2009)

hi all,

this is my current server that been attacked for almost 4 days :

http://pastebin.com/m24ffec8c

how to know what type of icmp packet is that ?

thanks all


----------



## DutchDaemon (Dec 29, 2009)

Run a `# tcpdump -s 0 -pnli nic proto ICMP` on your interface (replace 'nic' with your interface name). E.g. a simple ping will show up as 'echo request'; icmp(4) will list the types of ICMP traffic.


----------



## FryShadow (Dec 29, 2009)

looks like it's a ping request


```
12:56:55.140332 IP 200.82.235.38 > 202.***.***.***: icmp
12:56:55.144389 IP 190.201.117.109 > 202.***.***.***: ICMP echo request, id 2, seq 65380, length 1480
12:56:55.148446 IP 190.201.117.109 > 202.***.***.***: icmp
12:56:55.152501 IP 190.199.166.58 > 202.***.***.***: ICMP echo request, id 1540, seq 43384, length 1480
12:56:55.156560 IP 190.199.166.58 > 202.***.***.***: icmp
12:56:55.160617 IP 190.201.41.242 > 202.***.***.***: ICMP echo request, id 512, seq 12201, length 1480
12:56:55.164673 IP 190.201.41.242 > 202.***.***.***: icmp
12:56:55.168730 IP 190.203.167.126 > 202.***.***.***: ICMP echo request, id 512, seq 31949, length 1480
12:56:55.172787 IP 190.203.167.126 > 202.***.***.***: icmp
12:56:55.176844 IP 189.135.124.62 > 202.***.***.***: ICMP echo request, id 512, seq 13733, length 1480
12:56:55.180901 IP 189.135.124.62 > 202.***.***.***: icmp
12:56:55.184958 IP 190.38.84.114 > 202.***.***.***: ICMP echo request, id 512, seq 36427, length 1480
12:56:55.189015 IP 190.38.84.114 > 202.***.***.***: icmp
12:56:55.193233 IP 190.39.101.76 > 202.***.***.***: ICMP echo request, id 512, seq 35780, length 1480
12:56:55.197187 IP 190.39.101.76 > 202.***.***.***: icmp
12:56:55.201243 IP 190.75.227.150 > 202.***.***.***: ICMP echo request, id 512, seq 27432, length 1480
```


----------



## DutchDaemon (Dec 29, 2009)

Not really something to lose any sleep over. There are plenty of CDNs that will ping a requesting host to see which mirror is closest to you based on RTT times, so you'll get your content as quickly as possible. It doesn't really matter whether you allow this traffic or not; if the other side belongs to a CDN, it will simply base its RTT values on replies given by routers on the way to your host that do reply.

BTW, these are not CDN hosts, but assorted DSL/cable IPs, so probably compromised hosts trying to replicate their virus/trojan infections and using a simple ping to scan for hosts to connect to. If you are doing P2P traffic, they may also be peers trying to get (back) in touch with you after you dropped the connection, though these usually keep hammering the last used/known port for a while before giving up.


----------



## FryShadow (Dec 29, 2009)

Agreed with DutchDaemon, I'm sure those IP are from DSL cable(home) which may be infected with virus and become a zombie.


```
sysctl -w net.inet.icmp.icmplim=1
```


----------

