Re: [ANNOUNCE] haproxy-1.4.0
Hi Holger, On Sat, Feb 27, 2010 at 01:28:12PM +0100, Holger Just wrote: > Hi all, > > On 2010-02-26 16:02, Willy Tarreau wrote: > > I'm obviously interested in any problem report :-) > > I'm trying to compile Haproxy 1.4 on Opensolaris Build 133 (i386 on a > Core i7). This however fails. thanks for your report. Could you please try to add the two following lines at the top of the 3 faulty files (types/session.h, types/proxy.h, types/protocols.h) : #include #include I think it should fix the build. Thanks! Willy
Re: sL flag
On Sat, Feb 27, 2010 at 10:17:12AM -0800, Joe Williams wrote: > Looks like all the most recent sL's I have seen have been GET requests. OK thanks Joe. I will look into the code to see how we can produce that. Maybe it's normal, but no obvious case comes to my mind. Regards, Willy
Re: sL flag
Looks like all the most recent sL's I have seen have been GET requests. Thanks. -Joe On 2/27/10 10:08 AM, Joe Williams wrote: Willy, This was on 1.3.23, it might have been a POST I will need to go back through the logs to find out. Thanks. -Joe On 2/27/10 12:26 AM, Willy Tarreau wrote: On Fri, Feb 26, 2010 at 03:07:40PM -0800, Joe Williams wrote: I wasn't able to find it in the documentation, what does the "sL" termination flag stand for? strange. It means there was a server timeout during the last transfer from the server to the client. But normally the last transfer is identified because the server has already closed, so it's strange to see a timeout. Or maybe it was a post and we got the timeout in the other direction. I'm a bit puzzled. What version was it ? Regards, Willy -- Name: Joseph A. Williams Email: j...@joetify.com Blog: http://www.joeandmotorboat.com/
Re: sL flag
Willy, This was on 1.3.23, it might have been a POST I will need to go back through the logs to find out. Thanks. -Joe On 2/27/10 12:26 AM, Willy Tarreau wrote: On Fri, Feb 26, 2010 at 03:07:40PM -0800, Joe Williams wrote: I wasn't able to find it in the documentation, what does the "sL" termination flag stand for? strange. It means there was a server timeout during the last transfer from the server to the client. But normally the last transfer is identified because the server has already closed, so it's strange to see a timeout. Or maybe it was a post and we got the timeout in the other direction. I'm a bit puzzled. What version was it ? Regards, Willy -- Name: Joseph A. Williams Email: j...@joetify.com Blog: http://www.joeandmotorboat.com/
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
Re: [ANNOUNCE] haproxy-1.4.0
Hi all, On 2010-02-26 16:02, Willy Tarreau wrote: > I'm obviously interested in any problem report :-) I'm trying to compile Haproxy 1.4 on Opensolaris Build 133 (i386 on a Core i7). This however fails. make TARGET=solaris CPU=i686 USE_STATIC_PCRE=1 SMALL_OPTS="-I/usr/include/pcre" [...] gcc -Iinclude -Iebtree -Wall -O2 -march=i686 -g -fomit-frame-pointer -DFD_SETSIZE=65536 -D_REENTRANT -I/usr/include/pcre -DTPROXY -DENABLE_POLL -DUSE_PCRE -I/usr/include -DCONFIG_HAPROXY_VERSION=\"1.4.0\" -DCONFIG_HAPROXY_DATE=\"2010/02/26\" -c -o src/auth.o src/auth.c In file included from include/types/fd.h:32, from include/proto/fd.h:31, from include/common/standard.h:32, from include/common/compat.h:29, from include/types/acl.h:25, from include/proto/acl.h:26, from src/auth.c:22: include/types/protocols.h:87: error: field `addr' has incomplete type In file included from include/types/queue.h:29, from include/types/server.h:37, from include/types/lb_map.h:26, from include/types/backend.h:29, from include/types/proxy.h:40, from include/types/acl.h:30, from include/proto/acl.h:26, from src/auth.c:22: include/types/session.h:170: error: field `cli_addr' has incomplete type include/types/session.h:171: error: field `frt_addr' has incomplete type In file included from include/types/acl.h:30, from include/proto/acl.h:26, from src/auth.c:22: include/types/proxy.h:154: error: field `src' has incomplete type make: *** [src/auth.o] Error 1 I'm at an end here as my knowledge of C is rather sparse as is my (Open)solaris experience. --Holger
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
RE: option httpchk version 'trick'
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. 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. Thanks again. Cheers, Andrew BTW. Read your blog, sorry to see the VAX retired. I might still find a use for the MicroVAXs I and 2000 gathering dust in my shed :-) Great hardware and software (I'm an old VMS guy), pity about the management. -Original Message- From: Willy Tarreau [mailto:w...@1wt.eu] Sent: Saturday, 27 February 2010 6:56 PM To: Andrew Commons Cc: haproxy@formilux.org Subject: Re: option httpchk version 'trick' Hi Andrew, On Sat, Feb 27, 2010 at 03:15:25PM +1030, Andrew Commons wrote: > Hi all, > > The ability to extend the option httpchk argument string to dummy > up a Host header is described as a 'trick' in the configuration > documentation. I have found that the 'trick' can be extended to add > User-Agent (HAProxy) and Accept (*/*) headers to keep ModSecurity quiet when > checking an Apache server. This leads me to two questions: > > (1) To what level is this 'trick' supported? Is an haproxy update likely to > kill it? It's supported and is unlikely to break on future versions. It's a trick because it happens due to the way the request is built, and it requires that users have a bit of HTTP knowledge to use it. > (2) Is there a better way of handling something like ModSecurity that > doesn't like the request generated by haproxy because it doesn't look like > it has come from a browser? right now I have no other solution ! > Note that in respect to question (2) I have messed around a bit with the > ModeSecurity configuration and made some progress but the use of the 'trick' > was far simpler! Recently the HTTP check was internally changed so that the code now supports adding headers. So we could very well have some "http-check" statements to add multiple headers, like this : http-check host www.mydomain.com or : http-check header Host www.mydomain.com or maybe : http-check add "Host: www.mydomain.com" We could even add some POST DATA if required. This needs a bit of thinking before implementing something, but I think we can do useful things now. BTW, if we do that in 1.5 before reorganizing the checks, we'll even be able to backport into 1.4-stable. Regards, Willy
Re: sL flag
On Fri, Feb 26, 2010 at 03:07:40PM -0800, Joe Williams wrote: > > I wasn't able to find it in the documentation, what does the "sL" > termination flag stand for? strange. It means there was a server timeout during the last transfer from the server to the client. But normally the last transfer is identified because the server has already closed, so it's strange to see a timeout. Or maybe it was a post and we got the timeout in the other direction. I'm a bit puzzled. What version was it ? Regards, Willy
Re: option httpchk version 'trick'
Hi Andrew, On Sat, Feb 27, 2010 at 03:15:25PM +1030, Andrew Commons wrote: > Hi all, > > The ability to extend the option httpchk argument string to dummy > up a Host header is described as a 'trick' in the configuration > documentation. I have found that the 'trick' can be extended to add > User-Agent (HAProxy) and Accept (*/*) headers to keep ModSecurity quiet when > checking an Apache server. This leads me to two questions: > > (1) To what level is this 'trick' supported? Is an haproxy update likely to > kill it? It's supported and is unlikely to break on future versions. It's a trick because it happens due to the way the request is built, and it requires that users have a bit of HTTP knowledge to use it. > (2) Is there a better way of handling something like ModSecurity that > doesn't like the request generated by haproxy because it doesn't look like > it has come from a browser? right now I have no other solution ! > Note that in respect to question (2) I have messed around a bit with the > ModeSecurity configuration and made some progress but the use of the 'trick' > was far simpler! Recently the HTTP check was internally changed so that the code now supports adding headers. So we could very well have some "http-check" statements to add multiple headers, like this : http-check host www.mydomain.com or : http-check header Host www.mydomain.com or maybe : http-check add "Host: www.mydomain.com" We could even add some POST DATA if required. This needs a bit of thinking before implementing something, but I think we can do useful things now. BTW, if we do that in 1.5 before reorganizing the checks, we'll even be able to backport into 1.4-stable. Regards, Willy
