FAQ

# $Id: FAQ,v 1.48 2006/01/21 08:25:05 andreas_o Exp $ #


The must current version if this FAQ can be found
at the Oinkmaster web site, http://oinkmaster.sourceforge.net/


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

Q1:  What URL should I download the Snort signatures (rules) from?

Q2:  Oinkmaster says the file in URL does not exist (or it exists but
     doesn't work with my Snort).

Q3:  Can Oinkmaster be useful for distributing rules and configurations
     locally to my sensors?

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

Q5:  In which order will the localsid/modifysid/disablesid/enablesid 
     configuration directives be processed?

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

Q7:  Can Oinkmaster restart Snort after an update?

Q8:  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?

Q9:  I want to copy the rules archive from a remote host to the sensor 
     via scp 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?

Q10: How do I setup proxy configuration?

Q11: Can Oinkmaster be used to update rules from www.whitehats.com?

Q12: Will Oinkmaster fail when new keywords are introduced in the rules?

Q13: Under what license are the official Snort rules released, and
     can I modify them without violating it?

Q14: Is there a GUI for Oinkmaster?

Q15: When starting Oinkmaster it says my Perl version is too old, or 
     gives me errors about "too many arguments for open".

Q16: If I make a modification directly in a rules file that is updated by
     Oinkmaster, will that change be permanent?

Q17: Should I run Oinkmaster as root?

Q18: I get "/usr/bin/perl: bad interpreter" when starting.

Q19: How often should I run Oinkmaster?

Q20: Can Oinkmaster send email or execute a command when the rules have
     been modified?

Q21: What do I do if I need to locally customize (not disable) some 
     rules (and so that those modifications become permanent)?

Q22: I want to disable rules by editing the files directly and putting 
     a "#" in front of the rules. How do these changes become permanent?

Q23: How do I update the rules from multiple sources, like the official 
     ones at www.snort.org and the ones at www.bleedingsnort.com?

Q24: How do I know which rules to disable?

Q25: Why do I get alerts like "Snort Alert [1:123456:0]", i.e. 
     "Snort Alert" instead of the rule's msg string?

Q26: How do I keep my sid-msg.map up-to-date?

Q27: How to I make Snort reload the new rules without stopping the current 
     Snort process?

Q28: Can I use an external utility to download the rules archive rather
     than one of the built-in methods?

Q29: I update from multiple URLs at the same time and get the error 
     "a file called 'sid-msg.map' exists in multiple rules archives"
     (or the same message for some other file).

Q30: I get this error when running Oinkmaster:
     "URL not specified. Specify at least one 'url=<url>' in the
     Oinkmaster configuration file or use the '-u <url>' argument"

Q31: How do I add a new classification when using Oinkmaster?

Q32: What Perl modules do I need to be able to set use_external_bins = 0?

Q33: Can I tell Oinkmaster to disable all rules by default, and only
     enable and update specific ones?



--------------


Q1:  What URL should I download the Snort signatures (rules) from?

A1:  Quick instructions if you want to update using the official free 
     Snort signatures:

     1) Go to http://www.snort.org/ and register.
        You will receive a password in your mail shortly after.

     2) Go to the Snort site and login, and choose to edit your user 
        profile.

     3) You will find the most current instructions under
        "Oinkmaster Download Codes" on that page. Basically press the
        "Get Code" button to generate a code.
        This will generate a code looking something like
        "5a081649c06a277e1022e1284bdc8fabda70e2a4".
        Then construct the URL like this:
        http://www.snort.org/pub-bin/oinkmaster.cgi/<oinkcode>/<filename>
        The filename depends on which version of Snort you use, so you must
        remember to always use the right one.
        If you for example use Snort 2.4, the url would look like this 
        (without wrap):
        http://www.snort.org/pub-bin/oinkmaster.cgi/5a081649c06a277e1022e1284b
        dc8fabda70e2a4/snortrules-snapshot-2.4.tar.gz

     You can now specify this URL as "url = <url>" in oinkmaster.conf
     or use the "-u <url>" command line argument.


     Here is some more information about downloading Snort signatures.
     Oinkmaster can be used to update Snort signatures from many different 
     places, like the official ones at www.snort.org or the
     "Bleeding Snort" ones from www.bleedingsnort.com. Here follows 
     information about the official Snort signatures at www.snort.org 
     Third party rules sources should have their own instructions.
     Remember that you should never ever update the Snort signatures
     from an untrusted source!

     In March 2005, Sourcefire changed the license of the Snort 
     signatures. There are currently two different types of free rules 
     tarballs on the official Snort site. The first one is the 5-day 
     delayed Sourcefire VRT Certified Rules which you must register to 
     get access to It's free to register, but to get them without the 
     5-day delay you must pay Sourcefire. The second type is the Community 
     Rules released under GPL. See http://www.snort.org/rules/ 
     for details about the different types of rules. The good news is that 
     you can update all of them using Oinkmaster.

     To download the Sourcefire VRT licensed rules, see the instructions 
     above. For the Community rules, no registration is required, so just 
     point to the right URL (currently 
     http://www.snort.org/pub-bin/downloads.cgi/
     Download/comm_rules/Community-Rules.tar.gz).

     As of Oinkmaster v1.2, you can specify multiple URLs to grab 
     multiple rules archives at the same time. Note that when updating 
     from multiple sources, e.g. both the Sourcefire VRT Certified 
     Rules and the Community Rules, and you use a program such as 
     Barnyard that requires a sid-msg.map file, you must handle this 
     somehow. More information about this can be found elsewhere in 
     this FAQ. It's generally recommended to use the Sourcefire 
     VRT licensed rules as a minimum and other rules sources as a 
     complement if requested.



