Re: tcp-request content track-sc2 with if statement doesn't work?
On Sat, Sep 6, 2014 at 9:16 PM, PiBa-NL piba.nl@gmail.com wrote: Hi list, Inspired by a blog about wordpress bruteforce protection [0] , i'm trying to use this same kind of method in a frontend/backend configuration. I did change the method from POST to GET, for easier testing, but that doesn't matter for retrieving the gpc counter, does it? So i was trying to use this: tcp-request content track-sc1 base32+src if METH_GET login It however doesn't seem to work using HAProxy 1.5.3, the acl containing sc1_get_gpc0 gt 0 never seems to get the correct gpc0 value, even though i have examined the stick-table and the gpc0 value there is increasing. If i change it to the following it starts working: tcp-request content track-sc1 base32+src Even though the use_backend in both cases checks those first criteria: acl flagged_as_abusersc1_get_gpc0 gt 0 use_backendpb3_453_http if METH_GET wp_login flagged_as_abuser Am i doing something wrong, is the blog outdated, or was a bug introduced somewhere? If more information perhaps -vv or full config is needed let me know, thanks for any reply. p.s. did anyone get my other emails a while back? [1] Kind regards, PiBa-NL [0] http://blog.haproxy.com/2013/04/26/wordpress-cms-brute-force-protection-with-haproxy/ [1] http://marc.info/?l=haproxym=140821298806125w=2 Hi, Plese let us know if you have the following configuration lines (or equivalent), before your tracking rule: tcp-request inspect-delay 10s tcp-request accept if HTTP Baptiste
Re: Spam to this list?
On Sat, Sep 06, 2014 at 01:09:57AM +0200, Willy Tarreau wrote: FWIW, I've noticed that there is actually *more* spam than what I do receive, simply because my trivial procmail filters catch about half of it. I'll see if I find a way to port them to postfix in order to reduce this amount for everyone to the level I'm seeing on my side. With Benoit's help, we have converted most of these filters and applied them to the list. They don't generate false positives on my side so they should be safe. Also, please let me post a few numbers. On Friday, the server rejected 5495 emails at the connection level, 206 based on a few correctness rules, and only delivered 83 to the mailing list, 37 of which were valid, and 10 of which were valid but caused by someone who intentionally wants to harm the list, which leaves 36 spam out of 5737, which is 0.63%. I had to delete about 10-20 of them by hand from my box, I don't remember, which indicates that the extra filters could catch about half of the remaining ones on average, without false positives. Personally, I consider that if we kill 99.5% of spam and only let 0.5% leak through for the sake of not getting any false positives, it's already reasonably good for an open mailing list. I know that some people won't share this point of view, but that suits my goals for this list. Regards, Willy
Re: tcp-request content track-sc2 with if statement doesn't work?
On Sun, Sep 7, 2014 at 2:55 PM, PiBa-NL piba.nl@gmail.com wrote: Hi Baptiste, Thanks that fixes my issue indeed with the following: tcp-request inspect-delay 10s tcp-request content track-sc1 base32+src if METH_GET wp_login tcp-request content accept if HTTP I didn't think about inspect-delay because both frontend and backend are using 'mode http', and i only used to use inspect-delay with frontends using tcp mode. Though maybe the 'tcp-request' should have given my that hint. The 'accept' must be below the 'track-sc1' to make it work. Could you perhaps also add this to the blog article, or should i post a comment under it for other people to not fall into the same mistake? Thanks, PiBa-NL Baptiste schreef op 7-9-2014 11:38: On Sat, Sep 6, 2014 at 9:16 PM, PiBa-NL piba.nl@gmail.com wrote: Hi list, Inspired by a blog about wordpress bruteforce protection [0] , i'm trying to use this same kind of method in a frontend/backend configuration. I did change the method from POST to GET, for easier testing, but that doesn't matter for retrieving the gpc counter, does it? So i was trying to use this: tcp-request content track-sc1 base32+src if METH_GET login It however doesn't seem to work using HAProxy 1.5.3, the acl containing sc1_get_gpc0 gt 0 never seems to get the correct gpc0 value, even though i have examined the stick-table and the gpc0 value there is increasing. If i change it to the following it starts working: tcp-request content track-sc1 base32+src Even though the use_backend in both cases checks those first criteria: acl flagged_as_abusersc1_get_gpc0 gt 0 use_backendpb3_453_http if METH_GET wp_login flagged_as_abuser Am i doing something wrong, is the blog outdated, or was a bug introduced somewhere? If more information perhaps -vv or full config is needed let me know, thanks for any reply. p.s. did anyone get my other emails a while back? [1] Kind regards, PiBa-NL [0] http://blog.haproxy.com/2013/04/26/wordpress-cms-brute-force-protection-with-haproxy/ [1] http://marc.info/?l=haproxym=140821298806125w=2 Hi, Plese let us know if you have the following configuration lines (or equivalent), before your tracking rule: tcp-request inspect-delay 10s tcp-request accept if HTTP Baptiste Hi, Article updated. Baptiste
Re: tcp-request content track-sc2 with if statement doesn't work?
Baptiste schreef op 7-9-2014 17:13: On Sun, Sep 7, 2014 at 2:55 PM, PiBa-NL piba.nl@gmail.com wrote: Hi Baptiste, Thanks that fixes my issue indeed with the following: tcp-request inspect-delay 10s tcp-request content track-sc1 base32+src if METH_GET wp_login tcp-request content accept if HTTP I didn't think about inspect-delay because both frontend and backend are using 'mode http', and i only used to use inspect-delay with frontends using tcp mode. Though maybe the 'tcp-request' should have given my that hint. The 'accept' must be below the 'track-sc1' to make it work. Could you perhaps also add this to the blog article, or should i post a comment under it for other people to not fall into the same mistake? Thanks, PiBa-NL Baptiste schreef op 7-9-2014 11:38: On Sat, Sep 6, 2014 at 9:16 PM, PiBa-NL piba.nl@gmail.com wrote: Hi list, Inspired by a blog about wordpress bruteforce protection [0] , i'm trying to use this same kind of method in a frontend/backend configuration. I did change the method from POST to GET, for easier testing, but that doesn't matter for retrieving the gpc counter, does it? So i was trying to use this: tcp-request content track-sc1 base32+src if METH_GET login It however doesn't seem to work using HAProxy 1.5.3, the acl containing sc1_get_gpc0 gt 0 never seems to get the correct gpc0 value, even though i have examined the stick-table and the gpc0 value there is increasing. If i change it to the following it starts working: tcp-request content track-sc1 base32+src Even though the use_backend in both cases checks those first criteria: acl flagged_as_abusersc1_get_gpc0 gt 0 use_backendpb3_453_http if METH_GET wp_login flagged_as_abuser Am i doing something wrong, is the blog outdated, or was a bug introduced somewhere? If more information perhaps -vv or full config is needed let me know, thanks for any reply. p.s. did anyone get my other emails a while back? [1] Kind regards, PiBa-NL [0] http://blog.haproxy.com/2013/04/26/wordpress-cms-brute-force-protection-with-haproxy/ [1] http://marc.info/?l=haproxym=140821298806125w=2 Hi, Plese let us know if you have the following configuration lines (or equivalent), before your tracking rule: tcp-request inspect-delay 10s tcp-request accept if HTTP Baptiste Hi, Article updated. Baptiste Hi Baptiste, Thanks, however there are now 2 issues with that. - The 'accept' must be below the 'track-sc1' to make it work. (at least in my tests..) - Syntax error missing 'content' keyword in: tcp-request content accept if HTTP In the backend i didn't seem to need the inspect-delay, probably because the frontend has already filled buffers because it is in 'http' mode. Thanks, PiBa-NL
Re: http-send-name-header buffer corruption (1.4.25)
Hi all, Le 06/09/2014 08:28, Willy Tarreau a écrit : To be honnest, I think it is necessary, and I hope it will be enough. We had this issue in 1.5-dev as well a long time ago and the problem was the same, the beginning of the message was not moved. Now 1.5's buffer semantics have changed to make all this much simpler. There is one thing to test to confirm it's enough : make a farm with two untested servers, one which does not respond and a valid one so that there's a retry and redispatch. Haproxy will first pick server1, prepend the header, and try to send the request there. After the failure it will redispatch to server2 and rewind the buffer to change the header. On server2 you should see a valid request if the fix is OK. That's how I managed to fix it in 1.5-dev. The config below should be enough to reproduce it : listen test :10002 balance roundrobin mode http option http-server-close http-send-name-header Host retries 1 option redispatch server bad 127.0.0.1:12345 server good 127.0.0.1:80 I also remember that rewinding POST requests is harder than rewinding GET because the body was already partially parsed. I remember something in 1.4 which we did to take care of that, either we refrain from parsing the body before connecting when there's the send-name-header, or we could correctly rewind. So sending a POST request through the config above will tell you if that's OK :-) I was optimistic during my tests unless I tried sending POST requests with a body longer than the buffer size. In certain conditions, haproxy segfaults. For example, this is the case with the bad server, no need to redispatch. I need some time to remember how buffers work in 1.4, in order to fix the segfault. -- Cyril Bonté
unsubscribe
Sebastien Estienne
