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.

output alert_fast: output alert_full: alert.full output alert_syslog: LOG AUTH LOG_ALERT

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- cat /var/log/snort/alert.csv 
04/24-15:50:29.236253 ,1,498,6,ATTACK-RESPONSES 
id check returned 

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- cat /var/log/snort/alert.csv.short
04/24-15:50:29.236253 ,ATTACK-RESPONSES 
id check returned root


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- 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 ->
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- tcpdump -n -r 
reading from file /var/log/snort/tcpdump.log.1177529275, 
link-type EN10MB (Ethernet)
15:50:29.236253 IP > 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.


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.

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 
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


--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        *:*

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 analyst@ 
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-
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 
cel433:/root# mysql -e "SET password for 
cel433:/root# mysql --password=r00t -e 
"delete from user where Password=''" mysql
cel433:/root# mysql --password=r00t -e 

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- ./
configure --enable-dynamicplugin --with-mysql=/usr/local 

After changing to the /usr/local/snort- directory, copy the contents of the /usr/local/src/snort- directory to that directory. You need files like and others in the directory from which to run Snort.

cel433:/usr/local/snort- cp /usr/local/src/snort-* .

The following shows the changes made to the stock snort.conf file (in the new configuration file snort.conf. 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- ./bin/snort -c ./snort.conf. 
TCPDUMP file reading mode.
Reading network traffic from "" 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 =
[reading from a file]
database:     sensor id = 2
database: schema version = 107
database: using the "alert" facility
Action Stats:
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- 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.

This was last published in May 2007

Dig Deeper on Network security products, technologies, services



Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.





  • Passive Python Network Mapping

    In this excerpt from chapter two of Passive Python Network Mapping, author Chet Hosmer discusses securing your devices against ...

  • Protecting Patient Information

    In this excerpt from chapter two of Protecting Patient Information, author Paul Cerrato discusses the consequences of data ...

  • Mobile Security and Privacy

    In this excerpt from chapter 11 of Mobile Security and Privacy, authors Raymond Choo and Man Ho Au discuss privacy and anonymity ...