FreshRSS

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

Politique de mot de passe : comment appliquer les bonnes pratiques de l’ANSSI ?

24 novembre 2021 à 10:00

I. Présentation

Dans cet article, je vais vous parler des bonnes pratiques de l'ANSSI en matière de politique de mot de passe, et nous verrons quelles sont les solutions techniques envisageables pour appliquer ces recommandations dans un environnement Active Directory.

Pour rédiger cet article, je me suis appuyé sur le guide publié par l'ANSSI le 08 octobre 2021 et qui s'appelle "Recommandations relatives à l'authentification multifacteur et aux mots de passe - v2.0".

II. Les bonnes pratiques de l'ANSSI sur les mots de passe

Avant de rentrer dans la technique, je souhaitais vous proposer une synthèse des bonnes pratiques de l'ANSSI au sujet des politiques de mot de passe. Ce guide aborde d'autres sujets, comme l'authentification multifacteurs, mais ici, on va se concentrer uniquement sur l'aspect "politique de mot de passe".

Tout d'abord, une politique de mot de passe définit les règles à respecter par un utilisateur lorsqu'il souhaite définir un nouveau mot de passe pour son compte. À cela s'ajoutent des règles de gestion des mots de passe, comme la limite du nombre d'essais avant verrouillage du compte, la gestion de l'historique des mots de passe, etc.

A. Longueur minimale du mot de passe, en nombre de caractères

Pour les mots de passe ne devant pas être mémorisés par l'utilisateur, l'ANSSI recommande une longueur minimale beaucoup plus importante : minimum 20 caractères. Le stockage de ce précieux sésame s'effectuera dans votre gestionnaire de mots de passe.

Pour les mots de passe devant être mémorisés par l'utilisateur, ce qui est le cas du mot de passe Active Directory puisqu'il permet à l'utilisateur d'accéder à sa session Windows, l'ANSSI met à disposition le tableau suivant à la page 28 de son guide :

Source : Guide de l'ANSSI

Le niveau a choisir dépend de la sensibilité du compte concerné. Pour un compte d'un utilisateur lambda, on se situera sur les deux premiers niveaux de sensibilité. Pour les utilisateurs qui ont accès à des ressources sensibles ou des données confidentielles, on définira à minima le niveau de sensibilité "Moyen à fort". Et enfin, pour les administrateurs, la sensibilité sera au maximum, et donc il est recommandé de mettre en place l'authentification multifacteurs en complément. Tout cela pour dire que la longueur minimale à imposer n'est pas une évidence et dépend du niveau de criticité du compte.

Il faut retenir aussi qu'il est bien souvent plus pertinent d'augmenter la longueur de son mot de passe plutôt que de chercher à conserver la longueur tout en le complexifiant. Cela va permettre d'avoir une meilleure entropie sur votre mot de passe, et donc, de le rendre plus robuste, plus fort (voir cet article).

B. Ne pas imposer de longueur maximale pour les mots de passe

Imposer une longueur minimale est une excellente idée, mais à l'inverse imposer une longueur maximale est une mauvaise idée, ou alors elle doit être très élevée (et là pour des questions de sécurité et contrainte vis-à-vis du logiciel en lui-même). Fixer une longueur maximale revient aussi à empêcher l'utilisation de passphrase, appelée aussi "phrase de passe".

C. La complexité des mots de passe

En imposant des contraintes sur les types de caractères qu'un utilisateur doit utiliser pour définir un mot de passe, on définit ce que l'on appelle la règle de complexité des mots de passe. Pour cela, on met à la disposition de l'utilisateur différents jeux de caractères : les chiffres, les lettres A à Z en minuscules, les lettres de A à Z en majuscules, les caractères spéciaux, etc. Plus il y a de jeux de caractères autorisés, plus il y a de combinaisons possibles.

Généralement, pour s'en sortir et respecter cette notion de complexité des mots de passe, les utilisateurs vont remplacer un "a" par un "@", un "o" par un "0", ou encore ajouter un "!" à la fin du mot de passe. C'est un grand classique. On le sait tous, et on a tous fait ça un jour pour inventer un mot de passe.

Dans le cas d'une tentative d'attaque en ligne, c'est-à-dire contre un système actif, cette méthode reste encore efficace à condition que le compte ciblé soit en mesure d'être verrouillé au bout de quelques tentatives en échec. Par contre, dans le cas d'une attaque hors ligne où il est possible d'effectuer du brute force sans limites, il y a de fortes chances pour que le mot de passe soit deviné. En effet, il existe des outils et des dictionnaires capables d'imaginer ces variantes, et donc, de trouver votre mot de passe.

D. Le délai d'expiration des mots de passe

Alors que pendant longtemps, on entendait qu'il était nécessaire d'imposer aux utilisateurs de changer leur mot de passe tous les 6 mois ou une fois par an, aujourd'hui ce n'est plus aussi évident. Quel est l'intérêt de modifier son mot de passe "Bonjour1" par "Bonjour2" ? Si le mot de passe précédent fuite, il y a des chances pour que le suivant soit deviné assez facilement.

L'ANSSI précise que pour les comptes non sensibles, c'est-à-dire les comptes des utilisateurs : "Si la politique de mots de passe exige des mots de passe robustes et que les systèmes permettent son implémentation, alors il est recommandé de ne pas imposer par défaut de délai d’expiration sur les mots de passe des comptes non sensibles comme les comptes utilisateur." [page 30 du guide].

Par contre, pour les comptes avec des privilèges, il est recommandé d'imposer un délai d'expiration compris entre 1 et 3 ans.

E. Contrôler la robustesse des mots de passe

Un mot de passe qui respecte la longueur minimale et les contraintes de complexité, est-il pour autant un mot de passe robuste ? En voilà une bonne question, et c'est un point très intéressant soulevé par l'ANSSI.

Ainsi, il est recommandé de :

  • Vérifier si votre mot de passe a déjà fait l'objet d'une fuite de données.

En fait, si vous définissez un mot de passe qui à première vue semble complexe, mais qu'il est présent dans un dictionnaire qui circule sur Internet ou qui est utilisé par certains outils, alors on peut douter de sa robustesse.

Dans le même esprit, lorsqu'il y a une fuite de données suite à un piratage, on se retrouve avec d'énormes bases de données de mots de passe constituées à partir ces fuites. Si le nouveau mot de passe que vous venez de choisir se situe dans une fuite de données, il vaut mieux le changer immédiatement, car la probabilité qu'il soit trouvé est plus élevée. Par exemple, le site Have I Been Pwned permet de rechercher un mot de passe dans une base regroupant les données d'un ensemble de fuites d'information.

  • Bloquer les suites de caractères ("12345", "azerty", "aaaa", "abcd", etc.)
  • Bloquer l'utilisation d'informations personnelles dans le mot de passe (nom, prénom, date de naissance)
  • Bloquer la réutilisation d'un mot de passe déjà utilisé lors des X derniers mots de passe (gestion de l'historique des mots de passe)

III. Quelles solutions techniques ?

En prenant connaissance des différentes recommandations de l'ANSSI en matière de politique de mot de passe, on se rend compte que d'un point de vue technique, cela ne va pas forcément être évident à mettre en œuvre. Enfin, c'est comme tout, il suffit d'avoir les bons outils alors cela tombe bien, car nous allons en parler de ces solutions potentielles.

Ici, j'évoque le cas des mots de passe stockés dans l'Active Directory et utilisé par les utilisateurs pour une connexion à Windows. En complément ce mot de passe peut être utilisé pour se connecter sur Microsoft 365, s'il y a un outil tel que Azure AD Connect en place au sein de votre infrastructure. Le stockage des mots de passe doit être effectué de façon sécurisée et il convient de ne pas activer le chiffrement réversible au niveau de votre Active Directory, même si c'est demandé par la solution logicielle que vous souhaitez utiliser.

A. Les politiques de mots de passe de l'Active Directory

La première solution qui nous vient à l'esprit, c'est la politique de mots de passe native à l'Active Directory. Il y a deux types de politiques de mots de passe : celle définie par GPO, et celle que l'on définira sous la forme d'objets appelée stratégie de mots de passe affinée.

Si l'on compare les recommandations de l'ANSSI avec les possibilités offertes nativement par l'Active Directory, on voit rapidement qu'on ne pourra pas appliquer toutes les recommandations.

Exemple d'une politique de mot de passe affinée
Exemple d'une politique de mot de passe affinée

Sur des choses basiques comme la longueur minimale ou l'âge maximal du mot de passe, ce sera gérable. Par contre, sur les recommandations plus spécifiques comme le blocage de certaines chaînes de caractères ou la vérification dans les fuites de données, ce ne sera pas possible avec la méthode native de l'Active Directory. Pour la complexité des mots de passe, il est bien possible d'imposer le fait que le mot de passe doive respecter une certaine complexité, mais cette complexité n'est pas ajustable. Dommage.

Voici un récapitulatif :

Même si cette méthode ne remplit pas toutes les cases vis-à-vis des recommandations de l'ANSSI, il vaut mieux mettre en place une stratégie de mot de passe affinée plutôt que de ne rien faire.

B. La solution Password protection for Windows Server Active Directory

Azure AD intègre une fonctionnalité baptisée "Password protection for Windows Server Active Directory". Cette fonctionnalité s'applique aux utilisateurs Cloud, mais aussi aux utilisateurs locaux de l'Active Directory lorsqu'il y a une synchronisation avec Azure AD Connect.

Avec Azure AD Password Protection, vous allez renforcer la sécurité de vos mots de passe locaux puisque vous allez pouvoir bloquer certains termes (et leurs variantes) à partir d'un dictionnaire personnalisé, limité à 1000 entrées. Par exemple, avec l'entrée "it-connect", les mots de passe suivants sont bloqués : "it-connect123", "it-c0nnect14!" ou encore "1t-c0nnect14!". Certaines substitutions ne sont pas prises en compte, car si l'on bloque "securite", on peut définir "S€curite14!" comme mot de passe.

En complément, Microsoft dispose de sa propre liste globale de mots de passe interdits (car trop faibles). J'ignore combien de mots de passe contient cette liste (ce n'est pas précisé) mais certains mots de passe présents dans des fuites de données semblent fonctionner. En tout cas, un mot de passe basique comme "Password123!" est bien bloqué alors qu'il pourrait matcher avec la politique de sécurité. Idem pour "Azerty123!" qui est bien bloqué, par contre "Motdepasse123!" et "123soleil" sont autorisés. J'ai tendance à penser que l'outil de Microsoft analyse surtout les mots anglais et qu'il ne doit pas forcément se référer à une liste externe comme I Have Been Pwned.

En cumulant une politique de mot de passe affinée et la protection Password Protection en complément, on obtient la synthèse suivante :

Cette fonctionnalité est incluse dans certaines licences et vous devez couvrir vos utilisateurs. L'installation est assez simple et s'appuie sur la mise en œuvre d'agents sur vos serveurs locaux. L'outil en tant que tel est peu configurable pour le moment, ce qui est dommage.

Si vous souhaitez en savoir plus sur Password Protection, je vous invite à lire ce tutoriel :

C. La solution Specops Password Policy

En termes de solution payante et proposée par un éditeur tiers, je souhaitais inclure Specops Password Policy (SPP) à cet article. Pourquoi ? Pour une raison simple : je connais ce logiciel et je sais qu'il répond à la majorité des recommandations de l'ANSSI, pour ne pas dire toutes.

Ce logiciel va beaucoup plus loin que la solution native intégrée à l'Active Directory, notamment pour gérer la complexité des mots de passe. En fait, vous pouvez créer des règles très précises pour imposer l'utilisation à minima de X majuscules, X minuscules, X chiffres, etc...

