Hacker News new | past | comments | ask | show | jobs | submit login
Large DDoS strikes US, Europe (itnews.com.au)
85 points by ndesaulniers on Feb 11, 2014 | hide | past | favorite | 23 comments



I wonder if this is a part of an attack that has been targeting private torrent trackers recently.

A lot of private trackers lately have been getting hit by DDOS attacks. To the point that a few have taken on extra developers/admins which have openly stated their primary goal is to deal with said attacks.

One in particular that has a large user base (35,000 active users) has been experiencing difficulties and is also customer of CloudFlare. This might be one reason why CloudFlare is hesitant to give out details.

The "French networking host" (OVH) that is mentioned in the article is one of the largest suppliers of seedboxes I known of. Usually indirectly through smaller companies who buy from OVH and then provide support and server management services. In fact, this is so widely known within the private P2P community that "being on the OVH network" is actually a selling point due to the sheer amount of peers that you'll be getting ridiculously high speeds with.

Of course, it could all just be a coincidence too.


The big ones all turned to Cloudflare after last month's DDOS, IIRC. And what looks to be premium plans, too. Hypothetically, of course...


If you haven't fixed your NTP server, it is probably part of this traffic amplification attack.

Here's a description of the necessary configuration changes: http://www.meinbergglobal.com/english/news/meinberg-security...


I just got out to fix my machines, and I'm glad to say that Debian's default configuration is already right, nothing to fix there.

Anyway, I'd encorage anybody to read the link and check, maybe you are not using the default, or maybe you are using an earlier version.


Is there a legitimate reason why any ISP / hosting provider etc allows traffic to exit with an IP that doesn't belong to them?

Surely enforcing this would prevent any IP spoofing, which would cut down on these types of attacks?

(As far as I'm aware in this type of attack you send packets purporting to be from your target, to anything on the internet that will blindly send back a reply. Hopefully the reply will be bigger/more packets than your request was, thus amplifying the bandwidth).

If I'm mistaken please explain why...


What you suggest is actually the default behavior of most major carriers. Its codified here: http://tools.ietf.org/html/bcp38

That said, source address spoofing is needed for some one-way satellite internet providers.

There are also some really cool advanced load balancing tricks you can do with it. It even comes in handy (ironically) when doing DDoS mitigation.


Is it the default behavior of major carriers in Russia/China/Africa/etc as well as in Europe/America?

My experience has been that the majority of the countries where attacks come from do not really care.


Yes, it is. But DDoS attacks to EU or the US aren't launched from China/Africa anyway.

You need relatively low capacity to start an amplification attack, so a server at some ISP which doesn't care is enough. There are some ISPs which knowingly allow this, like Ecatel in The Netherlands which is probably the most notorious example.


As dsl pointed out, this filtering is already enforced, but it presents caveats and limitations: http://tools.ietf.org/search/rfc3013#section-4.3


The way to solve this is not through technology but through the bounty, which needs to be assisted-sponsored by the government(s) as it affects global strategic infrastructure.

Post $5-$10M bounty to find those responsible, make their buddies to salivate to give them up and then make the public case out of them for others to think 10 times more before engaging in stupidity.


NTP reflection attack technical explanation: http://blog.cloudflare.com/understanding-and-mitigating-ntp-...


"Cloudflare did not return a request for more information..."

lol.


In my opinion, the NTP reflection attacks are a result of a larger problem on the internet - large payloads being delivered without any sort of connection handshake. While it is easy to blame open ntp servers, dns resolvers, and snmp servers - these protocols wouldn't be as easy to abuse if the internet hadn't grown to rely on UDP. UDP is a connectionless protocol, so there is no handshake before data is thrown at the vulnerable target. Worse yet, there is no way to 'reset' function in these protocols, so there is no way for the victim to tell the remote host to shut up.

As for the targets of these attacks. They're still happening. It's honestly a pretty stupid attack. The connections from victim:80 to ntpserver:123. The attackers don't seem to understand that port 80 is not a commonly used UDP port. I'm seeing the following targets in my ntp server's logs:

37.187.133.51 (OVH) 216.33.93.214 (edline.com) 23.9.97.251 (akamai) 59.7.146.69 (Korea Telecom) 198.50.139.161 (OVH) 217.236.16.131 (Deutsche Telekom)



Is 400 Gbps globally really that much?


It may not be a good idea to measure DDoS merely based on the volume. For example, a 100Gbps L7 attack is much harder to mitigate than a 100Gbps L3 attack. [1] Also, some had previously questioned the accuracy of CloudFlare's figures. [2]

[1] https://blogs.akamai.com/2013/03/how-big-is-300-gbps-really.... [2] http://www.techweekeurope.co.uk/news/prolexic-ceo-scott-hamm...


CloudFlare has 24 datacenters worldwide. That works out to 16 Gbps per DC if evenly distributed, or roughly 2 10 GigE circuits.


Pointed to a single target: yes.


Obviously yes. Even for an anycast network like CloudFlare. Not that they can't mitigate it, but it's hard and not free to do so.


The target is probably : http://egaliteetreconciliation.fr/

Edit : French customer, use cloudflare and OVH. Is strongly attacked by ddos since yesterday


yeah right, another blurb of conspiracy theorists.

who cares about those guys anyway.



yeah it's easy to unite people around conspiracy theories




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: