Well I'm beginning to make real progress here. My aim is to have a completely
clean sheet with RKH running as many tests as possible.

So far, point no. 1 (strange characters in cron output) has been cleared up
nicely with the use of the --nocolors option. Thanks.


Point no. 2 (deleted files). Well, even after a reboot the same two files (but
different PIDs) are still present.

Warning: The following processes are using deleted files:
         Process: /bin/bash    PID: 4041    File: /dev/pts/0
         Process: /bin/mail    PID: 6313    File: /tmp/Rs2Br4oe

>RKH is only going to report what it finds at the time it is run. So it
>is possible for it to report deleted files, and the next minute report
>none. I suspect if you do something like 'ls -l /dev/pts/0' it will
>report that there is no such file (which would agree with what RKH is
>saying). However, missing /dev/pts/0 seems a bit odd. A reboot should
>fix it.

'ls -l /dev/pts/0' does indeed report no such file even after a reboot. Should 
I be concerned about
this?

The /bin/bash process is always the same:
[EMAIL PROTECTED] ~]# ps aux | grep 4041
root      4041  0.0  0.2   4496  1112 ?  Ss   Oct23   0:00 /bin/sh 
/etc/X11/prefdm -nodaemon

The specific /bin/mail process identified above no longer exists but every run
of RKH finds a similar entry.

I guess at this point I have two options:
a) Disable the "deleted_files" check; or
b) Whitelist the processes using ALLOWPROCDELFILE=/bin/bash and
ALLOWPROCDELFILE/bin/mail
(This works by the way - but I am a bit nervous of allowing any /bin/bash
process. Can I make it more specific?)


Point no. 3 (Suspect files):
I have cleared out the "dead" clamassassin files from /tmp and, naturally,
these no longer feature in the RKH scan. There are however two "live" files
('/var/tmp/clamdb/SCAM-UpdateSession.log' and
'/var/tmp/clamdb/PHISH-UpdateSession.log') which I'm satisfied are legitimate.
There appears to be no way to whitelist specific files for the suspscan test
in rkhunter.conf. I can select the directories to be scanned, the file size,
or the reporting threshold. Am I missing something?

So here again I have two options:
a) Disable the "suspscan" check; or
b) Accept that these files will always be reported.
(Actually three options thinking about it)
c) Increase the reporting threshold to 231 (both files seem to be 230)


Point no. 4 (suspcan finding its own files)
Adding a "rm /dev/shm/suspscan.*" line to my rkhunter cron script is only
partially successful. It seems that suspscan creates the file during the
scanning process and then finds it on that scan so as long as the above clamd
files are present it will create and find its own suspicious file. My script
merely deletes that file preventing it from being found on future scans.

However, I have discovered that placing the following line:
ALLOWDEVFILE=/dev/shm/suspscan.*
in rkhunter.conf does away with this problem. The other option of course is to
upgrade to the cvs version. 
>You don't need to access CVS directly. You can download the nightly CVS
>version as a tarball from
>http://rkhunter.sourceforge.net/rkhunter-CVS.tar.gz 
>
>The CVS version already has a few bug fixes, but whether you need them
>depends on your system and the tests being run. The CHANGELOG file will
>show you the differences between version 1.3.0 and the CVS version
>(1.3.1).

Thank you, I am going to look into that.

In summary, the only things I really need to be concerned about are the deleted
files problem and the whitelisting of known "suspect" files.

Your help and support is much appreciated.

AD


Attachment: pgppqU9EJMKjz.pgp
Description: PGP signature

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Rkhunter-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rkhunter-users

Reply via email to