OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: mysql & snort (win32)
From: Matt Baudendistel (logicboxPEAKNET.NET)
Date: Mon Oct 30 2000 - 00:57:51 CST

Here you go this got me up and going with the Linux version

Taken from the README.database file that comes with the Linux cvs version of
snort

<---- Snip ----->

1) Install MySQL, Postgresql, or (unixODBC + some other RDBMS)
        MySQL => http://www.mysql.org
        Postgresql => http://www.postgesql.org
        unixODBC => http://www.unixodbc.org

   2) Follow directions from your database vendor to be sure your
      RDBMS is properly configured and secured.

   3) Follow directions from your vendor to create a database for
      snort.
         MySQL example
         % echo "CREATE DATABASE snort;" | mysql -u root -p

   4) Create a user that has privileges to INSERT and SELECT
      on that database.
      example
         - First create a user - for this example we will use "jed"
         - now grant the right privileges for that user
> grant INSERT,SELECT on snort.* to jedlocalhost;

   5) Build the structure of the database according to files supplied
      with snort in the "contrib" directory as the user created in
      step 4.

      Do this while in the snort source directory.

      For MySQL
      % mysql < ./contrib/create_mysql

      For Postgresql
      % psql < ./contrib/create_postgresql

      If you are using unixODBC, be sure to properly configure and
      test that you can connect to your data source (DSN) with isql
      before trying to run snort.

      For RDBMS other than MySQL and Postgresql that are accessed
      through ODBC you will need to create the database
      structure yourself because datatypes vary for different
      databases. You will need to have the same column names and
      functionality for each column as in the mysql and
      postgresql examples. The mysql file is the best example to
      follow since it is optimized (given that mysql supports tiny
      ints and unsigned ints). I intend to document this process
      better in the future to make this process easier.

      As you create database structure files for new RDBMS mail
      them in so they can be included as part of the distribution.

III. Plugin Configuration

You must add some information to the snort configuration file
to enable database logging. The configuration file distributed
with snort has some sample configuration lines.

The configuration line will be of the following format:

   output database: [log | alert], [type of database], [parameter list]

Arguments:

   [log | alert] - specify log or alert to connect the database
       plugin to the log or alert facility. In most cases you will
       likely want to use the log facility.

   [type of database] - You must supply the type of database. The
       possible values are mysql, postgresql, and unixodbc.

   [parameter list] - The parameter list consists of key value
       pairs. The proper format is a list of key=value pairs each
       separated a space.

       The only parameter that is absolutely necessary is "dbname".
       All other parameters are optional but may be necessary
       depending on how you have configured your RDBMS.

       dbname - the name of the database you are connecting to

       host - the host the RDBMS is on

       port - the port number the RDBMS is listening on

       user - connect to the database as this user

       password - the password for given user

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

   The configuration I am currently using is MySQL with the database
   name of "snort". The user "jedlocalhost" has INSERT and SELECT
   privileges on the "snort" database and requires a password of
   "xyz". The following line enables snort to log to this database.

   output database: log, mysql, dbname=snort user=jed host=localhost
password=xyz
<---- snip ---->

Matt Baudendistel
logicboxpeaknet.net
ICQ: 13240420