CentOS Serveur - Ports SSH et Fail2ban - Protéger un minimum les accès ssh depuis l'extérieur vers vos CentOS / RHEL
Par manuardo le vendredi 8 mars 2013, 20:52 - CentOS
Vous en avez assez de voir des tentatives de connexion à répétition dans vos logs ? Ou vous souhaitez simplement ajouter quelques protections à un serveur ouvert en SSH sur l'extérieur ?
Voici quelques lignes qui devraient vous aider à mettre en place facilement une paire de solutions utiles..
Les "robots" (ou bots) pullulent sur la toile et disposent d'un avantage non négligeable, ils ont tout leur temps.
En effet, un serveur ouvert sur l'extérieur l'est généralement en permanence. A moins de rester à l'entrée et surveiller les logs H24, il vaut mieux se donner le maximum de chances de ne pas être victime d'une attaque, notamment "brute force". Inscrire le serveur à un cours de musculation n'aura qu'un effet peu dissuasif...
Note importante : Cet article n'est absolument limitatif. Il s'agit d'exemples simples et fonctionnels pour protéger à minima contre les méthodes d'intrusion SSH les plus exploitées. Ces méthodes peuvent être utilisées ensemble (mieux) ou séparément.
Tout d'abord, changez le port d'écoute SSH
Qui dit SSH, dit souvent port 22. Forcément, c'est donc vers ce port que les bots les plus répandus dirigent leurs tentatives.
Sous CentOS / Redhat, il est facile de le changer, via le fichier " /etc/ssh/sshd_config ". repérez la ligne "Port" au début du fichier et indiquez le port de votre choix.
Le port 2222 peut être une solution, mais il devient lui aussi très répandu. Veillez à ce que le port choisi ne soit pas utilisé par un autre protocole.
- Pour changer le port SSH (début de fichier) :
# vi /etc/ssh/sshd_config
# The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a # default value. Port 2222 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress ::
Note : Si vous êtes derrière un routeur, pensez à corriger également le transfert de port depuis l'extérieur.
- Toujours à l'abri d'un routeur, vous pouvez également laisser les deux ports en écoute. Dans ce cas, n'effectuez le transfert externe que du port ajouté (pas le 22). Le haut du fichier ressemblera à :
# The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a # default value. Port 22 Port 2222 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress ::
- Parefeu activé ? N'oubliez pas d'adapter vos règles (iptables). Exemple toujours avec le port 2222 (adaptez au port que vous aurez choisi) :
# iptables -t filter -A INPUT -p tcp --dport 2222 -j ACCEPT
# service iptables save
- Pour la prise en charge de vos modifs, pensez à redémarrer le service SSH :
# service sshd restart
Note : Veillez à ne pas déclarer votre serveur en DMZ (sur le routeur).
Créez un utilisateur dédié à l'accès SSH et interdisez "root" en accès SSH
Autre pratique courante des bots, ils vont chercher à se loguer en "root". Donc, si vous limitez l'accès SSH à n'importe quel utilisateur défini, autre que "root", leurs tentatives resteront vaines. De préférence, choisissez un nom d'utilisateur un peu sioux.. Et pensez à créer l'utilisateur avant d'interdire root.. (exemple ci dessous avec "userduchnoc"). L'idée, c'est pouvoir se connecter depuis l'extérieur avec "duchnoc" puis de passer en "root" (via un "su -" par exemple)..
- Création de l'utilisateur :
# useradd duchnoc
- Affecter un mot de passe à ce dernier :
# passwd duchnoc
- Pour interdire "root" en SSH, dé commentez et corrigez la ligne qui va bien dans le fichier " /etc/ssh/sshd_config " :
# vi /etc/ssh/sshd_config
# Acces root permis #PermitRootLogin yes
# acces root interdit PermitRootLogin no
- On peut aussi limiter les accès possibles à une liste pré-définie d'utilisateurs (toujours dans le même fichier de configuration) en ajoutant la ligne ci-dessous (avec vos utilisateurs à vous bien sûr) :
AllowUsers userduchnoc userduchnoc2
- Pas besoin de redémarrer le service dans ce cas, il suffit de le recharger :
# service sshd reload
Installez Fail2ban
Fail2ban est un processus qui va tourner en arrière plan. Son rôle est d'analyser les "logs" de connexion et, en fonction de ces derniers, d'établir des règles temporaires (via iptables) qui vont bannir les ip des éventuelles attaques.
Selon les paramètres indiqués dans la configuration, un accès SSH depuis une ip "x.x.x.x" sera interdit après un nombre défini d'échecs (user ou mot de passe incorrect) pendant un laps de temps lui aussi spécifié.
Note : Afin de faciliter la compréhension du fichier de conf de Fail2ban, les exemples ci-après ne traitent que de l'option SSH. Il est possible de l'utiliser pour d'autres protocoles comme le FTP ou Apache (Serveur Web).
Pour installer Fail2ban, vous pouvez utiliser un dépôt tiers comme "Rpmforge" (voir notre page dédiée aux dépôts pour plus d'infos).
- Installation (en root) :
# yum install fail2ban
- Ajouter Fail2ban aux process automatiques au démarrage :
# chkconfig fail2ban on
- Le fichier de configuration original est "/etc/fail2ban/jail.conf" , nous allons le laisser de côté (il contient des exemples intéressants) et créer l'alternative qui sera prise en compte automatiquement par le système.
# vi /etc/fail2ban/jail.local
- Si vous utilisez le port 22 (par défaut) :
## exemple fichier conf fail2ban ## by mgroup.fr [DEFAULT] # indiquer une adresse IP, un nom resolu de machine ou un reseau # exemple avec le reseau local ci-dessous ignoreip = 127.0.0.1 # temps de bannissement en secondes bantime = 3600 # temps de prise en compte pour le nombre de tentatives # donc banni si x tentatives echec pendant les dernieres 600 secondes findtime = 600 # nombre de tentatives max avant bannissement maxretry = 3 ######### sections dediees ######### [ssh-iptables] enabled = true filter = sshd action = iptables[name=SSH, port=SSH, protocol=tcp] logpath = /var/log/secure maxretry = 3 ## fin de fichier
- Pour tout autre port, adaptez à votre situation (exemple ci-dessous avec le 2222, 3ème ligne en partant du bas de cet exemple) :
[DEFAULT] # "ignoreip" can be an IP address, a CIDR mask or a DNS host. Fail2ban will not # ban a host which matches an address in this list. Several addresses can be # defined using space separator. ignoreip = 127.0.0.1 # "bantime" is the number of seconds that a host is banned. bantime = 3600 # A host is banned if it has generated "maxretry" during the last "findtime" # seconds. findtime = 600 # "maxretry" is the number of failures before a host get banned. maxretry = 3 [ssh-iptables] enabled = true filter = sshd action = iptables[name=SSH, port=2222, protocol=tcp] logpath = /var/log/secure maxretry = 3
- Il est possible d'ajouter une machine ou un réseau local dans la liste blanche. Dans ce cas, l'ip indiquée (ou le réseau) ne sera pas prise en compte par Fail2ban :
[DEFAULT] # "ignoreip" can be an IP address, a CIDR mask or a DNS host. Fail2ban will not # ban a host which matches an address in this list. Several addresses can be # defined using space separator. ignoreip = 127.0.0.1 192.168.0.0/24 # "bantime" is the number of seconds that a host is banned. bantime = 3600 # A host is banned if it has generated "maxretry" during the last "findtime" # seconds. findtime = 600 # "maxretry" is the number of failures before a host get banned. maxretry = 3 [ssh-iptables] enabled = true filter = sshd action = iptables[name=SSH, port=2222, protocol=tcp] logpath = /var/log/secure maxretry = 3
- Pour démarrer fail2ban :
# service fail2ban start
- Pour le redémarrage, suite à une modif par exemple :
# service fail2ban restart
Debug Fail2ban, quelques exemples
Il arrive, selon la distribution que vous utilisez, que fail2ban ne fonctionne pas du premier coup. Voici quelques causes basiques parmi les plus fréquentes.
- Indiquer le bon fichier de log
Sous CentOS / RedHat, les erreurs (échecs) de connexion SSH apparaissent dans le fichier log "/var/log/secure". C'est celui qui est déclaré dans nos fichiers d'exemples.
Sous Ubuntu, c'est dans "/var/log/auth.log" que vous trouverez les erreurs liées aux échecs SSH, il faudra donc corriger si vous êtes dans ce cas.
- Pour protéger d'autres services comme apache ou ftp, il faudra procéder de la même manière. C'est à dire trouver le fichier de "logs" correspondant (ci dessus c'est pour le SSH. Pour apache, ce doit être quelque part dans /var/log/apache2/..)
- Fail2ban utilise "Iptables". Donc si vous l'avez désactivé, ça risque de poser souci..
- Fail2ban possède son propre fichier de "logs" (/var/log/fail2ban.log), dans lequel il indique ses propres activités. En cas de souci, ce fichier peut aider à débugger.. A ne surtout pas confondre avec ceux décrits plus haut.
- Vous pouvez, à tout instant connaître les ip bloquées par Fail2ban, via la commande iptables suivante (cherchez "chain fail2ban-SSH" pour les exemples décris dans cette page ) :
# iptables -v -L
- Il est également possible de libérer une ip bloquée par fail2ban. Toujours en suivant nos exemples, pour l'accès SSH, Fail2ban utilise la chaine iptables "fail2ban-SSH". Pour libérer l'ip 12.12.12.12 (c'est un exemple) :
# iptables -D fail2ban-SSH -s 12.12.12.12 -j DROP
Sources et liens utiles :
- La FAQ de Fail2ban (en Français)
- Un wiki assez complet sur Fail2ban chez les copains Debian (en Français)
Vous pouvez commenter ou participer à l'amélioration de cet article via le topic dédié du forum.