Recommandations de configuration d’un système GNU/Linux

Centre Opérationnel de Sécurité et de Cyberdéfense Recommandations de configuration d’un système GNU/Linux DRAFT

Gestion du document

Date de la première version :	27/08/2018
Date de la dernière version :	27/08/2018
Version :	1.0
Source :	SLCC  : Service de Lutte Contre la Cybercriminalité ANSSI : Agence National de la Sécurité des Systèmes d'Information COSC  : Centre Opérationnel de Sécurité et de Cyberdéfense

Préambule

“Hardening” est un terme anglais signifiant “durcissement“. Appliqué à la sécurité d’un système d’information, il s’agit donc d’améliorer la sécurité d’un système, d’un réseau ou d’une application via le durcissement de sa configuration ou de sa structure. Plus précisément, le durcissement d’un système informatique consiste à le rendre plus résistant et mieux protégé face à des attaques ou des mauvaises utilisations. Cela peut s’effectuer à plusieurs niveaux sur un système, et cela est même nécessaire. Ainsi, le durcissement d’un système complet va passer par : – Le durcissement de la couche réseau – Le durcissement du système d’exploitation – Le durcissement des applications installées – Le durcissement des accès physiques – etc. Le durcissement est donc plus globalement le fait de réduire la surface d’attaque d’un système et de rendre plus résistants les points d’entrée nécessaires à sa bonne utilisation. La notion de surface d’attaque illustre bien l’intérêt du hardening. L’hardening ayant pour objectif principal de minimiser les risques en termes de sécurité suite à l’installation d’un système ou d’une application. Il existe des outils d’audit comme Lynis, openscap (serveurs Redhat) qui peuvent, par exemple, lister les fonctionnalités inutiles ou manquantes dans les fichiers de configuration et effectuer diverses autres préconisations de sécurité.

La première étape du durcissement d'un serveur GNU / Linux est de déterminer la fonction du serveur, ce qui permet d’identifier les services qui doivent être installés. Par exemple, si le serveur est utilisé comme serveur Web, vous devez installer uniquement les services adaptés (Apache, PHP, …). Les seules applications et services qui devraient être autorisés à s'exécuter sont ceux requis pour la tâche qu'il doit effectuer. Rien de plus ne devrait être installé.

L'installation de logiciels supplémentaires ou l'exécution de services supplémentaires crée des vulnérabilités. Par exemple, si vous exécutez Lightweight Directory Access Protocol (LDAP) sur un serveur pour des services d'annuaire, le système d'exploitation et LDAP doivent être à jour avec les correctifs de sécurité. Si un environnement LAMP (ou tout autre logiciel) a été installé sur ce serveur, il faut également le mettre à jour, même s’il n'est pas utilisé. Sa simple existence sur le serveur donne à un attaquant un autre vecteur d’attaque sur le système. L'installation d'un logiciel supplémentaire sur un serveur signifie que quelqu'un pourra tenter d’en détourner l’utilisation. L'utilisation du serveur pour des tâches autres que sa tâche principale détourne les ressources de son travail principal et l'expose à d’autres menaces potentielles.

Par conséquent, la sécurité du socle n’est pas acquise à l’installation, mais doit être construite dans le contexte d’utilisation de ce socle.

Pour assurer une protection efficace dans la durée, la sécurisation du socle doit être revue et mise à jour régulièrement (patches, évolution des menaces et des pratiques de durcissement, …).

A minima, l’ANSSI estime que les 5 recommandations suivantes doivent être appliquées.

• Recommandations de sécurité relatives à un système GNU/Linux

Il s’agit de principes qui ont été appliqués aux préconisations que vous trouverez dans la suite de ce document.

Sécurité du système physique

Pour les serveurs physiques

Configurez le BIOS pour désactiver le démarrage à partir de CD/DVD et de périphériques externes. Activer le mot de passe du BIOS et protéger GRUB avec le mot de passe pour restreindre l'accès physique de votre système. Malgré cela, ces mesures servent de mécanismes de retardement car une personne non autorisée ayant un accès physique peut prendre la main sur votre système (moyennant qu’elle dispose de suffisamment de temps).

Pour les serveurs Virtuels

Les serveurs Virtuels sont également, dans une moindre mesure, vulnérables. Il est également important de protéger votre BIOS et GRUB