Q2:  Oinkmaster says the file in URL does not exist (or it exists but
     doesn't work with my Snort).

A2:  Check the "url = ..." line in oinkmaster.conf (or argument to "-u" 
     if you specify it on command line). The URL you should use depends 
     on the version of Snort you run (check with snort -V). If Snort 
     complains about unknown keywords, you are probably trying to use 
     rules that aren't compatible with your Snort version. See Q1 for 
     more information.
	
     If you are absolutely sure you are using the right rules for your
     version of Snort but still have problems, you may need to read the
     Snort manual because it is likely that your local configuration is
     broken. For example, the new rules maybe contains new variables that
     you forgot to add. But of course there can be times when the rules
     archive actually is broken somehow (remember that auto-update of 
     the rules with automatic Snort restart is bad unless you are 
     careful). These issues are often mentioned on the Snort mailing 
     lists.



Q3:  Can Oinkmaster be useful for distributing rules and configurations
     locally to my sensors?

A3:  Yes, there are several situations where Oinkmaster can be handy when
     dealing with local rules management. If you have only a few sensors,
     you can simply run Oinkmaster in a traditional way to update the 
     rules from the Internet on all of them. However, if the sensors have 
     no way to talk to the outside, and/or you have many sensors you want 
     to control in a convenient way from a single place, you'll want to
     consider another solution.

     A common way to solve this is to do some very simple scripting and
     have a "master" host which downloads the rules using Oinkmaster and
     does some global modifications to them. With some simple scripting,
     it can then push the rules archive to each sensor which runs
     Oinkmaster on it. You can also have each sensor run Oinkmaster and
     pull the rules archive from the master, for example using
     -u scp://... and point to the master. Each sensor can have its own
     oinkmaster.conf to fine-tune the rules (even override global settings
     set by the master). The rules archive can of course contain more than
     just the rules, such as Snort/Barnyard/Oinkmaster configuration files
     and the sid-msg.map and so on.
     

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

     1) foohost, the master, uses Oinkmaster in a traditional way with 
        its own oinkmaster.conf to download the rules into some local 
        directory. Rules that you modify here will become 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, for example. If you don't want any global 
        preprocessing of the rules, you could just use a simple wget of 
        the archive on this host (or run Oinkmaster with a NOOP config).

     2) Create a script that re-creates the rules tarball from the rules
        just downloaded. You could then either push this new archive to 
        all the sensors or have each sensor pull the tarball from foohost 
        using '-u scp://user@foohost:/...'. If your sensor does not have 
        a way to talk to other hosts at all (like when only using 
        receive-only cables), the rules archive will obviously have to be 
        distributed manually using a removable media like a USB memory 
        stick or something. 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 fine-tune the 
        rules to fit this particular sensor.



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

