Warnings when running rkhunter

[nb8550]

Are these warnings normal when running rkhunter?

Warning: The file properties have changed: File: /usr/sbin/init
Warning: The file properties have changed: File: /usr/sbin/runlevel
Warning: The file properties have changed: File: /usr/bin/curl
Warning: The file properties have changed: File: /usr/bin/systemd
Warning: The file properties have changed: File: /usr/bin/systemctl
Warning: The file properties have changed: File: /usr/lib/systemd/systemd

Warning: The command '/usr/sbin/adduser' has been replaced by a script: /usr/sbin/adduser: Perl script text executable
Warning: The command '/usr/bin/egrep' has been replaced by a script: /usr/bin/egrep: POSIX shell script, ASCII text executable
Warning: The command '/usr/bin/fgrep' has been replaced by a script: /usr/bin/fgrep: POSIX shell script, ASCII text executable
Warning: The command '/usr/bin/ldd' has been replaced by a script: /usr/bin/ldd: Bourne-Again shell script, ASCII text executable
Warning: The command '/usr/bin/which' has been replaced by a script: /usr/bin/which: POSIX shell script, ASCII text executable
Warning: The command '/usr/bin/lwp-request' has been replaced by a script: /usr/bin/lwp-request: Perl script text executable
Warning: Write permission is set on file '/usr/bin/touch' for all users.

Warning: Suspicious file types found in /dev: /dev/shm/ecryptfs-juju-Private: ASCII text
Hidden directory found: /etc/.java

[1000]

I don't use it. but I'm guessing how it works.
Check also aide app.
https://en.wikipedia.org/wiki/Advanced_ ... nvironment

AIDE takes a "snapshot" of the state of the system, register hashes, modification times, and other data regarding the files defined by the administrator. This "snapshot" is used to build a database that is saved and may be stored on an external device for safekeeping.

When the administrator wants to run an integrity test, the administrator places the previously built database in an accessible place and commands AIDE to compare the database against the real status of the system.

If you update your system then you will see which files have been changed.


From main web page rkhunter
http://rkhunter.sourceforge.net/
you can find something what looking like documentation of rkhunter app
https://sourceforge.net/p/rkhunter/rkh_ ... /files/FAQ

4. ERROR AND WARNING MESSAGES
=============================
...
A. For rkhunter to perform file property checks, it must first
have a database file ('rkhunter.dat') containing the property
values for each file. It can then compare each files current
values against those stored in the database. Any difference
indicates that the file has changed. ...

I want to tell you that you are updating the system, so you need to know if the file was changed by you or someone else.

I can only advise you that you can try to combine system check with system update.
If rkhunter not found changes ; then update system ; and then build new / refresh database for rkhunter.
If rkhunter found changes ; then print log from rkhunter.

[t42]

For rkhunter to perform file property checks, it must first
have a database file ('rkhunter.dat') containing the property
values for each file.

No need in this while there is a native solution debsums available in the repositories.
Checksums of installed packages are already placed in /var/lib/dpkg/info/

Code: Select all

sudo apt install debsums

debsums -s this command check the MD5 sums of installed packages and report only errors.

More about it : man debsums

[Pjotr]

Don't use things like rkhunter in your desktop Linux:
https://easylinuxtipsproject.blogspot.c ... urity.html

[karlchen]

My point of view on advice like the one given below:

Don't use things like rkhunter in your desktop Linux:

In order to make use of rkhunter, you have got to know how it works. You will have to know the limitations of the approach, which rkhunter follows. You will have to be able to interpret its results.

So the question of whether rkhunter is a useful tool to somebody, does not depend on whether the person runs it on a Linux desktop system or on a Linux server system. It depends on whether the person knows how it works and its (serious) limits.

If somebody doesn't, then rkhunter will be equally useless on server systems and on desktop systems.

rkhunter(8) - Linux man page

[karlchen]

Hello, nb8550.

Summary:

Are these warnings normal when running rkhunter?

Such warnings are not uncommon.

Details:

When I read warnings like the ones you shared with us below

