On Tue, 2007-10-23 at 15:57 +0100, Arthur Dent wrote: > > This has produced a couple of > questions none of which are really serious - just curious: > > 1) I run RKH from a daily cron job and in the resulting mail output I get > these > strange characters that I don't get when I run it from the command line: > > [1;33mChecking rkhunter version...[0;39m > This version : 1.3.0 > Latest version: 1.3.0 > I'm assuming you are running something like 'rkhunter --versioncheck' on its own in cron? In the cronjob, run RKH with the '--nocolors' option. The funny characters are used to display colours, and when --cronjob is used RKH supresses the colouring. However, when --versioncheck/--update is run, on its own, via cron, RKH does not know that it should stop the colouring.
I'm going to add this as a FAQ question because it is a tricky situation (in cron --versioncheck/--update uses colours, --cronjob does not), and one that I suspect will come up every so often. > > 2) Deleted files: > What does this actually mean and what should I do? > > Warning: The following processes are using deleted files: > Process: /bin/bash PID: 4037 File: /dev/pts/0 > Process: /bin/mail PID: 13513 File: /tmp/Rsw5uchv > In the first line, the process 4037 is running the /bin/bash command and is using the file /dev/pts/0 for some purpose. However, that file does not exist. In the second line, /bin/mail is using the file /tmp/Rsw5uchv, but that file does not exist either. What to do is difficult to say since it depends on the process involved. However, it generally implies that something has gone wrong. At work I currently have a web server which shows the web process running with it using 2 deleted files. These files are the (Apache) web log files access_log and error_log. The files should have been created when the service was restarted, but for some reason they were not. The solution in my case is to stop and start the web process, so that it creates the files it needs. In your case I would suggest seeing who is running these processes and what they are doing. The 'mail' command I would suspect is transient, so it may be that a user was doing something odd but that they have now closed the mail command. Hence if you run RKH again it may not show any warnings. > > 3) Not really a RKH question - this is actually a clamav / clamassassin > question but I thought I would ask here in case anyone knows... Suspscan finds > a bunch of these files in /tmp They all date back to 12 October on which day > my spamassassin and clamassassin processing crashed due to an (unrelated) > network problem. I guess they are real virus emails which were only partially > processed. My question: I know I could whitelist them in rkhunter.conf but I > presume it would be safe to delete them? > Warning: File '/tmp/clamassassinmsg.Rwmej24697' (score: 261) contains some > suspicious content and should be checked. > I don't use clamav/clamassassin so can't really answer about that. > > 4) Question 3 is inconsequential, but I have left it there because it relates > to this question which is probably the only important one in my list... > Having run Suspscan which finds the above content, any further runs of RKH > produce the following: > Warning: Suspicious files found in /dev: > /dev/shm/suspscan.16568.strings: ASCII English text > /dev/shm/suspscan.11185.strings: ASCII English text > /dev/shm/suspscan.27539.strings: ASCII English text > /dev/shm/suspscan.22541.strings: ASCII English text > /dev/shm/suspscan.19189.strings: ASCII English text > /dev/shm/suspscan.15620.strings: ASCII English text > /dev/shm/suspscan.11709.strings: ASCII English text > /dev/shm/suspscan.8034.strings: ASCII English text > /dev/shm/suspscan.7005.strings: ASCII English text > /dev/shm/suspscan.11229.strings: ASCII English text > /dev/shm/suspscan.8636.strings: ASCII English text > > (one for each day I have run RKH since it found the clamassassin entries) > > My question: > > Why does RKH trigger its own suspect file warning? Should these be whitelisted > or deleted? > They should be deleted. This is a bug, fixed in CVS. Unfortunately the suspscan process creates a temporary file in /dev/shm, but doesn't remove it. Hence subsequent runs of RKH may treat the file as suspicious. If you want to use the suspscan check regularly, then I would suggest getting a copy of the CVS version. Alternatively, just remember to delete any 'suspscan' files in /dev/shm on a regular basis. > > Thanks in advance for your answers and thanks very much to unSpawn and all the > RKH rpoject team for all their efforts in providing us with such a great > product. > Thank you very much from all of us :-) 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 [email protected] https://lists.sourceforge.net/lists/listinfo/rkhunter-users
