FreshRSS

🔒
❌ À propos de FreshRSS
Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

Sécurité DNS – DoH : Qu’est-ce le DNS over HTTPS ?

10 juin 2021 à 11:30

I. Présentation

Le DNS over HTTPS (DoH) est une norme qui a pour objectif de chiffrer les requêtes DNS entre votre machine et votre serveur DNS. Comment fonctionne-t-il ? Est-il fiable ? Est-ce que ce protocole permet de protéger ma vie privée ? Différentes questions se posent et dans ce premier article sur le sujet, je vais vous en parler.

🎥 Vidéo complète sur le sujet : de la théorie à la pratique avec la configuration des navigateurs et une démo sous Windows 10 avec une rapide analyse de trames.

Le DNS est l'un des protocoles les plus anciens et surtout, c'est un protocole indispensable que l'on utilise tous au quotidien. Pour rappel, il sert à traduire les noms de domaine en adresse IP, alors d'un point de vue des utilisateurs il facilite grandement l'utilisation d'Internet au quotidien. On retient le nom de domaine d'un site, et non son adresse IP sinon cela pourrait être compliqué.

Néanmoins, le protocole DNS a beau être précieux, il a une faiblesse majeure : il n'a pas été pensé pour être sécurisé (comme les autres protocoles de sa génération, en fait). Forcément cela pose des problèmes, d'autant plus que ces dernières années le respect de la vie privée est devenu un enjeu majeur, tout comme la sécurité des données au sens large.

Aujourd'hui, le protocole HTTP non sécurisé dispose d'une version sécurisée avec le HTTPS, les protocoles de messagerie disposent aussi de versions sécurisées, etc... Quid du protocole DNS ?

Psst... Si vous ne maîtrisez pas la notion de DNS, je vous propose de découvrir ma vidéo "Le DNS pour les débutants" :

II. La notion de résolveur DNS

Le résolveur DNS correspond au serveur DNS sollicité lorsque votre machine a besoin de traduire un nom de domaine en adresse IP. Une étape indispensable pour contacter le bon serveur et accéder à votre site préféré.

Concrètement, lorsque vous contactez un site Internet en saisissant son nom de domaine directement dans la barre d'adresse, votre machine va envoyer une requête DNS au résolveur DNS pour lui poser une question simple : "Peux-tu m'indiquer l'adresse IP correspondante au site it-connect.fr ?". Si la réponse est connue, le serveur va répondre : "L'adresse IP du site it-connect.fr est 1.2.3.4", et votre machine va se connecter sur ce serveur.

Pour obtenir cette réponse, le résolveur va regarder dans son cache s'il a déjà l'information et si elle est toujours valide. Dans le cas où il n'a pas l'information, il va contacter le serveur DNS faisant autorité pour la zone de notre domaine afin de l'obtenir.

Sur Windows, on peut obtenir facilement l'adresse IP correspondante à un nom de domaine grâce à l'outil natif "nslookup". Il existe aussi sous Linux, mais il y a d'autres alternatives. L'utilisation basique de cet outil consiste à préciser le nom de domaine à résoudre : le résolveur DNS configuré sur votre machine (votre carte réseau) sera sollicité.

nslookup www.france.fr

A. L'échange entre la machine et le résolveur DNS est-il sécurisé ?

Cet échange entre votre machine et le résolveur DNS s'effectue en clair sur le réseau.

Lorsqu'un échange s'effectue en clair sur le réseau, cela signifie que le contenu de la requête, c'est-à-dire le contenu du message, est lisible. Autrement dit, il n'est pas protégé par du chiffrement.

Si un attaquant intercepte cette requête, il pourrait la consulter, la modifier et vous retourner une réponse falsifiée dont l'objectif serait de vous orienter vers un site Internet malveillant. Ce site malveillant pourrait être une copie du site sur lequel vous souhaitez accéder dans le but de récupérer vos identifiants de connexion, par exemple. Dans ce cas, nous parlerons d'une attaque de l'homme du milieu (man in the middle) où "l'homme du milieu" est représenté par l'attaquant puisqu'il se situe entre vous et le résolveur DNS.

Par défaut, le protocole DNS n'a pas de mécanisme pour s'assurer de l'authenticité de la réponse : qu'est-ce qui me garantit que je vais bien consulter le bon site Internet ? Autrement dit, le serveur DNS peut renvoyer n'importe quelle adresse IP, le client DNS lui fera confiance.

Cet exemple (il y en a d'autres) met en évidence ce besoin de sécuriser les échanges entre votre machine et le résolveur DNS.

B. Quel résolveur DNS doit-on utiliser ?

Au-delà de la problématique autour de la sécurité des échanges, il y a une autre question que l'on peut se poser : quel résolveur DNS doit-on utiliser ? Est-ce qu'il y a des résolveurs DNS plus fiables que d'autres ?

Prenons un exemple. Lorsque vous êtes chez vous et que vous utilisez la configuration par défaut de votre Box, vous utilisez les serveurs DNS de votre fournisseur d'accès à Internet (FAI). À première vue, ces résolveurs DNS sont fiables et, éventuellement, on peut dire qu'ils sont neutres. Mais ce n'est pas le cas.

Dans le cas où une décision de justice ordonne le blocage d'un site spécifique (ce qui est déjà arrivé pour des dizaines de sites de streaming tels que Allostream et Time2watch), les serveurs DNS des FAI ne répondront plus aux requêtes lorsqu'un client DNS demande l'adresse IP correspondante à un domaine bloqué. Pourtant le site existe et il est en ligne. On parle alors de résolveurs DNS menteurs.

En alternative, nous avons bien sûr les DNS de Google notamment le fameux "8.8.8.8" que certains connaissent surement. Disons que Google n'est pas réputé pour respecter la vie privée des utilisateurs donc si on peut en trouver un autre, ce n'est pas plus mal. Utiliser le DNS de Google, cela veut dire que l'on autorise Google à garder l'historique de nos requêtes DNS et potentiellement, à l'exploiter. Mais alors, quel résolveur DNS choisir ?

En parlant du DNS de Google, il y a d'ailleurs une histoire assez incroyable à ce sujet. En 2014, la Turquie avait décidé de bloquer Twitter et YouTube. Pour contourner cette censure, les internautes turcs utilisaient les DNS de Google. Pour faire passer le message, il y avait même des inscriptions sur les bâtiments pour diffuser l'adresse du DNS de Google. Le gouvernement a contre-attaqué en demandant aux FAI que les DNS de Google soient bloqués en redirigeant les requêtes vers des sites mis en place par les FAI.

Source : 01net.com - https://www.01net.com/actualites/censure-les-fai-turcs-interceptent-les-services-google-617176.html

Comme alternative à Google, il y a depuis 2018, le résolveur DNS du géant Cloudflare que vous pouvez utiliser en utilisant l'adresse IP "1.1.1.1". Il se veut rapide et respectueux de la vie privée, je pense que c'est un bon choix, mais il reste américain. Dans le doute, vous pouvez vous tourner vers le résolveur DNS Quad9, exploité par la Fondation Quad9 basée en Suisse et accessible à l'adresse IP 9.9.9.9 (d'où le nom Quad9). Je reviendrai plus en détail sur le choix du résolveur DNS au moment d'en choisir un à utiliser avec le protocole DNS over HTTPS : tous les résolveurs ne sont pas compatibles.

En fait, ce qu'il faut retenir c'est que le résolveur DNS n'est pas là pour sécuriser le protocole DNS, mais il a un rôle à jouer dans le respect de la vie privée : en quelque sorte, vous devez avoir confiance en votre résolveur DNS.

Pour vous convaincre que le résolveur DNS a un rôle à jouer dans le respect de la vie privée, lisez ce qui suit... Si vous utilisez toujours le même résolveur et que celui-ci garde un historique de vos requêtes DNS, ce dernier pour facilement retracer l'ensemble des sites sur lesquels vous vous rendez. Votre adresse IP publique (qui est un peu comme votre adresse postale sur Internet) sera liée à un ensemble de noms de domaine, ce qui permettra de dresser un profil type. Par exemple si l'adresse IP 3.4.5.6 demande l'adresse IP correspondant au site it-connect.fr, puis openclassrooms.com, puis pole-emploi.fr. On peut deviner que vous recherchez un emploi dans l'informatique et que vous êtes sans emploi, étudiant ou en reconversion professionnelle (simple exemple).

III. Quelles solutions pour sécuriser les échanges DNS ?

Pour répondre à la question "comment sécuriser les échanges DNS ?", il y a plusieurs pistes à explorer. Plusieurs termes reviennent souvent : DNSSEC, DNS over TLS, DNS over HTTPS, voire même DNSCrypt. Dans le cadre de la présentation de DNS over HTTPS, je vais m'intéresser aux trois premiers cités.

A. DNSSEC

Le DNSSEC (Domain Name System Security Extensions) est un protocole de communication qui a pour objectif d'apporter une couche de sécurité au protocole DNS. Les ingénieurs de l'IETF l'ont créé dans les années 1990.

Par l'intermédiaire de signatures numériques, le propriétaire d'une zone DNS va pouvoir signer les données des enregistrements DNS. C'est bien le contenu de la zone qui est signé et sécurisé, non pas les requêtes DNS. L'objectif étant d'authentifier le serveur qui répond à la requête DNS, mais aussi de s'assurer de l'intégrité de la réponse (pour être sûr qu'elle n'a pas été modifiée).

Cette méthode s'appuie sur de la cryptographie à clé publique où chaque zone dispose d'une paire de clés publique-privée. La clé privée reste secrète tandis que la clé publique sera publiée dans la zone directement. C'est intéressant, car cela va permettre à un résolveur DNS de vérifier l'authenticité des données de la zone DNS grâce à la clé publique et à la vérification des signatures. Dans le cas où l'authentification des données est réussie, le résolveur DNS retourne la réponse au client DNS, alors que si la signature est incorrecte, une erreur est renvoyée au client DNS. Cela peut signifier qu'il s'agit d'une attaque.

Concrètement, DNSSEC va permettre de lutter contre différentes attaques, et particulièrement l'empoisonnement du cache DNS, qui consiste à envoyer de fausses informations à un résolveur DNS qui cherche à résoudre un nom. Cette fausse information sera ensuite envoyée aux clients DNS. On dit que le cache est empoisonné, car il contient de fausses informations.

Pour que le mécanisme de protection de DNSSEC soit pleinement efficace, il faut que l'ensemble de la chaîne soit signée pour créer une chaîne de confiance. En fait, si l'on prend l'exemple du domaine "it-connect.fr", il faut appliquer DNSSEC sur la zone "it-connect.fr", mais également sur la zone ".fr" qui correspond à son domaine de premier niveau (ccTLD, gTLD, etc.). Rassurez-vous, c'est le cas pour toutes ces zones de premiers niveaux.

Pour activer le DNSSEC sur un domaine, au niveau de votre hébergeur ce n'est pas plus compliqué que de cocher une case dans les options de votre domaine. Par exemple chez OVH, il y a une option nommée "Délégation sécurisée - DNSSEC". Sachez également que DNSSEC peut être activé pour sécuriser la zone DNS d'un annuaire Active Directory.

Le DNSSEC est un premier pas en avant puisqu'il permet de s'assurer que le contenu de la réponse que l'on reçoit est authentique, qu’elle est saine et qu'elle correspond bien à notre requête. Néanmoins, il n'apporte pas de réponse à la problématique suivante : comment chiffrer les échanges DNS entre la machine et le résolveur DNS ?

B. DNS over TLS

Le DNS over TLS (DoT) est une norme qui a pour objectif de chiffrer le trafic DNS et permettre de sécuriser les échanges entre une machine et un résolveur DNS. Grâce à ce chiffrement, les attaquants (ainsi que les FAI) ne peuvent pas lire les données du trafic DNS, ni le modifier : une excellente protection contre les attaques de type "homme du milieu".

Le protocole TCP est utilisé pour établir la connexion par l'intermédiaire du port 853. Il s'agit d'un port dédié et cela peut s'avérer contraignant si le port est bloqué par le pare-feu qui se situe en sortie de votre réseau. Les paquets DNS sont chiffrés avec le protocole TLS pour sécuriser leur transmission.

C. DNS over HTTPS

Le DNS over HTTPS (DoH) est également une norme et elle est similaire au DNS over TLS. Clairement, son objectif est de chiffrer les échanges entre la machine qui effectue la requête DNS et le résolveur DNS en lui-même.

Là où il est différent, c'est dans son fonctionnement. Le protocole HTTPS est utilisé pour établir la connexion, ce qui implique que l'on utilise un port standard et qui sera celui du HTTPS : le port 443. Le trafic DNS quant à lui sera encapsulé au sein de la connexion HTTPS, tout en sachant que cette connexion bénéficie du chiffrement via TLS.

L'intérêt du DNS over HTTPS en comparaison du DNS over TLS, c'est qu'il utilise un protocole et un port standard : le HTTPS/443. Ce qui va lui permettre de passer plus facilement au travers des pare-feux, mais aussi de noyer les requêtes DNS dans la masse de trafic HTTPS.

Note : Le DNS over HTTPS correspond à la RFC 8484

