Configuration de Microsoft Advanced Threat Analytics (ATA)

Bonjour à tous, suite au  premier article ou nous avions vu la découverte et l'installation de Microsoft Advanced Threat Analytics (ATA), aujourd'hui nous allons voir la configuration de celui ci.

Pour que Microsoft Advanced Threat Analytics (ATA) puisse recevoir et surveiller les informations du trafic nous avons la possibilité d'installer deux types de passerelle:

- Passerelle ATA (full gateway): Cette passerelle est installée sur un serveur dédié qui va s'intercaler entre les différents contrôleurs de domaine pour y capturer tout le trafic grâce à la mise en miroir de ports.

- Passerelle Lightweight: C'est une alternative à la Full Gateway, sauf que cette passerelle dite "légère" s'installe directement sur les contrôleurs de domaines et évite d'avoir un serveur dédié.

Même si je recommande un serveur dédié, pour ce laboratoire nous utiliserons la "Passerelle Lightweight".

Pour la configuration de Microsoft Advanced Threat Analytics (ATA) nous devrons avoir les éléments suivants:

- Un compte de service pour pouvoir connecter le centre "ATA" à l'Active Directory"
- Les sources d'installation de la passerelle "ATA Lightweight" (il suffit de les récupérer depuis la console "ATA").
- Nos deux contrôleurs de domaine.

Création d'un compte de service avec seulement des droits de lecture.
Pour l'article je l'ai nommé "ATA" par simplicité mais ce n'est pas une bonne pratique (voir article précédent).

Nous configurons le compte de service dans la gestion "ATA" et nous pouvons constater le bon fonctionnement.

Toujours sur la passerelle "ATA" nous allons récupérer le setup d'installation 

Nous allons maintenant nous connecter sur nos serveurs Active Directory en mode Core et y installer notre passerelle.

Lancer simplement le "setup.exe"






Il est possible aussi de l'installer à distance en winrm.





Sur le mode core l'installation se passe en arrière plan.

Comme on peut le constater ci-dessous, le résultat est concluant car nos serveurs remontent correctement dans le centre de gestion "ATA"

Sur nos deux contrôleurs nous les cochons comme "candidat synchroniseur de domaine", ce qui permet la synchronisation entre l'Active Directory et le centre "ATA" et de remonter tous les informations.

Point d'attention: 

- Ne cochez pas cette fonction pour tous les contrôleurs de domaine car cela peut amener des problèmes de performances.
- La passerelle ne doit en aucun cas être installée sur un RODC.
- Les informations synchronisées entre "ATA" et "Active Direcory" mettent un peu de temps à remonter donc patience.

Dans la partie "Mise à jour", nous aurons la possibilité de mettre automatique à jour nos passerelles.

Rappel: La documentation sur le produit pour voir en détails les différentes options: https://docs.microsoft.com/fr-fr/advanced-threat-analytics/

Une fois ces petites configurations terminées nous allons pouvoir faire des tests d'intrusions et vérifier la bonne remontée d'informations.

Nous allons tester un transfert de zone DNS.

nslookup

set q=all

ls -d labo.local

Je reçois un accès refusé.

 

Nous allons maintenant vérifier la tentative d'intrusion.

Dans le centre de gestion "ATA"  nous allons aller sur "intégrité"

Nous constatons les différentes attaques.

Dans cet article nous avons pu voir la configuration globale de "Microsoft Advanced Threat Analytics (ATA)"

Dans un prochain article de "Microsoft Advanced Threat Analytics (ATA)"  nous essaierons de faire une utilisation avancée du produit (Honeytoken accounts, SIEM, SYSLOG....).

A bientôt. 😏

Installation de Microsoft Advanced Threat Analytics (ATA)

Bonjour à tous, aujourd'hui nouvel article sur l'Installation de "Microsoft Advanced Threat Analytics (ATA)".

Pour commencer, petite présentation du produit.

Microsoft Advanced Threat Analytics (ATA) est une solution locale (On-premise) qui permet l'analyse et la protection contre les cyber-attaques.

Il est capable d'analyser: 

- Les protocoles (DNS, Kerberos...).
- Les authentifications.
- Les autorisations d'accès.
- Les comportements anormaux.
- Les attaques malveillantes ( golden ticket, man in the middle...).

Pour plus de précisions: https://docs.microsoft.com/fr-fr/advanced-threat-analytics/what-is-ata

Fonctionnement de  "Microsoft Advanced Threat Analytics (ATA)":

Ci-dessous le schéma expliquant le fonctionnement d'ATA.

Explications en détails sur le site de Microsoft.

Prérequis pour l'installation de "Microsoft Advanced Threat Analytics (ATA)":

Ports:

Le tableau ci-dessous énumère les ports minimums qui doivent être ouverts pour que l'ATA Center fonctionne correctement.

Déploiement:

