rootcheck: don't traverse NFS/CIFS mounts

[reyjrar]

This prevents every node with a network mounted filesystem from scanning the share. You will need to run OSSEC-HIDS on the share point if you want the same protection. However, having 2,000 nodes running intensive scans on an NFS share at the same time results in less than ideal performance for everything that uses that share.

[jrossi]

On unix this is a problem that I have never seen and given the limited paths that are checked and the availability of root check ignore the use case can be take care of with configuration. Maybe I am just not understanding the problem this pull request solves. Thank you again for the patch.

[mstarks01]

I agree that this could be a problem, but I can see situations where a network mount scan would be desirable. Maybe the mount is part of a SAN which runs a proprietary OS and OSSEC cannot be installed. I think this would be better implemented as a configuration option, maybe even with the default to being off just to be on the safe side.

[jrossi]

I really like the start of this and it's something I want to make sure we use.

char *(dirs_to_doread[]) = { "/bin", "/sbin", "/usr/bin",
                                 "/usr/sbin", "/dev", "/etc",
                                 "/boot", NULL };

This is what is normally read as part of this functions. /usr might be on NFS, but other wise I don't see the issue.

I do think this code should be used in a lot more places of rootcheck and syscheck, but I think we will need to talk about where and how.

What do you think @reyjrar?

[ddpbsd]

I could be missing something, but f_type doesn't appear to be standard among the various *nixes (I'm also having trouble finding the man page for statfs on Solaris). I think it's a great idea that we desperately need, but maybe there's a more portable way it could be implemented.

[ddpbsd]

I have done essentially no testing, but on OpenBSD checking f_flags against MNT_LOCAL might work.
Again, haven't found anything for Solaris, so we might need to ifndef solaris systems.

[reyjrar]

We had to add this patch, because a subdirectory of /var/www is an NFS share in one or our environments. Without this patch, we kill the NFS server and lockup the whole web service with IO wait. The do_read check that dirs_to_read[] specifies only controls whether the file is read, it does not prevent the initial dir listing which was killing our static content servers.

I think ddpbsd is correct though, this may not work on Solaris. It also might be helpful to have a global configuration for NFS scanning. Rootcheck and syscheck should have a shared system for skipping certain directories or NFS mounted file systems. I think I can put something together and if someone has access to solaris, let me know.

[jrossi]

I still what to use this but it should be more general and needs to be portable to all platforms that we support for agents (aka everything 👎 ).

But I don't use much syscheck much, but i woudl think you could use the ignore options http://ossec-docs.readthedocs.org/en/latest/syntax/head_ossec_config.syscheck.html to restrict scanning on /var/www.

[jrossi]

https://github.com/ossec/ossec-hids/blob/master/src/rootcheck/check_rc_sys.c#L193

Looks like rootcheck has the ignore code, just not documented. Humm......

[mstarks01]

Something I would like to see clarified: does syscheck actually not scan a directory when you ignore it, does it not forward the checksum, or does it not alert? There has been some confusion about this in the past. I recall one user having performance issues even after ignoring a directory, and it seemed like syscheck was still scanning it.

[jrossi]

Nope in look and following the code looks like ignore and rootcheck and syscheck are not even close to complete. This is a bug that needs to be fixed.

[ddpbsd]

On Mon, Feb 24, 2014 at 9:44 AM, mstarks01 notifications@github.com wrote:

Something I would like to see clarified: does syscheck actually not scan a
directory when you ignore it, does it not forward the checksum, or does it
not alert? There has been some confusion about this in the past. I recall
one user having performance issues even after ignoring a directory, and it
seemed like syscheck was still scanning it.

It's my understanding that on the agent does not send the hashes,
and on the manager ignores the hashes sent. In both cases the
files/directories are still scanned (which I consider a bug).

Reply to this email directly or view it on GitHubhttps://github.com//pull/47#issuecomment-35892336
.

[jrossi]

Created #138 for the ignore bug.

What about this pull request? I don't think we can accept this as it's gonna be an issues on some platforms that we support. But I don't want lose the code.

[reyjrar]

I have the code stashed in my repo and deployed in production, so it won't be lost. I'll look at a more flexible solution in the near future, been side tracked on other things at $WORK.