Concernant le blocage des suites de caractères, c'est géré par SPP, car il y a une option pour bloquer les caractères identiques consécutifs, et il est possible de créer des expressions régulières pour empêcher certains patterns.

Pour bloquer la présence des informations personnelles dans le mot de passe (nom, prénom, date de naissance), c'est un peu plus complexe. L'outil intègre une option pour empêcher l'utilisation de l'identifiant dans le mot de passe, ce qui dans de nombreux cas, devrait permettre de bloquer le nom et le prénom puisque c'est souvent utilisé pour construire le login Active Directory de l'utilisateur. Pour la date de naissance, cette option n'est pas prise en charge par l'outil proposé par Specops. Pour cela, il faudrait pouvoir se référer à un attribut de l'Active Directory, pour chaque utilisateur. Néanmoins, la solution SPP intègre la gestion de dictionnaires personnalisés, ce qui vous permet d'importer des dictionnaires existants, ou de créer votre propre dictionnaire : vous pouvez créer un dictionnaire avec toutes les dates de naissance de vos salariés (cela signifie aussi qu'un utilisateur X ne pourra pas utiliser dans son mot de passe la date de naissance d'un utilisateur Y, car le dictionnaire est commun à tous les utilisateurs ciblés par la politique).

Pour ma part, je vous recommande de créer un dictionnaire avec le nom de votre entreprise, car c'est souvent réutilisé dans les mots de passe. Enfin, à partir des mots du dictionnaire l'outil bloquera aussi les variantes (exemple : le mot "itconnect" implique que "itc0nnect" avec un zéro sera bloqué aussi), en prenant compte de nombreuses méthodes de substitution (plus que la solution Microsoft présentée ci-dessus).

Aperçu de Specops Password Policy
Aperçu de Specops Password Policy

La solution de l'éditeur Specops est capable de vérifier si votre mot de passe a été compromis (fuite de données, collecté via les honey pots SpecOps, etc.), en s'appuyant à la fois sur une base locale et sur une base en ligne au travers d'une API. Cette base en ligne est actualisée quotidiennement et elle contient 2,5 milliards de mots de passe. Si c'est le cas, l'utilisateur sera notifié par e-mail/SMS et invité à changer son mot de passe de nouveau. Sur ce point, on est vraiment conforme vis-à-vis des préconisations de l'ANSSI.

Voici un récapitulatif :

Pour découvrir plus en détail ce logiciel, je vous invite à lire mon tutoriel complet au sujet de Specops Password Policy, dans lequel vous pouvez retrouver également une vidéo de démonstration (réalisée par mes soins).

IV. Conclusion

Suite à la lecture de cet article, vous avez connaissance des recommandations de l'ANSSI en matière de politique de mot de passe, et en plus, vous avez quelques pistes à explorer afin de mettre en pratique ces recommandations sur un annuaire Active Directory. En complément de la mise en œuvre de cette politique de mot de passe, il ne faudra pas oublier de configurer le verrouillage des comptes afin de bloquer les attaques Brute Force.

Si vous connaissez d'autres solutions susceptibles de mettre en place une politique de mot de passe qui respecte les best practices de l'ANSSI, n'hésitez pas à poster un commentaire.

The post Politique de mot de passe : comment appliquer les bonnes pratiques de l’ANSSI ? first appeared on IT-Connect.

Bloquer les attaques sur son serveur Web (Apache + PHP) avec CrowdSec

2 novembre 2021 à 10:30

I. Présentation

Dans ce tutoriel, nous allons voir comment l'outil gratuit CrowdSec va nous permettre de protéger un serveur Web (Apache et PHP) contre les attaques informatiques.

Pour rappel, CrowdSec est un outil open source, gratuit, français, qui s'inspire du célèbre outil Fail2ban et qui a pour objectif de protéger votre serveur, en détectant puis en bloquant les attaques.

Récemment, les équipes de CrowdSec ont travaillé sur le développement d'un bouncer PHP pour protéger les serveurs Web qui tournent sur "Apache + PHP". Une excellente une idée puisque PHP est utilisé sur une très très grande majorité des sites Internet à l'échelle mondiale.

A. L'objectif du jour

Pour suivre ce tutoriel, nous allons utiliser deux machines : un serveur Web qui sera notre cible, et une seconde machine pour émettre une attaque très légère, mais réelle. Ce qui donne :

  • Un serveur Web sous Debian 11
    • Apache et PHP installés, avec un site Web tout simple
    • CrowdSec va être déployé pour protéger le serveur
  • Un poste client pour simuler une attaque, sous Kali Linux pour ma part
    • L'outil Nikto sera utilisé pour effectuer un scan du serveur Web afin de rechercher des vulnérabilités ou des erreurs de configuration

Avant d'aller plus loin, je vous invite à prendre connaissance de mon premier article au sujet de CrowdSec où je présente plus précisément l'outil et dans lequel nous avons vu comment protéger un serveur Web sous Nginx.

Si vous êtes prêt à découvrir ce second cas d'usage de CrowdSec, poursuivez la lecture !

II. Mise en place d'Apache et PHP sur Debian 11

Pour la mise en place du serveur Apache avec PHP, je vous recommande de lire ce tutoriel sur la mise en place d'un serveur LAMP sous Debian 11. Il servira de point de départ afin d'avoir un serveur Web opérationnel.

On va se contenter d'une simple page d'accueil "index.php" avec un message "Hello !". Pour créer cette page, suivez ces quelques étapes.

sudo nano /var/www/html/index.php

Insérez ce petit bout de code :

<?php
echo "<h1>Hello !</h1>";
?>

Enfin, supprimez la page d'accueil d'origine d'Apache.

sudo rm /var/www/html/index.html

Le serveur Web est prêt, nous avons une page PHP en place. Elle est accessible sur le domaine it-connect.tech.

III. Installation de CrowdSec sur Debian 11

Sur Debian 11, CrowdSec est directement dans les dépôts, ce qui va nous faciliter la vie. Il suffit de mettre à jour le cache des paquets et de lancer l'installation :

sudo apt-get update
sudo apt-get install -y crowdsec

Le cas échéant, si le paquet n'est pas disponible, vous devez utiliser cette méthode pour réaliser l'installation :

curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash 
sudo apt install crowdsec

Lors de l'installation, CrowdSec va analyser votre machine afin de détecter les services présents et de télécharger les collections associées. Ces composants vont permettre à CrowdSec de détecter les attaques (sans les bloquer).

On peut lister les collections avec la commande suivante :

cscli collections list

Si la collection "base-http-scenarios" est présente dans la liste, ce qui normalement le cas si vous avez déjà installé Apache sur votre serveur, cela va notamment permettre de bloquer les mauvais User Agents, comme ceux utilisés par certains outils de scans. Ceci n'est qu'un exemple, car cette collection va détecter d'autres événements comme la recherche de backdoors, etc.

On peut regarder si nous avons des décisions actives au niveau de notre instance CrowdSec. En toute logique, non. Vérifions que ce soit bien le cas avec la commande ci-dessous issue de "cscli", l'ensemble de commandes associées à CrowdSec.

sudo cscli decisions list

IV. Mon serveur Web Apache + PHP vs Nikto

A. Premier scan avec Nikto

Rappel : Nikto est un outil open source qui sert à analyser un serveur Web à la recherche de vulnérabilités ou de défaut de configuration.

Avant toute chose, il faut installer l'outil Nikto sur la machine qui sert à réaliser le scan. Pour ma part, j'utilise Kali Linux via WSL (Windows Subsystem for Linux).

L'installation s'effectue très simplement :

sudo apt-get update
sudo apt-get install nikto

Avant d'exécuter le scan Nikto, vous pouvez vérifier que votre machine Kali Linux parvient à charger la page d'accueil de votre site :

curl -I it-connect.tech

Si vous obtenez un résultat avec un code de retour HTTP égal à 200, c'est tout bon ! Maintenant, on va lancer un scan de notre serveur Web avec Nikto. Pour cela, on spécifie l'adresse IP de l'hôte cible ou le nom de domaine, et on laisse tourner. Comme ceci :

nikto -h it-connect.tech

Suite au scan avec Nikto, mon adresse IP est bien dans le viseur de CrowdSec puisqu'il a décidé de bannir mon adresse IP. Cependant, l'adresse IP n'est pas bloquée. En effet, CrowdSec doit s'appuyer sur un Bouncer pour appliquer la décision et bannir l'adresse IP.

sudo cscli decisions list

On peut voir aussi que mon analyse avec Nikto a généré plusieurs alertes, ce qui donne des indications sur les types d'attaques détectés (reason).

cscli alerts list

B. Installation de PHP Composer

Pour déployer le Bouncer PHP sur son serveur, il faut installer Composer sinon il ne s'installera pas correctement. Pour l'installer, nous avons besoin de deux paquets : php-cli et unzip, que l'on va installer sans plus attendre :

sudo apt-get update
sudo apt-get install php-cli unzip

Ensuite, il faut se positionner dans son répertoire racine et récupérer l'installeur avec Curl :

cd ~
curl -sS https://getcomposer.org/installer -o composer-setup.php

Une fois qu'il est récupéré, il faut vérifier que le hash SHA-384 correspond bien à l'installeur que l'on vient de télécharger. Cela permet de s'assurer de l'intégrité du fichier. On stocke le hash dans une variable nommée "HASH" :

HASH=`curl -sS https://composer.github.io/installer.sig`

Puis, on lance la commande fournie sur le site officiel de Composer qui va permettre de vérifier le hash avant que l'installation soit lancée :

php -r "if (hash_file('SHA384', 'composer-setup.php') === '$HASH') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"

Vous devez obtenir le message "Installer verified". Sinon, cela signifie que votre installeur est corrompu, vous devez relancer le téléchargement.

Enfin, lancez l'installation de Composer :

sudo php composer-setup.php --install-dir=/usr/local/bin --filename=composer

Pour vérifier que l'installation est opérationnelle, exécutez simplement :

composer

Vous devez obtenir ceci :

Composer est correctement installé, vous pouvez passer à l'installation du Bouncer en lui-même.

C. Mise en place du Bouncer PHP

Souvenez-vous du premier tutoriel sur CrowdSec où j'utilisais un serveur NginX. J'avais utilisé le Bouncer NginX directement pour bloquer les adresses IP que CrowdSec souhaitait bannir. Cette fois-ci, comme nous n'utilisons pas NginX mais Apache, on va se tourner vers un autre Bouncer : PHP.

Note : le Bouncer PHP développé par CrowdSec prend en charge de nombreuses versions (PHP 7.2.x, 7.3.x, 7.4.x et 8.0.x).

Nous avons besoin de Git pour installer ce Bouncer afin de cloner le projet. Pour installer Git :

sudo apt-get install git

Ensuite, on récupère le projet en le clonant en local :

git clone https://github.com/crowdsecurity/cs-php-bouncer.git

On obtient un dossier nommé "cs-php-bouncer" dans lequel on va se positionner :

cd cs-php-bouncer/

Puis, on lance le script d'installation (il ne doit pas être lancé avec le compte "root", ni "sudo" !) en spécifiant que l'on utilise le serveur Web "Apache" :

./install.sh --apache
Installation du Bouncer PHP sur CrowdSec
Installation du Bouncer PHP sur CrowdSec

Enfin, on suit les instructions qui s'affichent à l'écran pour finaliser l'installation. On définit comme propriétaire sur le dossier "/usr/local/php/crowdsec/" l'utilisateur associé à Apache. Par défaut, il s'agit de l'utilisateur "www-data".

sudo chown www-data /usr/local/php/crowdsec/

Puis, on termine en rechargeant la configuration d'Apache :

sudo systemctl reload apache2

Si on liste les Bouncer installés sur notre serveur, on va voir qu'il apparaît dans la liste :

