rkHunter package manager fail warnings on CentOS 5 running WHM 11
 

Hello All!

I have a dedicated box at a pretty reputable hosting provider that I am using to develop a website... I'm primarily a web developer and a Linux n00b.

I have secured the box with the usual items; locked down WHM, set-up breach detection, changed ssh ip/port, disabled root, installed rkHunter etc.

I am now receiving "Package manager verification has failed:" messages from rkHunter for /bin/su and /usr/bin/perl. I believe this has something to do with changes made in WHM (wheel group and disable compilers for unprivileged users), but I cannot be sure; I've rpm -Vf both files and get the same errors.

Can WHM cause these errors from rkHunter and how do I verify this? Also, if in fact it was caused by WHM, how do I update the rpm database to recognize the changes and prevent these messages?

I've searched the forums and haven't been able to find an answer; hopefully some one here can help.

Any help would be greatly appreciated!

Blik

Welcome to LQ, hope you like it here.

Being new to Linux is nice, just don't mistake it as a perpetual license to stay uninformed OK?


Sounds fab but what does "set-up breach detection" really mean? Also understand that due to the nature of the tools running OSSEC HIDS, Chkrootkit and Rootkit Hunter is nice but it does not constitute "a complete security solution" nor does running it substitute prior and proper hardening.


If you read the RKH documentation you notice John and I set the Sourceforge-based rkhunter-users mailing list as primary point of contact in case of help.


"Package manager verification has failed" messages are part of the file properties check. You don't update the RPMDB. On verified change you run 'rkhunter --propupd'. Also RKH allows you to exempt a file from any package manager verification using the "PKGMGRNOVRFY" white list in rkhunter.conf. The file will then be checked as if it was a non-packaged file. This stops user-modified files from issuing warnings.

Thank you for the welcome unSpawn and the reply... it is very helpful!

Two quick follow-up questions:

Is there a tutorial you can point me to that explains proper hardening of a server? The items I put in place were mostly from this and similar forums and dealt with WHM and basic linux items... never went into the kernel or anything like that.

Is there a way to verify the packages using RPM (or similar) before placing them on the RKH white-list? I would like to make sure they are in fact 'user-modified' by the WHM instead of malicious files / modifications.

Thank you again!

Blik

Apart from the suggestion of running Aide, Samhain or even tripwire, running 'rpm -Vv [packagename]|grep -v "^\.\{8\}";' gets you the modification alerts if any. To investigate changes you would need to compare with 0) yum log if changes due to package ops seem plausible, 1) a "known good" copy in your backup if item #0 is not or 2) a "known good" copy from a trusted repo if the above doesn't apply.


Red Hat, Fedora and any RHEL derivatives due to Red Hat legacy, come with extensive documentation. If you use RHEL or a derivative then you should read the Red Hat Enterprise Linux 5 Installation Guide and the Red Hat Enterprise Linux 5 Deployment Guide to get acquainted (also see: Rute Tutorial & Exposition, Linux Documentation Project, LinuxSelfHelp, Linux Newbie Admin Guide) with your distribution and because the installation defaults and suggestions provided are sane operational and security defaults.
* You see there's not one single manual as there is no single fix and security does not equal applying any single fix either: security is a perpetual process.


I suggest reading the NSA Guide to the Secure Configuration of Red Hat Enterprise Linux 5 (PDF), the NIST SCAP Guide To The Secure Configuration of RHEL5 and when you start to grok the playing field with respect to vulnerabilities and attacks the Hardening Red Hat Enterprise Linux 5 presentation (PDF) by Steve Grubb of Red Hat. I'm deliberately placing the NSA Hardening Tips For Default Installation of Red Hat Enterprise Linux 5 (PDF) cheat sheet here snice you should not be looking for quick fixes and leave the rest for later: security is not to be bolted on as afterthought. For Fedora you'll find documentation at their site and the Securing Debian manual is one of the oldest and most all-encompassing ones. I still use it as "meditation". Also there's whole sections of the SANS Reading Room or you could also try the first part of the first post and the sixth post of the LQ FAQ: Security references.
* Do pace yourself and realize half of knowledge is not in knowing but knowing where to find sources of knowledge.


What does this all lead to? First and foremost: reading. Secondly: thinking before you act. because creating baseline data (a mix of "known good" distribution packages, off-site backups, system configuration placed under version control) should be done right after OS installation (and before alterations) after which you would perform local tests with like GNU Tiger or the SCAP tools or using the Center for Internet Security benchmarks and an assessment from a networked point of view (use a remote host) using say OpenVAS or Nessus. Depending on machine purpose this should give you a better view of what is in need of hardening as opposed to just installing some tool like RKH and just running it. There are many roads leading to Rome (or Wome as MPFC fans would have it) so alternative paths to hardening are possible, however the documents and sites mentioned above are about propagating and applying security standards. Adherence requires you to invest time and effort. The end result, your ROI, will be running GNU/Linux protecting assets and providing services in a continuous, stable and secure way.
* Use what you learn well: Linux may be free to use but using it is not free of responsibilities.


HTH & GL

Thank you unSpawn!!!

All of those are very helpful and a great resource... I really appreciate it.

Time to hit the books...

Blik