• Introducing WebPros Cloud - a fully managed infrastructure platform purpose-built to simplify the deployment of WebPros products !  WebPros Cloud enables you to easily deliver WebPros solutions — without the complexity of managing the infrastructure.
    Join the pilot program today!
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.

updated version of rkhunter for CentOS5

G

greyman56

Guest
Hi All, and happy new year to you.

I am looking for the best solution to the following errors we get when running a security scan from the watchdog module.
Determining OS... Unknown
Warning: This operating system is not fully supported!
Warning: Cannot find md5_not_known
All MD5 checks will be skipped!

Now I see from posts on the rkhunter mailing list that this OS may be supported if the hash values and prelinking database are rebuilt. They used a shell script called hashupd.sh but that stopped at version 1.2.9 and it is not available on rkhunter's download page at sourceforge any more. The bundled rkhunter version in psa-watchdog is 1.2.8.

I also found that rkhunter has support for CentOS 5.2 as of version 1.3.2 and it has a command line option to rebuild hash values. I believe that it is available over at ART repo, but it does not replace psa-watchdog but is a separate rkhunter rpm.
See this thread for intro and problem with the watchdog

So am I better off upgrading rkhunter (from ART or elsewhere) or finding the old hashupd.sh script and updating the hash values on the supplied rkhunter version 1.2.8?

Any hints and instructions would be most appreciated.

Thanks
Graham
 
You might be able to do some symlink hackery to get the plesk one to use the more standardized version that Ive got in atomic. Ive been meaning to try that myself, but I havent had the time to see what would happen.
 
You might be able to do some symlink hackery to get the plesk one to use the more standardized version that Ive got in atomic. Ive been meaning to try that myself, but I havent had the time to see what would happen.

Thanks ART

I am not all that experienced with rkhunter personally, but I guess I will know much more soon <grin>.

If I understand you correctly:-
- the download from atomic channel will install in a different location to the Plesk one from watchdog.
- as installed, the new rkhunter will be able to be run from a shell or cron separately from the plesk one.
- to get plesk to do the regular security scans using the new version I would rename the plesk supplied executable and replace it with a symlink to the new one.
- Would we get the new rkhunter to use the plesk supplied conf (in /usr/local/psa/etc/modules/watchdog/) and thus, I would hope, the data files (in /usr/local/psa/var/modules/watchdog/lib/rkhunter/db) by renaming /etc/rkhunter.conf and symlinking to /usr/local/psa/etc/modules/watchdog/rkhunter.conf?

Plesk obviously plays with their own conf file because it has the system admin email address in it. So it would probably be best to use their conf IMHO.

I also notice that Plesk must pass the location of the conf file to rkhunter when it invokes it because running the plesk rkhunter by itself barfs with a notice about not finding the conf file (in another location).

If all this be the case, and the symlinks I described are the way to go, do you think we would need to do a rkhunter --propupd once this has been done to update the database? Or would this do damage to the DB?

If this sounds right, I might give it a go on a recent psa8.6 install in the next day or two.

Cheers
Graham
 
Well that did not work. The processes just did not run. I think it may have something to do with the scripts directory.

So I tried to do it another way. Link the executable to the new version, link the watchdog conf file to /etc/rkhunter.conf file, and thus use the new package entirely. This seemed to work at first, but it got ansi excape sequences in the modules/watchdog/security window and then a heap of grep broken pipes.

So I tried moving the log file location to the psa desired one, but that seemed to break it totally and I saw a few defunct rkhunter processes.

If I ran the new rkhunter with the --configfile <psaconffile> option, it barfs with an issue with i18n directory missing. This would most like be due to the INSTALLDIR directive at the end of the PSA rkhunter conf file.

So I have returned the system to itrs original state I think, and will have anmother crack at it later.

If anyone has any ideas to try, please let me know.

Cheers
Graham
 
Well I am not sure I can get this thing to go properly.

When re-establishing the plesk binary and conf file, I found that the plesk version would not run in the GUI and for the life of me could not get it happening properly.

I had to uninstall the watchdog module and re-install it to make it go.

I have resorted to disabling the plesk rkhunter (disable repeat security scan in watchdog preferences) and relying on the ART package which has a cron job that is run in /etc/cron.daily/

This means that we cannot run an ad-hock security scan from the GUI, only from SSH.

If someone comes up with an answer to running them properly together, please let us know.

It would, of course, be better if Parallels just updated their software to the latest version and gave us an updated watchdog package. But that is probably too much to ask.

