Cant find this issue anywhere...
Using ASP.NET 3.5, I have 3 web servers, in a web farm, using ASP.NET State Server (on a different Server).
All pages Uses session (they read and do update the session)
Issue: my pages are prone to DDOS attack, it so easy to attack, just go to any page, and HOLD down 'F5' key for 30-60 seconds, and the request will pile up in all web servers.
I read, that if you make multiple call to session each will LOCK the session, hence the other request has to wait to get the same user's session, this waiting, ultimately causes DDOS.
OUR solution has been pretty primitive, from preventing (master page, custom control) to call session and only allow the page to call, to adding javascript that disable's F5 key.
I just realize ASP.NET with session is prone to such DDOS attacks!!
Anyone faced similar issue? any global/elegant solution? please do share Thanks
Check this:
Dynamic IP Restrictions: The Dynamic IP Restrictions Extension for IIS provides IT Professionals and Hosters a configurable module that helps mitigate or block Denial of Service Attacks or cracking of passwords through Brute-force by temporarily blocking Internet Protocol (IP) addresses of HTTP clients who follow a pattern that could be conducive to one of such attacks. This module can be configured such that the analysis and blocking could be done at the Web Server or the Web Site level.
Also, Check this:
DoS Attack: Most sites/datacenters will control (D)DOS attacks via hardware not software. Firewalls, routers, load balancers, etc. It is not effeicent or deesirable to have this at the application level of IIS. I don't want bloat like this slowing down IIS.
Also DDOS preventation is a complex setup with even deadicated hardware boxes just to deal with it with different rules and analysis for them that take a lot of processing power.
Look at your web enviornment infrastucuture and see the setup and see what your hardware provides as protection and if it is a problem look at dedicated hardware solutions. You should block DDOS attacks as soon as possible in the chain, not at the end at the webserver level.