Guide de durcissement d’un serveur Linux pour PCI DSS

ubuntuLors de la revue des exigences PCI DSS, il est demandé de produire un guide de durcissement des systèmes d’informations. Il apparait alors une vrai intérrogation sur le sujet.

Dois je fournir un guide d’installation complet de 200 pages sur le durcissement de ma plateforme ou encore un dossier d’installation avec quelques tips sur la sécurité ?

Je conseille fortement de différencier les différents guides de durcissements pour ne pas tout confondre.

La règle N°1: Documenter ce qui est en place, on ne demande pas la bible de la sécurité mais un guide de durcissement de vos systèmes. Cela peut aller de quelques pages à plusieurs dizaines. L’auditeur QSA passera en revu celui-ci.

Je vous propose une base de travail pour votre guide de durcissement pour les serveurs fonctionnants sous Linux sans aucun service pour le moment . Ce billet servira de fil rouge pour l’ensemble des serveurs Linux de votre périmètre. Attention, il ne couvre pas les composants (Applications, Outils de sauvegarde, Supervision…) qui sont installés. Ce mini guide sert uniquement au socle.

Le document doit posséder une nomenclature claire et avoir les informations suivantes dans son template.

  • Le titre du document.
  • La version de celui-ci.
  • La date d’écriture.
  • La date de révision.
  • La date de la dernière relecture technique (un document de durcissement peut très bien avoir 3 ans et être mis à jour chaque année).
  • L’auteur/le département.
  • Qui maintient le document.
  • Un sommaire clair qui permet à l’auditeur de faire son travail efficacement.

Entrons dans le vif du sujet maintenant, nous avons un socle Linux Ubuntu version LTS (Support longue durée).

Nous considérons que nous disposons d’un serveur avec seulement le logiciel ssh d’installé pour commencer. Nous n’avons encore mis aucune applications et outils sur celui-ci.

Attention, ce guide de durcissement est un début de sécurisation chaque administrateur de systèmes à ces habitudes et ce guide n’est pas une assurance que votre serveur soit ultra sécurisé. Nous sommes au début de la sécurisation du socle de vos applications. Donc prudence.

Une devise à maintenir sur votre durcissement « Keep it simple » Ca ne sert à rien de faire une usine à gaz, vous serez toujours vulnérable et vous devrez maintenir en état opérationnel ce système.

Règles de durcissement N°1: Maintenir à jour votre système en appliquant la mise à jour des patchs sécurités. Ceux-ci doivent être tracé aussi bien sur votre processus de gestion de patch management que sur vos processus ITIL existant. Si vous n’avez pas d’ITIL en interne ce n’est pas grave pour PCI DSS, par contre votre patch management doit avoir la trace de votre action.

durcissement linux 1

 

Lors de votre première connexion, nous constatons que notre serveur nécessite plusieurs mises à jours de sécurité (76 dans notre cas et 56 au niveau sécurité). Pas de panique. On lance les commandes de mises à jour après avoir noté les composants en cause pour faire notre ecab (changement d’urgence).

 

On lance les commandes de mises à jour de la base de paquets et on applique les changements si on est d’accord.

durcissement 2

 

On applique les changements demandés.

durcissement 3

 

Notre système est maintenant à jour mais totalement ouvert au monde…

Règle de durcissement N°2 : Le composant SSH. Il existe énormément de tuto sur le Net sur le sujet donc on va juste expliquer les bests practices pour sécurisé un composant SSH.

On édite le fichier situé dans /etc/ssh/sshd_config

Comme on peut le voir, notre serveur ssh répond sur le port 22 et il utilise le protocole 2. On a aussi les connexions ouvertes pour le compte root ainsi que l’utilisation d’un identifiant et d’un mot de passe…cela s’appel un serveur full open. le niveau de durcissement est faible voir inexistant dans ce cas précis.

 

durcissement 4

On modifie le tout et on change le port 22 par 22222 par exemple et on bloque le compte root. On autorise aussi les clé ssh et non les comptes utilisateurs.

durcissement 5

 

On commence à avoir un composant SSH durci mais il reste encore pas mal de boulot. On relance le service ssh et on peut plus se connecter sur le port 22 mais sur le 22222 maintenant en échangeant nos clés avec celui-ci. Vous pouvez parfaitement choisir un autre port.

Je vous conseil fortement de lire mon guide de durcissement SSH ici

Règles de durcissement N°3: Installation d’un logiciel contre les connexions à répétitions (DDOS). Linux dispose d’un outil particulièrement efficace qui se nomme Fail2ban. L’installation se fait via les commandes apt-get.

durcissement 6

 

On n’a plus qu’à modifier le fichier de configuration dans :

root@VMLXTEST01:/etc/fail2ban# vi jail.conf

 

 

[ssh]

enabled  = true
port     = ssh
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 6

et voila maintenant quand un utilisateur non autorisé viendra sur votre serveur, il se fera bannir un temps certains après 6 échecs dans mon cas j’ai mis 48 heures…

Règle de durcissement N°4 : On installe un firewall. Dans notre cas on va passer par ufw qui est une interface simple au dessus d’Iptables (Simple ne veut pas dire merdique). La puissance des règles IPtables peut amener à pas mal d’erreur dès que l’on dépasse la centaine de règles. Un condensé des commandes de bases.

Capture d’écran 2014-05-25 à 18.59.29

On peut constater qu’à part le port 22222 tout est fermé.

Règle de durcissement N°5: Détection des intrusions sur notre système et modification des fichiers. L’outils Tripwire est là pour nous simplifier la vie.

Capture d’écran 2014-05-25 à 19.04.00

On modifie ensuite dans le fichier de configuration de tripwire les fichiers sensibles à analyser.

Un bon début en commençant par le fichier twpol.txt

Capture d’écran 2014-05-25 à 19.07.00

Capture d’écran 2014-05-25 à 19.07.39

Nous disposons maintenant d’un socle plus sécurisé qu’au départ et nous répondons à l’exigence de durcissement de nos systèmes de manières simple et efficace. Attention, l’auditeur peut remettre en cause votre durcissement si celui-ci ne prend pas en compte le risque de votre composant (Exposé sur un réseau public, données sensibles…).

Règle de durcissement N°6 – Installer une solution antivirus

Règle du durcissement N°7 – Arrêter tous les services non utiles sur le socle