Very valuable insights. That’s a great idea. The rysnc script was ksh/bash or cron? Ideally I’d like to use Python to tackle something like this but I’m not against learning shell.
> On Apr 4, 2022, at 2:02 PM, Nick Holland <n...@holland-consulting.net> wrote: > > On 4/4/22 11:32 AM, Eric Thomas wrote: >> I want to have a high degree of confidence in my system's state >> (packages that have been added, configs that have changed, permissions >> changed, etc). I've read about "read only filesystems" and the >> pro's/con's [here](http://geodsoft.com/howto/harden/OpenBSD/no_changes.htm). >> Aside from that, is there a way to... >> 1. ...hash the file system in some way and monitor for changes? OR >> 2. ...somehow review changes that have taken place (a log somewhere)? >> The goal is to concretely know whether the state of the system has >> changed, then point to what EXACTLY has changed. >> Anyone doing something similar? >> Thank you > > Something I came up with which worked out really well at my employer was > a backup system that used rsync and the --link-dest option to make a useful > rotated disk-based backup of current systems. When they said, "We want some > kind of file integrity monitoring system", I puzzled over all kinds of ways > to look for altered files...but it suddenly hit me -- I HAD a list of all the > altered files -- the output of the rsync --link-dest backup run! > > Took that output, ran it through a "grep -vf exclusionlist", where > "exclusionlist" was a list of files (in regex form) I EXPECTED change on...and > I had a daily output of all unexpected changed files. I called it the > "File Alteration Reporting Tool", but my coworkers thought another name would > be more appropriate for some reason. :D > > It was really quite interesting. Never found a real security breach (yay), > but learned a LOT of new things about the software running on our systems, > and to the point -- we found a few things that prompted us to go kicking trees > to find out what someone had done that we weren't aware of. I call that > success. > > Yes, I'm working on re-doing it (i.e., clean slate so my (former)employer has > no gripes (and no internal information disclosure), but if you are adept at > scripting, it wasn't too difficult. > > Nick. >
