Qu'est ce qu'HAProxy ?
HAProxy, ou High Availability Proxy, est un logiciel gratuit et open source utilisé comme équilibreur de charge et serveur proxy pour les applications basées sur TCP et HTTP. Il peut fournir des performances supérieures par rapport à d’autres logiciels tels que NGINX et Stingray tout en étant une solution plus simple à gérer. HAProxy est écrit en C, fonctionne sous Linux et FreeBSD et prend en charge jusqu’à 10 000 connexions simultanées avec un minimum de ressources.
HAProxy est sorti pour la première fois en décembre 2001, avant de devenir open source en 2005. En 2013, il est officiellement devenu le logiciel le plus utilisé des trois principaux répartiteurs de charge open source. En février 2018, HAProxy était la norme de facto pour les déploiements cloud OpenStack.
Il a la réputation d’être rapide et efficace (en termes d’utilisation du processeur et de la mémoire). Il prend en charge la possibilité de configurer n’importe quoi, d’un serveur unique à de grands clusters avec des milliers de nœuds. Il a été utilisé par des entreprises telles que : GitHub, Twitter, eBay ou encore Wikimédia.
Quelles sont les différentes fonctionnalités HAProxy ?
- La répartition de charge : HAProxy peut distribuer les requêtes entrantes à différents serveurs Web en fonction de vos critères choisis, comme le round robin, les sessions persistantes, les temps de réponse ou le plus petit nombre de connexions ouvertes. C’est ce qu’on appelle « la répartition de charge ».
- L’état de santé des serveurs : HAProxy peut être configuré pour surveiller la santé de vos serveurs en envoyant des pings réguliers. Si un serveur renvoie un code 200 ou 300, cela indique que le serveur ne fonctionne pas correctement et HAProxy arrêtera d’acheminer le trafic vers celui-ci jusqu’à ce qu’il soit de nouveau opérationnel. C’est ce qu’on appelle la “vérification de l’état de santé”.
- La haute disponibilité : en cas de panne, le service peut automatiquement basculer d’un serveur à l’autre sans aucun temps d’arrêt.
- Compression HTTP : HAProxy compresse les réponses HTTP à l’aide de la compression gzip à la demande des clients qui prennent en charge la compression. La compression réduit la quantité de bande passante utilisée, ce qui entraîne une amélioration globale de la vitesse de transmission.
- Enregistrement : HAProxy enregistre toutes les demandes des clients
Étant donné que HAProxy peut répartir la charge entre les serveurs, il est couramment utilisé pour améliorer les performances et la fiabilité d’un environnement de serveur en réduisant la charge sur un seul serveur tout en offrant une protection contre les pannes occasionnelles, car elles ont tendance à se produire avec des serveurs Web/d’applications peu fiables.
Comment fonctionne HAProxy ?
HAProxy prend en charge les couches TCP et HTTP. En outre, il prend également en charge la couche HTTP ou les applications basées sur HTTP. TCP étant un protocole qui permet une communication fiable entre deux applications. HTTP étant un ensemble de règles permettant de transférer des fichiers tels que du texte, des images et des vidéos entre des navigateurs Web et d’autres appareils.
L’application principale HAProxy fonctionne sous Linux, Solaris, FreeBSD, OpenBSD et NetBSD. Le projet maintient également une documentation d’utilisation qui peut être trouvée ici : http://cbonte.github.io/haproxy-dconv/1.5/configuration.html#5
Tout d’abord, lorsque nous définissons une configuration HAProxy, nous devons définir une doctrine par défaut, c’est-à-dire une configuration utilisée dans tous les cas. Prenons l’exemple de la partie certificat SSL / TLS.
Quand vous utilisez un site internet en HTTPS, vous devez respecter des standards de sécurité. Nous avons par exemple des “ciphers”, des “options”, et même des “ciphers suites”.
Les “ciphers” sont les facteurs principaux de sécurité, ce sont eux qui déterminent la plus grosse partie de la sécurité SSL / TLS, c’est souvent déterminé un mot clef comme celui-ci: “TLS_X_Y_Z”.
Dans la majorité des cas, X est “AES” car c’est le chiffrement le plus utilisé. Y est la taille de clé symétrique utilisée pendant les échanges, parfois, c’est 128, ou même 256. On voit souvent des sites e-commerces utilisant la mention “AES 256bit”, cela correspond à la même chose. Et pour finir, Z détermine la signature utilisée par paquet chiffré transmis. Nous utilisons souvent SHA256, qui est un standard recommandé par la communauté internationale.
Si vous souhaitez obtenir une note de sécurité correcte auprès des acteurs de la sécurité, sur HAProxy, vous pourrez utiliser la configuration suivante : La partie ci-dessous correspond aux éléments “ciphers” supportés, et donc autorisés de notre côté. Si un client présente un “cipher” qui n’est pas dans la suite, la connexion SSL / TLS ne pourra pas se faire. Ils sont triés par ordre de priorité.
ssl-default-bind-ciphers
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-EC
DSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHAC
HA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:
DHE-RSA-AES256-GCM-SHA384
Dans la ligne ci-dessous, nous observons les “ciphersuites” qui sont des “ensemble de configuration”, c’est à dire que même si nous autorisons le cipher “AES128”, nous ne voulons l’utiliser qu’avec sa variante “GCM” et une signature SHA256. Cela permet de s’assurer que les variations de ciphers ne sont pas détournées.
ssl-default-bind-ciphersuites
TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
Enfin, dans cette partie, nous déterminons des options “coupe-feux”, ce sont des options dites générales. Nous ne supporteront que les connexions utilisant le mécanisme TLS ayant une version 1.2 ou supérieure. Et nous interdisons l’usage des “Tickets TLS” qui peuvent être un vecteur d’attaque.
ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets
Dans la ligne ci-dessous, afin de sécuriser les échanges, nous utilisons une clé de sécurité Diffie–Hellman avec une taille d’au moins 4096 caractères. Plus la clé est longue, moins il sera possible d’intercepter la clé de sécurité symétrique lors de la négociation TLS entre le serveur et le client.
tune.ssl.default-dh-param 4096
Au-delà de la partie TLS / SSL, il y a aussi les attaques par déni de service, comme les attaques “slowloris”.
Quelles sont les requêtes ?
Lorsque vous envoyez une demande à un serveur web, vous envoyez une requête HTTP, avec un format bien précis. Toutefois, le protocole HTTP ne prévoit pas de temps maximum d’envoi de la requête du client au serveur.
Ces attaques sont basées sur le fait que vous pouvez envoyer le début d’une requête, et attendre des secondes, ou même des minutes pour envoyer le reste de votre requête. Cela occupera donc une place dans la file d’attente du serveur.
Sur HAProxy, nous déterminons des temps d’attente pour ce type de requête:
timeout connect 120s
La première partie est le temps d’attente entre le haproxy et le backend, c’est le temps maximum que nous attendrons pour joindre le serveur où est hébergée l’application.
timeout server 120s
La seconde partie est le temps d’attente maximum du haproxy pour la réponse à la requête envoyée. Si votre page prend plus de 120 secondes à être renvoyé, haproxy coupera la connexion à 120 secondes.
timeout client 120s
Et enfin, dans cette partie, nous bloquerons les requêtes dites “slowloris” car si un attaquant tente de monopoliser la file d’attente du serveur comme déjà expliqué plus haut, nous couperons la connexion avec ce client au bout de 120 secondes.