Nginx server not safe against ldos | feedback from sys admins? | Hacker News Reader

Nginx server not safe against ldos | feedback from sys admins?

blog.crackerhost.com

Editorialized title on HN? According to article text served by the Google cache says he did this to Apache first, then someone specifically requested a test against Nginx. Those of you saying "it's not Nginx, it's the OS" are definitely correct, please at least acknowledge that the tester/author isn't being completely duplicitous.

Thanks for you 'vote' :). I have responded to the issue of nginx vs os

Attack description and analysis: http://www.cs.unc.edu/~jeffay/courses/nidsS05/attacks/TCP-sh...

I agree with andrewcooke, it doesn't seem to be a problem of nginx or apache. OS TCP implementation should be modified to handle this type of attacks.

why would it matter what the server was? isn't the attack against the TCP/IP stack? (low rate DOS fools TCP's flow control into over-restricting transmission afaict).

the attack was done with slow http traffic. the delay effect on an apache server on the same os(centos) was different than was on nginx(again on centos). also i have been able to control the attack by focusing on the web server - apache or nginx.

From the page summary on Google:

LDoS = low rate denial of service (I didn't know, did you?).

Now the article doesn't load, anyone has the text?

Google cache link: http://webcache.googleusercontent.com/search?q=cache:http://...

Thanks

This article is misleading. as Andrewcooke and jsn point out, this is not about web servers, it is about TCP/IP traffic. For a technical forum such as this, it is appreciated when the underlying causes are enumerated. This comes across as marketing with inadequate technical detail.

Thank you for your comments. I am always learning and take this opportunity to do that as well from someone with a better insight and experience.

On the specific points raised here, please go through:

http://lwn.net/Articles/338407/

Given above is also a similar(not the same) kind of attack, which can bring down an apache web server.

Quoting from this link, "It is not entirely clear which web servers have the means to defend against the attack, but there is general agreement that there is no way for Apache to completely defend against it, and that IIS is not vulnerable to the slowloris technique."

Also quoting, "Obviously, this is an application level attack. In their book on Internet Denial of Service, Mirkovic/Dietrich et. al noted that application level DoS is difficult to handle: "[...] many defenses are not able to help you defend against this kind of attack".

So we are back to what the Apache Security team concluded: This is an inherent problem for servers. If you want to serve, then you have to accept clients, and, if they intend to block you, so be it.

But, let's not give up so fast. Obviously, if the 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. "

If all that the attack has to do with is TCP/IP and has nothing to do with the (type of) web server, it should bring down an IIS server as well. No? Then why is that not the case, above?

1. Any denial of service attack will have to be about connections and therefore tcp/ip. Is that what I missed mentioning? But that is not what this is about. 2. Even http also belongs to the family of tcp/ip 2. The point here is that the attack takes advantage of the way apache or nginx treat connections. It is not a simple tcp/ip flooding. 4. What was it, again, that I am marketing, here?

Honestly looks like there are no real good solutions to this yet.

we have been working on this and have had some success in detecting and stopping an attack. would be glad to share more details, if you want

Go ahead.

Reply on news.ycombinator.com