[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]