RE: option httpchk version 'trick'

Hi Willy,

I was shooting from the lip with respect to the cookies. It's really about what scenarios you need to consider. If the client can choose the server they get directed to then you have to give that some thought and make sure your application behaves in a sensible manner. This would be considered in the case of failovers anyway. If observation of a number of sessions reveals something about your server farm then, again, that needs to be considered.

Mitigating these concerns is not something that HAProxy should have to deal with, session management at that level is an application problem.

With respect to your lock analogy I would add that all locks can be picked given enough time. Whilst obscurity is not security it can increase the time required to pick the lock. Make your thief work for the information and they may go somewhere else or, more importantly, you increase your chances of seeing them working on the lock.

This surveillance is the responsibility of the application. Once there is an understanding of these system failure modes (and it is not an HAProxy failure) then the appropriate security requirements can be formulated.

Cheers,
Andrew

-----Original Message-----
From: Willy Tarreau [mailto:w#1wt.eu]
Sent: Saturday, 27 February 2010 8:39 PM To: Andrew Commons
Cc: haproxy#formilux.org
Subject: Re: option httpchk version 'trick'

Hi Andrew,

On Sat, Feb 27, 2010 at 07:59:27PM +1030, Andrew Commons wrote:
> Hi Willy,
>
> Thanks for the comprehensive response. My HAProxy experience is measured
in
> days and the mailing list seems a great way to get support and your
> contributions are always spot on. HAProxy looks like a fantastic, highly
> professional, piece of software.

At least we try to make it reach that goal :-)

> With respect to the HTTP check internals I think that what you are
proposing
> is good.
>
> I'm still working through the implications of adding the cookies to the
> responses. This is not uncommon in a variety of applications but if we
> assume that it tells someone that HAProxy is there then does it give them
> any leverage. I have to read some more of the excellent documentation and
> play a bit.

There are many ways to detect intermediate systems. For instance, with apache, you just have to send TRACE requests with Max-Forwards. With haproxy, you can send invalid requests and try to see if the response looks like the default HTTP 400 response, etc... Of course, you could use many tricks to try to hide that, but there are always ways to detect with a great probability what components you're using. I work in environments where the security teams are extremely picky on this, but after the years, they finally make a difference between being able to identify one component and being able to abuse the rest of the infrastructure.
After all, if someone can tell you're using haproxy, he also knows that you can rewrite all headers and block the requests you don't like, so he will know that he cannot trust the responses to his identification requests that pass through it. That's the most important point.

To make an analogy with doorlocks, sometimes you'd rather have a solid lock with its brand engraved in it that will successfully keep thieves away than have a noname one which breaks at the first lock pick.

Regards,
Willy Received on 2010/02/27 14:08