I think they play with their syslog server to detect a check from real
traffic and prevent the syslog server to log the checks.

Baptiste

On Tue, Mar 31, 2015 at 11:33 AM, Matt . <yamakasi....@gmail.com> wrote:
> Hi Baptiste,
>
> Yes I've seen it also and never got around large logs.
>
> What do most people do, empty logt very often ?
>
>
>
> 2015-03-31 11:29 GMT+02:00 Baptiste <bed...@gmail.com>:
>> Hi Matt,
>>
>> The issue with LDAP, is that it is not a banner protocol.
>> So either you check the TCP port is well bound on the server for a
>> simple L4 check, for L7, you don't have the choice, you must send a
>> message and check the server's result.
>>
>> Baptiste
>>
>>
>> On Tue, Mar 31, 2015 at 9:53 AM, Matt . <yamakasi....@gmail.com> wrote:
>>> I'm also testing some ldap checks but I see lots of logging and log
>>> partitions filling up like crazy.
>>>
>>> I wonder if it's really doable to check the ldap status in in a gracefull 
>>> way.
>>>
>>> 2015-03-31 9:45 GMT+02:00 Neil - HAProxy List
>>> <maillist-hapr...@iamafreeman.com>:
>>>> Hello
>>>>
>>>> I was thinking of updating the ldap-check but I think I've a better idea.
>>>> Macros (well ish).
>>>>
>>>>   send-binary 300c0201 # LDAP bind request "<ROOT>" simple
>>>>   send-binary 01 # message ID
>>>>   send-binary 6007 # protocol Op
>>>>   send-binary 0201 # bind request
>>>>   send-binary 03 # LDAP v3
>>>>   send-binary 04008000 # name, simple authentication
>>>>   expect binary 0a0100 # bind response + result code: success
>>>>   send-binary 30050201034200 # unbind request
>>>>
>>>> could be in a file named macros/ldap-simple-bind
>>>>
>>>> then the option
>>>>  tcp-check-macro ldap-simple-bind
>>>>
>>>> would use it, I know this is close to includes.
>>>>
>>>> similarly macros/smtp-helo-quit
>>>>          connect port 25
>>>>          expect rstring ^220
>>>>          send QUIT\r\n
>>>>          expect rstring ^221
>>>>
>>>>
>>>> or from
>>>> http://blog.haproxy.com/2014/06/06/binary-health-check-with-haproxy-1-5-php-fpmfastcgi-probe-example/
>>>> # FCGI_BEGIN_REQUEST
>>>>  send-binary   01 # version
>>>>  send-binary   01 # FCGI_BEGIN_REQUEST
>>>>  send-binary 0001 # request id
>>>>  send-binary 0008 # content length
>>>>  send-binary   00 # padding length
>>>>  send-binary   00 #
>>>>  send-binary 0001 # FCGI responder
>>>>  send-binary 0000 # flags
>>>>  send-binary 0000 #
>>>>  send-binary 0000 #
>>>>  # FCGI_PARAMS
>>>>  send-binary   01 # version
>>>>  send-binary   04 # FCGI_PARAMS
>>>>  send-binary 0001 # request id
>>>>  send-binary 0045 # content length
>>>>  send-binary   03 # padding length: padding for content % 8 = 0
>>>>  send-binary   00 #
>>>>  send-binary 0e03524551554553545f4d4554484f44474554 # REQUEST_METHOD = GET
>>>>  send-binary 0b055343524950545f4e414d452f70696e67   # SCRIPT_NAME = /ping
>>>>  send-binary 0f055343524950545f46494c454e414d452f70696e67 # SCRIPT_FILENAME
>>>> = /ping
>>>>  send-binary 040455534552524F4F54 # USER = ROOT
>>>>  send-binary 000000 # padding
>>>>  # FCGI_PARAMS
>>>>  send-binary   01 # version
>>>>  send-binary   04 # FCGI_PARAMS
>>>>  send-binary 0001 # request id
>>>>  send-binary 0000 # content length
>>>>  send-binary   00 # padding length: padding for content % 8 = 0
>>>>  send-binary   00 #
>>>>
>>>>  expect binary 706f6e67 # pong
>>>>
>>>> (though for items like
>>>> send-binary 0e03524551554553545f4d4554484f44474554 # REQUEST_METHOD = GET
>>>> I'd prefer a
>>>> send-as-binary "REQUEST_METHOD = GET"
>>>> )
>>>>
>>>> these and many others could be shipped with haproxy.
>>>>
>>>> this seems to make sense to me as they are small contained logical items
>>>>
>>>> Neil
>>>>
>>>>
>>>> On 30 March 2015 at 23:02, Baptiste <bed...@gmail.com> wrote:
>>>>>
>>>>> you should believe it :)
>>>>>
>>>>> On Mon, Mar 30, 2015 at 11:34 PM, Neil - HAProxy List
>>>>> <maillist-hapr...@iamafreeman.com> wrote:
>>>>> > Hello
>>>>> >
>>>>> > Thanks so much. That worked well, I now get
>>>>> > L7OK/0 in 0ms
>>>>> > not sure I believe the 0ms but maybe I should
>>>>> >
>>>>> > Thanks again,
>>>>> >
>>>>> > Neil
>>>>> >
>>>>> > On 30 March 2015 at 22:14, Baptiste <bed...@gmail.com> wrote:
>>>>> >>
>>>>> >> On Mon, Mar 30, 2015 at 10:33 PM, Neil - HAProxy List
>>>>> >> <maillist-hapr...@iamafreeman.com> wrote:
>>>>> >> > Hello
>>>>> >> >
>>>>> >> > I'm trying to use ldap-check with active directory and the response
>>>>> >> > active
>>>>> >> > directory gives is not one ldap-check is happy to accept
>>>>> >> >
>>>>> >> > when I give a 389 directory backend ldap server all is well, when I
>>>>> >> > use
>>>>> >> > AD I
>>>>> >> > get 'Not LDAPv3 protocol'
>>>>> >> >
>>>>> >> > I've done a little poking about and found that
>>>>> >> >                         if ((msglen > 2) ||
>>>>> >> >                             (memcmp(check->bi->data + 2 + msglen,
>>>>> >> > "\x02\x01\x01\x61", 4) != 0)) {
>>>>> >> >                                 set_server_check_status(check,
>>>>> >> > HCHK_STATUS_L7RSP, "Not LDAPv3 protocol");
>>>>> >> > is where I'm getting stopped as msglen is 4
>>>>> >> >
>>>>> >> > Here is tcpdump of 389 directory response (the one that works) 2
>>>>> >> > packets
>>>>> >> > 21:29:34.195699 IP 389.ldap > HAPROXY.57109: Flags [.], ack 15, win
>>>>> >> > 905,
>>>>> >> > options [nop,nop,TS val 856711882 ecr 20393440], length 0
>>>>> >> >     0x0000:  0050 5688 7042 0064 403b 2700 0800 4500
>>>>> >> > .PV.pB.d@;'...E.
>>>>> >> >     0x0010:  0034 9d07 4000 3f06 3523 ac1b e955 ac18
>>>>> >> > .4..@.?.5#...U..
>>>>> >> >     0x0020:  2810 0185 df15 5cab ffcd 63ba 77d3 8010
>>>>> >> > (.....\...c.w...
>>>>> >> >     0x0030:  0389 2c07 0000 0101 080a 3310 62ca 0137
>>>>> >> > ..,.......3.b..7
>>>>> >> >     0x0040:  2de0                                     -.
>>>>> >> > 21:29:34.195958 IP 389.ldap > HAPROXY.57109: Flags [P.], seq 1:15,
>>>>> >> > ack
>>>>> >> > 15,
>>>>> >> > win 905, options [nop,nop,TS val 856711882 ecr 20393440], length 14
>>>>> >> >     0x0000:  0050 5688 7042 0064 403b 2700 0800 4500
>>>>> >> > .PV.pB.d@;'...E.
>>>>> >> >     0x0010:  0042 9d08 4000 3f06 3514 ac1b e955 ac18
>>>>> >> > .B..@.?.5....U..
>>>>> >> >     0x0020:  2810 0185 df15 5cab ffcd 63ba 77d3 8018
>>>>> >> > (.....\...c.w...
>>>>> >> >     0x0030:  0389 e878 0000 0101 080a 3310 62ca 0137
>>>>> >> > ...x......3.b..7
>>>>> >> >     0x0040:  2de0 300c 0201 0161 070a 0100 0400 0400
>>>>> >> > -.0....a........
>>>>> >> >
>>>>> >> > Here is tcpdump of active directory (broken) 1 packet
>>>>> >> >
>>>>> >> > 21:25:24.519883 IP ADSERVER.ldap > HAPROXY.57789: Flags [P.], seq
>>>>> >> > 1:23,
>>>>> >> > ack
>>>>> >> > 15, win 260, options [nop,nop,TS val 1870785 ecr 20331021], length 22
>>>>> >> >     0x0000:  0050 5688 7042 0050 5688 7780 0800 4500
>>>>> >> > .PV.pB.PV.w...E.
>>>>> >> >     0x0010:  004a 1d7d 4000 8006 34e3 ac18 280d ac18
>>>>> >> > .J.}@...4...(...
>>>>> >> >     0x0020:  2810 0185 e1bd 5a3f 2ae7 3ced 7b5b 8018
>>>>> >> > (.....Z?*.<.{[..
>>>>> >> >     0x0030:  0104 1d7a 0000 0101 080a 001c 8bc1 0136
>>>>> >> > ...z...........6
>>>>> >> >     0x0040:  3a0d 3084 0000 0010 0201 0161 8400 0000
>>>>> >> > :.0........a....
>>>>> >> >     0x0050:  070a 0100 0400 0400
>>>>> >> >
>>>>> >> > this was discussed but not finished before see
>>>>> >> > http://www.serverphorums.com/read.php?10,394453
>>>>> >> >
>>>>> >> > I can see the string \02\01\01\61 is there but not in the correct
>>>>> >> > place
>>>>> >> >
>>>>> >> > Anyone have any ideas about fixing this so that both (and possibly
>>>>> >> > other)
>>>>> >> > ldap implementations work?
>>>>> >> >
>>>>> >> > Thanks,
>>>>> >> >
>>>>> >> > Neil
>>>>> >>
>>>>> >>
>>>>> >> Hi Neil
>>>>> >>
>>>>> >> Yes you can switch to the tcp-check checking method.
>>>>> >> I works with binary protocols as well.
>>>>> >> Here is what I use for the AD in my lab:
>>>>> >>
>>>>> >>  option tcp-check
>>>>> >>  tcp-check connect port 389
>>>>> >>  tcp-check send-binary 300c0201 # LDAP bind request "<ROOT>" simple
>>>>> >>  tcp-check send-binary 01 # message ID
>>>>> >>  tcp-check send-binary 6007 # protocol Op
>>>>> >>  tcp-check send-binary 0201 # bind request
>>>>> >>  tcp-check send-binary 03 # LDAP v3
>>>>> >>  tcp-check send-binary 04008000 # name, simple authentication
>>>>> >>  tcp-check expect binary 0a0100 # bind response + result code: success
>>>>> >>  tcp-check send-binary 30050201034200 # unbind request
>>>>> >>
>>>>> >>
>>>>> >> You could add the same sequence for LDAPs on port 636:
>>>>> >>  tcp-check connect port 636 ssl
>>>>> >>  tcp-check send-binary 300c0201 # LDAP bind request "<ROOT>" simple
>>>>> >>  tcp-check send-binary 01 # message ID
>>>>> >>  tcp-check send-binary 6007 # protocol Op
>>>>> >>  tcp-check send-binary 0201 # bind request
>>>>> >>  tcp-check send-binary 03 # LDAP v3
>>>>> >>  tcp-check send-binary 04008000 # name, simple authentication
>>>>> >>  tcp-check expect binary 0a0100 # bind response + result code: success
>>>>> >>  tcp-check send-binary 30050201034200 # unbind request
>>>>> >>
>>>>> >>
>>>>> >> Note for myself: put this tip on the blog..
>>>>> >>
>>>>> >> Baptiste
>>>>> >
>>>>> >

Reply via email to