Thanks Mike, great input. My plan is to keep the md5sum, find and grep binaries on the floppy. They still require system .so libraries but those will be harder to hack. A bootable CD is a good idea, but I'd like to be able to check without taking the servers down.
I'll definitely add to the list of included files, and also compress the floppy-based md5sum output. Also I think I might avoid "md5sum -c" and instead create a new list, and then use diff to compare the two. This will guard against a black hat *adding* an executable that was not there before, and also avoid the bugs that you mention. Thanks again, -- Rod http://www.sunsetsystems.com/ On Saturday 14 December 2002 11:27 am, [EMAIL PROTECTED] wrote: > On Fri, Dec 13, 2002 at 02:41:00PM -0800, Rod Roark wrote: > > why it has to be so complicated. > > Rod, > It doesn't have to be complicated... > > > Any comments or suggestions for improvement will be much appreciated: > > 0 - The md5sum binary and the bash scripts you are running can not > be entirely trusted, because they are running on a possibly tainted > system. If you want more certainty, I would recommend customizing > a bootable rescue CD to have the commands you want which feeds off > of a floppy for the dynamic data, this way you can trust the kernel > and environment your checking system runs in. Maybe have a small > bootup menu which asks for 'check floppy against current system', > 'archive partition Foo state to floppy'... etc. > > 1 - You most likely will want to include files that aren't executable in > your system md5sum database. Things like /lib don't have to be > executable but if they are changed can easily provide any backdoors > required... > > 2 - The following find may work quicker, because it doesn't fork once > per file... > find / -xdev -type f -perm +111 -print0 | xargs -0 md5sum > > [when tested on the demo box the -exec method takes 55 seconds > of CPU time, but runs about 5:20. the xargs method takes 38 seconds > of CPU time, and runs in 5:40... so it's faster CPU wise, but probably > because of additional seeking slower wall clock] > > 3 - If you have multiple processors... or have some sort of RAID being > attacked (so multiple IOs aren't going to slow you down)... > you can get xargs to run multiple md5sum worker jobs: > find / -xdev -type f -perm +111 -print0 | xargs -0 -P 4 md5sum > > 4 - If you find a significant speedup doing the xargs style md5sums > the following may speed up finding the bad files: > sort -k 2 < md5sum.old > old > sort -k 2 < md5sum.new > new > diff -u 1 old new | perl -ne 's/^+\S+\s+// or next; print $_;'; > > 5 - Bzip2 compressing the md5sum list before storing on the floppy will > greatly increase your available archive area... > > 6 - While looking around at the md5sum source code I noticed that if the > complete path name of a file to check is over 255 characters, when > reading the input file of checksums for the '-c' option, that line > will *silently* be ignored... > /usr/local/lib/some_one_put_trojans_here/plus_200_charac...ters/foo > > Also since the -c option works by reading lines it doesn't handle > file names with newline characters in their names. If may be possible > to play some games with newlines that prevent detection of changed > files. Since it will also silently ignore any line that doesn't > parse right... you may want to use something other than -c to check. > [the sort above also expects newlines on a line... but at least > diff will still find something has changed if anything fishy > happened]. > > I think I should stop now... > > TTFN, > Mike > > [ps: if you are interested in a patch to md5sum that fixes the silent > dropping of long lines and unparsed lines... I could supply something] _______________________________________________ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