sudo cscli bouncers list

D. Deuxième scan avec Nikto : le bouncer PHP va-t-il se montrer intraitable ?

Cette fois-ci, on devrait être en mesure de détecter l'attaque, de décider de bannir l'adresse IP de l'hôte "Nikto" et surtout d'appliquer la décision grâce au Bouncer PHP. C'est ce que nous allons vérifier.

On peut commencer par utiliser Curl pour vérifier que l'on obtient bien un code de retour HTTP 200.

curl -I it-connect.tech

Puis, on lance notre scan Nikto :

nikto -h it-connect.tech

Cette fois-ci, le scan mouline un peu... Comme s'il était bloqué par quelque chose. Si on force son arrêt (CTRL+C) et que l'on relance la commande Curl, on peut voir que le code de retour HTTP a changé : HTTP/1.0 403 Forbidden. Ce qui correspond à un accès refusé sur la page, y compris si l'on essaie d'accéder au serveur avec l'adresse IP au lieu du nom.

Si j'essaie d'accéder au site avec un navigateur, on peut voir qu'un message s'affiche pour indiquer que mon adresse IP a été bloquée par CrowdSec ! Le Bouncer PHP est entré en action !

Je vous rappelle que l'on peut débannir manuellement une adresse IP avec la commande suivante (nous allons utiliser cette commande dans la suite du tutoriel) :

sudo cscli decisions delete --ip X.X.X.X

De la même façon, on peut aussi bannir manuellement une adresse IP :

sudo cscli decisions add --ip X.X.X.X

V. Bouncer PHP : mise en place d'un captcha

Avec la configuration actuelle, l'adresse IP sera bloquée pour une durée de 4 heures et l'utilisateur n'a pas de possibilité d'être débloqué pendant ce temps. À moins de prendre la peine de contacter le Webmaster du site...

Pour limiter l'impact des éventuels faux positifs sur la règle "bad user agents", nous allons présenter un captcha à l'utilisateur bloqué, plutôt qu'un blocage pur. De cette façon, un robot sera bloqué tandis qu'un utilisateur réel pourra  déverrouiller l'accès au site. Nous allons réserver le même sort au crawlers malveillants (robots d'exploration).

Pour cela, il faut éditer le fichier de configuration nommé "profiles.yaml", qui est au format YAML, comme son nom l'indique.

sudo nano /etc/crowdsec/profiles.yaml

Ce fichier contient une configuration par défaut qui sert à bloquer les adresses IP pendant 4 heures, peu importe le type d'attaque détectée. Nous souhaitons conserver ce comportement, à l'exception de deux types d'alertes :

  • http-crawl-non_statics
  • http-bad-user-agent

Il faut que l'on ajoute notre configuration au début du fichier, et non pas à la fin. À ce jour, CrowdSec gère la priorité par rapport à l'ordre dans le fichier puisque dès que l'on match sur une règle, on ne vérifie pas la suite (un peu sur le même principe que les ACL sur un routeur, finalement) compte tenu de la présence de la directive "on_success: break" (voir ci-dessous).

Autrement dit, si l'on ajoute notre configuration spécifique à la suite dans le fichier profiles.yaml, cela ne fonctionnera pas, car la première règle correspondra (matchera) toujours, et donc notre règle ne sera pas prise en compte.

Voici le bout de code à ajouter au tout début du fichier :

# Bad User agents + Crawlers - Captcha 4H
name: crawler_captcha_remediation
filters:
- Alert.Remediation == true && Alert.GetScenario() in ["crowdsecurity/http-crawl-non_statics", "crowdsecurity/http-bad-user-agent"]
decisions:
- type: captcha
duration: 4h
on_success: break
---

La partie "filters" sert à spécifier que l'on cible seulement les scénarios d'alertes "http-crawl-non_statics" et "http-bad-user-agent". Ensuite, au niveau du "type", on spécifie "captcha" au lieu de "ban" qui est l'action standard.

Enfin, la partie "duration" sert à spécifier la durée pendant laquelle on présente un captcha à l'adresse IP associée au "blocage". En l'occurrence, 4h par défaut, mais vous pouvez modifier cette valeur.

Au final, vous obtenez ceci :

Sauvegardez le fichier et fermez-le. Il ne reste plus qu'à relancer CrowdSec :

sudo systemctl restart crowdsec

Avant de refaire des tests, on va supprimer la décision qui s'applique actuellement sur notre adresse IP, c'est-à-dire "ban". On utilise la commande ci-dessous en remplaçant "X.X.X.X" par l'IP publique correspondante.

sudo cscli decisions delete --ip X.X.X.X

Ensuite, il faut que l'on simule un accès depuis un user-agent non autorisé, car si j'utilise Firefox, Chrome, Brave, Edge, etc... cela ne fonctionnera pas, car ce sont des user-agent légitimes. Pour cela, on peut se référer à la liste de user-agents malveillants relayée par CrowdSec sur GitHub. Pour l'outil à utiliser, on partira sur l'excellent Curl que l'on a déjà utilisé précédemment.

Nous allons utiliser le modèle de commande suivant :

curl -I it-connect.tech -H "User-Agent: <nom-user-agent>"

Voici quelques exemples :

curl -I it-connect.tech -H "User-Agent: Cocolyzebot"
curl -I it-connect.tech -H "User-Agent: Mozlila"
curl -I it-connect.tech -H "User-Agent: OpenVAS"
curl -I it-connect.tech -H "User-Agent: Nikto"

En effectuant deux-trois requêtes Curl à destination de notre site, on se retrouve rapidement avec un code d'erreur HTTP : 401 Unauthorized. Comprenez accès non autorisé.

Maintenant que je suis bloqué par CrowdSec, on va utiliser un navigateur classique pour voir comment réagit le serveur Web.

Aaaaah ! Bonne nouvelle ! Une page avec un captcha s'affiche ! Pour outrepasser le blocage, il suffit de compléter le captcha, de cliquer sur "Continue", afin d'accéder au site.

CrowdSec - Page de blocage avec captcha
CrowdSec - Page de blocage avec captcha

Si on liste les décisions actives, on peut voir que mon adresse IP est bien associée à l'action "captcha" au lieu de l'action "ban". On peut voir aussi que mon instance CrowdSec a banni quelqu'un d'autre, qui visiblement, s'en prend à mon serveur Web.

sudo cscli decisions list

Si l'on effectue un scan avec Nikto comme nous l'avons fait à plusieurs reprises dans cette démonstration, nous n'aurons pas le captcha, nous allons être directement bannis. En fait, il y a bien un user-agent Nikto, mais le scan avec cet outil va générer d'autres alertes avant celle sur le user-agent, ce qui implique que c'est l'action "bannir" qui va s'appliquer avant l'action "captcha". En soi, ce n'est pas plus mal, car quelqu'un qui scanne notre serveur Web, on préfère autant qu'il soit complètement bloqué.

VI. Conclusion

Voilà, nous venons de voir comment sécuriser une application ou un site Internet qui tourne sur un serveur Web Apache + PHP en détectant et bloquant les attaques avec CrowdSec. On peut voir que CrowdSec est un outil efficace et personnalisable grâce à la mise en place du captcha.

Je vous rappelle que vous pouvez démarrer un container Metabase pour accéder à un dashboard afin de visualiser de beaux graphiques et avoir des métriques précises quant à l'activité de CrowdSec sur votre serveur (voir mon précédent tutoriel).

Pour finir, quelques liens :

The post Bloquer les attaques sur son serveur Web (Apache + PHP) avec CrowdSec first appeared on IT-Connect.

GPO – Comment configurer AppLocker pour sécuriser vos postes Windows ?

7 octobre 2021 à 13:00

I. Présentation

Dans ce tutoriel, nous allons voir comment configurer AppLocker par GPO pour sécuriser les postes Windows en bloquant l'exécution et l'installation de logiciels.

La solution AppLocker est la remplaçante d'une autre fonction similaire, configurable par GPO, mais moins complète : la stratégie de restriction logicielle.

AppLocker permet de créer des règles pour définir les applications autorisées à être exécutées par les utilisateurs lambdas sur les machines du domaine. Grâce à ces restrictions, vous allez pouvoir lutter contre l'installation de logiciels non approuvés par le service informatique, de logiciels crackés en version portable, des logiciels portables au sens large, mais cela va permettre aussi de limiter l'installation de malwares sur les postes de travail.

AppLocker va permettre d'agir sur quatre types d'éléments : les exécutables, les installeurs au format Windows Installer (package MSI), les scripts et les applications modernes au format APPX.

Pour en savoir plus sur les différences entre AppLocker et les stratégies de restriction logicielle, consultez la documentation Microsoft.

Qu'allons-nous mettre en place ?

Pour ce tutoriel AppLocker, nous allons apprendre à créer une politique afin de bloquer l'exécution et l'installation de tous les logiciels, à l'exception :

  • Des logiciels présents dans Program Files (car ils sont déjà installés)
  • Des logiciels présents dans le dossier d'installation de Windows (les utilitaires natifs et les composants indispensables au bon fonctionnement de Windows s'y trouvent...)
  • Des applications modernes signées
  • De l'application Microsoft Teams (pour vous montrer le principe de création d'une exception)

Cette politique sera appliquée uniquement aux membres d'un groupe de sécurité Active Directory.

Pour suivre ce tutoriel, vous avez besoin de deux machines :

  • Un contrôleur de domaine Active Directory
  • Une machine pour tester AppLocker, Windows 10 ou Windows 11, c'est très bien ! Voire même un serveur.

II. AppLocker : les systèmes d'exploitation pris en charge

La solution AppLocker existe depuis quelques années déjà puisqu'elle a été introduite dans Windows à l'occasion de la sortie de Windows 7 et Windows Server 2008 R2. Au fil des versions et des sorties de Windows, Microsoft a fait évoluer AppLocker pour ajouter des fonctionnalités.

AppLocker est pris en charge sur Windows 10 et Windows 11 : vous pouvez miser sans problème sur cette fonctionnalité. Il en va de même pour Windows Server, si vous souhaitez mettre en place une politique AppLocker sur un serveur RDS.

Néanmoins, il y a un "mais" et c'est un petit détail qui fait mal. Pour utiliser AppLocker sur les postes de travail, vous devez utiliser une édition Entreprise ou Education de Windows. Autrement dit, AppLocker ne fonctionnera pas sur Windows 10 Pro, ni Windows 11 Pro, mais il fonctionnera sur Windows 10 Enterprise et Windows 10 Education.

Pour Windows Server, cette restriction n'existe pas pour les versions à partir de Windows Server 2012.

Maintenant que vous avez pris en compte de ce détail, nous allons pouvoir commencer la configuration.

III. Création d'un groupe pour appliquer la règle AppLocker

Avant d'attaquer la GPO AppLocker, nous allons créer un groupe de sécurité sur lequel va s'appliquer notre politique AppLocker.

À partir de la console "Utilisateurs et ordinateurs Active Directory", j'ai créé le groupe de sécurité "GG-Restrictions-Logiciels". Vous pouvez le créer avec le Centre d'administration Active Directory ou avec PowerShell : vous avez le choix.

Au sein de ce groupe, j'ai ajouté un salarié de l'entreprise pour lui appliquer les restrictions : "guy.mauve".

IV. Configuration d'une GPO AppLocker

À partir de la console de Gestion des stratégies de groupe, créez une nouvelle GPO et liez cette GPO à une OU qui cible vos machines. Pour ma part, je vais cibler l'OU qui contient la machine où se connecte "guy.mauve" et je vais nommer cette GPO "AppLocker", tout simplement.

Ensuite, modifiez cette GPO à l'aide d'un clic droit sur son nom.

A. Configurer le service Identité de l'Application

