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 |
On Tue, Jun 30, 2009 at 04:02:51PM -0400, Tom Metro wrote: > ref wrote: > > TRipwire annoyed me as it emailed me masses of stuff > > everyday about what had NOT changed. > > When I used Tripwire I also found that it required a lot of maintenance > in order to make it provide useful reports. If you don't keep up with > it, it ends up flooding you with useless reports (reporting the same > changes over and over), which leads to the reports being ignored. > > 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. This is the > secure, paranoid way to do it, but not particularly practical. It's the only really useful way. There are two tricks: - make it easy to reset the baseline - a single word alias is best - map exactly what parts of your filesystems you can ignore - in particular, you need to have the monitor automatically ignore logs, temp files, pidfiles, mail spools and user home directories > Back when I set up my first Debian system I went looking for something > simpler than Tripwire, and ran across Integrit, and have been using it > ever since, even though it remains fairly obscure. It was easy to set > up, and with a few tweaks to to its cron script, I was able to have it > automatically reset its baseline after changes. This eliminates > maintenance effort, and it only generates reports if there have been > changes since the last change occurred, so most of the time it stays quiet. Integrit is pretty good. So is AIDE. > Note that although these file system change detection tools are often > promoted as intrusion detection tools, they're actually more beneficial > for routine system administration by providing a record of what system > files changed when. This can be useful if system behavior changes and > you want to track down when a config was modified or when some upgrade > changed a shared library. Though there are three better tools: - keep your configurations in a version control system - and/or keep snapshots of your configurations (or whole filesystems) - look in your OS package installation log (/var/log/dpkg, for instance) -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 | |
We also thank MIT for the use of their facilities. |