Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Could someone analyze this info? We got information that slowloris attack took place. They say (hosting stuff) they have implemented mod_antiloris, is that enough btw? Feel free to share your opinion on this and tell whether all instances are normal. Thanks.

Linux 2.6.37.6-24-desktop (our-website-name) 08/05/13 _x86_64_ (8 CPU)

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 2.60 123.85 2.74 33.30 99.91 1257.43 37.66 1.69 46.77 1.88 6.78

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 47.60 0.80 19.00 8.00 532.80 27.31 0.13 6.74 2.88 5.70

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 68.20 1.20 113.40 9.60 1452.80 12.76 2.49 21.73 0.61 7.02

[Mon Aug 05 04:47:30 2013] [warn] Rejected, too many connections in READ state from 189.46.162.217 [Mon Aug 05 04:47:30 2013] [warn] Rejected, too many connections in READ state from 111.95.142.240

share|improve this question

migrated from programmers.stackexchange.com Aug 5 '13 at 12:50

This question came from our site for professional programmers interested in conceptual questions about software development.

    
Knowing the fact there is real-time application involved in this (I didn't mention that), What could be exploited to lead to such attacks like above? –  user2633999 Aug 5 '13 at 12:49

2 Answers 2

Slowloris is a kind of Denial-of-Service attack in which the attacker tries to exhaust your server's resources by opening a lot of connections to it, but being extremely slow. Each open connection consumes some resources on your server: just a a bit of RAM for the connection buffers and socket state, but that's resources nonetheless.

mod_antiloris is a heuristic filter for such attacks. It tries to detect situations which are definitely fishy; in this case, when a single client (an IP address) has opened a lot of connections to your server and still has all of them in "READ" state, meaning that in the HTTP protocol, all these clients are supposed to talk next, but do not, or do it very slowly.

As with all heuristic tools, there is a trade-off: if the filter's threshold is too high, then an attacker may maintain a medium-scale attack while keeping under the radar. But if the threshold is too low, then you will begin to reject legitimate users. The main problem with mod_antiloris is that it works with IP addresses so it can be at odds with NAT: if a lot of distinct human users are connected on a single network which does NAT (e.g. 50 students from the same class, on a University network), then all their connections will appear, from your server, to come from the same IP address, and this may trigger mod_antiloris even though these clients would all be legitimate. Conversely, if the attacker is motivated enough to go distributed (launching the attack from a botnet, i.e. a lot of distinct hosts under his control), then mod_antiloris won't help, because this will look like a lot of distinct, legitimate clients.

In any case, I suggest that you leave this issue to the people who handle your hosting: this is best addressed at their level. You might want to investigate who could possibly have a grudge against you, but it is possible that the attack is non-malicious after all: a buggy scripted client software can have the same effect (although it would probably not appear as coming from two distinct IP addresses, one in Brasil and one in Indonesia).

share|improve this answer
    
Thank you very much for the exhausting information. The problem could be that we are using chat app (PHP based + Pusher Websockets). We use Pusher (pusher.com) to maintain connection and all messages to be handled outside of our website so we won't get too much load. Could this be one of the causes? Btw yes I checked the IP addresses, I'm gonna find them. –  user2633999 Aug 5 '13 at 13:16

first, aks for your apache-version; in apache >= 2.2.16 this problem is/should be fixed.

if you want to know if you are attackable by slowloris, just stresstest your servers, but misusing http to create a "real time" application might be involved too :)

"atop" might help analyzing your problem.

btw, for such stuff with lots of connections i'd prefer nginx.

share|improve this answer

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.