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.
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 --rename --divert /etc/logrotate.d/asterisk.dpkg-dist /etc/logrotate.d/asterisk
sudo cp /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.
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.
sudo apt-get install fail2ban
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 --rename --divert /etc/fail2ban/jail.conf.dpkg-dist /etc/fail2ban/jail.conf
sudo cp /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 --rename --divert /etc/fail2ban/action.d/iptables-common.conf.dpkg-dist /etc/fail2ban/action.d/iptables-common.conf
sudo cp /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 --rename --divert /etc/fail2ban/jail.d/defaults-debian.conf.dpkg-dist /etc/fail2ban/jail.d/defaults-debian.conf
sudo cp /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
[asterisk]
du fichier /etc/fail2ban/jail.conf
, on ajoute une ligne : banaction = iptables-ipset-proto4
;sudo systemctl restart fail2ban
;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).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.