19
0
Fork 0

Ajout d'une section sur la protection d'attaques

This commit is contained in:
Tristan PILAT 2020-12-09 14:49:16 +01:00
parent e38cbea201
commit 4a8d8bd38f
1 changed files with 38 additions and 0 deletions

View File

@ -312,6 +312,44 @@ CREATE USER haproxy_check@IP_OF_HAPROXY;
#### Mode avancé
### Protection d'attaques
HAProxy peut prendre des mesures face à des attaques de type [HTTP flood](https://en.wikipedia.org/wiki/HTTP_Flood). Pour cela, il utilise un mécanisme qui permet de suivre l'activité des visiteurs en stockant en mémoire le nombres de requêtes par client. Cela est possible grâce à l'utilisation des « [stick tables](https://www.haproxy.com/blog/introduction-to-haproxy-stick-tables/) ». Les « [stick tables](https://www.haproxy.com/blog/introduction-to-haproxy-stick-tables/) » fournissent un stockage clé-valeur pouvant être utilisé pour suivre divers compteurs associés à chaque client. Ces compteurs peuvent se baser sur tout ce qui se trouve dans la requête (adresse IP, UserAgent, URL, token…). Les valeurs comptabilisées sont le nombre de requêtes ainsi que le taux sur une période donnée.
La première chose à faire est de définir une directive `stick-table` dans un `backend` ou un `frontend`. Il faut avoir à l'esprit que chaque backend/frontend ne peut contenir qu'une directive `stick-table`. On peut voir cela comme une vraie limitation, si l'on veut par exemple pouvoir suivre le nombre de requêtes par IP ainsi que que le nombre de requêtes par IP pour chaque URL. On peut vouloir également utiliser ces compteurs dans plusieurs backend/frontend simultanément. La bonne nouvelle est qu'il est possible de définir des frontend/backend dont la seule utilité est de contenir une directive `stick-table`. Il est alors possible ensuite d'utiliser ce compteur ailleurs via une directive `http-request` y faisant référence.
Dans l'exemple suivant, on définit deux backends. Le premier sert à enregistrer le nombre de requête par IP « per_ip_rates ». Le second sert à suivre le nombre requête par IP pour chaque URL « per_ip_and_url_rates » :
~~~
backend per_ip_rates
stick-table type ip size 1m expire 10m store http_req_rate(10s)
backend per_ip_and_url_rates
stick-table type binary len 8 size 1m expire 1h store http_req_rate(10s)
~~~
Pour les détails, dans le backend « per_ip_rates » on définit une directive `stick-table` de type IP qui peut contenir jusqu'à 1 million d'entrées, qui expire au bout de 10 minutes et qui comptabilise le nombre de requêtes sur les 10 dernières secondes.
Dans le second backend « per_ip_and_url_rates », on définit une directive `stick-table` de type binary (longueur de 8 bits), qui peut contenir jusqu'à 1 million d'entrées, qui expire au bout d'une heure et qui comptabilise le nombre de requêtes IP/URL sur les 10 dernières secondes.
On peut ensuite utiliser ces deux compteurs dans les frontends/backend de notre choix en y faisant référence dans une directive `http-request` via la paramètre `table`.
Dans l'exemple suivant, on crée deux blocs de 2 directives `http-request`.
~~~
frontend default
[…]
http-request track-sc0 src table per_ip_rates unless { path_end .css .js .png .jpeg .gif }
http-request deny deny_status 429 if { sc_http_req_rate(0) gt 100 }
http-request track-sc1 url32+src table per_ip_and_url_rates unless { path_end .css .js .png .jpeg .gif }
http-request deny deny_status 429 if { sc_http_req_rate(1) gt 10 }
[…]
~~~
Le premier bloc contient deux lignes dont la première définit une règle « track-sc0 » qui se basant sur la table du backend « per_ip_rates » en omettant toutes les requêtes vers certains type de fichiers (CSS, JS…). La seconde ligne indique ensuite de renvoyer un status 429 si le nombre des requêtes HTTP/sec pour une même IP selon les données provenant de « track-sc0 » est supérieur à 100 (donc 100 requêtes depuis une même IP sur les 10 dernières seconndes).
Le second bloc contient quant à lui deux lignes dont la première définit une règle « track-sc1 » qui se base sur la table du backend « per_ip_and_url_rates » en omettant toute les requêtes vers certains types de fichiers (CSS, JS…). La seconde ligne indique ensuite de renvoyer un status 429 si le nombre des requêtes HTTP/sec vers une URL unique depuis une même IP selon les données provenant de « track-sc1 » est supérieur à 10 (donc 10 requêtes depuis une même IP et vers la même URL sur les 10 dernières secondes).
## Check HTTP
Cela consiste à utiliser un check http pour déterminer l'état du serveur.