A4:  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 local
     directory (perhaps checked out from a cvs repository) containing 
     your homemade rules. 

     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. So when adding new homemade rules 
     on the master (and you only have to add them there since they will be 
     distributed to all your sensors automatically), just leave out the 
     SID and it will be filled in for you automatically. You can also use 
     create-sidmap.pl to create a new sid-msg.map from your rules.



Q5:  In which order will the localsid/modifysid/disablesid/enablesid 
     configuration directives be processed?

A5:  For each rule, the following is performed:
 
     1) If there is a matching localsid statement (no matter where in the 
        configuration file it is), skip further processing
     2) If -e was specified on the command line, enable the rule
     3) Process all matching modifysid and use_template statements in 
        the same order as they appeared in the configuration file
     4) Disable the rule if there is a matching disablesid statement (no 
        matter where in the configuration file it is)
     5) Enable the rule if there is a matching enablesid statement (no
        matter where in the configuration file it is)

     Usually you don't have to worry about this as it only matters if you
     have multiple types of processing directives for the same rule 
     and that affects each other.



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

A6:  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 (except for the "url" option,
     as you are allowed to specify multiple URLs). Remember that you
     can also use multiple "-C" arguments when starting Oinkmaster to make
     it load multiple configuration files. They will be loaded in the order
     of appearance on the command line.



Q7:  Can Oinkmaster restart Snort after an update?

A7:  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 not a 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 
     is not successful. Of course, you should only restart Snort if
     there actually were any changes in the rules.



Q8:  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?

A8:  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/whatever. 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 multi-line rules and can also take an arbitrary number 
     of rules directories as argument. It is described in detail elsewhere
     in this FAQ.



Q9:  I want to copy the rules archive from a remote host to the sensor 
     via scp 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?

A9:  Yes. You should really rely on the OpenSSH documentation on how to 
     do this as it is well documented there, 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.
     And in this particular case, there is absolutely no need to run as 
     root on either side. One solution 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 is 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 master host 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 
     restriction, 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 master host, but change it to 
     the location where you store the tarball there. When you are done 
     editing oinkmaster_scp.pub, append the contents of it to the master 
     host's ~/.ssh/authorized_keys for 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 run Oinkmaster:

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

     It will copy the archive without asking for a password/passphrase.
     If you start Oinkmaster in verbose mode (-v), scp will be run in
     verbose mode as well.



Q10: How do I setup proxy configuration?

A10: If you download the snort rules archive from a web site (e.g. 
     www.snort.org) and you are a behind an http proxy, you need to tell 
     Oinkmaster to use that proxy or the download will fail. How you do 
     that depends if you use wget (i.e. use use_external_bins=1, the 
     default, in oinkmaster.conf) or libwww-perl (use_external_bins=0). 
     You can read their man pages for complete configuration 
     instructions, "man wget" or "man LWP::UserAgent".

     Quick instructions for the impatient:

     For wget, you can either edit the wget configuration file (usually
     /etc/wgetrc for global settings and ~/wgetrc for user settings) and 
     set the http_proxy option. For example: 
     http_proxy = http://your_proxy_host:3128:/
     (or http_proxy = http://user:password@your_proxy_host:3128/ if you 
     are required to authenticate to the proxy). You can also set the 
     http_proxy environment variable. If you want your proxy server not to 
     return the file in its cache but rather get it from the web server 
     again, add "header = Pragma: no-cache" to your wget configuration 
     file.

     For libwww-perl, set the http_proxy environment variable as 
     described above (i.e. to "http://your_proxy_host:3128:/" or 
     "http://user:password@your_proxy_host:3128/").



