J’avais une liste assez longue de serveurs Rsync sous la main et avec Nmap je voulais m’assurer qu’aucun module (~répertoire) n’était accessible « anonymement » (comme lors d’un pentest par exemple).
Mais avec Nmap je ne pouvais uniquement voir les modules ou lancer un bruteforce (test de couples login/mot de passe) mais c’est tout. Je cherchais le moyen d’identifier si on pouvait accéder à ces modules et lire le contenu (lecture seule à minima), à la manière du script NSE smb-enum-shares pour le protocole SMB.
N’ayant pas de solution, j’ai crée ce script Bash qui est capable d’analyser une grande liste de hosts (adresses IP ou noms d’hôtes) en parallèle (réglable) et d’identifier ceux qui utilisent Rsync pour la synchronisation à distance :
Paramètre « p » pour le mode parallèle
Mode séquentiel par défaut
Il permet de parcourir les modules visibles et tente de se connecter sur chacun d’eux de manière anonyme pour identifier ceux qui sont accessibles. Tous les serveurs et modules accessibles sont ensuite enregistrés dans un fichier texte (commande Rsync complète pour validation) :
Un nouvel article sur la plateforme « Hack The Box » que j’affectionne tout particulièrement 🙂
J’ai profité des soldes de Noël dernier pour souscrire à un abonnement « Pro Lab. » et éviter de payer les frais d’installation. Le coût mensuel était 23 euros TTC « uniquement », et seulement deux mois d’abonnement pour compléter le Lab. « Dante« .
Sans prétention, cet article a pour but de guider un peu celles et ceux qui veulent se lancer dans l’aventure ou qui ont déjà commencé. Attention: Il ne s’agit pas d’un guide complet avec chacune des étapes, tous les drapeaux à découvrir, toutes les techniques etc… plutôt quelques conseils, des outils à utiliser, sur ma méthodologie etc…
Choix du Lab. Pro « Dante »
Sur https://app.hackthebox.com/ j’ai pu atteindre modestement le rang « Pro Hacker » avec une soixantaine de machines à mon actif depuis juin 2019. En majorité des VM de niveau « facile » et « intermédiaire »(3/4) sur Linux et Windows + quelques machines difficiles et challenges.
J’avais d’abord pensé à me présenter pour l’examen OSCP pendant un temps. Mais avec sa durée de 24 heures, je ne veux pas me lancer sans une bonne préparation car cela semble assez intense. Et j’aime bien réussir mes examens du premier coup.
Je voulais donc d’abord m’exercer sur un « vrai » Lab. représentatif de ce qui pourrait m’attendre et sans devoir payer trop cher pour cela. Mon but était de le faire en 2 mois à temps perdu, objectif atteint.
En comparant les différents Lab. proposés sur le site et en parcourant les forum, je me suis dit que Dante serait une bonne porte d’entrée. Et surtout un excellent terrain pour pratiquer sans se ruiner et abordable techniquement, je ne me suis pas trompé.
Présentation du Lab.
Dante comporte réellement 13 machines (le pare-feu est hors scope) : 7 VM Linux et 6 VM Windows.
Il est classé comme « intermédiaire » au niveau de la difficulté, j’estime que cela correspond effectivement : connaissance réseautique, diversités des plateformes/systèmes, technologies et outils variées etc…
Jusqu’à quatre tunnels seront nécessaires pour atteindre l’ensemble des machines. Autant vous dire que l’art du « pivot » ou déplacement latéral prend tout son sens ici !
Le Lab. est réinitialisé automatiquement tous les jours vers 07h00 (UTC) du matin.
Un point important : gardez à l’esprit que vous ne serez pas tout seul dans le Lab. Ce qui implique que des « petits malins » peuvent effacer des données ou les modifier (très rare tout de même, une seule fois dans mon cas en deux mois, sur un drapeau). Mais surtout, vous ne serez pas seul à lancer des scans à tout va, ce qui parfois rend instable le Lab. Il faut savoir prendre une pause quand cela n’aboutit pas et se poser les bonnes questions, un tunnel peut être défaillant sur le chemin, ou bien ICMP est bloqué par un pare-feu etc…
Outils utilisés
OS
Au niveau de l’OS j’ai utilisé kali-linux-2023-W03-vmware-amd64 via VMware Workstation 17 Player. Très stable durant toute mon utilisation et déjà bien fourni en termes d’outils. J’ai pu faire 100% du Lab. avec.
Scan / découverte réseau
j’ai utilisé mon propre outil au départ : MassVulScan
Sinon, le classique Nmap fera des merveilles. Pensez à utiliser les scripts pour la recherche de vulnérabilité ou faire de l’énumération d’utilisateurs par exemple :
Une fois l’agent connecté, il faut lister les sessions (session + [ENTER]) depuis Kali, sélectionner celle que l’on veut activer (choisir le numéro ou utiliser les flèches de direction + [ENTER]) et la démarrer (start + [ENTER]). Sans cela, pas de routage possible. Et il sera nécessaire de « switcher » les tunnels pour atteindre les autres réseaux après les premiers pivots (répondre « yes« ).
Comme indiqué lors de la présentation, les connexions ou tunnels ne sont pas toujours stables et parfois ICMP était bloqué. Du coup, j’avais une fenêtre qui était ouverte en permanence vers le host que j’attaquais sur le port concerné, ou vers un agent, avec un check en continue, comme ceci :
Ex. d’un test de port TCP en continue vers un host
Voici le script si cela vous intéresse, je m’en sers d’ailleurs régulièrement, fort utile :
#!/bin/bash
host=$1
port=$2
bold_color="\033[1m"
end_color="\033[0m"
if [ -z $host ] || [ -z $port ]; then
echo -e "${bold_color}Usage: `basename $0` [HOST] [PORT] (only compatible with TCP)${end_color}"
exit 1
fi
while :; do
result=`nc -z -v -w 1 $host $port > /dev/null 2>&1`
if [ $? -gt 0 ]; then
echo -e "`date +'%Y/%m/%d %H:%M:%S'` - port $port is \033[0;31mclosed or down\033[0m for host $host"
sleep 0.5
else
echo -e "`date +'%Y/%m/%d %H:%M:%S'` - port $port is \033[0;32mopen\033[0m for host $host"
sleep 0.5
fi
done
Buffer Overflow (BOF)
L’outil GDB-PEDA était suffisant, par contre j’ai dû l’installer à partir du dépôt GitHub : https://github.com/longld/peda
En effet, je voulais pouvoir travailler confortablement depuis ma VM Kali sans avoir de déconnexions intempestives. Il faut juste arriver à se mettre dans les mêmes conditions que le serveur à attaquer.
Surveillance des processus
Là aussi, un seul outil que je recommande (Linux) : pspy
Sinon, vous avez la base de données exploit-DB et leur outil searchsploit :
searchsploit MS17-010
searchsploit -m 41891
Metasploit
L’incontournable, même si je voulais limiter son utilisation, il m’a été utile plusieurs fois (tester des couples « utilisateurs/mots de passe », obtenir un Shell avec privilèges etc…) : https://www.kali.org/tools/metasploit-framework/
Gardez en tête qu’il est parfois utile de changer de contexte de processus pour aller plus loin.
Dans le cas du Reverse Shell, je vous conseille d’utiliser ce que l’on appelle un « wrapper » associé à Netcat pour plus de confort côté Kali. Par exemple : rlwrap
Deux outils à connaître, de véritables « couteaux suisses« , pour s’attaquer à un serveur Windows : CrackMapExec et Impacket
Que ce soit pour faire de l’énumération (version d’OS un serveur, version SMB, brute-force/password spraying, hashdump etc…) ou tout simplement pour réaliser une attaque (Kerberos, SQL etc…). Tout y est.
Répertoires et fichiers d’un serveur Web
Pour l’énumération ou la recherche de fichiers/répertoires, deux outils suivant ce que l’on cherche : Wfuzz et Feroxbuster
Il n’est pas toujours utilise de chercher à casser des mots de passe avec John ou Hashcat, il a d’autres façons de s’en servir.
Et il est rarement nécessaire de faire du brute-force avec de grosses listes pour trouver un mot de passe, et surtout, ne pas trop forcer (nombre de threads simultanés etc…) au risque de passer à côté.
Pour générer sa propre liste de mots avec CeWL par exemple :
Pour être honnête, je n’ai pu compléter ce Lab. seul qu’à hauteur de 90-95%. Mais les 5-10% restants c’était grâce à la communauté Discord du canal officiel Hack The Box (#prolabs-dante).
PwnKit (CVE-2021-4034)
Une note sur ce CVE : vous verrez cette faille apparaître régulièrement lorsque vous lancerez vos scripts de détection de vulnérabilités. Ne cédez pas à la tentation ! En effet, ce Lab. a été construit en 2020 donc avant sa découverte.
Je vous confirme que cela fonctionne mais testez cette faille une fois le chemin attendu identifié. Même si dans la « vrai vie » un « malotru » ne se gênerait pas et irait au plus efficace, c’est sûr !
Conclusion
Sachez prendre des pauses, je suis parfois resté 2-3 jours bloqués alors que j’avais la réponse sous les yeux. On dit souvent que l’étape d’énumération est l’une des plus importantes, et bien je vous le confirme. Et ne pas aller trop vite, je passais à côté d’un détail qui avait son importance à chaque fois.
Persévérez, faites le maximum avant de céder à la tentation de demander de l’aide. Dans mon cas, je n’ai pas eu le choix pour la partie Buffer Overflow (BOF), c’était une découverte pour moi et je me suis trouvé noyé dans des tas d’articles avant d’avoir les bons.
Pour ce Lab. inutile d’imaginer des attaques complexes. Cela reste un Lab. accessible n’oubliez pas, qui vous permet de tester différents outils, rien d’insurmontable.
Et une dernière chose, n’oubliez pas de tout explorer (codes sources, historique, fichiers cachés etc…), même une fois le serveur compromis durant votre phase d’énumération. Il faut avoir en « tête » une liste type des choses à vérifier systématiquement sur chacune des VM pour ne rien rater.
Voilà, merci pour votre lecture et bon courage ! Et si besoin d’aide, je suis sur Discord ou via ce site.
Pour finir nous devons créer une nouvelle méthode d’authentification. Il faut pour cela se rendre au niveau « Global », à savoir (GUI) :
Global/System/Administrators
Il suffit de créer un nouvel « administrateur » et de remplir à minima les champs suivants en jaune :
Création d’une méthode d’authentification basée sur 2FA
Il est important de bien choisir le type comme indiqué pour permettre à plusieurs administrateurs de se connecter et le groupe local que l’on a créé pour utiliser la double authentification. Et bien-sûr le profil ou rôle adéquate (comme Sheila !).
Timeout (important)
Il reste un dernier changement important à fairepour laisser le temps à l’administrateur de valider ou non la demande de connexionlors de la deuxième authentification (si accès frauduleux ou erreur).
En effet, par défaut, le Fortigate n’attendra que 5 secondes. Ce qui est problématique car cela ne laisse pas assez de temps à l’usager de sortir son smartphone par exemple ou de recevoir l’appel téléphonique pour agir (voir les méthodes DUO offertes dans le dernier article de la série 4/4).
Nous allons donc devoir augmenter ce temps d’attente à 60 secondes, ce qui est largement suffisant.
Il faut pour cela se rendre en ligne de commande dans la configuration globale, comme ici dans la démo, cliquer sur le signe « >_ » :
On augmente le délai d’attente à 60 secondes
Il est maintenant temps de tester la connexion.
Test de connexion
Vous devrez pour cela créer ou utiliser un utilisateur sur votre annuaire d’entreprise et le mettre dans le groupe « distant » correspondant au groupe local du firewall, « ADMIN_DUO » dans notre exemple.
Il suffit ensuite d’utiliser les informations de connexion de ce compte administrateur pour vérifier que l’authentification fonctionne, HTTPS et SSH, par exemple :
Un délai de 60 secondes sera donc accordé pour laisser le temps à administrateur de valider l’authentification à partir de son téléphone ou tablette.
En cas d’échec de connexion, il faudra vérifier les fichiers de logs sur le serveur DUO, notamment le fichier nommé « authevents » qui sera d’une grande aide pour identifier la ou les causes. Rendez-vous sur cet article pour les détails.
Mot de la fin
Cet article est le plus court de la série car l’essentiel a déjà été traité dans le précèdent.
Nous avons donc à ce stade une solution davantage sécurisée pour l’administration des firewall Fortigate et pour les connexions distantes via FortiClient.
Rendez-vous dans le dernier article pour voir comment nous pouvons ajouter ou plutôt « enrôler » un nouvel utilisateur et les différentes méthodes de validation offertes avec DUO.
Cet article est donc la suite logique dans lequel nous verrons comment l’utiliser depuis un firewall Fortigate. C’est l’article le plus long de la série.
Nous étudierons ici le cas suivant via le protocole LDAP(S) :
Accès sécurisés distants VPN SSL (FortiClient), Ex. pour des consultants ou employés d’une compagnie
Je vous détaillerai de petites astuces notamment pour bien gérer la redondance au niveau des Fortigate si vous souhaiter configurer deux serveurs DUO Proxy.
Dans l’article suivant nous verrons comment utiliser ces serveurs pour l’administration du Fortigate lui-même.
Fortigate – Configuration LDAP
Pour authentifier les usagers qui se connecteront aux Firewalls Fortigate depuis FortiClient, nous nous appuieront sur des serveurs LDAP que nous allons configurer.
Si j’utilise le protocole LDAP à la place d’un serveur Radius, c’est que je trouve cela plus lisible et plus souple pour gérer les groupes d’utilisateurs (au sens Active Directory ou AD) et plus logique finalement.
Plus lisible car il suffit de créer des groupes locaux (sur le fortigate) qui font référence à leur pendant côté Active Directory. Comme on le verra plus loin, il suffira d’aller naviguer sur l’AD depuis le Fortigate et de choisir les différents groupes.
Plus souple car il suffira ensuite d’ajouter les futurs usagers au niveau de l’AD dans les bons groupes sans que l’on ait besoin d’intervenir au niveau du Fortigate.
Plus logique car bien souvent lorsque l’on utilise un serveur Radius, il se base lui-même sur l’AD pour autoriser ou non l’accès suivant le(s) groupe(s) au(x)quel(s) l’usager appartient. Donc autant interroger directement l’AD sans passer par un intermédiaire.
La mise en place de la double authentification au niveau des connexions FortiClient (tunnels VPN SSL) nécessite quelques changements au niveau du Fortigate.
Tous les détails dans les sections suivantes mais dans les grandes lignes :
Configurer de nouveaux serveurs LDAP qui seront en fait nos serveurs « Duo Authentication Proxy »
Créer des groupes locaux pointant sur ceux d’Active Directory
Ajouter ces groupes au niveau du paramétrage VPN
Configurer de nouvelles règles de filtrage pour utiliser ces groupes
Réglages finaux des connexions LDAP, notamment le « timeout »
A noter que ce qui suit a été testé et validé sur des Fortigate ayant comme version FortiOS : 6.0.x et 6.2.x
Fortigate – Serveurs LDAP (DUO Proxy)
Serveur principal :
En premier lieu nous utiliserons l’interface graphique (GUI) pour configurer le serveur LDAP primaire qui sera en fait notre nouveau serveur DUO Proxy. Le cas échéant se positionner sur le bon « VDOM » puis se rendre ici : /User & Device/LDAP Servers
Renseigner les champs suivants de cette manière avec ses propres informations :
Name DUOPROXY Server IP/Name DUOPXY01.acme.corp Server Port 389 Common Name Identifier sAMAccountName Distinguished Name DC=acme,DC=corp Username CN=ldap-query-svc,OU=ACME,OU=Service Accounts,DC=acme,DC=corp Password L@ Securite est l affaire de t0us !!
Faire attention de bien saisir le CN de cette façon et d’indiquer le chemin complet pour l’utilisateur.
Un exemple ci-dessous, « Connection status » doit indiqué « Successful » :
La connexion au serveur est un succès
Serveur de secours :
Ensuite, nous pourrions configurer sur le Fortigate un second serveur LDAP (DUO Proxy) de secours de la même manière, cela fonctionnerait. Le problème dans cette configuration c’est que les deux serveurs seraient interrogés en même temps et que l’usager recevrait systématiquement deux demandes de validation pour le 2FA… ce qui ne donne pas une bonne expérience côté utilisateur vous conviendrez.
Aussi, nous allons procéder différent et configurer réellement un serveur de secours au principal mais cela ne peut se faire uniquement qu’en ligne de commande (CLI) avec le paramètre « set secondary-server » :
config user ldap edit « DUOPROXY » set server « DUOPXY01.acme.corp » set secondary-server « DUOPXY02.acme.corp » set source-ip 10.20.30.40 set cnid « sAMAccountName » set dn « DC=acme,DC=corp » set type regular set username « CN=ldap-query-svc,OU=ACME,OU=Service Accounts,DC=acme,DC=corp » set password ENC MTAwMKc0g0TL69uXauUZuYdZgAHh6626…. set password-expiry-warning enable set password-renewal enable next end
Dans cette configuration, si le serveur principal n’est pas joignable (durant une maintenance par exemple), le Fortigate enverra automatiquement les requêtes sur le serveur de secours.
Malheureusement, cette information ne sera jamais visible dans l’interface graphique (GUI), en tous les cas jusqu’à ce jour, il faut donc garder cela en tête.
Il est toujours bon de préciser la source (IPv4) qui se connecte aux serveurs pour une meilleure traçabilité et gestion des flux réseaux (set source-ip).
Et j’active également les messages via FortiClient afin d’avertir l’usager si son mot de passe venait à expirer prochainement et/ou si ce dernier devait le changer (set password-*). Ce qui n’est pas activé par défaut et seulement activable par CLI là aussi.
Fortigate – Groupes locaux
Nous devons maintenant créer des groupes locaux qui pointeront vers ceux de l’annuaire d’entreprise via nos nouveaux serveurs LDAP.
Prenons l’exemple du groupe « VPN_DUO_TEST » qui servira pour nos tests à se connecter à distance avec le FortiClient, il faut se rendre ici (interface GUI), le cas échéant se positionner sur le bon « VDOM » :
/User & Device/User Groups puis « Create New«
Type Firewall Members Ne rien mettre Remote Groups Cliquer sur « Add » et choisir le nouveau « Remote Server »
Exemple ci-dessous :
Début de création du groupe local
Ce n’est pas fini, nous devons maintenant indiquer à quel groupe « distant » (= AD) est relié notre groupe local. Pour cela, il faut faire un double clic sur la ligne en jaune où se trouve le serveur LDAP « DUOPROXY ». Ensuite, dans le champ de recherche on indique le nom du groupe (= CN) que l’on cherche, comme ci-dessous (cela peut-être n’importe quel nom) :
On doit chercher le groupe sur l’annuaire d’entreprise
Faire un clic droit sur la ligne qui nous intéresse, cliquer sur « Add Selected » et enfin terminé par « OK » :
Sélection du groupeLe groupe est sélectionné (une pastille apparaît)On valide la sélection
Notre groupe est bien présent mais sans référence pour le moment (= non utilisé pour l’instant) :
Le groupe est créé
Pour plus de clarté, il est préférable de ne faire corresponde qu’un seul groupe local à un groupe « distant » de l’AD (du 1 pour 1 donc).
Fortigate – VPN
Une fois le groupe créé nous devons créer et lui « affecter » un portail et lui permettre ainsi de se connecter au Fortigate.
Il faut pour cela se rendre dans le menu « VPN« . Si il n’est pas visible il suffit d’activer la fonction dans « System/Feature Visibility » et choisir « SSL-VPN Realms » (uniquement).
Cliquer ensuite sur le menu « SSL-VPN Portals« . Il est préférable de distinguer les connexions suivant leur finalité. Par exemple ici nous avons 4 portails distincts :
Différents portails VPN SSL
L’intérêt de faire cela est d’appliquer des options différentes suivant qui se connecte. Comme ici, nous avons par exemple le portail des « utilisateurs classiques » qui possède son propre range d’adresses IPv4 (pour le filtrage), son propre routage (split tunneling), on interdit d’avoir plusieurs connexions actives avec le même compte, mode « Tunnel » uniquement, etc…
Une fois le portail créé, nous devons l’affecter au groupe précédemment créé. Il faut se rendre dans le menu « SSL-VPN Settings » et créer la relation entre le groupe local et le portail voulu en cliquant sur « Create New » :
On créé et on affecte le portail à notre groupe localOn sélectionne le groupe local et portail
Une fois terminé, vous devriez avoir une page comme celle-ci, il ne reste plus qu’à valider les changements :
Paramètres appliqués à VPN SSL
Vous noterez qu’il est préférable de choisir un port « non standard » pour les accès externes même si cela obligera certains compagnies à ouvrir le flux en sortie. Il faut également prévoir un délai d’inactivité afin de faire tomber la connexion. Enfin, il est conseillé d’utiliser un certificat public valide et reconnu par une autorité certification.
Fortigate – Filtrage
Nous terminons la configuration en ajoutant les règles filtrage afin d’autoriser concrètement la connexion VPN SSL en précisant les flux réseaux permis.
Dans notre cas nous prendrons pour exemple l’accès à un intranet d’entreprise, Sharepoint :
Règles de firewall
Comme vous le voyez il faut également ne pas oublier d’ajouter le flux pour les requêtes DNS car les usagers utiliseront certainement le nom des serveurs.
A noter que l’interface source sera toujours « SSL-VPN tunnel » et qu’en source il faudra toujours préciser le range d’adresses IPv4 + le groupe local créé précédemment. Et le NAT ne doit pas être activé.
Une précision : le choix d’attribution de l’adresse IP est fait au moment de l’affectation du portail pour le groupe (étape précédente). En d’autres termes, ici avec la règle de filtrage, c’est le groupe qui va « orienter » le choix de l’adresse IPv4 qui est attribuée et non le fait de mettre tel ou tel range d’adresse IP (en bleu dans l’exemple).
Fortigate – Timeout (important)
Dans les sections précédentes nous avons vu quelques « astuces » seulement activables par ligne de commande (CLI), comme l’ajout d’un serveur de secours et les notifications lors de l’expiration des mots de passe.
Il reste un dernier changement important à fairepour laisser le temps à l’usager de valider ou non la demande de connexionlors de la deuxième authentification (si accès frauduleux ou erreur).
En effet, par défaut, le Fortigate n’attendra que 5 secondes. Ce qui est problématique car cela ne laisse pas assez de temps à l’usager de sortir son smartphone par exemple ou de recevoir l’appel téléphonique pour agir (voir Méthodes DUO offertes).
Nous allons donc devoir augmenter ce temps d’attente à 60 secondes, ce qui est largement suffisant.
Il faut pour cela se rendre en ligne de commande dans la configuration globale, comme ici dans la démo, cliquer sur le signe « >_ » :
On change la durée d’attente globale
Tout est prêt, nous allons pouvoir passer au FortiClient, le premier cas d’utilisation.
FortiClient – Installation et configuration
Installation
Pour valider le fonctionnement de l’ensemble, il est nécessaire d’installer et de configurer le FortiClient sur son PC/Mac (ou Tablette dans l’App store). Il s’agit d’un client VPN disponible sur de nombreuses plateformes :
Cette version « allégée » est suffisante pour nos tests :
Télécharger la dernière version du FortiClient
L’installation est très intuitive mais il faut les droits d’administration.
Configuration
Il faut créer une nouvelle connexion comme ici en cliquant sur la petite roue crantée en haut à droite dans le menu « REMOTE ACCESS » :
Ajouter une nouvelle connexion
Il peut être nécessaire de déverrouiller l’accès avant en bas à gauche :
Si besoin, déverrouiller l’accès aux paramétrage
Puis saisissez les informations correspondantes à votre environnement :
Paramètres de la nouvelle connexion VPN SSL
Bien se positionner sur le type de VPN « SSL-VPN », cocher la case « Customize port » et mettre le bon numéro de port dans la case correspondante. Et il faudra bien-sur créer une nouvelle entrée DNS publique. Enregistrer le tout.
Si vous voulez vérifier que le certificat est bien valide, il suffit de se rendre à cette l’URL avec votre navigateur depuis l’extérieur de votre entreprise : https://sslvpn.acme.com:12443
Test de connexion
Vous devrez ensuite créer un utilisateur sur votre annuaire d’entreprise et le mettre dans le groupe « distant » que nous avons relié au groupe local du firewall. Dans notre exemple le CN « VPN_DUO_TEST ».
Au niveau de la console FortiClient, sélectionnez votre connexion créée auparavant et saisir les informations de connexions, cliquer sur « Connect » comme ici :
Saisir les informations de connexion AD de l’utilisateur
Ensuite, la connexion va commencer à s’établir puis s’arrêter à 45%, l’usager aura 60 secondes pour répondre :
La connexion complète ne peut se faire qu’avec l’accord de l’usager
Une fois que l’utilisateur valide, la connexion s’établie.
En cas d’échec, il faudra vérifier les fichiers de logs sur serveur, notamment le fichier nommé « authevents » qui sera d’une grande aide pour identifier la ou les causes. Se référer au premier article pour plus de détails, section « Lancement et fichiers de logs ».
Mot de la fin
Nous venons de voir une manière de configurer un Fortigate avec un serveur DUO Authentication Proxy afin d’activer la double authentification pour les connexions VPN SSL avec FortiClient.
Pour connaître les différentes méthodes de validation côté utilisateur avec DUO et son enrôlement, il faut vous rendre au dernier article de la série (4/4) – en cours de rédaction.
Cet article décrit comment déployer une solution d’authentification à deux facteurs (2FA) afin de sécuriser davantage les accès aux ressources informatiques d’une entreprise, depuis l’internet ou le réseau local.
La solution présentée ici est celle de la société Duo Security qui se nomme « DUO Authentication Proxy« . Il s’agit d’une solution « sur site » (on-promises) accessible librement qui s’intègre aussi bien avec un service d’annuaire (Active Directory) via le protocole applicatif LDAP(S) qu’un serveur de stratégie réseau (NPS) déployé en tant que serveur Radius.
L’autre avantage de cette solution est de proposer une version d’essai de 30 jours à la version « Duo Access » qui permet d’avoir un bon aperçu de leur solution. On bascule ensuite automatiquement à la version gratuite appelée « Duo Free » qui permet d’enregistrer jusqu’à 10 utilisateurs, toujours compatible avec l’application « DUO Authentication Proxy « .
Dans cette première partie, nous étudierons que la partie DUO et ce en mode LDAP(S), rapidement suivra d’autres articles dédiés au Fortigate et FortiClient.
Vue d’ensemble
Le serveur » DUO Authentication Proxy » aura pour fonction « d’intercepter » les requêtes de demande d’authentification (LDAP, RADIUS etc…) et de les relayer aux différents serveurs concernés (contrôleurs de domaine, serveur Radius etc…).
Il jouera le rôle de « mandataire » et devra valider les accès lors de la première demande d’authentification « classique » puis effectuera une deuxième demande d’authentification via un second mécanisme différent qui lui est propre.
Pour cette deuxième demande d’authentification, ce serveur « intermédiaire » utilise sa propre infrastructure Cloud à partir de laquelle il communiquera avec l’utilisateur et validera ou non l’accès.
Schéma réseau
Ci-dessous les différentes étapes successives permettant de valider ou non l’accès à l’utilisateur final.
Dans cet exemple, il s’agit d’une demande de connexion distante depuis le client FortiClient de Fortinet pour établir un tunnel (VPN SSL). Le serveur « Duo Authentication Proxy » se situe au cœur de ce schéma réseau et communique directement avec les serveurs internes et le Cloud Duo :
Les différentes étapes pour établir un tunnel avec la double authentification
Première demande d’authentification initiée sur le Firewall Fortinet Fortigate via SSL VPN (FortiClient)
Le firewall transmet cette demande au serveur « Duo Authentication Proxy »
Le serveur « Duo Authentication Proxy » transmet à son tour la requête aux serveurs de l’entreprise (via LDAP/RADIUS)
En cas de succès, le serveur établit une connexion sécurisée avec les serveurs de Duo Security (via HTTPS)
Si l’utilisateur existe, une seconde demande d’authentification est faite auprès de ce dernier
Le serveur reçoit la réponse de l’utilisateur (via PUSH/SMS/PHONE)
Si la demande est bien approuvée, le firewall accorde l’accès à l’utilisateur.
Prérequis et installation
Nous utiliserons deux serveurs sous OS windows pour la redondance, voici la liste des prérequis pour l’installation de l’application :
Deux serveurs virtuels ou physiques avec Windows Server 2016 :
1 CPU, 4 GB de RAM et 40 GB d’espace disque (chacun)
Emplacement du fichier de configuration du serveur Duo
De préférence utiliser un éditeur de texte du type Notepad++ pour éviter les éventuels caractères parasites (retours chariots etc…).
Il faut ouvrir le fichier avec les droits d’administrateur et préciser différentes « sections » dans lesquelles nous allons mettre les paramètres et leur valeur.
Section [main]
La première section que nous devons configurer est la section [main] qui permet, notamment de :
Activer le mode « debug » au besoin (debug),
Inscrire dans un fichier toutes les tentatives d’authentification réussie ou non (log_auth_events),
Définir le nombre maximum de fichiers de logs à conserver par type de fichier (log_max_files),
Définir la taille maximale des fichiers de logs (log_max_size),
L’interface ou les interfaces d’écoute pour les requêtes LDAP/Radius (interface),
Et enfin d’activer ou non les tests de connectivité au (re)démarrage du service (test_connectivity_on_startup).
Voici un exemple ci-dessous que vous pouvez utiliser avec les explications :
[main] # On désactive le debug (par défaut le cas) debug=false # On logs les connexions des usagers log_auth_events=true # On ne conserve que 20 fichiers au maximum log_max_files=20 # Taille maximale des fichiers en octets (bytes) : ici 20 Mo log_max_size=20971520 # Une seule interface en écoute sur le serveur interface=10.20.30.40 # On active le tests de connexion à chaque démarrage du service test_connectivity_on_startup=true
Section à adapter en fonction de vos besoins et de votre plan d’adressage IPv4.
Comme on le voit il est possible de mettre des commentaires. Pour cela, différents caractères/mots peuvent être utilisés en début de ligne : REM, # (dièse) ou encore ; (point-virgule)
Remarque : il faut donc absolument éviter d’utiliser l’un de ces caractères ou mots pour les paramètres exigeant un mot de passe comme nous le verrons plus bas. Si on opte pour utiliser les mots de passe en clair dans le fichier, cela risque de poser problème.
Sections [ad_client] et [ldap_server_auto]
Toujours dans le même fichier de configuration, on continue avec les sections [ad_client] et [ldap_server_auto] qui permettront d’un côté au serveur de se connecter aux contrôleurs de domaine de l’entreprise et d’autre de recevoir les requêtes de type LDAP(S) depuis le Fortigate.
Dans notre cas, ces deux sections, l’une pour le mode « client » et l’autre pour le mode « serveur », serviront notamment pour :
Authentifier les usagers comme les consultants qui se connectent avec l’application FortiClient (tunnel VPN SSL)
Authentifier les administrateurs qui se connectent sur les firewalls Fortigate
Voici un exemple ci-dessous que vous pouvez utiliser avec les explications détaillées plus bas :
[ad_client] # Indiquer les différents contrôleurs de domaine host=DC01.acme.corp host_2=DC02.acme.corp # Compte de service utilisé service_account_username=ldap-query-svc service_account_password_protected=[mot de passe chiffré avec l’utilitaire « authproxy_passwd.exe »] search_dn=DC=acme,DC=corp # On utilise le protocole sécurisé LDAPS (SSL), sinon mettre la valeur « clear » pour LDAP transport=ldaps # On ne vérifie pas le certificat du ou des contrôleurs de domaine ssl_verify_hostname=false
[ldap_server_auto] # Informations de connexion à l’API Cloud Duo Security ikey=[copier/coller la clé au format DIXXXXXXXXXXXXXXXXXX] skey_protected=[clé chiffrée avec l’utilitaire « authproxy_passwd.exe »] api_host=[copier/coller le hostname au format api-XXXXXXXX.duosecurity.com] # On indique le client que l’on utilise pour se connecter aux contrôleurs de domaine, en l’occurrence celui crée plus haut client=ad_client # On laisse passer la connexion si 2FA échoue failmode=safe
Dans la section [ad_client] il est important de préciser plusieurs contrôleurs de domaine pour la redondance et on utilisera de préférence le protocole LDAPS, plus sécurisé. On incrémente pour cela le paramètre « host » : host pour le premier DC, host_2 pour le second, host_3 etc… le même compte de service sera utilisé.
Pour mettre le paramètre « ssl_verify_hostname » à « true » il faudrait mettre les certificats de chacun des contrôleurs de domaine dans le même répertoire que le fichier de configuration (ce qui est bien-sûr une bonne pratique). Ce ne sera pas le cas ici pour nos tests.
Dans la section [ldap_server_auto] trois groupes de données sont importants :
La partie Duo Security Cloud (ikey, skey et api),
Le client qui doit être utilisé (client),
Et enfin le comportement à adopter en cas d’échec de la connexion avec le Cloud de Duo (failmode).
Ici, si la double authentification ne fonctionne pas mais que l’authentification principale ou « classique » fonctionne, on autorise la connexion (mode=safe).
Il est possible de durcir la sécurité en passant au mode « secure », qui cette fois bloquerait la connexion, au risque par contre de perturber ou gêner l’administration en cas d’incident réel.
Par défaut le serveur écoutera sur le port standard TCP 389 et recevra donc les requêtes via le protocole LDAP. On imagine que ce serveur est DMZ et que seul les firewalls Fortigate s’y connecte pour l’instant.
Un point crucial ici est le chiffrement des mots de passe : aucun mot de passe ne devrait être présent en clair dans le fichier de configuration une fois le service en production.
Cela concerne les deux champs « service_account_password_protected » et « skey_protected ». Les informations à protéger sont ici chiffrées.
Il faut pour cela utiliser l’un des utilitaires fourni avec l’application qui se trouve ici :
Il suffit de lancer l’utilitaire en ligne de commande, de taper le mot de passe ou la clé puis de copier/coller le résultat, comme ici en jaune, dans le fichier de configuration :
L’utilitaire « authproxy_passwd.exe » permet de chiffrer les informationssensibles
Fichier complet
Vous trouverez ici un exemple de fichier complet (sans commentaire) à remplir avec vos propres informations :
Ceux qui nous intéressent sont en jaune, le dernier n’est pas utile dans notre cas :
Les 3 fichiers de log utiles au quotidien
connectivity_tool = dans ce fichier de log on peut voir l’état de la connexion du serveur avec le Cloud Duo Security lors d’un démarrage et permet de détecter un éventuel problème avec le fichier de configuration.
Par exemple ici les sections [ad_client] et [ldap_server_auto] sont correctes :
Pas d’erreur au lancement du service
Ici un autre cas où le certificat du contrôleur de domaine est manquant dans la section [ad_client] :
Le certificat du contrôleur de domaine est manquant
authproxy = ce fichier de log est complémentaire au fichier précèdent qui apportera d’autres informations lors du démarrage de l’application et indiquera si les ports sont bien en écoute ou pas. Il permettra également de voir les connexions « clientes » à savoir les Firewalls (LDAP et LDAPS) et équipements réseaux (Radius).
authevents = ce fichier au format JSON contient tous les évènements d’authentification des usagers. Cela permet rapidement de voir pourquoi une tentative de connexion aurait échouée, pour les deux niveaux d’authentification.
Quelques exemples ci-dessous :
Cas où l’usager n’existe pas ou bien que le mot de passe n’a pas été saisiIci l’usager n’est pas connu chez Duo Security et un cas où il a dépassé le délai pour répondre
Important : tout changement dans le fichier de configuration nécessite un redémarrage du service pour que cela soit pris en compte, ici en ligne de commande :
net stop duoauthproxy & net start duoauthproxy
Mise à jour
La procédure de mise à jour de l’application est très simple :
Lancer l’exécutable en tant qu’administrateur et suivre les indications qui s’affichent à l’écran. Les fichiers de configuration et de logs seront préservés.
Enfin, démarrer le service et vérifier les logs (connectivity_tool) : net start duoauthproxy
Remarques sur le « service »
J’ai remarqué que le service « DuoAuthProxy » ne démarrait pas toujours après un reboot suite à une maintenance par exemple.
Pour remédier au problème il m’a fallu modifier le type de démarrage à « Automatic (Delayed Start)« , comme ci-dessous :
On diffère le démarrage du service
De même pour le mode de récupération, où j’attends 5 minutes pour redémarrer le service après un incident :
On redémarre le service après 5 minutes
Mot de la fin
Dans cette première partie nous avons vu comment installer, configurer et interpréter les fichiers de logs du serveur DUO Authentication Proxy.
On pourra ainsi activer la double authentification à des usagers qui se connectent avec Forticlient ou à des administrateurs réseau pour l’administrer.
Dans ce 1er article nous verrons ensemble comment nous authentifier sur un serveur Linux en nous appuyant sur le protocole RADIUS (pour Remote Authentification DIal-in User Service, protocole AAA).
Il s’agit plus d’une découverte du « système » PAM (Pluggable Authentication Modules) car son implémentation peut devenir relativement complexe. Il peut notamment permettre la mise en place de diverses stratégies et mécanismes d’authentification comme LDAP, kerberos, lecteur d’empreinte digital etc… PAM fait également office d’API, de librairie… Ce qui ouvre beaucoup de possibilités aux développeurs et différents langages de programmation.
Si vous utilisez déjà un serveur d’annuaire Microsoft pour authentifier vos utilisateurs en entreprise (Active Directory), l’intérêt sera de pouvoir se baser sur ce dernier pour authentifier de la même manière les linuxiens 😉
Cela permet de faciliter la gestion des utilisateurs (une seule base de données), d’augmenter le niveau de sécurité et d’apporter plus de confort à l’utilisateur final.
Nous nous attarderons un peu sur la partie débogage que je trouve intéressante.
Important: Assurez-vous de garder un shell ouvert durant les opérations, afin de vous assurer de toujours avoir la main et de faire un rollback en cas de soucis
Nous installons la librairie RADIUS en premier lieu :
Nous devons ensuite créer les comptes utilisateurs sur le serveur Linux. Ils doivent strictement correspondre au logon name c.-à-d. au champ « sAMAccountName » dans l’annuaire :
sudo useradd -s /bin/bash -m -G sudo admin
A noter que l’on ne créé pas de mot de passe pour cet utilisateur.
On modifie les propriétés du fichier de configuration de la librairie ainsi que les droits associés. Par sécurité, il ne doit appartenir qu’au compte root en lecture/écriture :
On édite ce fichier de configuration et on ajoute notre serveur RADIUS dans la section adéquate :
sudo vi /etc/pam_radius_auth.conf
# server[:port] shared_secret timeout (s)
#127.0.0.1 secret 1
[adresse IP du serveur RADIUS] :1812 [secret/mot de passe partagé] 60
Suivant la version de votre serveur RADIUS, vous devrez peut-être mettre le port UDP 1645 à la place de UDP 1812. A noter qu’il est préférable d’augmenter le timeout à 60 secondes, notamment si vous utilisez du 2FA. Pour laisser le temps aux usagers de se connecter si leur connexion n’est pas bonne.
Autorisons maintenant l’authentification par le protocole RADIUS en SSH. Nous allons pour cela éditer le fichier suivant et ajouter la ligne qui commence par « auth… » au tout début, juste avant le ligne « @include common-auth » :
sudo vi /etc/pam.d/sshd
# Standard Un*x authentication.
auth sufficient /lib/security/pam_radius_auth.so
@include common-auth
Petite explication sur cette ligne :
auth = permet la vérifier l’identité de l’utilisateur lors de la connexion
sufficient = cela indique que si le test d’authentification réussi (utilisateur existant dans l’annuaire et mot de passe correct), le traitement s’arrête là.
/lib/security/pam_radius_auth.so = chemin vers la librairie utilisée, RADIUS dans notre cas
En effet, ce fichier, et un fichier « PAM » de manière générale, comprend un séquencement d’opérations qui sont traitées successivement sur conditions (échec ou réussite). Cela représente une « pile » de règles en quelque sorte.
A ce stade, un administrateur linux pourra s’authentifier mais il n’aura pas de privilèges. On doit donc éditer le fichier suivant et ajouter la ligne qui commence par « auth… » au tout début, juste avant le ligne « @include common-auth » :
sudo vi /etc/pam.d/sudo
# Standard Un*x authentication.
auth sufficient /lib/security/pam_radius_auth.so
@include common-auth
Et enfin, on doit autoriser l’administrateur à changer de compte utilisateur si besoin. Aussi, on va donc éditer le fichier suivant et cette fois on ajoute la ligne qui commence par « auth… » en fin de fichier, juste avant le ligne « @include common-auth » :
sudo vi /etc/pam.d/sudo
# The standard Unix authentication modules, used with
# NIS (man nsswitch) as well as normal /etc/passwd and
# /etc/shadow entries.
auth sufficient /lib/security/pam_radius_auth.so
@include common-auth
La partie configuration est terminée. Passons à la phase de test !
Tests et débogage
Si tout va bien, vous devriez pouvoir vous connecter en SSH avec votre compte Active Directory et voir apparaître le prompt :
Last login: Wed Feb 7 14:25:01 2018 from mon_pc.mon_domaine.corp
admin@mon_serveur-01:~$
On vérifie que notre compte a bien les privilèges en appelant une commande non accessible pour un utilisateur sans droit :
De la même manière vous devriez être en mesure de passer root et changer d’utilisateur :
admin@mon_serveur-01:~$ sudo su (votre mot de passe)
root@mon_serveur-01:/home/admin#
admin@mon_serveur-01:~$ su root (mot de passe root cette fois)
root@mon_serveur-01:/home/admin#
En cas de soucis, vous avez la possibilité d’activer le mode debug. Pour cela, il faut ajouter le mot clé « debug » comme ici dans le fichier « /etc/pam.d/sshd » (mais applicable dans tout fichier « PAM ») :
Assurez-vous ensuite que votre serveur log correctement les messages en mode « debug » dans un fichier de logs, qui est le mode le plus bavard.
Si ce n’est pas le cas, ajoutez ce fichier dans le répertoire rsyslog, service installé par défaut normalement (remplaçant de syslog, sinon installez-le avec « sudo apt-get install rsyslog« ) :
Cela aura pour effet de rediriger/d’écrire l’ensemble des messages du serveur dans un fichier qui aura comme nom le nom du serveur: mon_serveur-01-debug.log
Pour que le changement soit pris en compte, il faut relancer le service rsyslog :
sudo systemctl restart rsyslog.service
Ou suivant votre gestionnaire de système :
sudo service rsyslog restart
En enfin, affichez les logs à l’écran en temps réel grâce à la commande tail -f et en filtrant les messages :
Ici j’ai rentré un utilisateur qui est inconnu sur le serveur Linux et dans l’Active Directory (j’ai retiré l’horodatage pour une meilleure lecture) :
sshd[31232]: Invalid user le_matou from 192.168.2.200
sshd[31232]: input_userauth_request: invalid user le_matou [preauth]
sshd[31232]: pam_radius_auth: Got user name le_matou
sshd[31232]: pam_radius_auth: Sending RADIUS request code 1
sshd[31232]: pam_radius_auth: Got RADIUS response code 3
sshd[31232]: pam_radius_auth: authentication failed
sshd[31232]: pam_unix(sshd:auth): check pass; user unknown
sshd[31232]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=mon_pc.mon_domaine.corp
sshd[31232]: Failed password for invalid user le_matou from 192.168.2.200 port 21962 ssh2
sshd[31232]: Connection closed by 192.168.2.200 [preauth]
On voit que le système détecte d’emblée que le compte utilisateur n’existe pas sur le serveur puis que le serveur RADIUS rejette l’utilisateur.
Un autre cas où cette fois l’utilisateur existe bien sur le serveur Linux (avec un mot de passe) mais pas dans l’Active Directory :
sshd[26457]: pam_radius_auth: Got user name le_matou
sshd[26457]: pam_radius_auth: Sending RADIUS request code 1
sshd[26457]: pam_radius_auth: Got RADIUS response code 3
sshd[26457]: pam_radius_auth: authentication failed
sshd[26457]: Accepted password for le_matou from 192.168.2.200 port 22070 ssh2
sshd[26457]: pam_unix(sshd:session): session opened for user le_matou by (uid=0)
Cela fonctionne mais grâce à l’authentification locale de PAM dans ce cas. Cela pourrait être utile en cas de défaillance ou d’inaccessibilité du ou des serveurs RADIUS configuré(s). Soit vous avez un compte utilisateur de « secours » (que vous conserveriez soigneusement dans votre KeePass 😉 ), soit vos utilisateurs utilisent un mot de passe « de secours », ce que je ne conseille pas.
Côté serveur RADIUS on verra ce type d’événement lors d’un rejet (ici une log d’un serveur NPS de Microsoft, le client utilise un PC sous Windows 10 donc pas de client NAP) :
User:
Security ID: S-1-0-0
Account Name: le_matou
Account Domain: DOMAINE
Fully Qualified Account Name: DOMAINE\le_matou
Client Machine:
Security ID: S-1-0-0
Account Name: -
Fully Qualified Account Name: -
OS-Version: -
Called Station Identifier: -
Calling Station Identifier: mon_serveur-01.mon_domaine.corp
NAS:
NAS IPv4 Address: 127.0.0.1
NAS IPv6 Address: -
NAS Identifier: sshd
NAS Port-Type: Virtual
NAS Port: 8206
RADIUS Client:
Client Friendly Name: SERVER_IN_10.66.0.0/24
Client IP Address: 10.66.0.200
Authentication Details:
Connection Request Policy Name: Request SERVER_IN_10.66.0.0/24
Network Policy Name: -
Authentication Provider: Windows
Authentication Server: mon_serveur_RADIUS.mon-domaine.corp
Authentication Type: PAP
EAP Type: -
Account Session Identifier: -
Logging Results: Accounting information was written to the local log file.
Reason Code: 16
Reason: Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.
Il existe également un petit utilitaire bien pratique développé par FreeRADIUS (je crois) qui s’appelle « radtest ». Il s’installe de cette manière :
sudo apt-get install freeradius-utils
Il suffit ensuite de taper la commande suivante (pensez à vider votre historique bash ensuite avec « history -c ») :
radtest -x -4 "compte utilisateur AD" "mot de passe AD" [addresse ip/fqdn du serveur radius]:1812 0 "secret partagé (mot de passe)"
Suivant la version de votre serveur RADIUS, vous devrez peut-être mettre le port UDP 1645 à la place de UDP 1812.
Voici une trace lorsque le test fonctionne :
Sending Access-Request of id 93 to mon_serveur_RADIUS.mon-domaine.corp port 1812
User-Name = "admin"
User-Password = "***********"
NAS-IP-Address = 127.0.0.1
NAS-Port = 0
Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host mon_serveur_RADIUS.mon-domaine.corp port 1812, id=93, length=202
Marque-Exec-Privilege = 3
Marque-AVPair = "web-administrative-role=Manager"
Filter-Id = "Marque:version=1:mgmt=su:policy=SYS_ADMIN_AAA"
Login-Service = 50
Service-Type = Administrative-User
Class = 0x89d4084f00006543102000a0a047900000000789764a6f44df9d01d3993c0951af0700000000000353bd
MS-Link-Utilization-Threshold = 50
MS-Link-Drop-Time-Limit = 120
Cela permet notamment de voir les attributs de l’utilisateur.
Important : Une fois le débogage terminé, pensez à commenter (# en début de ligne) les 2 lignes du fichier de configuration rsyslog et relancez le service. Avec le temps, vous risquez d’avoir un TRÈS gros fichier. Sinon, utilisez le service logrotate afin d’archiver et compresser les messages.
Le mot de la fin
Voilà, c’est tout pour cet article. J’espère avoir pu aider ou éclairer quelques personnes 😉
J’ajouterai que par sécurité et redondance, il est préférable d’avoir aux moins 2 serveurs RADIUS configurés. Utile lors des maintenances, ce sera transparent pour les utilisateurs.
Comme indiqué en introduction, il s’agit d’une « simple » introduction. Nous pourrions aller plus loin en gérant le changement de mot de passe, la création automatique des répertoires à la première connexion etc…
