We are in the process of migrating this forum. A new space will be available soon. We are sorry for the inconvenience.

routing ICMP (translated)

04-30-2010, 11:46 AM
Verkkohyökkäyksistä johtuen ICMP liikennettä välillä OVH - Internet RAJOITETAAN!
Uusi kaistanleveys on 512Kbps. Rajoitus ei koske liikennettä välillä OVH - OVH.

Tämä koskee erityisesti niitä, joilla on palveluita pyörimässä OVH:lla ja niitä monitoroidaan ICMP:llä. Väärien positiivisten hälytysten välttämiseksi asiakkaita neuvotaan vaihtamaan monitorointi TCP/UDP -protokollaa käyttäväksi.

Rajoitukset ovat voimassa muutaman viikon, jonka jälkeen tilanne tarkistetaan ja päätetään jatkosta.


04-28-2010, 03:56 PM

Recently we noticed a dramatic increase in attacks on our system. The network size and quantity of customers that we host is "The origin" of this problem.

There are "dumb" attacks, a.k.a. "trivial", that we no longer want to suffer every time the kids are on vacation.

We have decided to limit "internet" traffic to "OVH" at the ICMP layer. No limitation on TCP or UDP (thankfully!). The ICMP layer serves to "monitor" the material on the Net and at this level the ICMP is very expensive to the router. Our routers were already protected for 7-8 years and responded "sometimes" to ICMP. Now all the network meets occasionally in ICMP

The consequences:

If you have sensors that monitor your premises at OVH in ICMP from outside our network, you may receive lots of "false positive". The solution is to monitor services such WEB, SMTP or DNS, then TCP / UDP server and not the global ICMP.

It is not a total break, but a limit to 512Kbps per connection between "Internet" to "OVH". So it is always possible to do the traceroute. Just when OVH is attacked and the attack comes through the same link you use, the traceroute is fine during the attack.

The ICMP is not limited to inside the network. We just have the protections on the connections between "Internet" and "OVH". Only on the edge of the network for traffic that comes to us from the Internet.

More information:

Is this final? We will look at the number of attacks that our system suffers for 2-3 weeks and if it does no good to limit ICMP, we will remove this protection. The probability is that this conclusion is low.

In contrast, we push Cisco to implement the CRS-3 (the big router that everybody has heard) UBRL features that are only available on Cisco 6500. It's a lot of dynamic QoS based on netflow to match the access-list and policy. This is very powerful, but require routers that are powerful in netflow. Cisco 6500 is not very strong in netflow. SRC-3 is. But the function is not in it. Anyway ... one day we can have intelligent routers to limit this intelligently

All the best,