Q11: Can Oinkmaster be used to update rules from www.whitehats.com?

A11: No, the Snort rules on www.whitehats.com have not been maintained 
     for a long long time and should not be used, although the arachNIDS
     database is still a good source of information for older rules.

     (And for Oinkmaster to work in a technical sense, the rules package 
     must be a gzipped tar file that contains a directory called 
     "rules", which holds all the rules files.)



Q12: Will Oinkmaster fail when new keywords are introduced in the rules?

A12: No. Not unless there is a bug in Oinkmaster anyway. Oinkmaster was 
     designed to be stupid and not try to understand every single part of 
     the rules. Basically, for a rule to be successfully identified by 
     Oinkmaster, it must start with one of the keywords in 'rule_actions' 
     specified in oinkmaster.conf. It must also contain 
     'msg: "some message";' and 'sid: <sid>;'. Some basic syntax checks 
     are also performed, but the rest is ignored.

     If a rule cannot be successfully parsed for some reason, it will 
     simply be regarded as a non-rule line (or multiple non-rule lines if 
     it is a multi-line rule). Since non-rule lines are also compared and 
     updated by Oinkmaster, things will work as usual anyway except that
     actions such as disablesid on that rule will have no effect.

     Remember that even if Oinkmaster may not have problems with the new
     rules, they can still be invalid when being read by Snort. This has
     happened a couple of times in the past when the official rules
     tarballs contained broken rules (containing keywords that weren't
     valid for that version of Snort) put there by accident. Until
     those broken rules are fixed, the easiest thing to do is usually
     to simply add temporary "disablesid" statements for the them.



Q13: Under what license are the official Snort rules released, and
     can I modify them without violating it?

A13: In March 2005 Sourcefire changed the license, but it should be 
     no problem as long as you don't redistribute the rules outside your 
     organization. See http://www.snort.org/rules/ for the details.



Q14: Is there a GUI for Oinkmaster?

A14: Yes, check out README.gui and contrib/oinkgui.pl. This is just a 
     primitive front-end for Oinkmaster though. Oinkmaster was designed 
     to be simple and also easy to use in scripts, so if you want a more 
     advanced graphical interface for maintaining Snort rules, you 
     should probably be looking at another tool instead.



Q15: When starting Oinkmaster it says my Perl version is too old, or 
     gives me errors about "too many arguments for open ...".

A15: Your Perl version needs to be upgraded to at least 5.6.1.
     The issue is common on FreeBSD boxes, which usually use Perl 
     5.005. There is a more recent Perl version in the ports tree though
     (lang/perl5.8 at the time of writing), so just install that one and 
     execute "/usr/local/bin/use.perl port" to globally enable it.



Q16: If I make a modification directly in a rules file that is updated by
     Oinkmaster, will that change be permanent?

A16: No! Permanent modifications in files that are updated by Oinkmaster
     must be done by editing oinkmaster.conf. If you edit a rules file
     directly, the next time you run Oinkmaster it will see that the file 
     is different than the downloaded one, and so your file becomes 
     overwritten. There is no such thing as "if you edit a rule, it 
     will automatically be marked as locally customized and therefore 
     not automatically updated". This may be different than some other 
     rules updating tools, but it is the expected behavior as Oinkmaster 
     was designed to work this way. You can however use the "localsid"
     keyword to achieve this behavior. See Q21 for recommendations how 
     to handle local customization of the rules.



Q17: Should I run Oinkmaster as root?

A17: No! You must run Oinkmaster as a user that has read/write access to 
     your rules directory and all rules files in it, but it should *NOT* 
     be a privileged user such as root! Never run Oinkmaster as root.
     Adding a new user to be used for running Oinkmaster is a good idea, 
     just make sure it has read/write access to your rules.
     (The user you run Snort as, if different than the Oinkmaster user, 
     usually only needs read access to the rules.)



Q18: I get "/usr/bin/perl: bad interpreter" when starting.

