We have just put into place traffic limitations on the
ICMP layer \"Internet to \"OVH\". This aims at protecting
our network at the level of \"silly\" attacks made by the
Update(s): Date: 2010-05-18 17:15:06 UTC
We record fewer attacks on our network.
We changed the rules to improve filtering and isolating the accounting ICMP to increase the limit to 1Mbps / link INPUT of our network. We should save less of false positive.Date: 2010-05-18 17:14:35 UTC
We leave those parameters for a 3 weeks period.Date: 2010-05-18 17:08:41 UTC
OVH comment, Wednesday, 28 April 2010, 19:25PM
Recently we noticed that our network is subject to an important increase of attacks. The size of the network and the amount of customers we host is at the \"origin\" of this problem.
There are \"silly\" attacks Alias \"trivial\", we no longer wants to be subject to them whenever kids are in vacation.
We decided to limit \"internet\" traffic to \"OVH\" at the level of the ICMP layer. No limitation on the TCP or UDP (thankfully!). The ICMP layer is used to \"Monitor\" the material on the Net and at this level ICMP is very expensive to route. Our routers were already protected for 7-8years and responded \"sometimes\" to ICMP. Now all the network responds occasionally in ICMP.
If you have sensors that monitor your installations at Ovh in ICMP and from the outside of our network, you may receive lots of \"false positive\".
The solution is to monitor services such WEB SMTP or DNS, then TCP / UDP and not the global server with ICMP.
It is not a total break, but a limitation to 512Kbps per connection between \"Internet\" to \"OVH\". Therefore it is always possible to do the traceroute. Just when
OVH is subject to an attack and this attack comes through the same connection you use, the traceroute is not perfect during the attack.
The ICMP is not limited to the inside of the network. We have just placed the protections only on connections between \"Internet\" and \"OVH\". Only on the edge of the Network for the traffic that comes to us from the Internet.
For more details:
Is this final? We will look in 2-3 weeks the number of attacks that our system undergoes and if it's pointless to limit ICMP we will remove this protection.
The probability to reach this conclusion is weak.
on the other side, we push Cisco in order to implement in SRC-3 (the big router that everybody has heard) UBRL features that are only possible on Cisco 6500. It's a some kind of dynamic QoS based on the netflow to match the access-list and policy. It's is very powerful, but requires routers that are powerful in netflow. Cisco 6500 is not very performent in netflow. CRS-3 is. But the function is not in it. Anyway ... if one day we will have intelligent routers, this limitation can be done intelligently. Currently we do with edges'means :(