Oinkmaster FAQ
--------------

Q1:  I want to download the rules archive using the program XXXXX, which I
Q2:  Can Oinkmaster be useful for distributing rules locally to my sensors?
Q3:  Can Oinkmaster be useful for distributing my homemade rules to my sensors?
Q4:  In which order will 'modifysid'/'disablesid'/'enablesid' be processed?
Q5:  How can the 'include' statement in oinkmaster.conf be useful?
Q6:  Can Oinkmaster restart Snort after an update?
Q7:  Can I tell Oinkmaster to not touch certain SIDs in sid-msg.map so the
Q8:  I want to copy the rules archive from a remote host to the sensor via scp 




Q1:  I want to download the rules archive using the program XXXXX, which I
     can't do with Oinkmaster. What do I do?

A1:  Use whatever program you want to download the rules archive to the local
     filesystem first, and then run Oinkmaster with -u file://<file>.



Q2:  Can Oinkmaster be useful for distributing rules locally to my sensors?

A2:  Yes, there are several situations where Oinkmaster can be handy when
     dealing with local rules management.

     Let's say you have one machine called foohost and also an arbitrary
     number of sensors, where foohost may be the only one with ability to
     download the (official) rules from the Internet, and also has the
     ability to talk to the sensors as well (if the sensors is not be
     able to talk to the Internet, they can obviously not run Oinkmaster
     in the traditional way anyway). One solution could be to run
     Oinkmaster on foohost, which then distributes the rules archive to
     the sensors (over https/sftp/scp/whatever) who will then run
     Oinkmaster and point to the file on their local filesystem. You can
     also have the sensors pull the rules from foohost using -u
     scp://user@foohost:/...

     An example step-by-step how this could be done:

     1) foohost uses Oinkmaster in a traditional way, with its own
        oinkmaster.conf, to download the rules to some local directory.
        Rules that you disable/modify here will become disabled/modified
        on ALL sensors by default. This is a convenient way to disable
        rules that you don't want to use on any sensors, instead of
        having to disable them on each sensor.
        If you don't want any global preprocessing of the rules, you
        could just use a simple wget of the archive on this host.

     2) Create a script that re-creates the rules tarball from the rules
        just downloaded/processed, if needed. You could then either push
        the archive to all the sensors, or have each sensor pull the
        tarball from foohost using '-u scp://user@foohost:/...'. If your
        sensors does not have a way to talk to other hosts at all (like
        when using receive-only cables only), the rules archive will
        obviously have to be distributed manually using a removable media
        like a USB memory stick, for example. If you pushed the archive to
        the sensors, they should run Oinkmaster with '-u file:///...' and
        point to this file. In each local oinkmaster.conf, you can then
        adjust things so they fit this perticular sensor.



Q3:  Can Oinkmaster be useful for distributing my homemade rules to my sensors?

A3:  Yes! This can be done almost exactly like in the example above.
     The main difference is that in step 1, you don't download from the
     Internet, but rather point to a rules tarball created from a directory
     (perhaps checked out from a cvs repository) containing your homemade
     rules when running Oinkmaster on foohost.
     There are a few scripts in Oinkmaster's contrib/ directory (that all
     handle multi-line rules) that may be useful in this case. For
     example, addsid.pl will parse all your rules and add the next
     available SID to rules that don't have any. This may be useful to
     run before creating the rules tarball (probably in the same script).
     So when adding new homemade rules on foohost (and you only have to
     add them here since they will be distributed to all your sensors),
     just leave out the SID and it will be filled in for you
     automatically. You can also use contrib/create-sidmap.pl to create
     a new sid-msg.map from your rules.



Q4:  In which order will 'modifysid'/'disablesid'/'enablesid' be processed?

A4:  All the 'modifysid' will be processed first, then 'disablesid' and last
     'enablesid'. The order they apperar in oinkmaster.conf does not matter.
     So if you use both "enablesid 1" and "disablesid 1" in
     oinkmaster.conf (in any order), sid 1 will first be disabled and then
     enabled. So if sid 1 was enabled by default in the downloaded rules
     archive, this is a NOOP. Disabling a disabled rule is also a NOOP, as
     is enabling an enabled rule.



Q5:  How can the 'include' statement in oinkmaster.conf be useful?

