En tant qu'administrateur système, vous avez peut-être déjà connu la joie (?) de faire auditer vos systèmes par un professionnel de la sécurité ou de la gestion des risques. Les outils de sécurité utilisés par les auditeurs analysent généralement les systèmes et produisent un rapport pour l'auditeur mettant en évidence les vulnérabilités trouvées sur le système analysé, que l'auditeur présente ensuite à l'équipe qui gère les systèmes. On s'attend à ce que l'équipe d'administration et de gestion résolve les vulnérabilités signalées. Cependant, pour les distributions Linux d'entreprise, les corrections recommandées par l'auditeur peuvent ne pas être le meilleur choix à appliquer pour l'organisation.
Obtenir les informations
En partant d'un exemple, bon nombre de ces outils d'audit commencent par analyser les ports d'un système cible et se connecter à des ports ouverts pour recueillir des données sur les services offerts par la machine. Voici un exemple de scan de port de mon propre système, généré par le nmap commande :
[root@somebox ~]# nmap 10.200.157.174
Starting Nmap 6.40 ( http://nmap.org ) at 2020-01-29 13:40 CET
Nmap scan report for 10.200.157.174
Host is up (0.000010s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
Nmap done: 1 IP address (1 host up) scanned in 0.41 seconds
À partir de cette sortie, vous pouvez voir que les ports 22, 80 et 111 sont disponibles pour les services qui se connectent à ce système. Un outil d'audit de sécurité se connecte alors probablement à chacun de ces ports pour déterminer ce qui s'exécute dessus, ou il peut utiliser un utilitaire de profilage pour collecter et analyser ces données. Je vais utiliser le telnet commande pour se connecter au port 80 de cette machine pour déterminer ce qui s'y exécute :
[root@somebox ~]# telnet 10.200.157.174 80
Trying 10.200.157.174...
Connected to 10.200.157.174.
Escape character is '^]'.
help
HTTP/1.1 400 Bad Request
Date: Wed, 29 Jan 2020 12:46:39 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux)
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
</body></html>
Connection closed by foreign host.
Une fois la connexion établie, j'ai dû faire une demande au service. Dans ce cas, j'ai tapé le mot "help" qui, selon le service, peut être une commande. Cependant, pour le service exécuté sur le port 80 de ce système, help n'est pas une commande comprise. En conséquence, une erreur est produite. L'en-tête contient de nombreuses informations sur le système et le service. Plus précisément, le service sur ce port est Apache version 2.4.6.
Effectivement, si je vérifie cette information en consultant une yum list , Apache version 2.4.6 est la version installée et en cours d'exécution sur la machine :
[root@somebox ~]# yum list httpd
… output truncated…
Installed Packages
httpd.x86_64 2.4.6-89.el7_6.1 @rhel-x86_64-workstation-7.6
Traitement du rapport de l'auditeur
C'est là que les choses commencent à devenir intéressantes. D'après mon expérience, ce qui se passe, c'est que le rapport d'audit atterrit sur le bureau et qu'il dit quelque chose comme :
Détection de l'ancienne version d'Apache (2.4.6) qui présente plusieurs vulnérabilités qui ont été fermées dans les nouvelles versions d'Apache.
Recommandation :Installez la version mise à jour d'Apache, 2.4.41, la plus récente.
À ce stade, en tant que déploiement Linux d'entreprise, vous devez vous arrêter. Comprenez que le rapport de l'auditeur souligne que, selon les informations d'analyse du système, ce système peut avoir des vulnérabilités ouvertes. Le rapport de l'auditeur est exact que l'installation de la version la plus récente d'Apache à partir d'apache.org résoudrait ce problème. Cependant, en tant que système Linux d'entreprise, ces vulnérabilités potentielles sont probablement déjà fermées dans la version d'Apache actuellement déployée sur le système.
Notez que la version sur le système est 2.4.6-89.el7_6.1, où 2.4.6 est le numéro de version réel et le numéro de version supplémentaire pour ce paquet est 89.el7_6.1. Les distributions Enterprise Linux prennent souvent des correctifs pour les problèmes des versions plus récentes et rétroportent ces correctifs dans une base de code plus ancienne, puis compilent une version mise à jour de cet ancien progiciel. Pour Red Hat Enterprise Linux, le système d'exploitation de mon système d'exemple, les ingénieurs qui gèrent le package Apache suivent ces modifications appliquées via ce numéro de version supplémentaire sur le package rpm.
Certains auditeurs le savent déjà, et certains outils prennent également en compte ce type de gestion logicielle. Parfois, cependant, vous travaillerez avec quelqu'un qui utilise un outil de numérisation moins sophistiqué. Non seulement cela, cette personne peut également ignorer que l'ancienne version d'Apache sur ce système est la correcte version à installer sur cette machine, et que les vulnérabilités de sécurité qui pourraient concerner les responsables de la sécurité ou de la gestion des risques sont déjà fermées. Et en tant qu'administrateur système, il vous incombe souvent d'expliquer pourquoi votre organisation ne devrait pas installer la version la plus récente de ce package, contrairement à la recommandation de l'auditeur.
D'après mon expérience, l'une des meilleures façons d'illustrer ce point consiste à examiner les données supplémentaires incluses dans la version Linux de votre entreprise de ce progiciel. De nombreuses distributions Linux d'entreprise utiliseront des fonctionnalités telles que le journal des modifications RPM pour mettre en évidence ces données. Voici les informations de mon exemple de système :
[root@somebox ~]# rpm -q httpd --changelog
* Tue Jun 25 2019 Lubos Uhliarik <> - 2.4.6-89.1
- Resolves: #1719722 - CVE-2018-1312 httpd: Weak Digest auth
nonce generation in mod_auth_digest
… output truncated …
Selon l'avis CVE lié ci-dessus, cette vulnérabilité n'a été corrigée dans Apache qu'après 2.4.29. Cependant, vous pouvez voir dans la sortie du journal des modifications de ce package qu'un correctif pour CVE-2018-1312 a été rétroporté et appliqué à la base de code actuellement installée, qui est basée sur Apache 2.4.6. Ce fait signifie que mon exemple de système n'est pas vulnérable à cet exploit, bien qu'il s'agisse d'une ancienne version du logiciel Apache.
Pourquoi tout cela est-il important ? Probablement, si vous utilisez une distribution Linux d'entreprise, vous le faites parce que vous souhaitez réduire au minimum les modifications, les conflits potentiels et d'autres problèmes d'incompatibilité logicielle. La mise à niveau d'Apache, comme indiqué par la recommandation d'audit, irait à l'encontre de l'objectif consistant à limiter les modifications au minimum. Si vous êtes un client bénéficiant d'un support commercial, votre fournisseur ne prendra probablement plus en charge les problèmes liés à Apache sur cette machine si vous passez à une version qui n'est pas livrée avec sa distribution.
Conclusion
Pour survivre à un rapport d'audit, comme dans l'exemple ci-dessus, vous devez travailler avec l'auditeur pour vous assurer qu'il comprend comment les packages Linux d'entreprise sont maintenus (que la version affichée sur le port peut ne pas être la même que la version installée sur le système) , et que le conditionneur Linux d'entreprise conserve généralement des versions plus anciennes de ces packages pour tenir compte des vulnérabilités qu'un auditeur, un professionnel de la sécurité informatique ou un associé de la gestion des risques pourrait trouver. L'utilisation de données telles que les informations du journal des modifications peut aider à démontrer ce concept de rétroportage et de gestion des packages Linux d'entreprise.
Vous voulez essayer Red Hat Enterprise Linux ? Téléchargez-le maintenant gratuitement.