Il faut désactiver le mode single user qui permet de booter avec le user root sans mot de passe

Recommendations

---

• Supprimer le « mode recovery » dans GRUB
  

Editez le fichier /etc/default/grub et dé commenter la ligne ci-dessous :

GRUB_DISABLE_RECOVERY="true"

Mettre à jour GRUB

# update-grub

• Ajouter un mot de passe dans GRUB

# grub-mkpasswd-pbkdf2
Enter password:

Editez le fichier /etc/grub.d/00_header et ajoutez à la fin du fichier le contenu suivant :

cat << EOF
set superusers="<user>"
password_pbkdf2 <user> grub.pbkdf2.sha512.10000.DABE******* 
EOF

Mettre à jour GRUB

# update-grub

La commande pour les serveurs redhat est « grub2-mkpasswd-pbkdf2 »
Les configurations des BIOS sont documentées dans les notices des constructeurs (physiques et virtuels).

Prationnement du stockage

Un schéma de partitionnement intelligent dépend de l'utilisation de la machine. Une bonne règle est d'être assez large avec vos partitions et de faire attention aux facteurs suivants :

• Les arborescences de répertoires modifiables par un utilisateur, telles que /home, /tmp et /var/tmp, doivent être sur des partitions distinctes. Cela réduit le risque qu'un déni de service provoqué par un utilisateur ne remplisse le point de montage « / » rendant ainsi le système inutilisable (remarque : ce n'est pas strictement vrai car il existe toujours un espace réservé au superutilisateur qu'un utilisateur normal ne pourra pas remplir) et cela empêche les attaques de liens directs (hardlinks).

• Toute partition qui peut fluctuer, par exemple /var (surtout /var/log) devrait être également sur une partition distincte. Vous devriez créer /var un petit peu plus grand que la normale car les paquets téléchargés sont stockés dans /var/cache.

• Toute partition où vous voulez installer des logiciels ne faisant pas partie de la distribution devrait être sur une partition distincte. Selon la norme de hiérarchie des fichiers (FHS), c'est /opt ou /usr/local. Si ce sont des partitions distinctes, elles ne seront pas effacées.

• D'un point de vue sécurité, il est souhaitable de mettre les données statiques sur une partition et de monter celle-ci en lecture seule.

Recommendations

---

Point de montage	Options	Description
/	<sans option>	Partition racine, contient le reste de l’arborescence
/boot	nosuid,nodev,noexec (noauto optionnel)	Contient le noyau et le chargeur de démarrage. Pas d’accès nécessaire une fois le boot terminé (sauf mise à jour)
/opt	nosuid,nodev (ro optionnel)	Packages additionnels au système. Montage en lecture seule si non utilisé
/tmp	nosuid,nodev,noexec	Fichiers temporaires. Ne doit contenir que des éléments non exécutables. Nettoyé après redémarrage(sauf mise à jour)
/srv	nosuid,nodev (noexec,ro optionnels)	Contient des fichiers servis par un service type web, ftp, etc.
/home	nosuid,nodev,noexec	Contient les HOME utilisateurs. Montage en lecture seule si non utilisé
/proc	hidepid=1	Contient des informations sur les processus et le système
/usr	nodev	Contient la majorité des utilitaires et fichiers système
/var	nosuid,nodev,noexec	Partition contenant des fichiers variables pendant la vie du système (mails, fichiers PID, bases de données d’un service)
/var/log	nosuid,nodev,noexec	Contient les logs du système
/var/tmp	nosuid,nodev,noexec	Fichiers temporaires conservés après extinction

La partition /boot contient le noyau de démarrage ainsi que le(s) fichier(s) System.map contenant la table des symboles utilisée par celui-ci. Ce fichier est souvent parcouru par différents programmes malveillants afin de construire plus facilement des « exploits » de code noyau. Le partitionnement idéal demande à ce que cette partition ne soit pas montée automatiquement au démarrage (option noauto), et que le montage de celle-ci soit un évènement critique d’un point de vue système (pour une mise à jour ou un correctif noyau par exemple). Mais cette mesure demande d’adapter les outils système à cette configuration particulière, et donc demande une expertise système pointue lors de son déploiement.

RX	Quand la partition /boot ne peut être démontée (ou qu’elle n’existe pas), le(s) fichier(s) System.map doivent être restreints en lecture à root uniquement.

