Sécuriser son serveur Linux (Partie 1)

Sécuriser son serveur Linux (Partie 1)

21/10/2015 2 Par Vincent

Comme vous le savez (maintenant si), le compte root sur une machine Linux/Unix est le compte utilisateur (enfin administrateur) le plus important. Et pour cause, il permet de faire absolument tout sur la machine, le meilleur comme le pire. Beaucoup de débutants dans le monde des serveurs (je parle de personnes utilisant pour diverses raisons un serveur dédié loué à droite ou à gauche) ne connaissent rien en sécurité informatique et il faut le dire, ça se voit :

  • Accès root depuis l’extérieur (accès en SSH)
  • Accès SSH par mot de passe (et qui dit mot de passe de débutant, dit mot de passe avec 3 chiffres et 4 lettres)
  • Firewall qui fait la tête (enfin non il laisse tout passer c’est plus simple comme ça)

Bref vous l’avez compris l’idée ici est de proposer quelques modifications simples pour sécuriser un minimum votre serveur linux à distance. On va partir sur deux parties :

Création d’un utilisateur et ajout au groupe wheel

Pour commencer, on va faire un nouvel utilisateur qui aura donc l’accès à SSH (accès à distance) mais également la possibilité d’accèder au « root » par élévation de droits via la commande « su ».

Pour cella !

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »useradd%20-m%20-s%20%2Fbin%2Fbash%20admin »/]

On peut ensuite changer son mot de passe pour commencer (même si on va vite le remplacer pour une clé RSA)

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »passwd%20admin »/]

On tape le mot de passe souhaité, à deux reprises.

Au sujet du mot de passe, attention à utiliser un mot de passe fort pour vos utilisateurs et surtout pour votre compte root. Vous pouvez le modifier avec cette commande :

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »passwd »/]

Nous le verrons plus tard, mais nous allons limité l’élévation de droits (c’est à dire le passage en root) qu’au utilisateur appartenant au groupe « wheel ». Il nous faut donc ajouter ce groupe à notre nouvel utilisateur :

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »gpasswd%20-a%20admin%20wheel »/]

Vous pouvez ajouter autant d’utilisateurs que vous voulez de cette façon, mais tout le monde n’a pas forcement besoin de cet accès, qu’en pensez-vous ?

Si vous souhaitez retirer les droits du groupe wheel à un utilisateur, c’est comme ça

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »gpasswd%20-d%20admin%20wheel »/]

La première méthode supprime tous les groupes secondaires de l’utilisateur (sur un utilisateur dédié à l’accès SSH c’est ok), la seconde retire juste le groupe en question (plus adapté si l’utilisateur en question gère d’autres choses sur la machine).

Maintenant, on a :

  • un utilisateur root (avec son mot de passe mis à jour si on l’a changé)
  • un utilisateur admin (qui a son propre mot de passe et appartient à wheel pour l’accès root)

Restreinte l’accès aux droits root aux membres de « wheel »

Vous pouvez vous déconnecté de l’utilisateur root (#logout ou #exit) et vous reconnectez en « admin ».

Pour repasser root :

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »su%20root »/]

puis votre mot de passe

Maintenant, nous allons restreindre l’utilisation de « su » qu’aux utilisateurs du groupe « wheel ». Pour ça, nous éditons le fichiers : /etc/pam.d/su en décommentant la ligne suivante :

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »%23auth%20%20%20%20%20%20required%20%20%20%20%20%20pam_wheel.so%20use_uid »/]

Si vous créez un nouvel utilisateur qui n’appartient pas à wheel, il ne pourra pas passer en root même s’il connait le mot de passe de ce dernier.

Génération de clé RSA(2048bits) pour SSH

Depuis le début, on considère que l’on a accès à la machine via SSH. Nous allons passer à la configuration de ce service mais avant ça, on va créé notre couple de clé RSA pour un accès sans mot de passe, plus sécurisé donc.

