-1

lately i'm trying to fight DDOS on my CentOS 6.4 server. I have installed CSF and I've set it quite strictly. Yet there is a URL that have like 1000 requests and max 2 per IP (smart ddos-er I guess).

How do you fight and prevent people to spam reqeusts, apache reports this request for all 1000+ requests... 

POST /wp-login.php HTTP/1.0

If anyone have an idea or suggestion how to fight such thing, without disabling / removing the attacked website.

Thanks for all usefull info in advance.

GioMac
  • 4,444
  • 3
  • 24
  • 41
ProDraz
  • 231
  • 1
  • 4
  • 10

3 Answers3

0

this is maybe still this botnet. IF you use wordpress, you might want to use this plugins (disclaimer: i cannot recommend it, since i dont use wordpress, i just see the scans against wp-login or wp-admin).

if possible: protect /wp-login.php with basic-auth (htaccess+htpasswd)

if you dont use wordpress: nevermind.

if you want to protect yourself against this probes and a lot of others that target various webapps and exploits you'll need some kind of WAF/IDS and a good set of actual and updated signatures. OSSEC might be a good solution because of its good basic-signatures, but i dont know about updates on new attacks and vulnerabilities. mod_security is a good solution but a real performance_killer (both in server-performance and creating new signatures), nginx+naxsi is a good and lighweight-solution for a simple WAF and has got a nice set of recent signatures against scripted scans.

when operating a internet-facing webserver you'll have to get used to these scans; there is a lot more that you will see.

you'll find a "usual scanners" - statistic here; this is a 30-day-result from one WAF about some known exploit-scanners, targeting various exploits.

that guy from over there
  • 1,355
  • 10
  • 11
0

If you have an upstream appliance/device that can filter HTTP traffic before it gets to wordpress, look for something common in each request, such as User-Agent. I've seen them to be exactly the same in my previous experiences with DDoS, which allowed us to filter them out. You can also look for things missing in each request and filter based on that. E.g. all modern browsers will send Accept-Encoding (and, more rarely Accept-Language) headers. If they are missing, it's likely a bot and can be filtered out to stem a DDoS attack. If a request is missing a Host header, then that's pretty much guaranteed to be a bot.

If you do not have an upstream filtering system, you can still do some of that logic with Apache, but your repertoire of tools will be a lot more limited than with something like mod_security.

mricon
  • 1,154
  • 7
  • 9
-1

you can use modsecurity to define any rule you want, block intensive requests with time-based blocking, by counting requests, blacklist, run external app (i.e. block with firewall), forward to proxy, drop packet, reject connection, reset connection, redirect, display 404 error (ir maybe you like error 666), play with variables etc. It can do many things: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual

Example: http://halfelf.org/2013/wp-login-protection-modsec/

SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},initcol:user=%{REMOTE_ADDR},id:5000134
<Locationmatch "/wp-login.php">
    # deny status and log, 401 to client
    SecRule user:bf_block "@gt 0" "deny,status:401,log,id:5000135,msg:'ip address blocked for 5 minutes, more than 10 login attempts in 3 minutes.'"

    # Tracking:  On a successful login, a 302 redirect is performed, a 200 indicates login failed.
    SecRule RESPONSE_STATUS "^302" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0,id:5000136"

    # count last 3 minutes
    SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000137"

    # if matched 10 times, block for 5 minutes
    SecRule ip:bf_counter "@gt 10" "t:none,setvar:user.bf_block=1,expirevar:user.bf_block=300,setvar:ip.bf_counter=0"
</locationmatch>

Also, you can use fail2ban to analyze logs and block client according to that.

GioMac
  • 4,444
  • 3
  • 24
  • 41
  • As the OP specifically pointed out that the attacker is sending at most 2 requests from each IP, hence the first "D" in the DDoS (Distributed). – mricon Sep 04 '13 at 19:18
  • Doesn't matter, `SecRule ip:bf_counter "@gt 1"`. – GioMac Sep 04 '13 at 19:54
  • This will very likely deny legitimate requests. – mricon Sep 04 '13 at 20:59
  • Have you ever configured modsecurity? There is no better WAF. For L7, this is best way to analyze and write different rules with great logic. – GioMac Sep 04 '13 at 21:02
  • Yes, I've used modsecurity extensively in the past. It's effective, but pretty horrible to configure (as most security tools are). Using it they way you suggest -- by counting per-IP accesses -- is not effective in a DDoS scenario. With a distributed botnet, each of the many thousands global nodes will make a handful of requests, each 5-10 minutes apart. Dumber botnets will not vary their headers, so you can filter by that (as I suggest above). Cleverer botnets will vary the headers and make their traffic pretty much indistinguishable from legitimate access. – mricon Sep 04 '13 at 21:13
  • `pretty horrible to configure`? :) OK OK :))) nevermind – GioMac Sep 04 '13 at 21:14