thanks
Graham
 
The last time I asked PSA about this (was back in 8.0) they had told me that the rkhunter in watchdog is located at /usr/local/psa/libexec/modules/watchdog/security/ and that I can change the command line options there

I seem to remember manually upgrading and installing rkhunter over the version psa gave me, changing the options in that flie and upadting the config files (and putting them in the command line) and it worked ok.

I've long ditched watchdog as its a POS and have opted for other external monitoring using SCOM instead.
 
I have resorted to disabling the plesk rkhunter (disable repeat security scan in watchdog preferences) and relying on the ART package which has a cron job that is run in /etc/cron.daily/
Although the ART package is running, it gives me plenty of errors that do not make a lot of sense to me. Should I be concerned about these?
OS: centos-release-5-2.el5
PSA: psa-8.6.0-cos5.build86080722
rkhunter-1.3.4-1.el5.art

I have done a rkhunter --propupd

Here is an output from one, they are all mostly the same, just different PID numbers.
---------------------- Start Rootkit Hunter Scan ----------------------
Warning: The following processes are using deleted files:
Process: /usr/sbin/httpd PID: 1759 File: /lib/libuuid.so.1.2
Process: /usr/local/psa/admin/bin/httpsd PID: 5142 File: /lib/libuuid.so.1.2
Process: /usr/local/psa/admin/bin/httpsd PID: 5154 File: /lib/libuuid.so.1.2
Process: /usr/local/psa/admin/bin/httpsd PID: 7190 File: /lib/libuuid.so.1.2
Process: /usr/sbin/httpd PID: 11540 File: /lib/libuuid.so.1.2
Process: /usr/sbin/sshd PID: 12166 File: /lib/libpthread-2.5.so
Process: /sbin/udevd PID: 14309 File: /lib/libnss_files-2.5.so
Process: /usr/sbin/crond PID: 15759 File: /lib/libnss_files-2.5.so
Process: /usr/sbin/saslauthd PID: 15769 File: (deleted)
Process: /usr/sbin/saslauthd PID: 15771 File: (deleted)
Process: /usr/sbin/crond PID: 15965 File: /lib/libnss_files-2.5.so
Process: /usr/sbin/httpd PID: 18270 File: /lib/libuuid.so.1.2
Process: /sbin/rsyslogd PID: 19749 File: (deleted)
Process: /sbin/rklogd PID: 19753 File: (deleted)
Process: /usr/sbin/httpd PID: 25911 File: /lib/libuuid.so.1.2
Process: /usr/sbin/httpd PID: 26154 File: /lib/libuuid.so.1.2
Process: /usr/sbin/named PID: 32357 File: /lib/libpthread-2.5.so
Process: /bin/bash PID: 32400 File: (deleted)
Process: /usr/libexec/mysqld PID: 32464 File: (deleted)
Process: /usr/sbin/httpd PID: 32582 File: /lib/libuuid.so.1.2
Process: /usr/local/psa/admin/bin/httpsd PID: 32604 File: /lib/libuuid.so.1.2
Warning: Hidden processes found: 735
3026
3028
3036
3038
3044
3046
3054
3056
4118
4130
6166
10516
[a long list of these - different lengths each day]
31440
31441
31442
31443
31444
31446
31447
31448
31449
31558
31580
Warning: File '/tmp/psa_8.6.0_cos5.build86080722.00_installing.081219.14.50.log' (score: 220) contains some suspicious content and should be checked.
Warning: File '/tmp/monitrc.chk' (score: 271) contains some suspicious content and should be checked.
Warning: File '/tmp/psa-libpam-plesk_8.6.0_cos5.build86080722.00_problems.081219.14.50.log' (score: 200) contains some suspicious content and should be checked.
Warning: Checking for files with suspicious contents [ Warning ]
Warning: Found enabled xinetd service: /etc/xinetd.d/ftp_psa
Warning: Found enabled xinetd service: /etc/xinetd.d/poppassd_psa
Warning: Found enabled xinetd service: /etc/xinetd.d/smtp_psa
Warning: Found enabled xinetd service: /etc/xinetd.d/smtps_psa
Warning: No output found from the lsmod command or the /proc/modules file:
/proc/modules output:
lsmod output:
Warning: The kernel modules directory '/lib/modules' is missing or empty.
Warning: Suspicious file types found in /dev:
/dev/shm/suspscan.9755.strings: ASCII text
 
Back
Top