La, il y a deux écoles :

  • on utilise son utilisateur du coté serveur pour générer les clés :

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »ssh-keygen%20-b%202048%20-t%20rsa »/]

Vous validez le dossier de création des fichiers puis choisissez un mot de passe pour déchiffrer la clé

A ce stade, vous avez deux fichiers générés : id_rsa (clé privée = SECRÈTE) et id_rsa.pub (clé publique).

  • on utilise un générateur de clé SSH (celui de Putty sous Windows est très bien

On choisi le type de clé : RSA2048 puis on génère la clé. On enregistre sa clé privée quelque part (fichier .ppk) et on met de coté la clé publique.

La deuxième méthode est sans doute la plus simple puisque le fichier (clé privée) généré est disponible sur votre machine personnelle directement et surtout elle est compatible avec la majorité des applications ssh sous Windows (Putty, WinSCP)

Maintenant, il faut renseigner à votre serveur les clés publiques qui correspondent aux clés privées :

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »cd%20%2Fhome%2Fadmin%0A%23%20S’il%20n’existe%20pas%20d%C3%A9j%C3%A0%0Amkdir%20.ssh%20%0Acd%20.ssh%0A%23%20%20Nano%20ou%20vi%20ou%20l’%C3%A9diteur%20de%20fichier%20que%20vous%20voulez%0Anano%20-w%20authorized_keys »/]

Dans ce fichier (authorized_keys) qui doit se trouver très exactement à cet emplacement : /home/admin/.ssh/, vous inscrivez vous clés publiques (copier/coller)… et vous laissez dans lignes vides à la suite des clés (une clé par ligne).

Il faut enfin vérifier les droits de chaque fichier :

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »chown%20admin%3Aadmin%20%2Fhome%2Fadmin%2F.ssh%20-R%0Achmod%20700%20%2Fhome%2Fadmin%2F.ssh%0Achmod%20600%20%2Fhome%2Fadmin%2F.ssh%2Fauthorized_keys »/]

Faites un essai en vous connectant maintenant avec votre clé et non votre mot de passe. Si tout est OK, on passe pour finir à la configuration de SSH pour limiter les accès.

Configuration de SSH

Dans la même foulée, on va :

  • Empêcher la connexion par mot de passe
  • Bloquer l’utilisateur root en SSH
  • Permettre l’accès par clés publique/privée
  • Restreindre SSH à certains utilisateurs

