idealhavoc

In our maps blog post we have a section where we talk about applying different rate limits for different paths (https://www.haproxy.com/blog/introduction-to-haproxy-maps/#r...). For this I'd change the path fetch to a req.hdr(authorization) (or however you send API keys) to limit per API key. You could also add a 20/second with another stick table using the methods in this DDoS post (just with a string key to store API key rather than ip/src to store the IP address).

You can put HAProxy directly on a box running another service to provide protection/reporting if you don't want to replace or add HAProxy to your ELB's (though sometimes that just adds too much complexity), we also talk about using HAProxy and ELB in our AWS blog post (https://www.haproxy.com/blog/haproxy-amazon-aws-best-practic...).

For the first example that looks good to catch scanners and the like, though it needs an "http-response track-sc0 src" or nothing will get stored in the stick table. The second example it looks good; since there aren't any regexes in there the ip/substring/end lookups are quite CPU friendly so shouldn't have a large impact even at higher request rates (IP ACL files notably get loaded into a binary tree format and take next to no CPU work to check for a match even with millions of IP's).

Its not terribly common to attack the SMTP service itself, as usually spam can be sent to cause problems outside of the availability of the SMTP service itself. If SMTP traffic is put through HAProxy conn_cur and conn_rate trackers can be used to limit connections per source IP. "inspect delay" can be used to cause SMTP connections to be held in HAProxy for a while, which makes mail flooding substantially more difficult as well (there is an example of that in the docs if you search for inspect-delay).

For volumetric attacks (where the attacker is using DNS reflection or similar to do nothing but eat your bandwidth) pretty much the only solution is to work with providers to block the sources/protocols to stop the majority of the traffic before it hits the fiber into the proxy servers. For SYN floods (where spoofed SYN packets are used to fill up the proxies connection table) the kernels SYN cookie functions can be used to ignore invalid SYN's, or if that isn't enough something like our ALOHA's PacketSheld to prevent the reflected/spoofed traffic from reaching the proxy at all (but still useless if the 10gb line is completely full). HAProxy comes into account more if they are actually establishing a TCP connection even if they don't actually make a request, as then conn_rate/conn_cur trackers can be used to refuse/drop the connections (and with silent drop fill up their connection tables and make it harder for them to make more). If they actually make a full HTTP request, then the http_req_rate comes into play to 403 the requests (and can be combined with connection rate limiting to reduce the amount of traffic in HTTP requests they send).

I'm the author of this, and have done quite a bit with DDoS and HAProxy; feel free to ask me any questions.

Your right, I frequently look as inspect-delay as not being a real line given that it doesn't do much itself. I have an explanation of inspect-delay a bit further down: When tcp-request inspect-delay is present, it will hold the request until the rules in that block have the data they need to make a decision or until the specified delay is reached, whichever is first.

Basically if an ACL requires an http request (such as updating the http_req_rate counter) but the action is tcp-request it tells HAProxy to wait until it has a http request before it continues. If using an http-request track-* action its not required as HAProxy won't process http-request until it has an HTTP request to add to the counters.

Since HAProxy won't send a request to a backend in HTTP mode until it has a full request inspect-delay doesn't actually delay the request at all; just the processing phase for a bit (in TCP mode where it doesn't it gets a bit more complicated).

Hey, author of this blog post here. If you have any questions feel free to ask (or if you want to insult me that is also acceptable).

The government worries me more than people/companies for two reasons:

1) The government can track me everywhere with cameras anywhere they want in public; companies would be mostly restricted to when I walk past their franchises in most cases (drones could be an issue, but cross that bridge when we get to it)

2) The government agencies have motivation and a history of suppressing new or bothersome political parties which challenge their budgets. Ether by spreading dirt gathered via other activities or jailing activists such things are at least substantially harder for a company to accomplish.

The main benefit I get out of it is that without it I would never cook anything because I wouldn't be able to get the motivation over the long term (I've tried, and it works for a short time, but fades).

So basically it gives me reasonable portions that I can cart to work, gets me to cook by force-feeding me recipes (which seems to reliably motivate me, and they taste good enough when done), and at least seem more healthy (and at $9 a serving substantially cheaper than) a restaurant.

Not saying that the same thing would work for anyone other than me, but has worked out better than the prior "stuffing whatever food I can reach into mouth" method.

To do it properly you would likely be looking at mandatory access control, such as SELinux, so that the ransomware wouldn't be authorized to modify the files and further would make itself obvious in the logs. Not very easy to use (in a way that still provides meaningful security) outside of the server space, though it can be done.