2017-07-29 16:57 GMT+02:00 Charlie Elgholm <char...@brightly.se>: > Ok, but anyhow, this actually means that I can use http-response to do > something on the response. That's good. I'll play with it for a while on my > dev-server. Nice! > > Version can be upgraded, of course, if I can just motivate it! :) > > Den 29 juli 2017 12:44 em skrev "Igor Cicimov" > <ig...@encompasscorporation.com>: >> >> >> >> On Fri, Jul 28, 2017 at 10:00 PM, Charlie Elgholm <char...@brightly.se> >> wrote: >>> >>> Ok, I'm on the 1.5.x bransch unfortunately, due to Oracle Linux issues. >>> Can install manually, but that might raise some eyebrows. >>> >>> But what you're telling me is that I can route the request to another >>> backend (or drop it) in haproxy based on something I received from one >>> backend?? >>> >>> Den 28 juli 2017 1:40 em skrev "Igor Cicimov" >>> <ig...@encompasscorporation.com>: >>> >>> >>> >>> On Fri, Jul 28, 2017 at 6:03 PM, Charlie Elgholm <char...@brightly.se> >>> wrote: >>>> >>>> Thanks! >>>> >>>> I was really hoping for acl-validation on the basis of the response from >>>> the backend server, and not on the incoming request at the frontend. >>>> And, as much as I really like lua as a language, I'd rather keep my >>>> haproxy with as small footprint as possible. =) >>>> >>>> Really nice example about all the possibilities though, thanks! >>>> >>>> This is how all examples I find operate: >>>> incoming request => haproxy => frontend => acl based on what's known >>>> about the incoming requests => A or B >>>> A: backend => stream backend response to client >>>> B: tarpit / reject >>>> >>>> I would like this: >>>> incoming request => haproxy => frontend => backend => acl based on >>>> what's known about the response from the backend => A or B >>>> A: stream backend response to client >>>> B: tarpit / reject >>>> >>>> >>>> 2017-07-28 9:52 GMT+02:00 Igor Cicimov <ig...@encompasscorporation.com>: >>>>> >>>>> >>>>> >>>>> On 28 Jul 2017 5:41 pm, "Charlie Elgholm" <char...@brightly.se> wrote: >>>>> >>>>> Hi Folks, >>>>> >>>>> Either I'm too stupid, or it's because it's Friday.... >>>>> >>>>> Can you tarpit/reject (or other action) based on a response from the >>>>> backend? >>>>> You should be able to, right? >>>>> >>>>> Like this: >>>>> tcp-response content tarpit/reject if res.hdr(X-Tarpit-This) >>>>> >>>>> Can someone explain this to me? (Free beer.) >>>>> >>>>> I have a fairly complex ruleset on my backend server, written in Oracle >>>>> PL/SQL, which monitors Hack- or DoS-attempts, and I would love to tarpit >>>>> some requests on the frontend (by haproxy) based on something that happens >>>>> on my backend. >>>>> >>>>> As I do now I return a 503 response from the server, and iptable-block >>>>> those addresses for a while. But since they see the 503 response they'll >>>>> return at a later date and try again. I would like the connection to just >>>>> die (drop, no response at all) or tarpit (long timeout, so they give up). >>>>> I >>>>> suppose/hope they'll eventually remove my IP from their databases. >>>>> >>>>> I'm guessing a tarpit is smarter than a reject, since the reject will >>>>> indicate to the attacker that somethings exist behind the server IP. >>>>> An iptable "drop" would be preferable, but I guess that's a little late >>>>> since haproxy has already acknowledged the connection to the attacker. >>>>> >>>>> -- >>>>> Regards >>>>> Charlie Elgholm >>>>> Brightly AB >>>>> >>>>> Good example of delay with lua: >>>>> http://godevops.net/2015/06/24/adding-random-delay-specific-http-requests-haproxy-lua/ >>>> >>>> >>>> >>>> >>>> -- >>>> Regards >>>> Charlie Elgholm >>>> Brightly AB >>> >>> >>> Well the idea is to redirect the response on the backend (based on some >>> condition) to a local frontend where you can use the tarpit on the request. >>> >>> You cam also try: >>> >>> http-response silent-drop if { status 503 } >>> >>> that you can use in the backed (at least in 1.7.8, not sure for other >>> versions) >>> >>> >>> >> >> I was thinking of something along these lines: >> >> frontend ft_tarpit >> mode http >> bind 127.0.0.1:4444 >> default_backend bk_tarpit >> >> backend bk_tarpit >> mode http >> timeout tarpit 3600s >> http-request tarpit >> >> backend bk_main >> mode http >> http-response redirect 127.0.0.1:4444 if { status 503 } >> >> but you are out of luck again since "http-response redirect" was >> introduced in 1.6 >> >
Hi Charlie, many ideas come to my mind to solve your requirement, but all of these require HAProxy 1.6 (or better: HAProxy 1.7) Some keywords: "http-response silent-drop" "http-response track-sc" + checking stick-table entry with acl in frontend "http-response" + (random) delay with lua (my preferred solution) ------------------- Best Regards Bjoern
