Serveur OpenSSH sous Linux : Manuel de configuration pour une sécurité maximale

D’autres caractéristiques fondamentales de SSH sont qu’il nous permettra de copier en toute sécurité des données, à la fois des fichiers et des dossiers, via le protocole SFTP (SSH FTP), un protocole créé à partir de zéro et qui n’a rien à voir avec FTPS ou FTPES (FTP sur SSL / TLS). Le protocole SSH est essentiel dans le domaine des réseaux et des systèmes, de plus, nous pouvons le configurer en détail pour fournir à notre système la sécurité maximale possible.

Le protocole SSH assure la confidentialité (les données sont cryptées point à point), l’ authentification (on peut s’authentifier devant le serveur SSH de multiples façons, avec utilisateur/clé, la cryptographie à clé publique et on peut même configurer un deuxième facteur d’authentification), l’ intégrité (oui, les données en cours de modification ou de modification par un utilisateur malveillant peuvent être détectées car il utilise HMAC pour vérifier l’intégrité de chaque donnée).

Il existe deux versions de SSH, la version 1 n’est pas recommandée aujourd’hui, en fait, par défaut la version SSHv2 est toujours utilisée. Par défaut, SSH utilise le protocole TCP de la couche de transport, et le numéro de port est 22, cependant, nous pouvons modifier le numéro de port pour atténuer les éventuelles analyses de bot vers le service SSH.

Dans ce manuel que nous présentons aujourd’hui, nous allons vous apprendre à configurer le serveur OpenSSH SSH, un programme disponible pour les systèmes d’exploitation basés sur Unix et Linux, tels que FreeBSD, OpenBSD, Debian, Red Hat Enterprise Linux et un longue etc. de distributions. Dans ce guide, nous apprendrons non seulement à configurer correctement le fichier de configuration sshd_config, mais nous utiliserons également des programmes supplémentaires pour fournir au système la sécurité maximale possible. Dans ce manuel, toutes les configurations seront effectuées avec Debian, cependant, toutes les mesures de sécurité peuvent être implémentées dans n’importe quel système d’exploitation basé sur Linux et Unix.

Installation et démarrage d’OpenSSH

OpenSSH est le programme serveur/client SSH le plus utilisé par les routeurs, les commutateurs, les serveurs et une longue liste d’appareils. Ce programme est entièrement gratuit et open source. L’ installation de ce serveur SSH (si vous ne l’avez pas déjà installé par défaut) est très simple, il suffit de mettre la commande suivante dans un terminal :

sudo apt install openssh-server

Une fois installé, il faut prendre en compte certains répertoires et commandes pour démarrer, arrêter et redémarrer le service SSH.

Pour éditer la configuration du serveur SSH nous devons faire en console :

sudo nano /etc/ssh/sshd_config

Un autre répertoire que nous devons prendre en compte est celui des hôtes connus, puisque c’est également là que nous allons configurer les clés cryptographiques RSA/DSA. Le répertoire où se trouvent les hôtes connus et les clés publiques est le suivant :

/home/usuario/.ssh/

Ce répertoire par défaut est masqué (.ssh) et il existe un répertoire pour chaque utilisateur qui se trouve dans le système d’exploitation et qui se connecte à un serveur distant.

Pour démarrer le serveur :

sudo /etc/init.d/ssh start

Pour arrêter le serveur :

sudo /etc/init.d/ssh stop

Pour redémarrer le serveur :

sudo /etc/init.d/ssh restart

Une fois qu’on a installé le serveur SSH, on sait où se trouvent les fichiers de configuration du serveur et le répertoire où sont stockées les clés publiques, on passe à la configuration du sshd_config puisque c’est le fichier de configuration fondamental d’OpenSSH.

Configuration Sshd_config pour une sécurité maximale

Changer le port par défaut du serveur SSH

Par défaut, les serveurs SSH utilisent le port 22 pour les connexions. Il est conseillé de changer ce numéro de port, pour empêcher les bots ou les cybercriminels d’essayer de se connecter, bien que cela à lui seul n’assure pas la sécurité, nous pouvons passer inaperçus par des scans massifs à partir d’Internet. Si, par exemple, nous voulons utiliser le port 22445, nous devons mettre ce qui suit dans le fichier de configuration :

