Aller au contenu

Wazuh - Surveillance des system calls (auditd)

Les "system calls" (appels système) sous Linux sont des interfaces de programmation qui permettent aux logiciels d'interagir avec l'OS.

Ils servent de pont entre l'espace utilisateur et l'espace noyau du système d'exploitation.

Quand un logiciel a besoin d'effectuer une opération qui nécessite des privilèges élevés, comme la lecture d'un fichier ou l'allocation de mémoire, il fait appel à ces fonctions systèmes.

Les appels système sont donc cruciaux pour la gestion des ressources, la communication entre processus, la gestion des fichiers, et d'autres fonctions basiques du système. Ils sont implémentés dans le noyau Linux et accessibles aux programmes via une interface de programmation standard.

Et plus concrètement ? Par l'exemple.

  1. Commande lancée par l'utilisateur : l'utilisateur lance une commande comme "cat document.txt" dans le terminal.
  2. Invocation de l'appel système : le programme "cat" utilise un appel système (par exemple, open()) pour ouvrir le fichier.
  3. Passage en mode noyau : le contrôle passe au noyau pour exécuter open().
  4. Ouverture du fichier : le noyau ouvre le fichier et renvoie un descripteur de fichier au programme.
  5. Lecture du fichier : "cat" utilise un autre appel système (par exemple, read()) pour lire le contenu du fichier. Le contrôle passe à nouveau au noyau pour lire les données.
  6. Affichage du contenu : après la lecture, le contenu est renvoyé au programme "cat", qui l'affiche sur le terminal.
  7. Fermeture du fichier : enfin, "cat" utilise close() pour fermer le fichier, un autre appel système qui passe le contrôle au noyau pour libérer le descripteur de fichier.

Dans cet exemple, chaque interaction avec le fichier (ouverture, lecture, fermeture) implique un appel système, car ces opérations nécessitent des privilèges d'accès au système de fichiers gérés par le noyau.

Pourquoi les surveiller ?

  1. Détection des comportements anormaux : les appels système peuvent révéler des activités suspectes ou anormales, comme l'accès non autorisé aux fichiers ou l'exécution inhabituelle de processus. en les surveillant, il est possible de détecter des signes de compromission ou de malware.
  2. Contrôle d'accès et audit : surveiller les appels système aide à contrôler l'accès aux ressources critiques du système. cela permet également d'auditer les actions effectuées, essentiel pour la conformité réglementaire et l'analyse forensique en cas d'incident de sécurité.
  3. Prévention des vulnérabilités : la surveillance peut identifier l'exploitation de vulnérabilités dans le système, comme l'escalade des privilèges ou les débordements de tampon, souvent initiés par des appels système malveillants.
  4. Réponse en temps réel : en détectant rapidement des activités suspectes via les appels système, il est possible de réagir immédiatement pour atténuer les menaces.
  5. Compréhension profonde des activités système : les appels système reflètent les interactions fondamentales entre les applications et le noyau. leur surveillance offre une vision détaillée de ce qui se passe dans le système.

Comment activer la surveillance ?

Il faut enregistrer toutes les actions souhaitées dans un fichier de log, auditd répond à ce besoin.

Voici 3 types de règles auditd :

  • Règles de contrôle : elles permettent de modifier le comportement et la configuration par défaut du système d'Audit Linux :
auditctl -b 8192
# définit la taille du tampon à 8192 événements.
  • Règles de système de fichiers : ces règles suivent l'accès aux fichiers et aux répertoires :
auditctl -w /etc/ssh/sshd_config -p rwa -k monitoring_sshd_config
# -w pour indiquer le chemin du fichier à surveiller
# -p pour surveiller lecture (r), écriture (w), modification (a)
# -k pour l'ajout d'une clef, afin que l'action puisse être identifiée plus facilement
  • Règles d'appel système : ces règles enregistrent les appels système de programmes spécifiques :
auditctl -a always,exit -F arch=b64 -S open,close -F pid=1234 -k monitoring_open_close
# -a always,exit # pour toujours surveiller les évènements en état exit
# -S open,close pour surveiller les appels système open et close
# -F pid=1234 pour le pid du processus à surveiller
# -k pour l'ajout d'une clef, afin que l'action puisse être identifiée plus facilement