Le DoH est probablement plus intéressant pour améliorer le respect de la vie privée des utilisateurs. Par contre, le trafic est difficilement identifiable, ce qui complique la tâche des administrateurs.

IV. DNS over HTTPS : quel résolveur choisir ?

Comme nous venons de le voir, le DoH permet de chiffrer les échanges DNS. Par contre, le résolveur DNS que l'on utilise sera toujours en mesure de savoir ce qu'on lui a demandé comme requête DNS : la requête n'est pas anonyme, elle est envoyée depuis notre machine.

Si l'on veut vraiment aller jusqu'au bout des choses, non seulement il faut utiliser le DNS over HTTPS pour sécuriser les échanges DNS, mais il faut aussi choisir un résolveur DNS dans lequel nous avons confiance. Un résolveur DNS respectueux de la vie privée, en fait. Le DoH n'empêchera pas le serveur DNS de mentir comme c'est le cas lorsqu'un FAI bloque un site suite à une décision de justice, et il n'empêchera pas non plus le résolveur DNS de collecter les données sur les requêtes DNS émises par les clients DNS.

Un bon résolveur DNS est un résolveur DNS qui n'applique pas de censure (à part éventuellement contre les sites malveillants) et qui ne collecte pas de données liées à l'utilisation. S'il est massivement utilisé c'est encore mieux, comme ça votre trafic sera noyé dans la masse. Les résolveurs DNS de Cloudflare et Quad9 sont compatibles DoH et ils me semblent pertinents, avec une petite préférence pour le second qui est basé en Europe (Suisse). Si vous en connaissez un, n'hésitez pas à partager l'information.

La théorie est posée, maintenant il reste à voir comment utiliser DoH sur son ordinateur, sa tablette ou son smartphone.

La bonne nouvelle, c'est que dans les prochains articles, nous verrons comment utiliser le DNS over HTTPS avec différents navigateurs (Firefox, Chrome, Edge ou encore Brave), mais aussi sur Windows 10.

The post Sécurité DNS – DoH : Qu’est-ce le DNS over HTTPS ? first appeared on IT-Connect.

Comment faciliter la remontée de vulnérabilités ?

31 mai 2021 à 10:30

I. Présentation

Dans le dernier bulletin d'actualité du CERT-FR, l'ANSSI fait un retour d'expérience sur les campagnes de signalement de vulnérabilités qu'elle mène auprès d'organisations privées ou publiques en France.

En effet, depuis qu'un texte de loi a été publié en 2018, l'ANSSI assure un service de veille active des vulnérabilités critiques. Ainsi, l'Agence effectue des scans automatisés envers des organisations françaises de tout type et peut également servir de relais entre un chercheur indépendant ayant trouvé une vulnérabilité et une organisation.

Par exemple, lors de la parution d'une nouvelle vulnérabilité critique, telle que la CVE-2019-19781 ayant impactées les services Citrix en 2019, l'ANSSI a effectué des scans réseau sur l'Internet français. Ceux-ci sont lancés sur un ensemble d'adresse IP relatives à des organisations françaises et l'ANSSI peut alerter les propriétaires des services vulnérables relevés. Pour cette vulnérabilité spécifique, par exemple, l'ANSSI fournis les chiffres suivants :

Le 3 janvier 2020, l’ANSSI avait pu identifier 870 adresses IP vulnérables à la CVE-2019-19781 affectant certains produits Citrix. En janvier 2021, 134 adresses IP étaient encore vulnérables à la CVE-2019-19781. En 2020, l’ANSSI a pu constater 15 incidents de sécurité affectant des entités publiques et privées importantes dont l’origine était attribuée à la vulnérabilité CVE-2019-19781.

II. Faciliter le contact avec l'ANSSI/les chercheurs

Il arrive cependant à l'ANSSI ou aux chercheurs indépendants que le contact avec le propriétaire d'un actif vulnérable soit difficile à établir. Ainsi, l'ANSSI dans son RETEX fournis quelques conseils afin d'être facilement joignable :

A. Informations WHOIS

Les informations d’enregistrement des noms de domaine doivent être maintenues à jour auprès du registraire.

L'une des première source d'information est en effet la base WHOIS, qui contient l'identité et les contacts des propriétaires d'un nom de domaine. La base WHOIS est consultable via la commande Linux WHOIS ou via de nombreux sites web (https://viewdns.info/whois/). Aujourd'hui, les hébergeurs proposent par défaut l'anonymisation des informations présentées dans l'enregistrement WHOIS, cela à des fins de protection de la vie privée. Si l'option est intéressante pour les personnes physiques, elle ne doit pas être utilisée par les entreprises. Dans d'autres cas, les informations présentes dans cette base sont obsolètes, par exemple : la personne ayant souscrit au nom de domaine n'est plus dans l'entreprise.

Voici en exemple le contenu d'un enregistrement WHOIS correctement rempli : 

Enregistrement WHOIS du domaine ssi.gouv.fr
Enregistrement WHOIS du domaine ssi.gouv.fr

Il est donc conseillé de faire régulièrement (disons une fois par an) le tour de l'ensemble des informations WHOIS des noms de domaine appartenant à l'entreprise afin d'être certains que ces informations sont toujours valides.

B. Informations des certificats SSL

Les certificats x509 utilisés doivent mentionner les bonnes informations concernant le propriétaire (il est déconseillé d’utiliser des certificats auto-signés tout comme les certificats proposés par défaut lors de l’installation du logiciel ou du matériel).

Les informations contenues dans les certificats publics sont également utilisables pour identifier le propriétaire d'un actif. Voici un exemple avec le site whatsapp.net, dont le propriétaire est l'entreprise Facebook :

Indication de l'organisation propriétaire du domaine whatsapp.com
Indication de l'organisation propriétaire du domaine whatsapp.net

Là encore, ces informations peuvent s'avérer fausses ou obsolètes. Pour une entreprise, il est conseillé de mettre des informations à jour et correspondant à la réalité, rien ne sert de mettre une fausse organisation ou adresse, etc. Un attaquant saura multiplier les sources pour trouver des informations valides.

C. Consultation des communications

Les adresses de contact doivent être consultées régulièrement par leurs propriétaires.

De toute évidence, ces adresses mails seront publiques et donc utilisées pour du spam ou des annonces commerciales. Néanmoins, il reste important de ne pas indiquer des adresses mails "poubelles" car leur publication garde un intérêt certains : être averti et contacté facilement en cas de découverte d'une vulnérabilité (entre autre).

D. Choix des contacts indiqués

Le destinataire doit être à même de juger de l’importance de la communication.

Autrement dit, l'adresse mail, postale ou le numéro du contact indiqué dans ces différentes sources doit avoir compétence à évaluer une alerte de sécurité. Si vous indiquez l'adresse mail du PDG de la boite, il n'aura peut être pas le temps ou le savoir nécessaire pour apprécier une telle alerte. Il est préférable d'indiquer le contact du/de la DSI, RSSI ou même une mailing-list regroupant plusieurs personnes compétentes, le SOC/CERT si vous en avez un, reste la meilleur option.

Enfin, je rajoute à ces différentes propositions l'utilisation du fichier /.well-known/security.txt, il s'agit d'un standard proposé par différents chercheurs en sécurité permettant de trouver facilement les bons contacts pour un signalement de vulnérabilité. Son fonctionnement est à l'image du fichier robots.txt pour les crawlers automatisés (Bing, Google, etc.). Un générateur automatique du fichier est même proposé : https://securitytxt.org/

Voici un exemple :

Fichier security.txt rempli
Fichier security.txt rempli


Enfin, l'ANSSI dans son RETEX nous parle également de la prise en compte du signalement, le fameux "on fait quoi maintenant ?". C'est là que les procédures internes de l'entreprise doivent être utilisés, notamment concernant la gestion des alertes et des incidents, ce qui implique qu'elles soit définies à l'avance et non pas improvisées lorsqu'un signalement arrive :). Dans le cas où vous passez totalement ou partiellement par un infogérant, il faut espérer que des clauses particulières concernant la sécurité soient présentes dans votre contrat. Si ce n'est pas le cas, je vous oriente vers ce guide : Maîtriser les risques de l'infogérance 

III. Signaler une vulnérabilité

