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 :
