File integrity: inotify vs auditd

809 views
Skip to first unread message

杨海

unread,
Sep 2, 2019, 11:22:20 PM9/2/19
to wazuh
Hi

There seems a compiler option to use inotify or auditd to monitor the desired folder. I understand auditd has substantial overhead to SYSCALL usec/call, and this is why read/write are not included and wazuh tried to use open instead to judge the file is changed or not roughly. By default, inotify is used. Would you mind tell me more about it and any restriction of inotify? for example, it does not report which user/process is manipulating the file.

Regards
Hai

Juan Pablo Saez

unread,
Sep 3, 2019, 5:31:44 AM9/3/19
to Wazuh mailing list
Hi,

There seems a compiler option to use inotify or auditd to monitor the desired folder.

I assume you are referring to our makefile USE_INOTIFY=no flag:

This flag is used on FreeBSD systems to enable Realtime or Whodata monitoring. As there is no Inotify for FreeBSD, with the USE_INOTIFY=yes flag, Inotify is set up as a thin wrapper around Kqueue directory watcher(Kqueue is similar to Inotify). Without this flag, FreeBSD systems can't use Realtime or Whodata monitoring.


I understand auditd has substantial overhead to SYSCALL usec/call, and this is why read/write are not included and wazuh tried to use open instead to judge the file is changed or not roughly. By default, inotify is used. Would you mind tell me more about it and any restriction of inotify? 

Let's see how Wazuh FIM modes use Inotify and Auditd:
  • Realtime 
    • Inotify
  • Whodata
    • Inotify + Auditd 


When using Realtime, inotify watchers are placed on the selected directory and its subdirectories. The further inotify events are monitored with Realtime:
#define REALTIME_MONITOR_FLAGS  IN_MODIFY|IN_ATTRIB|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF
You can see it in the code here


READ      Not monitored
WRITE    Monitored with IN_MODIFY 
OPEN     Not monitored 


In the further example, note who Inotify triggers when creating, modifying and deleting a file on a monitored directory. These outputs are the same as those evaluated by Wazuh.

5.png





On the other hand, Whodata is also based on inotify watchers. Besides using inotify,  Auditd logs are sent to Wazuh manager via socket and the information obtained with inotify is enriched with the interpretation of the auditd logs.




So, to sum up:
  1. USE_INOTIFY flag is only meaningful in FreeBSD systems.
  2. Both FIM realtime and whodata modes use inotify tools.
  3. You can see which inotify events are monitored by FIM here.

I hope it helps. Please let me know if you need to go into any detail.

Best regards, Juan Pablo Sáez

杨海

unread,
Sep 3, 2019, 7:45:51 AM9/3/19
to Juan Pablo Saez, Wazuh mailing list
Thanks Juan. 

"Besides using inotify,  Auditd logs are sent to Wazuh manager via socket and the information obtained with inotify is enriched with the interpretation of the auditd logs."
I tried "top |grep audit" when running wazuh agent on Linux, and there is no appearance of any audit related process - auditd, audispd, or kaudit. And from syscheckd_audit.c, it looks auditd is doing the same thing as inotify. Any tips to enable auditd in wazuh agent?

Regards
Hai
 
 
------------------ Original ------------------
From:  "Juan Pablo Saez"<jp....@wazuh.com>;
Date:  Tue, Sep 3, 2019 05:31 PM
To:  "Wazuh mailing list"<wa...@googlegroups.com>;
Subject:  Re: File integrity: inotify vs auditd
 
Hi,

There seems a compiler option to use inotify or auditd to monitor the desired folder.

I assume you are referring to our makefile USE_INOTIFY=no flag:

This flag is used on FreeBSD systems to enable Realtime or Whodata monitoring. As there is no Inotify for FreeBSD, with the USE_INOTIFY=yes flag, Inotify is set up as a thin wrapper around Kqueue directory watcher(Kqueue is similar to Inotify). Without this flag, FreeBSD systems can't use Realtime or Whodata monitoring.


I understand auditd has substantial overhead to SYSCALL usec/call, and this is why read/write are not included and wazuh tried to use open instead to judge the file is changed or not roughly. By default, inotify is used. Would you mind tell me more about it and any restriction of inotify? 

Let's see how Wazuh FIM modes use Inotify and Auditd:
  • Realtime 
    • Inotify
  • Whodata
    • Inotify + Auditd 


