Disk Space Full-Wazuh3.13

2,677 views
Skip to first unread message

siddha...@gmail.com

unread,
Apr 14, 2021, 5:45:22 AM4/14/21
to Wazuh mailing list
Hello Team,

i have install wazuh 3.13 as Distributed architecture on Ubuntu 20.04 and yesterday i check that my disk has been showing out of space so i extend 200 GB  for that time and today again disk showing out of space .
please suggest is there some logs which is generated again and again.

Regards
Siddharth

Julia Magan Rodriguez

unread,
Apr 14, 2021, 10:27:20 AM4/14/21
to Wazuh mailing list

Hello Siddharth,

I would recommend doing a few checks to find out what is taking up so much disk space.

First of all, please run du -sh /var/ossec to see how much disk space Wazuh is taking up.

Then, if the problem of disk space is caused by Wazuh, you should check which file is taking up disk space. Usually, those files are logs files, which are located at /var/ossec/logs. You can run the same command as before, but with the specified directory you want to check, for example, du -sh /var/ossec/logs. Old files are rotated into folders sorted by date:

/var/ossec/logs/alerts/year/month/day
/var/ossec/logs/archives/year/month/day

You can delete or move files that no longer interest you. Furthermore, when your alerts are sent to Elastic, it is not necessary to keep your logs in your manager. You can also, apply a data retention policy to remove old logs and use Opendistro IML for the elasticsearch indices, it is up to you. Here you can learn more about it: https://wazuh.com/blog/wazuh-index-management/


If the alerts file is taking up much disk space, you could run cat /var/ossec/logs/alerts/alerts.log | grep Alert | sort | cut -d '.' -f 1 | uniq -c , so you can check which alerts are repeated.


Finally, I would recommend you check Wazuh configuration in /var/ossec/etc/ossec.conf and disable options like logall and logall_json because, by default, alerts will be generated on important events or of security relevance, so with logall option enabled, you are storing all events even if they do not match a rule.

    <logall>no</logall>
    <logall_json>no</logall_json>

I hope I have helped you and I look forward to your response.

Best regards.

siddharth jha

unread,
Apr 16, 2021, 10:31:46 AM4/16/21
to Julia Magan Rodriguez, Wazuh mailing list
Hello julia.magan,

First of all thank you very much for your support.

as you suggested I have checked /var/ossec showing 344G and ./var/log contains 116G space.
one month ago I checked disk space showing around 250G available from 300 G and suddenly it's just showing out of space.
and in Elasticsearch VM it's showing 260G available from 314G .
i have also checked ossec.conf where same settings available  
<logall>no</logall> 
 <logall_json>no</logall_json> 
and i run this cmd as you suggested /var/ossec/logs/alerts/alerts.log | grep Alert | sort | cut -d '.' -f 1 | uniq -c 
its showing so much alert i can't understand which files that was and where its saved 
Please suggest.


--
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/0d5941e9-6e96-44d1-8ab1-72d59cd21308n%40googlegroups.com.

Julia Magan Rodriguez

unread,
Apr 19, 2021, 4:14:49 AM4/19/21
to Wazuh mailing list

Hello Siddharth,

When you run cat /var/ossec/logs/alerts/alerts.log | grep Alert | sort | cut -d '.' -f 1 | uniq -c you will be able to see something like this:


root@focal:/var/ossec/logs/alerts# cat alerts.log| grep Alert | sort | cut -d '.' -f 1 | uniq -c

      1 ** Alert 1618558437

     19 ** Alert 1618558440

     57 ** Alert 1618558441

     27 ** Alert 1618558442

     95 ** Alert 1618558443

     70 ** Alert 1618558444

      1 ** Alert 1618558451

      1 ** Alert 1618558462

      2 ** Alert 1618559333

      3 ** Alert 1618559341

Here, you are seeing how many times an alert is repeated. For example, Alert 1618558443 is repeated 95 times.

I suggest you run cat /var/ossec/logs/alerts.log | grep Rule | sort | uniq -c , so you will be able to see which rule is firing and how many times. For example:


      1 Rule: 502 (level 3) -> 'Ossec server started

     76 Rule: 510 (level 7) -> 'Host-based anomaly detection event (rootcheck)

      1 Rule: 5403 (level 4) -> 'First time user executed sudo

      3 Rule: 5501 (level 3) -> 'PAM: Login session opened

      1 Rule: 5715 (level 3) -> 'sshd: authentication success

