En cas d'échec des tentatives de connexion
Les tentatives de connexion ayant échoué doivent-elles être enregistrées? Mon doute est que s'il y a une attaque distribuée par force brute, elle pourrait épuiser l'espace disque disponible de la base de données. Quelle est la meilleure pratique pour cela?
Je protège un serveur Web public avec des données sensibles.
Sur la base des réponses jusqu'à présent, une autre question qui m'est venue à l'esprit est de savoir si les journaux du serveur Web seraient suffisants pour consigner de telles tentatives. Serait-il redondant de les enregistrer dans la base de données?
Oui, les tentatives de connexion ayant échoué doivent être enregistrées:
- Vous voulez savoir quand les gens essaient - d'essayer pour entrer
- Vous voulez comprendre pourquoi vos comptes sont bloqués
Il est également très important - l'ancien processus de journalisation de Windows n'a jamais suffisamment insisté sur ce point - de consigner tentatives de connexion réussies également. Parce que si vous avez une chaîne de tentatives de connexion échouées, vous devriez vraiment vraiment savoir si la dernière a été suivie d'une connexion réussie.
Les journaux sont relativement petits. S'il y a eu suffisamment de tentatives de connexion pour que la journalisation cause un problème, alors "ne pas connaître les tentatives" est probablement un problème pire que "découvert à leur sujet lorsque nous manquions de disque".
Une mise en garde rapide - comme @Polynomial le fait remarquer, le mot de passe ne doit pas être enregistré (je semble me rappeler qu'il y a 25 ans, certains systèmes le faisaient encore). Cependant, vous devez également être conscient que certaines tentatives de connexion légitimes échoueront lorsque les gens entreront leur mot de passe dans le champ du nom d'utilisateur, donc les mots de passe seront enregistrés. Vous doutez de moi? Parcourez vos journaux pour l'ID d'événement Windows 4768:
LogName=Security
SourceName=Microsoft Windows security auditing.
EventCode=4768
EventType=0
Type=Information
ComputerName=dc.test.int
TaskCategory=Kerberos Authentication Service
OpCode=Info
RecordNumber=1175382241
Keywords=Audit Failure
Message=A Kerberos authentication ticket (TGT) was requested.
Account Information:
Account Name: gowenfawr-has-a-cool-password
Supplied Realm Name: TEST.INT
User ID: NULL SID
En conséquence, vous devez limiter l'accès à ces journaux aux personnes nécessaires - ne vous contentez pas de les vider dans un SIEM auquel toute l'entreprise a accès en lecture.
Mettre à jour pour répondre à l'édition de la question:
Sur la base des réponses jusqu'à présent, une autre question qui m'est venue à l'esprit est de savoir si les journaux du serveur Web seraient suffisants pour enregistrer de telles tentatives. Serait-il redondant de les enregistrer dans la base de données?
Les meilleures pratiques sont que les journaux doivent être transmis à un agrégateur de journaux distinct dans tous les cas - par exemple, considérez PCI DSS 10.5.4. Dans la pratique, un tel agrégateur est généralement un SIEM et fonctionne comme une base de données plutôt que des fichiers journaux plats.
Donc, oui, c'est "redondant" par définition, mais c'est le genre de redondance qui est une caractéristique de sécurité, pas une erreur architecturale.
Les avantages de leur connexion à une base de données incluent la recherche, la corrélation et la sommation. Par exemple, la recherche Splunk suivante:
source="/var/log/secure" | regex _raw="authentication failure;" | stats count by user,Host
Nous permettra de cumuler les échecs d'authentification par utilisateur et hôte:
Notez que la possibilité d'interroger des champs discrets comme "utilisateur" et "hôte" dépend de la séparation des journaux SIEM et de la compréhension de ce que signifie quoi. L'accessibilité de ces champs ici est un effet secondaire de Splunk analysant automatiquement les journaux pour moi.
Étant donné que votre question initiale portait sur les contraintes d'espace, il convient de souligner que toute base de données ou solution SIEM va prendre plus d'espace disque que les journaux de fichiers texte plats. Cependant, si vous utilisez une telle solution, vous la placerez presque toujours sur un serveur distinct pour des raisons de sécurité et de gestion de l'espace. (Il existe même des solutions SIEM dans le cloud pour vous faciliter la vie!)
En complément de la réponse de @ gowenfawr qui explique pourquoi vous devriez enregistrer ces tentatives, je voudrais dire qu'il existe des moyens de garantir que les journaux n'épuiseront jamais vos disques.
Au moins dans le monde Unix-Linux, des outils comme logrotate ou rotatelogs permettent de changer le fichier journal lorsque sa taille dépasse un certain seuil. Ils sont couramment utilisés avec le serveur Apache (les rotatelogs proviennent de la fondation Apache) ou avec le système syslog.
Par exemple, logrotate est utilisé pour renommer un fichier journal (dans un anneau d'un certain nombre de copies, généralement environ 10 d'entre eux), éventuellement le compresser, et avertit le programme générant le journal de rouvrir son fichier journal en l'envoyant un signal dédié ou via toute commande arbitraire.
De cette façon, si votre serveur fait l'objet d'une attaque DoS, la taille de vos fichiers journaux restera sous contrôle. Bien sûr, vous perdrez des événements plus anciens, mais c'est certainement mieux que de planter le serveur en raison d'une partition de disque épuisée.
Cela dépend vraiment de la valeur que vous pensez pouvoir tirer des informations. Il y a une valeur limitée à avoir des pages de journaux vous indiquant que votre serveur est attaqué; il fait face à Internet et sera probablement soumis à divers degrés de bombardement constant pendant toute sa durée de vie.
Selon la configuration de votre serveur, il est tout à fait possible de créer un problème de disponibilité car vous avez épuisé l'espace disque disponible avec les journaux. Cela arrive. Gowenfawr a eu raison de dire que les journaux ne prennent pas beaucoup d'espace, mais c'est pourquoi les problèmes d'épuisement de l'espace disque peuvent prendre des années à apparaître, mais ils sont une douleur majeure lorsqu'ils le font.
Si vous décidez de vous connecter, vous devez alors concevoir une stratégie de gestion des journaux et prendre en compte certains des éléments suivants:
- Que vais-je faire de mes journaux? Que se passe-t-il après avoir établi que quelqu'un essaie d'accéder à votre système?
- Mes journaux contiendront-ils des données potentiellement sensibles? (N'oubliez pas que les vrais utilisateurs peuvent parfois saisir leurs informations d'identification). Si la réponse est oui, envisagez de nettoyer les journaux avant le stockage ou de les chiffrer une fois au repos
- Verbosité et journal des événements
- À quelle fréquence dois-je faire tourner les journaux? Rotation du journal est un moyen assez standard de gérer la taille des journaux. Il peut vous permettre de compresser les anciens journaux et potentiellement supprimer des archives de journaux particulièrement anciennes
- Informations sur la sécurité et gestion des événements. _Vous avez mentionné que votre serveur contiendra des informations sensibles, selon ce que vous voudrez peut-être examiner SIEM produits qui peuvent vous fournir des informations utiles basées sur journalisation et autres données telles que les alertes, les tableaux de bord, la criminalistique, etc.
En parlant personnellement, j'ai tendance à trouver les journaux uniquement utiles pour l'analyse médico-légale - ils aident à déterminer ce qui s'est passé après une violation réussie. Comme l'a mentionné Gowenfawr; la journalisation des tentatives réussies de connexion à un système est tout aussi (probablement plus) importante que celles qui ont échoué.
Un dernier point, votre mécanisme de connexion doit être construit de telle sorte que la probabilité qu'une force brute distribuée fonctionne jamais est extrêmement faible. Vous n'avez pas donné beaucoup de détails sur ce que vous avez construit, mais l'utilisation d'algorithmes de backend puissants, en particulier des hachages coûteux en termes de calcul et l'introduction d'un délai d'interruption dans les tentatives de connexion peuvent réduire considérablement les chances qu'un attaquant y accède de cette façon.