OpenBSD Journal

OnLamp: File Integrity and Anti-DDoS Utilities

Contributed by jose on from the filesystem-security dept.

OnLamp , the O'Reilly site which covers a host of interesting technologies, recently ran a two piece series for FreeBSD on filesystem integrity. The first piece was on Tripwire, which doesn't work well at all on OpenBSD. The second piece was about aide and searching for DDoS systems , which can easily be used on OpenBSD. According to the website for aide ,
It creates a database from the regular expression rules that it finds from the config file. Once this database is initialized it can be used to verify the integrity of the files. It has several message digest algorithms (md5,sha1,rmd160,tiger,haval,etc.) that are used to check the integrity of the file. More algorithms can be added with relative ease. All of the usual file attributes can also be checked for inconsistencies.
This is a useful way to ensure your servers remain intact and secure. Aide is available in the ports tree. You may also want to look at mtree , which comes in the base system and can be used for similar purposes.

(Comments are closed)


Comments
  1. By Michael Anuzis () on

    How much more file system integrity is available with Aide than without?

    It seems like Aide requires a pro-active approach to do what's already done automatically each night and e-mailed to me labeled "Daily Insecurities Output", telling me if/when any important binaries or configuration files have been changed.

    Is Aide's advantage in just being more configurable? Because it seems as it stands, the daily insecurities output feature already covers this job fairly well. --Michael

    Comments
    1. By Christopher () on

      Aide is just a bit different in that it stores a database file with a spec for each file, rather than requiring an entire file hierarchy to be checked against.

      mtree is great for the really important config stuff. But with aide I find it easier to modify the config, update the database when there are changes, and check against a majority of the disk space without too much overhead.

      But I'll admit I haven't tried tweeking mtree to the extent I've used other integrity checkers similar to aide. Plus, it's kind of nice having two seperate systems checking the important stuff :)

    2. By Christopher () on

      Actually, thinking about it, I may be getting some confusion from the daily insecurity script, not mtree itself... that script just works so I don't touch it :)

    3. By William Ahern () william@25thandClement.com on http://www.25thandClement.com/~william/projects/wa

      Maybe the above project will help. I need people to test this thing out, anyhow. It is a file/directory watcher shell utility. In this case it could be used to notify about file modifications _immediately_.

      running like so, `watch -f -w 1 /[s]bin /usr/[s]bin`
      would write on stdout, say if /usr/bin/login was altered:
      ! /usr/bin/login
      or if it was deleted and created
      - /usr/bin/login
      + /usr/bin/login

      it uses kqueue, so everything is instantaneous.
      i suppose one might need to protect the process
      so it couldn't be killed.

      its alpha at this point. a few seg faults i need to fix, and stabilize the semantics.

      Comments
      1. By Michael Anuzis () michael_anuzis@hotmail.com on http://www.anuzisnetworking.com

        now that sounds like it's got potential.

        I've always wondered, if someone who *really* knew what they were doing, say an OpenBSD developer or somesuch, broke into my system mid-day and had ~10-hours to cover up their tracks, edit/replace whatever it is that keeps track of the daily insecurities output to tell me nothing has changed, it seems like they could do it.

        Something that has an instantaneous response on the other hand, that could perhaps send an e-mail to an address hosted on another system where the attacker could not tamper with it seems like it has a lot more protection offered. I'd say sending it to the console would be just as good but then I'd be concerned the attacker may reboot, losing everything displayed on the screen, or may flood the console with misc things via syslog that would cover up their tracks. Just some on-the-fly thinking on the topic.. not sure how viable any of it really is. --Michael

    4. By William Ahern () william@25thandClement.com on http://www.25thandClement.com/~william/projects/wa

      Maybe the above project will help. I need people to test this thing out, anyhow. It is a file/directory watcher shell utility. In this case it could be used to notify about file modifications _immediately_.

      running like so, `watch -f -w 1 /[s]bin /usr/[s]bin`
      would write on stdout, say if /usr/bin/login was altered:
      ! /usr/bin/login
      or if it was deleted and created
      - /usr/bin/login
      + /usr/bin/login

      it uses kqueue, so everything is instantaneous.
      i suppose one might need to protect the process
      so it couldn't be killed.

      its alpha at this point. a few seg faults i need to fix, and stabilize the semantics.

  2. By tom () tom@replic8.net on mailto:tom@replic8.net

    any examples on using mtree in the above mentioned way?

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]