Sécurisation d’un serveur CentOS 6.3

Introduction

Suite a des problèmes de sécurité (en fait, l’absence totale de mesure de sécurité) sur mes serveurs Debian, j’ai décidé de repartir à zéro, et de créer un modèle de VM avec une CentOS 6.3 et de mettre la main à la pâte quant à sa sécurité.
Pourquoi une CentOS ? Car je vais avoir un nouvel emploi dans lequel je vais très probablement faire une certification RHEL. CentOS est donc le choix parfait pour me faire la main.

Durant l’installation

Durant l’installation CentOS, il est demandé à l’utilisateur de paramétrer un mot de passe pour le compte root. A ce stade là, je mets un mot de passe très simple, bien qu’avec majuscules et caractères spéciaux, afin de pouvoir rapidement le taper lorsque j’en ai besoin pendant la phase de configuration de SSH, étant donné que je ne peux pas faire de copier-coller dans la console du vSphere Client. Dès que SSH sera installé, je mettrai alors un mot de passe très fort.

Compte utilisateur alternetif

CentOS contrairement à d’autres distributions comme Ubuntu, ne crée pas de compte alternatif à l’installation, mais uniquement le compte root.

La première mesure à prendre est de créer un compte alternatif avec mot de passe très fort. Pour le reste de l’article, je l’appellerai srvadm par simplicité. Pour générer le mot de passe, j’utilise le générateur inclus dans Keepass dont je me sers pour le stockage de toutes mes authentifications et clés.

useradd srvadm
passwd srvadm

Installation de openSSH

Une fois l’installation de la CentOS terminée, et les VMware tools installées, s’il s’agit d’une VM sur un environnement VMware, il est temps d’installer SSH.

yum install openssh-server openssh-clients

Par défaut, la connexion de root par ssh est autorisée. J’en profite donc pour me connecter avec Putty en SSH. A partir de là, je vais pouvoir faire du copier-coller pour le mot de passe, jusqu’à une étape ultérieur où on se passera de mot de passe. Je génère donc un mot de passe très fort et l’applique à root depuis la connexion SSH.

passwd

