My sysadmin toolbox (Linux.com) [LWN.net]

My sysadmin toolbox (Linux.com)

Posted Apr 21, 2006 23:13 UTC (Fri) by danielpf (guest, #4723)
Parent article: My sysadmin toolbox (Linux.com)

"rpm -Va" does the rpm check.

to post comments

My sysadmin toolbox (Linux.com)

Posted Apr 23, 2006 16:05 UTC (Sun) by RPD (guest, #16045) [Link] (4 responses)

. . . and that's great, unless the person who cracked your system installed a new RPM with self-consistent checksums. With Tripwire you often keep the checksums off-system so modified files are harder to disguise.

However in my experience, rootkits and crackers in general rarely go to the trouble of installing new RPMs with proper signatures so rpm -Va does catch most problems.

My sysadmin toolbox (Linux.com)

Posted Apr 23, 2006 19:45 UTC (Sun) by ebirdie (guest, #512) [Link]

I just want to share another SA experience, I recently had, where verifying files from package checksums became handy in different context than system intrusion detection.

I had a nfs server with RAID10 disk set where 3 drives out of 4 broke in a row. Replacing disks and resyncing went fine one at the time and everything seemed ok for about a day. Disc replacements caused less than 3 minute downtime in service where the server had over 98% availability during its 17 months service. The 4th disk were already replaced early in its duty.

Then began big time problems. Exported file systems corrupted seriously. Everything were checked for the cause. No obvious fault were found. Between disk replacements no file system checks were made, so the conclusion was that possibly apparent simultaneousness of disc failures caused the corruption. The file systems were repaired and good copies of files were restored from backups.

Two days later the file systems became corrupted again. This time also the system's fs corrupted. The system were on RAID1 set on all 4 discs. Hardware was checked throughly and finally disk set were moved to another machine. The system seemed to work fine but after putting some pressure on it shared libraries didn't load and other obscure symptoms showed up. System backup was way too old to restore from and no debsums were installed. Restoring the system took much more time than if debsums were in place and helping in reinstalling only the needed packages. So the system was reinstalled and some files from the corrupted system were restored.

Again system worked fine for couple days and both the exported and system fs became corrupted. Things started to seem desperate. Now disk cables and disk enclosure were replaced. The discs were PATA drives and jumpering were already checked. We checked the drive jumpers twice now and finally noticed that the first replaced disc had wrong jumpering. The problem with jumpering were caused by the view angle.

The drive had to be removed from its cage to see the jumpers, but the cables were left connected. So the drive were turned over the connectors. After the jumper setting was correct the system were quick repaired with debsums.

No need to mention that service availability dropped in ten percents.

My sysadmin toolbox (Linux.com)

Posted Apr 24, 2006 16:26 UTC (Mon) by xorbe (guest, #3165) [Link] (2 responses)

or a bad guy that drops an rpm binary that never fails while checking other replaced binaries.

My sysadmin toolbox (Linux.com)

Posted Apr 24, 2006 17:30 UTC (Mon) by danielpf (guest, #4723) [Link] (1 responses)

If the bad person is able to install a fake rpm it means s/he can
also do pretty much anything, including installing a fake
tripwire.

My sysadmin toolbox (Linux.com)

Posted Apr 24, 2006 19:31 UTC (Mon) by jwb (guest, #15467) [Link]

That's why you shut down the system and boot it from protected media before running tripwire. Someone with root access to a Unix system can, indeed, do anything.