• Port 22445

Bloquer l’accès root sur les connexions à distance

Par défaut, tout utilisateur du système d’exploitation disposant des autorisations Shell pourra se connecter au serveur. De plus, nous devons garder à l’esprit que si nous avons activé l’utilisateur root, il pourra également se connecter au serveur localement ou à distance, évitant ainsi à l’attaquant d’avoir à «deviner» le nom d’utilisateur. Par défaut, les bots essaient toujours d’attaquer le port 22 et l’utilisateur «root».

En désactivant l’utilisateur root lui-même et en utilisant «sudo» pour élever les autorisations de superutilisateur, nous éviterons cela. De plus, OpenSSH nous permettra également de désactiver la connexion de l’utilisateur root pour fournir au système une plus grande sécurité :

• PermitRootLogin non

De cette façon, les connexions root seront bloquées, empêchant les utilisateurs non autorisés d’effectuer des attaques par force brute contre notre serveur SSH pour deviner les informations d’identification de l’utilisateur root. Nous avons également d’autres options dans cette section, telles que » PermitRootLogin sans mot de passe » où l’authentification est autorisée mais pas avec nom d’utilisateur et mot de passe, mais avec des clés cryptographiques RSA.

Paramètres de sécurité supplémentaires

Il existe d’autres configurations recommandées pour éviter les connexions indésirables à notre serveur SSH. Ces connexions sont :

• LoginGraceTime : Nous établirons le temps nécessaire pour saisir le mot de passe, évitant que l’attaquant n’ait à «réfléchir».
• MaxAuthTries : Nombre de tentatives autorisées lors de la saisie du mot de passe avant la déconnexion.
• MaxStartups : Nombre de connexions simultanées depuis une IP, pour éviter d’utiliser la force brute avec plusieurs sessions en même temps.
• AllowUsers : Il s’agit de créer une liste blanche d’utilisateurs. Ce paramètre nous permet de configurer les utilisateurs qui pourront se connecter. Une mesure très restrictive mais en même temps très sécurisante puisqu’elle bloquera toutes les connexions des utilisateurs qui ne sont pas dans la liste. Les utilisateurs que nous avons ici pourront se connecter, et les autres non.
• DenyUsers : Similaire au précédent, mais maintenant nous créons une liste noire. Les utilisateurs que nous avons ici ne pourront pas se connecter, et les autres le seront.
• AllowGroups / DenyUsers : Exactement le même que ci-dessus, mais au lieu de créer une liste noire/blanche d’utilisateurs, ce sont des groupes d’utilisateurs.

Par exemple, un fichier de configuration pour sshd_config serait le suivant :

Port 22445
PermitRootLogin no
LoginGraceTime 30
MaxAuthTries 3
MaxStartups 3
AllowUsers sergio sergio2
DenyUsers adrian adrian2

Une mesure de sécurité supplémentaire consiste à configurer les algorithmes d’échange de clés, le cryptage symétrique, ainsi que la configuration HMAC pour la vérification d’intégrité. Actuellement il est recommandé d’appliquer la configuration suivante pour avoir une très haute sécurité :

KexAlgorithms [email protected],ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
MACs [email protected],[email protected],[email protected],hmac-sha2-512,hmac-sha2-256,[email protected]

Avec cette configuration, nous aurons les meilleures suites cryptographiques pour le serveur, cependant, il est possible que les anciens clients ne puissent pas se connecter car ils ne prennent pas en charge ces algorithmes. Nous devons tenir compte de ce détail et tester quels algorithmes sont compatibles et lesquels ne le sont pas.

Si nous avons créé de nouvelles clés RSA ou DSA pour celles avec une plus grande longueur de bit, nous devons la mettre dans le fichier de configuration (ou remplacer les précédentes, et ainsi nous n’aurons pas à toucher le fichier de configuration), de cette façon nous obtiendrons sécurité supplémentaire si par exemple nous utilisons des clés RSA de 4096 bits ou plus.

HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key

