La fin du brute-force SSH sur le Cloud avec Fail2Ban

Il existe beaucoup de mythes sur la sécurité dans le cloud.
Pourquoi le cloud garde t-il cette étiquette d’insécurité, alors que les CSP collectionnent les certifications ?
Un point très méconnu : vous êtes responsable de la sécurité des systèmes d’exploitation, alors que les CSP assurent la sécurité du IaaS.

Charge à vous de mettre à jour les systèmes d’exploitation et de filtrer les connexions à vos machines.
Lorsque vous lancez une instance dans le Cloud, le CSP vous fournit une IP publique pour s’y connecter.
Ces plages d’IP sont connues de tous et donc des attaquants cherchant à prendre le contrôle de machines pour faire grossir un botnet.
Ces attaques se font principalement par attaques de type brute-force en testant des couples login – mot de passe via SSH.

Sur une instance d’un grand fournisseur de IaaS, ce sont quasiment 1000 IPs différentes par jour initiant des dizaines de connexions.
Vous pouvez le constater sur une de vos machines en utilisant la commande : lastb

• La première recommandation est d’utiliser un système d’authentification par certificat plus que par mot de passe.
• La deuxième recommandation est de mettre en place un système pour mitiger ces attaques.

Pour limiter les tentatives d’intrusion vous pouvez installer le logiciel fail2ban.
fail2ban scrute les logs système pour détecter les connexions échouées et déclencher une action, comme un blocage de l’IP au niveau du pare-feu par exemple.

Installer de Fail2ban

Rien de plus simple :

sudo SUSEConnect -p PackageHub/15.1/x86_64
sudo zypper -n in fail2ban firewalld

Configuration de Fail2ban

fail2ban est fourni avec des dizaines de configuration déjà prêtes.
Il suffit de créer un fichier jail.local dans lequel on active les services souhaités.

Mon exemple ci-dessous, après 2 échecs de connexions, l’IP est bannie au niveau de firewalld pour 1 heure.

$ cat /etc/fail2ban/jail.local
[DEFAULT]
bantime = 1h
banaction = firewallcmd-ipset
maxretry = 2

[sshd]
enabled = true

Lancement des services

Là encore une opération très simple pour activer et lancer les services :

sudo systemctl start firewalld
sudo systemctl enable firewalld

sudo systemctl start fail2ban
sudo systemctl enable fail2ban

Vérifier l’état de Fail2ban

fail2ban vient avec une commande pour vérifier l’état du blocage actuel et l’historique du nombre de blocage.

$ sudo fail2ban-client status
 Status
 |- Number of jail: 1
 `- Jail list: sshd

$ sudo fail2ban-client status sshd
 Status for the jail: sshd
 |- Filter
 | |- Currently failed: 1
 | |- Total failed: 238
 | `- Journal matches: _SYSTEMD_UNIT=sshd.service + _COMM=sshd
 `- Actions
 |- Currently banned: 29
 |- Total banned: 120
 `- Banned IP list: [...]

J’ai choisi l’utilisation de l’action firewalld-ipset pour bloquer les IP des attaquants.
La combinaison de ces deux outils permet d’avoir une liste de règle firewall plus lisible.

Au lieu d’avoir une règle par IP bloquée, une seule règle fait référence à un groupe d’IP.
Ce groupe d’IP gérer par ipset est bien plus performant au niveau noyau.

$ sudo firewall-cmd --direct --get-all-rules
 ipv4 filter INPUT_direct 0 -p tcp -m multiport --dports ssh -m set \
 --match-set f2b-sshd src -j REJECT --reject-with icmp-port-unreachable

$ sudo ipset list f2b-sshd
 Name: f2b-sshd
 Type: hash:ip
 Revision: 4
 Header: family inet hashsize 1024 maxelem 65536 timeout 3600
 Size in memory: 5464
 References: 1
 Number of entries: 27
 Members:
 [...]

Et voilà : un soucis de moins à se faire.
fail2ban a également la capacité à bloquer des IP sur des échecs d’authentification venant d’autres services comme web (httpd, nginx) ou email (postfix, sendmail).

Il est même possible de remonter les IP malveillantes à des services comme : AbuseIPDB
https://www.abuseipdb.com/fail2ban.html