Auditeur : Clément Minnens Date de l’audit : 22/04/2020
Date de rédaction du rapport : 23/04/2020
RAPPORT D’AUDIT
Audit de sécurité du serveur « Bigboss » Destinataires :
Philippe LEFRANC : Directeur des Systèmes d’Information Mathieu FALES : Administrateur système & réseau
Commanditaire :
John LAFARGUE : Directeur IT
Contexte :
Cet audit concerne le serveur bigboss fournissant une application web type wordpress.
L’audit est réalisé depuis les locaux de l’entreprise, avec une prise en main sur le serveur via SSH et l’accès au compte « bigboss », super-utilisateur.
L’objectif de l’audit est simple :
- Préconiser les actions de sécurisation en contexte opérationnel sans impact sur le service
- Préconiser les changements à anticiper pour sécuriser l’infrastructure Résultats :
Nombre de recommandations TOTAL : 27 Nombre de recommandations CRITICAL : 21 Nombre de recommandations WARNING : 6
Conclusion :
L’audit du serveur a démontré que le système Ubuntu hébergé sur ce serveur est installé avec une configuration par défaut. La plupart des actions de sécurisations indispensables et immédiates peuvent être effectuées sans incidence sur la disponibilité du service. Le
système présente des failles de sécurité sensibles.
Sommaire
1 / Audit manuel
2 / Audit automatique via Lynis 3 / Conclusion
Audit manuel
Indicateurs rapides :
Nombres de services actifs : 30
Nombre de services inactifs / static : 144 Nombre d’utilisateurs hors-système : 3
Port ouvert : 22 (SSH) / 25 (SMTP sans chiffrement) / 53 (DNS) / 68 (DHCP BOOTP) / 80 (HTTP) / 110 (POP3) / 143 (IMAP) / 953 (BIND)
1 / Bootloader, noyau et modules
La première vérification que nous effectuons se situera au niveau de GRUB, le programme de démarrage de Linux.
Voici les premières recommandations :
Nos vérifications porteront également sur le fichier /etc/default/grub. Il s’avère que le démarrage n’est pas sécurisé, en effet nous pouvons démarrer un shell à l’écran du grub.
Il est recommandé de forcer l’utilisation de l’IOMMU au démarrage du noyau Linux.
Le chargement à chaud des modules n’est pas désactivé. Ceci est également une alerte de sécurité.
2 / Consoles virtuelles
Les consoles virtuelles sont les premiers éléments d’interaction avec l’utilisateur après le processus de démarrage. Elles sont donc accessibles à toute personne qui se retrouve face à la machine. Il est important que plusieurs point soit vérifié ici.
La vérification se fait par le biais du fichier /etc/securetty.
Voici la recommandation pour les consoles virtuelles :
3 / Démarrage
Il est important d’auditez les services qui se lance au démarrage du système :
4 / Composants matériels 4.1/ CPU
La commande more /proc/cpuinfo va nous donner plus d’informations :
Les flags PAE et NX ne sont pas présent ici.
4.2/ Disque
Pour vérifier les partitions nous utiliserons plusieurs commandes : fdisk -l
lsblk
blkid /dev/sda5
La partition principale n’est pas chiffrée :
Le retour de la commande cat /etc/fstab
dévoile que la partition root est monté sans options.
L’idéal pour le partitionnement en termes de sécurité est :
4.2/ Utilisateurs et droits
Le stockage des mots de passe doit être sécurisé et chiffré.
La liste d’utilisateur est stockée dans le fichier /etc/passwd. Une alerte critique est ici remontée, le fichier étant accessible en lecture seule pour tout le monde.
Une politique de sécurité concernant les mots de passe doit également être mise en place. En effet, pour la sécurité du SI, il est important que les utilisateurs aient un mot de passe fort qui expire régulièrement.
Il est possible de modifier les valeurs par défaut pour la gestion des mots de passe grâce au fichier /etc/login.defs.
Les utilisateurs administrateurs devront être défini dans le fichier /etc/sudoers.
4.2/ Mises à jour de sécurité
Il est important de vérifier que les sources pour installer les paquets et pour mettre à jour ces paquets doivent être signé et sûr.
5 / Services 5.1 / Services lancés
L’audit de la configuration des systèmes lancés va nous permettre de faire une opération de
durcissement. Cette opération consiste à configurer les services pour retarder voire empêcher toute tentative de compromission.
Voici l’ensemble des services lancés :
Sous Linux, il existe également un processus de cloisonnement historique nommé chroot. Cette technique utilise l'argument obligatoire, passé à tous les processus lors de leur exécution, désignant leur racine dans l'arborescence et dont la valeur est par défaut est /. Le chrootage consiste à donner à cet argument une valeur différente de / pour ce répertoire (/directory par exemple). Le résultat de cette opération limite le processus affecté dans cette sous-arborescence.
5.1.1 / Apache
La recommandation pour le service web Apache2 serait d’ajouter plusieurs directives :
Pour chaque répertoire, vérifiez la présence de la directive Options -Indexes, qui permet d'empêcher de lister le contenu du répertoire.
Limitez les méthodes autorisées du protocole HTTP selon votre besoin. La plupart du temps, les méthodes GET, HEAD et POST suffisent largement. Les autres méthodes, OPTIONS, PUT, DELETE, TRACE et CONNECT, induisent des risques inutiles. Vérifiez alors la présence de la directive LimitExcept telle que, par exemple :
<LimitExcept GET POST HEAD>
deny from all
</LimitExcept>
6/ Réseau
Voici les quelques recommandations qu’on peut émettre sur ce serveur précisément : Le pare-feu n’est pas configuré pour DROP les paquets non souhaités :
7 / SSH
L’accès SSH est une porte pour les attaquants. Il faut vérifier que la directive PermitRootLogin soit bien défini à no dans le fichier /etc/ssh/sshd_config.
De plus le serveur écoute sur le port par défaut, le port 22.
Audit Automatique avec Lynis
Lynis est un programme shell Open Source développé par CISOfy. Il permet une analyse complète du système d’exploitation.
Le système d’exploitation n’est pas du tout up-to-date, ce qui implique que la version de lynis qu’on va installer via les dépôts ne sera pas la dernière. Pour effectuer l’audit avec la dernière version nous la récupérons sur le site du projet et l’installons hors dépôt.
L’utilitaire sera stocké dans le dossier /usr/local. Nous pouvons vérifier que la version est plus récente :
Nous pouvons désormais démarrer notre audit de sécurité sur le serveur. Le rapport entier est disponible en annexe de ce fichier.
Le rapport que l’on vient d’éditer via Lynis nous apporte des suggestions et alarmes concernant la sécurité de notre système. La liste qui suit reprend les recommandations non citées lors de l’audit manuel.
Pour l’analyse de ce rapport nous nous baserons sur deux mots clés, warning & suggestion. Les warnings sont les alertes remontées par Lynis qui mérite une correction rapide. Les suggestions quant à elle ne sont pas obligatoires mais permettent une sécurité accrue et un index de résultat plus haut.
Cette alerte de sécurité est présente sur le serveur de mail SMTP Postfix également.
Le système installé est UBUNTU 16.04 LTS.
Actuellement la dernière version disponible est là 20.04 LTS. Une mise à jour est nécessaire pour que les paquets ne soient plus vulnérables. Lynis nous remonte ce point avec beaucoup de paquets.
Lynis nous remonte également qu’aucune règle ne sécurise avec le firewall IPTABLES le réseau.
Passons désormais au niveau des suggestions de la part de Lynis :
Il est possible afin de sécuriser le serveur de désactiver le stockage USB afin de diminuer le risque d’attaque.
Lynis apporte des conseils de sécurité supplémentaire pour le serveur Apache :
Concernant le serveur SSH, lynis nous conseille plusieurs durcissements :
Légalement il serait judicieux d’ajouter une bannière légale de sécurité dans le fichier /etc/issue.net pour alerter les utilisateurs non autorisés.
La dernière recommandation émanant de ce rapport sera celle d’ajouter une solution antivirus – anti malware sur le système afin de parfaire sa sécurisation.
Conclusion
Cet audit de sécurité nous aura démontré que le serveur « bigboss » n’est pas up-to-date, que cette non mise à jour peut exposer à des failles de sécurité et vulnérabilité pouvant être exploité par un attaquant.
Les différentes recommandations listées dans cet audit doivent être respectée pour accroitre la sécurité de ce serveur.
Il convient dans un premier temps d’effectué l’ensemble des actions ne nécessitant pas de
modifications de configurations ou de redémarrages, pour finir par les actions nécessitant un accès physique au serveur.
L’outil d’audit automatique que nous utilisons permet de vérifier que les modifications et sécurisations effectuées ont portées leurs fruits.