When using Realtime, inotify watchers are placed on the selected directory and its subdirectories. The further inotify events are monitored with Realtime:
#define REALTIME_MONITOR_FLAGS  IN_MODIFY|IN_ATTRIB|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF
You can see it in the code here


READ      Not monitored
WRITE    Monitored with IN_MODIFY 
OPEN     Not monitored 


In the further example, note who Inotify triggers when creating, modifying and deleting a file on a monitored directory. These outputs are the same as those evaluated by Wazuh.





On the other hand, Whodata is also based on inotify watchers. Besides using inotify,  Auditd logs are sent to Wazuh manager via socket and the information obtained with inotify is enriched with the interpretation of the auditd logs.




So, to sum up:
  1. USE_INOTIFY flag is only meaningful in FreeBSD systems.
  2. Both FIM realtime and whodata modes use inotify tools.
  3. You can see which inotify events are monitored by FIM here.

I hope it helps. Please let me know if you need to go into any detail.

Best regards, Juan Pablo Sáez



El martes, 3 de septiembre de 2019, 5:22:20 (UTC+2), 杨海 escribió:
Hi

There seems a compiler option to use inotify or auditd to monitor the desired folder. I understand auditd has substantial overhead to SYSCALL usec/call, and this is why read/write are not included and wazuh tried to use open instead to judge the file is changed or not roughly. By default, inotify is used. Would you mind tell me more about it and any restriction of inotify? for example, it does not report which user/process is manipulating the file.

Regards
Hai

--
You received this message because you are subscribed to the Google Groups "Wazuh mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/6835dc7d-7813-4bd9-bd05-5802736ea892%40googlegroups.com.
6676B1FE@4749E976.64526E5D

Juan Pablo Saez

unread,
Sep 3, 2019, 9:44:47 AM9/3/19
to Wazuh mailing list
Hi again Hai,


I tried "top |grep audit" when running wazuh agent on Linux, and there is no appearance of any audit related process - auditd, audispd, or kaudit.

  • The who-data monitoring functionality uses the Linux Audit subsystem to get the information about who made the changes in a monitored directory. Firstly we need to check if the Audit daemon is installed in our system. # auditctl -v should be enough: i.e:
    [root@workerCentos test_wazuh]# auditctl -v
    auditctl version 2.8.4
  • # top | grep audit will never work as top is an interactive tool, and it will be eternally stuck awaiting input. You can try # top | grep crond or # top | grep whatever, it won't work. To use the pipe operator |, you should use ps aux. So # ps aux | grep audit is the command you are looking for. On CentOS 7 this is my output for # ps aux | grep audit (i recommend this command to look for audit instead of top):
    [root@workerCentos test_wazuh]# ps aux | grep audit
    root       110  0.0  0.0      0     0 ?        S    12:46   0:00 [kauditd]
    root     31019  0.0  0.0  55520   908 ?        S<sl 13:06   0:00 /sbin/auditd
    root     31436  0.0  0.0 112716   988 pts/0    R+   13:23   0:00 grep --color=auto audit

  • When you have made sure that auditd is installed on your system, you can enable the Whodata syscheck feature for some directory the ossec.conf configuration file. i.e:
    <!-- File integrity monitoring -->
    <syscheck>
    <disabled>no</disabled>

    <!-- Frequency that syscheck is executed default every 12 hours -->
    <frequency>43200</frequency>

    <scan_on_start>yes</scan_on_start>

    <!-- Directories to check  (perform all possible verifications) -->
    <directories check_all="yes" whodata="yes">/etc/test_wazuh</directories>  <!--This line sets the /etc/test_wazuh directory to be monitored with Whodata,using inotify + auditd-->

  • You can add the desired directories with the line above: <directories check_all="yes" whodata="yes">/path/to/directory</directories>


And from syscheckd_audit.c, it looks auditd is doing the same thing as inotify.

  • Monitoring a directory with Realtime(inotify): <directories check_all="yes" realtime="yes">/path/to/directory</directories>
  • Monitoring a directory with Whodata(inotify + auditd): <directories check_all="yes" whodata="yes">/path/to/directory</directories>
To see the difference between realtime and whodata, you can see that in the whodata code the socket that auditd is going to use to send the events is initialized



Please, let me know if it helps. Ask everything you need!

Best regards, Juan Pablo Sáez


To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages