
Application-Layer DDoS Attack Protection with HAProxy - phil21
https://www.haproxy.com/blog/application-layer-ddos-attack-protection-with-haproxy/
======
idealhavoc
I'm the author of this, and have done quite a bit with DDoS and HAProxy; feel
free to ask me any questions.

~~~
lukeqsee
So correct me if I'm wrong, this solution is great if you're the target of a
DDoS targeted on overloading your backend services via many malicious
requests. However, if you are the target of a bandwidth consumption attack,
there isn't much HAProxy can do, correct?

There's still the fundamental limitations of incoming bandwidth, system pps
limits, etc., etc.

~~~
idealhavoc
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).

------
PM_ME_YOUR_CAT
Any info on what the other topics will be in this series or is that kept as a
surprise?

~~~
rogerdonut
Soon we'll release a post about bot detection and protection with HAProxy. If
you'd like to see us cover a specific topic feel free to reply to me here and
I'll pass it onto the team.

------
andrewkro
Is peering the same as the stick table aggregator?

~~~
rogerdonut
No, the peers protocol only syncs the stick-table data between other haproxy
instances, but doesn't aggregate the values. The stick table aggregator
aggregates all of the values from all of your haproxy instances.

Assume that you have 2 haproxy instances and a client makes 2 requests and
each request lands on a separate haproxy instance. With peers, the request
count would sync as "1" but with the stick table aggregator the request count
would sync as "2".

~~~
wtarreau
By the way, when you have very few devices to aggregate values from (let's say
only 2 haproxy nodes), there's a trick you can use to still aggregate their
values over peers, assuming you are willing to maintain different
configurations on each node.

The principle is that there will be one table per metric and per node, and
each node will track values using its own table. This way each table is
written to by only one node, and all nodes get all the table updates. They are
then free to watch other nodes' values in their respective tables.

Using the arithmetic converters it's even possible to add or average values
between all tables, but then this quickly becomes complicated, as for example
you can't easily take into account the number of online nodes in your
operations. This is why this is mostly workable with two nodes and not really
much more. In this case of two nodes, you either use your own value or the
average operation if you can ping the neighbor.