Pour qu'AppLocker fonctionne, il faut que le service "Identité de l'application" (AppIDSvc) soit actif et démarré automatiquement. Ce n'est pas le cas par défaut. Nous allons configurer la GPO pour configurer ce service sur nos postes de travail.

Parcourez l'arborescence comme ceci :

Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Services système

Ouvrez les propriétés du service "Identité de l'application", cochez la case "Définir ce paramètre de stratégie" et cliquez sur "Automatique".

Validez. Première étape réussie !

B. Créer les règles AppLocker

Pour configurer AppLocker, parcourez l'arborescence de cette façon :

Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies de contrôle de l'application > AppLocker

Ensuite, cliquez sur le lien "Configurer la mise en application des règles" sur la partie de droite.

Pour chaque type de règles, cochez l'option "Configuré" et basculez sur "Appliquer les règles".

Note : j'utilise le mode "Appliquer les règles" dès maintenant, mais en phase de test, c'est pertinent de commencer par une phase d'audit et d'analyse en sélectionnant "Auditer uniquement". De cette façon, les événements AppLocker seront générés, mais il n'y aura pas de restrictions effectives sur la machine.

Validez avec "OK".

Développez "AppLocker", quatre catégories vont s'afficher : règles de l'exécutable (EXE), règles Windows Installer (MSI), règles de scripts et règles d'applications empaquetées (APPX).

Je vous invite à générer les règles par défaut pour les "Règles de l'exécutable", les "Règles Windows Installer" et les "Règles d'applications empaquetées". Pour cela, effectuez un clic droit sur la catégorie et cliquez sur le bouton "Créer des règles par défaut".

Si l'on regarde la partie "Règles de l'exécutable", on peut voir que cette action crée plusieurs règles pour autoriser "Tout le monde" à exécuter les programmes situés dans "Program Files" et "Windows". En complément, les administrateurs n'auront pas de restrictions. C'est une bonne base pour la suite.

Dans le même esprit, une règle est créée pour les applications empaquetées.

Désormais, passons à la création de notre règle personnalisée. Effectuez un clic droit sur "Règles de l'exécutable" et cliquez sur "Créer une règle". Un assistant va se lancer.

Je vous rappelle que l'objectif est de créer une règle pour empêcher le groupe "GG-Restrictions-Logiciels" d'exécuter et d'installer des logiciels, à part ceux présents dans "Program Files" et "Windows".

Cliquez sur "Suivant" lorsque le premier écran apparaît.

Choisissez l'action "Refuser" et pour le champ "Utilisateur ou groupe", sélectionnez le groupe "GG-Restrictions-Logiciels". Poursuivez.

Lorsque l'on crée une règle, il y a trois types de conditions principales :

  • Editeur : règle basée sur l'éditeur de l'exécutable. Par exemple : autoriser uniquement l'exécutable d'un éditeur spécifique, avec un nom spécifique, dans une version spécifique, ou autoriser tous les exécutables de l'éditeur Microsoft.
  • Chemin d'accès : règle basée sur un chemin d'accès. Par exemple : bloquer l'exécution de tous les exécutables situés sur le Bureau de l'utilisateur.
  • Hachage du fichier : règle basée sur le hash de l'exécutable, tout en sachant qu'un hash va évoluer pour un même logiciel d'une version à l'autre.

Choisissez "Chemin d'accès" et continuez.

Pour le chemin d'accès, précisez "*.*" : cela signifie que l'on refuse tous les exécutables ! Mais, nous allons créer deux exceptions à la prochaine étape.

Sous "Ajouter une exception", choisissez "Chemin d'accès" et cliquez sur le bouton "Ajouter". Créez une première exception avec ce chemin :

%PROGRAMFILES%\*

Répétez l'opération avec ce chemin :

%WINDIR%\*

Cela va permettre d'autoriser les exécutables situés dans "Program Files" et le dossier d'installation de Windows. Cliquez sur "Suivant".

Nommez cette règle et indiquez une précision si vous le souhaitez. Cliquez sur "Créer".

Nous obtenons le résultat suivant :

Je vous invite à créer une règle similaire, mais dans la catégorie "Règles Windows Installer" pour bloquer les fichiers MSI.

Une fois que c'est fait, la GPO est prête, nous allons tester depuis un poste client.

V. Tester la configuration AppLocker

Sur le poste client, je me connecte avec l'utilisateur "guy.mauve" puisqu'il est membre du groupe "GG-Restrictions-Logiciels". Ensuite, j'effectue un "gpupdate /force" et pendant ce temps je télécharge quelques logiciels : Putty, Firefox Portable, Chrome, Teams et 7-Zip.

Le problème, c'est que l'administrateur système bloque l'exécution de tous ces exécutables ! Et oui, notre stratégie AppLocker rentre en jeu et contrôle l'exécution de chaque fichier ! Comme l'exécutable n'est pas dans un dossier autorisé (Program Files ou Windows), il est bloqué !

Dans le même esprit, avec un package MSI (suite à la création de la seconde règle).

Si l'on regarde dans l'Observateur d'événements de la machine locale, on peut voir que tous les événements AppLocker sont enregistrés. Vous pouvez les retrouver dans :

Journaux des applications et des services > Microsoft > Windows > AppLocker

Ensuite, il y a un journal par catégorie de règles, ce qui est appréciable pour le debug. On peut voir que "guy.mauve" a tenté d'exécuter "Putty.exe" et que l'exécution a été empêchée. Là ce sont des exécutables sans réels dangers, mais ce serait un logiciel malveillant, ce serait bloqué également et d'autant plus appréciable !

J'en profite pour parler du module PowerShell AppLocker. Il permet de récolter des informations assez précises, comme par exemple la liste des applications refusées pour un utilisateur avec la commande "Get-AppLockerFileInformation".

Get-AppLockerFileInformation -EventLog -EventType Denied

À l'inverse, on peut voir ce qui a été autorisé :

Get-AppLockerFileInformation –EventLog –EventType Allowed

VI. AppLocker : créer une exception pour autoriser l'installation de Teams

Pour finir, nous allons apprendre à créer une exception pour autoriser l'installation d'un logiciel spécifique, en l'occurrence Teams, malgré les restrictions mises en place. Un cas très courant puisque Teams peut s'installer sans les droits Administrateur étant donné qu'il s'installe dans le répertoire "AppData" du profil de l'utilisateur, comme d'autres applications.

Lorsque l'on télécharge Teams, on obtient le fichier suivant : Teams_windows_x64.exe

La première chose à faire, c'est ajouter une nouvelle exception sur notre règle située dans "Règles de l'exécutable". Effectuez un clic droit sur la règle "Empêcher installation de logiciels" et cliquez sur "Propriétés".

Au sein de l'onglet "Exceptions", choisissez "Editeur" sous "Ajouter une exception" puis cliquez sur le bouton "Ajouter".

Vous devez indiquer le chemin vers l'exécutable de Teams pour que l'assistant AppLocker récupère des informations sur l'exécutable, notamment l'éditeur. Ensuite, les différents champs seront complétés automatiquement : Editeur, Nom du produit, Nom du fichier et Version du fichier.

Prenez le curseur à gauche et positionnez-le sur "Editeur". Cela va permettre d'accepter toutes les valeurs pour les autres champs et d'autoriser toutes les applications signées par l'éditeur Microsoft. En fait, on pourrait être plus restrictif et autoriser seulement le produit "MICROSOFT TEAMS", mais le problème c'est que Teams s'appuie sur plusieurs composants. Si l'on ne crée par une autorisation plus large, l'installation échouera. Validez.

La création d'une exception dans AppLocker ne suffit pas : même avec cette exception, l'installeur de Teams sera bloqué ! En fait, en plus d'ajouter une exception, il faut créer une règle pour autoriser l'éditeur Microsoft. Une petite subtilité, mais qu'il faut connaître si vous ne voulez pas vous casser les dents pendant 3 heures sur une règle AppLocker qui ne s'applique pas (ce qui devrait arriver à un moment donné malgré tout).

Toujours dans "Règles de l'exécutable", créez une nouvelle règle... et :

  • Choisissez l'action "Autoriser" et ciblez "Tout le monde" ou le groupe "GG-Restrictions-Logiciels"
  • Choisissez le type de condition principale "Editeur"
  • Indiquez le fichier exécutable de Teams comme fichier de référence et positionnez le curseur sur "Editeur"

Finalisez la création de la règle.

Vous devez obtenir ceci :

À partir de là, sur le poste client, l'utilisateur "guy.mauve" sera toujours restreint à l'exception près qu'il pourra exécuter les logiciels signés par Microsoft qui ne sont pas situés dans "Program Files" et "Windows". Pour Teams, cela va lui permettre d'installer l'application dans sa session.

VII. AppLocker : efficace avec PowerShell et l'Invite de commande

Nous avons vu comment exécuter le logiciel depuis l'Explorateur de fichiers et nous avons pu constater que l'exécution est bien bloquée. Il faut savoir aussi que l'exécution sera bloquée si l'on tente de lancer l'exécutable depuis la console PowerShell ou l'Invite de commande. Par exemple :

Cela peut paraître normal, mais avec la méthode plus ancienne, à savoir "Stratégie de restriction logicielle", ce n'est pas le cas. En effet, si vous ouvrez une console comme l'Invite de commande sur votre machine en tant qu'utilisateur standard (et donc restreint par la stratégie de restriction logicielle), vous allez pouvoir exécuter les fichiers bloqués. Ce qui nécessite de bloquer l'accès à l'Invite de commande et la console PowerShell, ce qui n'est pas un mal de toute façon ! Voilà, un atout de plus pour AppLocker puisqu'il est efficace contre cette méthode de contournement.

Cette introduction à AppLocker touche à sa fin ! Vous avez désormais connaissance des bases pour configurer cette fonctionnalité très intéressante afin de sécuriser vos postes de travail, mais aussi vos serveurs !

The post GPO – Comment configurer AppLocker pour sécuriser vos postes Windows ? first appeared on IT-Connect.

Comment bloquer les attaques Brute Force RDP avec EvlWatcher ?

28 septembre 2021 à 11:30

I. Présentation

Dans ce tutoriel, nous allons voir comment bloquer les attaques Brute Force sur le service RDP (Bureau à distance) d'une machine Windows avec l'outil gratuit EvlWatcher.

Les attaques par brute force sont très courantes sur les services populaires comme le RDP ou le SSH. C'est d'autant plus vrai si vous décidez d'exposer sur Internet le service RDP d'un serveur. Bien souvent, lorsque l'on se connecte sur un serveur Windows pour l'administrer, on le fait à partir du client "Bureau à distance" et du protocole RDP. Donc, cela représente une porte d'entrée potentielle pour les pirates.

Si l'attaque est effectuée sur un compte utilisateur existant au sein de l'Active Directory, il y a des chances pour que le compte soit verrouillé au bout d'un certain nombre de tentatives. Encore que, ça dépend de votre politique à ce sujet.

Pour protéger son serveur Windows contre les attaques de type "Brute Force" sur le service RDP, il y a plusieurs pistes à explorer :

  • Utiliser un port d'écoute différent pour le RDP : remplacer le port 3389 par un autre port pour tenter de masquer le service. Voir ce tutoriel : modifier le port RDP par GPO
  • Mettre en place la double authentification (MFA) au niveau du RDP : il existe différentes solutions, comme le logiciel UserLock de chez IS Decisions. Voir ce tutoriel : mise en place de la double authentification avec UserLock
  • Bannir les adresses IP effectuent des attaques par Brute Force : c'est ce que nous allons voir avec la mise en place du logiciel EvlWatcher

La question que l'on peut se poser, c'est "pourquoi EvlWatcher et pas un autre outil ?". Pour faire simple, il est gratuit, son code source est disponible sur GitHub, il s'installe très rapidement et il fonctionne suffisamment bien pour que je vous en parle !