A18: By default, Oinkmaster assumes that Perl is found as /usr/bin/perl.
     If you get this message, you need to edit oinkmaster.pl and modify 
     the first line so it points to the right location for your system
     (try "which perl").



Q19: How often should I run Oinkmaster?

A19: The short answer would be that once a day is probably reasonable in 
     most cases. The official rules tarballs on www.snort.org are 
     currently generated from the CVS repository many times a day, but 
     that does not mean there are always any changes in it. My 
     experience is that the rules are sometimes updated daily, and 
     sometimes in bursts with several days/weeks apart (also depending 
     on which rules tarball you use). If you've run Oinkmaster several 
     times for a few days and it still says that nothing has changed, 
     this does not automatically mean anything is wrong. If you want to 
     verify that Oinkmaster is working you can do some arbitrary 
     modifications in some rules file in your rules directory and then 
     run Oinkmaster. If those changes are noticed by Oinkmaster, 
     everything probably works as expected.

     If you are behind a web proxy, make sure it is not trying to be 
     nice by caching the rules archive and always give you the old 
     version instead of actually polling the real site for an updated 
     version (see Q10). Check out http://www.snort.org/ for the latest 
     information about the rules and the rules release process 
     (Oinkmaster and its author has nothing to do with this).



Q20: Can Oinkmaster send email or execute a command when the rules have
     been modified?

A20: There is no built-in function in Oinkmaster to do that, because that
     functionality does not belong there. However, it is very easy to do
     it with a small wrapper. You can for example run Oinkmaster with the
     -q flag so it doesn't give any output unless the rules had changed,
     and redirect the output to a file. Then check the size of this file.
     If it is empty, nothing had changed. If it has some content, 
     something had changed. So then you can either send the content of 
     the file in an email and/or execute some command. Here is a basic
     wrapper script to show how you could do this. There is also an
     example in the README file.

     #!/bin/sh

     tmpfile=`mktemp /tmp/oinkmaster.XXXXXXX` || exit

     oinkmaster.pl -o /etc/snort/rules -q > $tmpfile

     if [ -s "$tmpfile" ]; then
         echo "The rules have changed."
         # Do stuff here, like send content of $tmpfile in
         # an email or execute some command.
     else
         echo "No changes in the rules."
     fi

     rm $tmpfile



Q21: What do I do if I need to locally customize (not disable) some 
     rules (and so that those modifications become permanent)?

A21: As seen in Q16 you cannot just edit a local rules file and 
     customize the rules, because they would be overwritten during 
     the next update. There is however often a need of being able to do 
     such modifications to the rules, and there are a few different 
     ways you could do this with Oinkmaster. One way is often the best 
     one and the other two are often less good, depending on the 
     situation of course.

     The often best way - modifysid (and templates)
     ----------------------------------------------
     If you need to modify rules slightly, this is definitely the way to 
     go. For documentation about modifysid, see oinkmaster.conf (don't 
     forget README.templates and template-examples.conf if you use 
     modifysid a lot and want to simplify the process).

     A modifysid statement is a way to apply a substitution expression 
     on specified rules after each update. Here comes the whole point of 
     why using this approach is often the best one: If the default 
     version of this rule is later improved somehow in the new rules 
     archive, you would automatically get the updated version while your 
     customization would still apply (assuming your substitution 
     expression still matches the new version of the rule, of course). 
     This means that even rules that you need to customize can be 
     continued to be automatically maintained!

     Some typical examples where using modifysid is the best way to go 
     is where you pretty much like the default rule and always want to 
     use the latest version of it, but you want to change some detail
     (such as switching $HOME_NET/$EXTERNAL_NET) or add something to it 
     (such as a tag or flexresp statement). Another point is that all 
     these local customizations by using modifysid become kind of 
     self-documenting, which you will appreciate when looking at your 
     rules and wonder what those local modifications you've done over 
     the years actually are.

     The sometimes less good way #1
     ------------------------------
     If you need to modify a rule heavily in such way that it becomes 
     too complex and too meaningless to try to use and maintain a 
     modifysid statement for it, you need to solve the problem in 
     another way. I would recommend using a "disablesid" statement for 
     that rule and then rewrite and copy it to some local rules file 
     (one that is not updated by Oinkmaster) and change its SID to a
     local one.

     Note however that by doing this, the rule will no longer be 
     automatically maintained! Be very careful so you don't end up with
     lots of rules that become forgotten and not maintained, as this is 
     the exact opposite of what Oinkmaster is created for.

     A positive side-effect of using "disablesid" for these rules is 
     that Oinkmaster keeps track of changes even in disabled rules in 
     the official rules files. So you may want to pay attention to 
     these - you might find an interesting change some day that you want 
     to apply to your version of the rule as well.

     The sometimes less good way #2
     ------------------------------
     As of Oinkmaster 1.1, you can use variant of the above as it 
     introduced the "localsid" keyword.
     
     By using "localsid <sid>" in oinkmaster.conf, you mark this rule as 
     being "locally modified" which means it will never get overwritten.
     Instead, your local version of the rule is kept. Any updates in 
     the official version of the rule is silently discarded, but if 
     you run in verbose mode (-v) Oinkmaster will print the current 
     difference between your version and the official version.

     Again, be warned that all "localsid" rules will no longer be
     automatically maintained! If you are using this feature more than 
     in a very few cases, chances are that you are doing something wrong.



Q22: I want to disable rules by editing the files directly and putting a 
     "#" in front of the rules. How to these changes become permanent?

A22: As can be read elsewhere in this FAQ, you shouldn't ever modify 
     rules in any way by editing the rules files directly when using
     Oinkmaster. Normally, the right way to disable rules is to use
     the "disablesid" keyword. However, if you for some reason really
     want to disable rules by editing the rules files directly and
     putting a "#" in front of unwanted rules, like if you're about
     to use Oinkmaster for the first time and you already have a bunch
     of disabled rules, you can use a little trick.

     Use contrib/makesidex.pl to generate "disablesid" lines for those 
     disabled rules and feed them to Oinkmaster. You can for example use 
     something like this to update this information automatically and 
     redirect to a file included by Oinkmaster (we don't touch the main 
     config file):

     makesidex.pl /etc/snort/rules >autodisable.conf 2>/dev/null && \
     oinkmaster.pl -C /etc/oinkmaster.conf -C autodisable.conf \
     -o /etc/snort/rules



Q23: How do I update the rules from multiple sources, like the official 
     ones at www.snort.org and the ones at www.bleedingsnort.com?

A23: One way is to simply run Oinkmaster once for each URL and with 
     different output directories. This way you don't have to worry 
     about filename collisions etc. 

     As of Oinkmaster 1.2 though, you can specify multiple URLs at the 
     same time, either by using several url=<url> in the configuration 
     file or by specifying several -u <url> on the command line. Beware 
     that even when using multiple URLs, all the downloaded rules files 
     will be put in the same output directory. So if a filename exists 
     in multiple rules archives, there is going to be trouble 
     (Oinkmaster will detect this and abort before touching anything). 
     Any 'skipfile' or other directive you may have in your Oinkmaster 
     configuration that takes a filename as argument will apply on any 
     matching file regardless of which rules archive it was in. If you 
     specify multiple URLs and one of them happen to be broken somehow, 
     Oinkmaster will exit and not process the other ones. This may be 
     good or bad, depending on the situation.

     Note that if you run Barnyard (or any other program that use 
     unified logs) when using rules from multiple sources (and/or local 
     rules), you must make sure that your SID message map file 
     (sid-msg.map) is up-to-date and contains entries from all those 
     sources, including your local rules if any. This procedure is 
     described elsewhere in this FAQ.



Q24: How do I know which rules to disable?

