ossec.conf and ossec.conf on endpoints

[Fl Passelerg]

Hello Wazuh Team 

 I have a synchronization problem between ossec.conf of my manager and all ossec.conf of all my endpoints. 

I can't find what I add or modify in the ossec.conf on the web manager configuration page in the agents' ossec.conf and I don't understand why? 

Example: when I add a virustotal integration on ossec.conf, it is not automatically transmitted to ossec.conf on my endpoint? and I have to manually edit and add the same integration on every ossec.conf on my endpoint if I want to use virustotal integration. 

is this normal? 

until i did that virustotal check was ok on my endpoint. 

I have the same problem with rootckeck ou syscked configuration

How to synchronize the agents ?

Can you help me understand my mistake?

Thansk 

Florence

[Gabriel Emanuel Valenzuela]

Hi Florence ! How are you ?

Probably the best option for synchronizing the configuration of the agents is to use the centralized configuration.

Agents can be configured remotely by using the agent.conf file. The following capabilities can be configured remotely:

File Integrity monitoring (syscheck)

Rootkit detection (rootcheck)
Log data collection (localfile)
Security policy monitoring (wodle name="open-scap", wodle name="cis-cat")
Remote commands (wodle name="command")
Labels for agent alerts (labels)
Security Configuration Assessment (sca)
System inventory (syscollector)
Avoid events flooding (client_buffer)
Configure osquery wodle (wodle name="osquery")

force_reconnect_interval setting (client)

When using the centralized configuration, it is important to keep in mind that it applies to a particular group of agents, all agents by default are in the default group.
But you can create groups by operating system and thus differentiate the configurations that vary from one operating system to another.

You can find a step by step example in our documentation, centralized configuration process.

Where you can also find more information and considerations to take into account.

If you need anything more, please don't dub to ask. We're here to help :)

Have a nice day!

[Gabriel Emanuel Valenzuela]

An additional consideration, that there are configurations that are only applied in the manager, and if they were applied in the agent it would fail. 

[Fl Passelerg]

ok, thanck you very much. !!! 

I put my virustotal configuration in each group et all is ok now !! :-)

Another point : I'm trying to use whodata auditing system (on each group ?)  I want to activate the auditing system for all my endpoint

but :

only the wazuh-manager has events in the system auditing module, and without whodata information..? why ?

none of my endpoint has events in the system auditing module.

example in my group "linux" configuration

    <rootcheck>
        <check_unixaudit>yes</check_unixaudit> <!-- FB -->
    </rootcheck>
    <syscheck>
        <directories check_all="yes" realtime="yes">/root</directories>
        <directories check_all="yes" whodata="yes">/home/kali/Documents</directories>
        <directories check_all="yes" whodata="yes">/etc</directories>
    </syscheck>

but, when I see my configuration group on the web, I have this message : "the system is not available" et if I try to modifie a file in the /home/kali/Documents directorie, I have events on the FIM module but without whodata information

Can you help me ?

thanks !

Florence

[Gabriel Emanuel Valenzuela]

Hi Florence ! How are you ?

Not a problem, that’s why I’m here =) 

Possible this issue could be because it's necessary follow a few steps before configure audit in Linux.

The who-data monitoring functionality uses the Linux Audit subsystem to get the information about who made the changes in a monitored directory. These changes produce audit events that are processed by syscheck and reported to the manager. Firstly we need to check if the Audit daemon is installed in our system and then you enable it in the ossec.conf.

If you are using debian base OS, you need to execute: # apt-get install auditd

Once this configuration is added, we need to restart Wazuh to apply the changes.

We can check if the Audit rule for monitoring the selected folder is applied. To check that, we need to execute the following command:

# auditctl -l | grep wazuh_fim

and check in the command output that the rule was added:

# auditctl -w /etc -p wa -k wazuh_fim

When the agent is stopped, we can use the same command to check that the added rule was successfully removed.

You can find more infomation and examples in our documentation, about configuring who-data monitoring and Auditing who-data (Inside you will find the know-how for Linux and Windows)

If you have any question, please don't dubt in ask.

Have a nice day =)

[Fl Passelerg]

Hello Gabriel :-) are you a french boy..? because my english is so bad..so sorry..it's hard for me to read and write in english!! but you understand me :-D !! 

 actually i did everything you mention and i already checked the auditd 

You can see the result on the picture 

it's strange...

Florence

[Fl Passelerg]

I looked at the logs (DEBUG mode) :

Jan 12, 2023 @ 18:28:51.000 wazuh-syscheckd DEBUG (6275): Reloading Audit rules. 

Jan 12, 2023 @ 18:28:51.000 wazuh-syscheckd DEBUG (6926): Unable to add audit rule for '/home/kali/Documents' 

Jan 12, 2023 @ 18:28:51.000 wazuh-syscheckd DEBUG (6926): Unable to add audit rule for 'C:\Windows\System32\drivers\etc' 

Jan 12, 2023 @ 18:28:51.000 wazuh-syscheckd DEBUG (6276): Audit rules reloaded. Rules loaded: 0 

Jan 12, 2023 @ 18:29:21.000 wazuh-syscheckd DEBUG (6275): Reloading Audit rules. 

it sems that the rules are not available... ?