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
