Il y a quelques années, j'ai installé et configuré un serveur VOIP Asterisk sans prétention. L'ennui, c'est que des robots essayent en permanence de trouver un couple identifiant+mdp valide dans l'objectif de dénicher des appels nationaux / internationaux. Il suffit ensuite à leur propriétaire de souscrire à une offre de fourniture d'un numéro surtaxé puis de faire téléphoner ses robots au numéro ainsi obtenu afin d'encaisser de l'argent. Asterisk consigne toutes ces tentatives dans un fichier de log… qui grossit et sature notre espace disque (le conteneur LXC qui héberge ce serveur Asterisk est dimensionné pour juste ce qu'il faut).

Soit on réduit la verbosité d'Asterisk, soit on ajuste la politique de conservation du log Asterisk, soit on filtre les pénibles. Je refuse la première solution, mais j'ai appliqué les deux autres.

Debian, Asterisk et Logrotate

La configuration de logrotate fournie par le paquet Debian contenant Asterisk ne compresse pas les logs. Changeons ça :

• On évite que dpkg nous informe de la modification du fichier et nous demande ce que nous souhaitons faire à chaque mise à jour :

  sudo dpkg-divert --add --no-rename --divert /etc/logrotate.d/asterisk.dpkg-dist /etc/logrotate.d/asterisk

• Puis, on active la compression en ajoutant les lignes suivantes dans /etc/logrotate.d/asterisk :

  compress
  delaycompress

La compression du log Asterisk a résolu mon problème à elle seule : l'espace disque n'est plus jamais saturé. Mais ça n'empêche pas de vouloir dégager les pénibles.

Filtrer les pénibles

Fail2ban

Puisqu'on peut repérer une tentative pour trouver un couple identifiant+mdp depuis le log Asterisk, fail2ban est l'outil idéal : il va analyser ce fichier avec des regex et il bannira temporairement les pénibles avec iptables. Le paquet fail2ban fournit par Debian contient déjà un jeu de règles pour identifier quelques attaques contre un serveur VOIP.

• Installer fail2ban : sudo apt-get install fail2ban
  
  
• Contrairement à ce qu'expose la documentation de fail2ban, il n'est pas nécessaire d'activer le log de la sécurité (security log) même si l'on a un une version d'Asterisk >= 10. Activer ce log le rend encore plus verbeux ;
  
  

• Activer les règles de filtrage Asterisk de fail2ban en créant un fichier /etc/fail2ban/jail.d/asterisk.conf contenant :

  [asterisk]
  enabled = true

• Désactiver l'envoi d'un mail à root à chaque fois qu'une IP est bloquée en commentant la ligne %(mta)s-whois[name=%(__name__)s, dest="%(destemail)s"] dans la section [asterisk] du fichier /etc/fail2ban/jail.conf :

  sudo dpkg-divert --add --no-rename --divert /etc/fail2ban/jail.conf.dpkg-dist /etc/fail2ban/jail.conf
  sudo $EDITOR /etc/fail2ban/jail.conf # commenter « %(mta)s-whois[name=%(__name__)s, dest="%(destemail)s"] » dans la section « [asterisk] »

• Désactiver l'envoi d'un mail à root à chaque fois qu'un jeu de règles de filtrage est activé ou désactivé en créant un fichier /etc/fail2ban/action.d/sendmail-common.local contenant :

  [Definition]
  actionstart =
  actionstop =

• Par défaut, fail2ban insère des règles netfilter qui envoient un message ICMP au robot spammeur bloqué (« -j REJECT »). On peut changer ce comportement :

  sudo dpkg-divert --add --no-rename --divert /etc/fail2ban/action.d/iptables-common.conf.dpkg-dist /etc/fail2ban/action.d/iptables-common.conf
  sudo sed -i -e 's#blocktype = REJECT --reject-with icmp-port-unreachable#blocktype = DROP#' /etc/fail2ban/action.d/iptables-common.conf

• On peut aussi désactiver le jeu de règles de filtrage pour sshd :

  sudo dpkg-divert --add --no-rename --divert /etc/fail2ban/jail.d/defaults-debian.conf.dpkg-dist /etc/fail2ban/jail.d/defaults-debian.conf
  sudo sed -i -e 's#enabled = true#enabled = false#' /etc/fail2ban/jail.d/defaults-debian.conf

• Si l'on veut toucher du doigt la modernitude, on peut activer un filtrage utilisant les ipsets. Dans la section [asterisk] du fichier /etc/fail2ban/jail.conf, on ajoute une ligne : banaction = iptables-ipset-proto4 ;
  
  
• On redémarre fail2ban : sudo systemctl restart fail2ban ;
  
  
• On profite du spectacle : sudo tail -f /var/log/asterisk/messages /var/log/fail2ban.log et sudo iptables -t filter L -n -v (et sudo ipset list f2b-asterisk-udp si l'on a activé l'utilisation des ipset).

Rate-limiting avec netfilter

En attendant d'avoir le temps de me pencher sur fail2ban pour la première fois, j'ai utilisé cette règle de filtrage :

sudo iptables -A INPUT ! -s $SUBNET_RESEAU -d $IP_SERVEUR/32 -p udp -m udp --dport 5060 -m hashlimit --hashlimit-above 5/min --hashlimit-burst 10 --hashlimit-mode srcip --hashlimit-name RL-SIP-GLOBL-v4 --hashlimit-srcmask 24 -m comment --comment "RL SIP QUERIES 5/min burst 10/min" -j DROP

Elle autorise 5 paquets par minute destinés au port UDP 5060 du serveur VOIP en vitesse de croisière et 10 paquets/minute par à-coups. Les utilisateurs membres du réseau ont la garantie de ne pas être filtrés grâce à « ! -s $SUBNET_RESEAU ».

Je rends cette règle de filtrage résistante à un redémarrage avec le logiciel netfilter-persistent.

Si cette règle de filtrage n'est pas idéale, elle a le mérite de calmer le jeu. Elle n'empêche pas le trunk SIP avec notre fournisseur de fonctionner normalement en vitesse de croisière, mais il ne faut pas effectuer plusieurs tentatives d'appel en une minute. Bref, cette règle fonctionne uniquement parce que je connais la plage IP des usagers de ce serveur VOIP, qu'ils sont très peu nombreux, et qu'ils n'utilisent pas compulsivement le téléphone.

En environ 3 mois d'utilisation, cette règle de filtrage a produit le résultat suivant :

Chain INPUT (policy ACCEPT 13M packets, 1285M bytes)
pkts bytes target prot opt in out source destination
83M 31G DROP udp -- !$SUBNET_RESEAU $IP_SERVEUR/32 udp dpt:5060 limit: above 5/min burst 10 mode srcip srcmask 24

Elle a filtré 31 Go (!!!) de merde, mais elle en a aussi laissé passer 1,2 Go. Bref, pas idéal.