Here, Rule 510 has been fired 76 times.

All these alerts are being saved in /var/ossec/logs/alerts/alerts.log, which is the file you are searching in. If you run the same command but with /var/ossec/logs/alerts/year/month/day/ossec-alerts-day.log, you will be able to see the alerts that have been rotated.
Finally, I would recommend you to run du -ah /var/ossec/ | sort -n -r | head -n 20 so you will be able to see at once, how much the Wazuh directories occupy.

siddharth jha

unread,
Apr 28, 2021, 2:27:59 PM4/28/21
to Julia Magan Rodriguez, Wazuh mailing list
Hello Julia,

Thanks for your email,
as per your suggestion I have run  cat /var/ossec/logs/alerts.log | grep Rule | sort | uniq -c then its showing no such file and directory .


then i run cat /var/ossec/logs/alerts/alerts.log |grep Rule | sort |uniq -c and got some out which i have also attached kinldy check the same and suggest.
after that i run du -ah /var/ossec/ | sort -n -r | head -n 20 and got below output.

1020K   /var/ossec/framework/python/include/python3.8
1016K   /var/ossec/framework/python/lib/python3.8/site-packages/pip/_vendor/urllib3
1016K   /var/ossec/framework/python/lib/python3.8/site-packages/pip/_vendor/html5lib
1008K   /var/ossec/framework/python/lib/python3.8/site-packages/pycparser
1008K   /var/ossec/bin/ossec-makelists
1004K   /var/ossec/framework/python/lib/python3.8/site-packages/botocore/data/ec2/2016-09-15
1000K   /var/ossec/bin/ossec-syscheckd
992K    /var/ossec/logs/alerts/2020/Oct/ossec-alerts-28.log.gz
976K    /var/ossec/framework/python/lib/python3.8/lib2to3/fixes
956K    /var/ossec/framework/python/lib/python3.8/site-packages/asn1crypto
948K    /var/ossec/etc/shared
948K    /var/ossec/bin/wazuh-db
944K    /var/ossec/framework/python/lib/python3.8/site-packages/pkg_resources
936K    /var/ossec/framework/python/lib/python3.8/site-packages/pip/_vendor/chardet
936K    /var/ossec/framework/python/lib/python3.8/site-packages/chardet
936K    /var/ossec/framework/python/lib/python3.8/distutils/tests/__pycache__
928K    /var/ossec/etc/shared/default
928K    /var/ossec/bin/ossec-remoted
925M    /var/ossec/logs/alerts/2021/Jan
924K    /var/ossec/logs/alerts/2020/Sep/ossec-alerts-11.log.gz


please check and suggest.
thanks again for your time and support.


--
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/rzf59mnX3KU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wazuh+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/af9dc1ab-45f7-4231-80d6-61099385519en%40googlegroups.com.
alert.log-output.txt

Julia Magan Rodriguez

unread,
Apr 29, 2021, 3:51:39 AM4/29/21
to Wazuh mailing list

Hello,
I am sorry, I forgot to add the alerts folder to the path, the running command should be:


cat /var/ossec/logs/alerts/alerts.log |grep Rule | sort |uniq -c

In the information of how much space Wazuh is occupying, Wazuh is not occupying 200GB. It seems that you have Elasticsearch installed in the same server and it hasn’t enough shards. Could you check how much memory is elasticsearch taking up?
du -sh /usr/share/elasticsearch
You are reaching the maximum number of shards as you can see in the next picture:

image (1).png
This problem is generating level 2 events, and those are generating alerts.
You could add nodes to the cluster or increase the maximum number of shards possible:

curl -X PUT localhost:9200/_cluster/settings -H "Content-Type: application/json" -d '{ "persistent": { "cluster.max_shards_per_node": "3000" } }'

Also, in the output you have attached, I can see that rule 1002, the one that is generated because of the problem above, has been fired 6394457 times. This rule has level 2, so maybe, you have lowered the alert level, by default is 3. You can check it at /var/ossec/etc/ossec.conf:

  <alerts> 
 <log_alert_level>3</log_alert_level> 
 </alerts>

Regards.

siddharth jha

