Provya

Expertise pfSense

Sommaire des articles  -  Liens & Actualités  -  Firewall pour pfSense

[Asterisk] Sécuriser efficacement et simplement son serveur avec iptables et fail2ban

icon 14/05/2019 - Aucun commentaire

Héberger son serveur Asterisk sur un cloud public, ou d'une façon générale rendre son serveur Asterisk accessible sur Internet peut être une nécessité ou une facilité d'usage, mais cela implique de le sécuriser avec la plus grande précaution afin d'éviter les mauvaises surprises...

Bonne nouvelle, il est possible de se protéger très facilement en adoptant une démarche pragmatique, en réalisant une simple configuration d'Asterisk et en adoptant les outils fail2ban et iptables.

Cet article est dédié à la sécurisation d'un serveur Asterisk.
Cet article n'est pas un tuto détaillé sur la configuration du logiciel Asterisk.



fail2ban & iptables, qu'est-ce que c'est ?


iptables est un outil accessible en ligne de commande sur n'importe quel serveur GNU/Linux permettant de configurer des règles de filtrage des flux réseaux entrants et sortants d'un serveur. C'est un véritable pare-feu intégré à la machine.
Pour être tout à fait précis, iptables est une interface utilisateur au framework Netfilter qui implémente un pare-feu au sein du noyau Linux.

fail2ban est un outil d'analyse de journaux (log) dont l'objectif premier est de détecter des tentatives d'intrusions ou de connexions infructueuses sur un service et de bannir les adresses IP à l'origine de ces tentatives d'intrusion.

Le trio d'une configuration d'Asterisk pragmatique + fail2ban + iptables va nous permettre de nous mettre en sécurité contre la quasi-totalité des attaques que peut subir notre serveur Asterisk.



[1/4] Pour commencer : soyons pragmatiques


Pour sécuriser Asterisk, il est important d'adopter une approche logique et pragmatique. Pour cela, nous respecterons deux règles très simples :
  1. n'autoriser que ce qui est nécessaire. C'est-à-dire que l'on n'activera pas les services que l'on n'utilise pas d'une part, et que l'on appliquera des filtrages par adresse IP lorsque cela est possible d'autre part.
  2. ne pas utiliser un identifiant et/ou un mot de passe simple. Jamais. Il ne faut pas utiliser d'identifiant trivial comme : "100", "abc", "demo", "Pierre", "test", "temporaire", etc. Idem pour les mots de passe.


Filtrer l'authentification SIP par adresse IP


Dans la configuration de nos comptes SIP (fichier sip.conf et dérivés) il est possible de préciser l'adresse IP ou les adresses IP autorisées à s'enregistrer sur les comptes SIP de notre Asterisk.
Cette configuration se fait par compte SIP (ou trunk SIP). Elle permet donc d'être très souple.

Dans la configuration de chaque compte SIP, nous ajoutons les paramètres suivants :
deny=0.0.0.0/0.0.0.0
permit=33.12.13.14/255.255.255.255
La première ligne interdit toutes les adresses IP.
La second ligne autorise exclusivement l'adresse IP 33.12.13.14

Si nous devons autoriser plusieurs adresses IP ou plages d'adresses IP, nous pouvons ajouter autant de lignes permises que nécessaire. Exemple :
deny=0.0.0.0/0.0.0.0
permit=33.12.13.14/255.255.255.255
permit=33.22.23.24/255.255.255.255
Dans cet exemple, les adresses IP 33.12.13.14 et 33.22.23.24 seront autorisées.



Appliquer une sécurité de base sur notre configuration SIP


Il y a deux paramètres indispensables à faire figurer dans notre contexte general de notre configuration SIP :
[general]
...
allowguest=no
alwaysauthreject=yes
...

La signification de ces deux paramètres est la suivante :
  • allowguest=no : bloque la possibilité de passer un appel sans être préalablement enregistré
  • alwaysauthreject=yes : configure Asterisk pour qu'il renvoi le même message d'erreur générique lors d'une tentative de connexion erronée, que l'identifiant soit valide ou non



