Wazuh 3.8 Kibana not show alert about files added.

[Stefano Serano]

Hi.

I've configured Wazuh agent 3.8 to monitor a specific folder using this confguration:

<directories check_all="yes" realtime="yes" whodata="yes">pathtofolder</directories>

I've followed your documentation from this link:

https://documentation.wazuh.com/current/user-manual/capabilities/file-integrity/fim-configuration.html

and i've noticed 2 things:

1)Agent configuration said that real time monitoring was not enabled fot this folder until not added realtime="yes" to the configuration.

2)on kibana i see in real time altert about deleted files, but not about added or modified files.

I've missing something?

Thanks for your help.

[daniel...@wazuh.com]

Hi Stefano Serano,
Your configuration looks good, keep in mind you don't need to use realtime when you are using whodata because who data makes realtime scanning already.
With the configuration you are using you should be able to see the alerts you say.

They should look something like:

 

What are the OS and wazuh version (3.8.0 , 3.8.1 , 3.8.2) you are using?
Best Regards.

[Stefano Serano]

Hi Daniel, thanls for your reply.

I made some tests here results and configuration:

WAZUH VERSION:

Wazuh 3.8.2 deployed

CLIENT CONFIGURATION:

Server Version: Server Windows 2008R2

Whodata Configuration: <directories check_all="yes" realtime="yes">f:\share\dati</directories>

RESULTS: No data are displayed on Kibana, attached to this message you cand fins logs.

CLIENT CONFIGURATION

Server Version:: Server Windows 2003

Here the log said:

2019/03/11 09:56:54 wazuh-modulesd:syscollector: WARNING: Network and opened ports scans are incompatible with versions older than Vista.

2019/03/11 09:56:54 wazuh-modulesd:syscollector: INFO: Starting evaluation.

2019/03/11 09:56:54 wazuh-modulesd:syscollector: ERROR: At sys_hw_windows(): Unable to load syscollector_win_ext.dll: The specified procedure could not be found. (127).

i've foud this about it:

https://github.com/wazuh/wazuh/pull/2326/files/ce17d5810c6d6c635821d89c045b0352d9c427d1#diff-74a40b33660b026386f57bc9a3889073

There is a solution or i need to wait for a new release?

Have a nice day

[Stefano Serano]

**UPDATE**

Maybe i Found the problem about Server 2008R2, Local audit policy are resetted after gpupdate, but i don't know why.

Thank anyway

Il giorno venerdì 8 marzo 2019 14:02:25 UTC+1, daniel...@wazuh.com ha scritto:

[daniel...@wazuh.com]

Hi Stefano,

The configuration you are giving me should be working fine.
What are you doing to generate the alerts you want to see in Kibana?
You should be getting alerts when you create, edit or delete a file in the folder C:\share\dati or any folder inside /dati
Can you send me your ossec.conf in order to check if there is something wrong?
You may check this link to read about the FIM behaviour in Wazuh and how to configure it:
https://documentation.wazuh.com/current/user-manual/capabilities/file-integrity/fim-configuration.html

Best Regards.

[daniel...@wazuh.com]

Hi Stefano,

I've checked your configuration and logs and I can clearly see the problem, when FIM is used to monitor files in real-time (Who-data uses real-time scanning too) it's necessary to specify the folders you want to check thinking at the number of files they will store.
Real-time monitoring uses the machine's hardware so, if you try to monitor an entire disk (your case) it will probably overload the machine because of his size.

Looking at your case you should probably think on how to change the following line in the ossec.conf file:

<directories check_all="yes" whodata="yes">D:</directories>

In the logs we can see errors with the format:

2019/03/15 10:03:22 ossec-agent: ERROR: It was not possible to extract the permissions of 'AFILEYOUARETRYINGTOMONITOR'. Error: -3.

Where the agent doesn't have permissions over the file you are trying to monitor, it doesn't stop the agent but the file won't be monitored.

Hope it helps.

On Fri, Mar 15, 2019 at 11:58 AM Stefano Serano <serano...@gmail.com> wrote:

Hi Daniel.

Thanks again for your support. I've found the problem by myself: windows logs was full and wasn't deleted automatically.

Anyway i've another problem, another agent start the monitoring check for a couple of hour then stop working.

attach to this mail you can find logs and configuration.

Thank again.

--
You received this message because you are subscribed to a topic in the Google Groups "Wazuh mailing list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wazuh/xw50uEh8oQo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wazuh+unsubscribe@googlegroups.com.
To post to this group, send email to wa...@googlegroups.com.
Visit this group at https://groups.google.com/group/wazuh.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/d586f5cb-973f-452e-b8ca-34238d5896fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Stefano Serano]

Many thanks Daniel. I'll try to configure single folders, the is a way to get whodata info using a periodic scan?

Have a nice day

To unsubscribe from this group and all its topics, send an email to wazuh+un...@googlegroups.com.

