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" < [email protected]>: > > > On Fri, Jul 28, 2017 at 10:00 PM, Charlie Elgholm <[email protected]> > 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" < >> [email protected]>: >> >> >> >> On Fri, Jul 28, 2017 at 6:03 PM, Charlie Elgholm <[email protected]> >> 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 <[email protected]>: >>> >>>> >>>> >>>> On 28 Jul 2017 5:41 pm, "Charlie Elgholm" <[email protected]> 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 > >
