6

We are about to deploy a web application to a web farm of quite a few web servers. During our testing we have found issues happening in one of the servers but not in others. Most of them because of misconfiguration in the web servers.

Identifying the server that is misbehaving turns out to be time consuming. I thought about adding an HTTP Header to the response with a server identifier. That way we can quickly see from the browser what server processed the request.

Say our web servers are named following the pattern:

  • prodweb1
  • prodweb2
  • prodweb3
  • and so on

The response HTTP header for prodweb1 would be:

X-ServerID: 1

and for prodweb2:

X-ServerID: 2

Is there a security vulnerability in specifying in the response the server that processed the request? Could someone take advantage of this in some way for an attack?

Improve this question

4 Answers 4

Reset to default
6

Does this disclose more information to a potential attacker? Yes. Does it make you vulnerable to an attack that you weren't vulnerable to otherwise? No. You may have helped them attack you a bit quicker. However, they still have to find a flaw to exploit. Really, you are just as secure as you would have been without using a load balancer (or more correctly you are as secure as using one server behind a load balancer as the load balancer could be attacked as well). Is the point of the load balancer security, or to allow more load than a single server could handle?

Now, you probably already log access requests in log files or a database of some sort; typically storing things on each server like IP/time stamp/GET request/HTTP status, Response Size, and User Agent string. Would it be possible in debugging to run a quick grep over the relevant logs to identify the server that's not performing? E.g., change the User-Agent in your browser while testing to something like "DEBUG_14_Feb_2013", search for that User-Agent in all the logs and identify the server + requests that are malfunctioning based on response size or timestamp or IP?

Or maybe you could turn this HTTP header on, but only while debugging by having a flag set received from the load balancer (or alternatively set at each server), so its only displayed when you are actively debugging an issue?

Improve this answer
1
  • Those are very good debugging techniques.
    – epignosisx
    Commented Feb 15, 2013 at 13:49
5

As usual, the more data an attacker obtains about your architecture, the easier things become for him. Debug information helps developers and attackers alike. However, the advantage of knowing your detailed server architecture is not as large as often assumed; and it would be suicidal to rely on architecture "obscurity" for security.

See this blog post for some further opinions and pointers.

Improve this answer
3

If an individual server is missing a patch, or has a configuration issue, it can easily be identified by the would be attacker.

If the attacker is trying to target that machine, he will more easily deduce what load balancing approach you're using (standard cookie, source IP, vs authentication hash). He can use this information to attack each server individually.

Improve this answer
2

Any information that is not necessary should not be given to the world. If might be used in some chained exploit and might be valuable correlated with other isolated information.

Ex: If you're load balancing the connections it would be easier for the attacker identify and try to lock the session to the server.

Improve this answer

You must log in to answer this question.

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