X·STAZE

Bonjour à tous, dans cet article nous allons voir comment superviser les logs réseaux du logiciel présent sur le distribution Linux, à savoir “iptables”. En effet, il est très important d’avoir une visibilité sur les flux réseaux qui arrivent et qui sortent de vos équipements. D’un point de vue sécurité, cela permet d’identifier des communications vers des serveurs avec une mauvaise réputation ou encore d’être en mesure de détecter une machine qui pourrait scanner votre serveur. D’un autre côté, cela peut également servir à des fins de débug.

Vous allez au travers de cet article apprendre comment mettre en place cette collecte mais également comme faire en sorte que ce qui arrive dans QRadar soit correctement compris et que cela puisse matcher avec vos règles de détection.

2. Mise en place côté Linux

a. Modification des règles iptables

Premièrement il faut que nous configurions “iptables” pour lui demander d’enregistrer certains flux. En effet, nous n’allons pas prendre tous les flux dans cet exemple pour que cela soit plus lisible de par la grosse volumétrie d’échanges réseaux qu’il peut y avoir même pour des équipements de test.

Par exemple, si je souhaite récupérer toutes les requêtes DNS, j’effectue la commande suivante (avec un utilisateur ayant les droits suffisants) :

# iptables -A OUTPUT -p udp --dport 53 -j LOG --log-level info

En faisant cela, et après avoir redémarré “iptables” vous devriez voir des événements en affichant le fichier de log “kern.log”, comme ceci :

On fait une demande de résolution pour “google.fr”

On affiche en temps réel le fichier “/var/log/kern.log”

Attention, il est important que la règle “iptables” soit située avant la règle que l’on souhaite superviser. Si ce n’est pas le cas, les événements ne pourront pas être enregistrés car l’action du pare-feu aura déjà été prise.

Nous avons donc bien les logs des requêtes DNS loguées. Maintenant, avant de configurer la partie rsyslog qui va permettre au serveur d’envoyer ces événements vers le QRadar, nous allons rajouter un élément à notre log pour pouvoir attribuer les événements côté QRadar plus facilement.

Pour ce faire, nous allons utiliser l’option “–log-prefix” de l’utilitaire “iptables” qui permet, comme son nom l’indique, de rajouter un élément statique dans le log comme ceci :

# iptables -A OUTPUT -p udp --dport 53 -j LOG --log-level info --log-prefix "Q1Target=fw_accept "

Et si vous souhaitez avoir les flux qui sont :

• deny
• reject
• drop

Il faut simplement changer la valeur avec le mot-clé correspondant.

Enfin, pour la partie rsyslog, il suffit de rajouter un fichier “qradar-iptable.conf” dans le dossier “/etc/rsyslog.d/” comprenant la ligne suivante :

kern.info        @@<QRADAR_FQDN>:514

Pour que le changement s’applique, il faut effectuer un redémarrage de rsyslog.

b. Vérification des logs

Pour passer à la dernière partie côté QRadar, il faut s’assurer que nous avons bien les logs qui arrivent sur notre QRadar. Pour ce faire, il y a plusieurs solutions, soit en ligne de commande avec un “tcpdump”, soit en affichant les logs qu’il y a dans la log source “SIM Generic” de votre QRadar. Comme nous avons déjà discuté de la seconde dans un précédent article, nous allons utiliser “tcpdump” ici.

Il faut vous connecter à la console QRadar en ligne de commande et effectuer la commande suivante en prenant soin de remplacer la valeur “<CLIENT_IP>” par l’IP de la machine qui envoie les logs vers QRadar :

# tcpdump -i any 'src host <CLIENT_IP> and dst port 514' -A

Une fois que la commande est lancée, vous pouvez tout simplement effectuer une requête DNS sur votre machine cliente et observer un comportement similaire à celui ci-dessous :

On voit ici les 3 paquets, surlignés en vert, qui correspondent à :

• l’adresse IPv4
• l’adresse IPv6
• l’adresse du serveur mail

que la commande “host” m’a retourné.

3. Mise en place côté QRadar

Nous avons vu juste avant que nous récupérions bien les logs dans QRadar. Malheureusement, le format de ces logs n’est pas compris par défaut par QRadar, il faut donc passer par un DSM Custom. Si vous souhaitez avoir plus de détails sur cette partie là je vous renvoie vers cette article : Comment surveiller vos équipements #3 – DSM personnalisé.

J’ai effectué ce travail pour vous et vous retrouverez le fichier à installer sur votre instance ici. Une fois que vous l’avez installé, il faut configurer l’auto-détection de ce type de log source (décrit dans la partie 4) et au bout de 25 logs vous devriez avoir votre log source créée. Ce phénomène est encore plus facile à comprendre quand on va dans le “Log Activity” de QRadar et que l’on filtre sur l’IP de la machine à superviser (cela implique qu’il n’y ait pas d’autre collectes sur cette machine), on obtient :

Avant la ligne rouge, les événements arrivaient dans “SIM Generic” car QRadar ne trouvait pas de log source qui correspondait à l’identifiant présent dans les logs. Après la ligne rouge, et parce que précédemment QRadar a réussi à effectuer le parsing sur un nombre suffisant de logs, la log source est créée et les logs arrivent désormais dans cette dernière.

4. Conclusion

Vous êtes maintenant en mesure de superviser les logs réseaux sur vos différents équipements Linux. Comme dit en introduction c’est une partie très importante à surveiller dans un SI et très révélateur de comportements anormaux sur un SI.

Nous avons vu une petite portion de ce qu’il était possible de configurer sur “iptables”, libre à vous d’étendre ou de restreindre cette configuration.

N’hésitez pas à me faire part de vos remarques et avis sur ce sujet.

5. Bibliographie

• https://serverfault.com/questions/353130/iptables-and-multiple-ports
• https://www.ibm.com/docs/en/dsm?topic=iptables-configuring#t_dsm_guide_linux_iptables_cfg
• https://www.ibm.com/support/pages/qradar-how-change-or-customize-log-source-time
• https://www.malekal.com/configurer-log-iptables/
• https://github.com/staze0/QRadar/blob/main/DSM%20Custom/Custom%20Linux%20iptables.zip