[derchris]

I like this very much.

[Andy]

Remember ping can mean nothing if services are down, or the server goes into rescue mode

[Winit]

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

Damn.

[jonlewi5]

ello,
Recently we noticed a dramatic increase
of attacks that our system suffers. The network size and
the amount of customers that is home to the "origin" of
this problem.

There are attacks "dumb" Alias "trivial" that no
longer wants to suffer whenever kids are
in holiday.

We decided to limit traffic "internet" to
"OVH" at the ICMP layer. No limitation on
the TCP or UDP (thankfully!). The ICMP layer serves to
"monitor" the material on the Net and at this level
is very expensive to ICMP router. Our routers were
already protected for 7-8years 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 ICMP in from outside our
network, you may receive lots of "false positive".
The solution is to WEB type monitor services,
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" worms " 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 beautiful during
the attack.

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

More:
http://travaux.ovh.com/?do=details&id=4140

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

By cons, we push Cisco so that it implements the
SRC-3 (the big router that everybody has heard)
UBRL features that are possible only on the
Cisco 6500. It's a lot of dynamic QoS based
on netflow matcher for the access-list and policy.
This is very powerful, but require walking tonneur
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 ... if it has one day
we can make intelligent routers that limitation
intelligently. Currently we do with the
ways of edges

Amicalement
Octave

[oles@ovh.net]

Hello,

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:
http://travaux.ovh.com/?do=details&id=4140

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,
Octave