Comment surveiller vos équipements #2 – Premières collectes

1. Introduction
2. Surveillance Windows
3. Surveillance Linux
4. Surveillance serveur web (Apache2)
5. Conclusion
6. Bibliographie

1. Introduction

Ça y est votre QRadar est fonctionnel, nous allons maintenant mettre en place la surveillance sur des équipements classique que sont :

• Une machine Windows
• Une machine Linux
• Un serveur Apache2 (très pratique quand on a un petit blog 😏)

Pour cela vous pouvez utiliser des machines virtuelles ou des machines existantes parmi vos équipements personnels.

Dans mon cas je vais mettre en place la surveillance sur ma machine Windows personnel et mon VPS Linux hébergé dans le cloud. Et oui ! vous pouvez surveiller vos équipements en dehors de chez vous, pour cela il faudra juste vous armez de votre “Le Réseau pour les Nuls” et faire quelques configurations sur votre box internet.

2. Surveillance Windows

Pour la surveillance Windows nous allons utiliser l’agent que propose IBM pour collecter les événements de votre ordinateur. Il est possible de le télécharger sur le site d’IBM dans le Fix Central l’exécutable en question :

https://www.ibm.com/support/fixcentral/swg/selectFixes?parent=IBM Security&product=ibm/Other+software/IBM+Security+QRadar+SIEM&release=7.3.0&platform=All&function=textSearch&text=wincollect

Quand la recherche a fini il faut bien choisir l’exécutable suivant :

<VERSION-QRADAR>-QRADAR-AGENT-wincollect-<VERSION WINCOLLECT>.<ARCHITECTURE>.exe

Téléchargez le fichier et transférez le sur la machine que vous souhaitez superviser puis exécutez le pour arriver sur la capture suivante :

On continue l’installation en cliquant sur “Next >“.

On coche “I accept the term in the license agreement” puis on clique sur “Next >“.

