We have just introduced traffic restrictions on the
ICMP layer \"Internet\" to \"OVH\". This is meant to better protect
our network against \"silly\" attacks made by novice hackers.
Date: 2010-05-11 11:09:00 UTC We leave those parameters for a 3 weeks period.
Date: 2010-04-28 17:25:29 UTC Hi,
Recently, we noticed that our network is subject to an important attacks'increase.
The size of the network and the amount of customers we host is at the \"origin\" of
There are \"silly\" attacks alias \"trivial\" we no
longer wants to go through, whenever kids are on vacation.
We decided to limit the \"internet\" traffic to
\"OVH\" at the level of the ICMP layer. No limitation neither on the
TCP nor UDP (thankfully!). The ICMP layer is used to monitor
the material on the Net and at this level the
ICMP is very expensive to rout it. Our routers were
already protected for 7-8years and responded \"sometimes\"
to ICMP. Now all the network responds occasionally
If you have probes that monitor your installations
with Ovh in ICMP, from outside of our
network, you may receive lots of \"false positive\".
The solution is to monitor services such WEB
SMTP or DNS, that's with 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
The ICMP trafic is not limited inside the network.
We have just placed the protections on connections
between \"Internet\" and \"OVH\". Only on the edge of the
Network traffic that comes to us from the Internet.
Is it final? We will look in 2-3 weeks
the number of attacks that our system goes through and if it is 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 :(