Date: Sat, 8 Sep 2001 17:16:42 -0500 From: D J Hawkey Jr <hawkeyd@visi.com> To: Krzysztof Zaraska <kzaraska@student.uci.agh.edu.pl> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Kernel-loadable Root Kits Message-ID: <20010908171641.A79354@sheol.localdomain> In-Reply-To: <Pine.BSF.4.21.0109081905250.1015-100000@lhotse.zaraska.dhs.org>; from kzaraska@student.uci.agh.edu.pl on Sat, Sep 08, 2001 at 08:07:14PM %2B0200 References: <20010908102211.A77764@sheol.localdomain> <Pine.BSF.4.21.0109081905250.1015-100000@lhotse.zaraska.dhs.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 08, at 08:07 PM, Krzysztof Zaraska wrote: > > On Sat, 8 Sep 2001, D J Hawkey Jr wrote: > > > Except for a ctime change on /tmp (or wherever), you're right. > > But activity in /tmp is normal and will be ignored by tripwire, right? Tripwire's policy file can reflect nearly any level of Admin paranoia. > > I've added quite a bit of stuff to /etc/security. > > If it doesn't affect your security will you tell us what checks do you > recommend? Well, I'm no expert (witness my blunders around here), but depending on the box's purpose(s), I've added the following log messages: - successful logins (in addition to failed ones) - denied SSH authentications, and maybe successful ones, too - selected HTTP entries - selected 'ipmon' entries - selected entries from a home-brewed periphery monitor The latter two are rather closely mated to their tool's rulesets. The last is something of a heuristic pattern matcher that "blacklists" perceived port scanners in semi-realtime. Not too sophisticated, but it shows promise as I continue to build on it. I seem to be developing a pattern of tweaking /etc/security to reflect the realities/interests of the moment. Were I to build an FTP server or a shell server, I'm sure I'd want to see different stuff from them. Maybe I'm too dependant on the logs as my reporting data, but ipfilter and tripwire continue to continue should a cracker wipe the log files. Or perhaps I place too much confidence in those tools, too? Gee, do ya think I second-guess myself a lot? ;-, > > > We may also consider adding a feature to kldload to load only modules > > > from under /modules but I'm afraid this may be circumvented by attacker > > > fetching her own kldload. A better way would be to implement an > > > appropriate lock in kernel code but I don't know if it's possible. Who's the "we"? The FreeBSD project? > > The first pro'lly isn't worth the effort. > > > > You lost me with the last bit; a lock to determine or do what, prevent > > userland 'kldload's? This would seem to be a Good Thing(tm), but how do > > you lock the lock - or would this be a kernel build-time option? > > A kernel option that would do some extra checks with kldload(2) or > underlying functions. For example, the simplest thing would be to make > sure that the module is loaded from under /modules, since that tree is > static and watched by tripwire as you said. Ah. > Or, something LIDS-like. You're the second to mention LIDS. I know so little about it as to refrain from comment (like, why should I let that stop me now?). Based on another's description, it strikes me as rather over-engineered, but that's an ignorant opinion. Maybe it has to be. RedHat does seem more dependant on LKMs than FreeBSD and KLDs, at least out-of-the-box, so perhaps the modules are more of a security issue? > > All in all, it seems to me a kernel that needs no KLD modules, and denies > > all KLD loading, would be the easiest and most effective solution. > > Definitely. > > However, I can see an exception. At least in Linux world (where i come > from ;)) some time ago there were proprietary device drivers (sound cards, > IIRC) distributed as compiled modules. So you needed module support. There > may be a similar situation in the future, that say some SuperHardware Inc. > releases it's new 10Gbit ethernet adapter giving away the compiled drivers > as modules and not releasing the source code nor the hardware > specifications. In this case you need module support, at least at boot > time. Or, wait for the more open-minded competition that'll be along shortly. :-) So far, out of this whole thread, I'd first wish for hacks to the kernel that deny KLDs. Were that I had the time to immerse myself that deeply... > Kris Dave -- Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" 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?20010908171641.A79354>