La configuration des information du système est facultative, vous pouvez donc mettre ce que vous souhaitez (ici je laisse par défaut, c’est à dire l’utilisateur avec lequel j’ai exécuté l’installeur en tant qu'”User Name“). Ensuite on clique sur “Next >“.

Pour l’emplacement d’installation, il est très fortement conseillé de laisser sur le lecteur C: de votre système car il est dit sur le support IBM que des bugs connus peuvent apparaître en cas d’installation sur un autre lecteur. Cliquez sur “Next >“.

Nous voici arrivés à la configuration de la console (collecteur QRadar). Avant de mettre des valeurs, il nous faut configurer un token d’authentification, qui permettra à l’agent de s’authentifier auprès de la console. Pour ce faire, retournez sur la GUI de QRadar avec un compte administrateur puis dans “Admin > Authorized Services“. Dans la nouvelle fenêtre qui vient de s’ouvrir, cliquez sur “Add Authorized Service” et renseignez les informations suivantes :

1. “Service Name” : le nom “humainement lisible” de votre token
2. “Expiry Date” : la durée de validité de votre token, j’ai personnellement coché “No Expiry” qui demande moins de maintenance sur une instance personnelle

Le reste des champs peut être laissé par défaut. Après avoir tout renseigné vous pouvez cliquer sur “Create Service” et lorsque vous allez retourné sur la page d’accueil des “Authorized Services” vous aurez votre token et il faut sauvegarder la valeur dans la colonne “Authentication Token” que vous allez mettre dans le champ du même nom pendant l’installation de l’agent WinCollect.

Retournons maintenant à l’installation, il faut vous munir désormais de l’IP du collecteur que vous renseignez dans le champ “Configuration Console” (ici je suis dans un cas particulier ou j’envoie vers un équipement réseau qui va renvoyer en interne vers le collecteur). Pour le port, si vous envoyez directement vers le collecteur vous laisserez la valeur par défaut à savoir “8413“, pour ma part comme je passe par un relai je me suis adapté.

Vous pouvez ensuite cliquer sur “Next >“.

Sur le prochain écran, nous allons décidé de, si oui ou non nous allons créer la log source automatiquement sur le collecteur. Je vous conseille de le faire et donc de cocher “Create Log Source” et de renseignez les valeurs suivantes :

• “Log Source Name” : le nom de votre log source, je vous conseille de mettre un nom facilement identifiable même si vous pouvez mettre ce que vous souhaitez sans conséquence
• “Log Source Identifier” : le nom d’hôte de la machine que l’on souhaite collecter (alternativement l’IP est possible même si déconseillé)

Pour la dernière valeur, il faut retourner une fois de plus sur la GUI du collecteur pour ajouter une “Destination Name” via “Admin > WinCollect” puis allez sur l’onglet “Destination” et complétez comme ci-dessous :

Le “Host Name” correspond à l’IP du collecteur et le “Port” est le port de réception du Syslog. Dans le cas présent vous constatez que j’ai modifié et que j’ai mis “51411“, c’est parce que je passe par un relai, mais si vous n’avez pas de contrainte particulière vous pouvez laisser “514“.

Une fois que cela est créé vous pouvez renseigner le “Name” dans le champ “Destination Name” de l’installeur WinCollect.

Enfin pour le choix des “Event Logs” vous pouvez laisser par défaut mais libre à vous de collecter plus ou moins d’informations.

Cliquez sur “Next >“.

Pour l’écran de la personnalisation de la collecte d’un point de vue taux de collecte, vous pouvez laisser par défaut et cliquez sur “Next >“.

Nous arrivons presqu’à la fin, et si vous n’avez pas de configuration particulière comme moi (relai d’un point de vue réseau) vous pouvez laisser tous les champs par défaut. Dans le cas contraire, vous modifierez le champ suivant :

• “Syslog Status Server (if different from default)” : l’adresse du collecteur que vous avez mentionné plus haut dans la configuration de la “Destination Name” avec le port de collecte après les “:” suivant l’adresse IP si le port est personnalisé (ce qui est le cas ici)

Puis cliquez sur “Next >“.

Nous voici dans l’écran récapitulatif de l’installation, vous pouvez cliquer sur “Next >“.

Cliquez sur “Install“.

Cliquez sur “Finish“.

Si tout s’est bien passé, vous verrez, sur la GUI du collecteur dans l’onglet “Admin“, apparaître les log sources fraîchement ajoutées pour lesquelles il faut effectuer un déploiement pour finaliser l’installation et la collecte.

Une fois le déploiement effectué, pour vérifier que tout fonctionne vous pouvez aller dans l’onglet “Log Activity” et filtrer sur les log sources pour vérifier que tout est OK.

3. Surveillance Linux

Pour la partie Linux, nous allons utilisé l’outil rsyslog très utilisé dans l’univers UNIX pour le transfert de logs. Si vous utilisez un autre système, n’hésitez pas à le partager – j’utilise personnellement syslog-ng qui est nativement sur les NAS Synology, je vous montrerais d’ailleurs dans un prochain article la collecte personnalisée de ces types d’équipements.

Si l’utilitaire rsyslog n’est pas installé, il vous suffit tout simplement d’utiliser le gestionnaire de paquet de votre OS correspondant avec l’option d’installation pour le paquet “rsyslog“. Si ce dernier n’est pas trouvable ou que vous rencontrez une erreur, il est possible de vos repositories ne soient pas à jour, que vous n’ayez pas les droits pour installer un paquet… Je vous conseille de faire une petite recherche avec l’erreur correspondante dans ce cas et/ou de la partager dans la section de commentaires plus bas.

Une fois le paquet installé, vous pouvez valider le bon fonctionnement de rsyslog comme ceci :

debian@<hostname>:~$ systemctl status rsyslog.service
● rsyslog.service - System Logging Service
   Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2022-08-09 09:05:27 UTC; 8min ago
     Docs: man:rsyslogd(8)
           https://www.rsyslog.com/doc/
 Main PID: 14571 (rsyslogd)
    Tasks: 5 (limit: 2318)
   Memory: 1.1M
   CGroup: /system.slice/rsyslog.service
           └─14571 /usr/sbin/rsyslogd -n -iNONE

Aug 09 09:05:27 <hostname> systemd[1]: Starting System Logging Service...
Aug 09 09:05:27 <hostname> systemd[1]: Started System Logging Service.
Aug 09 09:05:27 <hostname> rsyslogd[14571]: imuxsock: Acquired UNIX socket '/run/systemd/journal/syslog' (fd 3) from systemd.  [v8.1901.0]
Aug 09 09:05:27 <hostname> rsyslogd[14571]:  [origin software="rsyslogd" swVersion="8.1901.0" x-pid="14571" x-info="https://www.rsyslog.com"] start

Si vous n’avez pas un statut “running“, alors il faut lancer le service – il est également possible que le service ne démarre pas dû à un problème dans le fichier de configuration mais dans ce cas cela veut dire que le paquet était préalablement installé et que vous avez déjà touché à la configuration. Il vous faut dans ce cas corriger l’erreur avec les messages d’erreur fournis.

Passons maintenant à la configuration, pour ce faire nous allons créer un fichier exprès pour avoir une arborescence plus propre.

debian@<hostname>:~$ touch /etc/rsyslog.d/qradar.conf
debian@<hostname>:~$ sudo chown root: /etc/rsyslog.d/qradar.conf
debian@<hostname>:~$ sudo chmod 644 /etc/rsyslog.d/qradar.conf

Ensuite, avant de mettre la ligne de configuration nécessaire, un peu de culture 😁 En effet, la granularité du transfert de logs est très pointue et il n’y a pas de “bonne configuration”. Les deux termes qu’il faut avoir en tête pour de bons débuts sont :

• Facility (selon RFC5424)
• Severity (selon RFC5424)

Le premier correspond grossièrement à la source du log, par exemple des logs venant du kernel ou du NTP. Pour la liste exhaustive je vous mets le tableau ci-dessous :

Pour la severity, c’est un peu plus intuitif et il s’agit donc littéralement de la sévérité de l’événement et nous avons les sévérités suivantes qui sont définies (toujours dans la même RFC).

Maintenant que nous savons tout cela, comment l’intégrer dans notre configuration ? Pour cela, rien de plus simple, il faut suivre le formalisme suivant :

# <facility>.<severity>	@@<IP QRadar>:<port>
# => envoie les logs de sévérité warning et supérieure venant du kernel vers l'IP 192.168.1.1 en UDP (1 seul '@') sur le port 514 (port pas défaut utilisé quand pas mentionné)
kernel.warn		@192.168.1.1
# => envoie les logs de toutes les sévérités venant des logs user vers l'IP 192.168.1.1 en TCP (2 '@' avant l'IP) sur le port 5140
user.*			@@192.168.1.1:5140
# => envoie les logs de toutes les sévérités venant des logs d'authentification vers l'IP 192.168.1.1 en TCP
authpriv.*		@@192.168.1.1

Dans notre cas, si nous souhaitons simplement superviser les logs d’authentification, qui sont, dans un premier temps le must have, il faut utiliser la dernière configuration dans les exemples ci-dessus.

Une fois que cette ligne est rajoutée à la configuration il suffit de redémarrer le service rsyslog.service pour que tout soit pris en compte.

Enfin côté collecteur QRadar, l’auto-détection va faire son travail et en fonction de la verbosité de votre machine, créer la log source plus ou moins rapidement. Néanmoins il est toujours possible de faire manuellement ou encore de modifier les paramètres d’auto-détection du log source type suivant “Linux OS” (à faire si vous maîtrisez déjà un petit peu cette partie de QRadar). Quand la log source est créée, vous aurez des logs similaires à ceux ci-dessous :

4. Surveillance serveur web (Apache2)

Pour conclure cet article, nous allons faire un tour du côté des serveurs web qui sont, pour la plupart, très exposés à l’internet du monde, ce qui en fait des cibles de choix pour établir un premier point d’entrée pour les attaquants. C’est donc pour cela qu’il est très important de les protéger au maximum de manière active (anti-DDOS, fail2ban…) mais aussi passive par le biais de règle de détection. Et pour que ces règles de détection fonctionnent, il nous faut des événements, ce sont ces événements qu’il va falloir collecter vers notre QRadar pour ensuite pouvoir créer des règles.

Dans le cas présent nous allons récupérer les événements d’un serveur Apache2 installé sur un Linux, ce qui représente un classique dans les petites infrastructures web. Pour ce faire, rien de plus simple, nous allons utiliser rsyslog, comme pour la partie précédente. En effet, cet utilitaire permet également de transférer les logs applicatifs pour peu de mettre la configuration adéquate.

Cette configuration se situe à 2 endroits :

1. Apache2 : il va falloir “dire” au serveur d’envoyer selon un certain format ses logs dans une des facilities (cf partie 3) disponible du système
2. Rsyslog : il va falloir configurer l’utilitaire pour transférer ce qui arrive de la facility choisie précédemment vers le collecteur QRadar

Pour le premier point, je me suis basé sur la documentation IBM que j’ai modifié quelque peu car elle n’était pas fonctionnelle en l’état. Ainsi, j’ai rajouté les 2 lignes suivantes dans les fichiers de configuration de vos différents “Virtual Host” à l’emplacement “/etc/apache2/sites-available/” :

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" apache_qradar
CustomLog "|$/bin/logger -t httpd -p local1.info" apache_qradar

Il faut bien que ces 2 lignes apparaissent dans le “<VirtualHost></VirtualHost>” pour toutes vos configurations, SSL inclus. Une fois que ces modifications ont été faites, vous pouvez redémarrer le service “Apache2” pour qu’elles soient prises en compte.

Enfin, dans un deuxième temps, il faut récupérer les logs envoyés vers la facility “local1” dans notre cas. Pour arriver à nos fins, nous allons procéder comme dans la partie 3 et donc rajouter à notre configuration “/etc/rsyslog.d/qradar.conf” la ligne suivante :

local1.info             @@192.168.1.1

Dans le cas ci-dessus, il vous faudra bien entendu changer l’IP avec l’IP du collecteur QRadar ou de l’équipement qui reçoit les logs et, éventuellement, rajouter le port de réception des logs s’il diffère du port standard, à savoir “514“.

Quand la configuration est bonne, il ne reste plus qu’à redémarrer le service “rsyslog.service” pour que tout soit en ordre et comme nous pouvons le voir sur la GUI QRadar en filtrant sur la log source, tout est OK :

5. Conclusion

Tout est bon, vous avez désormais sous votre surveillance vos équipements préférés.

6. Bibliographie

• Documentation sur le LogFormat
• Documentation IBM sur la configuration Apache2 à avoir pour la collecte et le formatage des logs
• RFC5424