To post to this group, send email to wa...@googlegroups.com.
Visit this group at https://groups.google.com/group/wazuh.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/d586f5cb-973f-452e-b8ca-34238d5896fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to a topic in the Google Groups "Wazuh mailing list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wazuh/xw50uEh8oQo/unsubscribe.

To unsubscribe from this group and all its topics, send an email to wazuh+un...@googlegroups.com.

To post to this group, send email to wa...@googlegroups.com.
Visit this group at https://groups.google.com/group/wazuh.

To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/3bb262f4-5591-4e65-87d4-a75578600f72%40googlegroups.com.

[daniel...@wazuh.com]

Hi Stefano,
Unfortunately, whodata option is only available as a realtime feature.
We are open to feedback from the community. If you think this would be a valuable addition to Wazuh, please don't hesitate to create an issue in our public repository: https://github.com/wazuh/wazuh
Regards.

[daniel...@wazuh.com]

Hi Stefano,

Where are you looking for the alerts? Wazuh stores the alerts in the files:

/var/ossec/log/alerts/alerts.log

/var/ossec/log/alerts/alerts.json

The ossec.log you shared with me won't show you the alerts which the agents could send to the manager.
In order to see if alerts are coming look at the files mentioned before in the manager or set a filter in Kibana to see just the syscheck alerts:

Hope it helps.

On Mon, Mar 18, 2019 at 3:25 PM Stefano Serano <serano...@gmail.com> wrote:

Hi Daniel.

I hope to bore you for the last time.

i've setted up a path to folder and no to disk for whodata logging, all works fine until 1:30 pm, when logs stopped to appear in console.

Event viewer on the machine still generate log, wazuh is up and running, but no log on console. attached to this mail you can find ossec configuration and console.

Have a nice day.

Il giorno lun 18 mar 2019 alle ore 14:48 Stefano Serano <serano...@gmail.com> ha scritto:

Hi Daniel.

I hope to bore you for the last time.

i've setted up a path to folder and no to disk for whodata logging, all works fine until 1:30 pm, when logs stopped to appear in console.

Event viewer on the machine still generate log, wazuh is up and running, but no log on cosole. attached to this mail you can find ossec configuration and console.

Have a nice day.

To unsubscribe from this group and all its topics, send an email to wazuh+unsubscribe@googlegroups.com.

To post to this group, send email to wa...@googlegroups.com.
Visit this group at https://groups.google.com/group/wazuh.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/d586f5cb-973f-452e-b8ca-34238d5896fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Wazuh mailing list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wazuh/xw50uEh8oQo/unsubscribe.

To unsubscribe from this group and all its topics, send an email to wazuh+unsubscribe@googlegroups.com.

[daniel...@wazuh.com]

Hi Stefano,

The problem could be you are trying to monitor a folder where the user used to install wazuh doesn't have permissions.
I can see it in the file ossec.log you shared with me where from the line 116 the messages are:

2019/03/15 10:31:30 ossec-agent: ERROR: It was not possible to extract the permissions of 'PATH'. Error: -3.

I can see more than 10000 lines with that kind of error. I think you don't have permissions in the entire directory tree.
Are you creating/deleting the file in the folder where these errors are being received?
Try to look at the permissions in the folder with the user where you are using wazuh to know if you can access the files in the folder.

Best regards

On Wed, Mar 20, 2019 at 10:23 AM Stefano Serano <serano...@gmail.com> wrote:

Hi Daniel.

I'm receiving Logs from Agent, but not the logs about files added/delete/modified. 

I make an example:

I Can see in Windows Event Viewer(Server windows 2008 R2) a lot of events 4663(i checked few minutess ago, 10:15 AM), but on wazuh i have no alert, last was at 9.28 AM about a file added to the system.

Even into:

/var/ossec/log/alerts/alerts.log

/var/ossec/log/alerts/alerts.json

i can't see other logs about files added, deleted, modified.

On the system is installed Kaspesky Security 10(just in case you need to know).

Let me know if i can do something to figured it out.

Have a nice Day.

To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/ad14d90c-a2b4-48e8-a560-8d56607c2fe2%40googlegroups.com.

[daniel...@wazuh.com]

Hello Stefano,

I've tested the situation you describe and I can confirm you that folders with a character "à" in the name won't be monitored.
It was a known issue fixed in 3.9 with this PR:
https://github.com/wazuh/wazuh/pull/2416
But the rests of directories should be monitored normally, as I said, in your log, I can see tons of permissions errors and that could be the reason of your issue.
You may check the permissions needed to read the folders you are trying to monitor and you don't get info from.

Regards.

On Fri, Mar 22, 2019 at 3:22 PM Stefano Serano <serano...@gmail.com> wrote:

Hi Daniel.

I've probably figured out. Our IT Costumed added a lot of path to be monitored, one of them had ad "à" font inside the pat, this cause the crash of whodata for all the path.

I'll let you know if is really solved in the next days.

Have a nice day. 