Pour générer de nouvelles clés RSA 4096 bits, il suffit d’exécuter la commande suivante :

ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -b 4096

Si nous voulons générer de nouvelles clés ECDSA (d’une longueur maximale de 512 bits) ou ED25519, nous devrons entrer les commandes suivantes :

ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key -t ecdsa -b 521
ssh-keygen -f /etc/ssh/ssh_host_ed25519_key -t ed25519

Authentification en SSH : Tous les modes expliqués en détail

Dans cette section, nous allons vous montrer les différentes méthodes d’authentification dont nous disposons sur le serveur. Normalement, nous avons principalement deux méthodes : le nom d’utilisateur et le mot de passe (quelque chose que nous savons), et aussi avec des clés cryptographiques (quelque chose que nous avons). Cependant, nous pouvons fournir au système une sécurité supplémentaire, en combinant ces authentifications avec, par exemple, un mot de passe à usage unique généré par une application telle que Google Authenticator ou Latch OTP. De plus, nous pouvons également fournir le système Latch, pour empêcher tout utilisateur de se connecter si nous n’avons pas le «latch» ouvert.

Utilisateur et mot de passe

Si nous voulons activer la connexion au service via le nom d’utilisateur et le mot de passe du système, le fichier de configuration doit avoir cette déclaration :

• Mot de passeAuthentification oui

Sinon, si nous voulons empêcher l’authentification par nom d’utilisateur / mot de passe, et autoriser uniquement les connexions via des clés cryptographiques, nous devons indiquer non :

• Mot de passeAuthentification non

Cette phrase concerne tous les utilisateurs du système. Afin de ne pas perdre l’accès au serveur, nous devons nous assurer que la déclaration  PubkeyAuthentication est définie sur «yes», pour permettre la connexion avec des clés cryptographiques.

Il y a une autre phrase liée à cela appelée ChallengeResponseAuthentication , si nous définissons la configuration sur «non», cela n’autorisera pas les connexions avec lesquelles le clavier est interagi, donc si par exemple nous avons un mot de passe à usage unique configuré, nous ne pourrons pas connectez-vous au système. Si nous n’utilisons que des clés cryptographiques, vous pouvez le définir sur «non» sans problème.

Clé publique SSH

Pour configurer l’accès par clé publique au serveur, nous devons définir la déclaration suivante sur « oui » :

• Authentification Pubkey oui

C’est ainsi que nous activons la configuration avec la clé publique SSH dans le système, cependant, nous devons encore effectuer certaines étapes pour pouvoir nous connecter à ce serveur, à savoir transmettre la clé publique à l’ordinateur lui-même. Pour ce faire, nous devons autoriser (pour le moment) l’authentification avec nom d’utilisateur / mot de passe, une fois toutes les étapes terminées, nous pouvons refuser l’authentification avec nom d’utilisateur et mot de passe sans aucun problème.

Depuis l’ordinateur sur lequel nous voulons nous connecter au serveur avec des clés cryptographiques, nous devons créer ces clés et les transmettre au serveur. Pour créer des clés RSA de 4096 bits nous devons mettre la commande suivante dans le client SSH :

ssh-keygen -t rsa -b 4096

Dans l’assistant de génération de ces clés, il nous dira si nous voulons les enregistrer dans /home/usuario/.ssh/id_rsa, nous disons oui. Plus tard, cela nous permettra de mettre un mot de passe pass-through à la clé privée, de cette façon, si nous perdons la clé privée, rien ne se passera car ils ne pourront pas se connecter, car il faut toujours entrer un pass -word pour pouvoir faire la connexion correctement.

Une fois que nous avons créé la clé publique et privée sur notre ordinateur, nous devons envoyer la clé publique au serveur SSH où nous voulons nous connecter, attention : la clé publique.

ssh-copy-id usuario@IP_servidor

La clé publique sera automatiquement copiée sur ledit serveur, et nous pourrons activer l’authentification avec uniquement la clé publique et nous nous serons automatiquement enregistrés. La sortie offerte par cette commande devrait ressembler à ceci :