EvlWatcher va permettre de détecter les attaques par Brute Force sur votre machine Windows en analysant les journaux d'événements de Windows et en bloquant les adresses IP malveillantes à l'aide du pare-feu de Windows. C'est en quelque sorte un fail2ban pour Windows qui surveille le service RDP.

J'aurais pu également vous proposer ma propre solution basée sur PowerShell puisque l'on peut lire les logs avec Get-EventLog et que l'on peut agir sur le pare-feu avec Set-NetFirewallRule. Mais, pour le moment, elle n'existe pas et je suis tombé sur EvlWatcher.

II. Prise en main d'EvlWatcher

Commençons par télécharger EvlWatcher sur GitHub, tout en sachant qu'il est mis à jour de temps en temps. Ce qui est rassurant.

Vous obtiendrez un exécutable très léger : procédez à l'installation, deux trois clics suffisent. Il faut savoir que par défaut l'outil s'installe dans "C:\Program Files (x86)\EvlWatcher" et qu'il crée un service nommé "EvlWatcher service" sur la machine.

Dans le menu Démarrer, vous allez trouver un raccourci nommé "EvlWatcherConsole" qui donne accès à l'interface de gestion du logiciel. Voici à quoi elle ressemble :

Aperçu de la console d'EvlWatcher
Aperçu de la console d'EvlWatcher

L'onglet "Currently banned" se découpe en trois parties :

  • Temporarily banned IPs : les adresses IP bannies temporaires, pour une durée limitée
  • Permanently banned IPs : les adresses IP bannies définitivement (après plusieurs bannissements temporaires)
  • White-Listed IP Patterns : les adresses IP ou les sous-réseaux en liste blanche

Il est possible d'ajouter ou supprimer des adresses IP manuellement dans chaque section. C'est simple, mais efficace pour visualiser rapidement l'état des bannissements sur son serveur.

Au sein des règles de trafic entrant du pare-feu Windows, vous allez retrouver une règle nommée "EvlWatcher" qui est utilisée par le logiciel pour bloquer l'accès (sur tous les ports) aux adresses IP bannies.

La règle de pare-feu d'EvlWatcher
La règle de pare-feu d'EvlWatcher

L'onglet "Live" permet de suivre en live l'activité du logiciel. Lorsqu'une adresse IP est bannie, de nouveaux messages vont s'afficher :

Temporarily banning 192.168.100.12, this is strike 2
Banned 192.168.100.12

Cela signifie que l'adresse IP "192.168.100.12" a été bannie de façon temporaire pour la deuxième fois. Au bout de trois fois (selon la configuration par défaut), elle sera bannie définitivement.

L'onglet "Global Settings" donne accès à quelques paramètres pour gérer les logs : niveau de log, nombre d'entrées dans le journal "Live" ainsi que l'intervalle d'actualisation des logs.

Enfin, l'onglet "Rule Tester" permet de tester une règle de détection. Vous choisissez une règle, vous collez le contenu du log à analyser au format XML (récupéré à partir de l'observateur d'événements) et vous pouvez tester si EvlWatcher détecte bien l'adresse IP.

C'est surtout utile si vous cherchez à ajouter au logiciel de nouvelles capacités de détection, car par défaut, pour le RDP, il s'appuie déjà sur 3 types d'événements différents (divers ID).

Voyons ce que donne EvlWatcher dans la pratique.

III. Tester l'efficacité d'EvlWatcher

Le logiciel est installé sur ma machine et il est actif. Pour vérifier qu'il fonctionne bien, je vais simuler une attaque sur mon serveur protégé par EvlWatcher.

Pour cela, il me suffit d'ouvrir le client Bureau à distance et d'essayer de me connecter en RDP sur mon serveur en utilisant de mauvais identifiants.

Comme c'est la troisième fois que j'effectue une attaque à partir de ce serveur (IP = 192.168.100.12), je suis banni définitivement ! En temps normal, lors de la première attaque, l'hôte est banni temporairement. Par défaut, la durée du bannissement est de 3600 secondes, c'est-à-dire 1 heure.

Pour qu'une adresse IP soit considérée comme bannie, il faut effectuer 5 tentatives de connexion en échec dans un délai de 3 minutes. Cela est modifiable, comme nous allons le voir dans la prochaine partie de ce tutoriel.

IV. Configurer EvlWatcher

Le logiciel EvlWatcher est préconfiguré, mais on peut personnaliser la configuration grâce au fichier XML suivant :

C:\Program Files (x86)\EvlWatcher\config.xml

À l'intérieur, nous retrouvons plusieurs sections où chaque section correspond à une règle de détection. Par exemple, nous avons la section "<Task Name="BlockRDPBrutersBySecurity4625" Active="true">" et chaque section contient sa propre configuration pour définir la durée du bannissement, etc.

Note : à l'heure actuelle, EvlWatcher est fourni avec 3 règles de détection pour le RDP et une règle pour le SSH.

Concrètement, il y a les paramètres suivants :

  • Durée en secondes pendant laquelle un hôte est banni (via le firewall Windows)
<LockTime>
3600
</LockTime>
  • Pour bannir, tenir compte des événements des X dernières secondes pour chaque adresse IP, par défaut 120 secondes soit 2 minutes
<EventAge>
120
</EventAge>
  • Bannir l'hôte distant au bout de X tentatives en échecs, par défaut 5 (dans le délai imparti défini par EventAge)
<TriggerCount>
5
</TriggerCount>
  • Bannir définitivement l'hôte distant au bout de X bannissements temporaires, par défaut 3
<PermaBanCount>
3
</PermaBanCount>

Après modification du fichier de configuration, redémarrez le service d'EvlWatcher. Voici la commande PowerShell :

Restart-Service EvlWatcher

L'outil EvlWatcher est en place et en plus vous savez comment le configurer ! Votre serveur est désormais capable de gérer les attaques par Brute Force RDP. Même s'il y a surement mieux, il présente l'avantage d'être léger, fonctionnel et gratuit.

Il n'est pas possible de mutualiser la base des adresses IP bannies entre plusieurs machines, et il n'est pas non plus possible de recevoir une alerte par e-mail lorsqu'une nouvelle adresse IP est bannie. Lorsque CrowdSec sera compatible Windows, il y a des chances qu'il apporte une réponse encore plus pertinente à cette problématique.

The post Comment bloquer les attaques Brute Force RDP avec EvlWatcher ? first appeared on IT-Connect.

Améliorez la gestion des mots de passe dans l’AD avec Specops Password Policy

22 septembre 2021 à 11:15

I. Présentation

Dans ce tutoriel, nous allons découvrir le logiciel Specops Password Policy. Il va permettre de mettre en place des politiques de mots de passe très flexibles au niveau de l'Active Directory et d'accompagner les utilisateurs pour le renouvellement de leur mot de passe.

La mise en place d'une politique de mots de passe n'est jamais une tâche facile en entreprise. Bien souvent, les utilisateurs sont réticents à la mise en place de contraintes concernant les mots de passe. Pourtant, c'est indispensable, car les mots de passe sont continuellement pris pour cible lorsqu'il s'agit d'attaquer une entreprise. Ce fameux sésame est la clé qui ouvre la porte à une partie du système d'information. Pour lutter contre les attaques de type brute force et password spraying, il n'y a pas de secrets : il faut mettre des mesures de protection en place.

Nativement, l'Active Directory intègre la possibilité de mettre en place une politique de mots de passe pour les comptes des utilisateurs. Même si l'on peut mettre en place les stratégies de mots de passe affinées, cette solution native ne va pas assez loin en matière de sécurité des mots de passe et dans la gestion du renouvellement de ces mêmes mots de passe.

Quand je dis "cette solution native ne va pas assez loin en matière de sécurité des mots de passe", j'entends par là qu'il n'est pas possible d'interdire les mots de passe trop proches, et qu'il n'est pas possible de vérifier si le mot de passe saisi par l'utilisateur fait déjà l'objet d'une fuite de données (et que, potentiellement, il est déjà présent dans un dictionnaire).

Le logiciel payant Specops Password Policy va apporter des fonctionnalités que l'on peut résumer en trois points :

  • Définir une politique de mots de passe sur mesure pour les utilisateurs (en s'appuyant sur un groupe de sécurité ou en ciblant une unité d'organisation) en appliquant de nombreuses règles
  • Vérifier si le mot de passe est compromis : le mot de passe définit par l'utilisateur est un mot de passe qui est présent dans une fuite de données ou utilisé par des hackers et repéré par Specops grâce à des honeypots
  • Notifier les utilisateurs par e-mail et/ou SMS : le mot de passe expire dans X jours ou le mot de passe a été trouvé dans une fuite de données

Avant de commencer, vous devez télécharger Specops Password Policy. En utilisant mon lien, vous pouvez obtenir une version d'essai de 45 jours (contre 30 jours en temps normal) : de quoi prendre le temps de découvrir le logiciel et d'avoir de premiers retours.

II. Installation de Specops Password Policy

L'installation de Specops Password Policy (SPP) s'effectue en plusieurs étapes. Pour cette démonstration, je vais utiliser 3 machines virtuelles pour reproduire l'installation selon les bonnes pratiques de l'éditeur :

  • 1 serveur contrôleur de domaine Active Directory - SRV-ADDS-01
  • 1 serveur membre Windows Server - SRV-APPLIS
  • 1 poste de travail sous Windows 11

En résumé, je vais installer sur le contrôleur de domaine : les outils d'administration de SPP et le composant Sentinel qui doit être installé sur l'ensemble des contrôleurs de domaine. Sur le serveur membre, je vais installer également les outils d'administration de SPP ainsi que le composant Arbiter. Enfin, le poste de travail sous Windows est là pour tester le logiciel en se mettant dans la peau d'un utilisateur.

A. A quoi correspondent les rôles Sentinel et Arbiter ?

Les rôles Sentinel et Arbiter sont propres à Specops Password Policy, donc je vais vous expliquer l'utilité de ces deux composants.

Le rôle Sentinel s'installe sur tous les contrôleurs de domaine et il est là pour s'assurer que les politiques de mots de passe définies dans SPP sont bien respectées. En fait, lorsqu'un utilisateur va modifier son mot de passe il va l'analyser pour vérifier qu'il respecte bien la politique qui s'applique sur cet utilisateur.

Le rôle Arbiter sert de proxy (ou de passerelle si vous préférez) entre le contrôleur de domaine et les services Cloud de Specops. Il s'installe sur un serveur différent, car on considère que le contrôleur de domaine n'a pas d'accès à Internet. Grâce à une clé d'API, il va communiquer avec le service "Breached Password Protection API" de Specops pour vérifier si le nouveau mot de passe de l'utilisateur est présent dans une fuite de données, auquel cas il sera refusé.

Note : la vérification du mot de passe au travers de "Breached Password Protection API" s'effectue de façon sécurisée. Le mot de passe n'est pas envoyé entièrement pour requêter l'API puisque la requête est effectuée avec les quatre premiers caractères du mot de passe. Ensuite, l'API retourne les mots de passe correspondants s'il y en a, et c'est au niveau local que la vérification est effectuée.

B. Préparation du contrôleur de domaine

Au premier lancement, l'exécutable décompresse ses données dans le dossier "C:\Temp\SpecopsPasswordPolicy_Setup_7.6.21182.1", ce qui sera utile pour la suite, vous verrez. Il faut commencer par installer la console de gestion du logiciel, par l'intermédiaire du bouton "Administration Tools".

Ensuite, il faut cliquer sur le bouton "Add menu ext." puis sur le bouton "Install" pour installer les différents composants liés à la gestion du logiciel.

Ensuite, revenez au menu principal de l'installeur. Cliquez sur "Domain Controller Sentinel".

