Comment sécuriser un VPS sous Ubuntu Linux

Dès que vous prenez les rênes de la machine, vous devez vous assurer que votre VPS dispose au moins d'un minimum de défenses contre les attaques externes. Aucun système n'est parfait, de même qu'aucun système n'est véritablement impénétrable; cela ne dispense toutefois pas de mettre en place une série de précautions techniques visant, à tout le moins, à éviter que même les attaques les plus simples n'aboutissent.

Par politique de VPS GREEN, les VPS sont livrés avec le système d'exploitation choisi tel que le fournit son éditeur. Cela implique évidemment un minimum d'opérations, consacrées à la sécurité, avant de pouvoir installer vos propres programmes. Comme dans la célèbre phrase de la bande dessinée Spider-Man : l'administrateur système a de grands pouvoirs, mais aussi de grandes responsabilités.

L'équipe technique de VPS GREEN n'est pas autorisée à accéder à vos VPS; elle reste en revanche toujours disponible pour vous assister sur le système d'exploitation.

Prérequis

1. Un VPS avec un système d'exploitation Linux
2. Un utilisateur avec des privilèges adéquats, c'est-à-dire sudo ou directement root
3. Un éditeur de texte, dans notre exemple nous utiliserons nano
4. Le gestionnaire de paquets apt, normalement inclus dans le système d'exploitation
5. [Recommandé] Un pare-feu, dans notre exemple nous utiliserons ufw

Mettez à jour votre système d'exploitation

La première des responsabilités d'un sysadmin est de garantir au quotidien la sécurité et le bon fonctionnement du système d'exploitation et des applications. Les développeurs de distributions et de systèmes d'exploitation proposent de fréquentes mises à jour de paquets, très souvent pour des raisons de sécurité : garantir la mise à jour de la distribution ou du système d'exploitation est un élément essentiel pour protéger le VPS.

Il peut arriver que les éditeurs des applications publient une liste de paquets système ou de bibliothèques compatibles ou incompatibles : avant de mettre à jour des composants spécifiques, assurez-vous qu'il n'existe pas d'incompatibilités avec les applications que vous avez installées ou devrez installer sur le VPS.

Commençons par nous assurer que la bibliothèque des paquets est à jour. Il suffit de se connecter au VPS via SSH ou via la console et de lancer la commande :

$ sudo apt update && sudo apt upgrade

Apt répondra par une série d'informations, dont le nombre de paquets à mettre à jour. Il est bon de se rappeler (sauf besoins particuliers) de toujours maintenir votre VPS à jour, en confirmant les paquets proposés, comme dans l'exemple :

6 upgraded, 8 newly installed, 0 to remove and 0 not upgraded.
6 standard LTS security updates
Need to get 54.5 MB of archives.
After this operation, 242 MB of additional disk space will be used.
Do you want to continue? [Y/n] Y

Modifiez le port par défaut du Secure Shell

Même si ce n'est pas obligatoire, il peut être judicieux de modifier le port standard de SSH, normalement défini sur le 22. Cette opération, somme toute banale, évite les attaques de robots qui viseraient normalement le port standard. La procédure est assez simple : il suffit de modifier le fichier de configuration du service avec l'éditeur de texte de votre choix.

$ sudo nano /etc/ssh/sshd_config

Cherchez la chaîne « Port 22 » et remplacez le numéro par le port de votre choix, en veillant toutefois à ne pas utiliser un port employé par un autre protocole système. Par convention, les ports compris entre 49152 et 65535 sont considérés comme libres, non attribués à un protocole ou à une application spécifique.

# This is the sshd server system-wide configuration file.
# Port 22
Port 4422

Enregistrez les modifications et redémarrez le service SSH :

$ sudo systemctl restart sshd

Une fois le service redémarré, vous ne devriez remarquer aucune différence, mais il est clair que lors de votre prochaine connexion vous devrez utiliser la chaîne :

ssh Nome_Utente@IPv4_del_VPS -p Numero_della_porta

Si vous utilisez un pare-feu, pensez à ajouter le nouveau port et à autoriser le trafic entrant. Par exemple, si vous décidez d'utiliser ufw, exécutez la commande :

$ sudo ufw allow 4422
$ sudo ufw show added
Added user rules (see 'ufw status' for running firewall):
ufw allow 25565
ufw allow 22
ufw allow 4422

