Habib M’henni / Wikimedia Commons, CC BY-SA

De nos jours, mettre en place un serveur sur un hébergement ne prend que quelques minutes et quelques clics de souris. Mais juste après son lancement, il se retrouve dans un environnement hostile, car il est ouvert à tout Internet comme une jeune fille innocente dans une disco rock. Il sera rapidement repéré par des scanners et constaté par des milliers de bots automatiques qui parcourent le web à la recherche de vulnérabilités et de configurations incorrectes. Il y a plusieurs actions à entreprendre immédiatement après le lancement pour assurer une protection de base.

Contenu

• Utilisateur non-root
• Clés au lieu de mots de passe SSH
• Pare-feu
• Fail2Ban
• Mises à jour de sécurité automatiques
• Changement des ports par défaut

Utilisateur non-root

La première étape consiste à créer un utilisateur non-root. En effet, un utilisateur root a des privilèges absolus dans le système, et si vous lui autorisez l'administration à distance, vous ferez la moitié du travail d'un hacker en lui laissant un nom d'utilisateur valide.

C'est pourquoi il est nécessaire de créer un autre utilisateur et de désactiver l'administration à distance pour le root via SSH.

Le nouvel utilisateur est créé avec la commande useradd:

useradd [options]

Ensuite, un mot de passe lui est attribué avec la commande passwd:

passwd

Enfin, cet utilisateur doit être ajouté à un groupe ayant le droit d'exécuter des commandes avec élévation de privilèges sudo. En fonction de la distribution Linux, cela peut varier. Par exemple, sur CentOS et Red Hat, l'utilisateur est ajouté au groupe wheel:

usermod -aG wheel

Sur Ubuntu, il est ajouté au groupe sudo:

usermod -aG sudo

Clés au lieu de mots de passe SSH

Les attaques par brute force ou les fuites de mots de passe sont des vecteurs d'attaque standard, il est donc préférable de désactiver l'authentification par mot de passe sur SSH (Secure Shell) et d'utiliser à la place l'authentification par clés.

Il existe plusieurs programmes pour mettre en œuvre le protocole SSH, comme lsh et Dropbear, mais le plus populaire est OpenSSH. Installation du client OpenSSH sur Ubuntu :

sudo apt install openssh-client

Installation sur le serveur :

sudo apt install openssh-server

Démarrage du démon SSH (sshd) sur le serveur Ubuntu :

sudo systemctl start sshd

Démarrage automatique du démon à chaque chargement :

sudo systemctl enable sshd

Il est à noter que la partie serveur d'OpenSSH inclut le client. C'est-à-dire via openssh-server vous pouvez vous connecter à d'autres serveurs. De plus, depuis votre machine cliente, vous pouvez créer un tunnel SSH depuis le serveur distant vers un hôte externe, et cet hôte extérieur considérera le serveur distant comme la source des requêtes. Une fonctionnalité très pratique pour masquer votre système. Voir l'article pour plus de détails «Conseils pratiques, exemples et tunnels SSH».

Il n'est généralement pas nécessaire d'installer un serveur complet sur la machine cliente afin d'éviter la possibilité de connexion distante à l'ordinateur (pour des raisons de sécurité).

Ainsi, pour votre nouvel utilisateur, vous devez d'abord générer des clés SSH sur l'ordinateur à partir duquel vous vous connecterez au serveur:

ssh-keygen -t rsa

La clé publique est stockée dans un fichier .pub et ressemble à une chaîne de caractères aléatoires commençant par ssh-rsa.

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ3GIJzTX7J6zsCrywcjAM/7Kq3O9ZIvDw2OFOSXAFVqilSFNkHlefm1iMtPeqsIBp2t9cbGUf55xNDULz/bD/4BCV43yZ5lh0cUYuXALg9NI29ui7PEGReXjSpNwUD6ceN/78YOK41KAcecq+SS0bJ4b4amKZIJG3JWm49NWvoo0hdM71sblF956IXY3cRLcTjPlQ84mChKL1X7+D645c7O4Z1N3KtL7l5nVKSG81ejkeZsGFzJFNqvr5DuHdDL5FAudW23me3BDmrM9ifUmt1a00mWci/1qUlaVFft085yvVq7KZbF2OP2NQACUkwfwh+iSTP username@hostname

