Meilleure façon de suivre l'énumération de nom d'utilisateur Brute-Force / les tentatives de nom d'utilisateur ayant échoué AD

Nous avons un serveur Windows qui a une application qui réside dessus, qui utilise les informations d'identification du domaine lors de la connexion à l'application. Lors d'un test de plume récent, les testeurs ont pu utiliser l'application afin d'énumérer les noms d'utilisateur de domaine valides en fonction de la réponse de l'application (il a donné une réponse différente pour un nom d'utilisateur non valide par rapport à un mot de passe non valide).

L'application est en cours de correction, de sorte qu'elle ne révèle pas ces informations, mais je pense également que nous aurions dû détecter cette attaque, car il y a eu plus de 2 000 000 tentatives de noms d'utilisateurs invalides sur une courte période. Nous ne l'avons pas vu, même lorsque nos administrateurs surveillaient de près Active Directory. Apparemment, les échecs ne sont apparus que dans le journal des événements local du serveur sur lequel l'application a été installée.

Ma question: 1) Existe-t-il un moyen d'obtenir Active Directory pour enregistrer ces demandes de nom d'utilisateur ayant échoué dans un emplacement central afin que nous puissions remarquer une pointe en eux?

2) Sinon, quelle est la meilleure façon de surveiller et de détecter activement ce type d'attaque à l'avenir (avec un peu de chance sans avoir à acheter trop de nouveaux équipements).

Merci de votre aide.

Grande question.

Tout d'abord - je considère que la plupart des "testeurs de pénétration" sont des gamins de script. Mon parti pris n'est peut-être pas juste ou exact, mais je mets cet avertissement afin que si vous détectez un cynisme dans mon ton, vous savez d'où il vient. Je ne dis pas qu'il n'y a pas de pentesters qualifiés, mais c'est ma généralité générale.

(Équipe bleue pour la vie!)

Ma question: 1) Existe-t-il un moyen d'obtenir Active Directory pour enregistrer ces demandes de nom d'utilisateur ayant échoué dans un emplacement central afin que nous puissions remarquer une pointe en eux?

Vous n'avez pas fourni suffisamment d'informations pour que quiconque puisse répondre à cette question de manière approfondie et en toute confiance. Vous avez dit que votre application contenait une faille qui permettait aux attaquants d'énumérer les comptes d'utilisateurs. J'essaie de comprendre de quelle manière vous pensez qu'AD doit effectuer la journalisation pour votre application.

Apparemment, les échecs ne sont apparus que dans le journal des événements local du serveur sur lequel l'application a été installée.

Apparemment, les échecs sont apparus dans le journal des événements sur le serveur? Ou les échecs sont apparus dans le journal des événements sur le serveur? Si oui, que disent exactement les événements? Qui les a enregistrés? Ton application? Ou Windows? Allez le découvrir et je pourrai peut-être ajouter des éclaircissements à ma réponse.

Je vais m'étendre ici sur la base de votre présomption que ces événements auraient dû être enregistrés par Active Directory d'une manière ou d'une autre ... et si vos pentesters n'exploitaient pas du tout une faille dans votre application, mais utilisaient à la place une faille très connue dans Kerberos pour énumérer les noms d'utilisateurs? Kerberos lui-même contient ce que je considérerais comme une faille de conception dans laquelle un attaquant peut tenter des milliers et des milliers de tentatives de "pré-authentification" (c'est-à-dire une attaque par force brute) et le KDC répondra différemment selon que le compte utilisateur existe ou non. Ce comportement n'est pas spécifique à Active Directory, mais s'applique tout aussi bien au MIT Kerberos, Heimdal, etc. Le KDC répondra parKDC_ERR_PREAUTH_REQUIREDsi un nom d'utilisateur valide a été présenté sans données de préautorisation, même sans tenter une authentification réelle. De cette façon, vous pouvez énumérer les noms d'utilisateur d'un KDC. Mais parce que l'attaquant (ou l'outil que l'attaquant utilise tel que KrbGuess - parce que les pentesters sont à leur meilleur lorsqu'ils utilisent les outils des autres), n'a pas à poursuivre une tentative d'authentification complète, rien n'est enregistré car aucun l'authentification réelle a été tentée!

Passons maintenant à votre prochaine question:

2) Sinon, quelle est la meilleure façon de surveiller et de détecter activement ce type d'attaque à l'avenir (avec un peu de chance sans avoir à acheter trop de nouveaux équipements).

Un certain nombre de choses.

Premièrement, il existe des produits payants de qualité professionnelle conçus pour détecter ce type d'attaques (entre autres). De nombreux fournisseurs proposent de tels produits, et les recommandations de produits sont hors sujet pour Serverfault, mais il suffit de dire qu'elles sont hors service Là. Beaucoup de ces produits fonctionnent en vous obligeant à configurer la mise en miroir des ports entre vos contrôleurs de domaine et ces «collecteurs de données» afin qu'ils voient et analysent littéralement chaque paquet entrant ou sortant de vos contrôleurs de domaine.

