This is just stupid. OVH is one of the largest server providers in the world - of course they will be at the top of that list. What exactly should they do, according to you? Why should people de-peer them?
Regards, Filip Hruska > > On 28 Feb 2018 at 1:13 am, <Dan Hollis> wrote: > > > OVH does not suprise me in the least. Maybe this is finally what it will > take to get people to de-peer them. -Dan On Tue, 27 Feb 2018, Ca By wrote: > > Please do take a look at the cloudflare blog specifically as they name and > > shame OVH and Digital Ocean for being the primary sources of mega crap > > traffic > > > https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/ > > > Also, policer all UDP all the time... UDP is unsafe at any speed. > > > > On Tue, Feb 27, 2018 at 12:28 PM Barry Greene wrote: > >> Hello > Fellow NANOGer, >> >> If you have not already seen it, experiences it, or > read about it, working >> to head off another reflection DOS vector. This > time it is memcached on >> port 11211 UDP & TCP. There are active > exploits using these ports. >> Reflection attacks and the memcached is not > new. We know how reflection >> attacks work (send a spoofed packet to a > device and have it reflected back >> (yes please deploy source address > validation and BCP 38). >> >> Operators are asked to review their > networks and consider updating their >> Exploitable Port Filters > (Infrastructure ACLs) to track or block UDP/TCP >> port 11211 for all > ingress and egress traffic. If you do not know about >> iACLs or Explorable > port filters, you can use this white paper details and >> examples from > peers on Exploitable Port Filters: >> > http://www.senki.org/operators-security-toolkit/filtering-exploitable-ports-and-minimizing-risk-to-and-from-your-customers/ > >> >> Enterprises are also asked to update their iACLs, Exploitable Port > >> Filters, and Firewalls to track or block UDP/TCP port 11211 for all > ingress >> and egress traffic. >> >> Deploying these filters will help > protect your network, your organization, >> your customers, and the > Internet. >> >> Ping me 1:1 if you have questions. >> >> Sincerely, > >> >> -- >> Barry Raveendran Greene >> Security Geek helping with > OPSEC Trust >> Mobile: +1 408 218 4669 >> E-mail: bgre...@senki.org >> > >> ---------------------------- >> Resources on memcached Exploit (to > evaluate your risk): >> >> More information about this attack vector can > be found at the following: >> >> • JPCERT – memcached のアクセス制御に関する注意喚起 > (JPCERT-AT-2018-0009) >> http://www.jpcert.or.jp/at/2018/at180009.html >> > • Qrator Labs: The memcached amplification attacks reaching 500 >> Gbps >> > >> > https://medium.com/@qratorlabs/the-memcached-amplification-attack-reaching-500-gbps-b439a7b83c98 > >> • Arbor Networks: memcached Reflection/Amplification Description >> > and DDoS Attack Mitigation Recommendations >> >> > https://www.arbornetworks.com/blog/asert/memcached-reflection-amplification-description-ddos-attack-mitigation-recommendations/ > >> • Cloudflare: Memcrashed – Major amplification attacks from UDP >> > port 11211 >> >> > https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/ > >> • Link11: New High-Volume Vector: Memcached Reflection >> > Amplification Attacks >> >> > https://www.link11.com/en/blog/new-high-volume-vector-memcached-reflection-amplification-attacks/ > >> • Blackhat Talk: The New Page of Injections Book: Memcached >> > Injections by Ivan Novikov >> >> > https://www.blackhat.com/docs/us-14/materials/us-14-Novikov-The-New-Page-Of-Injections-Book-Memcached-Injections-WP.pdf > >> • Memcache Exploit >> > http://niiconsulting.com/checkmate/2013/05/memcache-exploit/ >> > >
