|
# $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=' in the
Oinkmaster configuration file or use the '-u ' 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//
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 = " in oinkmaster.conf
or use the "-u " 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: ;'. 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 " 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= in the configuration
file or by specifying several -u 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:// as URL specification (url=
in oinkmaster.conf or -u 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=' in the
Oinkmaster configuration file or use the '-u ' 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 ' 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.
|