Ensuite, sous root, créez un répertoire SSH dans le répertoire personnel de l'utilisateur sur le serveur et ajoutez la clé publique SSH dans le fichier authorized_keys, en utilisant un éditeur de texte comme Vim:

mkdir -p /home/user_name/.ssh && touch /home/user_name/.ssh/authorized_keys

vim /home/user_name/.ssh/authorized_keys

Enfin, définissez les permissions correctes pour le fichier:

chmod 700 /home/user_name/.ssh && chmod 600 /home/user_name/.ssh/authorized_keys

et changez la propriété de ce répertoire à cet utilisateur:

chown -R username:username /home/username/.ssh

Du côté client, vous devez spécifier l'emplacement de la clé secrète pour l'authentification:

ssh-add DIR_PATH/keylocation

Vous pouvez maintenant vous connecter au serveur sous le nom de l'utilisateur avec cette clé:

ssh [username]@hostname

Après autorisation, vous pouvez utiliser la commande scp pour copier des fichiers, ainsi que l'outil sshfs pour le montage à distance des systèmes de fichiers ou des répertoires.

Il est conseillé de faire plusieurs copies de sauvegarde de la clé privée, car si vous désactivez l'authentification par mot de passe et que vous la perdez, vous n'aurez absolument aucun moyen d'accéder à votre serveur.

Comme mentionné précédemment, il faut désactiver l'authentification pour root (c'est pourquoi nous avons créé un nouvel utilisateur).

Sous CentOS/Red Hat, recherchez la ligne PermitRootLogin yes dans le fichier de configuration /etc/ssh/sshd_config et modifiez-la:

PermitRootLogin no

Sous Ubuntu, ajoutez une ligne PermitRootLogin no dans le fichier de configuration 10-my-sshd-settings.conf:

sudo echo "PermitRootLogin no" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf

Après avoir vérifié que le nouvel utilisateur s'authentifie avec sa clé, vous pouvez désactiver l'authentification par mot de passe afin d'éliminer le risque d'extraction ou de brute force. Maintenant, pour accéder au serveur, un attaquant devra obtenir la clé privée.

Sous CentOS/Red Hat, recherchez la ligne PasswordAuthentication yes dans le fichier de configuration /etc/ssh/sshd_config et nous la modifions comme suit :

PasswordAuthentication no

Sous Ubuntu, ajoutez une ligne PasswordAuthentication no dans le fichier 10-my-sshd-settings.conf:

sudo echo "PasswordAuthentication no" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf

Pour un guide sur la connexion avec l'authentification à deux facteurs via SSH, voir ici.

Pare-feu

Le pare-feu garantit que seul le trafic sur les ports que vous avez explicitement autorisés atteindra le serveur. Cela protège contre l'exploitation des ports qui se sont accidentellement activés avec d'autres services, réduisant ainsi considérablement la surface d'attaque.

Avant d'installer le pare-feu, veillez à ce que SSH figure sur la liste des exceptions et ne soit pas bloqué. Sinon, après le démarrage du pare-feu, nous ne pourrons pas nous connecter au serveur.

Le système Ubuntu est livré avec Uncomplicated Firewall (ufw), tandis qu'avec CentOS/Red Hat — firewalld.

Autorisation de SSH dans le pare-feu sur Ubuntu :

sudo ufw allow ssh

Sur CentOS/Red Hat, utilisez la commande firewall-cmd:

sudo firewall-cmd --zone=public --add-service=ssh --permanent

Après cette procédure, vous pouvez démarrer le pare-feu.

Sur CentOS/Red Hat, démarrez le service systemd pour firewalld :

sudo systemctl start firewalld
sudo systemctl enable firewalld

Sur Ubuntu, utilisez cette commande :

sudo ufw enable

Fail2Ban

Service Fail2Ban analyse les journaux sur le serveur et compte le nombre de tentatives d'accès depuis chaque adresse IP. Dans les paramètres, des règles sont définies pour le nombre de tentatives d'accès autorisées sur un intervalle donné — après quoi cette adresse IP est bloquée pendant une période spécifiée. Par exemple, nous autorisons 5 tentatives d'authentification échouées par SSH sur une période de 2 heures, après quoi cette adresse IP est bloquée pendant 12 heures.

