Date: Wed, 19 Jun 2002 11:50:43 +0200 From: Maxlor <mail@maxlor.com> To: "freebsd-security@FreeBSD.ORG" <freebsd-security@FreeBSD.ORG> Subject: Re: preventing tampering with tripwire Message-ID: <2799555.1024487443@[10.0.0.16]> In-Reply-To: <27700541.1024450071@[10.0.0.16]> References: <27700541.1024450071@[10.0.0.16]>
next in thread | previous in thread | raw e-mail | index | archive | help
Thank you guys for your answers. Let me just comment on a few things: Putting the tripwire binary on an external, read only drive doesn't help. As I mentioned, an attacker who gained root could simply unmount the disk and place a tampered copy into the mountpoint dir. I would only notice this if I happened to have a closer look at df *and* the attacker was nice enough not to modify df too. Similar with making MD5 hashes of the tripwire binary. The MD5 program could be modified to always generate the same hash for tripwire. Using an external machine for generating and saving the hashes would be ok, but this would either require handwork (create a ssh connection, start the hashing), or somehow making the file system available to this machine, which would imo create a bigger security hole than it tries to cover. Making the whole system read only would help, alas it's not possible since I actually need to use my machine :-) Having some tools (tripwire, MD5) on a floppy, and mounting and checking the files by hand would work, imo. Only problem is that this adds quite a bit of inconvenience, which would lead to me not doing it anymore when I get tired of it. I mean, it's simple - I just want a tripwire report in my Inbox when I wake up in the morning :-). So, what I did so far is this: - Setting the schg flag for /usr/local/sbin/tripwire, /etc/crontab and /usr/sbin/cron. I set the flag for the cron files too so an attacker doesn't just delete the crontab entry and add 'cat fakereport.txt' in its place :). - Change kern.securelevel to 1. This prevents modifying any file which has the schg flag set. The securelevel cannot be lowered without a reboot. I've got to think a bit about how preventing a lowering through rebooting... maybe schg'ing /etc/rc and /etc/rc.conf? I actually went so far as to schg /sbin, /bin, /usr/sbin and /usr/bin. These will only be changed on a make world, and I need to drop to single user mode for that anyway, so no inconvenience should be created through this while my executables gain some reliability. Why do I like this solution a lot? Even if my system was rooted, and the attacker had enough skills to replace each binary with a compromised version that would look the same to me, he couldn't do so without dropping to single user mode. And since he'd have to have physical access to the machine for that, I think I can say the machine gained some reasonable security against rootkits overall. Thanks again for all your thoughts. Greetings Maxlor To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2799555.1024487443>