To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/a6a0ec7e-4877-4b26-a9eb-f7c0770319cd%40googlegroups.com.

[daniel...@wazuh.com]

Hi Stefano,

As you say, info about who deleted the file should be given when you use whodata.
Probably something has been missed in the configuration, how are you setting FIM in the machine indicated?
Normally you only need to use a simple line to get the info, something similar to:

        <directories check_all="yes" whodata="yes">PATHTODIRECTORY</directories>

It would be nice if you can share the agent configuration (ossec.conf file) with me.

Regards.

On Wed, Mar 27, 2019 at 12:07 PM Stefano Serano <serano...@gmail.com> wrote:

Hi Daniel.

All work fine now, but i have a last questton for you.

I've enabled integrity monitor with who-data on  a windows server 2008 r3 and I've enabled local audit policy.

I've noticed that when i delete a file, into the log on Kibana i can't see who deleted that file. is that right or i missing something into the configuration?

Have a nice day.

Il giorno mar 26 mar 2019 alle ore 16:44 Stefano Serano <serano...@gmail.com> ha scritto:

Hi Daniel.

I think problem is solved after removed that specific directory.

Wazuh logs show me permission error even if i start the service with Domain Admin user account. I checked the permission on some of those files and i can confirm that are accessible from the wazuh service user account. Anyway even with those errors now i can see logs in console, i'll monitor the situation for another few days and give you a feedback soon.

Have a nice day.

To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/780f83e6-9c0e-4ec2-a059-400e32326040%40googlegroups.com.

[daniel...@wazuh.com]

Hello Stefano,

Windows Server 2008 R2 should be configured natively, last version that needs to do it manually is windows server 2008.

Don't hesitate to ask me again if you still have any question.

Regards.

On Thu, Mar 28, 2019 at 10:33 AM Stefano Serano <serano...@gmail.com> wrote:

Ok Daniel i've solved, i was sure i've configured whodata but was realtime instead. 

A question about this:

https://documentation.wazuh.com/3.x/user-manual/capabilities/auditing-whodata/who-windows-policies.html 

You said to set up "Security Settings -> Local Policies -> Audit Policy -> Audit object access" ONLY if i had Vista or Server 2008 O.S.. Do you mean even Server 2008 R2? because can be a little bit tricky for us.

Have a nice day 

To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/776acec7-9238-4e46-a27d-55b0c02ffa9b%40googlegroups.com.

[daniel...@wazuh.com]

Hello Stephano,

Looking at the scenario you describe we have the same issue as before:

 1. Enabling whodata (it uses realtime) will create a new thread for each file tree.
    When you try to monitor a directory and it has too many subdirectories it needs a lot of threads and your pc won't be able to manage it.
    With whodata just specific directories should be monitored, thinking in the size of them before enabling the realtime feature.
    In this case, the shared disk probably have too many files to be monitored in realtime.
    Also the whodata feature can only be used in folders of the C: drive. We plan on allowing other drives in the future.   

 2. Syscheck scans files sequentially, a huge amount of files will produce a slow behavior of this feature due to his nature.
    Regarding your question, syscheck can be set not to scan at startup inside its section in the ossec.conf file.
    If you want to launch the syscheck scan just once it's possible to use a high value in the <frecuency> option, for example, several years expressed in seconds.
    Realtime is stopped during this scan but directories specified as realtime are scanned too.

We strongly encourage you to direct your questions to our mailing list directly so more people can benefit from the answers, as well as opening new threads in it to ask about different issues or questions.

Hope this helps and don't hesitate to ask us again.

On Fri, Mar 29, 2019 at 9:59 AM Stefano Serano <serano...@gmail.com> wrote:

Many thanks Daniel for your support and patient.

i've two new question for you:

1- i've enabled whodata on a windows server 2008 R2 where it monitor a 1.2 TB  shared disk. after the first syscheck scan was completed and realtime engine started this error appear and the service go down:

2019/03/28 06:57:55 ossec-agent: CRITICAL: (1102): Could not acquire memory due to [(12)-(Visual C++ CRT: Not enough memory to complete call to strerror.)].

2019/03/28 06:57:55 ossec-agent: INFO: (1314): Shutdown received. Deleting responses.

Maybe not enough ram? the server has 12 GB but maybe to maintain active the real time on a 1.2 TB disk it need more boost?

2- a syscheck scan on this disk take 2 day to complete, this mean than for 2 day i'm unable to recieve whodata info. thhere is a way to disable syscheck scan after the first run? or at least a way to keep realtime engine up during the scan?

Have a nice day.

To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/38eccffa-8d52-4f53-a704-e1ac9d845c0f%40googlegroups.com.

[daniel...@wazuh.com]

Hello again Stefano,

I wanted to clarify something I mentioned in my previous response.
If you set scan_on_start to no, realtime features won't start until the first frequency scan completes.
Depending on your configuration that can be hours after the agent started.

Hope it helps.