A24: This is a very hard question that really has very little to do with 
     Oinkmaster. But here are a few tips:

     - Remember that there are many ways to stop alerts from firing, and 
       disabling the rule is not always the best way. For example, if all 
       you want is to stop the alert from/to a particular host, you should 
       not disable the rule completely. Instead, check the Snort manual on 
       how to use BPF filters, suppressing and pass rules and choose the 
       best method for the situation.

     - Review your Oinkmaster configuration files every now and then, 
       especially rules you have disabled or modified. Rules you disabled 
       or modified a long time ago may have improved, or your environment 
       may have changed since then.
       
     - Subscribe to relevant mailing lists, like snort-sigs.



Q25: Why do I get alerts like "Snort Alert [1:123456:0]", i.e. 
     "Snort Alert" instead of the rule's msg string?

A25: It happens when you run Barnyard with a sid-msg.map file that is not 
     up-to-date. When Snort generates an alert in unified format, it does 
     not include the rule's msg string, just the rule's SID (a number to 
     identify a rule). When Barnyard then converts the unified alerts to 
     something human readable or something to insert in the database, it
     must somehow be able to lookup the msg string for each rule by using 
     their SIDs. This is done via the file sid-msg.map. This file must 
     contains an entry for every rule. This means that when adding new 
     rules, this file must be updated as well (how to do this can be found 
     elsewhere in this FAQ). Also, make sure to restart both Barnyard and 
     Snort so they stay in sync. You must also make sure that the 
     gen-msg.map file is current, but it probably only requires updating 
     when switching Snort versions.

     If you wonder what the numbers in [1:123456:0] means, the first is 
     the generator ID (1 means it's a rule), the second number is the SID 
     (123456 in this case) and the last one is the revision (0 in this 
     case, which probably mean the rule has no revision keyword in it).
     See the Snort and Barnyard manuals for more information.



Q26: How do I keep my sid-msg.map up-to-date?

A26: When using Barnyard and the like, it's important that the 
     sid-msg.map file is always up-to-date, or you will end up with 
     alerts like "Snort Alert [1:123456:0]" instead of getting the 
     rule's real msg string. There are several ways to do this.

     One way is to assume that an updated SID map file is included in 
     each rules archive and to update those along with the rules, and 
     then merge them into a new file which you then feed to 
     Barnyard/whatever.

     Another way (which I think is much better) is to ignore the SID map 
     files in all the rules archives and instead generate it yourself 
     after each rules update. There is a script in Oinkmaster's contrib 
     directory, create-sidmap.pl, which can generate a sid-msg.map file 
     from multiple rules directories. It can handle multi-line rules and 
     will also warn you in case of duplicate SIDs, regardless of the file 
     or directory. This includes any local rules you may have written, 
     which is very important as the SIDs in those may collide with those 
     in a 3rd party rules archive. Just remember to run create-sidmap.pl 
     after each rules update, and also to to restart Barnyard/whatever to 
     use the new SID map if there were any changes.

     A tiny example just to show the idea how an update wrapper could 
     look like when updating from multiple sources and then generating 
     the sid-msg.map file:

     #!/bin/sh

     oinkmaster.pl -u http://www.bleedingsnort.com/... -o /etc/snort/rules/bleeding/  
     oinkmaster.pl -u http://www.snort.org/... -o /etc/snort/rules/official/
	
     create-sidmap.pl /etc/snort/rules/official/ \ 
                      /etc/snort/rules/bleeding/ \
                      /etc/snort/rules/local/    \
                      > /etc/snort/sid-msg.map

     You may also want to put in some sanity checks like aborting in case 
     of duplicate SIDs and restarting Barnyard/Snort if everything went ok 
     and there were changes and so on, you get the point.



Q27: How to I make Snort reload the new rules without stopping the current 
     Snort process?

A27: This is not really an Oinkmaster question so you may want to check 
     the Snort documentation for the most current information. 
     Basically, the answer to the question is that you can't do it. You'll 
     have to restart the Snort process to reload the rules. If you don't 
     want to miss any traffic while doing that, one trick is to start a 
     new Snort process before stopping the old one (possible existing 
     state information will be lost though). Some might argue that sending
     a SIGHUP signal will reload the rules without stopping Snort, but 
     that's not true as that will simply make Snort stop and restart 
     itself. Also, this currently requires that you run Snort as root 
     and non-chrooted. Don't ever do that.



Q2:  Can I use an external utility to download the rules archive rather
     than one of the built-in methods?

A2:  Yes, use whatever program you want and download the rules archive 
     to the local filesystem first, and then run Oinkmaster and point to 
     that file using file://<filename> as URL specification (url=<url> 
     in oinkmaster.conf or -u <url> on the command line).