Vous ajouterez ainsi le nouveau port choisi pour SSH et vérifierez quels ports sont configurés sur le pare-feu. Si vous souhaitez, en plus de ne pas utiliser le port 22, en bloquer également le trafic, vous pouvez définir le deny :

$ sudo ufw deny 22
$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To                         Action      From
--                         ------      ----
25565                      ALLOW IN    Anywhere
22                         DENY IN     Anywhere
4422                       ALLOW IN    Anywhere
25565 (v6)                 ALLOW IN    Anywhere (v6)
22 (v6)                    DENY IN     Anywhere (v6)
4422 (v6)                  ALLOW IN    Anywhere (v6)

Le paramètre status verbose vous permet d'avoir une vue d'ensemble de la configuration du pare-feu. Si tout correspond à ce que vous voulez obtenir, assurez-vous que le service de pare-feu est actif :

$ sudo ufw enable

N'utilisez pas root pour tout : créez un compte aux droits limités

C'est une bonne règle générale de ne pas toujours utiliser l'utilisateur root, en particulier pour les opérations qui ne requièrent pas des privilèges aussi élevés. Pour créer un nouvel utilisateur, utilisez cette commande :

$ sudo adduser Nome_del_Nuovo_Utente

Le système demandera de spécifier le mot de passe (il est toujours conseillé de ne pas utiliser de mots de passe faibles) et d'autres informations (nom, etc.). Une fois créé, il pourra être immédiatement utilisé pour accéder au VPS. Si l'utilisateur créé doit exécuter des opérations qui requièrent des privilèges, deux méthodes distinctes sont possibles :

1. utiliser la commande $ su root pour basculer momentanément sur l'utilisateur root;
2. ajouter l'utilisateur à la liste des « sudoers », une liste spéciale d'utilisateurs qui peuvent élever leurs privilèges via la commande sudo.

Si la première méthode ne nécessite pas d'explications supplémentaires, la seconde prévoit l'ajout du nouvel utilisateur à la liste. Pour l'autoriser, il faut lancer depuis root :

$ echo "Nome_del_Nuovo_Utente  ALL=(ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/Nome_del_Nuovo_Utente

De cette façon, nous utiliserons l'utilisateur root pour créer un fichier dédié au nouvel utilisateur dans sudoers.d/, qui sera lu par sudo et autorisera notre nouvel utilisateur. À ce stade, nous pouvons nous connecter en SSH au VPS avec le nouvel utilisateur, y compris pour des opérations qui requièrent des privilèges particuliers, comme par exemple :

$ sudo apt update

Désactivez l'accès de l'utilisateur root au serveur

L'utilisateur root est créé par défaut sur les systèmes GNU/Linux et représente généralement l'utilisateur disposant du niveau d'accès le plus élevé du système. Il est fortement déconseillé, et même dangereux, de laisser votre VPS accessible exclusivement en tant qu'utilisateur root, car ce compte peut effectuer des opérations sans aucun garde-fou, y compris des opérations nuisibles et irréversibles. Il est donc fortement recommandé de désactiver l'accès direct des utilisateurs root via les protocoles d'accès à distance (RDP, VNC, etc.) en général, et pas seulement pour le protocole SSH.

La procédure est assez simple : il suffit de modifier le fichier de configuration du service avec l'éditeur de texte de votre choix.

$ sudo nano /etc/ssh/sshd_config

Cherchez la chaîne « PermitRootLogin yes » et définissez « no » :

# Authentication:
# PermitRootLogin yes
PermitRootLogin no

Enregistrez les modifications et redémarrez le service SSH :

$ sudo systemctl restart sshd

À partir de ce moment, toute tentative de connexion via SSH avec root@IPv4_del_VPS échouera. Pensez à créer un utilisateur à utiliser pour l'accès à distance. Dans tous les cas, root pourra toujours être utilisé pour l'accès via la console web de VPS GREEN.

Un peu de protection en plus… Fail2ban

Fail2ban est extrêmement utile pour prévenir les tentatives d'intrusion et peut donc représenter une petite précaution supplémentaire pour la sécurité de votre VPS. Le but de Fail2ban est de bloquer les adresses IP depuis lesquelles les robots ou les attaquants essaient d'accéder à votre système, en particulier si vous êtes attaqué par un robot qui tente un brute force (c'est-à-dire qui essaie de se connecter à un service en testant des mots de passe aléatoires ou tirés d'un dictionnaire).

