Haproxy : anti DDOS

HAPROXY est, entre autres choses, un load-balancer très souple qui peut apporter en outre un gain en sécurité par une gestion spécifique des connexions. Il "protège" les serveurs Web en limitant le nombre des connexions simultanées afin d'empêcher la saturation du serveur. De nombreux tests montrent que si Haproxy est bien réglé on peut garder un accès (pas exemple ssh) sur un serveur surchargé de demandes d'accès HTTP (qui a dit malicieuses ?), cela semble notamment efficace contre les attaques de style «Killer2 / Slowloris» voir les sites : Securityvibes et Phrack  à ce sujet. 
Tous les exemples fournis dans cet article sont fondés sur le protocole HTTP, mais Haproxy permet aussi de gérer d'autres protocoles, en fait pratiquement tous les protocoles TCP. 
Son empreinte mémoire et sa consommation CPU réduite ne chargent que peu les serveurs, c'est donc un investissement d'un très bon rapport qualité/coût.

•     nombre de requêtes, d'octets «in», d'octets «out» par «frontend»
•     nombre de requêtes, d'octets «in», d'octets «out» par «backend»

Le paramétrage relativement simple et compréhensible, est divisé en «blocs» délimités par des mots clefs:

•     global
•     defaults
•     frontend nom_du_frontend
•     backend nom_du_backend
•     listen nom_du_listen

Section «global». 
Ici sont définis principalement les paramètres communs à tous les «frontend» et «backend». 
log, nombre total de connexions gérées : 
log 127.0.0.1 local0 
maxconn 512 
Lancement en «démon» (arrière plan) cette option est obligatoire pour que le processus se «détache» de la console, l'utilisateur et le groupe sous lequel le programme doit tourner, l'option «chroot» qui permet de mieux protéger le système en isolant le processus dans une cage : 
chroot nom_du_répertoire_cage 
user haproxy 
group haproxy 
daemon 
L'option "chroot" est fortement conseillée, le répertoire indiqué peut être «vide» puisque, une fois lancé le processus ne gère que des accès réseau. 
On peut par ailleurs utiliser les options «debug» ou «quiet» pour augmenter ou diminuer le niveau de log. 
Section «defaults». 
Ici sont définis divers paramètres permettant de limiter la durée des connexions afin de protéger le serveur et les services WEB. Sont définis aussi les protocoles suivis (pas uniquement du http). En utilisant «http» il est possible d'utiliser des outils d'analyse des requêtes, par exemple pour rediriger des domaines différents sur des serveurs (ou ports) différents et «éliminer» les demandes de sites non gérés. 
Voici un exemple des valeurs adoptées : 
timeout client 15s 
timeout server 15s 
timeout queue 15s 
timeout connect 8s 
timeout http-request 8s 
Ces valeurs, bien sûr, sont à adapter selon les services demandés et une option spécifique http: 
option forwardfor 
Section «frontend». 
C'est ici que l'on peut «repérer» les motifs qui nous intéressent dans les flux HTTP, par exemple le nom du site demandé pour effectuer les bonnes redirections. 
Choisir adresse/port : 
bind 0.0.0.0:80 
La distribution vers différents «backend» s'effectue avec l'aide de directives «ACL», exemple: 
acl PRA hdr_beg(host) siteA 
acl PRB hdr_beg(host) siteB 
il existe un très grand nombre de fonctions de détection, celle utilisée ici (hdr_beg) teste le début du nom de site. Il suffit ensuite de diriger la requête en fonction de l'acl vers le bon «backend» par une directive telle que celle ci dessous : 
use_backend BACKA if PRA 
use_backend BACKB if PRB 
et prévoir une sortie spécifique aux requêtes non sélectionnées : 
default_backend POUBEL 
dans lequel sont traitées les demandes «résiduelles». 
Il est parfaitement possible de créer plusieurs «Frontend» écoutant sur plusieurs couples adresse/port différents. Il est ainsi possible de différencier des accès à la même application par le couple adresse/port pour, par exemple, avoir des statistiques différenciées pour chaque partie de l'application en utilisant un couple adresse/port différent pour les accès «administratifs». Les statistiques du site ne seront ainsi pas «polluées» par des accès liés à l'administration et l'on pourra aussi avoir des statistiques sur les accès administratifs. On peut faire de même pour des accès intranet/extranet afin de disposer de statistiques plus précises. 
Section «backend». 
C'est ici qu'est fait le lien vers le service sélectionné, celui-ci peut alors être envoyé sur un ou des serveurs spécifiques avec une fonction de répartition de charge : 
option httpchk 
balance roundrobin 
cookie SERVERID rewrite 
server local 127.0.0.1:84 maxconn 127 
option httpclose 
option abortonclose 
retries 2 
La directive «server» peut être répétée pour décrire les différents serveurs entre lesquels doivent être réparties les requêtes exemple: 
server srv1 192.168.1.201:81 cookie srv1 weight 2 check 
server srv2 192.168.1.201:81 cookie srv2 weight 1 check 
Ce groupe de directives permet de répartir sur srv1 et srv2 en considérant que srv1 doit recevoir deux fois plus de requêtes que srv2.

Ce logiciel est facile à employer et bourré de fonctionnalités intéressantes. 
Un petit exemple des statistiques disponibles :