Si vous êtes un chercheur en sécurité ayant découvert une vulnérabilité, je vous conseille d'essayer de faire correspondre votre situation à l'un de ces deux cas de figure :

  • Si votre cible possède un fichier security.txt, une page de type hall of fame (https://unite.un.org/content/hall-fame) ou même un programme de bug bounty, utilisez ces moyens pour remonter des vulnérabilités en vous assurant de respecter les conditions indiquées (le fameux scope) et montrez dans vos interactions comme dans vos tests que vos intentions sont bienveillantes (pas besoin de dumper la base utilisateur, montrer que c'est possible suffit).
  • Si ce n'est pas le cas, et que vous avez affaire à une entité française, passez par l'ANSSI, qui peut jouer le rôle d'intermédiaire tout en protégeant votre identité. Les modalités de signalement auprès de l'ANSSI sont décrites sur cette page : Alertes aux vulnérabilités et failles de sécurité . Dans ce cas précis, vous êtes protégés par la loi :
https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000033206854/
https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000033206854/

Attention, l'ANSSI ne sera surement intéressée que par des vulnérabilités conséquentes sur des entités importantes, pas la peine de leur signaler une XSS sur un blog de jardinage 🙂

Si vous ne rentrez dans aucun de ces cas de figure, mon avis est généralement de ne pas remonter de vulnérabilités, notamment lorsque l'on s'attaque à des environnement de production, en opposition à des applications que l'on peut installer en local comme un Owncloud, un Firefox, ou autre. Il m'est arrivé de croiser des chercheurs pour lesquels la poursuite pénale n'était pas loin, aussi louables étaient leurs intentions, certaines entreprises ont une philosophie encore très vintage. A vos risques et périls donc. 😉

Dernier bulletin du CERT-FR : Retour d’expérience sur les campagnes de signalement de vulnérabilités

The post Comment faciliter la remontée de vulnérabilités ? first appeared on IT-Connect.

PowerShell – Comment générer un mot de passe aléatoire ?

20 mai 2021 à 11:00

I. Présentation

Créer des comptes Active Directory pour les nouveaux collaborateurs arrivant dans l’entreprise, c’est l’une des tâches les plus courantes et les plus répétitives qui soit.

C’est d’ailleurs l’une des premières tâches que vous automatisez.

Et la même question revient à chaque fois : comment faire pour automatiser la création d’un mot de passe aléatoire en PowerShell ?

Je vois souvent dans vos scripts deux cas de figure :

  • Le premier : mettre un mot de passe par défaut en « Password1 », à changer à la première connexion
  • Le second : Générer un mot de passe dans une application telle que Keepass ou motdepasse.xyz, puis le copier/coller dans le terminal PowerShell, pour finaliser la création du compte Active Directory.

Et bien, vous allez maintenant pouvoir utiliser un troisième cas de figure : une fonction vous permettant de générer un mot de passe aléatoire conforme à votre politique de sécurité.

🎥 Disponible au format vidéo :

II. Prérequis

Un seul et unique prérequis à respecter :

  • PowerShell version 5.1 ou +

III. La méthode .NET

La première possibilité (et celle qui demande le moins de lignes de code), c’est d’utiliser une méthode existante en .NET.

Pour cela, ajoutez dans votre script les commandes suivantes :

Add-Type -AssemblyName 'System.Web'
[System.Web.Security.Membership]::GeneratePassword($Length, $SpecialCharacters)

Il vous suffit de remplacer la variable $Length par le nombre de caractères à respecter, et la variable $SpecialCharacters par le nombre minimal de caractères spéciaux à respecter.

Par exemple, pour générer un mot de passe de 10 caractères, avec un minimum de 2 caractères non alphanumériques, il vous faut taper :

[System.Web.Security.Membership]::GeneratePassword(10, 2)

Mais cette méthode comprend un inconvénient majeur : vous pouvez vous retrouver avec des mots de passe à plus de 2 caractères spéciaux, certains avec uniquement des minuscules, etc. Ce qui fait qu’on peut se retrouver avec des mots de passe ne respectant pas la politique de mot de passe de l’entreprise, ou alors qui la respecte, mais qui sont tellement difficile à taper pour l’utilisateur que vous allez vous retrouver très rapidement à le changer dans l’Active Directory.

Voici quelques exemples :

IV. Créer sa propre fonction PowerShell

Du coup face à ces deux problématiques majeures, j’ai créé une fonction PowerShell pour générer un nouveau mot de passe aléatoire pour un utilisateur, tout en :

  • Pouvant choisir la taille du mot de passe, le nombre de majuscules à mettre, le nombre de chiffres ainsi que le nombre de caractères spéciaux
  • Respectant la politique de mot de passe de l’entreprise

Copier un code qui fonctionne c’est top, notamment pour vous dépanner d’un coup dur. Mais comprendre ce qu’on a copié, et pourquoi ça fonctionne, c’est mieux. Décomposons donc ensemble la fonction que l'on va créer.

A. Explications

On commence par déclarer notre fonction.

J’ai nommé la fonction New-RandomPassword afin de respecter la convention de nommage en PowerShell, qui est Verbe-Nom.

function New-RandomPassword {
    [CmdletBinding()]
    Param()
    Begin {}
    Process {}
    End {}
}

Bien, on a maintenant un squelette vide, qu’il va falloir remplir.

Commençons par lui indiquer quels sont les paramètres de la fonction. Autrement dit, quelles sont les options que l’on va pouvoir lui passer lorsqu’on y fera appel.

Nous avons besoin de 4 paramètres, afin de pouvoir générer un mot de passe aléatoire qui colle parfaitement à votre politique de sécurité / à vos besoins spécifiques :

  • La taille du mot de passe en nombre de caractères
  • Le nombre de majuscules
  • Le nombre de chiffres
  • Le nombre de caractères spéciaux (non-alphanumériques)

Ces 4 paramètres sont de type [int] : ils n'accepteront qu’un chiffre comme valeur.

On va également considérer que le premier paramètre, la taille du mot de passe, est obligatoire (mandatory). Sans cela, on ne sait pas quelle taille générer, et donc quel mot de passe générer.

Les autres paramètres sont optionnels, et ont tous une valeur par défaut de 1 (que vous pouvez bien sûr changer).

Donc si vous appelez la fonction avec la commande :

New-RandomPassword -Length 10

Vous générez en fait un mot de passe de 10 caractères, contenant 1 majuscule, 1 chiffre, et 1 caractère non-alphanumérique.

Si vous souhaitez faire varier le nombre de majuscules, de chiffres, ou de caractères spéciaux, vous pouvez alors appeler la fonction comme ceci :

New-RandomPassword -Length 10 -Uppercase 2 -Digits 3 -SpecialCharacters 3

Bien. Si l’on traduit donc maintenant cela en PowerShell, voici comment nous allons déclarer nos paramètres :

function New-RandomPassword {
    [CmdletBinding()]
    Param
    (
        [Parameter(Mandatory=$true)][int]$Length,
        [Parameter(Mandatory=$false)][int]$Uppercase=1,
        [Parameter(Mandatory=$false)][int]$Digits=1,
        [Parameter(Mandatory=$false)][int]$SpecialCharacters=1
    )
}

Note : Il n’est pas obligatoire d’écrire (Mandatory=$false) pour déclarer qu’un paramètre est optionnel, mais je le fais systématiquement pour faciliter la lecture.

À l’intérieur de notre fonction, nous avons déclaré au-dessus trois sections :

Begin {}
Process {}
End {}

Ce n’est pas obligatoire non plus, mais on considère cela comme une bonne pratique.

  • La section Begin{} va vous servir généralement à initialiser les variables nécessaires pour votre fonction, ou à vérifier par exemple que les paramètres saisis correspondent bien à ce que vous attendez.
  • La section Process{} contient le cœur de votre fonction : la majorité de votre code se trouvera donc ici.
  • La section End{} contient généralement les retours utilisateurs, si vous voulez renvoyer à l’utilisateur un mot de passe aléatoirement généré par exemple, ou alors les déconnexions bases de données, etc.

Commençons par la section Begin{}.

Maintenant que nous connaissons la taille du mot de passe ($Length), le nombre de majuscules ($Uppercase), le nombre de chiffres ($Digits), ainsi que le nombre de caractères spéciaux ($SpecialCharacters), on peut donc calculer le nombre de minuscules que le mot de passe devra comporter. Ce qui nous donne :

Begin {
        $Lowercase = $Length - $SpecialCharacters - $Uppercase - $Digits
    }

On va également déclarer 3 tableaux, contenant les caractères minuscules, majuscules et spéciaux que l’on souhaite voir apparaître dans le mot de passe.

Begin {
        $Lowercase = $Length - $SpecialCharacters - $Uppercase - $Digits
        $ArrayLowerCharacters = @('a','b','c','d','e','f','g','h','i','j','k','l','m','n','o','p','q','r','s','t','u','v','w','x','y','z')
        $ArrayUpperCharacters = @('A','B','C','D','E','F','G','H','I','J','K','L','M','N','O','P','Q','R','S','T','U','V','W','X','Y','Z')
        $ArraySpecialCharacters = @('_','*','$','%','#','?','!','-')
    }

Note : L’avantage de le faire de cette manière est que cela vous laisse toute latitude pour enlever certains caractères, parmi ceux disponibles pour le mot de passe.

Il est maintenant temps de passer à la section Process{} de la fonction, là où la magie opère.

On va créer une nouvelle variable de type [string], $NewPassword, et choisir aléatoirement des lettres minuscules, selon la valeur de $Lowercase. On utilise pour cela la commande Get-Random à laquelle on passe via un pipeline le tableau de lettres minuscules que l’on a précédemment créé : $LowerCharacters.

On répète ensuite cela pour les chiffres, puis les majuscules, puis les caractères spéciaux.

Process {
[string]$NewPassword = $ArrayLowerCharacters | Get-Random -Count $Lowercase
            $NewPassword += 0..9 | Get-Random -Count $Digits
            $NewPassword += $ArrayUpperCharacters | Get-Random -Count $Uppercase
            $NewPassword += $ArraySpecialCharacters | Get-Random -Count $SpecialCharacters
}

Note : 0..9 indique une suite de chiffre continue de 0 à 9. La commande 0..9 | Get-Random -Count $Digits demande donc à PowerShell de choisir aléatoirement X chiffres entre 0 et 9.

Cette méthode a toutefois deux inconvénients :

  • Le premier, c’est qu’entre chaque caractère, on se retrouve avec un espace. Votre mot de passe « Password1 » est donc : « P a s s w o r d 1 ». C’est donc inutilisable en l’état.
  • Le second, c’est que votre mot de passe est actuellement de la forme : abc22ABC%. On a donc choisi aléatoirement des caractères, mais leur placement dans la chaîne de caractères est prévisible : ce n’est pas ce que l’on cherche. Il va donc falloir retravailler cela.

Pour répondre au premier inconvénient, on va utiliser la méthode Replace qui fonctionne très bien pour les chaînes de caractères. Dans notre cas, on cherche à remplacer les espaces par rien, donc à éliminer les espaces.

$NewPassword = $NewPassword.Replace(' ','')

Il nous reste maintenant à traiter le second inconvénient : mélanger de manière aléatoire les caractères que l’on a retenus.

Pour cela, on va transformer la chaîne de caractères en tableau, puis mélanger les caractères entre eux, avant de retransformer le résultat en chaîne de caractères.

$characterArray = $NewPassword.ToCharArray()  
$scrambledStringArray = $characterArray | Get-Random -Count $characterArray.Length     
$NewRandomPassword = -join $scrambledStringArray

Le plus gros est fait, mais si vous vous arrêtez là, votre fonction marche, un mot de passe aléatoire est bien créé, mais à aucun moment vous ne le verrez puisqu’on n’a pas demandé explicitement à la fonction de vous retourner la valeur du mot de passe.

Il nous reste donc à modifier la section End{} pour retourner le mot de passe.

End {
  Return $NewRandomPassword
}

Vous voici maintenant avec une fonction de génération de mot de passe aléatoire, le tout en PowerShell !

Testons enfin notre fonction, en générant un mot de passe de 15 caractères, dont 3 majuscules, 2 chiffres, et 2 caractères spéciaux :

New-RandomPassword -Length 15 -Uppercase 3 -Digits 2 -SpecialCharacters 2

Contrairement à tout à l’heure, on peut voir que les mots de passe ont bien tous 2 caractères spéciaux, et non pas un minimum de 2. Et ça fait toute la différence !

 

B. La fonction en action

Si vous souhaitez tester cette fonction, voici sans plus attendre le code à recopier dans votre script :

function New-RandomPassword {
    [CmdletBinding()]
    Param
    (
        [Parameter(Mandatory=$true)][int]$Length,
        [Parameter(Mandatory=$false)][int]$Uppercase=1,
        [Parameter(Mandatory=$false)][int]$Digits=1,
        [Parameter(Mandatory=$false)][int]$SpecialCharacters=1
    )
    Begin {
        $Lowercase = $Length - $SpecialCharacters - $Uppercase - $Digits
        $ArrayLowerCharacters = @('a','b','c','d','e','f','g','h','i','j','k','l','m','n','o','p','q','r','s','t','u','v','w','x','y','z')
        $ArrayUpperCharacters = @('A','B','C','D','E','F','G','H','I','J','K','L','M','N','O','P','Q','R','S','T','U','V','W','X','Y','Z')
        $ArraySpecialCharacters = @('_','*','$','%','#','?','!','-')
    }
    Process {
            [string]$NewPassword = $ArrayLowerCharacters | Get-Random -Count $Lowercase
            $NewPassword += 0..9 | Get-Random -Count $Digits
            $NewPassword += $ArrayUpperCharacters | Get-Random -Count $Uppercase
            $NewPassword += $ArraySpecialCharacters | Get-Random -Count $SpecialCharacters

            $NewPassword = $NewPassword.Replace(' ','')

            $characterArray = $NewPassword.ToCharArray()  
            $scrambledStringArray = $characterArray | Get-Random -Count $characterArray.Length    
            $NewRandomPassword = -join $scrambledStringArray
    }
    End {
            Return $NewRandomPassword
    }
}

N’oubliez pas que pour utiliser cette fonction, vous devrez l’appeler dans votre script de la manière suivante :

New-RandomPassword -Length $Length -Uppercase $Uppercase -Digits $Digits -SpecialCharacters $SpecialCharacters
  • $Length correspond à la taille de votre mot de passe
  • $Uppercase correspond au nombre de majuscules
  • $Digits correspond au nombre de chiffres
  • $SpecialCharacters correspond au nombre de caractères non-alphanumériques

En l’état, ce code est fonctionnel, mais si on souhaite bien faire les choses, il faudrait encore ajouter des commentaires, si possible visible via la commande Get-Help, ainsi que des contrôles d'erreur.

Pour voir à quoi cela ressemble, faites un tour sur ma page Github, vous pourrez alors récupérer cette fonction avancée avec les commentaires, ainsi que les contrôles d'erreurs.

➡Script - New-RandomPassword.ps1

V. Conclusion

Vous savez maintenant ce qu’il vous reste à ajouter dans vos scripts PowerShell pour automatiser la création d’un utilisateur, et générer un mot de passe aléatoire qui respecte la politique de sécurité de l’entreprise, tout en étant relativement simple à saisir pour l’utilisateur.

The post PowerShell – Comment générer un mot de passe aléatoire ? first appeared on IT-Connect.

Office 365 : comment améliorer la délivrabilité et la sécurité de vos e-mails ?

18 mai 2021 à 13:00

I. Présentation

Que ce soit avec Office 365 et Exchange Online, ou une autre solution de messagerie, lorsque l'on parle d'e-mails, il y a deux termes qui reviennent encore et encore, constamment : sécurité et délivrabilité.

En tant qu’administrateur infrastructure, on souhaite éviter autant que possible de recevoir les mails de type spam, phishing, contenant des pièces jointes frauduleuses. Alors on met en place des filtres anti-phishing, antispam. On cherche aussi à sécuriser les e-mails au départ de notre serveur de messagerie, et faire en sorte qu’ils soient sains. Et puis on souhaite enfin s’assurer que nos mails passent les filtres de sécurité des serveurs de messagerie distants sans encombre, et arrivent directement dans la boîte mail du destinataire, sans passer par la case spam.

Avec Office 365, il y a plusieurs manières (complémentaires) d’arriver à nos fins. L’une d’entre elles est de passer par le trio gagnant des enregistrements DNS : « SPF », « DKIM » et « DMARC ».

II. Prérequis

III. Pourquoi l’enregistrement SPF n’est pas suffisant ?

Bon, je vous vois venir, vous allez me dire que lorsque vous configurez un nouveau domaine dans Office 365, vous devez obligatoirement configurer un enregistrement SPF dans votre zone DNS, et que cet enregistrement sert déjà à améliorer la sécurité et la délivrabilité de vos mails. Alors, à quoi bon s’embêter avec DKIM et DMARC ?

On va la faire courte : SPF est bien entendu nécessaire, mais n’est absolument pas suffisant. C’est là que DKIM et DMARC entrent en jeu.

Je vous explique.

A. SPF – Comment ça marche ?

SPF (ou Sender Policy Framework) est une norme adoptée à l’international qui permet de réduire les spams au niveau de votre serveur.

Concrètement, l’enregistrement SPF sert à authentifier l’expéditeur d’un courrier électronique. Cela permet de vérifier que le serveur qui envoie un mail à partir d’une adresse mail en @mondomaine.com est bien un serveur légitime.

Le nom de domaine de l’émetteur est extrait de l’en-tête du mail reçu (« MAIL FROM : »), et une requête DNS est émise sur ce domaine pour connaître la liste des serveurs de messagerie légitimes qui peuvent émettre des mails pour ce domaine précis. On compare alors cette liste de serveurs à l’adresse IP du serveur qui a émis le message.

Par exemple dans mon cas, comme mes domaines sont configurés sur Office 365, seuls les serveurs Exchange Online du tenant Office 365 sont autorisés à envoyer des mails à mon nom.

Du coup, si jamais quelqu’un essaye de se faire passer pour moi en envoyant un mail en mon nom, son serveur ne sera pas reconnu comme légitime et le mail pourra donc être classifié comme mail frauduleux / spam.

SPF est donc devenu un indispensable pour :

  • Augmenter la délivrabilité globale de ses mails
  • Se défendre contre l’usurpation d’identité de domaine, ainsi que l’usurpation d’adresse électronique (mail)

Cependant, SPF ne sait pas gérer les transferts de mail, et c’est là que les enregistrements DKIM entrent en jeu.

B. SPF – Les bonnes pratiques

L’enregistrement SPF est un enregistrement dans votre zone DNS publique de type TXT qui contient la liste des serveurs de messagerie autorisés à envoyer un mail pour votre domaine.

Voici une bonne pratique à respecter en toute circonstance : incluez toujours vos serveurs sous la forme server.mondomaine.com, ne listez pas les adresses IP une par une.

A. Vérifier la configuration SPF

Vous pouvez vérifier la validité de votre enregistrement SPF en utilisant cet outil gratuit.

Renseignez dans le champ votre nom de domaine, puis cliquez sur le bouton « Valider DNS ».

Vous obtiendrez alors un résultat complet de l’analyse de votre enregistrement SPF.

Dans mon cas, ma configuration SPF est validée, et le serveur spf.protection.outlook.com (correspondant à Office 365) est bien celui qui est déclaré. Tout est parfait! 🙂

 

IV. Comprendre et configurer DKIM

A. DKIM – Comment ça marche ?

DKIM est un acronyme pour Domain Keys Identified Mail. Cette technologie permet d’envoyer un message chiffré, et de s’assurer que celui-ci n’a subi aucune altération durant sa transition entre le serveur émetteur et le serveur récepteur.

Rassurez-vous, le contenu du mail n’est pas chiffré, et votre destinataire pourra continuer à lire le message sans vous demander de clé de déchiffrement.

Au moment où vous envoyez votre mail, le serveur émetteur le chiffre via sa clé DKIM privée. Le serveur récepteur va lui vérifier la clé DKIM publique (l’enregistrement DKIM de votre zone DNS), et comparer celle-ci avec ce qu’il a reçu. Si le test est concluant, alors le serveur émetteur est bien qui il prétend être, l’identité de l’émetteur est prouvée et le mail peut donc être délivré dans la boîte mail du destinataire.

DKIM permet donc de s’affranchir des attaques de type « man in the middle ».

Note : Cette signature DKIM se gère dans l’en-tête du mail envoyé. Cela est donc transparent pour l’utilisateur final. Comme cette signature reste dans l’en-tête, cela permet de continuer à certifier l’exactitude du mail initial si celui-ci est transféré à une tierce personne.

 

B. Pourquoi DKIM est aujourd’hui indispensable ?

Je vous conseille fortement de mettre en place DKIM en plus de vos enregistrements SPF. Pourquoi ?

Parce que DKIM prouve que le contenu du mail ainsi que les en-têtes n’ont subi aucune altération : le mail est donc authentique et légitime : personne ne l'a envoyé à votre place, et le serveur de messagerie distant est maintenant en capacité de le vérifier.

C. Configuration de DKIM pour votre domaine

Tout d’abord, ouvrez une console PowerShell et commencez par vous connecter à votre serveur Exchange Online :

Import-Module ExchangeOnlineManagement

Connect-ExchangeOnline

Avant de commencer, vérifions ensemble que mondomaine.com soit bien déclaré comme un nom de domaine utilisable par Exchange :

Get-AcceptedDomain

Vous devriez voir mondomaine.com dans la liste.

Nous allons ensuite initialiser la configuration DKIM de notre nom de domaine mondomaine.com :

New-DkimSigningConfig -DomainName mondomaine.com -Enabled $false

 

Note : Vous pouvez utiliser le paramètre -Keysize 2048 dans la commande précédente, pour forcer la taille de votre clé DKIM à 2048 bits. Pas de panique toutefois, si vous ne l'avez pas fait, vous pourrez toujours y apporter des modifications plus tard en production.

Bien. Maintenant, il nous reste à générer les enregistrements DNS « DKIM » que nous devrons ajouter dans notre zone DNS publique.

Pour cela, tapez la commande :

Get-DkimSigningConfig -Identity mondomaine.com | Format-List Selector1CNAME, Selector2CNAME

Dans mon cas, je vais donc devoir créer 2 enregistrements CNAME sur ma zone DNS :

Prenons 30 secondes pour analyser la structure des enregistrements selector1 et selector2 à créer. Ces deux enregistrements se composent comme suit :

selector<id>-<domaine>-<extension>._domainkey.<tenantOffice365>.onmicrosoft.com

Pour le domaine mondomaine.com, cela donnerait donc :

  • selector1-mondomaine-com._domainkey.mondomaine.onmicrosoft.com
  • selector2-mondomaine-com._domainkey.mondomaine.onmicrosoft.com

Il ne nous reste plus qu'à créer ces deux enregistrements CNAME dans notre zone DNS avec le paramétrage suivant :

  • Nom : selector1._domainkey & selector2._domainkey
  • TTL : 3 600 secondes

Note : Pensez bien à ajouter un point (.) à la fin du nom de domaine, pour indiquer que vous souhaitez pointer vers selector1-mondomaine-com._domainkey.mondomaine.onmicrosoft.com (domaine externe).

 

Attendez maintenant quelques secondes, le temps que votre zone DNS se réplique, puis lancez la commande suivante afin d’activer l’utilisation de DKIM pour mondomaine.com.

Set-DkimSigningConfig -Identity mondomaine.com -Enabled $true

Note : Si vous obtenez une erreur, soit une faute s’est glissée dans votre enregistrement DNS de type CNAME (pensez à bien vérifier le point final), soit vous n’avez pas attendu assez longtemps pour que la réplication de votre zone DNS soit effectuée.

D. Vérifier la configuration DKIM

Pour vérifier la bonne configuration de DKIM sur votre domaine, je vous conseille d’utiliser ce lien.

Renseignez l’un des 2 sélecteurs configurés, ainsi que votre nom de domaine, puis cliquez sur le bouton « Valider DNS ».

Note : Ne saisissez que selector1, l'outil va compléter automatiquement le reste de l'enregistrement DNS. Si vous saisissez selector1._domainkey, le test échouera.

Vous pouvez donc voir que dans mon cas l’enregistrement DKIM du sélecteur 1 est valide.

Note : Pensez bien à refaire cette étape pour chacun des sélecteurs DKIM configurés pour votre domaine.

Vous pouvez également, lorsque vous êtes connectés à votre serveur Exchange en PowerShell, exécuter la commande suivante :

Get-DkimSigningConfig -Identity mondomaine.com

Je n'obtiens pas d'erreur, mon domaine est donc correctement configuré avec DKIM.

V. Comprendre & configurer DMARC

A. DMARC – Comment ça marche ?

DMARC est un acronyme pour Domain-based Message Authentication, Reporting, and Conformance. DMARC utilise SPF et DKIM pour authentifier les expéditeurs d’emails, et fournit une protection supplémentaire.

En effet, SPF et DKIM permettent d’authentifier un expéditeur (ou non). Mais ils ne donnent aucune indication sur la conduite à tenir dans le cas d’une usurpation d’identité avérée.

C’est là que DMARC entre en jeu : lorsqu’on configure cet enregistrement DNS, on lui indique une politique à tenir. Cela permet au serveur de messagerie de savoir quoi faire de ces mails : faut-il les rejeter ? les mettre en quarantaine ? Ne rien faire mais l’historiser ?

A vous de le décider, et ça se passe dans DMARC.

B. Configuration de DMARC pour votre domaine

Afin de configurer DMARC pour votre domaine, il n’est pas nécessaire de faire des manipulations PowerShell : tout se passe dans votre zone DNS.

Il vous faut créer l’enregistrement TXT suivant dans votre zone DNS :

  • Type : TXT
  • Nom : _dmarc
  • TTL : 3 600 secondes
  • Valeur : « v=DMARC1 ; p=<policy>; rua=mailto:[email protected]; pct=100; adkim=s; aspf=s »

Quelques explications :

Pct=100 indique que cette règle s’applique à 100% des emails.

adkim=s indique que la règle d'alignement avec DKIM est stricte. Seuls les mails partant du domaine mondomaine.com sont valides. Les mails en provenance d'un sous-domaine de mondomaine.com ne sont pas considérés comme valides.

aspf=s indique que la règle d'alignement avec SPF est stricte. L'en-tête "De" du mail doit correspondre exactement au nom de domaine de la commande SMTP "MAIL FROM".

Le paramètre rua est optionnel. Si vous l'indiquez comme ici, cela permettra d'envoyer des rapports sur l'activité DMARC à l'adresse mail [email protected].

Vous pouvez remplacer <policy> par 3 valeurs. Il s’agit ici de configurer la stratégie à appliquer sur le serveur de messagerie si un mail est rejeté par DMARC :

  • None : vous êtes en mode surveillance uniquement.
  • Quarantine : les mails qui ne passent pas DMARC sont mis en quarantaine.
  • Reject : les mails qui ne passent pas DMARC sont rejetés

Note : Je vous conseille de commencer par la stratégie none. Cela vous permet d’analyser l’impact de DMARC sur les mails reçus lorsque vous le passerez en mode quarantaine. On ne sait pas exactement la quantité de messages que l’on risque de perdre (non délivrés dans la boîte de réception du destinataire) via une stratégie DMARC restrictive, commencez donc par la stratégie de surveillance « none ».

C. Vérifier la configuration DMARC

Afin de vérifier que votre enregistrement DMARC est bien configuré sur votre zone, je vous invite à utiliser ce lien.

Renseignez alors le nom du domaine à vérifier, et cliquez sur le bouton « Valider DNS ».

Si vous avez suivi mes recommandations sur l’implémentation de DMARC, vous devriez donc avoir un enregistrement présent avec une stratégie de type « none ».

VI. Et si on regardait les en-têtes de nos mails ?

Avant de nous quitter, vérifions maintenant ce qui se passe dans l’en-tête des mails en sortie de notre serveur de messagerie.

Je me suis donc envoyé un mail de mon adresse [email protected] à mon adresse Gmail personnelle, puis j’ai affiché l’intégralité du message pour pouvoir consulter l’en-tête.

On peut voir que le mail a bien été envoyé à partir d’un serveur Exchange Office365, nommé FRA01-PR2-obe.outbound.protection.outlook.com, et qu’il a été réceptionné par le serveur mx.google.com.

On peut également voir 4 mentions importantes dans la section Authentication-Results :

  • Dkim=pass
  • Arc=pass
  • Spf=pass
  • Dmarc=pass

Ces mentions indiquent que la configuration SPF, DKIM et DMARC mise en place ensemble est fonctionnelle, et que ce mail est légitime. Autrement dit :

  • Le serveur ayant envoyé le mail est bien un serveur autorisé et légitime pour envoyer des mails du domaine mondomaine.com
  • Le mail a bien été envoyé par [email protected], il n’y a donc pas d’usurpation d’identité.

 

Note : On peut également voir deux points supplémentaires :

  • L’échange du mail entre les deux serveurs de messagerie s’est bien effectué de façon sécurisée : le protocole TLS 1.2 a été utilisé pour cela.
  • La politique DMARC actuellement mise en place pour ce domaine est sur « none », comme je vous le conseille dans un premier temps. Pour l’anecdote, elle va changer dans les prochains jours pour passer en « quarantine ».

VII. Conclusion

Vous n’avez maintenant plus aucune excuse pour ne pas correctement configurer vos enregistrements SPF, DKIM et DMARC.

Et si vous êtes amenés à expliquer à vos collègues ou à votre DSI l’intérêt de configurer ces enregistrements, retenez simplement que cela :

  • Renforce la protection antispam & anti-phishing
  • Augmente la sécurité de votre serveur de messagerie
  • Permets de contrer les attaques « man in the middle » ainsi que l’usurpation de domaine et l’usurpation d’identité
  • Favorise la délivrabilité de vos mails

Sachez engin que Google, Microsoft et Yahoo travaille sur un nouveau standard pour toujours plus renforcer la sécurité et la délivrabilité des mails, j’ai nommé BIMI.

The post Office 365 : comment améliorer la délivrabilité et la sécurité de vos e-mails ? first appeared on IT-Connect.

Détails des durcissements des sysctl sous Linux : sysctl réseau

12 mai 2021 à 13:00

I. Présentation

Faisant suite à mon autre article "Détails des durcissements des sysctl sous Linux : sysctl système".

Nous allons dans cet article nous intéresser aux durcissements recommandés par l'ANSSI sur les sysctl réseau dans son guide Recommandation de configuration d'un système GNU/Linux. Je vais dans cet article suivre la même approche que dans l'article précédent, dans lequel vous trouverez également quelques exemples d'utilisation de la commande sysctl pour lire et écrire des paramètres.

Pour les paramètres sysctl au niveau réseau, celles-ci peuvent être appliquées à plusieurs niveaux, ce qui détermine le nom précis du paramètre à modifier. On peut par exemple différencier les paramètres s'appliquant sur les interfaces IPv4 (net.ipv4.X.X) ou IPv6 (net.ipv6.X.X), mais également spécifier une interface précise (net.ipv4.eth0), les mots-clés all et default sont utilisés respectivement pour appliquer un paramètre sur toutes les interfaces ou pour les interfaces nouvellement créées (configuration par défaut si rien n'est spécifié).