L'installation est très simple :

$ sudo apt install fail2ban

L'application est déjà parfaitement fonctionnelle telle qu'elle vient d'être installée. Si vous préférez personnaliser quelques paramètres, vous pouvez modifier la configuration dans le fichier /etc/fail2ban/jail.conf; pour approfondir, nous vous conseillons la documentation officielle sur le site du projet Fail2ban.

Comme suggéré dans la documentation, créons notre propre fichier de configuration :

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

Rappelez-vous que les paramètres marqués [DEFAULT] agissent au niveau global, sur tous les services; ces valeurs sont toutefois « écrasées » si on les insère dans les sections dédiées aux différents services. Exemple :

# [DEFAULT]
bantime = 1h
...
[sshd]
# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode   = normal
port    = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
bantime = 3h

Dans notre exemple, nous avons défini au niveau global un temps de bannissement de 1 heure (bantime = 1h), tandis que pour le service SSH nous avons défini un bantime de 3 heures. Pour activer immédiatement les personnalisations, il faut redémarrer le service :

$ sudo systemctl restart fail2ban.service

Attention à ne pas écrire de paramètres en double au sein d'une même section [DEFAULT] ou de n'importe quelle section [nom_du_service] : sinon Fail2ban ne démarrera pas et renverra une erreur.

Changez souvent les mots de passe

C'est une bonne pratique de définir une politique de changement des mots de passe, en particulier pour les utilisateurs qui disposent de privilèges élevés. Il n'y a pas de règle absolue mais, d'une manière générale, plus on change souvent le mot de passe (le plus complexe possible), mieux c'est. Pour modifier le mot de passe de votre propre utilisateur :

$ passwd

Si le mot de passe à changer est celui d'un autre utilisateur, il faudra en préciser le nom :

$ sudo passwd root

Conclusion

Même si Linux (en général) est réputé pour figurer parmi les systèmes d'exploitation les plus sûrs, il présente certaines vulnérabilités. De nombreuses menaces de sécurité peuvent aboutir à une perte ou à une altération des données, c'est-à-dire à des coûts et du temps de restauration. Par exemple :

1. Malware — un logiciel intrusif conçu intentionnellement pour endommager les systèmes d'exploitation.
2. Sniffing — une pratique visant à intercepter les paquets en transit depuis et vers des applications non protégées.
3. Brute force — une attaque visant à deviner les mots de passe par génération automatique ou à l'aide de dictionnaires.
4. Injection SQL — une pratique qui exploite les faiblesses du code d'une application web pour obtenir l'accès à la base de données du serveur.
5. Cross-site scripting (XSS) — une attaque côté client au cours de laquelle du code malveillant est inséré dans un site web.
6. No function-level control — un logiciel peut en être la cause en ne vérifiant pas correctement les droits d'accès, accordant des privilèges root à des utilisateurs ordinaires.
7. Broken authentication — un vol d'identité qui se produit généralement à cause de données non chiffrées, de mots de passe faibles ou de délais d'expiration de session mal configurés.

Avant de mettre en œuvre toute mesure de sécurité, prenez conscience des éléments que vous devriez surveiller. En voici quelques-uns :

1. Sécurité de l'hébergement VPS
2. Logiciels installés sur le serveur
3. Connexions via SSH et autres protocoles activés sur le serveur
4. Accès root et connexions
5. Mots de passe, droits et privilèges des utilisateurs
6. Pare-feu
7. Connexions via FTP et autres protocoles d'échange de fichiers activés sur le serveur
8. Fichiers de log

Protéger un serveur n'est pas impossible : si vous avez suivi ce guide, vous avez déjà fait un premier pas. Les prochains : l'accès par clés SSH et la désactivation de l'accès par mot de passe. Et si vous voulez vérifier la sécurité, pas seulement la déclarer : c'est notre métier.

Guide publié à l'origine sur le blog de VPS GREEN, le service VPS sur notre cloud privé green.

• VPS
• Ubuntu
• hardening
• SSH
• pare-feu
• Fail2ban
• sécurité