Installation de Fail2Ban sur CentOS et Red Hat :

sudo yum install fail2ban

Installation sur Ubuntu et Debian :

sudo apt install fail2ban

Lancement :

systemctl start fail2ban
systemctl enable fail2ban

Le programme contient deux fichiers de configuration : /etc/fail2ban/fail2ban.conf et /etc/fail2ban/jail.conf. Les restrictions pour le ban sont indiquées dans le second fichier.

Le jail pour SSH est activé par défaut avec des paramètres par défaut (5 tentatives, intervalle de 10 minutes, ban de 10 minutes).

[DEFAULT]
ignorecommand =
bantime = 10m
findtime = 10m
maxretry = 5

En plus de SSH, Fail2Ban peut également protéger d'autres services sur le serveur web nginx ou Apache.

Mises à jour de sécurité automatiques

Comme chacun sait, de nouvelles vulnérabilités sont constamment découvertes dans tous les logiciels. Après la publication des informations, des exploits sont ajoutés dans des packs d'exploits populaires, largement utilisés par des hackers et des adolescents lors du scan de tous les serveurs. Il est donc crucial d'installer les mises à jour de sécurité dès qu'elles apparaissent.

Sur un serveur Ubuntu, les mises à jour de sécurité automatiques sont activées par défaut, donc aucune action supplémentaire n'est requise.

Sur CentOS/Red Hat, il faut installer l'application dnf-automatic et activer le timer :

sudo dnf upgrade
sudo dnf install dnf-automatic -y
sudo systemctl enable --now dnf-automatic.timer

Vérification du timer :

sudo systemctl status dnf-automatic.timer

Changement des ports par défaut

SSH a été développé en 1995 pour remplacer telnet (port 23) et ftp (port 21), c'est pourquoi l'auteur du programme, Tatu Ylönen, a choisi le port 22 par défaut, et il a été approuvé par l'IANA.

Évidemment, tous les attaquants savent sur quel port fonctionne SSH — et le scanent avec les autres ports standards pour connaître la version du logiciel, vérifier les mots de passe par défaut pour root, etc.

Changer les ports standards — une forme d'obscurcissement — réduit considérablement le volume du trafic indésirable, la taille des logs et la charge sur le serveur, tout en diminuant la surface d'attaque. Bien que certains critiquent cette méthode de "protection par l'incertitude" (security through obscurity). La raison en est que cette technique s'oppose à une protection architecturale fondamentale. Ainsi, par exemple, l'Institut national des normes et de la technologie des États-Unis dans son "Guide de sécurité des serveurs" indique la nécessité d'une architecture serveur ouverte : "La sécurité du système ne doit pas reposer sur la furtivité de la mise en œuvre de ses composants", est-il écrit dans le document.

Théoriquement, changer les ports par défaut contredit la pratique de l'architecture ouverte. Mais en pratique, le volume du trafic malveillant est effectivement réduit, donc c'est une mesure simple et efficace.

Le numéro de port peut être configuré en modifiant la directive Port 22 dans le fichier de configuration /etc/ssh/sshd_config. Il est également spécifié par l'option -p dans sshd. Le client SSH et les programmes sftp supportent également cette option -p.

Paramètre -p qui peut être utilisée pour indiquer le numéro de port lors de la connexion via la commande ssh sous Linux. Dans sftp et scp il est utilisé l'option -P (titre P). L'instruction de la ligne de commande remplace toute valeur dans les fichiers de configuration.

S'il y a plusieurs serveurs, presque toutes ces actions de protection du serveur Linux peuvent être automatisées dans un script. Mais s'il n'y a qu'un seul serveur, il est préférable de contrôler le processus manuellement.

En tant que publicité

Commandez et commencez à travailler immédiatement ! Création de VDS de n'importe quelle configuration et avec n'importe quel système d'exploitation en une minute. La configuration maximale permettra de déployer pleinement — 128 cœurs CPU, 512 Go de RAM, 4000 Go NVMe. Épique 🙂

Source : habr.com