Comment sécuriser la base de son serveur sous Linux

4.86/5 (7)

-15% sur tous les serveurs  avec le code
“GTA5COOLMICROSERUM”
https://microserum.net

Bonjour,

enfin la première partie d’une longue série consacrée aux instances Linux, commençons tout de suite à sécuriser un serveur Linux !

Nous allons donc voir ensemble les bases de sécurité sous Linux, pour éviter les « brute force » principalement causé par ces satanés bots… nous éviterons cependant d’être parano.

Le tutoriel sera fonctionnel sous Debian / Ubuntu, toutes versions confondues, si vous avez le moindre soucis sur une commande, signalez-le moi en commentaire. Également tout aide et correction sont les bienvenus 🙂

 

Notez que ce tutoriel demande un minimum de niveau dans l’informatique, si dès le départ vous bloquez, posez-vous les bonnes questions.

1\ Vous avez déjà effectué l’achat de votre location VPS ? bien, vous avez surement reçu vos accès root par email, il faut modifier cela dès le départ.

Simplement, on lance son terminal, on se connecte en root :

ssh root@ip_de_votre_serveur

Vous aurez un premier message de sécurité, explication de @Pingex :

Votre client SSH ne connaît pas la fingerprint du serveur, ce dernier se méfie donc (problème de trust). L’acceptation de la clé rajoute une entrée dans ~/.ssh/known_host (ou son équivalent sous PuTTY) avec la fingerprint de l’hôte. Si la clé venait à changer par la suite (réinstallation, IP spoofing ou même MITM), le client SSH avertira l’utilisateur que la clé a changée. Ce mécanisme a pour but que le client puisse authentifier de manière sûre le serveur, et donc être certain que le client ne parle pas en fait à un autre hôte. L’inverse est également possible et s’appelle “authentification par clé SSH

Première chose, on met à jour notre Linux

apt-get update && apt-get upgrade -y

Maintenant nous allons changer notre mot de passe pour le root user (choisissez un mot passe que vous retenez facilement, vous comprendrez pourquoi plus tard)

(n’oubliez pas, vous ne verrez pas ce que vous écrirez, c’est normal)

passwd root

Puis nous allons installer le paquet « sudo » (vous comprendrez pourquoi plus tard)

apt install sudo

 

2\ Bien, maintenant nous allons créer notre « user » principal, du moins celui que nous utiliserons (vous pourrez bien sur en créer plusieurs)

Je vous laisse suivre ce qui est marqué, c’est simple, ATTENTION cependant, c’est là que vous allez mettre un mot de passe complexe !

(rappel, copier sur l’ordi, clique droit pour coller dans la console)

adduser mat

Ayé !! Votre compte est créé et vous avez associé votre mot de passe complexe qui vous sera demandé à chacune de vos connexions ssh, mais ce n’est pas grave, vous pourrez faire des commandes en sudo facilement via un mdp root rapide 🙂

Notez bien ce mot de passe quelque part (si vous le perdez, c’est comme perdre ces accès root), évitez dans un bloc note sur le bureau, préconisez plus un logiciel comme Dashlane par exemple.

(merci à @Pingex pour son aide) Nous allons associer notre user au groupe sudo, eh oui, le group sudo créé précédemment via l’installation du paquet sudo.

usermod -aG sudo mat

3\ Et maintenant ? bhen nous allons désactiver la possibilité de se connecter en root via ssh/sftp !!

Ce qui signifie que nous allons faire toutes les commandes qui nécessite des droits de root, avec « sudo ». (exemple: sudo adduser test)

C’est là que les essais de bruteforce sur le root sont annulés et le risque qu’un bot trouve le mdp de votre root devient quasiment impossible parce qu’il devra commencer par trouver le nom d’un “user” puis le mdp de votre user, puis trouver le mdp de votre root … nous ne lui facilitons pas la tache ^^.

On va commencer par tout faire via notre user, histoire de test si nos cmd en sudo fonctionnent correctement.

exit
ssh mat@ip_de_votre_serveur

Puis j’ouvre le fichier sshd_config avec l’éditeur nano. (avec sudo, vous devrez saisir le mot de passe de votre root)

sudo passwd -dl root

Cela désactivera complètement l’utilisateur root au login ainsi que son mot de passe (vérifiable dans /etc/passwd et /etc/shadow).

Notez qu’il est toujours possible de se connecter en root, à partir d’une connexion d’un user, avec simplement « sudo su » sur debian.

4\ Changement du port, simple mais pas forcément indispensable !

Comme @Pingex me l’a gentiment précisé : « le changement du port SSH n’est qu’un simple tour de passe-passe pour empêcher les scanbots de tenter de bruteforce ton accès root et n’est donc pas une “vraie” mesure de sécurité (de mon point de vue). Un pirate voulant s’emparer de ton serveur ira scanner tes ports avec nmap et retrouvera donc facilement ton serveur SSH pour ensuite l’attaquer. »

Si votre choix est fait, commencez par ouvrir ce fichier :

sudo nano /etc/ssh/sshd_config

