I. Présentation

L'Active Directory Windows propose une fonctionnalité intéressante permettant de créer une blacklist de mot de passe utilisée lors du paramétrage ou du changement de mot de passe d'un utilisateur. Cette fonction est bien utile car elle évite que des utilisateurs ne choisissent des mots de passe trop simples, en rapport avec leur entreprise ou leur contexte par exemple. Dans cet article, nous allons voir comment interdire aux utilisateurs locaux d'un système Linux de choisir certains mots de passe grâce à PAM et à son module pam_pwquality.

Pour effectuer cette même opération sur un Active Directory, suivez cet article : Active Directory : Auditer la qualité des mots de passe.

Cet article est réalisé sur un environnement CentOS 8.1 à jour.

II. Utilisation et installation de pam_pwquality

Dans un premier temps, nous allons devoir installer un module de la solution PAM (Pluggable Authentication Module) nommé pam_pwquality. Ce module permet d'effectuer certains contrôles sur la qualité des mots de passe lors de leur paramétrage par un utilisateur. Il s'agit d'un module très utile en termes de sécurité, qui permet de garantir une qualité et une robustesse minimale de tous le mots de passe présents sur un système Linux.

Nous allons commencer par regarder quels sont les modules PAM installés sur votre système. Ceux-ci sont situés dans /usr/lib64/security sous le forme de bibliothèques compilées (.so, pour Shared Object):

[root@localhost dict]# ls /usr/lib64/security/ -l
total 1728
-rwxr-xr-x. 1 root root  20240 10 mai    2019 pam_access.so
-rwxr-xr-x. 1 root root  13600  8 nov.  13:56 pam_cap.so
[...]
-rwxr-xr-x. 1 root root  11928 10 mai    2019 pam_nologin.so
-rwxr-xr-x. 1 root root   7808 10 mai    2019 pam_permit.so
-rwxr-xr-x. 1 root root   7776 10 mai    2019 pam_postgresok.so
-rwxr-xr-x. 1 root root  20584 10 mai    2019 pam_pwhistory.so
-rwxr-xr-x. 1 root root  11896 10 mai    2019 pam_pwquality.so
[...]
-rwxr-xr-x. 1 root root  61448 10 mai    2019 pam_unix.so
-rwxr-xr-x. 1 root root  16048 10 mai    2019 pam_userdb.so
-rwxr-xr-x. 1 root root   7816 10 mai    2019 pam_warn.so
-rwxr-xr-x. 1 root root  11912 10 mai    2019 pam_wheel.so
-rwxr-xr-x. 1 root root  24208 10 mai    2019 pam_xauth.so

Si vous voyez un pam_pwquality.so, vous n'avez rien besoin d'installer. Sinon, exécutez la commande suivante :

yum install libpwquality

Comme souligné plus haut, pam_pwquality permet d'effectuer bon nombre de contrôles différents, notamment concernant la structure des mots de passe paramétrés (nombre de caractères, d'alphabet différents, etc.). L'outil cracklib est utilisé pour créer, vérifier et gérer les dictionnaires de mot de passe que nous allons être amené à gérer. Il faut donc l'installer également :

yum install cracklib

III. Rappel sur la configuration de PAM

Nous allons à présent ajouter un nouveau module à la configuration PAM : pam_pwquality. Pour rappel, PAM dispose d'une configuration de base avec un fichier de configuration par application pouvant utiliser PAM, c'est pour cette raison que par défaut, un grand nombre de fichier sont présents dans /etc/pam.d/ :