- Version d'évaluation (90 jours) de "Microsoft Advanced Threat Analytics (ATA)"
- Windows 2012 R2 Minimum (GUI ).
- La gestion principale ATA ne peut pas s'installer sur un serveur core (seulement la gateway)..
- Compatible virtualisation (la mémoire dynamique n'est pas supportée. 
- Si Windows 2012 R2 GUI, vérifier que la KB2919355 soit bien installé
- Si Windows 2012 R2 Core, vérifier que la KB3000850 soit bien installé.
- Navigateurs d'accès à la console: Internet Explorer 10 et versions ultérieurs, Microsoft Edge, Google Chrome 40 et versions ultérieurs


Bonnes pratiques d'installation:

Avant d'installer Microsoft Advanced Threat Analytics (ATA) en production il est nécessaire de mettre en place les bonnes pratiques ci-dessous recommandées par Microsoft:

- Le serveur ATA devra être à jour avec les derniers cummulatifs.
- L'idéale est de déployer la solution dans une forêt dédiée.
- Nommer les serveurs avec et les comptes de configuration avec un autre nom que "ATA"
- Le par-feu matériel de l'entreprise doit respecter seulement les ports décrits dans le tableau ci-dessus.
- Utiliser un certificat d'une autorité de certification publique.
- Installer principalement les passerelles complètes. 
- Configurer correctement votre antivirus (exclusions bases de données).
- Si vous utilisez le syslog, il faudra le configurer en TLS.
- Si vous utilisez la messagerie, il faudra le configurer en SSL.
-Limiter l'accès à la console ATA (scope ip).

Installation:

Le laboratoire ci-dessous sera utilisé:

- 1 serveur Microsoft Advanced Threat Analytics (ATA).
- 2 contrôleurs de domaine Windows 2019 Serveur Core avec les gateway ATA installées.
- 1 station Windows 10

Nous allons maintenant lancer l'installation de Microsoft Advanced Threat Analytics (ATA).

Lancer le setup ci-dessous

Choisir la langue

Très important, je recommande fortement d'utiliser Windows Update.

Choisir les répertoires d'installation et de base de données.
Choisir votre certificat ou utiliser le certificat auto-signé.

 Installation de la base de données "Mango DB"

 L'installation est maintenant terminée.

Vous pouvez lancer la console et vérifier le bon fonctionnement.













Dans cette première partie, nous avons pu voir l'installation de Microsoft Advanced Threat Analytics (ATA).

Dans le prochain article nous verrons la configuration du produit.

A bientôt.

Active Directory: Création d'un "cookie"

Bonjour à tous et très bonne année.

Pour ce premier article en 2019, je voulais partager avec vous une commande Active Directory que je trouve très pratique.

Il arrive parfois que certains clients demandent d'identifier les modifications pouvant être apportées sur l'active directory lorsque par exemple on augmente le niveau fonctionnel de l'active directory ou lorsque l'on ajoute une application comme Exchange ou ADFS.

Pour ce faire, nous allons créer un "cookie" avec la commande "reapadmin".

Il nous suffit de lancer les commandes ci-dessous:

repadmin /showchanges <nom-du-DC> dc=labo,dc=local /cookie:labo.bin > nul

repadmin /showchanges <nom-du-DC> cn=configuration,dc=labo,dc=local /cookie:labo-cfg.bin > nul

PS: La commande "nul" permet de minimiser le temps de génération du cookie.

Les deux fichiers "cookie" sont maintenant correctement générés.

Nous allons maintenant ajouter des modifications à notre Active Directory en installant le service "ADFS" et nous augmenterons ensuite le niveau fonctionnel du domaine.

Installation de l'ADFS ok:

L'identification des changements dans l'AD associé à l'installation de l'ADFS sera obtenue en présentant le cookie précédemment généré (le cookie sera actualisé).

Un différentiel sera créé entre les premières commandes et les dernières.

Nous pouvons à présent lancer les 2 commandes sans le paramètre "nul".

repadmin /showchanges <nom-du-DC> dc=labo,dc=local /cookie:labo.bin

repadmin /showchanges <nom-du-DC> cn=configuration,dc=labo,dc=local /cookie:labo-cfg.bin

La sortie ci-dessous de la première commande nous montre que l'installation de l'ADFS nous a créé un nouveau conteneur.

La deuxième commande nous montre qu'il n' y a pas eu de modifications au niveau de la partition de configuration de l'Active Directory avec l'installation du service "ADFS".

Nous allons maintenant augmenter le niveau fonctionnel du domaine.

Nous relançons à nouveau les commandes "cookie".

La première commande nous retourne les modifications après l'augmentation du niveau fonctionnel.
On observe  que le niveau fonctionnel du domaine a bien été augmenté.

La deuxième commande concernant la partition de configuration nous renvoie cette fois-ci des modifications.
On observe donc que l'augmentation du niveau fonctionnel du domaine modifie également la partition de configuration.

Ces commandes sont vraiment pratiques et peuvent être utilisées dans des environnements de pré-productions afin d'étudier les impacts ou problèmes potentiels (droits...) que peuvent amener des modifications sur un environnement aussi critique que l'Active Directory.

A très bientôt pour un nouvel article.

Mise en place de comptes gMSA

Bonjour à tous, nouvel article sur la mise en place de comptes gMSA.

Habituellement, nous utilisons tous des comptes de services avec mots de passe.

Qui dit mot de passe dit problème potentiel de piratage, sachant que les mots de passe des comptes de services ne sont en règle générale jamais changés car cela demande beaucoup de temps.

Pour pallier ces problèmes de mot de passe sur les comptes de services, Microsoft a d'abord sorti les comptes MSA avec Windows 2008.

Les gMSA (« Group Managed Service Accounts ») sont ensuite apparus avec Windows Server 2012, lesquels sont une amélioration des comptes MSA permettant l’utilisation d’un compte sur un seul et unique ordinateur. 

Les comptes MSA ne permettaient pas d'utiliser un seul compte pour plusieurs ordinateurs.

Les comptes MSA n'étaient supportés que pour quelques applications.

gMSA est un compte de service associé à un groupe de sécurité dans lequel seront ajoutés les ordinateurs autorisés à utiliser ce compte.

Les comptes gMSA sont compatibles avec les applications ci-dessous:

• Sur plusieurs machines
• Pour des tâches planifiées
• Pour IIS, ADFS, SQL Server, …
• Pour des services Windows

Pour pouvoir créer des comptes gMSA, il faudra générer la clé racine KDS  de Distribution de clés Services.

Pour cela, lancer une console PowerShell et exécuter le code PowerShell ci-dessous:

Cette clé sera ensuite répliquée sur l'ensemble des contrôleurs de domaine. Par sécurité, il est nécessaire d'attendre 10H pour s'assurer que tout soit bien répliqué.

Nous allons maintenant pouvoir créer nos gMSA.

Deux possibilités pour créer ces comptes:

• Avec l'outil graphique "Managed service accounts GUI" téléchargeable ici.
• PowerShell

Managed service accounts GUI:

Il vous suffit simplement d'ajouter le nouveau compte avec "New"
Donnez-lui un nom et choisissez l'OU dans votre active directory où vous souhaitez le stocker.

Votre compte est maintenant créé.

Pour que ce compte fonctionne, il faudra l'attribuer à l'ordinateur autorisé à l'utiliser.

Le compte gMSA peut maintenant être utilisé sur le serveur.

On va également vérifier la présence du compte dans l'active directory

PowerShell:

Idem en PowerShell, mais dans cet exemple, nous allons attribuer un groupe d'ordinateurs au compte gMSA.

Sur notre serveur autorisé à utiliser notre compte gMSA , nous allons enfin configurer le service concerné (dans notre exemple un service "SQL").

Dans cet article, nous avons pu voir la mise en place de comptes gMSA qui apportent beaucoup plus de sécurité qu'un compte de service avec mot de passe.

Je vous dis à très bientôt.

Déploiement d'un environnement Active Directory en mode Core

Bonjour à tous.

Dans ce nouveau billet, je souhaite partager avec vous un sujet qui me tient à cœur: Windows Server Core.

Windows core est une installation minimale sortie avec Windows 2008 Server.

Windows core (Installation minimale de Windows Server) est une version allégée dépourvue d'interface graphique.

La solution core apporte les avantages suivants:

• Aucune interface graphique (limitation des surfaces d'attaques)
• Plus léger en ressources (moins d'espace disque, de mémoires...)
• Déploiement plus rapide, redémarrage plus rapide
• Moins de mises à jour, de patch critiques
• Moins de maintenance
• Forcer les administrateurs à utiliser des stations d'admins.

Nous allons donc voir au travers de ce document la mise en place d'un labo Active Directory en mode core. (Attention, depuis la version Windows 2016, il n'est plus possible de convertir le mode core en mode GUI, il faudra donc réinstaller le système d'exploitation).

Le déploiement a été effectué sur un Windows 2016 Server Core

Ensuite, l'utilitaire "Sconfig" a été utilisé pour configurer les IPs, DNS et nom d'ordinateur

Si vous souhaitez, comme moi, gagner du temps en utilisant "PowerShell", il vous suffira simplement d’utiliser les commandes ci-dessous:

Notre serveur est maintenant prêt, nous allons donc pouvoir créer notre forêt Active Directory:

Pour info:Les commandes ci-dessous sont les mêmes que celles utilisées lorsque vous lancez l'assistant ADDS en mode graphique.

 Nous pouvons maintenant ajouter un deuxième contrôleur de domaine avec un script PowerShell légèrement différent de celui évoqué précédemment:

Nous avons pu voir à travers cet article comment déployer rapidement une nouvelle forêt Active Directory (pratique aussi pour les labos de tests).