Ça, c'était la théorie, la réalité est un chouilla plus obscure (voir ce mail https://marc.info/?l=linux-kernel&m=123606366021995&w=2) et je vous déconseille, pour résumer, de paramétrer des valeurs différentes pour le all et le default d'une même sysctl sous peine de vous retrouver avec des comportements difficiles à déboguer ou à comprendre.

II. Durcissement des sysctl réseau Linux

A. IP Forwarding

Le premier durcissement généralement recommandé en ce qui concerne les sysctl réseau est la désactivation de l'IP forwarding. Ce sysctl, lorsqu'il est à 1, permet au serveur de faire transiter des paquets d'une interface vers une autre, à l'image d'un routeur. Lorsque cette fonctionnalité n'est pas utile au fonctionnement du serveur, il est recommandé de désactiver l'IP forwarding :

net.ipv4.ip_forward = 0

Ainsi, le serveur ne sera pas autorisé à faire du routing, c'est-à-dire faire suivre des paquets d'une interface vers une autre, et ne pourra être utilisé comme un routeur entre deux réseaux. Dans le cas où votre serveur dispose de deux interfaces, dont une vers un réseau non maitrisé (Internet par exemple), les paquets provenant d'internet ne pourront atteindre directement les autres serveurs du réseau non exposé (deuxième interface de votre serveur), car le serveur ne fera pas suivre ces paquets, même s'il connait la route par lesquels ils sont censés passer.

