search

ossec / ossec-hids

OSSEC is an Open Source Host-based Intrusion Detection System that performs log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting and active response.
http://www.ossec.net
Other
4.42k stars 1.04k forks source link

ossec.log file filling up with "WARN: Error opening directory" errors #1792

Open randallsevery opened 4 years ago

randallsevery commented 4 years ago

I have been running an OSSEC installation (version 3.3.0) on a CentOS 7 server for about a month now, and after a lot of fiddling with configurations and rules it is mostly working properly. But I'm noticing that the /var/ossec/logs/ossec.log file is already very large (almost 1Gb), and 99% of the entries in the log file appear to be something similar to the following:

2019/11/13 10:04:28 ossec-syscheckd: WARN: Error opening directory: '/path/to/directory/encode.lock': No such file or directory 2019/11/13 10:00:02 ossec-syscheckd: WARN: Error opening directory: '/etc/recent_recipient_mail_server_ips.trim': No such file or directory 2019/11/13 09:59:23 ossec-syscheckd: WARN: Error opening directory: '/path/to/directory/statuscheck.txt': No such file or directory 2019/11/13 09:50:03 ossec-syscheckd: WARN: Error opening directory: '/etc/recent_authed_mail_ips.build': No such file or directory

In most of the cases of that log entry, there is a file (not a directory) that has a name similar to, but not the same, as the name in the warning (such as encode.php, recent_recipient_mail_server_ips, or recent_authed_mail_ips), except for "statuscheck.txt", which doesn't exist in any similar fashion in the directory referenced in the warning.

So I have two questions about this:

1) Why is OSSEC trying to access files that don't exist? 2) Why is OSSEC trying to open those non-existent files as directories?

ddpbsd commented 4 years ago

Are these directories/files configured in the syscheck section of the ossec.conf or a relevant section of the agent.conf?

randallsevery commented 4 years ago

Yes, the parent directories are configured to be scanned (/path/to/directory is not the real directory in the examples I gave in the original post, but I didn't want to include the actual directory in those examples), but the directories listed in the warnings either don't exist or are files, not directories. For the /etc directory in the example, I have the following configuration setting in ossec.conf:

<directories realtime="yes" check_all="yes">/etc,/usr/bin,/usr/sbin</directories>