unread,
Apr 29, 2021, 5:25:33 AM4/29/21
to Julia Magan Rodriguez, Wazuh mailing list
hello Julia,
Thanks for your email,

i have checked elasticsearch is not installed on same vm and run this cmd   du -sh /usr/share/elasticsearch and got this output du: cannot access '/usr/share/elasticsearch': No such file or directory
and run same cmd where elasticsearch is installed got this output --  510M    /usr/share/elasticsearch

and yes i have set a lower log level sometimes back to get some firewall logs and same it was running around 6 months.

please check this in 2021 dir Apr folder its showing 333G 
root@WazuhM:~# du -sh /var/ossec/logs/alerts/2021/Apr
333G    /var/ossec/logs/alerts/2021/Apr

please suggest.
Thank You



Julia Magan Rodriguez

unread,
Apr 29, 2021, 7:32:08 AM4/29/21
to Wazuh mailing list

Hello,
So that’s the folder that is taking up so much space. I recommend that you delete the logs that are stored there unless you want to save them for some reason, then I suggest you move them to another site. Before deleting the file, I recommend that you do:
du -ah /var/ossec/logs/alerts/2021/Apr/
You will be able to see how much space the logs take up and the date of the logs. Then run:
cat /var/ossec/logs/alerts/2021/Apr/ossec-alerts-day.log |grep Rule | sort |uniq -c
And you can check which alerts are being fired all the time.
Finally, if you want to see an alert when an event happens, for example, the firewall logs you want to check, I would recommend you increase the level of this event, instead of lowering the log_alert_level. To do this, you will have to change the rules, you can see how it’s done here: https://documentation.wazuh.com/current/learning-wazuh/replace-stock-rule.html

Regards.

siddharth jha

unread,
Apr 29, 2021, 8:45:27 AM4/29/21
to Julia Magan Rodriguez, Wazuh mailing list
hello Julia,

Thanks again,

as you suggested i have run this cmd du -ah /var/ossec/logs/alerts/2021/Apr/ got this output

