LL      IIIII NN   NN KK  KK EEEEEEE RRRRRR  RRRRRR   OOOOO  RRRRRR 
LL       III  NNN  NN KK KK  EE      RR   RR RR   RR OO   OO RR   RR
LL       III  NN N NN KKKK   EEEEE   RRRRRR  RRRRRR  OO   OO RRRRRR 
LL       III  NN  NNN KK KK  EE      RR  RR  RR  RR  OO   OO RR  RR 
LLLLLLL IIIII NN   NN KK  KK EEEEEEE RR   RR RR   RR  OOOOO  RR   RR
                                                           ramblings
____________________________________________________________________
Posted on: Thursday, April 23rd, 2009 at 03:48.
Filed under: All, Coding, ServerAdmin, Software.
RSS 2.0 feed for comments.
You can leave a response, or trackback from your own site.

I figured I would share with you, a setup I am using on all my BSD servers to monitor changes to the filesystem.

The idea is to be notified by email at a certain interval (eg: once a day) with a list of all files that have changed since last time the check ran.

This, allows you to be notified when files change without your knowledge, for example, in the event of a cracker breaking into the server or if you accidentally, recursively chowned /, and you managed to interrupt the command; mtree allows you to see how many of the files were affected, and fix them.
As mtree also reports HOW the files were changed. For example, in the chown scenario it would mention the expected uid/gid and what it changed to. This would allow for an automated recovery of such a disaster.

In addition to the e-mail notifications it will also keep a log file (by default in /var/log/mtree.log)

The utility we’ll use for this on FreeBSD is mtree (On GNU/Linux you’d have to use tripwire or auditd).
I wrote a perl script which uses mtree to accomplish what I described above: download it.

So basically, to set it up, you can do the following:

mkdir /usr/mtree
cd /usr/mtree
touch fs.mtree fs.exclude
wget http://linkerror.com/programs/automtree
chmod +x automtree

Now, if you run ./automtree -h you’ll see a list of valid options with some documentation:

  Usage: ./automtree [OPTION] ...
  Show or E-mail out a list of changes to the file system.

  mtree operation options:

    -u,  --update        Updates the file checksum database after 
                         showing/mailing changes.
    -uo, --update-only   Only update the file checksum database.
    -p,  --path          Top level folder to monitor (default: /)
    -q,  --quiet         Do not output scan results to stdout or any
                         other output.

  Path configuration options:

    -l,  --log           Logfile location 
                         (default: /var/log/mtree.log)
         --mtree         Set the location of the mtree executable. 
                         (default is /usr/sbin/mtree)
         --checksum-file Set the location of the file containing the 
                         mtree file checksums. 
                         (defaul: /usr/mtree/fs.mtree)
         --exclude-file  Set the location of the file containing the 
                         list of files and folders to exclude from the 
                         mtree scan. (default is /usr/mtree/fs.exclude)

  E-mail options:

    -e,  --email         Adds specified e-mail address as destination.
         --sendmail      Set the location of the sendmail executable. 
                         (default: /usr/sbin/sendmail)
         --reply-to      Set the e-mail reply-to address.
         --subject       Sets The e-mail subject. 

  Misc options:

    -h,  --help          Display this help text.
 

  Example usage:

    ./automtree -uo
    ./automtree -u -q -e foo@example.com -e bar@example.com
    ./automtree /var/www --mtree /usr/local/sbin/mtree

As you can see, by default, the script will just index the entire filesystem, as the default for the -p option is / … In order to do this you’ll want to ignore some folders, so edit the fs.exclude file, and stick at least this into it:


./dev
./proc
./var
./tmp
./usr/mtree
./usr/share/man
./usr/share/openssl/man
./usr/local/man
./usr/local/lib/perl5/5.8.8/man
./usr/local/lib/perl5/5.8.8/perl/man

Note that you have to prefix folders with ./
So now, in order to automatically scan and receive notifications, the command which will go into crontab is:


./automtree -u -q -e foo@example.com

(It is possible to add multiple -e options for multiple e-mail destinations.)

The command above will not output to stdout (-q), email filesystem changes to foo@example.com (-e foo@example.com), and automatically update the checksum file with the newly discovered changes (-u).

An example crontab line, to check every 3 hours (type crontab -e to edit your crontab):


0 */3 * * * /usr/mtree/automtree -u -q -e youremail@example.com &> /dev/null

The script won’t send an e-mail if there are no changes to report.

pixelstats trackingpixel
____________________________________________________________________

3 Responses to “Monitoring changes to the filesystem.”

  1. mouser says:

    i love the change monitoring stuff you set up.

  2. argv says:

    what does the lack of mtree say about GNU?

    i mean BSD has had mtree since Reno.

    maybe… eventually everyone is going to be using bsd. first they left windows for linux and soon enough they’ll leave linux for bsd. though no one will call it that. it will be marketed as something else. maybe that’s how it will go.

    it’s like we all going back to the beginning. unix can only be “improved” so much. it’s fundamentally the same as it was 30 years ago.

    hardware improves (smaller and faster), but software… ???

    • John says:

      For what it’s worth, mtree is in the portage tree of Gentoo GNU/Linux now. Then again, Gentoo was always probably closest to FreeBSD among the GNU/Linux distro’s…

      As far as I can tell, ‘everyone else’ is still using Windows. And I’d prefer to keep it that way :D – Think of it. You don’t want all the closed source stuff+malware+gui fluff coming over along with the users. Stay off my lawn! :)

      I don’t think unix is the same as it was 30 years ago,… there have been significant advances. We wouldn’t have FreeBSD jails, we wouldn’t have the TrustedBSD stuff, etc…
      However the core principles remain the same perhaps, and that’s probably a good thing.

      Back in the day, everything was new and it was easy to innovate. New features keep getting added to the kernels of all major operating systems under development. Starting from scratch and throwing away 30 years of development on working production systems, just to try something ‘new’ would be the equivalent of taking a time machine and going back in time 30 years to re-write 30 years of software. Nobody has the time or money to pull that off anymore. There is plenty of research OS’es or OS’es that get implemented for fun, and sometimes exciting new features come out of them, that make their way into the mainstream OS’es eventually… Don’t get me wrong, I’d love to see a brand new OS that is innovating and rethinks everything, but I’m not waiting for it to happen any time soon.
      Software does improve, but it evolves very slowly, much like the evolution of mammals :)
      30 years ago everything was taking it’s baby steps. There wasn’t near the number of computer users as there is today either. It is much much harder now to make ground breaking innovations. You can’t just get up and change everything overnight anymore.

____________________________________________________________________

Leave a Reply