Sélectionnez tous les contrôleurs de domaine de votre infrastructure pour déployer l'agent partout. Pour ma part, il n'y en a qu'un seul. Une fois la sélection effectuée, il faut cliquer sur "Install".

Voilà, nous en avons fini avec le contrôleur de domaine pour le moment.

C. Préparation du serveur membre

À partir du serveur membre, qui s'appelle dans mon cas "SRV-APPLIS", je vais accéder aux sources d'installation située sur mon serveur SRV-ADDS-01.

\\SRV-ADDS-01\c$\Temp\

Ensuite, j'exécute l'assistant d'installation.

Cette fois-ci, je sélectionne le rôle "Specops Arbiter". Il est à noter que l'éditeur recommande d'installer au minimum deux serveurs avec le rôle Arbiter pour assurer la redondance. Que vous installiez un seul ou plusieurs serveurs Arbiter, le coût reste le même.

Cliquez sur le bouton "Install" et suivez l'assistant.

Comme sur l'autre serveur, installez la console en cliquant sur "Administration Tools", puis cliquez directement sur "Install".

Vous pouvez fermer l'assistant d'installation. Sur votre serveur, vous pouvez ouvrir la console "Specops Password Policy Domain Administration" pour commencer à configurer le logiciel.

Accédez à l'onglet "Domain Settings" : le message "The group has not been created, click Create" apparaît. Cliquez sur le bouton "Create" puis sur "OK". Cela va permettre de créer un groupe nommé "Specops Password Policy Custom Expiration Readers" dans l'Active Directory.

Ensuite, accédez à l'onglet "Breached Password Protection" afin d'enregistrer notre serveur Arbiter ("Register new Arbiter") auprès de l'API Breached Password Protection. Ce qui est indispensable pour utiliser cette fonctionnalité (que nous découvrirons par la suite).

Voilà, laissez la console de côté un instant, nous allons préparer le poste client. Ce sera fait et nous aurons plus à nous occuper de la partie installation.

D. Préparation du poste client

Sur les postes clients, il est recommandé de déployer un agent Specops. Pourquoi ? Cet agent est utile lors de la réinitialisation d'un mot de passe depuis le poste client. Il va permettre d'afficher à l'utilisateur les conditions à respecter pour définir son nouveau mot de passe. Sachez malgré tout que l'installation du logiciel sur les postes clients est facultatif (vous verrez par la suite l'intérêt de ce client).

Cet agent est disponible au format MSI, ce qui va permettre de le déployer facilement par GPO ou avec un logiciel de déploiement. Il est disponible en version 32 bits et 64 bits. La bonne nouvelle, c'est qu'il s'installe très facilement, sans configuration particulière.

Pour ma part, j'ai procédé à l'installation du package "Specops.Authentication.Client-x64.msi" sur une machine Windows 11.

Nous verrons dans la suite de ce tutoriel à quoi ressemble l'intégration au sein du poste client.

III. Création de sa première politique de mots de passe renforcée

Il est temps de créer notre première politique de mots de passe renforcée et surtout une politique sur mesure, que l'on va configurer aux petits oignons, comme on dit.

En haut à gauche, cliquez sur "Password policies". Ensuite, le logiciel va lister les politiques de mots de passe actuelles, y compris celle native de l'Active Directory. Pour notre part, nous allons créer une nouvelle politique : cliquez sur "Create new Password Policy".

Note : pour modifier une politique existante et créée avec Specops, il suffit de la sélectionner et de cliquer sur le bouton "Edit Policy".

Ensuite, la liste de vos GPOs s'affiche. Cliquez sur "New Group Policy object" pour créer une nouvelle GPO qui va utiliser l'extension Specops. Pour ma part, je nomme cette GPO "Password_Policy".

Pendant le processus de création de la GPO, il est nécessaire de sélectionner l'OU sur laquelle appliquer la GPO (et donc la politique de mots de passe). Tout en sachant que la politique s'applique sur les utilisateurs. Une alternative consiste à s'appuyer sur un groupe de sécurité pour appliquer les politiques du logiciel Specops, c'est au choix.

Note : la liaison de la GPO liée à Specops sur les OUs peut être effectuée à partir de la console standard de gestion des GPOs.

Ensuite, vous avez plusieurs choix pour créer votre politique :

  • Custom : une politique sur mesure que vous personnalisez entièrement
  • Microsoft recommendation : politique de mots de passe basée sur les recommandations de Microsoft
  • NCSC recommendation : politique de mots de passe basée sur les recommandations du NCSC (National Cyber Security Centre, équivalent de l'ANSSI au Royaume-Uni
  • NIST recommendation : politique de mots de passe basée sur les recommandations du NIST (National Institute of Standards and Technology, États unis)
  • NSA recommendation : politique de mots de passe basée sur les recommandations de la NSA (National Security Agency, Etats-Unis)

Ce serait intéressant que l'ANSSI entre en contact avec Specops (ou l'inverse) pour intégrer les recommandations de l'ANSSI au logiciel. Ce serait une bonne évolution pour aiguiller les entreprises lors de la création d'une politique.

Pour notre part, nous allons choisir "Custom" pour voir les différentes options proposées par ce logiciel. Le fait d'utiliser une politique qui suit les recommandations permet de partir d'une base, mais vous pouvez ajuster la politique malgré tout.

Nous pouvons définir une politique de mots de passe et une politique de passphrase ("phrase secrète"), que l'on peut considérer comme des mots de passe constitués d'une suite de mots et avec une longueur plus importante que les mots de passe standards. Nous pouvons faire choisir les deux, c'est ce que nous allons faire : choisissez "Enable Both".

Commençons par le premier onglet "General Settings". Au sein de cet onglet, nous allons retrouver les paramètres globaux, notamment au sujet de l'historique des mots de passe.

Note : le message "The password policy is incompatible with the built-in domain password policy...." s'affiche si la politique que vous êtes en train de créer "est plus faible" que la politique de mots de passe intégrée à l'Active Directory. Dans ce cas, il faut ajuster la politique existante pour faire disparaître le message.

Pour être plus précis sur la partie historique des mots de passe :

L'option "Disallow incremental passwords" permet de désactiver l'incrémentation des mots de passe. Je m'explique : un utilisateur avec le mot de passe "Bonjour1" ne pourra pas définir "Bonjour2" ni "Bonjour5" comme mot de passe. Quant à l'option "Number of remembered passwords", elle permet d'indiquer le nombre de mots de passe mémorisés et sur lequel se base l'historique de mots de passe de l'utilisateur.

Il est déconseillé d'utiliser les options "Minimum number of changed characters" (Minimum de caractères différents entre l'ancien et le nouveau mot de passe) et "Disallow reusing part of current password" (Désactiver la réutilisation d'une partie du mot de passe actuel), car, bien qu'elle puisse sembler pertinente, elles nécessitent d'activer le chiffrement réversible au sein de l'Active Directory. Pour des raisons évidentes de sécurité, on évitera et on se contentera des comparaisons basées sur les hash.

Ce que j'aime bien au sein de l'interface de SPP, c'est le panneau d'aide sur la droite. En fait, lorsque l'on positionne la souris sur une option, il y a l'aide concernant cette option qui s'affiche sur la droite. C'est très pratique.

Passons à l'étape suivante : "Password Expiration". Elle va permettre de configurer la politique d'expiration des mots de passe et de paramétrer les notifications associées.

  • Password expiration

En configurant la politique, on peut adopter la logique suivante : plus le mot de passe est long, plus l'utilisateur peut le conserver longtemps. Tout cela est ajustable et on crée des "niveaux d'expiration". Une bonne manière de motiver les utilisateurs pour qu'ils définissent un mot de passe plus long car en général ils n'aiment pas changer leur mot de passe. 😉

Dans l'exemple ci-dessous, il y a trois niveaux d'expiration, mais on peut en créer plus que cela. Un utilisateur qui définit un mot de passe compris entre 10 et 14 caractères devra le changer au bout de 30 jours maximum, tandis qu'un utilisateur avec un mot de passe compris entre 15 et 19 caractères devra le changer au bout de 365 jours maximum.

  • Password expiration notifications

Il est possible de notifier l'utilisateur que son mot de passe arrive à expiration. Cette notification s'effectue par e-mail et vous pouvez choisir combien de jours avant l'expiration du mot de passe vous souhaitez notifier l'utilisateur.

Pour les notifications, l'e-mail est entièrement personnalisable et vous pouvez inclure certaines variables. Ces valeurs dynamiques vont permettre d'intégrer le nom d'utilisateur, le nom d'affichage, l'adresse e-mail ou encore l'adresse e-mail du responsable (si c'est renseigné dans l'AD).

Passons à l'étape "Password Rules". Comme son nom l'indique, cette section va permettre de définir les règles pour les mots de passe, notamment la longueur, les types de caractères, etc.

L'option "Number of required character groups" sert à définir le nombre de types de caractères différents requis pour le mot de passe. Par exemple, si vous définissez "3", vous devez sélectionner au minimum trois types de caractères (la sélection s'effectue en dessous) et pour chaque type, vous pouvez indiquer le nombre minimal. Cela permet d'affiner très précisément.

Vous pouvez appliquer des restrictions au niveau du mot de passe : l'option "Disallow consecutive identical characters" égale à "3" empêche l'utilisation de 3 caractères identiques à la suite. Dans le même esprit, si l'on coche "Disallow full user name in password", l'utilisateur ne pourra pas utiliser son nom d'utilisateur dans le mot de passe.

Il est à noter la présence de la section "Use custom dictionaries". En cliquant sur le bouton "Manage", on a la possibilité de créer un nouveau dictionnaire ou d'en importer un existant.

Par exemple, si l'on crée un nouveau dictionnaire soi-même, il faudra saisir les mots à interdire. La chose que l'on peut faire, c'est indiquer le nom de son entreprise pour empêcher que le nom soit utilisé dans les mots de passe. Indispensable selon moi, car c'est très très courant !

En spécifiant "Connect" en référence à "IT-Connect", cela va bloquer "Connect", "CONNECT", mais aussi "connect" et même "C0nnect" (un zéro à la place du "o"). Le logiciel va prendre en charge les variantes pour renforcer l'interdiction.

Si votre entreprise dispose déjà d'un dictionnaire de mots à bloquer, il est possible de l'importer très facilement grâce à l'option "Import Password File".

Chaque dictionnaire est configurable, notamment pour bloquer les caractères de substitution lors de l'utilisation d'un mot du dictionnaire. Cela correspond à l'option "Character substitution (leet speak)".

Poursuivons la configuration sur notre lancée : rendez-vous dans l'onglet "Passphrase". Dans le cas où l'utilisateur souhaite définir un mot de passe très long, on parlera plus de passphrase. Dans ce cas, une stratégie différente peut s'appliquer afin de choisir la longueur, les types de caractères que vous souhaitez, etc.

Le logiciel va très loin puisque l'on peut créer ses propres règles pour les prérequis, en s'appuyant sur des expressions régulières (RegEx).

Par exemple, si l'on veut imposer une passphrase composée de 3 mots de 6 caractères séparés par un espace, on utilisera cette RegEx :

^\S{6,}\s+\S{6,}\s+\S{6,}$

De la même façon, on peut bloquer les mots identiques :

^(?!.*\b(\w+)\s\1\b).*$

Ainsi que l'utilisation de caractères consécutifs identiques :

^(?!.*(.)\1\1).*$

Ensuite, on peut tester ses règles, au fur et à mesure de préférence, via la zone de saisie "Sample Passphrase". Grâce à nos règles, un utilisateur ne pourra pas utiliser "111111 222222 333333" ni "111111 111111 22222" comme passphrase.