root@WazuhM:~# du -ah /var/ossec/logs/alerts/2021/Apr/
1.8G    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-26.json.gz
1.9G    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-21.json.gz
0       /var/ossec/logs/alerts/2021/Apr/ossec-alerts-26.log.sum
48G     /var/ossec/logs/alerts/2021/Apr/ossec-alerts-29.log
4.0K    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-15.json.sum
0       /var/ossec/logs/alerts/2021/Apr/ossec-alerts-17.log.sum
1.9G    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-19.json.gz
28K     /var/ossec/logs/alerts/2021/Apr/ossec-alerts-23.log.gz
4.0K    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-24.json.sum
4.0K    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-13.json.sum
0       /var/ossec/logs/alerts/2021/Apr/ossec-alerts-27.log.sum
1.8G    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-24.json.gz
4.0K    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-18.json.sum
4.0K    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-19.json.sum
4.0K    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-07.json.sum
4.0K    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-28.json.sum
4.0K    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-22.json.sum
1.8G    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-22.json.gz
0       /var/ossec/logs/alerts/2021/Apr/ossec-alerts-15.log.sum
1.8G    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-27.json.gz
0       /var/ossec/logs/alerts/2021/Apr/ossec-alerts-07.log.sum
0       /var/ossec/logs/alerts/2021/Apr/ossec-alerts-19.log.sum
1.9G    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-17.json.gz
4.0K    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-27.json.sum
4.0K    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-16.json.sum
77G     /var/ossec/logs/alerts/2021/Apr/ossec-alerts-29.json
36K     /var/ossec/logs/alerts/2021/Apr/ossec-alerts-25.log.gz
32K     /var/ossec/logs/alerts/2021/Apr/ossec-alerts-20.log.gz
28K     /var/ossec/logs/alerts/2021/Apr/ossec-alerts-28.log.gz
1.8G    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-23.json.gz
0       /var/ossec/logs/alerts/2021/Apr/ossec-alerts-18.log.sum
2.1G    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-14.json.gz
4.0K    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-13.log.sum
1.8G    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-20.json.gz
4.0K    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-25.json.sum
1.8G    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-25.json.gz
54G     /var/ossec/logs/alerts/2021/Apr/ossec-alerts-09.log
4.0K    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-14.log.sum
4.0K    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-08.json.sum
0       /var/ossec/logs/alerts/2021/Apr/ossec-alerts-25.log.sum
0       /var/ossec/logs/alerts/2021/Apr/ossec-alerts-24.log.sum
32K     /var/ossec/logs/alerts/2021/Apr/ossec-alerts-27.log.gz
28K     /var/ossec/logs/alerts/2021/Apr/ossec-alerts-24.log.gz
86G     /var/ossec/logs/alerts/2021/Apr/ossec-alerts-09.json
21G     /var/ossec/logs/alerts/2021/Apr/ossec-alerts-12.json
32K     /var/ossec/logs/alerts/2021/Apr/ossec-alerts-15.log.gz
32K     /var/ossec/logs/alerts/2021/Apr/ossec-alerts-26.log.gz
4.0K    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-23.json.sum
1.3G    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-13.log.gz
0       /var/ossec/logs/alerts/2021/Apr/ossec-alerts-28.log.sum
0       /var/ossec/logs/alerts/2021/Apr/ossec-alerts-23.log.sum
0       /var/ossec/logs/alerts/2021/Apr/ossec-alerts-22.log.sum
1.7G    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-13.json.gz
1.9G    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-15.json.gz
1.9G    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-16.json.gz
4.0K    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-21.json.sum
4.0K    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-26.json.sum
32K     /var/ossec/logs/alerts/2021/Apr/ossec-alerts-21.log.gz
0       /var/ossec/logs/alerts/2021/Apr/ossec-alerts-08.log.sum
4.0K    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-17.json.sum
0       /var/ossec/logs/alerts/2021/Apr/ossec-alerts-07.log.gz
28K     /var/ossec/logs/alerts/2021/Apr/ossec-alerts-19.log.gz
2.5G    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-07.json.gz
1.7G    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-28.json.gz
4.0K    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-20.json.sum
0       /var/ossec/logs/alerts/2021/Apr/ossec-alerts-20.log.sum
28K     /var/ossec/logs/alerts/2021/Apr/ossec-alerts-22.log.gz
28K     /var/ossec/logs/alerts/2021/Apr/ossec-alerts-18.log.gz
32K     /var/ossec/logs/alerts/2021/Apr/ossec-alerts-16.log.gz
32K     /var/ossec/logs/alerts/2021/Apr/ossec-alerts-17.log.gz
1.9G    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-18.json.gz
1.8G    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-08.json.gz
0       /var/ossec/logs/alerts/2021/Apr/ossec-alerts-16.log.sum
4.0K    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-14.json.sum
0       /var/ossec/logs/alerts/2021/Apr/ossec-alerts-08.log.gz
0       /var/ossec/logs/alerts/2021/Apr/ossec-alerts-21.log.sum
1.6G    /var/ossec/logs/alerts/2021/Apr/ossec-alerts-14.log.gz
14G     /var/ossec/logs/alerts/2021/Apr/ossec-alerts-12.log
333G    /var/ossec/logs/alerts/2021/Apr/

and when run this cmd cat /var/ossec/logs/alerts/2021/Apr/ossec-alerts-day.log |grep Rule | sort |uniq -c its showing no such file and directory.

please suggest.

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/36a4ca4f-1e45-489a-9f12-d754b4bb2f9cn%40googlegroups.com.

Julia Magan Rodriguez

unread,
Apr 30, 2021, 8:16:51 AM4/30/21
to Wazuh mailing list

Hello,
Sorry if I didn’t specify it enough, but in the command that I gave you, day is in bold and blue because you have to change it to the number of the day of the log. You can see the day in the name of the log. For example, if you want to see what is in /var/ossec/logs/alerts/2021/Apr/ossec-alerts-29.log, you should run cat /var/ossec/logs/alerts/2021/Apr/ossec-alerts-29.log |grep Rule | sort |uniq -c
Regards.

siddharth jha

unread,
May 3, 2021, 1:58:26 AM5/3/21
to Julia Magan Rodriguez, Wazuh mailing list
hello Julia,

Thanks again for your support.

I have deleted the log file which is taking so much space from this path-- /var/ossec/logs/alerts/2021/Apr.
also set alert level default as you recommended

<alerts> <log_alert_level>3</log_alert_level> </alerts>

and restart wazuh services. then I check space and it again occupies all disk space.
please also find attached file and suggest.


wazuh-alert.log-output.txt

Julia Magan Rodriguez

