On Fri, 2010-05-07 at 16:44 +0200, Michael Li wrote:
> 
> Today I ran the rkhunter-1.3.6, first with the --propupd, and got:
> sudo rkhunter --propupd[ Rootkit Hunter version 1.3.6 ]
> File updated: searched for 156 files, found 83, missing hashes 83
> 
> => Are the missing hashes a problem for the check?
>
Yes. From the FAQ:

  3.8) When I used the '--propupd' option, Rootkit Hunter told me
       I had some missing hashes. What does this mean?

  A.   Your system probably uses prelinking (the log file will say if
       it does or not). Sometimes a file may be updated but not be
       prelinked. When this happens RKH cannot determine the files hash
       value. 

I have no idea if MAC's use prelinking (or prebinding) anymore, but the
log file (/var/log/rkhunter.log) will tell you. You need to find out why
RKH could not determine the hash value for these files (ah, see further
below for a probable reason). Until that is done, RKH will give you a
warning for each of them.

> => Secondly, I could not use "rkhunter --propupd -- pkgmgr" because I 
>    do not know the name of the package manager in Mac OSX 10.5.8.
> 
RKH does not support any package manager for OSX, so ignore the
'--pkgmgr' options.

> 
> When running the check, it found the "Dica-Kit Rootkit", here is an
> excerpt of the log file:
> 
> [15:01:32] Checking for Dica-Kit Rootkit...
...
> [15:01:33]   Checking for file '/etc/sshd_config'            [ Found ]
>
Okay. I am making the assumption that this is normal for OSX (it is for
you to verify that). This can be whitelisted by adding

    RTKT_FILE_WHITELIST=/etc/sshd_config

to your '/etc/rkhunter.conf.local' file.

(Note: You can modify the main /etc/rkhunter.conf configuration file if
you wish, but I prefer to use a rkhunter.conf.local file instead to
contain any changes I make. If you modify the main config file, then
when RKH is next updated you will have to copy/paste your changes into
the new config file. Using a '.local' file avoids that.)

> 
> I then checked the file '/etc/sshd_config' but did not know what to
> look for.
> 
It is the fact that the file existed. Part of this specific rootkit is
to install an /etc/sshd_config file, so by checking if one exists hints
at the fact that a rootkit may be present.

>
> [15:02:38] Info: Using system startup
> paths: /etc/rc.d /etc/rc.local /usr/local/etc/rc.d /usr/local/etc/rc.local 
> /etc/conf.d/local.start /etc/init.d /etc/inittab
> [15:02:38] Warning: Checking for possible rootkit strings
> [ Warning ]
> [15:02:39]          No system startup files found.
> 
In your RKH config file add:

   STARTUP_PATHS=none

This will disable the tests that expect system startup files, or set the
option to the actual pathname for the files on your system (a quick
google check and I can't seem to find any other than /etc/rc.local
and /etc/rc. However, if you set the option to /etc RKH will check all
the files in there. Not really a good idea. I'll see if we can do
something about that in RKH.)

> 
> And warning no 3:
> 

> [15:06:08] Info: Starting test name 'startup_malware'
> [15:06:08]   Checking for system startup files
> [ Warning ]
> [15:06:08] Warning: No system startup files found.
> 
Setting the above option will disable this test.

> 
> Warning no 4:
> 
>              [ Warning ]
> [15:06:08] Warning: No shadow/password file found.
>
You can set the following option in your config file:

    PASSWORD_FILE=<path to password file>

RKH will try and determine where the password file is located, but if it
cannot then you get the above warning. Use the config file option to
tell RKH where your password file is located.
(Note: For other OS's this is actually the 'shadow' file, the file which
contains the actual passwords. The test is to see if an account has no
password, and to do that we need to check the file containing the actual
passwords (the shadow file), rather than the file just containing the
account names (usually the passwd file.))

If you could let me know the pathname of your file (email me off list
preferably) then it may be useful to get RKH to check for that
automatically for OSX users (assuming you are using some sort of
standard password file for OSX systems). I'll add the pathname into the
RKH code.

Again a quick google: It seems a /etc/passwd or /etc/master.passwd file
may be present. If either is, then set it in the above option. If
neither is, then you need to disable the password file checks. To do
this add 'group_accounts' to the DISABLE_TESTS list.

> 
> Several warnings, no 5:
> 
>         [ Warning ]
> [15:06:09] Warning: The SSH configuration option 'PermitRootLogin' has
> not been set.
>            The default value may be 'yes', to allow root access.
>
As the warning says, it seems that your /etc/sshd_config file has not
set the 'PermitRootLogin' option. This sometimes defaults to yes, which
would (obviously) allow root to directly log in. You do not really want
to allow this, so should set the 'PermitRootLogin' to 'no' in order to
disable root logins.

If on OSX the default is not to allow root logins via SSH, then you can
set the following option in your RKH config file:

     ALLOW_SSH_ROOT_USER=unset

>
> [15:06:10]   Checking if syslog remote logging is allowed
> [ Warning ]
> [15:06:10] Warning: Syslog configuration file allows remote logging:
> install.*                                             @127.0.0.1:32376
> 
Okay, that's an odd one. The test is to see if some form of remote
syslog logging is going on. However, as far as I remember the code does
not actually check to see if the 127/8 address is being used. It assumes
you are logging to some remote system. I will make a note to check that
part of the code, and correct it if necessary.

You can tell RKH that remote logging is okay by setting the following
option:

           ALLOW_SYSLOG_REMOTE_LOGGING=1

> 
> Several warnings, no 6:
> 
> [15:06:32] Checking application versions...
>
I'm not a great fan of this test at all, and personally would suggest
disabling it (add 'apps' to the DISABLE_TESTS list). However, if you
prefer you can whitelist the application versions in your RKH config
file using 'APP_WHITELIST'. If you look in the rkhunter.conf file you
will find some examples of its use.

> 
> At the beginning of the test, there was a warning for every file it
> checked, it started like this:
> 
> [14:49:55] Performing file properties checks
> [14:49:55] Info: Starting test name 'properties'
> [14:49:56] Info: Skipping all immutable-bit checks. This check is only
> available for Linux systems.
> [14:49:56] Checking for prerequisites                        [ OK ]
> [14:49:56] /bin/bash
> [ Warning ]
> [14:49:56] Warning: No hash value found for file '/bin/bash' in the
> rkhunter.dat file.
>
Yup, because of the missing hashes.


> [14:49:56] Warning: Unable to obtain current properties for file
> '/bin/bash'
>
It indicates that RKH could not determine properties of the file - e.g.
its permissions, size etc.

As far as as I can see OSX uses a BSD format of the 'stat' command.
However RKH does not know this. Try adding the following option to your
RKH config file:

  STAT_CMD=BUILTIN

This will use a supplied perl script.

To enable RKH to detect the correct use of 'stat' for OSX systems could
you run the following command for me please, and send me the output:

   stat -f '%i %Mp%Lp %u %g %z %m:' /bin/ls

It doesn't really matter whether you use '/bin/ls' or some other file,
it is the output of the 'stat' command that I want to see. Thanks.

> [14:49:57] Warning: Unable to obtain current write permission for file
> '/bin/bash'
>
Because of the above.

> 
> My foremost aim is to find out if this is a false positive 
> 
Since it seems most of the files/directories are not present, then I
would say so.




John.

-- 
John Horne, University of Plymouth, UK
Tel: +44 (0)1752 587287    Fax: +44 (0)1752 587001


------------------------------------------------------------------------------

_______________________________________________
Rkhunter-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rkhunter-users

Reply via email to