Sécuriser son serveur Linux (Partie 1)

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 :

• Partie I (ce tuto) : Ajout d’un utilisateur / Configuration SSH / Accès limité au compte « root »
• Partie II (http://blog.vincentcharles.ovh/index.php/2015/10/21/securiser-son-serveur-linux-partie-2/) : Configuration du firewall / Outils de protection DDOS – Scan de ports…

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 !

useradd -m -s /bin/bash admin

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

passwd admin

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 :

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 :

gpasswd -a admin wheel

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

gpasswd -d admin wheel

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 :

su root

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 :

#auth      required      pam_wheel.so use_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 :

ssh-keygen -b 2048 -t rsa

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 :

cd /home/admin
# S'il n'existe pas déjà
mkdir .ssh 
cd .ssh
#  Nano ou vi ou l'éditeur de fichier que vous voulez
nano -w authorized_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 :

chown admin:admin /home/admin/.ssh -R
chmod 700 /home/admin/.ssh
chmod 600 /home/admin/.ssh/authorized_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 :

################################################################
###   Fichier de configuration SSHD - By Linux 2015-10-21    ###
################################################################


#### Options réseau ####

# Port d'écoute de SSH (d?faut 22)
Port 22

# Réstriction inet = IPv4, inet6 = IPv6, any = both (défaut both)
AddressFamily inet

# N'écoute que certaines IP (si vous n'êtes pas sur ne faites rien)
#ListenAddress 192.168.1.0

# Utilise le Protocole 2 (1 est obsol?te)
Protocol 2

# Désactive le X11 Forwarding (serveur)
X11Forwarding no

# Protection du TCP Spoofing
TCPKeepAlive no
ClientAliveInterval 600
ClientAliveCountMax 3

#### Options réseau ####


#### Configuration des clés ####

# Clés host pour le protocole niveau 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key

# Séparation des privilèges (sécurité) en multipliant
# les processus pour bloquer les gradiants de permissions
# Original : prevent privilege escalation exploits
UsePrivilegeSeparation yes

# Permettre utilisation de clés publiques
PubkeyAuthentication yes

# Lieu de stockage des clés publiques de chaque utilisateur
AuthorizedKeysFile      %h/.ssh/authorized_keys

# Interdire les clés blacklistees
# Liste provient d'une vulnérabilité OpenSSH
# Testez vos clé (ssh-vulnkey)
PermitBlacklistedKeys no

#### Configuration des clés ####


#### Authentification ####

# Autorise que les utilisateurs suivant
AllowUsers admin

# Autorise que les utilisateurs du groupe suivant
#AllowGroups sshusers

# Temps pour taper la clé (moins de 30 secondes)
# Au dela c'est un echec de connexion
LoginGraceTime 30

# Empèche le login de ROOT
PermitRootLogin no

# Verifie les permissions des dossiers et fichiers des clés
# Dossier .ssh (700) et fichiers authorized_keys (600)
StrictModes yes

# Ne pas lire les fichiers  ~/.rhosts and ~/.shosts (utilisateurs) 
IgnoreRhosts yes

# Décide si /etc/hosts.equiv et une cle publique sont autorisés
HostbasedAuthentication no

# Ne fait pas confiance au fichier ~/.ssh/known_hosts
IgnoreUserKnownHosts yes

# Ne pas permettre les mots de passes vides
PermitEmptyPasswords no

# Je ne sais pas a quoi ca sert. En anglais :
# Disable challenger response authentication
# Inutile puisque l'on utilise des clés RSA
ChallengeResponseAuthentication no

# Bloque utilisation des mots de passe
# Limite le serveur aux clés RSA
PasswordAuthentication no

# Permet de lancer sshd sans privilèges superutilisateur (root)
UsePAM no

# Ne pas utiliser le systeme traditionnel de login
UseLogin no

#### Authentification ####


#### Divers ####

# Defini le niveau de log de SSH (voir info LogLevel)
SyslogFacility AUTH
LogLevel INFO

# Indique la date et l'heure de dernière connexion
PrintLastLog yes

# Nombre maxi d'echec possible par connexion
# Envoi une alerte log à la moitié de la valeur
# Si MaxAuthTries est dépassé, vous êtes déconnectés
# Permet de ralentir les attaques de bruteforce mais
# pas de banip ici. (voir fail2ban)
MaxAuthTries 1

# Nombre maxi de connexions permises sans authentification
# Les 10 premi?res connections sont acceptées en attente 
# d'authentification puis les suivantes (de 11 ? 60) sont
# rejetées avec une probabilité croissante linéairement de
# 30% pour la 11ème jusqu'? 100% pour la 60ème.
MaxStartups 10:30:60

# Afficher la bannière à la connexion (arrivée sur le prompt ssh)
Banner /etc/issue.net

# Affiche /etc/motd càd la bannière après s'être loguer
# Sur certains OS c'est aussi demand? via /etc/profile ou le shell
PrintMotd yes

# Indique si SSH accepte les variables d'environnement du client
PermitUserEnvironment no

# Indique les variables environnementales acceptées depuis le client
# (dans le cas ou PermitUserEnvironment = yes)
AcceptEnv LANG LC_*

# Defini le subsystem pour SFTP (SecureFTP)
Subsystem sftp /usr/lib/openssh/sftp-server

#### Divers ####

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

/etc/init.d/ssh restart
# ou
services ssh off
services ssh on