Snort.conf output options
Snort offers functional equivalents for FAST, FULL and SYSLOG command line output modes, as shown here.
Snort offers functional equivalents for FAST, FULL and SYSLOG command line output modes, as shown below. These directives can be placed in the snort.conf file.
The alert_syslog option allows... setting Syslog facility and priority, which is handy.
From the snort.conf file, I can also use the alert_csv output option. This output method permits writing alert details in CSV format. By default, a great number of options are printed.
output alert_csv: alert.csv default • timestamp • sig generator • sig id • sig rev • msg • proto • src • srcport • dst • dstport • ethsrc • ethdst • ethlen • tcpflags • tcpseq • tcpack • tcplen • tcpwindow • ttl • tos • id • dgmlen • iplen • icmptype • icmpcode • icmpid • icmpseq cel433:/usr/local/snort-2.6.1.4# cat /var/log/snort/alert.csv 04/24-15:50:29.236253 ,1,498,6,ATTACK-RESPONSES id check returned root,TCP,82.165.50.118,80,69.143.202.28,39929, 0:1:5C:22:AA:C2,0:2:B3:A:CD:5E,0x154,***AP***, 0xD6D45629,0xD3786273,,0x 1920,48,32,52671,326,20,,,,
Alternatively, any combination of keywords, in any order, may be called. Here we tell Snort to write the alert timestamp and message to the alert.csv.short file.
output alert_csv: alert.csv.short timestamp,msg cel433:/usr/local/snort-2.6.1.4# cat /var/log/snort/alert.csv.short 04/24-15:50:29.236253 ,ATTACK-RESPONSES id check returned root
LOG_TCPDUMP
Finally, Snort can be told to simply log offending traffic to a file specified by the log_tcpdump output option.
output log_tcpdump: tcpdump.log
In this mode Snort will write an alert in FULL format to the alert file, and it will save traffic to a file called tcpdump.log.TIMESTAMP.
cel433:/usr/local/snort-2.6.1.4# cat /var/log/snort/alert
[**] [1:498:6] ATTACK-RESPONSES id check returned root [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
04/24-15:50:29.236253 82.165.50.118:80 ->
69.143.202.28:39929
TCP TTL:48 TOS:0x20 ID:52671 IpLen:20 DgmLen:326 DF
***AP*** Seq: 0xD6D45629 Ack: 0xD3786273 Win: 0x1920
TcpLen: 20
cel433:/usr/local/snort-2.6.1.4# tcpdump -n -r
/var/log/snort/tcpdump.log.1177529275
reading from file /var/log/snort/tcpdump.log.1177529275,
link-type EN10MB (Ethernet)
15:50:29.236253 IP 82.165.50.118.80 > 69.143.202.28.39929: P
3604239913:3604240199(286) ack 3547882099 win 6432
You may notice that calling log_tcpdump results in the same results as using alert_full, except the name of the Libpcap trace is different. This is due to the fact that the default packet logging mode for Snort in alert_full is Libpcap.
The Unix socket option can be called via
output: alert_unixsock
but I don't cover using that option here.
DATABASE OUTPUT
I hesitate to discuss the following option, but I include it for completeness. With the exception of the SYSLOG and Unix socket output modes, all of the previous modes wrote their data to disk. This method allows Snort to rapidly process data and store its results. A single-threaded program cannot devote individual threads to various system operations like a multi-threaded program can. When Snort saves data to a destination other than the local hard drive, any delay results in the inspection engine dropping packets. An excellent way to cause Snort to drop packets is to tell Snort to send its output directly to a database.
Those who wish to send Snort data to a database should use Unified output. Unified output is a means to let Snort write data to disk, after which Unified output can be read and sent to a database. A program to read Unified output, Barnyard, has been available since December 2002. Unfortunately, many popular Snort installation guides continue to recommend configuring Snort to log directly to a database. Whenever possible, those wishing to log to a database should use Unified output. Because Unified output offers many other options, I devote the next Snort Report to that subject.
Here, I show how to use Snort's native output_database option for MySQL.
First I install MySQL Server 5.1.x on FreeBSD via a package.
cel433:/root# pkg_add -vr mysql51-server cel433:/root# /usr/local/bin/mysql_install_db --user=mysql Installing all prepared tables Fill help tables To start mysqld at boot time, copy support-files/mysql.server to the right place for your system. PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER! To do so, start the server, then issue the following commands: /usr/local/bin/mysqladmin -u root password 'new-password' /usr/local/bin/mysqladmin -u root -h cel433.taosecurity.com password 'new-password' See the manual for more instructions. You can start the MySQL daemon with: cd /usr/local ; /usr/local/bin/mysqld_safe & You can test the MySQL daemon with the benchmarks in the 'sql-bench' directory: cd sql-bench ; perl run-all-tests Please report any problems with the /usr/local/bin/mysqlbug script! Support MySQL by buying support/licenses.
Next, start MySQL.
cel433:/root# /usr/local/bin/mysqld_safe --bind-address .0.0.1 --user=mysql & [1] 89460 cel433:/root# Starting mysqld daemon with databases from /var/db/mysql
When started, MySQL listens on port 3306 TCP on localhost.
cel433:/root# sockstat -4 | grep 3306 mysql mysqld 89478 10 tcp4 127.0.0.1:3306 *:*
Create the "snort" database, and permit user "analyst" to manipulate it.
cel433:/root# mysql -e "CREATE DATABASE snort" cel433:/root# mysql -e "GRANT INSERT, SELECT, CREATE, DELETE, UPDATE ON snort.* TO [email protected] IDENTIFIED BY 'analyst'" cel433:/root# mysql -e "GRANT INSERT, SELECT, CREATE, DELETE, UPDATE ON snort.* TO analyst@localhost IDENTIFIED BY 'analyst'"
Call upon a script packaged with Snort to create the database tables Snort needs.
cel433:/root# mysql < /usr/local/src/snort-2.6.1.4/schemas/ create_mysql snort
Verify the tables were created.
cel433:/root# mysql -e "SHOW TABLES" snort +------------------+ | Tables_in_snort | +------------------+ | data | | detail | | encoding | | event | | icmphdr | | iphdr | | opt | | reference | | reference_system | | schema | | sensor | | sig_class | | sig_reference | | signature | | tcphdr | | udphdr | +------------------+
With the database configured, assign passwords for user analyst and root, and delete all other records where no password is set.
cel433:/root# mysql -e "SET password for
analyst@localhost=password('analyst')"
cel433:/root# mysql -e "SET password for
root@localhost=password('r00t')"
cel433:/root# mysql --password=r00t -e
"delete from user where Password=''" mysql
cel433:/root# mysql --password=r00t -e
"FLUSH PRIVILEGES"
Check the permissions on the /var/log/snort directory, and ensure that user analyst can write to the directory by making analyst the owner.
cel433:/root# ls -ald /var/log/snort drwxr-xr-x 2 root wheel 512 Apr 24 14:18 /var/log/snort cel433:/root# chown analyst:analyst /var/log/snort
Configure Snort to support database output with the "--with-mysql=/usr/local" option. I address how to compile Snort in the first Snort Report.
cel433:/usr/local/src/snort-2.6.1.4# ./ configure --enable-dynamicplugin --with-mysql=/usr/local --prefix=/usr/local/snort-2.6.1.4
After changing to the /usr/local/snort-2.6.1.4 directory, copy the contents of the /usr/local/src/snort-2.6.1.4/etc directory to that directory. You need files like sid-msg.map and others in the directory from which to run Snort.
cel433:/usr/local/snort-2.6.1.4# cp /usr/local/src/snort-2.6.1.4/etc/* .
The following shows the changes made to the stock snort.conf file (in the new configuration file snort.conf.2.6.1.4) to support database output.
output database: alert, mysql, user=analyst password=analyst dbname=snort host=localhost
As you can see by the host directive, it's possible to tell Snort to log to a remote database. This is usually a performance killer. Here we're logging to a database on the same host as Snort. Depending on the network load and the host hardware, this can also kill Snort's performance. For these reasons database logging should use Unified output.
With the configuration file changed, tell Snort to read out test trace.
cel433:/usr/local/snort-2.6.1.4# ./bin/snort -c ./snort.conf.2.6.1.4
-r www.testmyids.com.lpc
...edited...
TCPDUMP file reading mode.
Reading network traffic from "www.testmyids.com.lpc" file.
snaplen = 1514
database: compiled support for ( mysql )
database: configured to use mysql
database: user = analyst
database: password is set
database: database name = snort
database: host = localhost
database: sensor name = cel433.taosecurity.com:
[reading from a file]
database: sensor id = 2
database: schema version = 107
database: using the "alert" facility
...edited...
Action Stats:
ALERTS: 1
LOGGED: 1
PASSED: 0
===============================================
================================
TCP Stream Reassembly Stats:
TCP Packets Used: 10 (100.000%)
Stream Trackers: 1
Stream flushes: 1
Segments used: 1
Segments Queued: 1
Stream4 Memory Faults: 0
================================================
===============================
database: Closing connection to database "snort"
Snort exiting
One alert was generated. If you look at the database using a MySQL client, you see a new alert in the event table.
cel433:/usr/local/snort-2.6.1.4# mysql -u analyst --password= analyst -e "select * from event" snort +-----+-----+-----------+---------------------+ | sid | cid | signature | timestamp | +-----+-----+-----------+---------------------+ | 2 | 1 | 1 | 2007-04-24 15:50:29 | +-----+-----+-----------+---------------------+
Looking at Snort alerts via MySQL command line access is not efficient. In a future Snort Report I'll introduce several programs that can read events from a database. Suffice it to say for now, you can test that database logging is working by querying the database directly.
In addition to supporting MySQL, Snort supports PostgreSQL, ODBC and Microsoft SQL Server interfaces. Furthermore, options to either "alert" or "log" can be specified. The snort.conf file gives a few examples.
# output database: alert, postgresql, user=snort dbname=snort # output database: log, odbc, user=snort dbname=snort # output database: log, mssql, dbname=snort user=snort password=test
You should now have a good understanding of various output modes for Snort. In the next Snort Report we'll cover the final mode, which uses unified output.