The authenticity of host '12.34.56.78 (12.34.56.78)' can't be established.
RSA key fingerprint is b1:2d:33:67:ce:35:4d:5f:f3:a8:cd:c0:c4:48:86:12.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '12.34.56.78' (RSA) to the list of known hosts.
[email protected]'s password:
Now try logging into the machine, with "ssh '[email protected]'", and check in:
~/.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.

Dans cette sortie, l’utilisateur doit confirmer qu’il souhaite ajouter l’identité et saisir les informations de connexion pour le compte qu’il souhaite utiliser dans ce service. Pour cette raison, il est important que sur le serveur, nous maintenions toujours la possibilité de s’authentifier avec le nom d’utilisateur / mot de passe. Une fois ce processus terminé, nous devrions pouvoir nous connecter à cet ordinateur sans entrer le mot de passe :

ssh usuario@IP

N’oubliez pas de définir la directive «PasswordAuthentication no» pour ne pas autoriser l’accès via le nom d’utilisateur et le mot de passe.

Utilisateur et mot de passe avec un mot de passe à usage unique (Google Authenticator ou Latch OTP)

Dans cette partie du manuel, nous allons nous authentifier avec le nom d’utilisateur/mot de passe habituel, mais aussi, nous devons utiliser un OTP avec Google Authenticator ou Latch OTP pour entrer dans la session. C’est-à-dire que nous fournirons au serveur SSH une vérification en deux étapes.

La première chose que nous devons faire est d’installer une série de dépendances nécessaires pour configurer la double authentification sur notre serveur SSH. Pour ce faire, nous allons ouvrir un terminal et taper :

sudo apt install libpam0g-dev make gcc wget ssh

Une fois les dépendances installées dans notre système, nous pouvons télécharger le logiciel de double authentification.

sudo apt install libpam-google-authenticator

Nous avons déjà Google Authenticator installé dans notre système d’exploitation. Les prochaines étapes à suivre sont la configuration de l’outil pour pouvoir l’utiliser dans notre SSH.

Pour commencer la configuration de Google Authenticator il suffit de taper dans le terminal :

google-authenticator

REMARQUE : exécutez-le sans les autorisations root (sudo), c’est-à-dire exécutez-le en tant qu’utilisateur «normal». Si vous l’exécutez en tant que root, Google Auth ne sera disponible qu’en root lui-même, et le désactiver en SSH lui-même ne fera rien.

Ensuite, nous verrons un simple assistant du terminal. La première chose qu’il nous demandera est si nous voulons que nos jetons d’accès soient basés sur le temps. Ensuite, nous verrons la clé privée, la clé de vérification et les codes d’urgence si nous n’avons pas notre téléphone portable à portée de main. Nous devons conserver toutes ces données en toute sécurité afin de pouvoir récupérer l’accès en cas de perte de la clé d’authentification.

Ensuite, nous lui disons d’enregistrer les modifications du fichier dans notre dossier / home et il nous demandera si nous voulons que chaque token ne soit utilisé qu’une seule fois, même si cela limite une connexion toutes les 30 secondes. Pour nous protéger contre d’éventuelles attaques MITM, nous sélectionnons oui. Enfin, il nous demandera si nous souhaitons prolonger la période de validité de chaque code au lieu de seulement 1 minute et 30 secondes (pour éviter les problèmes de synchronisation de l’heure). Pour éviter les attaques par force brute, nous pouvons également limiter les connexions à 3 toutes les 30 secondes.

La numérisation du code QR ou la saisie manuelle du code peuvent être effectuées dans des programmes tels que Google Authenticator, Authy, Latch, etc. Nous vous recommandons d’utiliser Google Authenticator ou Latch.

La prochaine étape que nous devons faire est d’ouvrir le fichier de configuration «sshd» pour lui dire d’utiliser ce module pour la connexion. Pour ce faire, nous pouvons faire un «clear» pour effacer le terminal et taper:

sudo nano /etc/pam.d/sshd

Et nous ajouterons la ligne suivante à la fin du fichier :

auth required pam_google_authenticator.so

Nous enregistrons les modifications et ouvrons le fichier sshd_config avec la commande suivante :

sudo nano /etc/ssh/sshd_config