Terminons par la configuration de l'onglet "Breached Password Protection". Grâce à cette fonctionnalité (vendue en complément sous le nom de "Breached Password Protection"), le logiciel SPP va comparer les mots de passe définis par les utilisateurs avec les mots de passe contenus dans les fuites de données connues ou collectés par Specops. On parlera de "leaked password", sans oublier les mots de passe collectés par Specops via les serveurs honeypots. Pour effectuer cette comparaison, le logiciel s'appuie sur le hash des mots de passe, car il ne connaît pas le mot de passe des utilisateurs.

Cette section se découpe en deux zones :

  • Express List : l'analyse est effectuée à partir de la base de mots de passe téléchargée en local (environ 5 Go) sur le serveur et qui contient environ 750 millions de mots de passe (mise à jour tous les deux mois).
  • Complete API : l'analyse est effectuée via API sur la base de mots de passe hébergée en ligne et qui contient 2,5 milliards de mots de passe (mise à jour quotidienne). Par exemple, la base intègre les mots de passe présent dans la fuite de données qui a touchée Fortinet récemment.

Dans le cas où un mot de passe est trouvé dans une fuite de données, l'utilisateur sera averti afin qu'il puisse changer son mot de passe. Cette notification sera envoyée par e-mail, ou par SMS (gratuit/inclus). Le texte de la notification sera en français puisque c'est le message configuré dans Specops qui est repris.

Il y a une option qui permet de forcer la réinitialisation du mot de passe s'il est trouvé dans une fuite ("Continuously check for leaked passwords and force users to change them"). C'est intéressant, mais cela peut poser des problèmes de connexion aux utilisateurs en télétravail (notamment à cause du cache local des identifiants).

Comme je le disais, les notifications sont personnalisables au niveau du texte. Pour envoyer la notification par e-mail, le logiciel reprend l'adresse e-mail de l'utilisateur au niveau de l'Active Directory. Idem pour le numéro de téléphone afin d'envoyer le SMS (ce qui nécessite d'avoir un annuaire bien renseigné).

Nous sommes à la fin de l'assistant de création d'une nouvelle stratégie ! Cliquez sur "OK" pour sauvegarder et nous allons tester le bon fonctionnement de notre politique.

Comme vous avez pu le constater, l'interface de ce logiciel de chez Specops est en anglais, mais la bonne nouvelle c'est que les notifications sont en français. Pour la partie configuration en anglais, cela ne devrait pas vous effrayer en tant que sysadmin. 😉

IV. Tester la politique Specops Password Policy

Avant de passer aux tests, je tenais à vous préciser que le contenu de la stratégie SPP est visible également à partir de l'Editeur de gestion des stratégies de groupe. Il suffit de modifier la GPO et d'accéder à l'emplacement suivant : Configuration utilisateur > Stratégies > Paramètres Windows > Specops Password Policy.

Faisons un test. On va réinitialiser le mot de passe de l'utilisateur "Guy Mauve" à partir du contrôleur de domaine. Bien sûr, la politique Specops que j'ai créée précédemment s'applique sur cet utilisateur. Il suffit de faire un clic droit sur le compte puis de cliquer sur "Réinitialiser le mot de passe". On saisit un mot de passe, par exemple "Connect123!".

On obtient alors une erreur, car le mot de passe ne respecte la politique. Si l'on regarde l'observateur d'événements du serveur (Journaux Windows > Application), on peut voir qu'il y a des événements générés par Specops Password Policy.

Cet échec de réinitialisation de mot de passe a créé un événement : "Password AdminReset for user 'GUY.MAUVE' rejected". Ensuite, on sait que notre mot de passe ne respecte pas les prérequis de la politique "Password_Policy" et en regardant le détail, on peut savoir quels sont les prérequis non respectés.

Si je recommence avec un mot de passe qui respecte tous les prérequis, cela va fonctionner bien entendu.

Maintenant, je vais basculer sur mon poste client où j'ai déployé le client Specops Password Policy... Je me connecte avec l'utilisateur "guy.mauve" et je décide de changer le mot de passe de ce compte (CTRL+ALT+SUPPR > Modifier un mot de passe).

Voici l'écran qui s'affiche :

Un panneau latéral indique quels sont les prérequis à respecter que ce soit pour le mot de passe ou la passphrase (phrase secrète). Lorsque l'utilisateur saisit son mot de passe, les prérequis changent d'état dynamiquement pour que l'utilisateur sache d'où vient le problème si le mot de passe n'est pas accepté.

Note : dans le cas où le client Specops Password Policy n'est pas installé sur le poste client, cela va fonctionner malgré tout. Cependant, le panneau latéral avec les indications ne s'affichera pas.

Dans le cas où l'utilisateur définit un mot de passe qui est repéré dans la base des mots de passe compromis, une notification est envoyée et un événement ajouté au journal (Observateur d'événements > Journaux des applications et des services > Specops).

Voici par exemple le SMS que j'ai reçu puisque c'est mon numéro qui est renseigné dans la fiche Active Directory de l'utilisateur "guy.mauve". Je vous rappelle que le message peut être défini en français, il suffit de modifier le texte de la notification au sein de la politique.

Quoi qu'il en soit, cette démonstration dans la peau d'un utilisateur permet de se rendre compte de l'utilité du client Specops Password Policy sur les postes et du système de notifications.

V. Analyse des résultats avec Specops Password Auditor

Après avoir mis en place Specops Password Policy, il est intéressant de relancer une nouvelle analyse avec Specops Password Auditor pour voir l'impact de cette nouvelle configuration. Si vous aviez de nombreux mots de passe vulnérables avant la mise en œuvre de SPP, les choses ont dû évoluer dans le bon sens désormais.

Si vous souhaitez découvrir Specops Password Auditor (logiciel gratuit), je vous invite à regarder ma vidéo à ce sujet.

Un logiciel que vous pouvez télécharger gratuitement via cette page : Télécharger Specops Password Auditor.

L'analyse effectuée par Specops Password Auditor suite à la mise en place de Specops Password Policy doit donner des résultats satisfaisants : pas d'utilisateurs sans mot de passe, pas de mots de passe compromis, etc.

Si l'on regarde la conformité de notre politique "Password_Policy" vis-à-vis des recommandations des différents organismes de sécurité, on peut voir qu'elle s'en sort bien également.

Avant de mettre en œuvre SPP, je vous recommande d'effectuer une analyse avec Specops Password Auditor afin de voir la valeur ajoutée de SPP après quelque temps d'utilisation.

Cette découverte de Specops Password Policy touche à sa fin ! N'hésitez pas à tester le logiciel de votre côté et à poster un commentaire si vous avez des questions.

Je vous laisse avec le lien de téléchargement qui vous permettra d'obtenir une version d'essai de 45 jours tout en sachant que le coût de la licence dépend du nombre d'utilisateurs à protéger avec Specops Password Policy :

Télécharger Specops Password Policy

The post Améliorez la gestion des mots de passe dans l’AD avec Specops Password Policy first appeared on IT-Connect.

Comment créer une campagne de phishing avec Gophish ?

16 septembre 2021 à 11:30

I. Présentation

Dans ce tutoriel, nous allons voir comment utiliser le framework open source Gophish pour créer une campagne de phishing (hameçonnage) dans le but d'évaluer le niveau de vigilance des utilisateurs.

Grâce à Gophish, vous allez pouvoir créer différentes campagnes de phishing et les diffuser auprès de vos utilisateurs, dans le but de les sensibiliser, de les entraîner, afin qu'il soit capable d'adopter les bons réflexes lorsqu'ils se retrouvent face à un e-mail douteux.

Visiter le site officiel de Gophish

Voici les fonctionnalités principales de Gophish :

  • Création d'utilisateurs et de groupes d'utilisateurs (cibles)
  • Création de template pour les e-mails de vos campagnes
  • Création de landing page pour vos campagnes (exemple : un formulaire de connexion)
  • Envoyer des campagnes de phishing avec suivi des e-mails (e-mail envoyé, e-mail ouvert, clic sur le lien, données récoltées via le formulaire) pour chaque utilisateur
  • Reporting sur les campagnes
  • API pour interroger Gophish à distance et récupérer des informations

Voici à quoi ressemble le tableau de bord de Gophish, accessible à partir d'un navigateur :

Tableau de bord de Gophish
Tableau de bord de Gophish

Bien sûr, un tel outil peut être détourné pour créer des campagnes malveillantes, mais ce n'est clairement pas l'objectif de cet article.

De nombreuses attaques informatiques débutent par un e-mail malveillant et un utilisateur piégé ! Je vous encourage à utiliser Gophish (ou un autre outil) pour sensibiliser et entraîner vos utilisateurs ! Rien de mieux que la pratique pour vérifier s'ils ont bien compris la session de formation visant à les sensibiliser.

Remarque : via Office 365 / Microsoft 365, Microsoft propose une fonctionnalité qui permet de réaliser des campagnes de phishing pour sensibiliser vos utilisateurs. Cela nécessite d'utiliser des licences Microsoft 365 E5.

II. Rappel : c'est quoi le phishing ?

