On Wed, 2007-10-24 at 10:35 +0100, Arthur Dent wrote:

> 
> 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?
> 
It is difficult to say. You haven't said what O/S you are running, but
you may want to ask the question on a user mailing list for your O/S.


> 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?)
> 
No, you can't make it more specific, but I will note that for
consideration in my TODO list.


> 
> 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?
> 
No, you cannot whitelist files from the suspscan test. unSpawn has done
the work for this test, so you may want to enter this as a feature
request in the RKH bugzilla. (He's a bit busy, but does pick up on
reported bugs/requests.)


> 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)
> 
Yup, that would be about it at present.

> 
> 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.
> 
No I don't think that's right. The suspscan test will create a temporary
file, but it is the subsequent 'filesystem' test that then detects it
in /dev. I have noted that the warning message for the filesystem test
says something like 'suspicious file', but I will change that to say
'suspicious file type'. The two tests are seperate in that suspscan
checks file contents, whereas 'filesystem' (amongst other things) checks
the file type. An ascii file type in the /dev directory is suspicious,
hence you get the warning.

If you run 'rkhunter --enable suspscan' you may or may not get warnings,
but they won't include the temporary file. If you look in /dev/shm you
will see that the file has been created though.


> However, I have discovered that placing the following line:
> ALLOWDEVFILE=/dev/shm/suspscan.*
> in rkhunter.conf does away with this problem.
>
Because this has whitelisted the file from the 'filesystem' test, not
the 'suspscan' test.


John.

-- 
---------------------------------------------------------------
John Horne, University of Plymouth, UK  Tel: +44 (0)1752 233914
E-mail: [EMAIL PROTECTED]       Fax: +44 (0)1752 233839

-------------------------------------------------------------------------
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
Rkhunter-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkhunter-users

Reply via email to