Pour ça, il faut éditer le fichier /etc/ssh/sshd_config :

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%0A%23%23%23%20%20%20Fichier%20de%20configuration%20SSHD%20-%20By%20Linux%202015-10-21%20%20%20%20%23%23%23%0A%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%0A%0A%0A%23%23%23%23%20Options%20r%C3%A9seau%20%23%23%23%23%0A%0A%23%20Port%20d’%C3%A9coute%20de%20SSH%20(d%3Ffaut%2022)%0APort%2022%0A%0A%23%20R%C3%A9striction%20inet%20%3D%20IPv4%2C%20inet6%20%3D%20IPv6%2C%20any%20%3D%20both%20(d%C3%A9faut%20both)%0AAddressFamily%20inet%0A%0A%23%20N’%C3%A9coute%20que%20certaines%20IP%20(si%20vous%20n’%C3%AAtes%20pas%20sur%20ne%20faites%20rien)%0A%23ListenAddress%20192.168.1.0%0A%0A%23%20Utilise%20le%20Protocole%202%20(1%20est%20obsol%3Fte)%0AProtocol%202%0A%0A%23%20D%C3%A9sactive%20le%20X11%20Forwarding%20(serveur)%0AX11Forwarding%20no%0A%0A%23%20Protection%20du%20TCP%20Spoofing%0ATCPKeepAlive%20no%0AClientAliveInterval%20600%0AClientAliveCountMax%203%0A%0A%23%23%23%23%20Options%20r%C3%A9seau%20%23%23%23%23%0A%0A%0A%23%23%23%23%20Configuration%20des%20cl%C3%A9s%20%23%23%23%23%0A%0A%23%20Cl%C3%A9s%20host%20pour%20le%20protocole%20niveau%202%0AHostKey%20%2Fetc%2Fssh%2Fssh_host_rsa_key%0AHostKey%20%2Fetc%2Fssh%2Fssh_host_dsa_key%0AHostKey%20%2Fetc%2Fssh%2Fssh_host_ecdsa_key%0A%0A%23%20S%C3%A9paration%20des%20privil%C3%A8ges%20(s%C3%A9curit%C3%A9)%20en%20multipliant%0A%23%20les%20processus%20pour%20bloquer%20les%20gradiants%20de%20permissions%0A%23%20Original%20%3A%20prevent%20privilege%20escalation%20exploits%0AUsePrivilegeSeparation%20yes%0A%0A%23%20Permettre%20utilisation%20de%20cl%C3%A9s%20publiques%0APubkeyAuthentication%20yes%0A%0A%23%20Lieu%20de%20stockage%20des%20cl%C3%A9s%20publiques%20de%20chaque%20utilisateur%0AAuthorizedKeysFile%20%20%20%20%20%20%25h%2F.ssh%2Fauthorized_keys%0A%0A%23%20Interdire%20les%20cl%C3%A9s%20blacklistees%0A%23%20Liste%20provient%20d’une%20vuln%C3%A9rabilit%C3%A9%20OpenSSH%0A%23%20Testez%20vos%20cl%C3%A9%20(ssh-vulnkey)%0APermitBlacklistedKeys%20no%0A%0A%23%23%23%23%20Configuration%20des%20cl%C3%A9s%20%23%23%23%23%0A%0A%0A%23%23%23%23%20Authentification%20%23%23%23%23%0A%0A%23%20Autorise%20que%20les%20utilisateurs%20suivant%0AAllowUsers%20admin%0A%0A%23%20Autorise%20que%20les%20utilisateurs%20du%20groupe%20suivant%0A%23AllowGroups%20sshusers%0A%0A%23%20Temps%20pour%20taper%20la%20cl%C3%A9%20(moins%20de%2030%20secondes)%0A%23%20Au%20dela%20c’est%20un%20echec%20de%20connexion%0ALoginGraceTime%2030%0A%0A%23%20Emp%C3%A8che%20le%20login%20de%20ROOT%0APermitRootLogin%20no%0A%0A%23%20Verifie%20les%20permissions%20des%20dossiers%20et%20fichiers%20des%20cl%C3%A9s%0A%23%20Dossier%20.ssh%20(700)%20et%20fichiers%20authorized_keys%20(600)%0AStrictModes%20yes%0A%0A%23%20Ne%20pas%20lire%20les%20fichiers%20%20~%2F.rhosts%20and%20~%2F.shosts%20(utilisateurs)%20%0AIgnoreRhosts%20yes%0A%0A%23%20D%C3%A9cide%20si%20%2Fetc%2Fhosts.equiv%20et%20une%20cle%20publique%20sont%20autoris%C3%A9s%0AHostbasedAuthentication%20no%0A%0A%23%20Ne%20fait%20pas%20confiance%20au%20fichier%20~%2F.ssh%2Fknown_hosts%0AIgnoreUserKnownHosts%20yes%0A%0A%23%20Ne%20pas%20permettre%20les%20mots%20de%20passes%20vides%0APermitEmptyPasswords%20no%0A%0A%23%20Je%20ne%20sais%20pas%20a%20quoi%20ca%20sert.%20En%20anglais%20%3A%0A%23%20Disable%20challenger%20response%20authentication%0A%23%20Inutile%20puisque%20l’on%20utilise%20des%20cl%C3%A9s%20RSA%0AChallengeResponseAuthentication%20no%0A%0A%23%20Bloque%20utilisation%20des%20mots%20de%20passe%0A%23%20Limite%20le%20serveur%20aux%20cl%C3%A9s%20RSA%0APasswordAuthentication%20no%0A%0A%23%20Permet%20de%20lancer%20sshd%20sans%20privil%C3%A8ges%20superutilisateur%20(root)%0AUsePAM%20no%0A%0A%23%20Ne%20pas%20utiliser%20le%20systeme%20traditionnel%20de%20login%0AUseLogin%20no%0A%0A%23%23%23%23%20Authentification%20%23%23%23%23%0A%0A%0A%23%23%23%23%20Divers%20%23%23%23%23%0A%0A%23%20Defini%20le%20niveau%20de%20log%20de%20SSH%20(voir%20info%20LogLevel)%0ASyslogFacility%20AUTH%0ALogLevel%20INFO%0A%0A%23%20Indique%20la%20date%20et%20l’heure%20de%20derni%C3%A8re%20connexion%0APrintLastLog%20yes%0A%0A%23%20Nombre%20maxi%20d’echec%20possible%20par%20connexion%0A%23%20Envoi%20une%20alerte%20log%20%C3%A0%20la%20moiti%C3%A9%20de%20la%20valeur%0A%23%20Si%20MaxAuthTries%20est%20d%C3%A9pass%C3%A9%2C%20vous%20%C3%AAtes%20d%C3%A9connect%C3%A9s%0A%23%20Permet%20de%20ralentir%20les%20attaques%20de%20bruteforce%20mais%0A%23%20pas%20de%20banip%20ici.%20(voir%20fail2ban)%0AMaxAuthTries%201%0A%0A%23%20Nombre%20maxi%20de%20connexions%20permises%20sans%20authentification%0A%23%20Les%2010%20premi%3Fres%20connections%20sont%20accept%C3%A9es%20en%20attente%20%0A%23%20d’authentification%20puis%20les%20suivantes%20(de%2011%20%3F%2060)%20sont%0A%23%20rejet%C3%A9es%20avec%20une%20probabilit%C3%A9%20croissante%20lin%C3%A9airement%20de%0A%23%2030%25%20pour%20la%2011%C3%A8me%20jusqu’%3F%20100%25%20pour%20la%2060%C3%A8me.%0AMaxStartups%2010%3A30%3A60%0A%0A%23%20Afficher%20la%20banni%C3%A8re%20%C3%A0%20la%20connexion%20(arriv%C3%A9e%20sur%20le%20prompt%20ssh)%0ABanner%20%2Fetc%2Fissue.net%0A%0A%23%20Affiche%20%2Fetc%2Fmotd%20c%C3%A0d%20la%20banni%C3%A8re%20apr%C3%A8s%20s’%C3%AAtre%20loguer%0A%23%20Sur%20certains%20OS%20c’est%20aussi%20demand%3F%20via%20%2Fetc%2Fprofile%20ou%20le%20shell%0APrintMotd%20yes%0A%0A%23%20Indique%20si%20SSH%20accepte%20les%20variables%20d’environnement%20du%20client%0APermitUserEnvironment%20no%0A%0A%23%20Indique%20les%20variables%20environnementales%20accept%C3%A9es%20depuis%20le%20client%0A%23%20(dans%20le%20cas%20ou%20PermitUserEnvironment%20%3D%20yes)%0AAcceptEnv%20LANG%20LC_*%0A%0A%23%20Defini%20le%20subsystem%20pour%20SFTP%20(SecureFTP)%0ASubsystem%20sftp%20%2Fusr%2Flib%2Fopenssh%2Fsftp-server%0A%0A%23%23%23%23%20Divers%20%23%23%23%23″/]

A ce stade, c’est terminé. Si les modifications ont été sauvegardé, relancer le service ssh-server pour tester :

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »%2Fetc%2Finit.d%2Fssh%20restart%0A%23%20ou%0Aservices%20ssh%20off%0Aservices%20ssh%20on »/]