|
|
|
|
Next: csv
Up: database
Previous: database
Contents
database: <log | alert>, <database type>, <parameter list>
The following parameters are available:
-
- host
- - Host to connect to. If a non-zero-length string is specified, TCP/IP communication is used. Without a host name, it will connect using a local UNIX domain socket.
- port
- - Port number to connect to at the server host, or socket filename extension for UNIX-domain connections.
- dbname
- - Database name
- user
- - Database username for authentication
- password
- - Password used if the database demands password authentication
- sensor_name
- - Specify your own name for this Snort sensor. If you do not specify a name, one will be generated automatically
- encoding
- - Because the packet payload and option data is binary, there is no one simple and portable way to store it in a database. Blobs are not used because they are not portable across databases. So i leave the encoding option to you. You can choose from the following options. Each has its own advantages and disadvantages:
-
- hex
- (default) - Represent binary data as a hex string.
-
- Storage requirements
- - 2x the size of the binary
- Searchability
- - very good
- Human readability
- - not readable unless you are a true geek, requires post processing
- base64
- - Represent binary data as a base64 string.
-
- Storage requirements
- -
1.3x the size of the binary
- Searchability
- - impossible without post processing
- Human readability
- - not readable requires post processing
- ascii
- - Represent binary data as an ASCII string. This is
the only option where you will actually lose data. Non-ASCII
Data is represented as a `.'. If you choose this option, then data
for IP and TCP options will still be represented as hex because
it does not make any sense for that data to be ASCII.
-
- Storage requirements
- - slightly larger than the binary because
some characters are escaped (&,
, )
- Searchability
- - very good for searching for a text string impossible
if you want to search for binary
- human readability
- - very good
- detail
- - How much detailed data do you want to store? The options
are:
-
- full
- (default) - Log all details of a packet that caused an alert
(including IP/TCP options and the payload)
- fast
- - Log only a minimum amount of data. You severely limit the potential
of some analysis applications if you choose this option, but this
is still the best choice for some applications. The following fields
are logged: timestamp, signature, source ip, destination ip, source
port, destination port, tcp flags, and protocol)
Furthermore, there is a logging method and database type that must
be defined. There are two logging types available, log and alert.
Setting the type to log attaches the database logging functionality
to the log facility within the program. If you set the type to log,
the plugin will be called on the log output chain. Setting the type
to alert attaches the plugin to the alert output chain within the
program.
There are five database types available in the current version of the plugin.
These are mssql, mysql, postgresql, oracle, and odbc.
Set the type to match
the database you are using.
Note:
The database output plugin does not have the ability to handle alerts that are
generated by using the tag keyword. See section for more
details.
|
Figure:
Database Output Plugin Configuration
 |
Next: csv
Up: database
Previous: database
Contents
Steven Sturges
2007-10-04
|
|
|