Dans le cas où ce sysctl est à 1 (IP forwarding activé), alors les paquets reçus par le serveur sans lui être destinés, mais pour lesquels il connait une route seront automatiquement envoyés sur cette route, le serveur pourrait alors servir de pont entre deux réseaux sans que cela ne soit voulu.

À noter que ce paramétrage ne protège pas de tout, si votre serveur est compromis ou si l'application web qu'il héberge est ciblée par une attaque SSRF (Server Side Request Forgery), alors les IP du réseau "interne" pourront tout de même être atteintes.

B. Filtrage par chemin inverse

Le filtrage par chemin inverse ou Reverse Path Filtering est un mécanisme du noyau Linux consistant à vérifier si l'adresse source indiquée dans les paquets reçus par une interface est routable par cette interface. En d'autres termes, lorsque notre serveur va recevoir un paquet sur une interface, il va l'ouvrir, regarder quelle est son adresse IP source, puis utiliser sa table de routage pour voir s’il contient une route capable de joindre cette IP source pour l'interface par laquelle il a reçu ce paquet (qui deviendra une IP destination en cas de réponse :)). On pourrait décrire ce mécanisme comme un contrôle de cohérence du serveur qui reçoit un paquet, le serveur cherche à vérifier s'il est normal ou cohérent de recevoir un paquet avec telle IP source sur cette interface.

Dans le cas où ce "contrôle de cohérence" échoue, le paquet est supprimé ("droppé" pourrait-on dire en bon français). L'ANSSI recommande d'activer cette fonctionnalité en mettant une valeur 1 aux sysctl suivants :

 net.ipv4.conf.all.rp_filter = 1
 net.ipv4.conf.default.rp_filter = 1

À noter que les systèmes Red Hat possèdent une option supplémentaire (2) permettant d'accepter un paquet si son IP source est routable par n'importe quelle interface du serveur, et non pas uniquement par l'interface ayant réceptionné le paquet analysé.

Le reverse path filtering est en réalité un mécanisme créé pour limiter les attaques par Déni de Service (Denial of Service ou DoS). L'une des techniques de déni de service profite du Three way Handshake TCP combiné à de l'IP spoofing. Plus clairement, l'attaquant va envoyer des milliers de paquets TCP SYN au serveur avec des adresses IP usurpées ou n'existant pas. Le serveur va alors renvoyer à ces adresses IP un paquet SYN/ACK et n'obtiendra jamais de réponse. Ainsi, les connexions resteront ouvertes pendant un long moment, ce qui les rendra indisponibles pour de nouvelles connexions légitimes. Un peu comme si l'on réservait toutes les tables d'un restaurant sur une semaine sans venir y manger :).

Ce mécanisme est décrit précisément dans la RFC3704 : https://tools.ietf.org/html/rfc3704

Lorsqu'une telle attaque intervient avec un rp_filter activé, la plupart des paquets seront droppés dès leur réception, car le système remarquera qu'ils ne sont pas légitimes pour arriver sur une interface réseau donnée.

C. Redirections ICMP

L'ICMP (Internet Control Message Protocol) est un protocole qui ne se réduit pas au ping, les paquets echo request (paquet ICMP de type 8) et echo reply (paquet ICMP de type 0) observés lorsqu'on fait un ping ne sont qu'une petite partie des capacités de ce protocole. Parmi les fonctions méconnues de ce dernier, les paquets ICMP de type 5, nommés Redirect Messages sont utilisés afin d'avertir un hôte nous ayant envoyé un message qu'une autre route est possible (et plus rapide) pour joindre l'hôte qu'il cherche à contacter.

Ce mécanisme se nomme l'ICMP redirect est n'est utilisé qu'à de rares occasions (voire jamais) sur un système d'information moderne correctement configuré, et comme tout en sécurité, si c'est inutile, c'est à désactiver.

net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

En soit, ce mécanisme de l'ICMP redirect permet donc à un hôte recevant un paquet de faire passer son correspondant par un autre chemin réseau, en lui indiquant une nouvelle route qu'il intégrera durablement dans sa table de routage, un attaquant utilisant ce mécanisme envers un système peut donc modifier le chemin qu'emprunterons les futurs paquets, et pourquoi pas provoquer une attaque de type Man in the Middle ou une simple interruption de service. C'est pourquoi l'ANSSI recommande de désactiver l'acceptation et l'envoi de paquets ICMP redirect.

Le sysctl secure_redirects correspond à une option permettant à l'hôte d'accepter un paquet ICMP redirect uniquement si celui provient de l'adresse IP d'une des passerelles enregistrées au niveau de la configuration réseau. On cherche ici a maintenir l'utilisation de l'ICMP redirect, mais à réduire les hôtes pouvant nous envoyés de tels paquets à une liste de confiance.

D. Source routing

Pour l'expéditeur d'un paquet IP, le mécanisme du source routing consiste en la possibilité de définir la route prise par ce paquet sur le réseau. Alors que dans la plupart des cas, un paquet IP est envoyé par son expéditeur sur la passerelle réseau, qui définit ensuite en fonction de sa table de routage quel sera le prochain saut ou la prochaine passerelle à atteindre. Dans le cas d'un source routing, l'expéditeur peut inclure dans le paquet IP une liste d'adresses IP par lequel le paquet devra passer et ainsi modifier la décision nominale des différentes passerelles du réseau qui seront traversées. En d'autres termes, l'expéditeur peut manipuler une partie de la décision des passerelles concernant le routage des paquets. Également, le chemin par lequel le paquet est passé peut être transmis à son destinataire, qui prendra potentiellement ce chemin pour ses réponses. Les guides de bonnes pratiques recommandent de désactiver cette fonctionnalité :

net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0

Dans les faits, le source routing au niveau d'un paquet IP n'est presque jamais utilisé, il peut être utile pour du débogage (notamment pour du traceroute). En plus d'aider à dresser une cartographie du réseau, le source routing reste intéressant pour un attaquant, car il peut permettre de joindre une machine sur un réseau qui n'est, selon les tables de routages habituelles, pas accessibles au travers un serveur ayant deux interfaces réseau par exemple. 

E. Journalisation des martians packet

L'IANA définit un paquet "martien" comme un paquet qui arrive sur une interface n'utilisant pas le réseau source ou destination du paquet reçu. Pour Linux, il s’agit de tout paquet qui arrive sur une interface qui n’est en aucun cas configurée pour ce sous-réseau.

net.ipv4.conf.all.log_martians = 1

L'objectif de la journalisation des IP "anormales" est justement de pouvoir investiguer, voire alerter et réagir sur un comportement réseau qui n'est pas usuel. Il est en effet courant qu'un attaquant produise ce genre de comportements anormaux lors d'une phase de cartographie, d'une analyse comportementale d'un hôte ou d'un service pour en déterminer la nature (version, technologie précise), voir de causer un bug ou d'exploiter une vulnérabilité.

Dans les faits, la journalisation d'un tel paquet aura aussi de grandes chances de provenir d'une erreur de configuration au niveau des routes et des routeurs du réseau, le but pourrait donc également être d'avertir les administrateurs d'un potentiel problème de routage.

F. RFC 1337

