Tag Archives: Fortinet

27 Mai

Fortigate, utiliser FSSO en mode Polling via WMI (1/2)

Introduction

FSSO ?

Fortinet Single Sign-On (FSSO), anciennement connu sous le nom de FortiGate Server Authentication Extension (FSAE), est le protocole d’authentification par lequel les utilisateurs peuvent s’authentifier de manière transparente auprès des appareils FortiGate (notamment).

Pourquoi utiliser ce mode et cette méthode ?

Après, contrairement au mode FSSO « DC Agent mode », le mode FSSO « Polling » évite l’installation d’un agent sur chacun des contrôleurs de domaine. Cela peut être problématique dans certaines organisations.

Ensuite, la récupération des événements de connexion des utilisateurs via WMI apporte d’autres avantages : plus de fiabilité dans la récupération des événements, une charge réseau réduite entre l’agent collecteur et les contrôleurs de domaine et enfin la possibilité d’utiliser un compte de service avec des droits restreints.

Comme on peut le voir sur le schéma ci-dessous, l’agent collecteur interroge directement les contrôleurs de domaine et le Fortigate récupère régulièrement les mises à jour :

Ce premier article sera consacré à l’installation et la configuration de l’agent FSSO sur un serveur Windows. Un second article permettra de voir son utilisation sur un Fortigate.

Permissions WMI sur les DC

Un des pré-requis pour pouvoir utiliser ce mode est d’appliquer certains droits au compte de service ou utilisateur qui sera utilisé par le service « Fortinet Single Sign On Agent Service ».

Pour cela, lancez la console « Windows Management Instrumentation » (WMI) sur chacun de vos contrôleurs de domaine concerné (wmimgmt.msc) :

  • Clic-droit sur « Contrôle WMI » puis « Propriétés »
  • Sélectionnez l’onglet « Sécurité » et étendre « Root »
  • Sélectionnez « CIMV2 » puis cliquez sur le bouton « Sécurité »
  • Ajoutez ensuite l’utilisateur / compte de service qui sera utilisé, ici « fsso_agent »
  • Puis donnez-lui les droits : « Appel à distance autorisé » et « Activer le compte »
  • Dans la même fenêtre, cliquez-sur « Avancé »
  • Sélectionnez l’utilisateur / compte de service dans l’onglet « Autorisations »
  • Cliquez sur « Editer » et appliquez les droits « Cet espace de noms et les sous-espaces de noms »
  • Enregistrez les changements en cliquant sur « OK »

Redémarrez ensuite le service WMI (services.msc) qui porte le nom « Windows Management Instrumentation », clic-droit puis « Redémarrer » :

Ouverture de flux réseaux à prévoir

Une matrice des flux sera faite plus tard, en attendant vous pouvez voir cet article de chez Fortinet :

https://docs.fortinet.com/document/fortigate/6.4.0/ports-and-protocols/879117/fsso-fortinet-single-sign-on

Installation et configuration de l’agent collecteur

Pré-requis pour l’installation et fonctionnement

Rendez-vous sur le site de Fortinet pour télécharger la version la plus récente de l’agent collecteur en fonction de votre version la plus récente du FortiOS installé (OS Fortigate). Par Ex. ici la version correspondante, ici 5.0.0276 (version 64 bits) compatible avec les Fortigate FortiOS 6.0.5 (même démarche pour les versions 6.2.x ou 6.4.x) :

A noter que la version de l’agent collecteur reste (rétro) compatible avec les anciennes versions de FortiOS (5.6, 5.4 etc…). Pensez à vérifier que le fichier téléchargé n’est pas corrompu en comparant les checksum :

Astuce : J’utilise l’extension http://code.kliu.org/hashcheck/ qui est bien pratique au quotidien pour cela. Sinon en PowerShell :

PS C:\Users\username\Downloads> Get-FileHash -Algorithm MD5 .\[filename]

Assurez-vous ensuite que votre serveur collecteur accepte les connexions entrantes sur le port TCP 8000, dans le cas contraire, ajoutez une règle de filtrage sur le firewall local et/ou sur tout autre firewall qui serait entre le Fortigate (source) et l’agent collecteur (destination).

Il vous faudra bien-sûr un serveur Windows, j’ai choisi la version 2016 dans ce cas-ci (ne faites pas attention aux captures d’écran + haut prises sur 2008/2012, c’est le même principe quelle que soit la version de l’OS).

Dernier point, vous devez bien-sûr disposer des droits d’administrateur pour l’installation de l’agent collecteur.

