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.

Maintenance d'un DAG Exchange 2019

Bonjour à tous, nouvel article sur Exchange 2019.

Aujourd'hui, nous allons voir comment mettre en maintenance un DAG sur Exchange 2019.

Dans le dernier épisode, nous avions pu voir la mise en place d'un DAG Exchange 2019, mais qui dit produit Microsoft dit bien évidemment mises à jour de nos serveurs Exchange (Cumulatifs Windows Server, Rollup Exchange..).

L'exemple le plus marquant pour la mise en maintenance d'un nœud Exchange sera bien évidement le passage d'un rollup Exchange.

L'installation d'un rollup Exchange  mettra hors connexion votre noeud, puisque le rollup désinstalle complètement l'application pour la réinstaller avec la nouvelle version.

Mais les questions qui reviennent le plus souvent sont les suivantes:

- Mais pourquoi mettre en maintenance un serveur Exchange  alors que je passe mes rollup le soir ou le Week-end?

- Mais pourquoi mettre en maintenance un serveur Exchange car je trouve que cela prend beaucoup de temps à faire toutes ces manipulations?

Comme toutes mises à jours il y a des phénomènes que l'on ne peut pas toujours anticipés, tout ne se passe pas comme prévu (il faut reconnaître qu'il n' y a plus beaucoup de problèmes, Microsoft ayant fait beaucoup d'effort sur la façon d'installer un nouveau rollup).

Chacun doit prendre conscience que l'on doit prendre un maximum de précautions même si cela doit prendre un peu plus de préparation.

Les avantages d'un DAG sont les suivants:

- Eviter de perdre des données et de rendre indisponible une base de données.
- Possibilité de passer un rollup en pleine Journalisée sans impacts sur les utilisateurs
- Possibilité de passer des cumulatifs update et redémarrer le serveur en pleine journée
- Possibilité de prendre du temps pour investiguer un problème matériel

Pour mettre un nœud Exchange en maintenance, nous n'allons pas utiliser le scripts présents par défaut dans le répertoire des binaires Exchange car je trouve qu'ils ne fonctionnent pas très bien donc je ne les recommande pas. (voir ci-dessous).

Nous allons en détails effectuer les différentes commandes.

Il est très important de comprendre le fonctionnement de mise en maintenance d'un nœud Exchange configuré dans un DAG.

Une fois que l'on maîtrise les différentes commandes on pourra automatiser le tout dans un script.

Pour commencer, nous allons nous connecter à la console "Exchange Management Shell".

La première commande à passer sera de vider le "Hub Transport" du nœud Exchange et de le passer en mode "drainage"

Set-ServerComponentState EXCH2019A -Component HubTransport -State Draining -Requester Maintenance 

Redémarrage du service.

Restart-Service MSExchangeTransport 

Nous allons ensuite forcer à rediriger tous les messages de la file d'attente vers l'autre serveur du DAG.

Redirect-Message -Server EXCH2019A -Target EXCH2019B.labo.local

Nous vérifions le résultat de la commande.

Get-ServerComponentState EXCH2019A -Component HubTransport

Nous vérifions ensuite quel serveur gère le "Primary Active Manager (https://docs.microsoft.com/fr-fr/exchange/high-availability/database-availability-groups/active-manager?view=exchserver-2019)


Get-DatabaseAvailabilityGroup -Status | fl Name, PrimaryActiveManager

Nous constatons que le PAM est géré par le noeud que souhaitons mettre en maintenance.
Il faudra donc le déplacer.

Nous allons donc déplacer le PAM vers l'autre nœud.

Remarque: vous devrez vous connecter en "PowerShell Remoting avec WinrM sur l'un deux serveurs.

Move-ClusterGroup "Groupe du cluster" -Node EXCH2019B

 On vérifie la bonne migration du PAM vers le deuxième serveur.

Get-DatabaseAvailabilityGroup -Status | fl Name, PrimaryActiveManager








Nous mettons en pause le cluster sur le Nœud Exchange.

Suspend-ClusterNode EXCH2019A

On vérifie le résultat.
Get-ClusterNode







Nous allons maintenant déplacer les copies Actives sur le nœud.
Nous vérifions quelles bases de données sont actives (Mounted) sur le Nœud Exchange.

Get-MailboxDatabaseCopyStatus -Server EXCH2019A

Nous remarquons que la base de données DB01 est active sur le serveur Exch2019A.

Nous déplaçons donc la copie active de la base de données DB01 vers le serveur Exch2019B.

Get-MailboxDatabaseCopyStatus -Server EXCH2019A | ? {$_.Status -eq "Mounted"} | % {Move-ActiveMailboxDatabase $_.DatabaseName -ActivateOnServer EXCH2019B -Confirm:$false}




Nous vérifions les copies actives sur le serveur Exch2019B

Get-MailboxDatabaseCopyStatus -Server EXCH2019B

DB01 est bien active sur le serveur EXCH2019B.





On peut également vérifier la présence dans le Centre d'Administration Exchange.

La commande ci-dessous sera nécessaire pour empêcher le serveur EXCHA2019A de pouvoir à nouveau monter la base de données DB01.

Set-MailboxServer EXCH2019A -DatabaseCopyAutoActivationPolicy Blocked

Vérification de la stratégie.

Get-MailboxServer EXCH2019A | ft Name,DatabaseCopyAutoActivationPolicy

 Pour terminer nous mettons notre nœud en maintenance.

Set-ServerComponentState EXCH2019A -Component ServerWideOffline -State Inactive -Requester Maintenance




Notre serveur est maintenant totalement hors ligne du DAG!!! 💪😏
Vous pouvez maintenant effectuer votre maintenance en toute sécurité!!!



Une fois votre maintenance terminée, nous allons pouvoir sortir le serveur Exchange de sa maintenance.

On sort le serveur du mode maintenance.

Set-ServerComponentState EXCH2019A -Component ServerWideOffline -State Active -Requester Maintenance

On réactive le cluster du le nœud.

Resume-ClusterNode EXCH2019A

On autorise à nouveau la possibilité l'auto-montage de la base de données sur le nœud.

Set-MailboxServer EXCH2019A -DatabaseCopyAutoActivationPolicy Unrestricted

    Et on vérifie.

Get-MailboxServer EXCH2019A | ft Name,DatabaseCopyAutoActivationPolicy

 On réactive le transport sur le serveur Exchange.

Set-ServerComponentState EXCH2019A -Component HubTransport -State Active -Requester Maintenance

Et on vérifie.

Get-ServerComponentState EXCH2019A -Component HubTransport





On vérifie que le serveur est à nouveau hors maintenance.

Get-ServerComponentState EXCH2019A | ft Component,State -AutoSize

 On rétablit le PAM sur le serveur Principal (Juste plus clair pour moi).

Move-ClusterGroup "Groupe du cluster" -Node EXCH2019A

On vérifie les bases de données.

Get-MailboxDatabaseCopyStatus -Server EXCH2019A

Get-MailboxDatabaseCopyStatus -Server EXCH2019B

On peu constater que tout est revenu comme à l'origine:

- DB01 est Active sur Exch2019A et Passive sur EXCH2019B
- DB02 est Active sur Exch2019B et Passive sur EXCH2019A

Voilà c'est terminé, tout est maintenant opérationnel. 😃😄

Dans cet article nous avons pu voir et comprendre la mise en maintenance d'un serveur Exchange 2019 présent dans un DAG.

Si vous avez compris et que vous maîtrisez les différentes étapes effectuées ci-dessus vous n'avez plus qu'à construire votre script.

A vos tests!Scriptez!!😊😊