unread,
May 6, 2021, 7:35:35 AM5/6/21
to Wazuh mailing list

Hello,

Sorry for the late response. I’ve been checking the thread and I saw that you have some log files that aren’t rotated.
First of all, I recommend you set an interval for rotating the logs, you can see how it’s done here. This will rotate and compress the logs to save disk space.
If the problem persists, you can apply:

0 6,14,22 * * * /bin/rm /var/ossec/logs/alerts/2020/* -Rf && /bin/systemctl restart wazuh-manager

More info at: https://github.com/wazuh/wazuh/issues/4425#issuecomment-577585313

Anyway, we will take a look at this problem and will come back as soon as possible.

Regards.

siddharth jha

unread,
May 10, 2021, 5:14:50 AM5/10/21
to Julia Magan Rodriguez, Wazuh mailing list
Hi Julia,

Again Thank you very much for your support.

as you suggested to set an interval for rotating the logs i have check this path /var/ossec/etc/internal_options.conf 
and found analysisd.min_rotate_interval=600 this is added by default there and i checked that article where its mention as 
example  <rotate_interval>10h</rotate_interval> 
Do I need to add this line there or need to change the number.? please suggest.

and if its not works then run below 
0 6,14,22 * * * /bin/rm /var/ossec/logs/alerts/2020/* -Rf && /bin/systemctl restart wazuh-manager
Do I need to change 2020 to 2021 ? kindly suggest 

and last thing should i upgrade this version to a newer version it will resolve this issue ?
please suggest.


Julia Magan Rodriguez

unread,
May 10, 2021, 8:24:19 AM5/10/21
to Wazuh mailing list

Hello,
To specify the Interval you should add <rotate_interval>10h</rotate_interval>, or change the number if this line already exists in /var/ossec/etc/ossec.conf. https://documentation.wazuh.com/3.13/user-manual/reference/ossec-conf/global.html#rotate-interval
When you change analysisd.min_rotate_interval=600 in /var/ossec/etc/internal_options.conf, you are telling the minimum value of rotate_interval option, but you aren’t specifying the interval. This is done using the <rotate_interval> option. Keep in mind that /var/ossec/etc/internal_options.conf changes every time you upgrade your Wazuh version. So if you want to change this value (or any other value), and you want it to persists even if you upgrade Wazuh, you should add it to /var/ossec/etc/local_internal_options.conf.
Also, you could take a look here. This sets the size limit of alert files with a maximum allowed value of 1TiB and a minimum allowed value of 1MiB.
Answering the question of if you should write 2021 instead of 2020, yes you should, since you won’t have any 2020 log.
Finally, it is not necessary to upgrade your Wazuh version, since the problems do not depend on the version you have.
Regards.

siddharth jha

unread,
May 13, 2021, 8:56:53 AM5/13/21
to Julia Magan Rodriguez, Wazuh mailing list
hello Julia,

As you suggested, I have added  <rotate_interval>10h</rotate_interval> in /var/ossec/etc/ossec.conf in the Global section. Please suggest if it is correct.

and change its value analysisd.min_rotate_interval=10 in /var/ossec/etc/internal_options.conf
but i can see disk space is getting full around in 20 hrs , previously it was getting full 10-20 min.
and when i run this cmd 0 6,14,22 * * * /bin/rm /var/ossec/logs/alerts/2020/* -Rf && /bin/systemctl restart wazuh-manager
its showing root@WazuhM:~# 0 6,14,22 * * * /bin/rm /var/ossec/logs/alerts/2020/* -Rf && /bin/systemctl restart wazuh-manager 0: command not found

Also, I can't see any events on the kibana web interface , i checked all services wazuh manager , agents , filebeat elasticsearch ,kibana and wazuh app all are running and showing active but still can't see any events and disk space is getting full.
please suggest.

Julia Magan Rodriguez

unread,
May 19, 2021, 5:29:15 AM5/19/21
to Wazuh mailing list

Hello,

Before running 0 6,14,22 * * * /bin/rm /var/ossec/logs/alerts/2020/* -Rf && /bin/systemctl restart wazuh-manager, please run crontab -e.

For the problem with Kibana, could you please start a new thread? It seems to be a different problem and, this way, we can give it more visibility to other users.

Regards.

Reply all
Reply to author
Forward
0 new messages