Hi JDS,

rootcheck does a lot of things: check rootkit_files and rootkit_trojans, 
scan the /dev directory looking for anomalies, check the file system 
looking for unusual files and permissions, inspect all process IDs, look 
for the presence of hidden ports, scan all network interfaces, etc. I 
guess, you are talking only about *system audits* (or *policies*). If you 
create a system audit (policy) to search Social Security Numbers in your 
system, you should to limit the search in order to make it efficient. The 
goal of a system audit is to check a policy in a system (check software 
version, check configurations, etc). Rootkits detection is performed using 
the definitions of rootkit_files, rootkit_trojans and the rest of rootcheck 
features.

I think we do not have many option to tune rootcheck, just enabled/disabled 
features:

   - check_files: Enable or disable the checking of rootkits. Default yes.
   - check_trojans: Enable or disable the checking of trojans. Default yes.
   - check_dev: Check for files in the /dev filesystem. Default yes.
   - check_sys: Scan the whole system for additional issues. Default yes.
   - check_pids: Check processes. Default yes.
   - check_ports: Check all ports. Default yes.
   - check_if: Check interfaces. Defalult yes.
   - skip_nfs: Specifies if rootcheck should scan network mounted 
   filesystems. Works on Linux and FreeBSD. Currently skip_nfs will abort 
   checks running against CIFS or NFS mounts. Default: no.
   - scanall: Tells rootcheck to scan the whole system (may lead to some 
   false positives). Default: no.
   - check_unixaudit: Enable system_audit.
   - check_winapps: Enable windows_app.
   - check_winaudit: Enable windows_audit.
   - check_winmalware: Enable windows_malware.
   
Regards.

On Monday, August 1, 2016 at 11:14:14 PM UTC+2, JDS wrote:
>
> Howdy. I've been trying to use Rootcheck as a "generic signature scanner" 
> to be able to find things we don't want to exist on our systems. Not 
> malicious stuff, necessarily, but things like SSH keys for forbidden users 
> or files with PII data in them.
>
> I based my prototype on this article: 
> http://www.immutablesecurity.com/index.php/2010/01/13/detecting-sensitive-info-with-ossec/
>
> Now, I'm having severe performance issues when implementing Rootcheck 
> scans across a system. In order for my Rootcheck signatures to be useful, I 
> have to scan basically the entire box. When I do this, CPU % utilization 
> goes through the roof. >95% CPU utilization for ages, many tens of minutes.
>
> I've noticed that none of the pre-packaged signature databases are as 
> broad as "check the whole system". They are always much more specific in 
> the directories they check. Even the example from that article I linked, 
> above, only checks a handful of dirs:
>
> (This is the example):
>
> $web_dirs=/var/www,/var/htdocs,/home/httpd,/usr/local/apache,/usr/local/
> apache2,/usr/local/www;
>
> # Detect possible SSNs
> [Possible Unencrypted Social Security Number Detected] [any] []
> d:$web_dirs -> r:^\. -> r:\d\d\d-\d\d-\d\d\d\d;
>
> In this example, $web_dirs is set to 
> "$web_dirs=/var/www,/var/htdocs,/home/httpd,/usr/local/apache,/usr/local/apache2,/usr/local/www;".
>  
> But even this many dirs is misleading -- any given Linux distro, only one 
> or maybe two of those dirs defined there is actually going to exist. i.e. 
> Even this example is really only running on a single directory.
>
> But that doesn't make any sense to me as far as the utility of this 
> signature file goes. Or any of the rootkit sigs, come to think of it. 
> Wouldn't we want to scan every directory and every file for rootkits?
>
> Basically, I'm looking for a way to scan all my files to make sure nothing 
> has prohibited data in it. Maybe rootcheck is not the tool for that.
>
> Any opinions on this matter? Is there a Better Way to do what I want? Can 
> Rootcheck be tuned so as to not consume so much CPU?
>
> Thanks,
> JDS
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to