(Désolé, cela tombe un peu dans votre clause "sans acheter trop de nouvelles choses".)

Une autre chose qui pourrait vous aider est l'entrée de registre:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

LogLevel = 1

Documenté ici .

Si vous activez cette entrée de registre, vous devriez être inondé d'événements dans votre journal des événements de sécurité à propos des erreurs Kerberos qui mentionnent que la pré-authentification Kerberos est requise. Un exemple d'un tel événement:

A Kerberos Error Message was received:
 on logon session DOMAIN\serviceaccount
 Client Time: 
 Server Time: 12:44:21.0000 10/9/2012 Z
 Error Code: 0x19 KDC_ERR_PREAUTH_REQUIRED
 Extended Error: 
 Client Realm: 
 Client Name: 
 Server Realm: DOMAIN
 Server Name: krbtgt/DOMAIN
 Target Name: krbtgt/DOMAIN@DOMAIN
 Error Text: 
 File: e
 Line: 9fe
 Error Data is in record data.

Mais cela peut ou peut ne pas vous aider s'il ne précise pas d'où viennent exactement le tsunami des requêtes Kerberos. Cela nous ramène aux produits de détection d'intrusion d'entreprise que j'ai mentionnés plus tôt.

Et n'oubliez pas le transfert d'événements Windows qui peut permettre à vos serveurs de transférer des événements vers un emplacement centralisé pour être analysés par n'importe quel outil dont vous disposez.

Jusqu'à présent, toute cette réponse était fondée sur le protocole Kerberos, que je ne peux même pas vraiment tenir pour acquis car vous avez donné si peu de détails dans votre message. Néanmoins, j'espère que cela aide au moins un peu.

C'est une question intéressante à laquelle j'aimerais entendre une bonne réponse. J'ai trouvé des informations que Doug pourrait trouver utiles, mais je pense qu'elles pourraient être légèrement insuffisantes. Quelqu'un d'autre peut probablement fournir une réponse élargie:

Connectez-vous au serveur sur lequel vous souhaitez conserver les informations d'audit, exécutez -> RSOP.MSC -> Configuration ordinateur -> Paramètres Windows -> Paramètres de sécurité -> Stratégies locales -> Stratégie d'audit -> "Événements de connexion au compte d'audit" & " Audit des événements de connexion "

L'explication des «événements de connexion au compte» se lit comme suit:

Auditer les événements de connexion au compte

Ce paramètre de sécurité détermine si le système d'exploitation vérifie chaque fois que cet ordinateur valide les informations d'identification d'un compte.

Les événements de connexion au compte sont générés chaque fois qu'un ordinateur valide les informations d'identification d'un compte pour lequel il fait autorité. Les membres de domaine et les machines non jointes au domaine font autorité pour leurs comptes locaux; les contrôleurs de domaine font tous autorité pour les comptes du domaine. La validation des informations d'identification peut prendre en charge une connexion locale ou, dans le cas d'un compte de domaine Active Directory sur un contrôleur de domaine, peut prendre en charge une connexion à un autre ordinateur. La validation des informations d'identification est sans état, il n'y a donc aucun événement de déconnexion correspondant pour les événements de connexion au compte.

Si ce paramètre de stratégie est défini, l'administrateur peut spécifier s'il convient d'auditer uniquement les succès, uniquement les échecs, à la fois les succès et les échecs, ou de ne pas auditer ces événements du tout (c'est-à-dire ni les succès ni les échecs).

L'explication des «événements de connexion» se lit comme suit:

Auditer les événements de connexion

Ce paramètre de sécurité détermine si le système d'exploitation audite chaque instance d'un utilisateur qui tente de se connecter ou de se déconnecter sur cet ordinateur.

Les événements de déconnexion sont générés chaque fois que la session de connexion d'un compte d'utilisateur connecté se termine. Si ce paramètre de stratégie est défini, l'administrateur peut spécifier s'il convient d'auditer uniquement les succès, uniquement les échecs, à la fois les succès et les échecs, ou de ne pas auditer ces événements du tout (c'est-à-dire ni les succès ni les échecs).

Vous devez essentiellement activer ces stratégies, définir les paramètres de stratégie et choisir «échec» si vous souhaitez simplement surveiller les tentatives infructueuses. Si vous le souhaitez, vous pouvez également surveiller les succès, mais cela peut être un peu plus difficile à analyser si vous ne vous inquiétez que de rechercher ce type d'attaque.

Si vous êtes préoccupé par des configurations similaires auxquelles vos systèmes peuvent être vulnérables, je recommanderais de regarder dans les paramètres STIG ( lien ), lorsqu'il est utilisé en conjonction avec un scanner SCAP, il peut vraiment aider à mettre en évidence certains des risques auxquels votre organisation pourrait être orienté vers. La visionneuse STIG a tendance à soulever quelques faux positifs, mais si vous lisez les détails de chaque problème, vous pourriez le trouver non-démarreur.