[root@localhost pam.d]# ls -l
total 108
-rw-r--r--. 1 root root 272 11 mai 2019    atd
-rw-r--r--. 1 root root 192 8 nov. 18:28   chfn
-rw-r--r--. 1 root root 192 8 nov. 18:28   chsh
-rw-r--r--. 1 root root 721 13 sept. 03:42 cockpit
-rw-r--r--. 1 root root 232 10 mai 2019    config-util
-rw-r--r--. 1 root root 328 8 nov. 11:47   crond
-rw-r--r--. 1 root root 701 10 mai 2019    fingerprint-auth
-rw-r--r--. 1 root root 715 8 nov. 18:28   login
-rw-r--r--. 1 root root 154 10 mai 2019    other
-rw-r--r--. 1 root root 168 11 mai 2019    passwd
-rw-r--r--. 1 root root 760 10 mai 2019    password-auth
-rw-r--r--. 1 root root 155 11 nov. 17:52  polkit-1
-rw-r--r--. 1 root root 398 10 mai 2019    postlogin
-rw-r--r--. 1 root root 640 8 nov. 18:28   remote
-rw-r--r--. 1 root root 143 8 nov. 18:28   runuser
-rw-r--r--. 1 root root 138 8 nov. 18:28   runuser-l
-rw-r--r--. 1 root root 743 10 mai 2019    smartcard-auth
lrwxrwxrwx. 1 root root 25  16 janv. 02:53 smtp -> /etc/alternatives/mta-pam
-rw-r--r--. 1 root root 76  8 nov. 18:02   smtp.sendmail
-rw-r--r--. 1 root root 727 8 nov. 16:28   sshd
-rw-r--r--. 1 root root 214 11 nov. 17:50  sssd-shadowutils
-rw-r--r--. 1 root root 566 8 nov. 18:28   su
-rw-r--r--. 1 root root 154 11 déc. 14:43  sudo
-rw-r--r--. 1 root root 178 11 déc. 14:43  sudo-i
-rw-r--r--. 1 root root 137 8 nov. 18:28   su-l
-rw-r--r--. 1 root root 760 10 mai 2019    system-auth
-rw-r--r--. 1 root root 248 3 janv. 13:14  systemd-user
-rw-r--r--. 1 root root 84  11 mai 2019    vlock

Cependant, tous ne sont pas "utiles", nous pouvons voir en analysant ces configurations qu'une majorité d'entre elles ne font que pointer vers des configurations génériques que sont les fichiers suivants :

/etc/pam.d/password-auth
/etc/pam.d/system-auth

Sur certains système ou contextes, ces fichiers peuvent être nommés password-auth-ac, password-auth-am, system-auth-ac, system-auth-am ou encore common-password, common-auth, common-session et common-account. Bref !

Les directives include ou substack sont utilisées pour "importer" les directives d'un autre fichier. Exemple avec le fichier de configuration /etc/pam.d/ssh et spécifiquement le groupe de gestion password :

password include password-auth

On voit ici que le groupe de gestion password de la configuration pour SSH inclut simplement la configuration de /etc/pam.d/password-auth. Pour gérer la majorité des contextes, nous n'avons donc qu'à modifier le contenu de la pile password de ce fichier pour que cela soit pris en compte par toutes les configurations qui y font référence.

Pour rappel, la configuration générique /etc/pam.d/password-auth est majoritairement utilisée comme référence pour les services distants (FTP, SSH), alors que la configuration générique /etc/pam.d/system-auth. est majoritairement utilisée par les services locaux (su, sudo, etc.).

IV. Dictionnaire de mot de passe interdit dans PAM avec pam_pwquality

Après ce bref rappel, regardons le contenu du fichier /etc/pam.d/passwd, commande qui permet de définir ou de modifier les mots de passe utilisateurs :

[root@localhost pam.d]# cat passwd
#%PAM-1.0
# This tool only uses the password stack.
password   substack system-auth
-password  optional pam_gnome_keyring.so use_authtok
password   substack postlogin

Celle-ci fait appel à la configuration générique /etc/pam.d/system-auth, nous allons donc nous intéresser au groupe de gestion password de ce fichier :

password requisite  pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
 
password sufficient pam_unix.so try_first_pass use_authtok nullok sha512 shadow
 
password required   pam_deny.so

Nous voyons ici que le module pwquality est déjà utilisé pour effectuer certaines vérifications. Nous allons de notre côté ajouter l'argument dictpath=, suivi du chemin vers un fichier de mots de passe blacklistés. La pile d'exécution du contrôle password devient donc la suivante dans le fichier /etc/pam.d/system-auth :

password requisite  pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= dictpath=/usr/share/dict/pw_blacklist
 
password sufficient pam_unix.so try_first_pass use_authtok nullok sha512 shadow
 
password required  pam_deny.so