Wazuh utilise la valeur indiquée dans la clef (-k) afin d'identifier les évènements du log auditd. Pour faire correspondre les keys avec une valeur, wazuh maintient une base CDB :

# cat /var/ossec/etc/lists/audit-keys
audit-wazuh-w:write
audit-wazuh-r:read
audit-wazuh-a:attribute
audit-wazuh-x:execute
audit-wazuh-c:command

Exemple (Ubuntu 22)

Sur le wazuh agent, il faut indiquer à wazuh le log auditd à surveiller dans /var/ossec/etc/ossec.conf :

<localfile>
  <log_format>audit</log_format>
  <location>/var/log/audit/audit.log</location>
</localfile>

# systemctl restart wazuh-agent

Puis nous allons créer 3 règles :

echo "-w /etc/ssh/sshd_config -p w -k audit-wazuh-w" >> /etc/audit/rules.d/audit.rules
echo "-w /etc/ssh/sshd_config -p r -k audit-wazuh-r" >> /etc/audit/rules.d/audit.rules
echo "-w /etc/ssh/sshd_config -p a -k audit-wazuh-a" >> /etc/audit/rules.d/audit.rules

# systemctl restart auditd

# auditctl -l 
-w /etc/ssh/sshd_config -p w -k audit-wazuh-w
-w /etc/ssh/sshd_config -p r -k audit-wazuh-r
-w /etc/ssh/sshd_config -p a -k audit-wazuh-a

Puis on réalise les actions w,r,a pour générer des logs :

echo '##' >> "/etc/ssh/sshd_config"
# ausearch -k audit-wazuh-w
----
time->Sat Jan  6 16:51:47 2024
type=PROCTITLE msg=audit(1704559907.004:712): proctitle="/bin/bash"
type=PATH msg=audit(1704559907.004:712): item=1 name="/etc/ssh/sshd_config" inode=35740 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=PATH msg=audit(1704559907.004:712): item=0 name="/etc/ssh/" inode=1303 dev=08:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1704559907.004:712): cwd="/home/vagrant"
type=SYSCALL msg=audit(1704559907.004:712): arch=c000003e syscall=257 success=yes exit=3 a0=ffffff9c a1=55e1fdc7ae10 a2=441 a3=1b6 items=2 ppid=51863 pid=51864 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=5 comm="bash" exe="/usr/bin/bash" subj=unconfined key="audit-wazuh-w"
cat /etc/ssh/sshd_config
# ausearch -k audit-wazuh-r
----
time->Sat Jan  6 16:52:08 2024
type=PROCTITLE msg=audit(1704559928.019:713): proctitle=636174002F6574632F7373682F737368645F636F6E666967
type=PATH msg=audit(1704559928.019:713): item=0 name="/etc/ssh/sshd_config" inode=35740 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1704559928.019:713): cwd="/home/vagrant"
type=SYSCALL msg=audit(1704559928.019:713): arch=c000003e syscall=257 success=yes exit=3 a0=ffffff9c a1=7ffe032ba884 a2=0 a3=0 items=1 ppid=51864 pid=53778 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=5 comm="cat" exe="/usr/bin/cat" subj=unconfined key="audit-wazuh-r"
chmod +x /etc/ssh/sshd_config
# ausearch -k audit-wazuh-a
----
time->Sat Jan  6 16:52:28 2024
type=PROCTITLE msg=audit(1704559948.386:714): proctitle=63686D6F64002B78002F6574632F7373682F737368645F636F6E666967
type=PATH msg=audit(1704559948.386:714): item=0 name="/etc/ssh/sshd_config" inode=35740 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1704559948.386:714): cwd="/home/vagrant"
type=SYSCALL msg=audit(1704559948.386:714): arch=c000003e syscall=268 success=yes exit=0 a0=ffffff9c a1=5616fb5cd1b0 a2=1ed a3=0 items=1 ppid=51864 pid=53781 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=5 comm="chmod" exe="/usr/bin/chmod" subj=unconfined key="audit-wazuh-a"

Puis voici les logs remontés sur le dashboard : type:video

Aller plus loin