System Integrity checker

[geolaw]

Many moons ago I wrote a set of scripts much like csf. I am glad great minds think alike

I know this is a tricky one, but one improvement I would like to see is a way to set up a set of files which the System Integrity check will restore if they are modified.

For instance, sshd, ps, etc...

Last year, one of my servers was compromised but I caught it immediately (thanks to csf!) however, it was late at night and there was a good chance I would not have caught it until the next morning. I got an email about sshd being replaced along with a few other commands.

the packages in question would have to be excluded from system updates (up2date, upcp, etc...) but this would provide a healing option

Another suggestion would be perhaps to use dnotify or inotify for monitoring these files which would provide more of an instantaneous trigger.

Just my 2 cents

--
George

[chirpy]

I've played with inotify for monitoring files, but it's only available (as standard) in the RHE/CentOS v5 kernel onwards and dnotify in the earlier kernels isn't reliable. It's something for the future, though.

I'll have a think about the other issues you raise regarding binaries and rootkits

[geolaw]

thanks for the quick response.

I have used dnotify on several rhel4 machines and it has always seemed fairly reliable. there are some weird things that happen file system wise.

For instance ... One instance I often use dnotify is to monitor files for uploads and then trigger a script to process the uploaded file. I have done this with video files that get uploaded and have it trigger off a script which calls ffmpeg/mencoder to convert the files over to flv.

With pureftp, the files come in as .pureftpupload-xxxxx where xxxx is some unique string. Once the upload completes, the file is renamed to match the client side.

Running dnotify with the -R option, to catch renames works, however, it also gets triggered if a duplicate file is getting uploaded ... so my guess is that when the original file gets deleted to make room for the new version, dnotify mistakes the deletion for a rename.

This is easy enough to check for in the script dnotify invokes, but it just takes a while to really figure out what the heck is happening


The 'auto heal' option I mention can be tricky - because redhat can throw out an update to sshd to fix a newly published exploit and the update is really needed before the exploit becomes viral and spreads throughout the hacker community. So, some cases, you would want to over ride an auto heal.

On a rpm based system, it might be possible to call rpm to verify the package the changed file belongs to...
something like :
rpm --verify `rpm -qf /usr/sbin/sshd` |grep /usr/sbin/sshd

if the RPM database indicates a change as well as the lfd MD5 check, replace the file with the known good replacement, otherwise accept the change and save the new version "in the vault".