OpenBSD Journal

Installing Snort, ACID, and Barnyard on OpenBSD 3.3

Contributed by jose on from the captured-packets dept.

Robin S. Socha writes: "Snort and the Analysis Console for Intrusion Databases (ACID) provide a graphical representation of potential malicious network traffic. Chris Paul has written a Step by Step Installation Guide for Snort, ACID, and Barnyard on OpenBSD 3.3. In this guide, he describes how to set up a sensor on an ISP link and an ACID console.

It should get anyone with OpenBSD 3.3. stable up an running within a very short time."

Thanks, Robin, Chris' note are very good and detailed. The ACID front end is pretty nice, well worth the effort to set it up. Sure beats trying to figure this all out on your own. Thanks, guys!

(Comments are closed)

  1. By Kay () on

    nice doc :) Thanks !

    Whats the reason for this:
    "Change cron so nightly jobs run in _late_ early morning."

    Why is this more secrure than running these jobs one or two hours after midnight ?


    1. By asp3n () on

      Wait until you set a cron job for every minute instead of every day and wonder why web server part seems so slow

      1. By coldie () on

        i don't think it was implied that running them later was more secure ... and i don't quite understand where the "every minute instead of every day" comment came from ..

        my interpretation is that it's a better idea to run big cron jobs between 3-5am on production machines as there are still a lot of people browsing, etc. at midnight, 1am, 2am, etc. i know that's when i do most of my administration on my home network. so if all my cron jobs started off at midnight? it'd be quite the annoyance..

        1. By Anonymous Coward () on

          Sorry i tend to disagree. It depends what the server serves and to who. If it's a webserver, serving to the world and if you live in Japan and do it at 3-5am it's evening in Europe and Morning in US (approx.) so doing the big stuff in 3-5am then could lag these people.

          1. By schubert () on

            If it's a webserver 'serving the world' then you either should have sufficient hardware resources such that this will not severely hamper load ability OR you just deal with it. It has to be done _sometime_ and you can't please every single primetime internet usage in every single timezone in the world. You have to compromise.

            I mean if you're that worried about ticking off overseas potential customers you obviously should be having enough muscle in your webserver(s) to handle such a thing.

            1. By Anonymous Coward () on

              Sufficient hardware resources? Holy.. why pay more if a little bit cron tweaking does the trick. We're talking about free (as in beer) efficiency here! I think there is something between black and white. Wether it's worth it depends on a lot of details in per situation

              Besides the actual point was that 'it does differ' at which time you should do it per box. If your box has statistically the lowest load on time X then you do it on time X. If your box has statiscally.. Y.. you got the point.

              Therefore a recommendation to set it to X is incorrect. It depends per situation; it's worth looking at, but it ain't a law that X is the best like the author states.

              Recently Linux 2.4.21 got released. got hard to reach. You say: oh, let's buy more and/or better hardware. I say: check if it's possible to tweak the software a bit around to make it more efficient. Your solution costs money (hint: not everyone has much money, even small businesses can have hard times!). I say: first look if it's possible to make software based changes to make it work better, or the most efficient (and then look at hardware if needed).

              1. By Wouter () on

                Don't forget, time = money !

                Changing apps to be more effecients costs money as well.

                1. By Anonymous Coward () on

                  "Don't forget, time = money!"

                  Agree, but for hobbyists it ain't (and yeah, hobbyists can run a server too. Hobbyists can run a big server too).

                  If you do it in free time it ain't costing. If you are bored at work and would be doing nothing else the whole day then it won't cost more either ;)

          2. By dantams () on

            How about putting a 'nice -n 15' in front of your command in crontab?

        2. By CP () on

          I test late at night often and I have a few old sparcs. When all their disks start crunching at 1AM at the same time, it is kinda unnerving. It disrupts my eletronic inner sanctum.

          The list of server recommendations in the guide is basically from my own list of first things I do when I set up a system.



        3. By Ryvar () on

          Also take into account timezone. For instance - if you are running a large content-neutral site primarily targeting Americans, probably the best time to run big cron jobs is when it is 5AM EST and 2AM PST. This is when you will catch as many of your visitors sleeping as is humanly possible.

          The nature of your website also applies - if you're running a site that caters more towards the 2AM gamer variety (like me) you'll tend to notice your traffic bottoms out around 4AM PST/7AM EST instead (weird but true). Examine your logs and decide as appropriate.

      2. By Anonymous Coward () on

        sorry, was an off the wall comment

  2. By satori () satori at icpnet dot pl on mailto:satori at icpnet dot pl

    It nice to see good tutorials :) great work ...

  3. By Anonymous Coward () on

    You'll also need these:


    1. By Anonymous Coward () on

      these also


  4. By Anonymous Coward () on

    The link for the setp-by-step guide is broken. I can't even get it in Google cache :(


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 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.]