Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

intrusion detection/prevention



On Tue, Jun 30, 2009 at 10:08:25PM -0400, Tom Metro wrote:
> Dan Ritter wrote:
> > Tom Metro wrote:
> >> Most file system change detection tools work on a model where they set a 
> >> baseline and then once they detect a deviation from that baseline, they 
> >> email you perpetually until that baseline gets reset.
> > 
> > It's the only really useful way. There are two tricks:
> > 
> > - make it easy to reset the baseline
> > 	- a single word alias is best
> 
> What is the advantage of having that manual intervention? If you're 
> busy, and don't get to manually reset the baseline before the next 
> report, the deltas accumulate, and after a few days the reports become a 
> useless muddled mess.

Actual practice suggests that on stable production systems, this
does not happen.

My chief henchman reviews the reports daily, and less than once
per week brings something to my attention that requires a reset.

> unlikely prospect that an attacker breaches your system and resets the 
> baseline.

If you can't cope with the changes on your systems, there's
something wrong with your change management procedure.

> (If you've automated resetting the baseline to the point where it is a 
> single word alias, then you haven't really gained any security over a 
> system that automatically resets the baseline after changes are 
> reported. Once you've eliminated the use of a complex passphrase that 
> gets hand-typed, anyone who has gained root can circumvent the system. 

Anyone unauthorized who gains root has caused a disaster on that box. It
needs to be taken out of service immediately. Resident
filesystem integrity checkers don't solve this problem.

> Even then, I tend to think that as long as your database is hosted on 
> the system itself, the passphrase approach is more of an illusion. If 
> you want real security, you need to bypass the target system's kernel 
> and directly scan the drive using another host or a live CD.)

Yup.

-dsr-

-- 
http://tao.merseine.nu/~dsr/eula.html is hereby incorporated by reference.

You can't defend freedom by getting rid of it.






BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org