Utiliser un bon identifiant et un bon mot de passe


Un bon identifiant SIP est un identifiant faisant au moins 8 caractères. Plus il sera long, mieux ce sera. C'est un identifiant que vous n'avons pas à retenir.
Si l'utilisateur Pierre dispose d'un compte SIP dont l'identifiant est aB7ytWxEd, rien n'empêche qu'il soit joignable sur l'extension 100. Il faut bien distinguer l'identifiant SIP et le numéro ou l'extension d'appel.
Par exemple, pour faire correspondre l'extension 100 au compte SIP aB7ytWxEd, alors dans notre fichier de configuration extensions.conf nous aurons quelque chose comme cela :

; Appel vers l'extension 100
exten => 100,1,Dial(SIP/aB7ytWxEd,25,rtT)
   same => n,Voicemail(100@mycontext,u)
   same=> n,Hangup()

Bien évidemment, l'identifiant SIP et le mot de passe SIP doivent être différents. Nous recommandons d'utiliser des mots de passe composés d'au-moins 20 caractères.



[2/4] Bye-bye script-kiddies ou comment réduire le nombre d'attaques d'environ 99%


Pour réduire le nombre d'attaques d'au-moins 99%, une configuration très simple mais malheureusement trop rarement appliquée consiste à paramétrer le service Asterisk pour qu'il soit en écoute sur un autre port que le port SIP standard 5060.

Cette configuration n'est pas un élément de sécurité à proprement parler, et il ne faut pas considérer être en sécurité juste parce qu'on applique cette mesure, mais elle nous permettra d'échapper à l'immense majorité des script-kiddies qui scannent le port 5060 des serveurs.

Pour modifier le port SIP d'écoute d'Asterisk, ouvrir le fichier /etc/asterisk/sip.conf et dans la section [general] ajouter ou modifier la valeur de l'option bindport :
[general]
bindport=5872

Dans l'exemple ci-dessus, nous avons configuré notre serveur Asterisk pour que son port SIP d'écoute soit le 5872. Vous pouvez choisir une autre valeur (en fait, nous vous encourageons à choisir une autre valeur).

L'ensemble des configurations réalisées jusqu'à présent permet de réduire la surface d'attaque. Nous allons maintenant voir comment filtrer et sécuriser les services restant actifs.

Nous insistons sur le fait que d'après nos statistiques internes, simplement en changeant le port SIP d'écoute d'Asterisk, on peut passer de plusieurs dizaines de tentatives d'intrusions par force brute par jour à un chiffre compris entre zéro et dix par an.
Ceci étant, il ne faut pas croire que cette configuration soit suffisante pour sécuriser un serveur Asterisk.



[3/4] Configurer fail2ban pour Asterisk


fail2ban est inclus dans toutes les distributions GNU/Linux. Pour l'installer :
Debian/Ubuntu/Mint : apt-get install fail2ban
CentOS/RedHat : yum install fail2ban (s'il ne trouve pas le paquet fail2ban, le faire précéder d'un yum install epel-release)

Dès que fail2ban est installé, il est immédiatement opérationnel pour le port SSH. Nous allons le configurer pour Asterisk.


3.1 - Créons un fichier de log Asterisk pour fail2ban


Dans son mode de fonctionnement, fail2ban lit un fichier de log pour y repérer les tentatives d'intrusions. Nous allons créer un fichier de log Asterisk spécifique pour fail2ban.
Commençons par ouvrir avec notre éditeur de texte préféré le fichier de configuration des logs d'Asterisk /etc/asterisk/logger.conf pour y ajouter la ligne suivante en fin de fichier :
fail2ban => notice,security

On recharge la configuration de journalisation d'Asterisk, en saisissant la commande suivante :
myserver# asterisk -rx 'logger reload'

