If you use apache... Must read
Moderator: General Moderators
Re: If you use apache... Must read
That is disturbing.
Useful info for the mod! Thanks.
Useful info for the mod! Thanks.
Set Search Time - A google chrome extension. When you search only results from the past year (or set time period) are displayed. Helps tremendously when using new technologies to avoid outdated results.
Re: If you use apache... Must read
Yea this guy I know took down some major sites. Also check out a tool called pyloris. GOogle for "pyloris sourceforge". Its a GUI, so you just point & click. My friend runs it from his phone... lol
Better protect yourself, because its undetectable while underway (by that I mean the symptoms will be a ton of httpd processes running, and denial of service, but no log entries written).
Another alternative is to simply install squid cache/nginx as a primary webserver, or as a reverse proxy for apache. I hear these reverse proxies will only pass off the request after a full request has been made. Certain firewalls & load balances can provide varying degrees of protection.
Another way to patch this is with mod_qos, although that has a higher potential to lock out legitimate users, and is not plug & play, and may or may not be as effective as mod_slowloris. mod_slowloris claims to inspect headers, with that installed I can only open 16 connections. I did exhaustive testing and nothing, even changing max_servers, fixed it except for installing mod_slowloris.
mod_slowloris only shows <100 downloads, which is pretty indicative of how unpached this issue is, with 50% of the interweb running apache. Apache has also said its a "feature" and will not fix it (gotta love open source, right?).
I have also heard that godaddy's shared hosting offers protection, this may/may not be also true of other shared hosting providers.
Better protect yourself, because its undetectable while underway (by that I mean the symptoms will be a ton of httpd processes running, and denial of service, but no log entries written).
Another alternative is to simply install squid cache/nginx as a primary webserver, or as a reverse proxy for apache. I hear these reverse proxies will only pass off the request after a full request has been made. Certain firewalls & load balances can provide varying degrees of protection.
Another way to patch this is with mod_qos, although that has a higher potential to lock out legitimate users, and is not plug & play, and may or may not be as effective as mod_slowloris. mod_slowloris claims to inspect headers, with that installed I can only open 16 connections. I did exhaustive testing and nothing, even changing max_servers, fixed it except for installing mod_slowloris.
mod_slowloris only shows <100 downloads, which is pretty indicative of how unpached this issue is, with 50% of the interweb running apache. Apache has also said its a "feature" and will not fix it (gotta love open source, right?).
I have also heard that godaddy's shared hosting offers protection, this may/may not be also true of other shared hosting providers.
- Jonah Bron
- DevNet Master
- Posts: 2764
- Joined: Thu Mar 15, 2007 6:28 pm
- Location: Redding, California
Re: If you use apache... Must read
Hm, an interesting attack. Very simple. Why is that a "feature"?
Re: If you use apache... Must read
I guess holding open 3,000 HTTP connections past their configured keep alive time sounds like a good "feature" to them. Either that or this finally proves developers are the worst type of person to deal with. Ironically enough Apache is essentially the only popular web server that is vulnerable.
Apache says its a feature because for example when you run this attack on Microsoft IIS, it only keeps 120 sockets, as it opens the 121st IIS immediately closes the pipe to the 1st socket without letting it complete. In practice this never interrupts a legitimate user, however Apache in my opinion has decided to "program theoretically" and instead of in the "real world". In their minds a user could want to open 121 tabs and might be on such a slow connection that by the time the 121st tab has completed the server hasn't even received a full http response on the 1st tab, and Apache is saying rather than take that risk, they'll just leave this "issue" unpatched.
However it truly is a bug, because a user's browser will send valid headers, slowloris sends "garbage" headers (redundant, invalid, and/or incomplete headers).
Apache says its a feature because for example when you run this attack on Microsoft IIS, it only keeps 120 sockets, as it opens the 121st IIS immediately closes the pipe to the 1st socket without letting it complete. In practice this never interrupts a legitimate user, however Apache in my opinion has decided to "program theoretically" and instead of in the "real world". In their minds a user could want to open 121 tabs and might be on such a slow connection that by the time the 121st tab has completed the server hasn't even received a full http response on the 1st tab, and Apache is saying rather than take that risk, they'll just leave this "issue" unpatched.
However it truly is a bug, because a user's browser will send valid headers, slowloris sends "garbage" headers (redundant, invalid, and/or incomplete headers).
Re: If you use apache... Must read
Here is code from httploris.py (part of the pyloris package)
As you can see it will send a bunch of otherwise valid HTTP headers, but the '\r\n\r\n' that marks the end of a header and beginning of the http document, is never sent. The server keeps sockets allocated waiting for that connection to complete. Apparently this counts toward Apache's "max servers" setting(?), which when reached, or when the Operating System allocates all it's sockets(?), denial of service is achieved.

