February 28th DDoS Incident Report • Hacker News Board

Re: February 28th DDoS Incident Report

#111

Post by franga2000 » Fri, Mar 02, 2018, 2:41 PM UTC

consumer451 wrote: post #107

bhauer wrote: post #60

Am I old-fashioned to raise an eyebrow when I discover that Memcached servers are running visible to the public Internet? This strikes me as approximately as bizarre as having a database server that accepts connections from the public Internet. In my day, such back-end services were either simply not connected to the Internet (connected via a private network to the application services), firewalled, or at the very le…

A bit off-topic, but I had the same thought when I read about Jenkins servers on the public Internet in this piece.[0] But when I read that he had found a public facing Jenkins server owned by Google, I figured I must be missing something. I run a 2 man shop, but I still keep things like Jenkins behind OpenVPN. Why would anyone leave Jenkins open? There must be a reason, right? https://emtunc.org/blog/01/2018/researc…

Many open-source applications (especially Java-based) use a public-facing Jenkins server for running and distributing nightly and PR builds. Nowadays, this is usually handled by hosted CI (Travis or GitLab), but there are still some who prefer good old Jenkins.

Re: February 28th DDoS Incident Report

#112

Post by dylz » Fri, Mar 02, 2018, 8:28 PM UTC

toomuchtodo wrote: post #91

hueving wrote: post #87

Earlier quoted context omitted.

Your confused if you think it's the clouds that are misconfigured here. The issue is the ISPs allowing the spoofed traffic going towards the memcached servers.

If you’re a service provider allowing your equipment to participate in an amplification attack, you’re the fool trashing the commons. It’s an ISPs job to filter outbound udp on arbitrary ports? Shall we only let 443 tcp outbound from eyeball networks?

udp is also used for web traffic, a very very large amount of web traffic - so you can't really block it.

Re: February 28th DDoS Incident Report

#113

Post by dec0dedab0de » Sat, Mar 03, 2018, 5:05 AM UTC

hueving wrote: post #88

dec0dedab0de wrote: post #57

Earlier quoted context omitted.

How could source IP spoofing help with DDoS mitigation?

This particular case relied on botnets being able to spoof their their source IP to match github's so the memcached responses would go to github. Google 'DRDoS attacks' to learn more. They are responsible for most of the largest volume attacks IIUC.

I understand the attack, I dont understand how it could be mitigated using the same technique.

Re: February 28th DDoS Incident Report

#114

Post by hueving » Sun, Mar 04, 2018, 7:42 PM UTC

mnw21cam wrote: post #108

hueving wrote: post #105

Earlier quoted context omitted.

Any UDP service can be used in an amplification attack. It's not the responsibility of AWS or other hosting companies to shut down all UDP traffic. The problem is the ISPs allowing spoofed IPs.

So the problem here is that a number of UDP packets were sent from somewhere (with a small bandwidth) that had a spoofed source address. They were then sent to the reflection servers which produced more/bigger UDP packets that did not have a spoofed source address. So the attacker only needs to find somewhere on the internet that is capable of generating spoofed packets. They needed a lot of places that had a reflect…

And taking down UDP services is just as folly. It only takes a 1000 servers with 100 mbps upload streams to wipe out any single load balancer. There are at least that many root name servers.