Collecte de logs Synology #2 : Création d’un DSM QRadar
Bonjour à tous, voici le deuxième article de la séries consacrée à la collecte des événements sur les équipements Synology. Nous avons vu dans le précédent article comment mettre en place l’envoi des logs via syslog-ng. Maintenant nous allons nous intéresser à la partie qui va permettre d’avoir des logs utilisables dans QRadar, je parle du parsing et du mapping.
Je ne vais pas rentrer dans les détails du parsing et du mapping car je l’ai déjà fait dans un article consacré à ce sujet que vous retrouverez ici.
A noter également que je vais présenter en détail la construction d’un DSM Custom uniquement pour la partie “fichier” sur les NAS. Il y a plusieurs raisons à cela :
- La construction de ce DSM est un bon contenu pour apprendre les bases
- La supervision des actions sur les fichier pour un NAS, c’est un point crucial à avoir
2. Identification des logs
Comme décrit dans l’article sur les DSM Custom, il va nous falloir 2 éléments importants (en vérité 3 mais vous verrez par la suite que c’est bon) :
- Un “Event Category”
- Un “Event ID”
Le premier va permettre de savoir que c’est bien un événement de telle technologie, telle application ou encore tel OS. Typiquement dans le cas présent nous savons que ce ne sont que des logs provenant de la supervision des actions sur les “fichiers” du NAS. Cela constitue donc la même application, ou tout du moins nous pouvons ranger tous ces logs dans un même “Event Category”. Ainsi pour correspondre d’un point de vue technique, il nous faut un élément fixe dans le log comme par exemple la “facility” du log qui est toujours égale à “kernel”.
D’un autre côté, il nous faut un deuxième élément qui va permettre la distinction entre tous les événements d’un même “Event Category”. En effet, je n’ai pas envie de mélanger les créations de fichier avec les suppressions. Pour cela il nous faut un élément fixe pour chaque log d’une même action mais qui va varier en fonction de l’action bien entendu.
Dans l’exemple ci-dessus, on voit bien que le ① va correspondre à “Event Category” et que le ④ sera le plus adéquat pour “Event ID”.
Maintenant que nous avons cette ligne directrice validée, nous pouvons passer à la suite de la création du DSM : le parsing.
3. Parsing des logs
Pour le parsing des logs, il faut bien faire attention à avoir un échantillon de logs représentatif de l’ensemble. Cela permet d’éviter les rustines à appliquer car tel ou tel log n’a pas le même format et donc les éléments souhaités ne sont pas récupérés.
Dans notre cas, nous pouvons par exemple faire quelques créations/suppressions de fichiers sur le NAS et récupérer les événement qu’il en ressort. On va obtenir un extrait de ce type :
On note ici qu’il y a 5 éléments importants à récupérer, comme il ne s’agit pas d’un format de logs très codifié comme peuvent l’être le JSON ou le XML par exemple, il va falloir passer par l’utilisation de regex.
Pour minimiser l’impact de cette étape d’un point de vue performance, il faut, comme pour du code classique, qu’il y ait le moins d’itérations dans le calcul de votre regex. Pour cela, je vous conseille d’utiliser un site de calcul d’itérations pour une regex donnée sur un échantillon.
Enfin, pour le détail des regex que j’ai pu utiliser je vous invite à télécharger le DSM que j’ai publié ici.
4. Mapping des logs
Nous avons désormais un parsing des événements qui est validé, il nous faut maintenant relier par paire un “Event Category” avec un “Event ID” pour avoir un événement. C’est ce que l’on appelle plus communément le mapping des logs. Comme pour beaucoup d’étapes dans la création d’un DSM Custom, il faut prendre le temps de voir quels sont les différents événements que l’on a, mais aussi les possibles liens entre eux (ie : deux “Event ID” peuvent vouloir dire qu’il y a eu une suppression de fichier).
Enfin, je vous conseille de vous renseigner sur l’existant dans QRadar, en effet, cela va vous permettre de vous calquer sur des exemples pour votre technologie à vous. Pour ce faire, vous pouvez afficher la création d’un événement et naviguer en recherchant un type d’événement comme ceci :
Je vous conseille de filtrer sur un type de log source sinon vous risquez d’avoir beaucoup trop de résultats, faites simple et prenez des types connus comme les événements Windows ici.
Il y a également la possibilité de rechercher parmi la liste de tous les événements par le biais de ce lien :
- Je manipule des fichiers depuis ma machine Windows (donc SMB2)
- Je manipule des fichiers depuis la GUI du NAS
- Je manipule des fichier depuis ma machine Windows et j’effectue la suppression de tous fichiers de test (“Event Count” qui correspond bien au nombre de fichiers que j’ai supprimé)
Point à noter : vous voyez que j’ai surligné 2 événements en jaune, il s’agit de la même action (upload d’un fichier) mais dans l’événement que j’ai quand l’action est faite depuis du SMB2, cela apparaît comme de la création de fichier. Ce n’est pas une fin en soi mais il faut faire attention à certains “flous” qu’il peut y avoir pour que votre mapping colle le mieux à la réalité.
5. Conclusion
Nous voici à la conclusion de ce deuxième article à la fin duquel vous êtes en mesure d’avoir les événements de votre Synology sur QRadar de manière propre et compréhensible.
N’hésitez pas à laisser un petit commentaire pour dire ce que vous en avez pensé, mais également de l’utilisation que vous faites de votre NAS Synology, si vous en avez un, pour me dire s’il y a des applications qu’il pourrait être intéressant de superviser.
Vous retrouvez l’ensemble de mes DSM Custom sur mon Github, pensez à les utiliser et à laisser une petite ⭐ si cela vous a plu.
Nous verrons dans le prochain article comment créer des règles de détection spécifiquement pour ce type de technologie, je vous invite, dès à présent, à partager vos idées pour essayer d’avoir une supervision de votre NAS au top.