A5:  There are many situations where this is useful, but perhaps the most
     common usage is to be able to use one global and one sensor-specific
     configuration file. You would usually want to make sure to include the
     sensor-specific file last, since possible values that are redefined
     overrides the previous ones. Remember that you can also use multiple
     "-C" arguments when starting Oinkmaster to make it load multiple
     configuration files.



Q6:  Can Oinkmaster restart Snort after an update?

A6:  No. This functionality does not belong in Oinkmaster since almost everyone
     has their own way of restarting Snort. Automatic restart of Snort
     after an update is usually no good idea either. See the README
     for more information. If you really want to do an automatic restart, just
     write a little wrapper that does what you want, and remember to run snort -T
     first and refuse to restart if the test was not successful.



Q7:  Can I tell Oinkmaster to not touch certain SIDs in sid-msg.map so the
     entries I add for my local rules don't get deleted?

A7:  No. What you may want to consider instead is to use a separate
     sid-msg.map for your local rules (and not touch the map for the
     official rules), and then join the two before feeding it to Barnyard.
     Or, what is probably even better, is to generate the sid-msg.map
     automatically yourself after each update. There is one script in Snort's
     contrib directory that does this, and there is also one that comes
     with Oinkmaster (contrib/create-sidmap.pl). The latter handles
     multiline rules and can also take an arbitrary number of rules
     directories as argument.



Q8:  I want to copy the rules archive from a remote host to the sensor via scp 
     (i.e. run "oinkmaster -u scp://user@foohost:/foo/rules.tar.gz ..." on 
     the sensor to pull the rules from foohost) without having to supply a 
     password or passphrase, but I also don't want to give the sensors 
     full access to that host. Can this be done?

A8:  Yes. You should really rely on the OpenSSH documentation on how to do
     this, but an attempt at explaining how it could be done follows.
     The instructions assumes OpenSSH on both client and server.
     If you want to automate the process of just copying a file with scp, you
     should never have to give one host full access to the other. One sollution
     is to generate a key pair where the private key has no passphrase and the
     public key has restrictions to only allow the copy. (If you don't plan on
     running Oinkmaster unattended, it's of course recommended to use a 
     passphrase anyway, even though the public key should still contain
     as many restrictions as possible.)

     First, generate the key pair on the sensor (i.e. the host that is
     going to run Oinkmaster, not the one that keeps the archive):

     ssh-keygen -t rsa -C 'oinkmaster copy' -N '' -f oinkmaster_scp

     This will give you two files in the current directory, oinkmaster_scp
     (private key) and oinkmaster_scp.pub (public key). The public key
     must now be edited to add some restrictions to it.
     Details about how to add restrictions to a host is described in the
     OpenSSH manual. Perhaps the most important restriction in this case 
     is the command="command". You should also use as many other 
     restrictions as possible, such as from="pattern-list" to only allow 
     the sensor(s), no-pty to prevent pty allocation and also turn off all 
     types of forwarding. You will see that the public key begins with 
     something like "ssh-rsa AAAA...". To only add the command 
     restrictions, modify the key to say something like:

     command="scp -f /etc/snort/snortrules.tar.gz" ssh-rsa AAAA...

     This assumes that the tarball will be found as 
     /etc/snort/snortrules.tar.gz on the host you will be copy from, but 
     change it to the location where you store the tarball.
     When you're done editing oinkmaster_scp.pub, copy it to the host that 
     keeps the rules and append it to ~/.ssh/authorized_keys of the user 
     that will be used to perform the copy. This should not be a 
     privileged user, the only requirement is that this user has read 
     access to the rules archive.

     Now make sure that you put the private key (oinkmaster_scp) in a suitable
     directory on the sensor. Then tell Oinkmaster to use this key by
     specifying "scp_key = ..." in oinkmaster.conf,
     You could use something like 
     "scp_key = /home/oinkmaster/.ssh/oinkmaster_scp".
     Or you can use ~/.ssh/config to specify the key as described in the 
     OpenSSH manual. Then you should be able to start Oinkmaster with 
     something like:

     oinkmaster.pl -u scp://user@foohost:/etc/snort/snortrules.tar.gz -o rules

     It will copy the archive without asking for a password/passphrase.
     You should see something like:

     ...
     Copying rules archive from oink@somehost:/etc/snort/snortrules.tar.gz using scp:
     snortrules.tar.gz                                 100%  110KB   0.0KB/s   00:00
     Archive successfully downloaded, unpacking... done.
     ...

     If you start Oinkmaster in verbose mode (-v), scp will be run in
     verbose mode as well.