Par défaut, le fichier /usr/share/dict/linux.words contient de nombreux de mot de passe (et noms communs). Il constitue un dictionnaire de base intéressant mais il est loin d'être suffisant dans vos contextes. Je vous conseille donc d'y ajouter vos propres mots de passe à interdire. Vous êtes également libre d'utiliser d'autres dictionnaires en les mettant dans l'argument du module pam_pwquality. C'est ce que nous allons faire ici, nous souhaitons créer une blacklist contenant le mot de passe itconnect2021 (pour l'instant 🙂 ) :

echo "itconnect2021" >> /usr/share/dict/pw_blacklist

Nous devons à présent convertir ce fichier dans un format attendu par le module pwquality, grâce à une commande venant du paquet cracklib précédemment installé :

[root@localhost dict]# create-cracklib-dict -o pw_blacklist pw_blacklist
1 1
[root@localhost dict]# ls -al
total 20
drwxr-xr-x. 2 root root 98 24 janv. 05:17     .
drwxr-xr-x. 90 root root 4096 24 janv. 03:03  ..
-rw-r--r--. 1 root root 14 24 janv.   05:17   pw_blacklist
-rw-r--r--. 1 root root 1024 24 janv. 05:17   pw_blacklist.hwm
-rw-r--r--. 1 root root 29 24 janv.   05:17   pw_blacklist.pwd
-rw-r--r--. 1 root root 16 24 janv.   05:17   pw_blacklist.pwi

Nous voyons que plusieurs fichiers sont créés à partir de notre liste initiale, il sera donc important de reexécuter cette commande à chaque nouvelle modification du dictionnaire initial. Je tente ensuite de paramétrer ce mot de passe interdit depuis une session de mon utilisateur marcel :

[marcel@localhost dict]$ passwd
Changement de mot de passe pour l'utilisateur marcel.
Current password:
Nouveau mot de passe :
MOT DE PASSE INCORRECT : Le mot de passe ne passe pas la vérification dans le dictionnaire - basé sur un mot du dictionnaire

Attention : Si vous effectuez une modification du mot de passe root ou d'un autre utilisateur depuis une session root, ces restrictions ne vous seront pas appliquées.

Nous voyons ici que le mot de passe que j'ajoute, qui est également présent dans la liste des mots de passe interdits créée, est refusé pour une raison explicite : "basé sur un mot du dictionnaire". A noter que le résultat sera le même si je saisie le nouveau mot de passe ItCoNnEcT2021, pwquality effectue également quelques permutations de ce genre sur les mots de passe fournis par les utilisateurs.

En constituant une liste de mots de passe faibles, en relation notamment avec votre contexte (nom d'entreprise, de ville, de région, etc.) vous serez en capacité d'interdire de nombreux mots de passe faibles pour une une meilleure sécurité globale du système d'information. Je vous conseille donc d'appliquer ce type de durcissement sur l'ensemble de vos serveurs Linux et stations de travail. La liste des mots de passe doit reposer sur des listes connues et référencées de mots de passe faibles et sur des éléments de contexte qui vous sont propres.

Le PDG d'Avast, Ondrej Vlcek, a annoncé la fermeture immédiate de Jumpshot, la filiale d'Avast qui est à l'origine de la revente des données de navigation des utilisateurs, dont nous vous parlions la semaine dernière.

Pour rappel, l'enquête menée par Motherboard et PCMag indiquait que Jumpshot revendait les données de navigation des utilisateurs d'Avast qui utilisaient la version gratuite. Des données revendues ensuite à de nombreuses sociétés, notamment Google, Microsoft ou encore Pepsi.

Suite à cette incident, le PDG d'Avast a pris sa décision et il a déclaré : « Je suis arrivé à la conclusion que l'activité de collecte de données n'est plus conforme à nos priorités en matière de respect de la vie privée ».

Depuis 2015, Jumshop récoltait les données de navigation de 100 millions de terminaux, ce qui comparait au nombre d'utilisateurs payants, représente près d'un appareil sur quatre. D'après eux, les données revendues étaient anonymisées mais visiblement en recoupant les données il était envisageable d'identifier certains clients.

Espérons que cette société ne (re)voit pas le jour sous un autre nom, avec les mêmes salariés et que tout reprennent en toute discrétion une fois l'incendie éteint... Cela devait être juteux pour Avast donc il semble quand même difficile de s'en passer, nous verrons dans les mois à venir si cela à des conséquences.

I. Présentation

L'Active Directory s'enrichit au fil des versions de mécanismes de protection pour protéger les comptes disposant de privilèges élevés sur l'infrastructure. Depuis Windows Server 2012 R2, Microsoft a intégré un nouveau groupe baptisé "Protected Users" : mais qu'est-ce qu'il apporte vraiment ?

Pour sécuriser les comptes d'administration, l'Active Directory va modifier certains comportements sur les comptes ajoutés au groupe Protected Users. L'idée est notamment d'éviter que les identifiants soient dérobés sur une machine où le compte est utilisé.

II. Protected Users : quels impacts (et bénéfices) ?

Lorsqu'un compte utilisateur est ajouté au groupe Protected Users, s'appliquent notamment les règles suivantes :

• Les identifiants ne sont pas mis en cache sur les machines. Sur une machine déconnectée du réseau, il ne sera pas possible de se connecter, même si la session a déjà était ouverte sur le poste en question. Le contrôleur de domaine doit être joignable impérativement.
• Le ticket Kerberos (TGT) est délivré à la connexion de l'utilisateur et il ne sera pas renouvelé automatiquement lorsqu'il devient invalide (4 heures, par défaut sur ces comptes).
• Impossible d'utiliser DES ou RC4 pour la pré-authentification Kerberos, d'utiliser NTLM pour s'authentifier, ni CredSSP.

Exemple n°1 : si vous utilisez un compte admin du domaine pour vous authentifier en VPN au travers de l'authentification basée sur l'AD, ça ne fonctionnera plus pour ce compte si il est ajouté au groupe Protected Users.

Exemple n°2 : pour vous connecter en RDP sur un serveur, il sera nécessaire d'utiliser le nom FQDN du serveur, avec l'adresse IP l'accès ne sera pas possible.

Tout cela pour dire qu'il ne faut pas ajouter des utilisateurs à ce groupe sans réfléchir, il convient de réaliser des tests sur votre infrastructure pour bien identifier les éventuelles problématiques.

Attention, ce groupe n'est pas fait pour contenir des objets ordinateurs ou des comptes de service.

Note : les fonctionnalités du groupe Protected Users sont supportées sur Windows Server 2012 R2 et Windows 8.1, et les versions ultérieures donc Windows 10 bien sûr et WS 2016 / 2019.

III. Gérer les membres du groupe

Pour lister les membres du groupe Protected Users et ajouter un nouveau membre, nous avons plusieurs méthodes : tout simplement via le Centre Active Directory, la console Utilisateurs et ordinateurs Active Directory, mais aussi avec PowerShell bien sûr. Ce groupe se situe dans l'OU built-in Users.

Voici la commande :

Get-ADGroupMember -Identity "Protected Users"

Pour ajouter un nouvel utilisateur à ce groupe, c'est également possible en mode graphique et en PowerShell. Par exemple pour ajouter le compte "fb.itconnect" :

Get-ADGroup -Identity "Protected Users" | Add-ADGroupMember –Members "CN=fb.itconnect,CN=Users,DC=IT-CONNECT,DC=LOCAL"

IV. Démo avec mimikatz

Mimikatz est une application gratuite qui est très réputée et répandue lorsqu'il s'agit de s'attaquer à un environnement Windows, et plus particulièrement lorsqu'il s'agit de postes intégrés à un domaine Active Directory.

Sur Windows, le processus lsass.exe (Local Security Authority SubSystem) gère les informations d'identifications, et ils sont notamment stockés en mémoire. Avec Mimikatz, ils peuvent être extrait, notamment dans le but de récupérer le hash NTLM des comptes actifs sur la machine. Imaginez s'il s'agit des informations correspondantes à un compte "Administrateur" sur le domaine : cela peut-être dramatique.

Nous allons voir le comportement dans deux cas : avec un compte administrateur qui n'est pas dans le groupe "Protected Users" et ensuite nous mettrons ce compte dans le groupe pour voir la différence.

L'outil Mimikatz est disponible sur Github. Pour ma part, je vais l'utiliser sur une machine Windows 10 et l'exécuter en tant qu'administrateur (pour gagner du temps...). Attention : de nombreux antivirus bloquent l'exécution de Mimikatz, il faudra donc désactiver Windows Defender pour pouvoir mener à bien cette attaque.

Commençons par réaliser une élévations de privilèges avec Mimikatz sur la machine locale :

privilege::debug
token::elevate

Ensuite, il y a plusieurs commandes disponibles pour afficher des informations... Pour ma part, j'ai utilisé la commande ci-dessous qui affiche notamment des informations sur les utilisateurs connectés :

sekurlsa::logonPasswords

Dans la liste des informations et comptes qui s'affichent, on retrouve assez rapidement le compte "fb.itconnect". Qu'est-ce que je vois comme information : NTLM, soit le hash NTLM du mot de passe de ce compte. Ça sent pas bon pour mon administrateur car avec ce hash en main, des portes s'ouvrent...!

Maintenant, on reprend tout à zéro : imaginons que ce compte est membre du groupe "Protected Users". Si je réalise de nouveau la même opération avec Mimikatz, voici ce que j'obtiens :

Sur la copie d'écran ci-dessus, on peut voir que le hash NTLM n'apparaît plus. Voilà l'un des bénéfices du groupe "Protected Users" où l'on est obligé d'utiliser Kerberos.

Comme je le disais précédemment, un compte membre du groupe "Protected Users" ne sera pas mis en cache sur une machine. Pour pouvoir ouvrir la session, le poste doit être en mesure de joindre le contrôleur de domaine. Avec un compte classique, les identifiants sont mis en cache (pour 10 utilisateurs par défaut), ce qui permettra d'ouvrir la session en mode hors ligne : ce qui est dangereux pour les comptes sensibles.

Les informations des identifiants en cache sont stockées dans le registre au sein de la clé : HKEY_LOCAL_MACHINE\Security\Cache

De façon plus radicale, la mise en cache peut être désactivée sur les postes par l'intermédiaire d'une GPO. Il faudra modifier le paramètre de GPO suivant : "Ouverture de session interactive : nombre de demandes d’ouverture de session à mettre en cache (au cas où le contrôleur de domaine ne serait pas disponible)" qui se trouve sous : Configuration Ordinateur\Paramètres Windows\Paramètres de sécurité\Options de sécurité

Tout cela pour dire qu'il est vivement recommandé d'utiliser le groupe "Protected Users" pour sécuriser les comptes sensibles de l'Active Directory. Bien que ce ne soit pas la seule action à mener, c'est une couche de sécurité intéressante que Microsoft a implémentée depuis Windows Server 2012 R2. A exploiter autant que possible 😉

En 2010, Google a lancé son programme VRP (Vulnerability Reward Program) afin de rémunérer les hackers qui découvrent des failles informatiques dans les outils et services de la firme. Dix ans plus tard, Google annonce avoir versé 21 millions de dollars sur cette période. Rien que pour l'année 2019, Google a versé 6,5 millions de dollars, ce qui est un record.

Communément appelé "Bug bounty", ce concept est très apprécié par les entreprises et les hackers car tout le monde s'y retrouve. En effet, il est préférable de récompenser la personne qui découvre la vulnérabilité plutôt que de devoir réparé des dégâts causés par un piratage, ces coûts pouvant alors être bien plus importants. Google soutient certaines événements de hacking, notamment le BountyCon à Singapour et l'ESCA8 à Londres.

Les différentes vulnérabilités découvertes et corrigées lui permettent de sécuriser Chrome, Android, et ses services comme Google Play. Au fur et à mesure de l'intégration de nouvelles fonctionnalités, les hackers sont toujours prêts à se mettre au défi.

La prime record est de 201 337 dollars suite à une faille importante trouvée dans les smartphones Pixels de Google. Cela a profité à Guang Gong, de la société Alpha Labs. Jusqu'à présent Google a récompensé 461 chercheurs.

Au final, qu'est-ce que 21 millions de dollars sur 10 ans pour Google ? Pas grand chose...

I. Présentation

Dans cet article, je vous propose plusieurs guides de durcissement pour les systèmes d'exploitations GNU/Linux que j'utilise au quotidien. Ce type de guides, notamment lorsque l'on prend en compte les différents blogposts sur internet, sont très nombreux, parfois contradictoires et il est facile de s'y perdre. Je vais ici me contenter de vous conseiller les plus complets et les plus pertinents.

II. Le guide "Recommandations de configuration d'un système GNU/Linux" de l'ANSSI

Ce guide, qui a l'avantage d'être en français est paru le 27 juillet 2012 en version 1.1 et a reçu une mise à jour le 22/02/2019.

Vous le trouverez sur la page suivante : Recommandations de sécurité relatives à un système GNU/Linux

Ce fameux ANSSI-BP-028 (c'est son code de référence) est plutôt complet et comporte plusieurs niveaux de sécurité (minimal, intermédiaire, renforcé et élevé). Dans un premier temps, il est important de vous concentrer sur le niveau "minimal" qui doit être appliqué dans tous les contextes, quelque soit la sensibilité de votre architecture. En fonction de ce que vous souhaitez protéger (des données personnelles, bancaires, médicales), il sera souvent opportun d'envisager l'application des mesures des niveaux supérieurs.

Il s'agit d'une très bonne base sur laquelle travailler et elle vous assurera d'être conforme à la plupart des audits de sécurité internes et externes que vous ferez, l'ANSSI est en France la référence à suivre dans ce domaine. En suivant ce guide, vous tomberez sur des blocs de recommandation numérotées de 1 à 69. Il s'agit des points techniques de sécurité à appliquer, ceux-ci sont parfois accompagné de lignes de commande vous permettant de vérifier ou de corriger ce point technique, mais cela reste assez rare dans ce guide.

Outre la sécurité des systèmes d'exploitation GNU/Linux, l'ANSSI propose un nombre intéressants de guide de durcissement qui sont de très bonnes sources de travail. On citera notamment le guide d’hygiène informatique, les recommandations de sécurité relatives à TLS ou encore le guide d'administration sécurisée. Vous trouverez l'ensemble de ces guides sur cette page : Guides de bonnes pratiques de l'ANSSI

III. Les guides Debian et Centos du CIS

Le CIS (Center for Internet Security) est très productif en ce qui concerne les guides de bonnes pratiques. Pour y accéder, il faut s'inscrire (gratuitement) sur leur plateforme, on obtient alors l'accès à un grande nombre de guides publiés, en cours de relecture ou de rédaction sur des sujets classiques (OS Linux, Windows, etc.) mais aussi sur des technos qui sont plus rares en ce qui concerne les guides bonnes pratiques de sécurité telles que Oracle, postgreSQL, kubernetes, etc.

Les guides concernant les dernières distributions (Debian, Centos, Red Hat) sont également pertinents et un peu plus complets que les guides de l'ANSSI. Certains des points de sécurité qu'ils contiennent sont à mon sens un peu trop poussés. Je vous conseille donc de ne pas forcément tout appliqué mais de parcourir ces guides avec curiosité. Ils ont également l'avantage de contenir les lignes de commande et éléments de configuration permettant de contrôler un point technique mais aussi de le corriger, ce qui est toujours bienvenue.

Pour vous inscrire gratuitement et accéder à l'ensemble des guides : https://workbench.cisecurity.org/

Ces guides du CIS ont l'avantage de contenir une section "Applicable Profiles" qui indique si la cible des durcissements sont des stations de travail, des serveurs, ou les deux. L'interface CIS est également très pratique et agréable pour parcourir les guides, qui sont également téléchargeables au format PDF. Ils ont l'avantage d'être souvent mis a jour et de disposer d'un canal d'échange et de discussion en cas de besoin (si l'on repère une typo où que l'on a une question technique).

Globalement parlant, le site du CIS est, une fois que l'on dispose d'un compte, très utiles pour les besoins en sécurité d'un SI. Ne soyez pas étonné, la création d'un compte demande une validation manuelle (il me semble) et peux donc prendre quelques heures le temps que cette validation arrive.

IV. Le Red Hat Enterprise Linux - Security Guide

Il s'agit là aussi d'un très bonne ressource accessible gratuitement. Je l'utilise cependant moins souvent car elle est plus difficile à parcourir qu'un guide en français ou qu'un guide dans l'interface web du CIS. Ce guide est assez verbeux, c'est à dire que les impacts en termes de sécurité sont plutôt détaillé et cela permet de comprendre ce que l'on fait et surtout pourquoi. Certains points techniques et de configuration sont abordés dans ce guide et sont absents des propositions précédentes, c'est pourquoi il est toujours intéressant de garder celui-ci en tête.

Il dispose également de mises à jour régulières (parution en 2017, dernière mise à jour le 2019-06-25).

• Vous le trouverez ici : Securing Red Hat Enterprise Linux 8
• Ou ici au format PDF : Securing Red Hat Enterprise Linux 8 format PDF

Red hat propose également un grande nombre de guides de configuration et de durcissement sur ses propres produits sur le lien suivant : https://access.redhat.com/documentation/en-us/

D'une manière générale dans le monde professionnel, je vous conseille de toujours vous reposer sur des guides officiels qui ont le mérite d'être rédigés par groupe de plusieurs personnes et d'être régulièrement mis à jour. Ceux-ci peuvent paraître assez indigeste à première vue car ils sont très complets, mais si l'on s'intéresse de façon unitaire à chaque partie, la lecture et l'appréhension du guide se fait naturellement.