à la ligne du port, dé-commenté le puis changer le, par exemple (évitez le 0 en début de port) :

Port 10789

Essayez de choisir un port pas trop simple, parce que souvent, les apt peuvent les utiliser.

Puis on restart le server ssh (n’oubliez pas de noter le port, il vous sera indispensable)

sudo service sshd restart

Pour vous connecter dorénavant :

ssh -p 10789 user@ip_de_votre_serveur

5\ Mise en route du paquet « fail2ban », comme son nom l’indique, « Trompe toi et je te ban !! »

Pour résumé, il permet d’éviter les brutes forces en bannissant les assaillants qui essayent des tentatives de connexion (6). Ils ont très peut de chance de réussir mais cela pompe des performances bêtement, alors on va les bloquer ces stupides bots.

Souvent les hébergeurs pré-install fail2ban mais il n’est pas totalement configuré, alors nous allons améliorer cela ensemble.

sudo apt install fail2ban

On va dupliquer le fichier de configurer pour utiliser le nouveau et ainsi garder le fichier de base intact (pratique et correct)

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

Puis on va le configurer

sudo nano /etc/fail2ban/jail.local

Dedans, nous avons « ignoreip », il suffira de rajouter vos ip whitelist dedans (chaque ip séparée par un espace),
« findtime » est le temps en seconde entre les échecs des tentatives de connexion,
« bantime » est le temps en seconde du bannissement.

Attention, faites déjà une recherche avec CTRL + W pour savoir si [DEFAULT] et [ssh], si non, alors copier/coller intégralement mes paragraphes ci-dessous.
Je vous invite à utiliser cette configuration pour commencer. (sauf pour ignoreip…)

[DEFAULT]
ignoreip = votre_ip1 votre_ip2 votre_ip3
findtime = 3600
bantime = 86400

et (remplacer VOTRE_PORT_SERVEUR par le nouveau port de votre serveur bien sur)

[ssh]
enabled = true
port    = ssh,sftp,VOTRE_PORT_SERVEUR
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 6

On va redémarrer le paquet fail2ban et voir au passage si il y a une erreur.

sudo fail2ban-client reload

puis on va simplement check si notre « ssh » est présent dans la « Jail list »

sudo fail2ban-client status

Si oui, parfait, vous pouvez allez plus loin avec la documentation ci-dessous pour voir si votre fail2ban fonctionne correctement 🙂

Plus de détails ici : https://doc.ubuntu-fr.org/fail2ban

 

Je suis client et également partenaire avec l’entreprise MicroSerum qui propose des services d’hébergement (VPS Linux / Windows, Serveur gamer, etc)

Ils sont jeunes et ambitieux, ils utilises les nouvelles technologies et ont un rapport qualité / prix très bien placé.

Les techniciens de MicroSerum préconisent ces suggestions de sécurité et de bonnes pratiques informatiques pour vos serveurs :

  • Installer l’application Fail2Ban (Linux).
  • Appliquer des restrictions de pare-feu (IP tables sous linux, pare-feu sous Windows).
  • Ne pas utiliser les mots de passe par défaut sur votre machine et bases de donnés.
  • Modifier périodiquement vos mots de passe.
  • Ne pas utiliser le port par défaut pour le FTP, SSH etc..
  • Ne pas utiliser l’utilisateur root / administrateur pour vos accès FTP, SSH, etc..
  • Faire périodiquement vos mises à jour (apt update suivi de apt upgrade sous linux, Windows update sous Windows).
  • Toujours douter de la source des courriels.
  • Utiliser sa conscience logique et sécuritaire dans toutes vos opérations.
  • Restreindre les permissions des utilisateurs au minimum.
  • Faire des copies périodiques des fichiers importants de son serveur.

source : https://manager.microserum.net/knowledgebase.php?action=displayarticle&id=8


Il existe des tonnes de solution pour améliorer la sécurité de son serveur, celles que je propose sont de bonnes bases qui seront parfaites si vous débutez sous Linux.

J’ai passé plusieurs heures à rechercher des informations et à écrire cet article, j’espère que cela vous aura été utile, dites le moi en commentaire 🙂

 

MatPain.

Quelle est votre note pour cet article ?

3
Poster un Commentaire

avatar
2 Comment threads
1 Thread replies
1 Followers
 
Most reacted comment
Hottest comment thread
3 Comment authors
MatPainPingexKarl Recent comment authors
plus récents plus anciens plus de votes
Karl
Invité
Karl

Très bon tuto!

Pingex
Invité
Pingex

Bonjour, J’suis tombé sur ton article par une connaissance. Je ne suis pas fan de GTA, mais je suis administrateur système et réseaux de formation. Permets-moi donc de t’adresser quelques remarques afin de mieux affiner ton article (d’après mon expérience personnelle surtout): – “Vous aurez un premier message de sécurité qui en gros dit que vous vous connectez sans une clé privée SSH et que cela est dangereux.” => Ce n’est pas une connexion sans clé qui pose problème, mais juste que le client SSH ne connaît pas la fingerprint du serveur, ce dernier se méfie donc (problème de trust).… Lire la suite »