Le phishing, ou hameçonnage en français, est une technique utilisée dans le cadre d'attaques informatiques pour inciter l'utilisateur à communiquer des informations personnelles (nom d'utilisateur, mot de passe, numéro de carte bancaire, etc.) à partir d'un e-mail, d'un SMS, etc... Qui va rediriger l'utilisateur sur une page Web malveillante.

Par exemple, le pirate informatique va créer une copie de la page de connexion sur Facebook et il va inclure un lien vers cette copie dans l'e-mail qu'il va envoyer aux utilisateurs ciblés. Si l'utilisateur clique sur le lien, accède à la page et saisit ses informations de connexion, le pirate va récupérer les informations saisies par l'utilisateur. Il peut alors usurper l'identité de l'utilisateur et se connecter à son compte Facebook, mais cela fonctionne pour tout autre compte (Google, impôts, banque, etc.).

Exemple d'un e-mail de phishing

III. Installation de Gophish

L'outil Gophish est disponible gratuitement sur Github et il existe des binaires pour Windows, Linux et macOS. Sinon, vous pouvez aussi le compiler vous-même ou utiliser un container Docker pour le tester rapidement.

Pour ma part, je vais utiliser le binaire pour Windows. On obtient un ZIP qu'il suffit de décompresser. Ensuite, il faut exécuter "gophish.exe".

Note : le serveur qui héberge Gophish doit être accessible par les machines de vos utilisateurs pour que la page Web puisse s'afficher lorsqu'ils vont cliquer sur le lien contenu dans l'e-mail.

Par défaut, Gophish s'appuie sur une base de données SQLite, mais il est possible de configurer un serveur MySQL. Le fichier de configuration se nomme "config.json" et il est situé au même endroit que l'exécutable.

Au premier démarrage, il y a quelques informations intéressantes à relever :

  • Le compte par défaut se nomme "admin" et le mot de passe généré aléatoirement est communiqué dans la console (il faudra le changer à la première connexion)
  • L'interface de Gophish pour afficher les pages web de vos campagnes est accessible sur le port 80/HTTP
  • L'interface d'administration de Gophish est accessible en HTTPS sur le port 3333
Démarrage de Gophish
Démarrage de Gophish

Laissez Gophish tourner et connectez-vous sur l'interface d'administration.

IV. Configuration de Gophish

Pour se connecter depuis la machine locale, il suffit d'accéder à l'adresse "https://127.0.0.1:3333" à partir d'un navigateur. Connectez-vous avec le compte admin et modifiez le mot de passe.

Dans cet exemple, mon objectif est de créer une campagne de phishing en reprenant un e-mail d'Instagram qui renvoie vers une page Web avec un formulaire.

Avant de pouvoir envoyer notre première campagne de phishing, il va falloir préparer un certain nombre d'éléments : c'est ce que nous allons faire, étape par étape. Suivez le guide !

A. Création des utilisateurs et des groupes

Nous devons commencer par créer nos utilisateurs et nos groupes. On peut imaginer qu'un groupe correspond aux utilisateurs d'un service ou d'un site. Lorsqu'une campagne de phishing sera envoyée, il faudra cibler un ou plusieurs groupes.

Cliquez sur "Users & Groups" puis sur "New Group".

Nommez votre groupe en renseignant le champ "Name" et ensuite vous avez deux options :

  • Créez vos utilisateurs un par un, en remplissant le formulaire et en cliquant sur "Add". Cela peut vite être chronophage...
  • Créez vos utilisateurs à l'aide d'un fichier CSV que vous pouvez importer avec le bouton "Bulk Import Users". Cela me plaît un peu plus et de toute façon on ne peut pas établir de connexion avec un annuaire externe.
Importer les utilisateurs dans Gophish
Importer les utilisateurs dans Gophish

On va s'intéresser un peu plus à la deuxième option : l'import CSV. Je ne suis pas trop du genre à faire des saisies en boucle pendant des heures...

D'après le template fourni par Gophish, on doit fournir un fichier CSV avec 4 colonnes et la virgule comme séparateur :

"First Name","Last Name","Email","Position"

Je ne sais pas vous, mais j'ai envie de faire une extraction des comptes de l'Active Directory pour importer les comptes dans Gophish. On va dire que "First Name" correspond à l'attribut "givenName", "Last Name" à l'attribut "sn", "Email" à l'attribut "mail" et "Position" à l'attribut "Title" des objets utilisateurs.

Pour ce premier groupe, je vais récupérer les utilisateurs de l'OU "OU=Personnel,DC=it-connect,DC=local" et exporter le résultat vers un fichier CSV ("C:\UsersGophish.csv").

En PowerShell, cela me donne la commande suivante (et tant qu'à faire avec les bons noms de colonnes souhaités par Gophish). Adaptez le paramètre -SearchBase et éventuellement le chemin de sortie du CSV.

Get-ADUser -Filter * -SearchBase "OU=Personnel,DC=it-connect,DC=local" -Properties mail,givenName,sn,title | Select-Object @{n='First Name';e={$_.givenName}},@{n='Last Name';e={$_.sn}},@{n='Email';e={$_.mail}},@{n='Position';e={$_.Title}} | Export-CSV -Path "C:\UsersGophish.csv" -Delimiter "," -NoTypeInformation

J'obtiens un joli CSV que je n'ai plus qu'à importer.

Exemple d'un CSV formaté pour Gophish
Exemple d'un CSV formaté pour Gophish

Note : vous pouvez aussi jeter un œil au script GoLDAP qui sert à importer les utilisateurs d'un annuaire LDAP vers Gophish.

Les utilisateurs, c'est réglé ! Passons à la suite.

B. Créer l'e-mail pour la campagne de phishing

Seconde étape : la création du modèle d'e-mail que l'on va envoyer aux utilisateurs dans le cadre de cette campagne de phishing.

Cliquez à gauche sur "Email Templates" puis sur le bouton "New Template".

Pour créer le modèle, vous pouvez partir de zéro ou importer le code HTML d'un e-mail existant (ce qui est intéressant pour gagner du temps) grâce au bouton "Import Email". Pour cet exemple, j'ai repris un modèle que j'ai trouvé ici et que j'ai traduit en français.

Dans tous les cas, je vous recommande d'utiliser l'éditeur HTML afin de pouvoir modifier les balises. Lorsque vous cliquez sur le bouton "Source", vous pouvez basculer entre l'affichage du code et la prévisualisation de votre e-mail. Le bouton le plus à droite permet de prévisualiser l'e-mail dans un nouvel onglet.

Pour accéder à tous les boutons de l'éditeur de texte, notamment pour insérer des liens, il faut cliquer sur le bouton "Source". Vous pouvez aussi insérer des balises où la valeur sera dynamique, notamment pour reprendre le prénom ou le nom de l'utilisateur : avec un "Bonjour Florian", vous avez plus de chance de piéger l'utilisateur qu'avec un simple "Bonjour". À vous de juger le niveau de difficulté que vous souhaitez pour ce premier essai. 😉

Les champs personnalisés pour Gophish
Les champs personnalisés pour Gophish

Pour renvoyer vers la landing page qui contient le formulaire, il faut ajouter un lien à l'e-mail. Sur ce lien, il faut indiquer l'URL "{{.URL}}" qui sera remplacée par Gophish par la bonne valeur.

Mon e-mail est prêt, voici un aperçu :

C. Créer la landing page pour récupérer les identifiants

Troisième étape : création de la landing page qui sera une page piégée puisque si l'utilisateur complète le formulaire, nous allons le savoir ! S'il clique sur le lien, nous allons le savoir aussi !

Cliquez sur "Landing Pages" sur la gauche du menu puis sur "New Page".

Donnez un petit nom à votre template et ensuite il faut passer à la construction.

Vous pouvez partir de zéro comme pour l'e-mail ou importer un site à partir d'une URL et du bouton "Import Site". Alors, vous pouvez importer la page d'un site existant, mais il faudra adapter le code source : le formulaire que vous allez récupérer ne sera peut-être pas conforme aux attentes de Gophish (notamment les noms des champs du formulaire). C'est la partie la plus délicate (si vous cherchez à copier Instagram, par exemple), mais si vous reprenez un portail de votre entreprise pour cette campagne, ça devrait aller.

Pour ma part, j'ai créé une page très basique pour cette démo.

Si vous souhaitez récupérer les informations saisies par les utilisateurs, cochez les cases "Capture Submitted Data" et "Capture Passwords" pour le mot de passe (même si vis-à-vis du RGPD, je pense qu'il vaut mieux éviter l'option "Capture Passwords"). Il est précisé que le mot de passe sera stocké en clair, mais finalement on peut se passer de la récupération du mot de passe. Sauf si vous souhaitez engueuler l'utilisateur s'il utilise un mot de passe faible (pour ne pas dire autre chose) en plus de s'être fait piéger.

Création d'une landing page Gophish

Voici le code source de ma superbe page :

<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body>
<form action="" method="post" name="form"><label>Nom d&#39;utilisateur:</label> <input type="text" /><br />
<label>Mot de passe:</label> <input name="password" type="password" /><br />
<input id="login" type="submit" value="Se connecter" />&nbsp;</form>
</body>
</html>

Si vous arrivez à piéger un utilisateur avec ça, je suis inquiet pour vous. Enregistrez... La page est prête !

D. Configurer le serveur SMTP

Avant de lancer la campagne, il nous reste une dernière étape : la configuration du serveur de messagerie (SMTP). Vous vous en doutez, il va servir à envoyer les e-mails de nos campagnes de phishing.

Sur la gauche, cliquez sur "Sending Profiles" puis sur "New Profile".

Ensuite, vous devez nommer votre profil et renseigner les informations en complétant le formulaire.

Gophish et la configuration du SMTP

Voici quelques indications :

  • From : adresse e-mail utilisée pour envoyer les e-mails, c'est-à-dire l'expéditeur. Si vous effectuez une campagne de sensibilisation axée sur Instagram, il peut être intéressant d'utiliser un nom de domaine trompeur et semblable à "@instagram.com". S'il n'a rien à voir, ce sera plus facile pour les utilisateurs de voir qu'il s'agit d'un piège : mais ce sera aussi l'occasion de voir s'ils ont bien compris qu'il fallait vérifier l'e-mail de l'expéditeur (même si ce n'est pas suffisant).
  • Host : serveur SMTP à utiliser pour envoyer les e-mails, suivi du port (séparé par ":")
  • Username : compte utilisateur pour s'authentifier sur le serveur SMTP
  • Password : le mot de passe de ce compte

Pour valider que ça fonctionne, cliquez sur "Send Test Email". Si c'est bon, vous pouvez continuer.

Note : vous pouvez créer plusieurs profils, car en fonction de la campagne, vous n'allez peut-être pas utiliser la même adresse d'expéditeur.

E. Lancer la campagne de phishing

Tout est prêt ! Nous allons pouvoir créer notre première campagne de phishing et tester nos utilisateurs !

Cliquez sur le menu "Campaigns" puis sur "New Campaign".

Pour créer cette campagne nommée "Instagram n°1", on va réutiliser les éléments créés précédemment : "Email Template", "Landing Page" et "Sending Profile".

Concernant, les autres options :

  • URL : indiquez le nom de domaine ou l'adresse IP (là aussi, essayez de faire en sorte de tromper vos utilisateurs pour les évaluer correctement) où les utilisateurs pourront contacter votre serveur Gophish.
  • Launch Date : date à laquelle envoyer la campagne, par défaut c'est immédiatement. Si vous spécifiez aussi une date pour le champ "Send Emails By", Gophish enverra les e-mails à un moment donné entre la date de début ("Launch Date") et la date de fin ("Send Emails By"). Ainsi, tous les utilisateurs ciblés ne vont pas recevoir l'e-mail en même temps.
  • Groups : sélectionnez un ou plusieurs groupes d'utilisateurs que vous souhaitez cibler avec cette campagne.
Créer une campagne dans Gophish
Créer une campagne dans Gophish

Quand tous les champs sont complétés, cliquez sur "Launch Campaign" pour démarrer la campagne ! Le tableau de bord de la campagne va s'afficher et la section "Details" vous indique la "progression" pour chaque utilisateur.

F. Consulter les résultats de la campagne de phishing

En tant qu'utilisateur ciblé par la campagne de phishing, j'ai reçu l'e-mail ci-dessous, avec le fameux "Bonjour Florian". On peut voir que le lien renvoie vers mon serveur Gophish (et l'adresse IP spécifiée dans la campagne).

Je décide de cliquer sur le lien : j'arrive bien sur la landing page. Je suis confiant, je vais me connecter comme indiqué dans l'e-mail....

Dans le même temps, sur l'interface de Gophish, on peut voir qu'il y a un utilisateur qui a ouvert l'e-mail, cliqué sur le lien et envoyé des données.

Note : la section "Email Reported" indique le nombre d'utilisateurs qui ont signalé cet e-mail pour dire qu'il était malveillant. Un utilisateur qui a signalé l'e-mail frauduleux au service informatique doit être récompensé ! 😉 - Pour configurer cette fonction, rendez-vous dans "Account Settings" puis "Reporting Settings" : configurez la boîte e-mail qui sert à vos utilisateurs à remonter les incidents de sécurité au service informatique.

En complément, la "Campaign Timeline" nous donne un aperçu des événements dans le temps, avec le nom d'utilisateur et l'action effectuée. C'est plutôt bien fait !

Au niveau de la section "Details", je peux voir que l'utilisateur "Florian Burnel" a envoyé des données via le formulaire ! Je peux même obtenir le détail des actions avec la date et l'heure, c'est très précis !

En affichant tous les détails, je peux également visualiser le mot de passe envoyé par le formulaire de ma landing page : "JeTeDonneMonMotDePasse". Finalement, je crois qu'il m'a démasqué et qu'il s'en amuse ! 😉

En complément, le bouton "Complete" permet de terminer une campagne et de l'archiver (les résultats restent accessibles). Enfin, vous pouvez exporter un rapport au format CSV en cliquant sur "Export CSV".

Cette démo de Gophish est terminée ! Maintenant, c'est à vous de jouer ! Pensez à former les utilisateurs puis à les tester avec Gophish. Dans la foulée de la campagne, effectuez une seconde session de sensibilisation auprès des utilisateurs qui se font piéger. Sans oublier une piqûre de rappel pour tout le monde, de temps en temps.

The post Comment créer une campagne de phishing avec Gophish ? first appeared on IT-Connect.
❌