At least one web-server, nginx, has the ability to "close the connection without sending any headers", by configuring it to return a (nonstandard) 444 to various malformed HTTP requests.

Is there any actual security value in this, or is it just security theater? How are attackers likely to respond to getting no response from an IP address? If there is any value, what's the cost-benefit ratio? Is it worth the effort to configure nginx to do this?

Update - after thinking about it, there's really two situations where I might want to close the connection. Not just bad HTTP requests, but also well-formed requests for non-existent pages.

For instance, a get /bank-files/index.htm request. There's no such page on my website. However, currently I'm passing all requests through to a Django process, and it obviously returns a 404 on any not-found pages. Given that my site will have a small number of sub-pages known in advance ("/", "/users", "/orders", etc) - I could configure nginx to pass through only those pages, and return 444 (close connection) on anything else. Assuming it's worth it. :)

So is there any value in closing the connection to all the requests that are valid HTTP, but for non-existent pages?

  • What is your threat environment? What assets does the server have or connect to?
    – this.josh
    Sep 26, 2011 at 20:51
  • It is (or will be) a single server, running Django/nginx, with Paypal-based subscriptions (via a HTTPS/SSL cert page). No stored credit cards, no personal information other than email addresses. Login/password via Django auth, which encrypts passwords properly (I hope).
    – John C
    Sep 26, 2011 at 21:59

5 Answers 5


The value is in avoiding having higher-level application software (php, wordpress, whatever) work with and possibly mishandle malformed requests. Since the nginx layer is evaluating for protocol correctness, and not attempting to actually do anything with the request, it's providing a pre-filter.

Terminating the connection abruptly doesn't win you much. It tells the attacker what defensive system you're using, and the same means would be achieved with a generic 404 response with less usefulness to the attacker. But it's the sort of dramatic security theater that crops up now and again, and it doesn't do any real harm to anyone.

  • Just to make sure I understand one part - you're saying that "closing the connection without a response", gives them more information than a generic 404 response? Does it tell them what defensive system is in use, because nginx is the only web-server to do that?
    – John C
    Sep 25, 2011 at 21:00
  • 2
    Yes, that's the idea. It also tells them you're trying to apply low-level security measures, that your guard is up. A simple 404 could be defenses or could be that request just didn't work (which it probably shouldn't because the request was malformed, right?)
    – gowenfawr
    Sep 25, 2011 at 21:47

I think gowenfawr and George Bailey have it right.

Terminating a HTTP protocol connection instead of returning an error response is a very low level mechanism. As a perpetual escapee of the unintended consequences beast, I recommend against implementing a mechanism without a clear purpose. Humans are error prone and you may by accident prevent a valid error message from being sent. Tracking an error without a normal response is just the wrong way to spend a few late evenings, followed by early mornings, followed by late mornings, and so on. Write out your security goals then figure out the mechanisms to meet them.


So is there any value in closing the connection to all the requests that are valid HTTP, but for non-existent pages?

That would be an unusual setup, with little profit. I would suggest reviewing your HTTP headers to see if they leak any information like server version, and stick to 404 on non-existent pages, which is less confusing. I cannot think of any security value to closing the connection except as a very very slight performance increase. (It would actually counter-act keep-alive, but I don't think that matters much for the traffic that is likely bring up 404)

This slight performance boost could start to make a difference in a DoS attack, I don't know how expensive your 404 pages might be. But even then, a DoS attack would be more effective on larger pages of your site to begin with, so this is probably not a likely target.

But then again, I could be missing something.


It reduces the possibility of information leakage.

If I make a malformed request theres the liklihood I'll get something interesting back to tell me about the system.

If the response always returns the same value regardless of the request, then you can't really find out anything about the system through malformed requests.

The worthiness of it is all relative to the system you are trying to protect, and to what degree you are trying to protect. I've never set it up, so I cannot speak to the effort involved.

  • IMHO it increases the amount of information leakage by allowing a fuzzer to probe the defences much faster.
    – symcbean
    Sep 26, 2011 at 12:59
  • but if it's replacing malformed requests and pages not actually existing, then you can't differentiate between the two.
    – Steve
    Sep 26, 2011 at 15:16
  • 1
    Given that we dont know, and are unlikely to find out all sources of information leakage, it is hard to say that this will reduce overall information leakage. My guess is that it will make no significant difference to the total information leakage.
    – this.josh
    Sep 27, 2011 at 7:41

"Security theatre" has nothing do to with your question. You've fallen into the trap of using that as an ad hominem attack against any security procedure you disagree with you.

Correct security is to avoid information leakage. If the URL is not found, then the correct behavior is to give a 404 not found. If the HTTP protocol is malformed, a good behavior is is to simply close the connection (I don't know what the standard says, but I know that's the behavior of most servers).

  • Incorrect - I'm not disagreeing with any security procedure mentioned here. I'm asking if one particular feature of one web-server has actual value, or if it's only a feel-good feature (which is more or less the definition of security theater).
    – John C
    Sep 26, 2011 at 12:42
  • 1
    My point was this: camouflage fatigues are useful in the jungle so that soldiers avoid getting shot. When soldiers patrolled airports after 9/11, jungle camouflage fatigues were so we could identify who was the soldier, and thus, security theatre. Just because they were theatre in that instance doesn't mean they are theatre in all instances. Just because you don't find the capability valuable in your situation doesn't mean it's intention was theatre. Oct 9, 2011 at 10:08
  • 1
    And my point was that I'm neither attacking nor disagreeing with any procedure, it was a question about the validity of the procedure (at least that was the intent). If you remove that first paragraph, I'd be glad to remove my downvote.
    – John C
    Oct 9, 2011 at 12:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .