lid's stuff

HAProxy: ACLs et IP source

Je ne le dirai jamais, HAProxy, c'est le bien©.

Il n'y a pas si longtemps (ce matin en fait), en checkant les logs d'une plateforme sur laquelle je bosse, j'ai remarqué une IP (on va dire, 1.2.3.4 pour la suite) effectuant des requêtes en boucle (mais en dessous du niveau qui trigger l'ACL "abuser" que j'avais décrite dans un précédent post (en gros, 250 requêtes/20 secondes)).
Bon, normalement, un bon vieux sudo iptables -I INPUT -s 1.2.3.4 -j DROP devrait faire l'affaire… Eh beh non, 1.2.3.4 apparaissait toujours dans mes logs. Meh oO. Je double checke mes tables iptables avec sudo iptables -L -n | grep 1.2.3.4, il est pourtant bien là. Bizarre. Comme j'étais assez pressé (parceque je vais ensuite passer un peu de temps à analyser le pourquoi du comment iptables ne le jette pas comme un malpropre), j'ai donc fait appel à mon vieux copain HAProxy.

Définir une ACL en fonction d'une IP (ou d'un bloc d'IPs)

Ici, on veut d'abord identifier l'IP source (src) grâce à une ACL, dans le bloc de configuration de notre frontend:

frontend my_front
    bind IP:80
    bind IP:443 ssl crt /chemin/vers/vos/certificats no-sslv3 strict-sni
    # ACLs
    …
    acl is_villain src 1.2.3.4
    tcp-request connection reject if is_villain

Et voilà, au revoir!

Autres utilisations

Bien sûr, ça, c'est l'utilisation "dégage de chez moi!". On peut par contre utiliser ce type d'ACL pour, suivant l'IP d'origine, utiliser telle ou telle backend, par exemple:

acl is_me src 2.3.4.5
use_backend ma_petite_backend_dans_la_prairie if is_me

Ou rejeter l'accès à tout le monde sauf à une ou plusieurs adresses IPs précises (pas terrible, vu qu'un paquet, ça peut se forger et notamment l'IP source):

acl is_us src 2.3.4.5 3.4.5.6
tcp-request connection reject if !is_us

etc, etc, etc. Bien sûr on peut toujours cumuler les ACLs - le and est implicite, le or est à préciser et ainsi appliquer des règles précises en fonction, par exemple, de l'URL de la requête (url_reg, path_beg, etc), de l'IP source, du virtual host (hdr_host, etc), et ainsi diriger notre trafic entre nos différentes backends en fonction de ces paramètres comme bon nous semble. On peut aussi tout casser, mais bon… :)

Les possibilités sont quasi infinies.


Tagged under: network, sysadmin, haproxy