[vox-tech] Easy tripwire alternative

Rod Roark vox-tech@lists.lugod.org
Sat, 14 Dec 2002 12:08:16 -0800


Thanks Mike, great input.

My plan is to keep the md5sum, find and grep binaries on the=20
floppy.  They still require system .so libraries but those=20
will be harder to hack.  A bootable CD is a good idea, but=20
I'd like to be able to check without taking the servers=20
down.

I'll definitely add to the list of included files, and also=20
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, msimons@moria.simons-clan.com wrot=
e:
> 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 i=
n
>     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 secon=
ds
>      of CPU time, and runs in 5:40... so it's faster CPU wise, but prob=
ably
>      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 th=
e
>     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/f=
oo
>
>       Also since the -c option works by reading lines it doesn't handle
>     file names with newline characters in their names.  If may be possi=
ble
>     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=
=2E
>     [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]