Warning: The file properties have changed: File: /usr/sbin/init
Warning: The file properties have changed: File: /usr/sbin/runlevel
Warning: The file properties have changed: File: /usr/bin/curl
Warning: The file properties have changed: File: /usr/bin/systemd
Warning: The file properties have changed: File: /usr/bin/systemctl
Warning: The file properties have changed: File: /usr/lib/systemd/systemd

then my approach is

• opening the rkhunter logfile /var/log/rkhunter.log
• locating every warning line and reading the additional details which are given inside the rkhunter.log
• trying to figure out whether the file properties have changed, because a legitimate software update from the official software repositories has updated the mentioned file.
  Also cf. t42's post on debsums, please.
• If the answer is, yes, software update, then the warning is harmless and I can go on to the next warning line
• Once all warnings have been cleared up as "caused by normal software updates from the repos", the logfile will be closed
• and the command "sudo rkhunter --propupd" will mark the current state as clean.
  (cf. https://linux.die.net/man/8/rkhunter)

About the warnings that binary executable files have been replaced by scripts:

Warning: The command '/usr/sbin/adduser' has been replaced by a script: /usr/sbin/adduser: Perl script text executable
Warning: The command '/usr/bin/egrep' has been replaced by a script: /usr/bin/egrep: POSIX shell script, ASCII text executable
Warning: The command '/usr/bin/fgrep' has been replaced by a script: /usr/bin/fgrep: POSIX shell script, ASCII text executable
Warning: The command '/usr/bin/ldd' has been replaced by a script: /usr/bin/ldd: Bourne-Again shell script, ASCII text executable
Warning: The command '/usr/bin/which' has been replaced by a script: /usr/bin/which: POSIX shell script, ASCII text executable
Warning: The command '/usr/bin/lwp-request' has been replaced by a script: /usr/bin/lwp-request: Perl script text executable

Replacing binary executable files by scripts, which may call the original executable plus some malicious executables, is one of many approaches, used by malware.
Therefore rkhunter warns wherever it expects to find a binary executable, but comes across a script.
Sadly, life is not as simple as that:
Not only malicious guys replace binary executables by scripts. Some Linux distros (all Linux distros?) do so as well.

As a consequence, it will be necessary to check for each item in the list above, whether your distro (Linux Mint) in an untampered with state comes with the mentioned instances, where it uses a script, although rkhunter expects a binary executable.
Such instances, which are normal for your distro, can be and should be then whitelisted by you in the rkhunter.conf file, so that rkhunter will not complain about them again in future.
(cf. https://linux.die.net/man/8/rkhunter)

Warning: Write permission is set on file '/usr/bin/touch' for all users.

Here on my system /usr/bin/touch is a symlink pointing to the executable /bin/touch. The symlink is owned by root, but the access permission suggest it were world writable. The executable /bin/touch is not.
In brief: false positive.

Essence:
rkhunter is not a tool, which can simply be used every once in a while ad hoc and out of the box in order to determine whether your system may or may not have caught a rootkit. Cf. https://linux.die.net/man/8/rkhunter You have to really understand how rkhunter works, what it can do and all the things which it cannot do.
If you use it without being aware of its approach and of its serious limits, then it is not unlikely either to give you heart attack or a false feeling of being on the safe side.

Regards,
Karl

[1000]

No need in this while there is a native solution debsums

This solution, of course, depends on the needs.
In this case, what level or what kind of security.
It's good to know how these tools working.
Therefore, I agree with the post above.

It looks rkhunter is a combination of several tools.
I focus on the files database because in my opinion this is the most important tool.

Once I made a script for myself that also creates a database of files.
- I had to skip files that are temporarily in memory but mounted to a directory.
So-called virtual files.
- I had to skip the files in the temp directory /tmp because in Linux Mint they are deleted every time I start my computer (This is good).
And because this is spam over which I have no influence, only apps.
- I had to partially skip the configuration files. Because they change very often.
Configuration files are files in /etc and files in the user's directory.
I have spam of these files. So I have to learn which files are more important.
- I had to omit some files in the /var directory. Mainly system logs.

So, in theory, the possibilities may be greater. (Maybe this is not the best tool but I can use this to find config file / to debug app )
Perhaps you can set the security level in a configuration file ( more info probably in manual ).

I can say a bit about AIDE because I know it.
It is essentially one tool. Its task is to check if the file has been changed.
It can checks both the checksums and the modification date.
Depending on the configuration, it can use several checksums simultaneously.
Personally, I think there is one main problem .
You can never trust a compromised operating system.
Therefore, it may be better to check the system from a USB stick ? ( USB live iso )
Assuming that the USB memory will lie ( will be located ) in a safe place.

check the MD5 sums

It's still a good tool for checking for errors.
When it comes to security, MD5 is a weak solution today, not recommended.
A way to bypass MD5 has already been presented. https://en.wikipedia.org/wiki/Secure_Hash_Algorithms
Checksums never guarantee 100% security. We call it safe until a workaround is found. ( " Collision attack " )
Newer solutions are a bit safer, but take up more space and time.
Only a backup and bit-by-bit checking of the file can do this. But this is impractical due to the need to have space for files.

[nb8550]

Thanks a lot for the feedback, will try to learn more about rkhunter and how it works when I have time.

[beepjeep]

Hi nb8550,

I am also new to rkhunter and I got exactly all the same warnings as you with the "Warning: The command '/foo' has been replaced by a script: "bar"". I am running Ubuntu 20.04. Hope that helps.

[Termy]

Code: Select all

Warning: The file properties have changed: File: /usr/sbin/init
Warning: The file properties have changed: File: /usr/sbin/runlevel
Warning: The file properties have changed: File: /usr/bin/curl
Warning: The file properties have changed: File: /usr/bin/systemd
Warning: The file properties have changed: File: /usr/bin/systemctl
Warning: The file properties have changed: File: /usr/lib/systemd/systemd

These messages are typically trivial and just par for the course after an update — obviously an update will change the contents of various files, like those mentioned in your rkhunter(8) log file. If you see stuff changed which you didn't update (directly or indirectly), then it's a cause for concern.

Code: Select all

 Warning: Suspicious file types found in /dev: /dev/shm/ecryptfs-juju-Private: ASCII text

No idea — sorry. Look online. TBH, it's probably nothing.

Code: Select all

 Warning: Write permission is set on file '/usr/bin/touch' for all users.

This is definitely alarming, although not necessarily in some huge "I'm being hacked!" way. It should not be so, unless there's some outlandish genuine reason for it. Possible a bug in a recent update caused this? Look into it.

Code: Select all

 Warning: The command '/usr/bin/lwp-request' has been replaced by a script: /usr/bin/lwp-request: Perl script text executable

This is normal, and has been normal for years. It doesn't guarantee that it wasn't replaced by something malicious which is a script, or that the existing benign script hasn't been meddled with, but it is otherwise normal. This can be confirmed by looking online, if you need peace of mind.

Code: Select all

 Hidden directory found: /etc/.java

Hidden things like that are weird and not generally normal in those sort of locations, but in this case, it looks benign, if it's this. I don't use Java, but I've known about that warning for years.

Code: Select all

 Warning: The command '/usr/bin/which' has been replaced by a script: /usr/bin/which: POSIX shell script, ASCII text executable

As the warning correctly states, it's a POSIX shell script, and should be entirely normal, although my caution above, for the 'lwp-request' script, applies here and with the warnings below.

Code: Select all

 Warning: The command '/usr/sbin/adduser' has been replaced by a script: /usr/sbin/adduser: Perl script text executable

This is normal. It's a PERL script on my system, too. It's a handy wrapper for usermod(8).

Code: Select all

Warning: The command '/usr/bin/egrep' has been replaced by a script: /usr/bin/egrep: POSIX shell script, ASCII text executable
Warning: The command '/usr/bin/fgrep' has been replaced by a script: /usr/bin/fgrep: POSIX shell script, ASCII text executable

These are normal, albeit long since deprecated. They're simple (and pointless, TBH) wrappers for grep(1).