Cette action a permis la création d'un fichier de log spécifique se situant à l'emplacement /var/log/asterisk/fail2ban (sauf si vous avez modifié le répertoire par défaut de stockage des logs d'Asterisk, bien-sûr) qui contiendra uniquement les informations de type "notice" et "security".
Nous allons maintenant configurer fail2ban pour Asterisk.


3.2 - Créons un "jail" pour Asterisk


Créons un fichier du nom de notre choix dans le répertoire /etc/fail2ban/jail.d/. Dans notre exemple, nous nommerons ce fichier provya.conf ; et ajoutons le code suivant dans le fichier :
[asterisk-provya]
enabled  = true
ignoreip = 127.0.0.1 1.2.3.4
filter   = asterisk
action   = iptables-allports[name=asterisk, protocol=all]
logpath  = /var/log/asterisk/fail2ban
findtime  = 10m
maxretry = 3
bantime  = 360m

Détaillons ligne-par-ligne :
  • [asterisk-provya] : nom de notre jail (prison)
  • enabled = true : permet d'activer ce jail ; c'est-à-dire cette règle
  • ignoreip = 127.0.0.1 1.2.3.4 : la liste des adresses IP sources qui ne doivent pas être prises en compte par fail2ban. Il s'agit généralement des adresses IP légitimes comme l'adresse IP de notre connexion Internet ou d'un serveur VPN, par exemple. Il est recommandé de toujours laisser l'adresse 127.0.0.1. Chaque adresse IP doit être séparée par un simple espace.
  • filter = asterisk : le nom du filtre qui contient l'expression régulière qu'utilisera fail2ban pour détecter les tentatives d'intrusion. Le filtre "asterisk" est un filtre déjà pré-existant avec fail2ban. Il est bien fait. Nous l'utilisons.
  • action = iptables-allports[name=asterisk, protocol=all] : l'action qui sera exécutée par fail2ban lorsque les critères de déclenchement s'activeront. Dans le cas présent, nous indiquons à fail2ban d'utiliser l'action "iptables-allports" qui est une action pré-existante qui va créer une règle iptables de filtrage. La règle de filtrage iptables comportera le mot clef "asterisk" (ce qui nous permettra de la repérer facilement) et bloquera tous les ports de notre serveur pour l'adresse IP source incriminée (protocol=all).
  • logpath = /var/log/asterisk/fail2ban : le nom du fichier de log que fail2ban devra lire pour détecter les tentatives d'intrusion. Il s'agit du fichier de log Asterisk que nous avons créé à l'étape précédente.
  • findtime = 10m : la durée sur laquelle le nombre de tentatives de connexion va être prise en compte par fail2ban. Ici, 10 minutes.
  • maxretry = 3 : le nombre de tentatives de connexions à partir de laquelle notre filtrage va se déclencher. Ici, 3 tentatives.
  • bantime = 360m : la durée de bannissement. Ici, 360 minutes, soit 6 heures. Si vous souhaitez bannir une adresse IP plus d'une journée, il vous faudra personnaliser la valeur de "dbpurgeage" du fichier fail2ban.conf

Ainsi donc, dans cette configuration, nous bannissons pour 6 heures toute adresse IP ayant effectué 3 tentatives de connexions erronées sur notre serveur en moins de 10 minutes.
Attention : pensez à bien configurer le champ "ignoreip" si vous ne voulez pas vous retrouver coupé de votre serveur suite à une mauvaise manipulation... ;-)


3.3 - [Optionnel] Personnalisons le filtre pour Asterisk


