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" <igorc@encompasscorporation. > com>: > > > > 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