Q29: I update from multiple URLs at the same time and get the error 
     "a file called 'sid-msg.map' exists in multiple rules archives"
     (or the same message for some other file).

A29: When updating from multiple URLs at the same time, the archives 
     can not contain files with identical filenames as the result will 
     go into a single output directory. Most rules archives include a 
     sid-msg.map file that is used by Barnyard and similar programs to 
     map a SID number into a rule msg string. When updating from 
     multiple URLs at the same time and you get the error message, you 
     must add "skipfile sid-msg.map" to your oinkmaster.conf to ignore 
     that file in all archives. If you need a sid-msg.map file, you must 
     generate it yourself. How this is done is described elsewhere in 
     this FAQ.
     


Q30: I get this error when running Oinkmaster:
     "URL not specified. Specify at least one 'url=<url>' in the
     Oinkmaster configuration file or use the '-u <url>' argument"

A30: The error message explains it all - you did not tell Oinkmaster 
     where to get the rules archive. Look in the default oinkmaster.conf 
     for more information. As of v1.2, no URL is specified by default in 
     the distribution oinkmaster.conf, so you must add at least one.



Q31: How do I add a new classification when using Oinkmaster?

Q31: It's often convenient to add new classifications for local 
     signatures that you create. You can not however put 
     those classification definitions in the regular classifications.conf 
     file that is updated by Oinkmaster, as those modifications would be 
     lost after an update. Instead, you can for example put your local 
     classification definitions in a file called local-classification.conf 
     and include that file with
     "include /path/to/local-classifications.conf" from your snort.conf, 
     just like you also include the regular classification.conf file.



Q32: What Perl modules do I need to be able to set use_external_bins = 0?

A32: To use pure Perl instead and not use any external binaries (except 
     when using scp do download the rules), you need the Perl modules 
     Archive::Tar, IO::Zlib and LWP::UserAgent. You can get them from 
     http://search.cpan.org. If you're on *BSD, they're most likely also 
     available in the ports tree. On OpenBSD they're called 
     p5-Archive-Tar, p5-IO-Zlib and p5-libwww. On Windows with 
     ActivePerl, all those modules are included and used by default.



Q33: Can I tell Oinkmaster to disable all rules by default, and only
     enable and update specific ones?

A33: Yes. This may be convenient if you for example want to update 
     rules from a third party, but you do not want to use their new 
     rules by default - you only want to use some specific SIDs
     and keep those updated automatically. This can be achieved with
     a 'modifysid' expression to disable all (or some) rules first,
     and then specify 'enablesid <sid>' to activate the rules you know 
     you want to use.

     Let's say there are a few specific rules you like from the 
     Bleeding Snort project, but you don't care about their other
     rules. You could copy those rules into some local rules file
     but that way they would not get updated if the Bleeding Snort
     project makes updates to their versions of the rules.
     The Oinkmaster way is better. First, use a 'modifysid'
     statement to disable all rules containing the "BLEEDING-EDGE"
     tag:

     modifysid * "^(.*BLEEDING\-EDGE.*)$" | "#${1}"
     
     Now, as 'enablesid' statements are processed after the
     'modifysid' statements, we can override them and reenable the 
     rules we like, for example:

     enablesid 2000566, 2000567, 2000568

     Now only the Bleeding Snort rules with SID 2000566, 2000567
     and 2000568 will be enabled and you can keep them automatically 
     updated. Oinkmaster will still update the other rules but they 
     will stay disabled (commented out), and changes in those will show 
     up as "Modified inactive rules". Remember that if you find a new 
     rule you want to use, you must add an 'enablesid' statement for it 
     as all added rules will be disabled by default.