Authentification ssh par clé (sans mot de passe

Création d’une clé pour Putty sous Windows

Il est temps de mettre en place une authentification par clé pour l’utilisateur srvadm.

D’abord, sur le serveur, je m’authentifie comme srvadm, et je me place dans le dossier ~/.ssh. Ensuite j’édite le fichier authorized_keys dans lequel je mettrai ma clé publique.

su srvadm
cd ~/.ssh
nano authorized_keys

Comme je suis sur Windows, je vais utiliser PuttyGen pour générer une clé, un utilitaire de création de clés pour Putty.

Dans Puttygen, en bas, je choisis « SSH-2 RSA » et 2048 bits. Ensuite je clique Generate, et je bouge la souris sur puttygen pour générer des caractères aléatoires comme indiqué. Une fois ceci fait, je clique « save public key », et « save private key ». Je vais stocker ces deux fichiers dans keepass, qui est capable de stocker des fichiers. NE GARDEZ JAMAIS LA CLE PRIVEE ET LA CLE PUBLIC ENSEMBLE !

Je copie ensuite dans le presse-papier le contenu du champs « Public key for pasting into OpenSSH autorized_keys file » (ce nom parle de lui-même).

De retour sur le serveur, je colle le contenu du presse-papier dans le fichier authorized_keys de mon utilisateur srvadm.

Pour tester la clé depuis Putty, il faut créer une nouvelle connexion vers le serveur, avec le nom d’utilisateur dans l’adresse:

srvadmin@ip_server

Ensuite, dans le volet de gauche, sous « Connection » > « SSH » > « Auth », il faut sélectionner, sous « Private key file for authentication » le fichier de clé privé qu’on vient de créer.

On retourne ensuite tout en haut du volet de gauche sous Session, on lui donne un nom et on la sauve. Il n’y a plus qu’à cliquer sur « Open » pour tester la connexion. Si on ne vous demande pas de mot de passe, c’est dans la poche. Sinon, relisez le chapitre, vous avez du faire une erreur quelque part.

Création d’une clé sous Linux

Si vous utilisez Linux, et non Windows, la procédure n’est pas très différente.

Sur votre ordinateur, ouvrez un terminal, et exécutez la commande suivante:

ssh-keygen -t rsa

Ceci génère deux fichiers, par défaut dans ~/.ssh: id_rsa qui est la clé privée, et id_rsa.pub qui est la clé publique. Collez ensuite le contenu de la clé public (id_rsa.pub) dans le fichier authorized_keys cité plus haut. Souvenez-vous: ce fichier doit être dans le dossier ~/.ssh de l’utilisateur désiré, à savoir srvadm dans notre exemple. Il ne faut pas être connecté en root, mais en srvadm (si vous avez lu l’article jusqu’ici, vous ne pouvez pas avoir fait faux).

Une fois la clé en place, on teste:

ssh srvadm@server_ip_address

on doit se retrouver sur le prompt utilisateur sans avoir eu besoin de mettre un mot de passe.

Passphrase

Personnellement, lors de la génération de clés, je ne mets pas de passphrase car ceci oblige à entrer la passphrase à chaque utilisation de la clé. Mais attention: Cela implique que si qqun vole ma clé, il pourra l’utiliser sans scrupule. Il faut donc être sûr de où on la garde pour éviter que cela n’arrive. Veillez à la mettre en sécurité, par exemple dans keepass.

Configuration de openSSH

Maintenant que je peux me connecter sans mot de passe, grâce à l’utilisation de la clé, à mon serveur, je vais désactiver l’authentification par mot de passe sur openSSH, et je vais interdire le login par l’utilisateur root.

Je vais également limiter l’accès SSH à un groupe d’utilisateur dans lequel je vais mettre pour l’instant l’utilisateur « srvadm », et ultérieurement éventuellement d’autres comptes qui devront pouvoir se connecter par ssh.

La configuration de ssh se fait dans le fichier /etc/ssh/sshd_config. Il faut se loguer en root pour éditer ce fichier. Comme plus haut on a fait un su srvadm, il suffit de taper « exit » maintenant pour retourner en root.

L’alternative est d’utiliser notre nouvelle connexion putty avec authentification par clé, et de se loguer en root avec la commande su:

su -

On copie le mot de passe fort créé pour l’utilisateur root, et le tour est joué.

On édite ensuite le fichier sshd_config:

nano /etc/ssh/sshd_config

Je ne vais pas faire le tour du fichier. Il y a la commande man pour ça. Voici les paramètres que j’ai mis en place. Certains de ces paramètres sont déjà configurés peut-être avec d’autre valeur. A vérifier. Un simple copier-coller de mes paramètres n’est pas une bonne idée.

Le protocole 2 est plus sûr que le protocole 1. On évitera donc d’autoriser le 1.

Protocol 2

Le paramètre suivant indique que une fois la session ssh entamée, on a 30 secondes pour s’authentifier, sinon la session est annulée:

LoginGraceTime 30

Les paramètres suivants concernent l’authentification.

Le premier interdit à root de se connecter par ssh. Le second interdit la connexion par mot de passe. Il est dès lors indispensable d’avoir mis en place l’authentification par clé, et d’utiliser la clé privée correspondante pour toute session vers le serveur. Enfin, le dernier n’autorise que les utilisateurs faisant partie du groupe sshusers à se connecter par ssh.

PermitRootLogin no
PasswordAuthentication no
AllowGroups sshusers

Il faut donc créer le groupe sshusers, et mettre l’utilisateur srvadm dedans:

groupadd sshusers
usermod -G sshusers srvadm

On quitte nano en sauvegardant le fichier, avec ctrl+X.

Il n’y a plus qu’à redémarrer openssh. ATTENTION: Une fois ssh redémarrer, il sera impossible de se connecter par SSH ni avec root, ni par mot de passe. Il est donc INDISPENSABLE de s’être assuré que l’on peut se connecter SANS MOT DE PASSE et avec l’utilisateur srvadm AVANT de redémarrer ssh.

service sshd restart

Il n’y a plus qu’à faire un test depuis putty: On se connecte avec srvadm avec authentification par clé, et si on a besoin de se mettre en root, on utilise pour l’instant su – .

sudo

Je me suis posé la question de savoir si sudo était sûr… Ne souhaitant pas me prendre le chou à entrer le mot de passe à chaque fois, si j’installe sudo, je vais utiliser le paramètre NOPASSWD qui me permet de faire n’importe quelle commande dans mot de passe. C’est faisable mais il y a quelques gardes fous à mettre en place. D’abord, il faut un mot de passe très fort. Je l’ai dit plus haut, j’utilise un générateur de mot de passe. Mes mots de passe font 20 caractères, et sont de ce type là:

C.6%DK'/uM-TRGy5U3@K

Difficilement hackable, quand même.

Dès lors, je considère que ma connexion srvadm est très sûre. Je me permets alors de mettre en place sudo, et d’autoriser srvadm, et uniquement srvadm à utiliser sudo sans mot de passe.

Première étape, il faut installer sudo. On passe en root, on colle le mot de passe de root, et on install sudo avec yum:

su -
yum install sudo

Ensuite on édite sudoers. Pour ce faire, on va utiliser visudo. Par défaut, visudo utilise vi comme éditeur. Si on souhaite utiliser nano, on peut le paramétrer en insérant une variable editor dans sudoers grâce à la commande suivante:

echo Defaults editor=/bin/nano >> /etc/sudoers

Ensuite donc on édite:

visudo

Dans sudoers, je vais empêcher root d’utiliser sudo. Il est activé par défaut, et ça ne sert à rien du tout.

# root  ALL=(ALL)       ALL

Je vais ensuite définir deux variables contenant tous les shells, ainsi que su, afin de pouvoir définir qu’un utilisateur n’a pas le droit de les utiliser:

Cmnd_Alias NSHELLS = /bin/sh, /bin/bash, /sbin/nologin, /bin/tcsh, /bin/csh, /bin/zsh, /bin/k$
Cmnd_Alias NSU = /bin/su

Enfin, j’autorise mon utilisateur srvadm à utiliser sudo sans mot de passe, mais je lui interdit le sudo su (qui est dans la variable NSU) ainsi que l’exécution d’un shell (dans la variable NSHELLS):

srvadm ALL=(ALL) NOPASSWD:ALL, !NSHELLS, !NSU

Ainsi, si l’utilisateur veut se connecter en root, il est obligé d’utiliser la commande « su – » et donc de fournir le mot de passe de root. Ce qui ne serait pas le cas avec sudo su.

CTRL-X y pour sortir et sauvegarder si on a utiliser nano. :wq si on a utiliser vi.

Installation et configuration de Fail2ban

Fail2ban a pour objectif de bloquer les attaques de type « brute force ». Ce sont des attaques ou des serveurs essaient d’entrer en force en faisant une série de tentative de connexions avec recherche de mot de passe sur un tas de nom d’utilisateurs potentiels.

Pour installer fail2ban sur la CentOS 6.3, il faut mettre en place le repository EPEL. Pour celui-ci, on télécharge d’abord la clé PGP, ensuite, on peut télécharger l’autoinstaller du repository, pour enfin installer fail2ban avec yum:

sudo wget http://ftp.riken.jp/Linux/fedora/epel/RPM-GPG-KEY-EPEL-6
sudo rpm --import RPM-GPG-KEY-EPEL-6
sudo rm -f RPM-GPG-KEY-EPEL-6
wget http://dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-7.noarch.rpm
sudo rpm -Uvh epel-release-6-7.noarch.rpm
sudo yum install fail2ban

Une fois fail2ban installé, on va juste modifier quelques paramètres. Sinon, la config par défaut fait bien l’affaire. Pour l’instant, il ne s’agit que de bloquer les attaques brute-force ssh

sudo nano /etc/fail2ban/jail.conf

On va définir l’adresse de destination des emails, l’adresse d’expédition des mêmes emails, et personnellement, je vais augmenter le délai de ban de 600 à 3600 secondes. Je vais également mettre ma propre machine dans les IP a ignorer. A part destmail qui n’existe pas par défaut et qu’il faut donc ajouter dans la rubrique [DEFAULT], toutes les autres variables existe, il suffit de les modifier:

destmail = monitoring@domain.ltd
ignoreip = 127.0.0.1 monddns.mondomaine.ltd
bantime  = 3600
...
action   = iptables[name=SSH, port=ssh, protocol=tcp]
           sendmail-whois[name=SSH, dest=root, sender=fail2ban.monhost@mondomaine.ltd]

Il faut également vérifier si le log a surveiller pointe au bon endroit. En l’occurence, sous « ssh-iptables »:

logpath  = /var/log/secure

dans le cas de CentOS 6.3.

Je mettrai à jour cet article au fur et à mesure de mon avancement.

Sources:
Sécurité Linux – sudo – su – ssh – clé …
sshd_config man page
The Perfect Server – CentOS 6.3 x86_64
How to Configure EPEL Repository on CentOS 6.3

2 réflexions sur “Sécurisation d’un serveur CentOS 6.3

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *