Hacker News Reader

Comment by goatsi | Hacker News Reader

The software has nothing to do with it, the "vulnerability" is that they probably have a 1Gbps port that is getting 5Gbps of reflected UDP thrown at it. I'd love to see your software mitigation for that.

View on HN

Have a connection broker on another IP address that you authenticate against prior to getting connection details for the real system. Rotate the IP addresses the real system uses every couple of days. Let brokered connections live for 48 hours so the DDOS attack has to last that long to do anything. If the real system gets attacked, drop that IP and pick up a new one, noting what users received that IP address as they are potentially the attacker.

Not perfect but it would probably stop these kids.

Unless the connection broker has more bandwidth than the server, the attack will just take it out instead, still denying access to the site. Either it doesn't work or it's just adding more bandwidth with extra steps. Your solution might help people already connected to the server, but anyone else is still out of luck.

Yes but those extra steps are material in handling the DDOS because of differences in time, effort, and expertise required to get them setup. The work required to handle a UDP flood when your application is TCP only is different than a highly motivated attacker with the resources to do a TCP-based attack that looks like legitimate traffic.

Remember, we're talking about a very motivated 9 years old here.

It will help anyone who connected to the server within 48 hours, it will also eventually reveal who is responsible for the attacks to some degree. This won't work if anyone on the internet can make a account, but this situation is a finte group of people that you can eliminate.

Reply on news.ycombinator.com