Et on change la ligne «ChallengeResponseAuthentication no» en «ChallengeResponseAuthentication yes».

Nous redémarrons le serveur avec «sudo /etc/init.d/ssh restart» et une fois qu’il redémarrera, nous aurons l’authentification en deux étapes activée.

Une fois cela fait, avec la connexion, il nous demandera également un mot de passe à usage unique, le code généré par notre application mobile.

Clé publique SSH avec mot de passe à usage unique (Google Authenticator ou Latch OTP)

La configuration au niveau de la clé publique doit être exactement la même qu’auparavant, ainsi qu’au niveau de l’installation et de la configuration de Google Authenticator. La seule différence est que dans le fichier sshd_config nous devons avoir quelque chose comme ceci :

PasswordAuthentication no
ChallengeResponseAuthentication yes
PubKeyAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive

Et dans le fichier /etc/pam.d/sshd nous devons avoir quelque chose comme ceci :

#@include common-auth
auth required pam_google_authenticator.so

Il est très important de mettre un dièse (#) pour commenter le @include, de cette façon, nous nous authentifierons correctement avec la clé publique plus le code OTP généré par le mobile. De cette façon, nous dirons au serveur d’accepter uniquement l’authentification par clé publique.

Latch configuration dans OpenSSH et plus tard choisir la méthode d’authentification

Latch pour OpenSSH a actuellement la limitation que nous ne pouvons l’utiliser que pour un seul utilisateur, c’est-à-dire que si nous essayons de nous connecter au serveur SSH avec plusieurs utilisateurs, nous ne pourrons pas protéger notre équipe avec Latch car c’est limité à un seul. Nous vous recommandons d’ accéder au site officiel du plugin Latch pour Unix sur GitHub , vous y trouverez le manuel étape par étape pour le configurer correctement avec le service SSH si vous êtes intéressé. Il faut se rappeler qu’il ne permet de jumeler qu’un seul utilisateur.

Mesures de sécurité supplémentaires : pare-feu, port-knocking, fail2ban et DenyHosts

Dans cette section, nous allons utiliser un logiciel supplémentaire pour protéger le serveur SSH, car il est essentiel d’avoir une sécurité supplémentaire. Nous utiliserons à la fois le pare-feu basé sur iptables, tel que le port-knocking pour toujours cacher le service derrière le pare-feu, ainsi que fail2bat et DenyHost pour détecter d’éventuelles attaques par force brute et l’arrêter avec le pare-feu.

Configuration du pare-feu Iptables pour protéger SSH

Le pare-feu iptables intégré dans la plupart des systèmes basés sur Linux nous permettra de limiter le nombre de connexions simultanées à notre serveur, et aussi, nous pourrons utiliser un module spécial appelé «récent» pour les enregistrer toutes dans une base de données. tentatives, idéal pour éviter les attaques par force brute.

Limiter le nombre de connexions simultanées dans iptables

Si un attaquant essaie de se connecter plusieurs fois à partir de la même IP, nous pouvons limiter ce nombre de connexions pour atténuer son attaque. Cela n’étouffe pas une éventuelle attaque dans l’œuf, mais l’atténue avec deux objectifs : ne pas avoir une grosse consommation mémoire et CPU sur l’ordinateur en ouvrant plusieurs connexions SSH, retarder une éventuelle attaque par force brute en ouvrant plusieurs connexions.

Cette déclaration ACCEPTE jusqu’à 5 connexions qui proviennent de la même IP publique, à partir de la sixième connexion nous la bloquons. Si nous avons plusieurs interfaces réseau, nous devons utiliser le «-i» pour mettre l’interface à laquelle nous appliquons cette règle, si nous ne mettons rien cela s’appliquera à toutes.

iptables -A INPUT -p tcp --dport 22445 -m connlimit --connlimit-upto 5 --connlimit-mask 32 -j ACCEPT

iptables -A INPUT -j DROP

Configurer le module récent pour atténuer les attaques par force brute sur le service SSH

Le module récent sert à limiter le nombre de connexions par seconde au niveau IP, c’est idéal pour nous protéger des attaques sur le port SSH car un attaquant tentera plusieurs mots de passe. Dans l’exemple suivant, nous enregistrerons toutes les connexions vers le port TCP de destination 22445 dans une base de données, et nous enregistrerons l’origine de ces connexions (l’IP publique d’un éventuel attaquant).

Par la suite, nous vérifions qu’il n’y a pas plus de 4 correspondances dans le tableau au cours des 60 dernières secondes. S’il y a plus de 4 correspondances, nous procédons au blocage de toutes les connexions à partir de là.

iptables -A INPUT -p tcp --dport 22445 -m conntrack --ctstate NEW -m recent --set --name ssh --rsource

iptables -A INPUT -p tcp --dport 22445 -m conntrack --ctstate NEW -m recent --rcheck --seconds 60 --hitcount 4 --name ssh --rsource -j DROP

Ce module diffère du précédent, en ce qu’il vérifie ces connexions dans le temps. Normalement pour protéger le service SSH il vaut mieux utiliser ce module récent que le précédent.

Port-Knocking pour «cacher» le service SSH

Le port knocking est une méthode discrète d’ouverture de ports que, par défaut, le pare-feu maintient fermé. Il fonctionne en exigeant des tentatives de connexion à une série de ports prédéfinis fermés. Lorsque la séquence correcte de «touches» de port (tentatives de connexion) est reçue, le pare-feu ouvre alors un ou plusieurs port(s). L’avantage est que dans une analyse de port normale, il semblerait que le service de port ne soit tout simplement pas disponible.

Port Knocking est une application, qui par défaut n’est pas installée dans les systèmes d’exploitation, vous pouvez l’installer via les référentiels officiels. Dans notre cas, lors de l’utilisation de Debian 9, l’installation ressemblerait à ceci :

sudo apt-get install knockd

Une fois installé, il faut l’activer en éditant :

sudo nano /etc/default/knockd

Et mettre : START_KNOCKD = 1

Ensuite, nous démarrons le service :

sudo service knockd start

Le fichier de configuration knockd est dans /etc/knockd.conf

Nous devons l’éditer avec n’importe quel éditeur de fichiers, les autorisations root nécessaires. Le fichier ressemblera à ceci :

[options] UseSyslog

[openSSH] sequence = 7000,8000,9000
seq_timeout = 5
command = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22445 -j ACCEPT
tcpflags = syn

[closeSSH] sequence = 9000,8000,7000
seq_timeout = 5
command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22445 -j ACCEPT
tcpflags = syn

Et pour «ouvrir» le port du service SSH, il faut mettre dans la console «knock IP_address 7000 8000 9000». Une fois que nous avons utilisé le service, nous pouvons le fermer avec la déclaration que nous avons précédemment placée dans le fichier de configuration, cela ne doit pas nécessairement être l’inverse (cela dépend de la façon dont vous avez configuré le fichier ci-dessus).

Une autre option que nous avons dans Port Knocking est le déblocage temporaire du serveur, de cette façon, nous ouvrirons le port pendant 10 secondes (ou ce que vous voulez), et c’est à ce moment-là que nous devrons nous connecter au service. Plus tard, le port sera fermé et si nous sommes connectés, il ne nous expulsera pas de ce serveur.

[options] UseSyslog

[SSH] sequence = 5438,3428,3280,4479
tcpflags = syn
seq_timeout = 15
start_command = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22445 -j ACCEPT
cmd_timeout = 10
stop_command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22445 -j ACCEPT

De cette façon, lorsque nous quitterons le serveur, nous n’aurons pas à «fermer» la porte comme dans le cas précédent, puisqu’elle n’est ouverte que depuis 10 secondes.

Fail2ban pour atténuer les attaques par force brute sur SSH

Nous pouvons également installer le programme fail2ban pour bannir les IP qui font de nombreuses tentatives de connexion infructueuses (qui se trompent de mot de passe). Ce programme est bien connu et utilisé, car il est très facile à configurer et à lancer. Nous pouvons l’installer en mettant

sudo apt install fail2ban

Maintenant, nous copions le fichier .conf dans le même fichier .local pour que cette configuration s’applique :

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Maintenant, nous pouvons créer avec fail2ban une règle personnalisée pour SSH, nous créons un nouveau fichier de configuration qui sera chargé d’écraser le fichier principal jail.local précédent.

sudo nano /etc/fail2ban/jail.d/sshjail.local

Et on colle ça :

[sshd] enabled = true
port = 22445
bantime = 3600
findtime = 600
filter = sshd
maxretry = 3

Et nous le démarrons, l’arrêtons et le redémarrons en faisant comme s’il s’agissait du SSH, dans ce cas start = start :

sudo /etc/init.d/fail2ban restart

Pour voir les LOGS de connexion, vous devrez regarder le chemin /var/log/auth.log, et pour voir les logs fail2ban vous devez les regarder ici : /var/log/fail2ban.log

DenyHosts : comme fail2ban mais spécifiquement orienté vers SSH

Nous avons également un autre programme dédié exclusivement à SSH, il s’appelle DenyHost et il possède une grande base de données d’adresses IP connues sous le nom d’attaquants. C’est une autre solution aux attaques possibles si nous avons toujours notre serveur SSH exposé à Internet. DenyHosts fonctionne de la même manière que fail2ban, il surveille les journaux de connexion pour détecter si nous sommes confrontés à une attaque par force brute, et il vérifie également les bases de données IP pour détecter s’il s’agit de botnets.

Pour installer ce programme, nous devrons le faire à partir des référentiels officiels, nous supposons que dans /etc/apt/source.list :

sudo apt install denyhosts

La première partie de la configuration se fait dans le chemin /etc/hosts.allow, ici il va falloir mettre la liste blanche avec nos ordinateurs pour qu’elle ne nous bloque jamais, c’est indispensable pour ne pas se bloquer à travers le firewall, surtout si vous utilisez un serveur distant, il est vraiment important de faire cette étape.

sudo nano /etc/hosts.allow

La syntaxe à utiliser est la suivante :

sshd: DIRECCION_IP

Par exemple, avec cela, vous autoriseriez trois adresses IP sources :

sshd: 192.168.1.2

sshd: 192.168.1.3

sshd: 192.168.1.4

Nous sauvegardons pour appliquer les modifications, et maintenant nous devrons éditer le fichier de configuration global DenyHosts :

sudo nano /etc/denyhosts.conf

Dans ce fichier de configuration, nous verrons les différentes options de configuration disponibles, la syntaxe est très similaire à Fail2ban, vous n’aurez donc pas de problèmes lors de sa configuration.

Pam_tally2 : une autre alternative hautement recommandée

Cet outil est également très similaire aux précédents, il remplit exactement la même fonction : gérer les tentatives infructueuses sur le serveur SSH. Ce programme nous permettra de compter les tentatives d’accès de différents utilisateurs avec leurs adresses IP source correspondantes, s’il y a trop de tentatives de connexion infructueuses, ils se verront automatiquement refuser l’accès via le pare-feu. Cet outil comporte deux parties, le pam_tally2.so qui est le module PAM que nous pouvons configurer dans notre système d’exploitation Linux, et nous aurons également le pam_tally2 qui est le programme lui-même.

Enfin, le programme SSHGuard est également fortement recommandé pour protéger adéquatement notre serveur SSH contre les tentatives d’intrusion.

Comment vérifier la sécurité de mon serveur SSH

Aujourd’hui, nous disposons de plusieurs outils pour vérifier la sécurité de notre serveur OpenSSH que nous venons de configurer, ces programmes seront chargés d’analyser la configuration du serveur en établissant des connexions au serveur, afin de détecter un type de configuration incorrecte ou dangereuse. Certains des programmes les plus recommandés sont Rebex SSH Check qui est un scanner en ligne hautement recommandé, en outre, nous avons également ssh-audit qui est un outil qui est installé localement où le serveur SSH doit vérifier la sécurité du serveur.

Jusqu’à présent, nous avons fourni ce manuel sur la façon de configurer en détail le service SSH sur notre serveur. Si vous avez des questions, vous pouvez commenter et nous serons ravis de vous répondre.