Le filtre pour Asterisk fourni par défaut avec fail2ban est bien fait et il n'est pas forcément nécessaire de le changer.
Nous avons seulement déjà remarqué qu'une des règles du filtre peut avoir tendance à créer des faux-positifs. Il s'agit de la ligne :
^Call from '[^']*' \(<HOST>:\d+\) to extension '[^']*' rejected because extension not found in context

Le problème de cette règle est que si un utilisateur compose à 3 reprises en moins de 10 minutes un faux numéro (relativement peu probable, certes, mais cas déjà rencontré), alors son adresse IP va se faire bannir par fail2ban.
De plus, cette règle est inutile si vous avez défini le paramètre allowguest=no dans le fichier sip.conf comme indiqué en début d'article.

Nous commentons donc cette ligne en ajoutant un dièse (#) devant.

Il ne nous reste plus qu'à recharger fail2ban et le tour est joué !

systemctl reload fail2ban


3.4 - Les commandes utiles pour fail2ban


Quelques commandes utiles pour fail2ban :

  • fail2ban-client status : liste tous les « jails » configurés
  • fail2ban-client status asterisk-provya : affiche le statut du jail spécifié (ici, asterisk-provya) et précise le nombre d'adresses IP bannies
  • systemctl restart fail2ban : redémarre le service fail2ban
  • fail2ban-client set asterisk-provya banip 1.2.3.4 : permet de bannir manuellement l'adresse IP 1.2.3.4 dans le jail asterisk-provya
  • fail2ban-client set asterisk-provya unbanip 1.2.3.4 : permet de dé-bannir manuellement une adresse IP qui a été précédemment bannie
  • fail2ban-regex /var/log/asterisk/fail2ban /etc/fail2ban/filter.d/asterisk.conf : permet de tester le bon fonctionnement d'un filtre fail2ban sur un fichier de log
  • fail2ban-client get dbpurgeage : affiche la durée maximum durant laquelle les adresses IP bannies seront conservées
  • fail2ban-client get asterisk-provya bantime : affiche la durée de bannissement du jail indiqué

La configuration de fail2ban est terminée. Passons à la configuration du filtrage avec iptables.



[4/4] Configurer iptables pour Asterisk


Dernière étape dans notre stratégie de sécurisation de notre serveur Asterisk, la configuration des règles de filtrage des flux réseaux avec iptables.

La démarche va consister à définir le plus précisément possible la liste du trafic réseau que nous souhaitons autoriser, puis interdire le reste du trafic réseau.
Pour cela, nous devons définir quels services tournent sur notre serveur Asterisk et sur quels ports ces services sont joignables.

Par exemple :
  • serveur Asterisk (SIP) : port UDP/5060 (ou celui que vous aurez configuré précédemment !)
  • serveur Asterisk (flux audio RTP) : ports UDP/10.000-20.000
  • serveur SSH : port TCP/22
  • interface d'administration web (si installée) : port TCP/443
  • ICMP (si l'on souhaite que son serveur réponde au ping) : icmp

Si l'on utilise une distribution Asterisk packagée (type Wazo, Xivo, Elastix, ...), il faut aussi prendre en compte les services spécifiques de ces distributions. Pour Wazo, la liste des flux réseaux est présentée dans la documentation en ligne.

Nous faisons le même travail pour les flux sortant du serveur ; c'est-à-dire les flux réseaux émis par le serveur.

Par exemple :
  • mise à jour (HTTP/HTTPS) : ports TCP/80, TCP/443
  • flux NTP : port UDP/123
  • flux DNS : port UDP/53
  • flux trunk SIP : port UDP/5060 (ou celui configuré par votre opérateur SIP)
  • flux RTP : ports UDP/10.000-20.000

Par simplicité, il est possible de n'appliquer aucune restriction sur les flux sortants, et de ne filtrer que les flux entrants. C'est un choix à faire en terme de sécurité.

Nous devons ensuite définir pour chacun de ces services, dans la mesure du possible, quelles adresses IP sont autorisées à joindre les services hébergés sur le serveur Asterisk (trafic entrant) et quelles adresses IP sont autorisées à être contactées par le serveur Asterisk (trafic sortant).

Cette étape est importante. Si les adresses IP sources sont connues, il n'y a aucune raison de laisser le serveur Asterisk joignable sans aucune restriction par adresse IP source. C'est la base de la sécurisation du serveur. Et cela évite de se reposer uniquement sur fail2ban pour filtrer les tentatives de connexions mal-intentionnées. Les rôles d'iptables et fail2ban sont complémentaires.

Pour l'exemple d'implémentation de nos règles de filtrage, nous partirons sur le cas suivant :
  • Nous autorisons l'accès aux services d'administration du serveur (SSH et HTTPS, par exemple) uniquement pour l'adresse IP de la connexion Internet de notre entreprise : 188.10.11.12
  • Nous n'appliquons pas de filtrage par adresse IP pour les services Asterisk (SIP & RTP) afin de permettre l'accès par les utilisateurs nomades
  • Nous autorisons la plage d'adresses IP utilisées par notre opérateur SIP : 51.5.6.0/24

Ce qui nous donnera en terme de filtrage des flux entrants les règles suivantes :
iptables -A INPUT -s 51.5.6.0/24 -p udp -m udp --dport 5060 -m comment --comment "Opérateur SIP - flux SIP" -j ACCEPT
iptables -A INPUT -s 51.5.6.0/24 -p udp -m udp --dport 10000:20000 -m comment --comment "Opérateur SIP - flux RTP" -j ACCEPT
iptables -A INPUT -s 188.10.11.12/24 -p tcp -m tcp --dport 443 -m comment --comment "Administration - IP du bureau" -j ACCEPT
iptables -A INPUT -s 188.10.11.12/24 -p tcp -m tcp --dport 22 -m comment --comment "Administration - IP du bureau" -j ACCEPT
iptables -A INPUT -m comment --comment "filtrage fail2ban" -j asterisk-provya
iptables -A INPUT -p udp -m udp --dport 5060 -m comment --comment "Flux SIP Open" -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 10000:20000 -m comment --comment "Flux RTP Open" -j ACCEPT
iptables -A INPUT -p icmp -m comment --comment "si l'on souhaite autoriser les PING" -j ACCEPT
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -m comment --comment "On bloque tout le reste" -j DROP

iptables -A asterisk-provya -j RETURN

Il faut bien évidemment adapter cet exemple à votre configuration réelle et aux services que vous souhaitez filtrer.

Et pour le filtrage des flux sortants :
iptables -A OUTPUT -d 51.5.6.0/24 -p udp -m udp --dport 5060 -m comment --comment "Opérateur SIP - flux SIP" -j ACCEPT
iptables -A OUTPUT -d 51.5.6.0/24 -p udp -m udp --dport 10000:20000 -m comment --comment "Opérateur SIP - flux RTP" -j ACCEPT
iptables -A OUTPUT -p udp -m udp --dport 10000:20000 -m comment --comment "Flux RTP Open" -j ACCEPT
iptables -A OUTPUT -p udp -m tcp --dport 80,443 -m comment --comment "Flux HTTP/HTTPS" -j ACCEPT
iptables -A OUTPUT -p udp -m udp --dport 123 -m comment --comment "Flux NTP" -j ACCEPT
iptables -A OUTPUT -d 9.9.9.9/32 -p udp -m udp --dport 53 -m comment --comment "Flux DNS vers Quad9" -j ACCEPT
iptables -A OUTPUT -p icmp -m comment --comment "si l'on souhaite autoriser les PING" -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m comment --comment "On bloque tout le reste" -j DROP

Encore une fois, il faut bien évidemment adapter cet exemple à votre configuration réelle et aux flux que vous souhaitez filtrer.


Commandes utiles pour iptables[/u]


Quelques commandes utiles pour iptables :

  • [b]iptables -L -n : liste toutes les règles iptables (l'option -n permet l'affichage des adresse IP au format numérique)
  • iptables -L --line-numbers : affiche le numéro de ligne de chaque règle
  • iptables -D OUTPUT 2 : supprime la règle numéro 2 de la chaîne OUTPUT
  • iptables-save > provya.txt : fait une sauvegarde des règles iptables vers le fichier provya.txt
  • iptables-restore < provya.txt : restaure les règles contenues dans le fichier provya.txt


Vous avez toutes les armes en main pour sécuriser correctement et efficacement votre serveur Asterisk.
Il faut bien évidemment adapter ces recommandations à votre usage, à votre besoin et à la localisation du serveur Asterisk (hébergement public type Cloud, hébergement privé derrière un firewall, etc.).
D'une façon générale, au plus vous serez précis dans vos règles de filtrage et mieux ce sera.
Enfin, il faut aussi rester pragmatique et implémenter la solution correspondant aux besoins réels avec les contraintes associées sans chercher à faire trop, ni tomber dans la fainéantise du pas-assez. Bref, à vous de trouver le juste équilibre ! ;-)



Pour aller plus loin


fail2ban est-ce vraiment utile ? Partage d'expérience
[Asterisk] Les commandes utiles pour Asterisk
[Asterisk] Connaître son nombre d'appels simultanés
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

fail2ban est-ce vraiment utile ? Partage d'expérience

icon 04/04/2019 - 10 commentaires

fail2ban est un outil d'analyse de journaux (log) dont l'objectif premier est de détecter des tentatives d'intrusion ou de connexions infructueuses sur un service et de bannir les adresses IP à l'origine de ces tentatives d'intrusions.

Mais est-ce vraiment utile d'implémenter ce logiciel (ou un logiciel similaire) sur son serveur GNU/Linux ? Et dans quels cas est-ce utile ou inutile ?

Nous répondrons à ces questions dans cet article, ou du tout moins, nous donnerons notre point de vue sur fail2ban en nous basant sur notre expérience de la sécurisation de serveurs et en partageant un retour d'expérience quant à l'implémentation de fail2ban.


fail2ban, est-ce bien utile ?


Non, fail2ban n'est pas utile ; fail2ban est absolument indispensable.

Soyons parfaitement clair, il nous paraît totalement inconcevable d'avoir un serveur GNU/Linux hébergeant un service accessible sur le réseau (que ce soit un réseau public comme Internet ou privé comme un réseau local) sans que ne soit implémenté fail2ban ou un outil similaire.

À partir du moment où votre serveur est allumé et connecté à un réseau, il devient de facto une cible d'attaques ; qu'il soit connecté à Internet ou non, et que vous en ayez conscience ou non.

Le premier type d'attaque que l'on rencontre le plus fréquemment est la tentative d'intrusion par force brute (brute-force). Ces attaques peuvent cibler un serveur SSH, un CMS Wordpress, un service Asterisk, etc. fail2ban protège efficacement contre ce type d'attaque en identifiant les tentatives de connexions infructueuses et en bloquant (via iptables, par exemple) les adresses IP à l'origine de ces tentatives d'intrusions.

Le second type d'attaque est la tentative de déni de service. fail2ban peut protéger couramment contre ce type d'attaque en identifiant rapidement les adresses IP à l'origine de trop nombreuses requêtes.



Pas convaincu de la nécessité de fail2ban ? Partage d'un retour d'expérience


Pour se convaincre de l'utilité d'implémenter un service comme fail2ban, nous avons réalisé l'expérience suivante : nous avons configuré fail2ban sur trois serveurs hébergeant les services suivants :

  • serveur 1 : SSH (port 22) et Asterisk (port 5060)
  • serveur 2 : SSH (port 22) et Apache (port 80)
  • serveur 3 : SSH (port 22) et Apache (port 443)

Nous avons mesuré le nombre de tentatives d'intrusions sur le port SSH sur chacun de ces serveurs et nous sommes demandés si le fait d'avoir d'autres services en écoute avait une incidence sur ce nombre.

Dans le cadre de ce test, nous avons configuré fail2ban pour superviser uniquement le port SSH et bannir les adresses IP faisant 3 tentatives de connexions infructueuses en moins de 10 minutes. La durée de bannissement a été défini à 15 jours. Le test a duré 15 jours. Ainsi, au cours de ces 15 jours, nous sommes certains de ne pas avoir banni plusieurs fois la même adresse IP.

Le graphique ci-dessous présente en bleu l'évolution heure par heure du nombre d'adresses IP bannies pour les trois serveurs ; la courbe rouge représente la courbe de tendance au démarrage de la mesure (attention à l'échelle) :

adresses IP bannies par fail2ban - provya


1° constat : au bout de 15 jours, chaque serveur a banni plus de 6 000 adresses IP uniques !
2° constat : la progression est continue au cours des 5 à 8 premiers jours, avant de commencer à décliner par la suite.
3° constat : le serveur hébergeant un service Asterisk est nettement plus attaqué que ceux hébergeant un serveur Apache (+30% d'attaques environ)
4° constat : le serveur hébergeant un service Asterisk a banni plus de 3 000 adresses IP les 3 premiers jours, tandis que les deux autres serveurs en ont banni environ 1 750 sur les 3 premiers jours ; soit +70% d'attaques environ sur le serveur Asterisk lors des 3 premiers jours.


Le graphique ci-dessous présente en bleu le nombre d'adresses IP bannies heure par heure ; la courbe rouge représente la courbe de tendance (attention à l'échelle) :

adresses IP bannies par fail2ban heure par heure - provya


1° constat : le nombre de tentatives d'intrusions baisse clairement au fil du temps ; la plus forte baisse étant constatée sur le serveur 1 (SSH + Asterisk), qui était le serveur enregistrant le plus d'attaques. Le serveur 2 (SSH + Apache) est celui qui a la tendance la plus stable.
2° constat : sur les 15 jours, il y a eu en moyenne 21 tentatives d'intrusion par heure sur le serveur 1 (SSH + Asterisk), 16 sur le serveur 2 (SSH + Apache) et 17 sur le serveur 3 (SSH + Apache). La valeur médiane pour les serveurs 2 et 3 est équivalente à leur moyenne à moins d'un point près (valeur médiane à 16 pour tous les deux) ; pour le serveur 1, la valeur médiane est de 18.
3° constat : il y a plus de tentatives d'intrusions la nuit (créneau 20h - 08h), que le jour (créneau 08h - 20h) ; 35 % en moyenne.
4° constat : nous n'avons pas vu d'augmentation significative du nombre d'attaques durant le week-end. De notre point de vue et de notre expérience, un serveur qui essuie une attaque par force-brute durant le week-end (à partir du vendredi soir, bien souvent...) a généralement déjà été testé de manière beaucoup moins virulente durant la semaine ; dans le cadre de ce test, notre script bannissant directement pour 15 jours, cela empêche l'attaquant d'effectuer un repérage en semaine avant de lancer une attaque durant le week-end.



Conclusion : fail2ban, c'est indispensable !


Il est extrêmement simple d'installer fail2ban sur n'importe quel serveur GNU/Linux. Il est inclus dans toutes les distributions.
Debian/Ubuntu/Mint : apt-get install fail2ban
CentOS/RedHat : yum install fail2ban (s'il ne trouve pas le paquet fail2ban, le faire précéder d'un yum install epel-release)

Dès qu'il est installé, il est immédiatement opérationnel pour le port SSH.
fail2ban incorpore un nombre important de règles prédéfinies pour énormément de logiciel, ce qui facilite grandement sa mise en œuvre.
Il ne vous reste plus qu'à le personnaliser pour mettre vos adresses IP en withelist par exemple ou pour modifier la durée du bannissement.
Il existe de nombreux tutos sur Internet pour chaque service que vous souhaiterez superviser par fail2ban.

fail2ban est également indispensable pour les serveurs internes (non-accessibles depuis Internet) car vous n'êtes pas à l'abri d'une personne mal-intentionnée ou qu'un ordinateur de votre réseau local soit infecté par un bot ou un ver informatique.
À noter que vous pouvez configurer fail2ban pour qu'il vous envoie un e-mail dès qu'il détecte un nombre important de tentatives d'intrusions. Nous recommandons l'utilisation de cette option d'alerte par e-mail pour les serveurs accessibles uniquement en interne.

À noter : si votre fail2ban est amené à bloquer un très grand nombre d'adresses IP, alors l'hébergeur Octopuce propose de coupler fail2ban à IPset plutôt que iptables. Vous pouvez lire leur article : IPSET & filtrages des attaques sur les serveurs. Ils partagent le code source de leurs scripts sur leur espace GitHub.



Et vous, utilisez-vous fail2ban ?

Dans l'article [Asterisk] Sécuriser efficacement et simplement son serveur avec iptables et fail2ban, nous présentons comment sécuriser simplement et efficacement un serveur Asterisk avec un peu de bon sens, fail2ban et iptables.



Pour aller plus loin


[Asterisk] Sécuriser efficacement et simplement son serveur avec iptables et fail2ban
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[Postfix] Installer et configurer Postfix pour envoyer ses e-mails depuis un serveur dédié

icon 23/07/2018 - 4 commentaires

Nous décrivons succinctement dans cet article l'installation et la configuration du service postifx.
Le but de cet article n'est pas de rentrer dans le détail, mais de servir de pense-bête.

Dans notre cas, nous travaillons sur un serveur Ubuntu ou Debian hébergé chez OVH.

Les étapes pour l'installation et la configuration d'un serveur postfix sont les suivantes :

Étape 1 - Installation de postfix


On installe le service postfix :

myserver# apt-get install postfix

Par simplicité et habitude, pour le choix de la configuration nous sélectionnons "Site Internet" :

Installation de postfix


Dans le champ "Nom du courrier", nous laissons l'hostname de la machine (proposé par défaut).

Étape 2 - Modification du fichier main.cf


On édite le fichier de configuration principal (/etc/postfix/main.cf) pour y modifier ou ajouter les lignes suivantes :

relayhost = ns0.ovh.net:587	# on précise le serveur relay ainsi que le port d'écoute

smtp_sasl_auth_enable = yes	
smtp_sasl_password_maps = hash:/etc/postfix/sasl/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_generic_maps = hash:/etc/postfix/generic

Forcer l'utilisation d'IPv4 (le cas échéant) :

inet_protocols = ipv4

La valeur de relayhost est évidemment à adapter à la configuration de chacun.

Étape 3 - Création du fichier generic


Pour la translation du courriel, on crée le fichier /etc/postfix/generic et on y place :
utilisateur	adresse@email.fr

On crée le hash :

myserver# postmap hash:/etc/postfix/generic
Cette commande crée le fichier generic.db

Étape 4 - Création du fichier sasl_passwd


On crée le fichier /etc/postfix/sasl/sasl_passwd dans lequel nous y stockons les informations de connexion au relai SMTP :
ns0.ovh.net adresse@email.fr:mot_de_passe
Évidemment, le nom de l'hôte est à adapter à la configuration de chacun.

On crée le hash :

myserver# postmap hash:/etc/postfix/sasl/sasl_passwd
Cette commande crée le fichier sasl_passwd.db

Le fichier sasl_passwd contenant les informations de connexion en clair peut être supprimé.

Étape 5 - Reload + test


On recharge la configuration de postfix :
myserver# /etc/init.d/postfix restart

Il reste a essayer d'envoyer un e-mail en ligne de commande (méthode de votre choix).

Pour voir l'état de la file d'attente :
mailq
Elle devrait être vide si l'envoi s'est bien passé.

Pour vider la file d'attente des e-mails :
myserver# /etc/init.d/postfix stop
myserver# postsuper -d ALL
myserver# /etc/init.d/postfix start

That's all folks! :-)



Pour aller plus loin


fail2ban est-ce vraiment utile ? Partage d'expérience
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :