Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Moved from Stackoverflow.

I have a LAMP server running Ubuntu with security programs such as Denyhosts, Fail2ban and with Mod_security installed but seem to constantly be the target of a DDOS attack. Here is a section of the access.log:

    83.57.208.254 - - [07/Oct/2013:12:44:32 +0100] "POST / HTTP/1.1" 200 14225 "" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
    71.234.72.17 - - [07/Oct/2013:12:44:33 +0100] "POST / HTTP/1.1" 200 14225 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
    77.242.132.166 - - [07/Oct/2013:12:44:36 +0100] "POST / HTTP/1.1" 200 14227 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
    41.215.148.226 - - [07/Oct/2013:12:44:37 +0100] "POST / HTTP/1.1" 200 14227 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
    193.95.115.254 - - [07/Oct/2013:12:44:37 +0100] "POST / HTTP/1.1" 200 4621 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
    77.252.113.238 - - [07/Oct/2013:12:44:37 +0100] "POST / HTTP/1.1" 200 14225 "-"         "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
    203.125.241.10 - - [07/Oct/2013:12:44:40 +0100] "POST / HTTP/1.1" 200 14259 "-"         "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
    202.3.84.79 - - [07/Oct/2013:12:44:40 +0100] "POST / HTTP/1.1" 200 14248 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
    125.60.156.222 - - [07/Oct/2013:12:44:42 +0100] "POST / HTTP/1.1" 200 14233 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
    41.194.49.44 - - [07/Oct/2013:12:44:44 +0100] "POST / HTTP/1.1" 200 14258 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
    79.211.175.35 - - [07/Oct/2013:12:44:45 +0100] "POST / HTTP/1.1" 200 14258 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
    109.86.12.76 - - [07/Oct/2013:12:44:46 +0100] "POST / HTTP/1.1" 200 14258 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
    84.121.39.44 - - [07/Oct/2013:12:44:47 +0100] "POST / HTTP/1.1" 200 14259 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
    86.148.77.223 - - [07/Oct/2013:12:44:49 +0100] "POST / HTTP/1.1" 200 14259 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"

Based on http://systembash.com/content/how-to-stop-an-apache-ddos-attack-with-mod_evasive/ this appears to be a "Sloworis" attack and is happening constantly. I have installed Mod_evasive but because it only seems to be 1 request a second from unique IP addresses it hasn't made any difference.

When other genuine users are on other sites at the same time Apache seems to get too many child processes and hang, needing to be restarted although I am not sure if they are related.

Are there any ways of tuning Apache to help prevent this from taking place?

Thanks for any help.

share|improve this question

2 Answers 2

up vote 0 down vote accepted

no, POST is never a slowloris-attack; if then, a R-U-D-Y - attack (are you dead yet?; google for it, if you dont know). distributed 1-threaded slowloris/rudy doesnt make sense and IIRC, you wouldnt see slowloris / rudy in the logs, because the request never gets completed (thats the point of those kind of attacks); this looks more like a brute-force-attack; is there something to login on / ?

your apache is burning when receiving 1 Request/second? seems like you should tune your setup a little more.

Are there any ways of tuning Apache to help prevent this from taking place?

apache >= 2.2.16 isnt vulnerable to slowloris anymore (dont know about rudy), but if you want to handle such stuff for certain: mod_antiloris exists for apache,

if you want to create a sure mitigation: place a reverse proxy like nginx or varnish infront of your apache.

if there is nothing to POST to on /, make yourself a mod_security - rule or fire up a 403 with rewrite-rules

share|improve this answer
    
Requests to sites show the host name in the logs so this is why I didn't expect it to be a brute force. Since they are all using the same user agent I looked through Fail2ban and saw that there's an apache-badbots that wasnt enabled that contained an almost identical username, I added: Mozilla/4\.0 (compatible; MSIE 6\.0; Windows NT 5\.1; SV1) enabled the jail and restated Fail2ban. So far 1100 IPs have been banned and it is still going. Thanks for the help. –  Thomas Oct 8 '13 at 14:13
    
yeah, i overlooked the UA too :) this UA has been seen from other sources as malicious too –  that guy from over there Oct 9 '13 at 7:23

Caveat: Potentially useful for "Single Server Installations Only", if you have something more complex, you will need a more complex solution.


I use iptables LIMIT functionality.. doesn't care what they are trying to brute-force, slows them down, but leaves everyone else running fine. ;-)

IE: Hundreds of failed ssh logins

This is part of my bash firewall script (it saves to iptables-save at the end, where $IPT is defined earlier as /sbin/iptables)

echo "HTTP/S hash-based-limiting"
$IPT -N LIMIT
$IPT -A LIMIT -j LOG --log-prefix "IPTABLES LIMIT: "
$IPT -A LIMIT -m recent --set --name attacks -j DROP
$IPT -A INPUT -m recent --update --seconds 180 --name attacks -j DROP
$IPT -A INPUT -p tcp --dport 80  -m state --state NEW -m limit --limit 25/minute --limit-burst 100 -j ACCEPT
$IPT -A INPUT -m state --state RELATED,ESTABLISHED -m limit --limit 50/second --limit-burst 50 -j ACCEPT
$IPT -A INPUT -m hashlimit --hashlimit-srcmask 32 --hashlimit-mode srcip -p tcp -m state --state NEW --hashlimit-above 10/minute --hashlimit-burst 15 --hashlimit-name webflood --dport 80  -j LIMIT
$IPT -A INPUT -m hashlimit --hashlimit-srcmask 32 --hashlimit-mode srcip -p tcp -m state --state NEW --hashlimit-above 10/minute --hashlimit-burst 15 --hashlimit-name webflood --dport 443 -j LIMIT

Basically, no human will be making more requests than that, so it only blocks bots, it doesn't stop them, it just shapes them, you could of course simply change the endpoint chain to DROP instead of LIMIT. Tweak the values to suit your server.

Don't forget:

/sbin/modprobe ip_conntrack
echo "Enabling syncookies protection"
echo "1" > /proc/sys/net/ipv4/tcp_syncookies

I've obviously implemented various flood-protections against service ports, 20:22 and these web-ports.. anyone on my deny-hosts system gets added to a complete iptables based blacklist and other things. So far, working pretty well.

If users "stop" flooding server, they get released automatically after 180s, so it doesn't require a lot of maintenance, and LIMIT'ed connections show up in logwatch reports.

I would allow your local servers or users before this as backups and such will sometimes cause themselves to get limited.. especially heavy SOAP usage!

share|improve this answer
    
be carefull when advising such rules; your setup might fit a small site, but will fail when you have many mobile-clients that visit using the same ip via forced proxy. btw, for detectign and blocking ssh-brute-force i'd prefer denyhosts/fail2ban. –  that guy from over there Oct 9 '13 at 7:18
    
I use denyhosts and fail2ban, but it will only catch it "after" its scanned the logs.. this will pick it up "before".. so you can shape someone who is trying lots of passwords really quickly trying to get in before the daemon checks. –  Grizly Oct 9 '13 at 22:44

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.