Il faut noter que certains services peuvent toujours avoir besoin d’accéder à une arborescence donnée après une opération de chroot, sans que cette arborescence ne soit rattachée et visible directement depuis la cage chroot. Dans de tels cas, l’usage de points de montage bind est à envisager.

Mise à jour

Il est important de mettre à jour régulièrement le système (noyau et logiciel). De nombreuses vulnérabilités (CVE – Common Vulnerabilities Exposure) paraissent chaque jour pour l’exploitation de failles critiques ou majeures (remote, ddos, …). Le fait de patcher régulièrement diminue drastiquement la surface d’attaque.

Recommendations

---

• Red Hat :

# yum update  
# yum –y upgrade  

• Debian :

# apt-get update –y
# apt-get upgrade -y

Suppression des services et logiciels inutiles

Appliquer les mises à jour et les correctifs du système contribue à corriger les vulnérabilités connues, l'une des meilleures façons de protéger le système contre les vulnérabilités non encore signalées est de désactiver tous les services qui ne sont pas requis pour un fonctionnement normal du système. Cela empêche l'exploitation de vulnérabilités découvertes ultérieurement. Si un service n'est pas activé, il ne peut pas être attaqué.

---

Pour les serveurs Debian

Commande de suppression :

# apt-get purge <service>

• Ci-dessous la liste des services qui doivent être supprimés :
  • is
  • rsh-client
  • rsh-reload-client
  • talk
  • xserver-xorg-core

Modification d'inetd :

Commenter (ou supprimer) les lignes dans le fichier /etc/inetd.conf

#talk dgram udp wait nobody.tty /usr/sbin/in.talkd in.talkd 
#ntalk dgram udp wait nobody.tty /usr/sbin/in.ntalkd in.ntalkd
#shell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd 
#login stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind 
#exec stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rexecd
#telnet stream tcp nowait telnetd /usr/sbin/tcpd /usr/sbin/in.telnetd
#tftp stream tcp nowait root internal
#chargen stream tcp nowait root internal
#daytime stream tcp nowait root internal
#echo stream tcp nowait root internal
#discard stream tcp nowait root internal
#time stream tcp nowait root internal

Liste des services qui doivent être désactivés :

Commande de suppression :

# update-rc.d <service> disable

• avahi-daemon
• rpcbind
• xinetd
• smbd
• squid3
• snmpd

Commande de suppression :

# systemctl disable <service>

• vsftpd
• bind9
• dovecot

Pour les serveurs RedHat

Commande de suppression :

# yum erase <service>

Ci-dessous la liste des services qui doivent être supprimés :

• telnet-server
• telnet
• rsh-server
• ypbind
• ypserv
• tftp
• tftp-server
• talk
• talk-server
• xinetd
• xorg-x11-server-common
• dhcp
• openldap-servers
• openldap-clients
• bind
• vsftpd
• dovecot
• samba
• net-snmp

Commande de suppression :

# systemctl disable <service>

Ci-dessous la liste des services qui doivent être supprimés :

• avahi-daemon
• nfslock
• rpcgssd
• rpcbind
• rpcidmapd
• rpcsvcgssd

Sécurisation de SSH

• Voir : Configuration d'OpenSSH

Activation du service d’audit et de Log

Audit

Les logs système classiques permettent de surveiller une partie de l’activité du système mais un certain nombre d’événements sensibles ne sont pas tracés au niveau du noyau. Auditd est un démon qui permet de surveiller ce qui se passe au niveau du noyau. Une fois activé il se met en écoute de nouvelles règles de surveillance et enregistre dans un fichier de journalisation (/var/log/audit/audit.log) tous les événements correspondants aux règles définies.

Pourquoi installer auditd ?

En utilisant un cadre de vérification puissant, le système peut suivre de nombreux types d'événements.
Par exemple :

• L'accès aux fichiers (voir qui a changé un fichier particulier, détecter les modifications non autorisées)
• La surveillance des appels et des fonctions système
• Détecter les anomalies comme les processus qui tombent
• Commandes utilisées par les utilisateurs

RX	Il est préconisé d’intégrer les logs au sein d'un SIEM comme par exemple celui du C.O.S.C pour que ces logs puissent être supervisées et que les incidents puissent être traités.

Lancement et Activation d’auditd

# systemctl start auditd
# systemctl enable auditd