DDOS Protection for Enterprise applications and web infrastructures
The time of static applications that just wait to be hit by a massive number of requests has gone.
This piece of code is an example of a Self-Protective servlet filter able to defend itself against such attacks by utilizing the Remotely Triggered Black Holling technique.
The servlet filter is able to apply a remotely triggered black holing as per RFC 5635.
Distributed DDOS attacks are attacks that can't be stoped by a firewall, access list, simple linux ip filter or iptables, IPS or IDS. If you enable and apply any of those tactics in your infrastructure the devices that enforce those security on the "way" of the attacker traffic will be the first to crash. Then nobody will be able to access your infrastructure and the attacker would accomplish his goals e.g to deny access of limited users to the Internet service offered by you.
There are some engines like Incapsula, Cloudflare or Norsk which will be very much willing to take your money but again won't be really able to help you. What will they do? First will occupy your DNS and will redirect your publically accessed points towards their infrastructure. Then they will allow funcitonality that will snapshot your site (so if you site has dynamic contect simply forget about them) finally they will tunnel the traffic from their infrastructure to yours.
So but how will that help you? In parallel with that they will apply RTBH. They have connections with some ISPs and major content hosting providers and will try to hide them and you from the eyes of the attacker. This works sometimes if you are lucky and your stuff has been hosted in an ISP with which they have good connections but in many cases and in many contries their service simply won't work well.
Thus instead of using such complex solutions we offer you a way to help yourself. If you an ISP and would like to use our ddos-servlet-filter you can easily expose it as an API and grant access to your customers to it. So once they are under an attack they would pull the "triggers" notify your API and you will block the attakcer traffic for them.
How the traffic will be blocked since we don't apply security rules or imply complex security equipment being used. Well we will simply a bit the situation and will blackhole directly the traffic on IP forwarding level at the endge of your network. Since the edge is typically distributed this method even if it does not give 100% guarantiees offers the most scalable way of dealing with DDOS. It has been described in RFC 5635 and has been used by Google, amazon and many, many other ISPs.
If you a final customer of an ISP your choice is to look for and ISPs or hosting operators that have that mechanism in place. If they don't and if they tell you to call their NOC in case of an DDOS security issues run away as fast as you can. If they offer your an API endpoint through which you to be able to pull the trigger well that's better.
Finally bellow let's see in more details how the rtbh-ddos-servlet actually works.
Then if certain threashold is triggered will pull the RTBH trigger and will put it in quarantine.
There is also a quarantineController initialized in the init method of the servlet filter that checks for prefixes with expired quarantine period. For those the trigger route will be deleted.
Note that in order that servlet filter to be useful for you you will have to have access to network infrastructure.
It is a simpleexample on how enterprise applications could benefit from RTBH and be self-adaptive in dealing with DDOS attacks. It is not a silver bulet and won't work straight in your infrastructure. You will have to put some effort and to adapt it for your particular application, network devices and business case.
Interested in and have some questions? Please use our contact form and we will be more than happy to answer!