Snort has many logging options that can be specified at run time on the command line. If you also specify the use of a configuration file, remember that any option listed on the command line will override that same option in the config-uration file. The following options are useful when considering different logging options:
-A alert-mode This switch tells Snort to use one of various alert modes. alert-modecan be fast, full, none, or unsock (an experimental alert mode that sends alerts to a Unix socket, and is safe to ignore unless you like writing Unix socket code).
-b This option tells Snort to log packets in a tcpdump-formatted file. Using this switch, Snort will log all packetsgoing across the wire, not just those that match an attack pattern or other rule. This makes Snort behave almost exactly like tcpdump — including the use of tcpdump-style expres-sions to specify which traffic to grab.
-B address-conversion-mask This switch converts all IP addresses of your local network, or home network in the binary logs, to the address indicated by address-conversion-mask. In this way, you can share binary Snort logs with others without reveal-ing your home network address.
-C When logging packets as ASCII text, this switch prints the character data from the packet only without printing the corre-sponding hex data.
-d This switch prints Application-layer data when logging packets.
-e Displays Link-layer data in packet headers -h home-net Use this option to specify your
home network, which should be replaced in your binary logs with the network specified by the -B switch.
-l logging-directory This option will tell Snort to log to the specified direc-tory, rather than the default /var/log/snort directory.
-L binary-log-file When logging in the binary tcpdump format, this switch speci-fies where Snort should dump its packets.
-N This option turns off packet logging. This is useful when you want to specify a snort.
conf file that includes a packet logging option that you want to override. Snort will continue to generate alerts normally when this switch is used.
-O When logging packets as decoded plain text, this switch will change any IP addresses that get printed to “xxx.xxx.xxx.
xxx”, unless the “home net” is specified with the -h switch — in which case, home-net IP addresses will be changed but exter-nal addresses will be left unchanged. This is another method of hiding your home-network information when sharing your logs with others.
-P snap-length When capturing packets, this sets the packet snaplen(the amount of data in a packet that’s captured) to the value represented here by snap-length. -s Use this switch to send alerts to the Unix
syslog facility.
Enter the Snort database output module. By logging your alerts and packet logs to a database, you get a very stable format that scales exceptionally well, and allows for extremely fast searching and reporting. It’s not unusual to have Snort databases that are a gigabyte or so in size. By splitting each log entry into component pieces, and writing those pieces to different database tables, searching for a specific entry is fast enough that it can be done from a Web-server script to generate Web pages on the fly. Try to do thatwith a text file (you’d better have some errands to run while you wait for the output). These are some of the reasons why we chose to configure Snort for database output in Chapters 4 and 5.
With the database output module, Snort has the ability to send output to many SQL databases. As of version 2.1, Oracle, UnixODBC, MS-SQL, PostgreSQL, and the ever-popular MySQL are all supported by this plug-in.
If you plan to log your Snort data to a database, make sure you run the config-ure script with the appropriate flag to include support for your particular database format when you compile and install Snort. More information on compiling Snort is available in Chapter 4.
Database logging isn’t available as a command-line option to Snort. Instead, it must be configured in the snort.conf file. The format to include this module is:
output database: <log | alert>, <database type>, <parameter list>
The |(pipe) between logand alertis shorthand, indicating that you need to specify either logoralertas the logging method.
The database module differs from other reporting modules a bit in how it han-dles logs versus alerts. If you have the logkeyword in a Snort rule, when the rule is activated, it sends data on to the appropriate output module (usually log_tcpdump) by way of the logfacility. When the alertkeyword is used in -U Timestamps in all logs will be converted to
UTC (Universal Coordinated Time)
-v Print packets to the console. A nearly uni-versal Unix directive to be verbose. This is great for testing or debugging, but bad for
production environments, since it will slow down your system, and cause Snort to drop packets.
-y Show the year in your log files.
a Snort rule, the alertfacility is used, but data is also written to the log facil-ity. If the databaseplug-in is configured for alerts, it will onlyreceive output from rules that specify the alertkeyword. If the databaseplug-in is config-ured with the logoption, it receives output from alertrules andlogrules.
Sound confusing? Don’t sweat it. The logoption will work just fine for most situations.
So if you know that you want to use the logoption, and you already know what database type you’re going to use, you can move on to specifying the required parameters to make it all work. Some of these parameters must be specified; others will be filled in by Snort, if not by you. When written into your snort.conffile, each parameter is specified by a name=valuepair, where name is the parameter name, and value is, of course, its value.
host: The name or IP address of the host that’s running your database server. If you don’t include a hostname, Snort assumes you’re sending data over a Unix domain socket. If a host name or IP address is specified, Snort will use TCP/IP to send your data. If you’re running your database server on the same system as Snort, set your host to localhost. port: The port number your database server is listening on.
password: If your database server requires authentication, this is the password to use.
dbname: This is the database username used for authentication purposes when connecting to your database.
encoding: Binary data isn’t very portable across databases, but binary data is what we’ve got in our packet payload, so some form of encoding must be done to actually store the data in the database. Your options are as follows:
•hex: This is the default method. It represents binary data as a hex string, which makes for great searchability, but poor human-readability without some form of post-processing. This takes up twice as much space as binary data.
•base64: Binary data is represented as a base64 string, which is slightly larger than the binary data itself. This format isn’t very searchable or readable without post-processing.
•ascii: Since not all binary data can be represented as ascii, you will loose some data if you go this route. This takes up slightly more space than the original binary format, but gives you excellent searchability when looking for a text string. And of course, ascii text is infinitely readable by us humans.
sensor_name: If you want to specify a name for this particular Snort sensor, do so here. If not, Snort will come up with one for you.
detail: How much detail of the offending packets should be logged?
full: This is the default, which logs all the available information about the packet, including the packet payload, and its ip/tcpoptions.
fast: This will only log the timestamp, message signature, source IP address, destination IP address, source port, destination port, tcp flags, and protocol.
A minimalist configuration entry for database logging would look something like this:
output database: log, mysql, user=snortuser password=h4wg dbname=snortdb host=localhost