Installation

  • Lancez l’exécutable et cliquez sur « Next »
  • Acceptez les conditions d’utilisation puis cliquez sur « Next » deux fois (on garde le répertoire par défaut « C:\Program Files (x86)\Fortinet\FSAE\ »
  • Saisissez ensuite correctement l’utilisateur / compte de service qui lancera le service, ici « fsso_agent » :
  • Cliquez sur « Next »
  • Cochez les deux options et sélectionnez la méthode « Advanced » :

Contrairement au mode « Standard », ce mode permet d’utiliser directement les comptes utilisateurs AD au niveau des règles de filtrage du Fortigate, pas seulement les groupes donc. Cela apporte plus de souplesse et de finesse.

Il permet en outre d’appliquer une règle de filtrage sur une OU ou un groupe AD contenant des groupes imbriqués, cela ne se limite plus au groupe. Ce qui est impossible dans le mode « Standard ».

Enfin, on aura la possibilité de « pousser » les groupes que l’on souhaite filtrer/utiliser depuis le Fortigate vers l’agent collecteur.

  • Procédez à l’installation en cliquant sur « Install » et patientez
  • Enfin, décochez la case « Launch DC Agent Install Wizard » et cliquez sur « Finish » :

Nous voyons qu’un nouveau service a été créé :

Droits sur le répertoire d’installation

Nous devons maintenant attribuer les droits en lecture / écriture à notre utilisateur / compte de service afin, notamment, qu’il puisse écrire ses fichiers de logs.

  • Ouvrez l’explorateur de fichiers et faites un clic-droit sur le répertoire « C:\Program Files (x86)\Fortinet\FSAE », choisir « Propriétés »
  • Dans l’onglet « Sécurité », cliquez sur « Modifier » puis « Ajouter » afin d’ajouter l’utilisateur / compte de service
  • Attribuez-lui les droits « Contrôle total » en cliquant sur « Autoriser »
  • Puis « Appliquer » et « OK » deux fois :

Redémarrez ensuite le service « Fortinet Single Sign On Agent Service » pour que les changements soient pris en compte :

Une nouveau fichier de log fera son apparition :

Groupes AD et droits dans la base de registre

L’utilisateur / compte de service doit faire partie du groupe AD « Event Log Readers » :

Ensuite, ce dernier doit avoir les pleins droits sur les clés et sous-clés de registre de l’agent collecteur. Pour cela, lancer l’utilitaire « regedit.exe » et modifier celles-ci, choisir le chemin correspondant à votre système :

  • 32bit :[HKEY_LOCAL_MACHINE\SOFTWARE\Fortinet\FSAE\collectoragent]
  • 64bit :[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Fortinet\FSAE\collectoragent]

Vous devez ensuite donnez le contrôle d’accès total à l’utilisateur / compte de service via :

  • Clic-droit sur le répertoire « collectoragent » puis choisir « Autorisations »
  • Ajouter le utilisateur / compte de service via le bouton « Ajouter »
  • Le sélectionner et cocher « Autoriser » devant « Contrôle total »
  • Enregistrez les changements en cliquant sur « OK »
  • Redémarrer le serveur collecteur pour prendre en compte les changements

Configurer l’agent collecteur

Lancez l’agent collecteur « FSAEConfig.exe » et cliquez sur « Run as administrator » pour accéder à toutes les fonctions :

En premier lieu, définissez un nouveau mot de passe qui sera utilisé par le ou les Fortigate. Pour cela, supprimez le contenu du champ « Password », insérer votre mot de passe et cliquez sur « Apply ». Pour chaque changement enregistré, une petite fenêtre s’ouvrira :

Note : en cas de problème lors de vos premiers tests, sachez que le mot de passe par défaut est « fortinetcanada ».

Ensuite, il est préférable d’avoir un fichier log pour les événements (connexions/déconnexions/mises à jours) utilisateurs, c’est plus facile pour le débogage. Pour cela, cliquez sur « Log logon events in separate logs » et cliquez sur « Apply » :

Aussitôt, un nouveau fichier de log sera créé dans le répertoire FSAE contenant toutes les logs :

Il vous suffira ensuite de cliquer sur « View Logon Events » pour ouvrir ce fichier et le visualiser.

Configurer les Event ID à récupérer

Nous devons indiquer à l’agent collecteur tous les Event ID que nous voulons « sonder » car par défaut, il ne prend pas en charge toutes les versions d’OS Windows, il en filtre pas mal.

  • Cliquez sur « Advanced Settings et dans le champ « Event IDs to poll » (section « Windows Security Event Logs ») indiquez cette liste :

672;673;680;528;540;4768;4769;4776;4624;4770

Ainsi, toutes les versions de Windows depuis 2003 jusqu’à 2016 fonctionneront (je n’ai pas testé avec 2019) :

Assurez d’avoir également la case « Use WMI to check user logoff » de cochée dans la section « Workstation Check ». L’agent collecteur interrogera régulièrement les PC afin de vérifier si l’utilisateur est toujours connecté ou non (un batch sera lancé toutes les 5 minutes, comme indiqué sur l’écran principal).

Sélectionner les DC à « monitorer »

  • Cliquez sur « Show Monitored DCs »
  • Puis sur « Select DC to Monitor »
  • Cochez la case « Polling Mode »
  • Puis la case « Check Windows Security Event Logs using WMI » (c’est là que l’on active concrètement le mode WMI)
  • Enfin, sélectionnez les DC que vous souhaitez interroger puis « OK »

Si tout fonctionne correctement, vous devriez de suite pouvoir visualiser et récupérer les premières connexions utilisateurs en cliquant sur « Show Logon Users » :

Dans le cas contraire, vérifiez à nouveau les permissions WMI sur les DC, les droits de l’utilisateur / compte de service et groupe AD.

Configurer les informations d’accès au répertoire

Nous allons configurer le mode « Advanced » pour l’accès au données qui permet plus de choses comme indiqué un peu plus haut lors de la phase d’installation.

A noter que dans ce mode, le nom des groupes sera au format LDAP (cn=group,ou=name,dc=domaine) et non Microsoft (domaine/groupe).

  • Cliquez sur « Set Directory Access Information »
  • Sélectionnez « Advanced » (doit l’être par défaut)
  • Puis cliquez sur « Advanced Setting… »
  • Cochez « Use secure connection (TLS) »
  • Puis renseignez l’un de vos DC en laissant les champs « User name » et « Password » vident puis « OK »

Assurez que les flux sont bien ouverts au passage entre l’agent collecteur et vos contrôleurs de domaine sur le port TCP 3269.

Configurer le(s) domaine(s) à sonder

Sélectionner maintenant le ou les domaines que vous voulez « monitorer ».

  • Cliquez sur « Select Domains To Monitor »
  • Puis cochez les domaines à sonder
  • Pour chacun des domaines, cliquez sur « Setting… »
  • Cochez « Use secure connection (TLS) »
  • Là renseignez à nouveau l’un de vos DC en laissant les champs « User name » et « Password » vident puis « OK » et « OK »

Là aussi, assurez que les flux sont bien ouverts au passage entre l’agent collecteur et vos contrôleurs de domaine sur le port TCP 636

Filtrage des groupes

Nous avons deux possibilités pour la configuration des groupes FSSO (basés sur ceux de l’AD) :

  • Soit depuis ce serveur directement pour les pousser ensuite vers le Fortigate
  • Soit les créer directement sur le Fortigate pour qu’ils soient visibles sur le serveur

J’utilise la seconde méthode, que nous verrons dans le prochain article.

Une fois les groupes configurés vous verrez ce message sur le serveur dans « Set Group Filters » :

Compte(s) utilisateur/de service à ignorer

Une dernière option permet d’exclure une liste de comptes à ne pas surveiller, comme par exemple notre compte de service « fsso_agent ».

Il suffit de cliquer sur « Set Ignore User List » puis d’ajouter les comptes, comme ici avec notre compte de service :

Une fois terminé, ne pas oublier d’appliquer les changements (Apply) et/ou de sauvegarder (Save&close).

Conclusion

Nous avons vu dans cette première partie comment configurer notre serveur avec notre agent FSSO afin de récupérer les activités des utilisateurs (logon/logoff) sur notre DC de manière fiable.

Dans un prochain article nous verrons comment configurer notre Fortigate :

  • Pour se connecter à ce serveur afin de récupérer ses données
  • La création des groupes FSSO (et/ou utilisateurs)
  • L’utilisation de ces groupes dans nos règles de filtrage
  • Et quelques commandes et astuces pour le débogage
07 Jan

Calculer la bande passante consommée des interfaces réseaux d’un Fortigate

Introduction

Je cherchais le moyen d’obtenir à intervalles réguliers la bande passante consommée (en entrée et sortie) de chacune de mes interfaces réseaux, notamment celles « virtuelles », à savoir des VPN (IPSec), sur mes firewalls.

Pour une architecture réseau en étoile (Hub and spoke en anglais) le plus simple est bien-sûr d’interroger l’équipement central qui s’interconnecte avec chacun des sites distants. Ce qui était mon cas.

L’objectif étant au final d’obtenir un fichier source avec toutes les valeurs me permettant ainsi d’alimenter un script pour ensuite générer une carte d’utilisation de bande passante (network weathermap en anglais) rafraîchie toutes les 5 secondes. Comme ci-dessous :

Script Bash

Explications

Vous trouverez plus bas le script Bash que j’ai utilisé pour récupérer les données via SNMP et les traiter. Comme les compteurs des interfaces réseaux s’incrémentent sans cesse, l’idée est de prendre les valeurs à l’instant T puis de les reprendre à l’instant T + 5 secondes.

Puis par un simple calcul on obtient la bande passante consommée en entrée et sortie. Enfin, en appelant régulièrement le script (crontab ou boucle), vous obtiendrez différentes valeurs qui pourraient alimenter d’autres scripts comme PHP Weathermap par exemple, que j’utilise.

Pensez à mettre les bons paramètres (variables) avant de lancer le script :

  • host = hostname/IPv4 de votre firewall
  • community = nom de la communauté SNMPv2

Bien-sûr, au préalable vous devez configurer SNMPv2 sur votre firewall (https://kb.fortinet.com/kb/documentLink.do?externalID=FD45755) et donner les droits en lecture (uniquement) au serveur qui l’interrogera.

J’utilise SNMPv2 dans mon cas car les données récupérées ne sont pas sensibles et il suffit de bien configurer les droits.

J’utilise la MIB standard (ISO/CCITT) pour interroger le firewall, ce qui est le cas avec beaucoup de fournisseurs/marques avec laquelle ils sont compatibles.

Par contre, il était important de prendre les compteurs 64 bits (ifHCInOctets/ifHCOutOctets) et non 32 bits (ifInOctets/ifOutOctets), au risque de voir le compteur repartir à zéro rapidement, surtout si vous avez de gros liens/débits.

En sortie vous aurez ce type d’affichage :

VPN-XXX-C-WS-3G 0 2
VPN-XXX-E-WS-3G 0 2
VPN-XXX-C-ES-OR 1637 1360
VPN-XXX-E-ES-OR 1391 370
VPN-XXX-C-ES-O3 0 6
VPN-XXX-E-ES-O3 0 2
VPN-XXX-C-OU-OR 2047 480
VPN-XXX-E-OU-OR 408 3164
VPN-XXX-C-OU-O3 14 434

Pour finir, vous aurez juste à retirer le nom de fichier « bandwidth.txt » de la ligne 62 pour le générer et le conserver sur disque pour l’intégrer avec un autre script si besoin.

Code source

Voici le script en question, suffisamment commenté je pense :

Sinon, vous pouvez le télécharger ci-dessous :

traffic.sh Bash script (zip)

Conclusion

Voilà, j’espère que ce sera utile à certains d’entre vous. A noter que ce script Bash devrait pouvoir fonctionner tel quel avec d’autres équipements que les Fortigate.

Pour d’autres types de réseaux ou besoins, on pourrait très bien imaginer avoir une liste de firewall en entrée qui serait parcouru et ainsi chacun serait interrogé avec ce script en parallèle pour gagner du temps. Je ferai un article là dessus aussi je pense.

Dernière chose, pour ceux qui s’interrogent sur la mise en forme du code dans l’article, j’ai utilisé l’excellent site : https://carbon.now.sh/

17 Août

Double authentification (2FA) avec un Fortigate via LDAP(S) : DUO côté usager (4/4)

Suite et fin

Je voulais finalement terminer cette série d’articles en évoquant la phase d’enrôlement avec les différentes méthodes et quelques petites astuces.

Commençons succinctement par le côté « administrateur » de DUO puis nous enchaînerons sur les étapes d’enrôlement.

Administration DUO

Envoyer l’email pour l’enregistrement

Une fois le nouvel usager crée chez DUO, l’administrateur va devoir envoyer un courriel à ce dernier (prérequis) afin qu’il puisse enregistrer son équipement « 2FA ». Il suffit de cliquer sur le lien en haut à droite « Send Enrollment Email » :

A noter que l’unique expéditeur de ces emails est : no-reply@duosecurity.com

Le destinatairedevra éventuellement s’assurer que rien n’est dans ces emails indésirables.

Exemple d’email que va recevoir la personne avec un lien (flouté ici) :

Les groupes

Je vous invite à utiliser les groupes également, surtout si vous avez ou comptez l’utiliser pour un grand nombres d’utilisateurs de votre compagnie ou consultants externes.

En effet, cela vous permettra d’identifier rapidement les usagers d’une même entreprise voire d’une même équipe. Et surtout, vous serez en mesure de désactiver l’accès d’un coup à un groupe d’usagers en cas d’incident de sécurité par exemple, sans bloquer tout le monde.

L’enrôlement

Application DUO

L’usager sera guidé durant ce processus. une fois qu’il aura cliqué sur le lien contenu dans le courriel, voici les différentes étapes :

Début de la configuration

Choisir « Mobile phone » si on veut utiliser l’application DUO et recevoir des notifications « push » :

Choix de l’équipement

A noter que niveau expérience utilisateur, l’utilisation d’une application (DUO App.) est préférable. L’application DUO supporte Android 7.0 et supérieur, iOS 11.0 et supérieur, BlackBerry 10, et enfin BBOS 4.5.0 et supérieur.

L’usager doit rentrer un numéro valide

Ensuite l’usager doit choisir le modèle d’appareil pour installer l’application :

Choix du modèle de smartphone

L’utilisateur devra aller chercher l’application dans le magasin de son appareil et l’installer. Une fois cela fait, il devra le confirmer :

Confirmer que l’application est installée

Pour finaliser l’enrôlement de son appareil, il devra scanner le QR code depuis son application (+) :

Scanner le QR code depuis l’application DUO

En dernier lieu il devra confirmer la méthode de son choix pour valider le second facteur :

Méthode de validation du second facteur

Et c’est fini :

Fin du processus d’enrôlement

Sans l’application DUO

Si utilisateur n’est pas en mesure d’utiliser un téléphone intelligent ni même de recevoir des SMS, il pourra toujours choisir l’option autre afin de valider le second facteur par un appel téléphonique :

Option pour recevoir des appels

Choisir l’option d’appel :

Appel cet appareil

Lorsqu’il recevra les appels, il aura juste à appuyer sur n’importe quel touche du clavier pour valider le second facteur.

Téléphone (fixe / de bureau) avec extension

L’administrateur a également la possibilité d’enregistrer un numéro de téléphone qui comporte une extension pour le compte d’un utilisateur (ou il peut le faire lui-même lors de la phase d’enrôlement).

Voici un exemple ci-dessous, sur la fiche de l’utilisateur il faut ajouter un téléphone puis afficher le champ extension :

Afficher le champ « extension »

On rentre les informations et on ajoute le téléphone :

Ajouter le téléphone

Il est important ensuite d’augmenter le délai d’attente lorsque l’extension est composé (sur « 0 » par défaut). Sinon, l’utilisateur risque de ne pas recevoir l’appel et/ou n’aura pas le temps de valider. Et veiller à bien choisir le type « Landline » (par défaut) :

Enregistrer un téléphone qui comporte une extension

Donc si c’est l’utilisateur qui rentre lui-même sa ligne fixe et son extension, l’administrateur devra allonger ce délai d’attente pour lui, non visible lors de la phase d’enrôlement.

Autres possibilités de validation du 2FA

Une fois que l’utilisateur a enrôlé son appareil et choisi son mode de validation, ce dernier aura la possibilité d’en utiliser d’autres dans le champ « Mot de passe / Password ».

Par exemple, il pourra demander à être appelé au lieu de recevoir une notification « push » si cette dernière ne fonctionne plus. Il suffit pour cela d’ajouter le mot « ,phone » après le mot de passe, comme ceci :

Choisir un autre mode de validation

De la même manière, il pourra demander à recevoir une notification « push », en ajoutant cette fois le mot « ,push » après le mot de passe :

Recevoir une notification

Conclusion

Voilà, c’est terminé, j’espère avoir pu éclairer certaines personnes sur le sujet. Pour ma part, globalement, DUO est plutôt pratique, que ce soit côté administrateur ou utilisateur.

La mise en place du serveur Proxy DUO n’était pas trop compliqué et c’est fiable au quotidien. La maintenance n’est pas difficile, par contre, toujours s’assurer d’avoir deux serveurs en redondance.

N’hésitez pas à posez vos questions en commentaires si besoin, je me ferai un plaisir de vous répondre.

02 Fév

Double authentification (2FA) avec un Fortigate via LDAP(S) : Fortigate, administration (3/4)

Objectif et contexte

Nous avons vu dans un premier article comment installer et configurer l’application « DUO Authentication Proxy » de DUO Security.

Puis dans un deuxième comment utiliser cette solution avec FortiClient pour les connexions VPN SSL.

Nous étudierons ici le cas suivant, toujours via le protocole LDAP(S) :

  • Administration d’un firewall Fortigate, Ex. pour des administrateurs réseau

Dans un prochain et dernier article nous verrons les différentes méthodes de validation pour l’usager et son enrôlement.

Configuration LDAP

Pour authentifier les administrateurs qui se connectent aux Firewalls Fortigate, nous nous appuieront sur des serveurs LDAP que nous avons préalablement configurés dans cet article.

Je ne détaillerai donc pas cette partie ici, il n’y a rien de plus à configurer.

Groupes locaux

Nous devons maintenant créer des groupes locaux qui pointeront vers ceux de l’annuaire d’entreprise via nos nouveaux serveurs LDAP.

Là aussi, je vous invite à lire cet article pour connaître tous les détails. Il n’y a rien de plus à ajouter si ce n’est qu’il faudra définir un groupe local avec un nom plus explicite et adapté pour l’administration (Par Ex. ADMIN DUO).

Méthode d’authentification

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 à faire pour laisser le temps à l’administrateur de valider ou non la demande de connexion lors 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 :

  • https://firewall01.acme.corp/
  • ssh compte_administrateur_AD@ firewall01 .acme.corp

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.

02 Fév

Double authentification (2FA) avec un Fortigate via LDAP(S) : FortiClient (2/4)

Objectif et contexte

Nous avons vu dans un premier article comment installer et configurer l’application « DUO Authentication Proxy » de DUO Security.

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 groupe
Le 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 local
On 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 à faire pour laisser le temps à l’usager de valider ou non la demande de connexion lors 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 :

https://forticlient.com/downloads

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.

Nous verrons dans l’article suivant comment utiliser la même méthode pour l’administration des Fortigate.

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.

02 Fév

Double authentification (2FA) avec un Fortigate via LDAP(S) : DUO Authentication Proxy (1/4)

Objectif et contexte

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
  1. Première demande d’authentification initiée sur le Firewall Fortinet Fortigate via SSL VPN (FortiClient)
  2. Le firewall transmet cette demande au serveur « Duo Authentication Proxy »
  3. Le serveur « Duo Authentication Proxy » transmet à son tour la requête aux serveurs de l’entreprise (via LDAP/RADIUS)
  4. En cas de succès, le serveur établit une connexion sécurisée avec les serveurs de Duo Security (via HTTPS)
  5. Si l’utilisateur existe, une seconde demande d’authentification est faite auprès de ce dernier
  6. Le serveur reçoit la réponse de l’utilisateur (via PUSH/SMS/PHONE)
  7. 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)
  • Créer un compte sur le site de Duo Security : https://signup.duo.com/
  • Générer et récupérer les informations de connexion sur le Cloud Duo Security (API) : https://admin.duosecurity.com
    • Il faut créer une API via le menu « Application« 
    • Cliquer sur le bouton bleu en haut à droite « Protect an Application« 
    • Chercher l’application « Fortinet » et cliquer sur le lien « Protect this application« 
    • Cliquer sur l’application « Fortinet FortiGate SSL VPN« 
    • Copier/coller les trois valeurs « Integration key« , « Secret key » et « API hostname« 
  • Télécharger la dernière version de l’application ( ~12 Mo ) : https://dl.duosecurity.com/duoauthproxy-latest.exe
  • Vérifier l’intégrité du fichier téléchargé (SHA-256) : https://duo.com/docs/checksums#duo-authentication-proxy
  • Ouvrir les flux réseaux en sortie (HTTPS 443) : https://help.duo.com/s/article/1337?language=en_US
  • Ouvrir les flux réseaux sur le réseau interne :
    • Depuis le serveur Duo vers le ou les contrôleurs de domaine : ports TCP 389 (LDAP) et 636 (LDAPS)
    • Depuis le firewall Fortigate vers le serveur Duo : ports TCP 389 (LDAP) et 636 (LDAPS)
  • Un compte de service dédié en lecture (seulement) pour pouvoir interroger l’Active Directory

Petite astuce pour vérifier le checksum d’un fichier avec PowerShell :

PS C:\Users\[username]\Downloads> Get-FileHash .\duoauthproxy-3.2.1.exe -Algorithm SHA256 | Format-List

Utiliser PowerShell pour vérifier le checksum d’un fichier

L’Installation est ensuite très intuitive, il faut utiliser un compte avec des droits d’administrateur et lancer l’exécutable.

Si besoin : https://duo.com/docs/authproxy-reference#installation

Fichier de configuration

A ce stade l’application ou plutôt le service n’est pas encore démarré, il faudra d’abord remplir le fichier de configuration qui se trouve ici :

C:\Program Files (x86)\Duo Security Authentication Proxy\conf\authproxy.cfg

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 :

C:\Program Files (x86)\Duo Security Authentication Proxy\bin\authproxy_passwd.exe

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 informations sensibles

Fichier complet

Vous trouverez ici un exemple de fichier complet (sans commentaire) à remplir avec vos propres informations :

Fichier authproxy.cfg

Lancement et fichiers de logs

Le démarrage du service peut se faire directement dans les services ou bien en ligne de commande (administrateur) :

net start duoauthproxy

Lancement du service en ligne de commande

Le nouveau service Windows sera lancé, qui par défaut, est exécuté avec le compte système local :

Le service est démarré

Lors du démarrage, quatre fichiers de logs seront automatiquement créés dans le répertoire « log » :

C:\Program Files (x86)\Duo Security Authentication Proxy\log

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é saisi
Ici 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 :

  1. Télécharger la dernière version de l’application : https://dl.duosecurity.com/duoauthproxy-latest.exe
  2. 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.
  3. 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.

Nous allons voir dans un prochain article comment utiliser ce nouveau type de serveur à partir d’un firewall Fortigate du constructeur Fortinet.

On pourra ainsi activer la double authentification à des usagers qui se connectent avec Forticlient ou à des administrateurs réseau pour l’administrer.

16 Jan

Notes sur la technologie SD-WAN de Fortinet

Introduction

Je viens de passer plusieurs jours à tester la technologie SD-WAN de Fortinet sur des Fortigate (90D et 101E, FortiOS 6.0.3) à travers différents LAB/scénarii. Je dois dire que je suis assez bluffé dans l’ensemble.

Une fois que l’on comprend la logique/philosophie, on se retrouve finalement avec moins de règles de filtrage à gérer et qu’une seule route par défaut quasiment. Il devient alors possible de s’affranchir d’utiliser un protocole de routage dynamique type OSPF, de réduire le temps de bascule en cas de défaillance d’un lien et de gérer finement les flux applicatifs.

J’ai tout de même rencontré quelques soucis lors de la mise en oeuvre que je voulais partager avec vous dans ce billet…

Les stratégies SLA et leur application avec SD-WAN

L’une des forces de cette dernière version du FortiOS 6.0 est la gestion intelligente des liens en s’appuyant sur des SLA que l’on peut combiner : RTT, Jitter et nombre de paquets perdus etc…

On peut également choisir, voire définir, la stratégie à appliquer sur notre flux :

« Best Quality » sera plutôt utilisée pour les services de type VoIP, Fortigate utilisera toujours le lien avec les meilleurs exigences en matière de SLA, quel que soit le coût de la liaison. On recherche les meilleures performances pour les applications critiques.

On peut ainsi définir le critère de qualité principal à retenir voire de créer un profile spécifique avec nos critères :

On peut également privilégier un lien pour l’upload et/ou le download.

« Minimum Quality (SLA) » servira pour le reste du trafic, où l’on considérera aussi bien le SLA que le coût du lien. A noter qu’ici l’ordre de priorité des interfaces à son importance, si toutes les interfaces répondent aux critères de SLA, Fortigate utilisera le premier lien, même si ce n’est pas le meilleur.

Un exemple ici avec 2 liens VPN IPSec : J’ai simulé un lien dit « public » qui passe par Internet avec un RTT moyen de ~20ms et un second lien dit « privé » avec un RTT inférieur à <1ms

Dans ma stratégie j’ai volontairement choisi le lien avec le moins bon RTT en premier :

A noter qu’il faut (souvent) se méfier de l’affichage via le GUI, il pourrait ne pas être représentatif de ce que l’on veut. Il est préférable de vérifier le résultat via CLI :

Ensuite, un simple ping vers la Loopback du Fortigate distant nous confirme le lien utilisé :

Mon LAB de test

Parmi les différents tests réalisés, j’ai retenu ce LAB. C’est le cas le plus simple où on a 2 sites reliés ensemble par 2 liaisons :

Chaque site possède son propre accès Internet. Ces sites sont reliés entre aux par 2 VPN IPSec :

  • Un VPN établi via les liens « publics » ISP 1 et ISP 2 d’une latence de ~20ms
  • Un VPN établi via les liens « privés » 172.[1-2].10.0/30 d’une latence de ~1ms

La configuration des Fortigate est symétrique au niveau des règles de firewall et SLA de telle sorte que chacun des sites puisse joindre le second et accéder à Internet:

  • 3 interfaces (VPN x2 + Interface WAN) dans le SD-WAN, avec comme route par défaut, la liaison SD-WAN justement
  • 2 règles SLA pour gérer la performance :
    • L’une vers Internet avec comme serveur cible le DNS Google 8.8.8.8 comprenant les 2 interfaces WAN (pas très utile car nous avons qu’un seul lien Internet mais c’est pour la forme)
    • Et la seconde vers la loopback du site distant, comprenant les 2 VPN IPSec
  • 2 règles SD-WAN de type « Minimum Quality » :
    • L’une pour l’accès Internet, comprenant nos interfaces WAN, utilisant notre première règle SLA
    • La seconde pour atteindre le PC distant, comprenant nos VPN, utilisant notre seconde règle SLA

Pour la seconde règle SD-WAN j’ai volontairement mis en premier le lien public avec une latence 25ms car je voulais observer le comportement des Fortigate lors du basculement des liens. Il suffisait de « secouer » le lien Internet pendant quelques secondes pour forcer la bascule sur le lien privé, j’utilisais pour cela le site de Netflix qui mesure la bande passante : https://fast.com/fr/

Pour permettre l’établissement du VPN sur le lien privé, j’ai du ajouter une route statique de part et d’autre afin de pouvoir atteindre chacun des subnets. Par exemple sur le site 1 :

La route par défaut de chacun des laptop est le Fortigate auquel il est relié.

Dernier détail qui aura son importance dans le point suivant, je n’utilise que le VDOM « root ».

Problèmes rencontrés et solutions

Déconnexion SSH et timeout HTTP(S)

Durant mes tests je perdais régulièrement la connexion vers le Fortigate distant. Par exemple, depuis le laptop 172.16.10.100 je me connectais sur la loopback du Fortigate du site 1 (10.66.255.1) et je perdais la connexion d’un coup. De même que la connexion HTTPS sur le Fortigate figeait puis revenait. J’ai ensuite essayé sur l’interface d’interconnexion du Fortigate (172.1.10.1), même chose, ainsi que sur l’interface publique.

Par contre, je ne perdais pas les connexions entre les 2 laptops. J’étais par exemple connecté via Remote Desktop (RDP) sur le laptop du site 1 (192.168.1.100), toujours depuis l’autre laptop et je ne constatais aucune déconnexion ou timeout…

Je me suis en fait aperçu, qu’à chaque fois que l’un des Fortigate changeait la route pour atteindre le site distant, je perdais la connexion… j’ai fait le parallèle en lançant un ping en continue entre les 2 laptop, comme ici où l’on passe du lien public au lien privé :

N’ayant pas de solution à ce problème dans l’immédiat, j’ai contacté le support Fortinet. Le support m’indique qu’il s’agit tout simplement d’une sécurité, car une session établie par une interface (Ex. liaison « publique »), ne peut ensuite se retrouver sur une autre (Ex. liaison « privée »)…Et ce problème ne concerne que les connexions faites sur le Fortigate, cela ne concerne pas les autres flux qui le traversent.

Ok mais cela ne m’arrange pas ça ! En effet, j’administre des Fortigate un peu partout dans le monde, notamment en Afrique où nous utilisons différentes liaisons satellites qui sont sensibles au mauvais temps et dont les performances sont aléatoires (latence, jitter…). Je ne me vois pas en production avec ce genre de comportement…Et surtout ce phénomène se produit systématiquement dès que l’on modifie quelque chose au niveau des fonctionnalités SD-WAN…

Et bien-sur le support n’a pas de solution à cela ! Enfin si, il me propose :

  1. Demander à mon commercial de faire une demande de développement d’une fonction par Fortinet pour gérer ce cas
    1. Mais bien-sur…et la marmotte…
  2. De permettre le routage asymétrique (désactiver la fonction « asymmetric check routing »)
    1. super pour la sécurité, les règles de firewall ainsi que les fonctions UTM ne sont plus utilisées…on se retrouve juste avec un simple routeur

J’ai finalement trouvé une solution : mettre les interfaces SD-WAN dans un VDOM à part (Ex. SD-WAN) et laisser l’interface loopback dans le VDOM « root »

C’est tout bête, il suffit ensuite de créer un VDOM Link et d’ajouter une route statique, comme ici sur le Fortigate du site 1 :

VDOM « SD-WAN » :

VDOM « root » :

Pour finir, on crée les règles de firewall et le tour est joué :

VDOM « SD-WAN » :

VDOM « root » :

Comme cela, même si l’interface utilisée change (publique vs privée), le Fortigate utilisera toujours cette unique interconnexion des VDOM pour atteindre la loopback.

Routage asymétrique

On parle de routage asymétrique lorsqu’un paquet n’emprunte pas le même chemin à l’aller et au retour.

J’ai également pu constater ce phénomène avec un simple ping et traceroute entre les 2 laptops :

Dans le même temps j’ai comparé comment se comportait ma session RDP vers le laptop du site 2, 172.16.10.100 :

Là le routage est symétrique, cela me rassure « un peu » plus. En effet, seul le protocole ICMP semble concerné par ce phénomène (le commande tracert windows utilise ce protocole également). Au niveau TCP/UDP avec RDP, c’est à la source qu’est « décidé » sur quel lien la session doit transiter aller/retour, dans notre cas c’est le Fortigate du site 1 avec le lien « public ».

Si j’ai bien constaté que la session se baladait d’un lien à l’autre, à aucun moment je n’ai vu les 2 liens utilisés en même temps pour les connexions TCP/UDP RDP, contrairement à ICMP.

Ce qui me dérange par contre, c’est pour les outils de supervision. Et oui, on utilise souvent le ping pour surveiller qu’un host distant est Up et surveiller la latence. Du coup, avec ce type de comportement le résultat risque d’être biaisé.

Rien de grave mais il faut avoir cela en tête. Et puis je pousse le vis en choisissant volontairement le lien le plus mauvais en premier avec des critères proches des limites du lien.

Et dernière chose, dans ce cas si il s’agit du même Fortigate qui a déjà connaissance d’une session dans sa table. Le routage asymétrique se produit surtout lorsque deux firewall distincts sont traversés, et le flux se trouve bloqué par sécurité.