Code: Select all
request = '%s %s HTTP/1.1\r\nHost: %s\r\nUser-Agent: %s' % (requesttype, options.page, args[0], options.useragent)
if options.keepalive == True:
request += '\r\nKeep-Alive: 300\r\nConnection: Keep-Alive'
if options.gzip == True:
request += '\r\nAccept-Encoding: gzip'
if options.referer != '':
request += '\r\nReferer: %s' % (options.referer)
if options.size > 0:
request += '\r\nCookie: '
if options.size > 100:
count = options.size / 100
for i in range(int(count)):
request += ('data%i=%s ' % (i, 'A' * 100))
request += 'data=' + ('A' * 100)
else:
request += 'data=' + ('A' * options.size)
if options.finish == True:
print("Specifying the -f or --finish flags can reduce the effectiveness of the test and increase bandwidth usage.")
request += '\r\n\r\n'
http://lwn.net/Articles/338407/ (AFFECTS/not AFFECTS is wrong @ this link! Squid is protected.)The way the script achieves this goal can be likened to a person at a checkout lane in a store. Everyone has encountered someone paying the cashier, one by one — literally — in pennies. This can take time; often it feels like it is taking forever.
To the company that has a chain of several stores, this random person does not affect its business. For an online shop, however, there is a single URL and slowloris unleashes hundreds if not thousands of these people approaching the checkout lane with an endless supply of pennies ready to block the queue. For HTTP, slowloris uses HTTP headers instead of pennies, and it is ready to add a new header every 5, 10, or 299 seconds.
From my reading of the script though, it simply sends (part of a) http request once, it doesn't sit there slowly adding character by character like this particular article implied.Unfortunately, the Apache at the cashier has no memory. With every penny dropped in its hands, it resets the timeout counter. With this technique it is rather simple to block every server thread or prefork process and bring the web server to a complete halt. Because the default timeout setting for Apache is 300 seconds, each header added can stretch things out for that much longer.
What ticks me off is everyone calls it a DDos, lumps in with a regular DDos, tells their clients there is no way to block it. In fact it is a BUG in an application you runthe well-known proprietary alternative from Microsoft, IIS, is not affected by this problem, there are other solutions. What IIS does differently, is in the way it handles incoming requests: There is no static tie between a worker thread and a network socket in IIS. Rather, the workers are organized in a pool where they wait for incoming TCP packets (rather than TCP connections as Apache does). These packets are then assigned dynamically to threads. So, an idle connection occupies a socket, but it does not block an entire thread. Thus the web need not be shut down by penny-wielding customers or slowloris.
Re: If you use apache... Must read
Similar "bug" appears in all TCP stack implementations - TCP SYN flood attack, though some may apply some defense (e.g. TCP SYNCOOKIES).
IMHO, it's not a bug, but a feature indeed, though it can be exploited maliciously.
IMHO, it's not a bug, but a feature indeed, though it can be exploited maliciously.
There are 10 types of people in this world, those who understand binary and those who don't
Re: If you use apache... Must read
Right, I consider it to be a bug with that feature. Having a feature is fine, but if it can be exploited I consider that a flaw/defect of the system. Especially when every other popular web server is not vulnerable. That's why I made the joke developers are "bad" people, the users are looking at the system from a black box point of view, not the inner implementation. If TCP/IP is flawed for example, and someone sells a firewall, and it doesn't block these attacks either, I would say both technologies are to blame.. TCP/IP and the firewall are both at fault for the vulnerability existing. Both made the promise of "doing X", yet users found conditions under which it no longer does X. (it could have been patched at any layer, but the developers each just shifts the blame to the adjacent layer).
I mean I'm not saying I could have designed it better, but I have higher hopes for humanity than a bunch of "half working" stuff.
I mean I'm not saying I could have designed it better, but I have higher hopes for humanity than a bunch of "half working" stuff.
- Jonah Bron
- DevNet Master
- Posts: 2764
- Joined: Thu Mar 15, 2007 6:28 pm
- Location: Redding, California
Re: If you use apache... Must read
It's nice to be the optimistic typejosh wrote:... but I have higher hopes for humanity than a bunch of "half working" stuff.
Re: If you use apache... Must read
Mostly every feature can be exploited, but it does not classify it a "bug".
For example (I havent tried it
), everyone here has used PHP session. So, there are files containing:
If you develop a simple script that performs a flood of requests to one of these, you will see that your session.save_path directory will be flooded with sessions files and soon or later it will be out of available inodes and will crash your server 
So, should we consider it a bug?
For example (I havent tried it
Code: Select all
session_start();So, should we consider it a bug?
There are 10 types of people in this world, those who understand binary and those who don't
Re: If you use apache... Must read
You need a DDoS for this (since the session will expire and you have to be able to create and support enough sessions). This is not a bug, it's about the server capacity (actually would you save session in a file if you are creating a busy site, or in the database - try filling the inodes in this case, or will prefer stateless application?)VladSun wrote:Mostly every feature can be exploited, but it does not classify it a "bug".
For example (I havent tried it), everyone here has used PHP session. So, there are files containing:
If you develop a simple script that performs a flood of requests to one of these, you will see that your session.save_path directory will be flooded with sessions files and soon or later it will be out of available inodes and will crash your serverCode: Select all
session_start();
So, should we consider it a bug?
The problem with slowloris is that it allows single computer to take down the server (as opposite to the failed DDoS to Amazon where even DDoS didn't took them down)
By the way, there are web server like Tornado that offer non-blocking connections and can handle order of magnitude more connections than apache.
Re: If you use apache... Must read
All of these are quite obvious, Darhazer. I'm just arguing that a lot of features (I would even say 100%) introduce some kind of weaknesses. But we still need them.
There are 10 types of people in this world, those who understand binary and those who don't
Re: If you use apache... Must read
Well in fact one may consider it as a "bug", because even empty sessions create files... And it's not about how bussy a website is - it's website under attack.Darhazer wrote:... This is not a bug, it's about the server capacity (actually would you save session in a file if you are creating a busy site, or in the database ...
There are 10 types of people in this world, those who understand binary and those who don't
Re: If you use apache... Must read
Which is not a bug of sessions themself, but of the default PHP implementation, and PHP is quite buggy softwareVladSun wrote:Well in fact one may consider it as a "bug", because even empty sessions create files... And it's not about how bussy a website is - it's website under attack.Darhazer wrote:... This is not a bug, it's about the server capacity (actually would you save session in a file if you are creating a busy site, or in the database ...
Re: If you use apache... Must read
The difference between the examples you are giving and slowloris, as Darhazer pointed out, is slowloris requires only a fraction of a KBps connection to execute, the other "floods" you point out require your computer's resources to be comparable to, or exceed the resources of the server. And yeah, I still consider them all bugs if they can be exploited. They can be fixed in a way that does not break the feature, as IIS, squid, nginx, etc.. have all proven.
The point of the Apache feature doesn't even work well, apparently people switch to nginx all the time because their legitimate dialup users unintentionally emulate a slowloris attack.
The point of the Apache feature doesn't even work well, apparently people switch to nginx all the time because their legitimate dialup users unintentionally emulate a slowloris attack.