La RFC 1337 est une RFC de type Informationnal (non obligatoire en somme) qui décrit un bug théoriquement possible sur des connexions TCP, ce bug est nommé "TIME-WAIT Assassination hazards". En somme, il s'agit d'une "lacune" dans la conception de TCP/IP qui rend possible la fermeture d'une connexion en TIME-WAIT par un paquet provenant d'une ancienne session TCP (arrivé en retard ou en dupliqué à cause d'une latence quelconque). Ce cas de figure théorique peut donc perturber des communications établies entre un client et un serveur :

net.ipv4.tcp_rfc1337 = 1

Cette protection vise donc à se protéger d'une anomalie potentielle dans les communications TCP, qui n'est pas le fruit d'une attaque ciblée visant à avoir un résultat précis.

G. Ignorer les réponses non conformes à la RFC 1122

Certains routeurs sur Internet ignorent les normes établies dans la RFC 1122 et envoient de fausses réponses aux trames de diffusion. Normalement, ces violations sont journalisées via les fonctions de journalisation du noyau, mais si vous ne voulez pas voir ces messages d'erreur dans vos journaux, vous pouvez activer cette variable, ce qui conduira à ignorer totalement tous ces messages d'erreur.

La RFC 1122  normalise ce que toute machine terminale (host, par opposition à routeur) connectée à l'Internet devrait savoir. Je vous invite à consulter la description de Stéphane Borztmeyer sur son blog pour plus de détails : RFC 1122: Requirements for Internet Hosts - Communication Layers

net.ipv4.icmp_ignore_bogus_error_responses = 1

L'objectif est donc simplement d'économiser un tout petit peu d'espace disque et d'éviter la présence de certains évènements inutiles dans les journaux. Peu d'impact en termes de sécurité donc.

H. Augmenter la plage pour les ports éphémères

Les ports éphémères sont les ports utilisés comme port source lorsqu'un système initie une connexion vers un serveur (alors nommés "port client"). Ces ports peuvent également être utilisés par certains protocoles dans une seconde phase d'échange avec le client après un premier échange sur un port "officiel". C'est notamment le cas pour les protocoles TFTP ou RPC. Sur les serveurs à haut trafic (reverse proxy ou load balancer), il est recommandé d'élargir la plage de port par rapport à celle par défaut :

net.ipv4.ip_local_port_range = 32768 65535

À noter que 65535 est la valeur la plus haute pouvant être acceptée. La valeur la plus basse (ici 32768) peut aller jusqu'à 0, gardez cependant à l'esprit que de nombreux ports sont réservés à des usages spécifiques (22 pour SSH, 80 pour HTTP, etc.). Il est donc plus sage de ne pas empiéter sur ces ports-là.

Le gain n'est pas très significatif, mais ce faisant, nous permettons au serveur d'établir plus de connexions et limitons ainsi les risques de saturation de ces ports pouvant être provoqués intentionnellement (attaque par déni de service) ou non (trafic réseau exceptionnellement élevé).

I. Utiliser les SYN cookies

Les SYN cookies sont des valeurs particulières des numéros de séquences initiales générés par un serveur (ISN: Initial Sequence Number) lors d'une demande de connexion TCP. Les bonnes pratiques de sécurité recommandent leur activation au niveau des échanges réseau :

 net.ipv4.tcp_syncookies = 1

L'activation des SYN cookies au niveau du système permet de se protéger des attaques par inondation de requêtes SYN (SYN flooding) qui consiste à ouvrir un très grand nombre de connexions sur un serveur à l'aide de requêtes SYN, sans jamais donner suite au Three Way Handshake TCP (SYN, SYN/ACK, ACK). Le serveur maintient donc un ensemble de connexions en attente (attente de réception d'un ACK après envoi d'un SYN/ACK), ce qui finit par saturer les connexions disponibles pour les clients légitimes.

Ce mécanisme permet au serveur de garder la "tête froide" lorsqu'il est ciblé par une telle attaque, mais il n'est pas conçu pour améliorer les capacités du serveur dans un contexte normal de fonctionnement (autre qu'une attaque par SYN flood).

Attention toutefois : les SYN cookies ne sont en théorie pas conforme au protocole TCP et empêchent l'utilisation d'extension TCP, ils peuvent entraîner une dégradation sérieuse de certains services (par exemple le relais SMTP). Si vous voulez tester les effets des SYN cookies sur vos connexions réseau, vous pouvez paramétrer ce sysctl sur 2 pour activer sans condition la génération de SYN cookies.

J. Gestion de l'IPv6

Dans le cas où l'IPv6 n'est pas activement utilisé au sein de vos réseaux locaux (c'est très très souvent le cas), il est tout simplement recommandé de désactiver la prise en compte de l'IPv6 au niveau du noyau Linux.

net.ipv6.conf.all.disable_ipv6 = 1 
net.ipv6.conf.default.disable_ipv6 = 1

La désactivation pure et simple de l'IPv6 permet de réduire la surface d'attaque du serveur, ce qui est l'un des principaux fondements de la sécurité. Dans bien des cas, l'IPv6 peut être utilisé pour détourner du trafic réseau, réaliser des attaques par déni de service ou contourner des politiques de filtrage lorsqu'il n'est pas activement utilisé et pris en compte dans la configuration et le durcissement global d'un système d'information.

K. Gestion de l'auto-configuration IPv6

Dans le cas, très rare selon moi, où vous utilisez de manière active l'IPv6 dans vos infrastructures internes, différents paramètres peuvent être utilisés afin de durcir la configuration de vos systèmes.

En IPv6, les router advertisements sont des paquets régulièrement envoyés par les routeurs d'un réseau pour s'annoncer aux éventuels nouveaux venus. Les informations contenues dans les router advertisements permettent à un nouvel hôte connecté de récupérer les caractéristiques essentielles du réseau, passerelles par défaut, routes et le préfixe servant à se forger une adresse IPv6 en auto configuration.

Dans le cas où les adresses IPv6 sont établies de manière statique sur vos réseaux, il est recommandé de désactiver la prise en charge des router advertisements afin de ne pas laisser la possibilité à un attaquant d'utiliser leur prise en charge sur les systèmes du réseau pour lui-même déterminer la configuration IPv6 de ces systèmes . En effet, quoi de plus simple que de se faire passer pour un routeur ou une passerelle pour réaliser une attaque par l'homme du milieu ?

# Ne pas accepter les router preferences par router advertisements
net.ipv6.conf.all.accept_ra_rtr_pref = 0
net.ipv6.conf.default.accept_ra_rtr_pref = 0

# Pas de configuration automatique des prefix par router advertisements
net.ipv6.conf.all.accept_ra_pinfo = 0
net.ipv6.conf.default.accept_ra_pinfo = 0

# Pas d’apprentissage de la passerelle par router advertisements
net.ipv6.conf.all.accept_ra_defrtr = 0
net.ipv6.conf.default.accept_ra_defrtr = 0

# Pas de configuration auto des adresses à partir des router advertisements
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.autoconf = 0

L. Désactiver le support des "router solicitations" IPv6

En IPv6, le router sollicitation est un type de message qui permet à un hôte de demander à tous les routeurs présents sur le réseau local de lui envoyer un Router Advertisement, afin qu'il l'enregistre dans sa liste de voisins et qu'il puisse récupérer les éléments essentiels du réseau IPv6. Dans le cas où les adresses IPv6 sont paramétrées en statique, il est recommandé de désactiver ce mécanisme :

 net.ipv6.conf.all.router_solicitations = 0
 net.ipv6.conf.default.router_solicitations = 0

Pour être plus précis, ce sysctl configure le nombre de router sollicitation à envoyer sur le réseau avant de considérer qu'il n'y a pas de routeur sur le réseau. Désactiver ce comportement lorsque les adresses IPv6 sont statiques permet donc d'éviter du trafic inutile, mais également qu'un attaquant puisse répondre à ces sollicitations en vue de se faire passer pour un routeur IPv6 auprès de votre serveur, lui facilitant ainsi le travail pour la réalisation d'une attaque de type man in the middle.

M. Nombre maximal d’adresses autoconfigurées par interface

L'adressage IPv6 permet d'utiliser plusieurs adresses par interface. À moins que vous n'ayez un besoin particulier nécessitant plusieurs adresses IPv6 unicast global par interface, il est recommandé de paramétrer ce sysctl à 1, ce qui limite à 1 le nombre d'adresses unicast global par interface (16 possibles dans la configuration par défaut).

 net.ipv6.conf.all.max_addresses = 1
 net.ipv6.conf.default.max_addresses = 1

Attention, positionner ces sysctl à 0 rend illimité le nombre d'adresses possibles, ce qui finira par avoir un impact sur les performances de votre serveur.

J'ai toutefois du mal à trouver des risques concrets relatifs à la non-application de ce paramètre. D'après ma compréhension du paramètre dans son état par défaut et du fonctionnement de l'IPv6, sa non-application entrainera la possibilité pour un attaquant de générer la création d'une adresse IPv6 sur sa cible puisque dans un environnement "normal", les 16 slots disponibles sur l'interface IPv6 ne seront pas toutes utilisées. En principe on laisse donc au travers la configuration par défaut, des paramètres non utilisés qui n'attendent qu'à recevoir les faux router avertissements d'un attaquant.  Alors que si le nombre d'adresses IPv6 est limité à 1 par interface est que celle-ci est déjà configurée lors de la venue de l'attaquant (en statique qui plus est), ce dernier n'aura pas de porte d'entrée possible.

N'hésitez pas à ajouter des informations de compréhension supplémentaires dans les commentaires si vous en avez à ce sujet :).

III. Conclusion

Voilà, nous avons fait le tour des durcissements sysctl recommandés par l'ANSSI dans son guide Recommandations de configuration d'un système GNU/Linux. Vous aurez compris que les raisons de certains durcissements sont faciles à appréhender alors que d'autres sont plus bien abstraits ou répondent à des cas très spécifiques. Quoi qu'il en soit j'espère vous avoir apporté une lumière supplémentaire sur ces éléments.

N'hésitez pas à signaler toute erreur ou précision technique dans les commentaires 🙂

The post Détails des durcissements des sysctl sous Linux : sysctl réseau first appeared on IT-Connect.

Détails des durcissements des sysctl sous Linux : sysctl système

12 mai 2021 à 10:00

I. Présentation

Nous allons dans cet article nous intéresser aux durcissements du noyau proposés par le guide de configuration de l'ANSSI à travers les sysctl. Les guides de bonnes pratiques et de configuration de l'ANSSI sont pour la plupart très pertinents, mais il arrive qu'ils manquent de détails et que la cohérence de certains durcissements puisse être difficile à appréhender. Je vais donc ici m'efforcer de décortiquer les recommandations 22 et 23 du Guide Recommandation de configuration d'un système GNU/Linux de l'ANSSI qui portent sur les paramétrages des sysctl réseau et système en vue du durcissement d'un noyau Linux. Nous parlerons dans cet article des sysctl système et un prochain article portera sur les sysctl réseau.

J'essaierai notamment de mettre en avant les implications en termes de sécurité et les attaques qu'un durcissement permet d'éviter, sans oublier les potentiels effets de bords si ceux-ci sont connus et les éventuelles questions qui restent en suspens après avoir tenté de creuser ce sujet.

Sur les OS Linux, sysctl est utilisé afin de consulter et modifier les paramètres du noyau, cela nous permet donc de configurer certains comportements du noyau comme la prise en compte de l'IPv6 sur nos interfaces réseau ou l'activation de l'ASLR. Les paramètres utilisables sont ceux listés dans le répertoire /proc/sys

On parle souvent de sysctl pour décrire une clé de configuration paramétrable par la commande sysctl. Ne soyez donc pas étonné de lire "On configure le sysctl net.ipv4.ip_forward à 0" pour indiquer que la clé de configuration net.ipv4.ip_forward doit être définie à 0, par exemple 😉

Pour les systèmes utilisant systemd, la configuration des sysctl se trouve dans /etc/sysctl.d/.conf, /usr/lib/sysctl.d/.conf. et /etc/sysctl.conf.

Attention, depuis récemment (2017) il se peut que certains systèmes utilisant systemd n'appliquent plus les configurations sysctl indiquées dans /etc/sysctl.conf. Seuls les fichiers ayant une extensions .conf et situés dans les répertoires /etc/sysctl.d ou /usr/lib/sysctl.d sont appliqués.

➡ A lire également : Détails des durcissements des sysctl sous Linux : sysctl réseau

II. Comment modifier un sysctl

Il existe deux possibilités de modification d'un sysctl, soit de façon temporaire, c'est à dire valable jusqu'au prochain redémarrage, soit de façon persistante, c'est à dire qui persiste après un redémarrage.

Pour modifier une configuration sysctl de façon temporaire, on peut modifier à chaud la valeur stockée dans le fichier correspondant au sysctl à modifier, par exemple :

# echo 1 > /proc/sys/kernel/sysrq

Ou utiliser la commande sysctl pour faire cette même opération :

# sysctl -w kernel.sysrq=1

Pour modifier un sysctl de façon persistante, il faut aller modifier le fichier configuration (/etc/sysctl.d/99-sysctl.conf, ou autre fichier finissant par .conf dans le même dossier) et y modifier ou ajouter notre valeur pour le sysctl souhaité :

Modification persistante d'une sysctl
Modification persistante d'une sysctl

Pour être techniquement plus précis, une configuration modifiant un sysctl est appelée clé. Ici la clé est donc net.ipv4.conf.default.log_martians et 0 est la valeur associée à cette clé.

Pour afficher l'ensemble des sysctl actuellement utilisées et appliquées, la commande suivante est à utiliser :

# sysctl -a

Enfin pour récupérer un sysctl précis, la commande suivante est à utiliser :

# sysctl -n net.ipv4.conf.eth1.log_martians

III. Durcissement des sysctl système Linux

A. Désactivation des SysReq

Les SysReq ou Magic System Request Key sont une fonctionnalité du noyau Linux permettant, via une combinaison de touche réalisable à tout moment, de lancer des commandes bas niveau, par exemple afin de pouvoir redémarrer un système bloqué sans corrompre le système de fichiers ou tuer un programme paralysant les ressources du système. Parmi les actions réalisables :

  • Déterminer le niveau de log de la console
  • Redémarrer l'ordinateur reBoot
  • Redémarrer via kexec pour faire un crashdump Crashdump
  • Envoyer un signal de terminaison (SIGTERM) à tous les processus (sauf init) tErm
  • Tuer le processus qui consomme le plus de mémoire (via oom-killer)
  • Envoyer un signal de fin (SIGKILL, plus ferme que SIGTERM) à tous les processus (sauf init)
  • Tuer tous les processus de la console virtuelle courante.
  • Envoyer un signal de fin (SIGKILL, plus ferme que SIGTERM) à tous les processus (même init)
  • Afficher le contenu actuel de la mémoire Memory
  • Éteindre le systeme via APM Out
  • Afficher sur la console les registres et drapeaux actuels Print
  • Basculer la gestion du clavier de mode brute (raw) à XLATE
  • Synchroniser les disques (tente d'écrire toutes les données non sauvegardées)
  • Afficher une liste des taches et autres informations dans la console
  • Remonter les disques en lecture seule

À noter que même si les SysReq sont activées, une partie seulement de ces actions sont réalisables dans la configuration par défaut. D'autres requièrent une configuration spécifique. Cette combinaison de touche clavier doit être réalisée sur un terminal "physique", entendez par là qu'une connexion SSH ne sera pas suffisante, en théorie :).

Il existe en effet une petite astuce permettant d'exécuter des SysReq depuis une connexion distante, et cela en utilisant directement une fonctionnalité "native" de sysctl, le fichier /proc/sysrq-trigger. Si l'on souhaite redémarrer le système par exemple, il faut envoyer l'instruction "b", et donc :

echo "b" > /proc/sysrq-trigger

Ce fichier n'est cependant modifiable que par l'utilisateur root :

[email protected]:~$ ls -al /proc/sysrq-trigger
 --w------- 1 root root 0 juil. 28  2018 /proc/sysrq-trigger

Pour gérer cela, il faut se rendre dans le fichier /proc/sys/kernel/sysrq ou utiliser la clé kernel.sysrq dans un fichier de configuration sysctl.

Positionner la valeur 1 permet d'activer l'utilisation des SysReq (valeur par défaut sur une majorité de systèmes), positionner la valeur 0 interdit toute utilisation des SysReq. Lorsque la valeur est autre que 0 ou 1, c'est que certaines commandes sont autorisées, d'autres non, à utiliser en connaissance de cause donc. À nouveau, comme cette fonctionnalité est très rarement utilisée, voir inconnue des sysadmins la plupart du temps, mieux vaut la désactiver :

kernel . sysrq = 0

L'ANSSI recommande en effet de positionner la valeur de cette clé à 0 afin de désactiver totalement leur utilisation. On peut imaginer les effets de bords possibles grâce à ces commandes, notamment en ce qui concerne la possibilité de tuer des processus, afficher les registres CPU, démonter un système de fichier, redémarrer la machine, etc. À noter que le plus grand danger reste l'exploitation de ces SysReq à partir d'un terminal physique par un utilisateur non privilégié, mais leur utilisation n'est pas forcément restreinte au terminal physique comme je l'ai indiqué précédemment.

La frontière entre physique et virtuel s'étant quelque peu estompée ces dernières années, j'ignore par exemple si l'on peut lancer des SysReq à partir d'un clavier virtuel, dans le cas d'un accès distant VNC, via une console d'hyperviseur type VMWare/Proxmox, etc.

B. Interdire les core dump des exécutables setuid

Par défaut, le système va réaliser un core dump (extraction de la mémoire) des processus s'arrêtant brusquement, cela est notamment pratique pour du debug, avoir une photo à l'instant du crash permet de voir quelles données ou actions ont potentiellement causé ce crash.

Cependant, ces dumps sont exécutés par le kernel et écrits sur le système avec les droits de l'utilisateur courant (celui ayant lancé la commande). Dans le cadre de l'utilisation d'un exécutable setuid ou setgid, l'extraction mémoire contiendra les informations d'un programme exécuté avec les droits d'un autre utilisateur, probablement avec un plus haut niveau de privilège que l'utilisateur courant ou root, mais sera écrit sur le système avec les droits de l'utilisateur courant (non privilégié). Ainsi, des informations sensibles, permettant potentiellement une élévation de privilège, pourront se trouver dans ce type de fichier et lisible par l'utilisateur courant.

Afin de contrôler ce comportement, on peut utiliser la clé fs.suid_dumpable afin de ne pas produire de core dump pour les exécutables possédant un bit setuid ou setgid.

fs.suid_dumpable = 0

L'ANSSI recommande de passer la valeur de la clé fs.suid_dumpable à 0 pour désactiver tout core dump sur les exécutables possédant un bit setuid ou setgid, et ainsi éviter d'éventuelles fuites de données sensibles concernant les attributs, les fichiers accédés ou d'autres actions d'un utilisateur privilégié.

C. Déréférencement des liens de fichiers

Une des vulnérabilités courantes sous Linux concernant les liens symboliques est le symlink-based time-of-check-time-of-use race (ou symlink race condition). Il s'agit d'un delta de temps entre le moment où un fichier est contrôlé (pour voir si les droits d'accès sont suffisants) et celui où il est utilisé par un programme.

Pendant le laps de temps où ces deux opérations sont effectuées, un utilisateur malveillant peut créer un lien symbolique portant le nom de ce fichier et ainsi manipuler une partie de l'exécution du programme, qui s'exécute idéalement avec un plus haut niveau de privilège. Un exemple courant fourni comme explication est le suivant :

Exemple d'une attaque time-of-check to time-of-use - Wikipedia
Exemple d'une attaque time-of-check to time-of-use - Wikipedia

Dans cet exemple, le programme contrôle les permissions d'un fichier file avec l'instruction access() en C. Puis, dans un deuxième temps si les permissions le permettent, il va écrire dans ce fichier. Dans le cadre d'une attaque, l'attaquant va laisser le fichier tel quel pour la première opération (par exemple créer lui-même le fichier file en permission 777 pour que le programme constate qu'il peut y écrire). Puis, il va remplacer ce fichier par un lien symbolique pointant vers /etc/passwd. Le programme s'exécutant avec un haut niveau de privilège va alors exécuter sa deuxième instruction et écrire dans le fichier file, qui sera en réalité/etc/passwd.

Un très bon labo est mis à disposition sur ce Gitlab Ranjelikasah/ace-Condition-Seedsecurity, je vous le recommande si vous souhaitez expérimenter par vous-même 🙂

Ce type d'attaque est notamment dangereuse sur les setuid/setgid, qui permettent d'exécuter un binaire avec les droits root (ou d'un autre utilisateur en fonction de leur configuration). C'est pourquoi il est recommandé de durcir ces sysctl qui ont plusieurs effets concernant les liens symboliques et les setuid.

Concernant les hardlinks et pour un utilisateur système créant un lien, l'une des conditions suivantes doit être remplie :

  • l'utilisateur peut seulement créer des liens vers des fichiers dont il est le propriétaire
  • l'utilisateur doit avoir les droits d'écriture et de lecture vers le fichier vers lequel souhaite créer un lien.
Démonstration sur l'effet des durcissement sysctl sur la création des hardlinks
Démonstration de l'effet des durcissements sysctl sur la création des hardlinks

Concernant les symlinks et les processus qui sont amenés à suivre des liens symboliques vers des répertoires world-writable qui ont le sticky bit activé :

  • le processus suivant le lien symbolique doit être le propriétaire du lien symbolique
  • le propriétaire du répertoire est également le propriétaire du lien symbolique.

Si vous avez bien compris le fonctionnement de l'attaque présentée, vous comprendrez rapidement quelle devient impossible si ces conditions sont imposées via le durcissement sysctl :

fs.protected_symlinks = 1
fs.protected_hardlinks = 1

Ce paramétrage permet en somme de durcir les conditions d'utilisation des symlinks et des hardlinks afin de se protéger des différentes attaques permettant une élévation de privilège

D. Activation de l’ ASLR

L'ASLR (Address Space Layout Randomization) est un mécanisme permettant de limiter les effets et de complexifier l'exploitation des attaques de type buffer overflow (dépassement de tampon). L'objectif est ici de placer la zone de données dans la mémoire virtuelle de façon aléatoire, changeant ainsi sa position à chaque exécution.

L'exploitation de buffer overflow consiste notamment à contrôler une partie des registres CPU afin de modifier le flux d'exécution d'un programme. Cela passe, entre autres, par le contrôle du registre EIP (Extended Instruction Pointer) qui permet d'indiquer à quel offset (adresse mémoire) la prochaine instruction à exécuter se trouve. En contrôlant le registre EIP, l'attaquant peut indiquer au programme de sauter à un offset précis et dont le contenu est sous son contrôle, notamment s'il a réussi à injecter du code malveillant (shellcode) à cet endroit de la mémoire. En modifiant la répartition et le positionnement des instructions, de la pile (stack), du tas (heap) et autres, en mémoire, l'attaquant n'est plus en capacité de pointer vers son shellcode car celui-ci ne sera jamais au même endroit à chaque exécution.

Pour activer l'ASLR, on peut utiliser la clé kernel.randomize_va_space et y positionner la valeur 2, qui permet de positionner de façon aléatoire (aka randomiser :/ ) la stack (pile), les pages CDSO (virtual dynamic shared object), la mémoire partagée et le segment de données (data segment), qui contient les variables globales et statiques initialisées par le programme. Positionner la valeur 1 aura le même effet, sauf pour le segment de données. La valeur 0 désactive l'ASLR.

kernel.randomize_va_space = 2

Pour plus d'information sur les buffer overflow, je vous oriente vers les très bons articles (en français) d'0x0ff :

E. Mappage de la mémoire des adresses basses

Une vulnérabilité de type NULL pointer dereference est le fait pour un programme d'utiliser un pointeur non initialisé (valant NULL) ou pointant vers une adresse mémoire inexistante (0x00000000). De fait, lorsque ce programme utilisera ce pointeur dans ses instructions, cela causera un crash. Dans le contexte d'exécution du noyau ou d'un programme à haut niveau de privilège, le fait de déclencher intentionnellement l'utilisation d'un pointeur NULL par un attaquant lui permet de faire crasher le programme, voir le système.

Cependant, si l'attaquant parvient à identifier l'adresse mémoire du pointeur en question et à la manipuler pour y insérer les données de son choix avant qu'elle ne soit utilisée activement par le noyau ou un programme à haut niveau de privilège, alors il pourra contrôler son utilisation dans le programme exécuté, menant à une potentielle élévation de privilège.

En C, un pointeur est une variable qui permet de stocker non pas une valeur ("ABC" ou 12,28), mais une adresse mémoire. Lorsqu'un programme démarre, le système lui alloue une zone mémoire dans laquelle il peut s'organiser. Cette zone mémoire est constituée de "cases" de 8 bits (octets). Chacune de ces cases (appelées blocs) est identifiée par un numéro : son adresse. On peut alors accéder à une variable soit par son nom "agePersonne", soit par l'adresse du premier bloc alloué à la variable en question, c'est-à-dire son pointeur.

Il se trouve que le noyau a tendance à plutôt utiliser les adresses mémoires dites "basses", si l'attaquant parvient à manipuler les pointeurs visant des blocs d'adresses mémoires "basses", alors il a plus de chances de trouver un bloc d'adresse qui sera ensuite utilisé par le noyau.

La clé vm.mmap_min_addr est donc une constante qui permet d'empêcher les utilisateurs non privilégiés de créer des mapping mémoires en dessous de cette adresse. Elle permet de définir l'adresse minimale qu'un processus n'ayant pas les droits root peut mapper, adresse que nous allons rehausser par rapport à sa valeur par défaut (0) :

vm.mmap_min_addr = 65536

Attention toutefois à bien tester le fonctionnement de vos programmes et applications avec ce paramètre avant de passer en production.

F. Espace de choix plus grand pour les valeurs de PID

Sous Linux (et Windows), le PID (Process IDentifier) est un numéro unique assigné à un processus en cours d'exécution. Il permet son identification parmi d'autres processus pour leur gestion, par exemple lorsque l'on utilise les commandes ps ou kill.

Comme pour les ports clients, les PID  sont en nombre limité sur un système. Il se peut donc que toute la plage de PID disponible soit saturée par un dysfonctionnement ou une attaque. Dès lors, aucun autre processus ne pourra être créé, car il n'aura aucun PID à utiliser. L'ANSSI recommande d'élargir la plage du nombre de PID disponible sur un système afin d'éviter ou de limiter de tels scénarios :

kernel.pid_max = 65536

Cette configuration permet donc de prévenir d'une saturation de PID entrainant une impossibilité de créer de nouveau processus. Sur les systèmes 32 bits, la valeur max est de 32 768 alors que pour les systèmes 64 bits, elle est de 2^22 (4 194 304, ça fait beaucoup de processus). À noter toutefois que les PID sont "recyclés", c'est-à-dire que lorsqu'un processus avec un certain PID se termine, ce PID peut être réutilisé plus tard par un autre processus. Ce durcissement vise donc à élargir le nombre de processus tournant simultanément sur votre système, ce qui ne sera le cas qu'en cas d'attaque ou pour des serveurs à très haute performance.

G. Obfuscation des adresses mémoires kernel

Un attaquant qui cherche à compromettre un noyau en cours d'exécution en écrasant les structures de données du noyau ou en forçant un jump (saut) vers un code de noyau spécifique doit, dans les deux cas, avoir une idée de l'emplacement des objets cibles en mémoire. Des techniques comme l'ASLR ont été créées dans l'espoir de "dissimuler" cette information, mais cet effort est vain si le noyau divulgue des informations sur l'endroit où il a été placé en mémoire. Il existe en effet plusieurs cas de figure où des adresses mémoires relatives au kernel peuvent être affichées (fuitées) vers l'espace utilisateur, qui obtient alors des informations intéressantes sur les pointeurs à cibler dans le cadre d'une attaque.

L'ANSSI recommande de paramétrer la directive suivante à 1 afin que, dans certains cas, les adresses mémoires relatives au noyau affichées par un programme soit dissimulées (remplacées par des 0) :

 kernel.kptr_restrict = 1

Attention toutefois, cette dissimulation n'est effective uniquement si le programme utilise la notation %pK (au lieu de %p pour un pointeur "normal"). C'est-à-dire que le développeur a marqué le pointeur vers une adresse noyau comme tel et indique donc au système que l'information doit être protégée. Dans le cas où un programme ne respecte pas cette bonne pratique, le durcissement au niveau du sysctl est inutile.

Enfin, si l'utilisateur possède la capabilities CAP_SYSLOG dans le contexte d'exécution du programme, les adresses mémoire kernel seront affichées normalement (paramétrez la sysctl à 2 si vous souhaitez éviter ce cas de figure).

H. Restriction d’accès au buffer dmesg

Sous Linux, la commande dmesg permet de voir les journaux (plus précisément la mémoire tampon des messages) relatifs au kernel, par exemple ceux créés par les drivers, lors du démarrage du système ou au branchement d'un nouveau périphérique. Ces messages sont ensuite stockés dans le fichier /var/log/messages.

L'ANSSI recommande de configurer le sysctl suivant à 1 afin de n'autoriser que les utilisateurs privilégiés à consulter ce type d'information via la commande dmesg :

 kernel.dmesg_restrict = 1

L'objectif est ici de dissimuler les informations relatives aux journaux du noyau de la vue des utilisateurs, ceux-ci peuvent en effet dans certains cas contenir des informations sensibles pouvant être utilisées dans le cadre de futures attaques.

Voici un exemple de l'utilisation de la commande dmesg par un utilisateur non privilégié avec le paramétrage à 1, puis à 0 :

Effet de la sysctl kernel.dmesg_restrict
Effet de la sysctl kernel.dmesg_restrict

I. Restreindre l’utilisation du sous-système perf

Sous Linux, le sous-système perf est une commande très complète et puissante qui permet de mesurer les performances d'un programme ou du système. Il réalise ces mesures en étant au plus proche de l'hardware, ce qui nécessite un niveau de privilège élevé.

L'ANSSI recommande le paramétrage à 2 de la sysctl suivante afin de limiter l'accès des utilisateurs non privilégiés à cette commande :

kernel.perf_event_paranoid = 2

Ainsi, un utilisateur non privilégié ne sera pas en mesure d'utiliser cette commande, qui peut notamment impacter les performances du système. Ce paramétrage est effectif sauf si l'utilisateur en question possède la capabilities CAP_SYS_ADMIN.

Également, les deux sysctl suivantes doivent être paramétrées à 1 :

kernel.perf_event_max_sample_rate = 1 
kernel.perf_cpu_time_max_percent = 1

Ces deux sysctl servent à gérer combien de ressource et de temps CPU le système de performance peut utiliser. Il s'agit d'un pourcentage (1% du temps CPU). Ces configurations visent à limiter l'impact du sous-système perf sur le système lors de son utilisation. Attention, mettre ces deux sysctl à 0 fait tout simplement sauter toute limite, ce qui serait contre-productif 🙂

Quoi qu'il en soit l'idée derrière le paramétrage de ces deux sysctl est de limiter l'impact du sous-système perf. sur les performances du système.

Rendez-vous dans le prochain article pour l'étude des durcissement des sysctl réseau :). N'hésitez pas à signaler toute erreur ou précision technique dans les commentaires 🙂

The post Détails des durcissements des sysctl sous Linux : sysctl système first appeared on IT-Connect.

Identifiez les mots de passe vulnérables dans l’AD avec Specops Password Auditor

11 mai 2021 à 11:30

I. Présentation

Dans cet article, je vous propose de découvrir l'outil Specops Password Auditor, un logiciel gratuit qui va permettre de réaliser un audit des mots de passe au sein de son annuaire Active Directory. Grâce à cet audit, vous serez en mesure d'identifier les utilisateurs qui ont un mot de passe faible et vulnérable. Quand je dis vulnérable, j'entends un mot de passe qui a fait l'objet d'une fuite de données.

Le logiciel va également vous indiquer les comptes sans mots de passe, les comptes où le mot de passe n'expire jamais, les comptes avec des mots de passe identiques, etc... La stratégie de mots de passe déployée sur votre Active Directory sera également évaluée pour voir si elle respecte les bonnes pratiques en matière de sécurité.

Auditer la qualité des mots de passe utilisés par les utilisateurs est important pour une raison simple : les mots de passe représentent un obstacle et agisse comme une défense en matière de sécurité, donc il est indispensable de s'assurer que cette barrière de protection soit à la hauteur de vos attentes. Un compte avec un mot de passe faible est en quelque sorte une proie facile.

Malheureusement, c'est loin d'être une évidence dans les entreprises et bien souvent cette partie est négligée. Grâce à cet audit, vous allez avoir des éléments entre vos mains pour remettre le sujet sur la table auprès de votre direction...

🎥 Disponible en version vidéo :

II. Les attaques sur les mots de passe : brute force et password spraying

Avant d'aller plus loin, il me semble pertinent de vous rappeler les deux attaques les plus courantes lorsqu'il s'agit de deviner les mots de passe : les attaques de type brute force et les attaques de type password spraying. 

A. Mots de passe - Attaque brute force

Les attaques par brute force sont un grand classique et repose sur une méthode très simple : prendre un compte utilisateur comme cible et essayer un maximum de combinaisons différentes. Autrement dit, on essaie un maximum de mots de passe différents en espérant trouver la bonne combinaison et accéder au compte de l'utilisateur.

Pour cette méthode, on s'appuie sur l'utilisation d'un outil adéquat et d'un dictionnaire, c'est-à-dire un fichier qui contient des dizaines de milliers de mots de passe différents (pour ne pas dire plus). Bien souvent, les mots de passe du dictionnaire sont issus directement d'anciennes fuites de données.

Cette attaque porte bien son nom, disons que c'est une méthode un peu brute et pas très discrète. Bien qu'elle soit efficace contre les comptes avec des mots de passe faibles (nous y voilà), cela peut être beaucoup plus compliqué et plus long dès que le mot de passe est plus complexe et aléatoire.

Les systèmes de protection actuels sont capables de détecter et bloquer ces attaques, notamment l'Active Directory grâce à la fameuse stratégie de mots de passe. En fait, si un utilisateur essaie de se connecter, mais qu'il y a 5 tentatives en échecs dans un laps de temps de 1 minute, on peut verrouiller le compte par sécurité.

B. Mots de passe - Attaque password spraying

Une attaque du type password spraying se rapproche d'une attaque brute force sauf qu'il y a la volonté de rester discret. Plutôt que de cibler un seul compte, nous allons en cibler plusieurs, et plutôt que d'utiliser énormément de combinaisons différentes, on va limiter le nombre de combinaisons. L'objectif est simple : rester sous le seuil de détection et éviter que les comptes ciblés soient verrouillés.

En fait, on teste un mot de passe sur un compte, et après on teste ce même mot de passe sur d'autres comptes. Pendant ce temps, le chrono tourne en la faveur de l'attaquant, tout en poursuivant l'attaque. Au bout d'un moment, il y a de fortes chances pour que la porte s'ouvre compte tenu du fait que les mots de passe faibles sont très répandus.

Ces attaques sont plus difficiles à détecter, mais pas impossible. Généralement les tentatives de connexion sont effectuées depuis la même adresse IP : est-ce normal qu'il y ait de nombreuses tentatives de connexion infructueuses depuis la même adresse IP dans les 10 dernières minutes ? Je ne pense pas 😉.

Le décor est planté, passons à la découverte de l'outil du jour : Specops Password Auditor.

III. Les fonctionnalités de Specops Password Auditor

Specops Password Auditor va effectuer une analyse de votre annuaire Active Directory. Pour réaliser cette analyse et en tirer des conclusions, il va regarder les hash des mots de passe et scanner différents attributs des comptes utilisateurs de votre annuaire, notamment pwdLastSet, userAccountControl, et lastLogonTimestamp.

Grâce à cette analyse rapide, Password Auditor va remonter les éléments suivants :

  • Comptes avec des mots de passe vides
  • Comptes avec des mots de passe ayant fait l'objet d'une fuite de données (mots de passe divulgués)
  • Comptes avec des mots de passe identiques
  • Comptes administrateur du domaine
  • Comptes administrateur inactifs
  • Comptes où le mot de passe n'est pas obligatoire
  • Comptes où le mot de passe n'expire jamais
  • Comptes où le mot de passe est configuré pour expirer
  • Comptes avec le mot de passe expiré
  • Liste des politiques de mots de passe
  • Utilisation / affectation des politiques de mots de passe
  • Conformité des politiques de mots de passe

Specops Password Auditor va également comparer les mots de passe de votre annuaire Active Directory avec sa propre base de mots de passe. La base de mots de passe du logiciel fait environ 5 Go, ce qui représente des centaines de millions d'entrées. Cette base est construite à partir des mots de passe qui sont sortis dans différentes fuites de données et à partir des informations du site haveibeenpwned.com.

Note : la version gratuite du logiciel s'appuie sur une base de 800 millions de mots de passe, tandis que le logiciel payant, Specops Password Policy utilise la base complète de 2,3 milliards de mots de passe.

Si les mots de passe de certains utilisateurs ont fait l'objet d'une fuite de données, vous serez au courant. C'est fort probable que ce soit le cas, notamment si le mot de passe de l'utilisateur est le même dans l'AD et pour se connecter sur ses sites de e-commerce préférés.

IV. Télécharger et installer Specops Password Auditor

Pour télécharger le logiciel, il faut se rendre sur le site de Specops Software et cliquer sur le bouton "Free Download". Il suffira ensuite de remplir un formulaire. Voici le lien : Télécharger - Specops Password Auditor

Un lien de télécharger et une licence seront envoyés sur votre adresse e-mail.

L'installation est très basique, il suffit de quelques clics avec l'assistant. Cochez l'option "Start Specops Password Auditor" à la fin pour démarrer le logiciel.

Passons à l'utilisation du logiciel en lui-même.

V. Rechercher les mots de passe faibles dans l'Active Directory

Le logiciel doit tourner à partir d'une session admin du domaine pour qu'il puisse collecter toutes les informations nécessaires et auditer vos mots de passe.

Au lancement du logiciel, il y a plusieurs champs à renseigner, mais en fait les valeurs sont remontées directement. Il n'y a rien à faire si ce n'est cliquer sur "Import License" en bas à gauche pour charger sa licence gratuite. Cliquez sur "Start".

Néanmoins, vous pouvez utiliser un autre contrôleur de domaine que celui proposé si vous préférez, et vous pouvez restreindre l'analyse à une unité d'organisation spécifique en modifiant la valeur de "Scan Root".

L'étape "Breached Passwords" que l'on peut traduire par "Mots de passe divulgués" permet d'indiquer si vous souhaitez que vos mots de passe soient comparés ou non avec la base de Specops. Le but étant d'identifier les mots de passe vulnérables dans votre annuaire, car concerné par une fuite de données.

Si vous désirez utiliser cette fonction, cochez la case "Download latest version..." et indiquez un chemin au niveau du champ "Local folder". En fait, la base de mots de passe du logiciel va être téléchargée sur votre machine. Comme je le disais, cela représente environ 5 Go d'espace disque.

Cliquez sur "Start Scanning".

La première fois, l'analyse est longue, car il faut télécharger la base de mots de passe. Si vous réexécutez l'analyse ultérieurement, ce sera beaucoup plus rapide.

Une fois l'analyse terminée, un résumé s'affiche sous la forme d'un tableau de bord. Pour chaque catégorie, le verdict tombe. La vue est synthétique, ce qui est appréciable. Pour chaque partie de l'analyse, il y a une bulle rouge qui s'affiche pour indiquer le nombre d'utilisateurs concernés par le point en question.

Tableau de bord de Specops Password Auditor après analyse
Tableau de bord de Specops Password Auditor après analyse

En cliquant sur un bloc, on peut obtenir des informations précises notamment la liste des utilisateurs concernés. Par exemple, voici pour les utilisateurs dont le mot de passe est divulgué. Ce qui est pertinent aussi, c'est la partie "Report information" à gauche qui donne des informations sur l'analyse effectuée et des recommandations.

Si l'on regarde le rapport de la section "Expiring Passwords", on peut voir les comptes utilisateurs pour lesquels le mot de passe va expirer prochainement. Il y a un curseur que l'on peut bouger et qui correspond à un nombre de jours restants avant expiration, de quoi anticiper les changements de mots de passe à venir pour vos utilisateurs.

En revenant sur le tableau de bord, on peut générer un rapport en cliquant sur le bouton "Get PDF Report".

Le rapport généré est très professionnel et très propre. Il reprend chacun des points audités avec un descriptif et la liste des comptes concernés. Au début du rapport, il affiche également une note globale sur 100 qui permettra de vous situer rapidement.

Aperçu du rapport PDF généré par Specops Password Auditor
Aperçu du rapport PDF généré par Specops Password Auditor

VI. Specops Password Auditor : le mot de la fin

Exécuter une analyse de son Active Directory avec le logiciel Specops Password Auditor est un bon point de départ lorsque l'on souhaite s'attaquer au sujet des mots de passe et des stratégies de mots de passe. C'est une manière simple d'auditer soi-même la qualité des mots de passe des utilisateurs : le résumé fourni suite à l'analyse vous permettra d'établir une liste d'actions à mener pour améliorer la sécurité de votre SI.

Vous pourriez même être surpris, sur des SI avec beaucoup de comptes, beaucoup d'unités d'organisations, on peut vite passer à côté de quelques comptes qui traînent et que l'on ignore. Il vaut mieux prendre un peu de temps pour réaliser ces audits et identifier les comptes problématiques avant que quelqu'un le fasse à votre place, si vous voyez  ce que je veux dire.

💡 Avec le rapport généré par l'outil, vous avez des éléments concrets pour avancer avec votre responsable ou votre direction, bien que le rapport soit en anglais.

Envie de tester ? Voici le lien : Télécharger - Specops Password Auditor

VII. Pour aller plus loin : Specops Password Policy

En plus de cet outil de scan et d’audit des mots de passe, une autre solution de Specops, Specops Password Policy, permet de facilement filtrer les mots de passe compromis ou divulgués de votre environnement Active Directory qui auraient été détectés, et de renforcer les stratégies de mot de passe par défaut d’Active Directory. Ce logiciel apporte une réponse aux problèmes remontés par le logiciel Specops Password Auditor.

Specops Password Policy a l’avantage de se baser sur une liste complète, constamment mise à jour, de plus de 2,3 milliards de mots de passe divulgués. En fait, à partir du moment où un mot de passe se trouve dans une fuite de données, vos utilisateurs ne pourront plus l'utiliser pour leur compte Active Directory. Ce logiciel va plus loin que le système de politiques de mots de passe natif à l'Active Directory. Par exemple, pour anticiper les changements de mots de passe, vos utilisateurs peuvent être avertis par e-mail juste avant que le mot de passe arrive à expiration.

Contrairement à Password Auditor, ce second logiciel est payant, mais vous pouvez l'essayer. Si cela vous intéresse, voici le lien : Specops Password Policy

The post Identifiez les mots de passe vulnérables dans l’AD avec Specops Password Auditor first appeared on IT-Connect.

Le secteur bancaire a connu une recrudescence d’attaques informatiques en 2020

22 avril 2021 à 11:18
Par : UnderNews

Depuis un an maintenant, le télétravail a réinventé la donne et a drastiquement complexifié la sécurité des systèmes informatiques, tous secteurs confondus. Désormais sur un système ouvert, l’infrastructure est fragilisée et le secteur bancaire a dû faire face à un nombre exponentiel de cyberattaques dès le premier confinement.

The post Le secteur bancaire a connu une recrudescence d’attaques informatiques en 2020 first appeared on UnderNews.
❌