Skip to content
This repository
branch: spooler-cache
Fetching contributors…

Octocat-spinner-32-eaf2f5

Cannot retrieve contributors at this time

file 396 lines (306 sloc) 16.258 kb
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395
I. Summary

The database output plug-in enables snort to log to

  - Postgresql,
  - MySQL,
  - any unixODBC database,
  - MS SQL Server and
  - Oracle.

This README contains some quick information about how to set up and
configure database logging with in snort. More complete and
update to date documentation about this plugin can be found at:

 Documentation:

 http://www.andrew.cmu.edu/~rdanyliw/snort/snortdb/snortdb.html

 FAQ:

 http://www.andrew.cmu.edu/~rdanyliw/snort/snortdb/snortdb_faq.html

Questions or comments about the database plugin can be directed to
Roman Danyliw <roman@danyliw.com> or to the snort-users mailing
list.

II. Database Setup

To get this plug-in working you must have a database set up and
configured properly. Take the the following steps to get things
working.

   1) Install MySQL, Postgresql, Oracle, MS SQL Server or
      (unixODBC + some other RDBMS)
        MySQL => http://www.mysql.org
        Postgresql => http://www.postgesql.org
        unixODBC => http://www.unixodbc.org
        Oracle => http://www.oracle.com
        SQL Server => http://www.microsoft.com

   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 "snortusr"
         - now grant the right privileges for that user
         > grant INSERT,SELECT on snort.* to snortusr@localhost;
         - In addition, grant that user the UPDATE privilege on the
           'sensor' table
         > grant INSERT,SELECT,UPDATE on snort.sensor to snortusr@localhost;

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

      Do this while in the snort source directory.

      For MySQL
      % mysql -D snort -u root -p < ./schemas/create_mysql

      For Postgresql
      % psql snort < ./schemas/create_postgresql

      For Oracle
      The file "./schemas/create_oracle.sql" contains the database
      structure.

      For MS SQL Server
      The file "./schemas/create_mssql" contains the database
      structure.

      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 data types 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, odbc, mssql, and oracle.

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

       ignore_bpf - Do we want to create a new sensor definition every time
                the BPF filter is changed? The options are:

                [no|0]: (default) Create a new sensor definition if BPF
                        filter has been modified

                [yes|1]: Ignore the BPF part when looking for the server
                         definition



        MYSQL ONLY

        ssl_key - the name of the SSL key file to use for establishing a secure
             connection.

        ssl_cert - the path of the SSL certificate file to user for establishing
             a secure connection.

        ssl_ca - the path to a file that contains a list of trusted SSL CAs.

        ssl_ca_path - The path to a directory that contains trusted SSL CA
             certificates in PEM format.

        ssl_cipher - A list of allowable ciphers to user for SSL encryption. For
             greatest portability, the cipher list should be of one or more
             cipher namges, separated by colons. Examples:

             ssl_cipher=AES128-SHA
             ssl_cipher=DHE-RSA-AES256-SHA:AES128-SHA

             If no cipher in the list is supported, SSL connections will not work.


        POSTGRESQL ONLY

        ssl_mode - SSL requirement for connection to the postgresql server

                [disable]: will attempt only an unencrypted SSL connection.

                [allow]: will negotiate, trying first a non-SSL connection, then
                         if it fails, tryin an SSL connection.

                [prefer]: (default) will negotiate, trying first an SSL
                          connection, then if that fails, trying a regular
                          non-SSL connection.

                [require]: will try only an SSL connection.

   The configuration I am currently using is MySQL with the database
   name of "snort". The user "snortusr@localhost" 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: alert, mysql, dbname=snort user=snortusr host=localhost \
                    password=xyz

IV. Changelog

2002-10-16: Escape the signature name before trying to write it to the
                 signature.sig_name field
2002-10-14: Transaction abstraction functions (Begin/Commit/Rollback)
            Fixed transaction SQL for MS-SQL
            Fixed incorrect return value for MS-SQL Insert()
2002-10-12: Fixed (PostgreSQL) sensor initialization to the sensor table
                 by setting a default last_cid value
            Fixed schema detection bug on MS-SQL enabled builds
2002-09-17: Make sure that a packet payload larger than those supported
                 in the SQL INSERT are properly terminated
2002-09-12: Made the updating of the sensor.last_cid more efficient by
                 only storing the new cid value at shutdown
2002-09-05: Added ignore_bpf option <michael.boman@securecirt.com>
2002-09-03: New schema v106
            The database now remembers the last used cid for a given sensor
                 (via the sensor.last_cid field). Cids will no longer ever
                 be re-used (even if an alert are deleted).
2002-08-13: Fixed logic to detect the DB schema version correctly when support
            for MS-SQL and another database are present
2002-08-12: Fixed length bug in code that generates the SQL INSERT statement
                 into signature table
2002-06-05: Fixed memory leak occurring when a signature is seen for the
            first time (Dirk Geschke)
2002-04-13: Fixed memory leak with query results structure under PostgreSQL
2002-04-15: Detect and use correct OCI library (v8 or 9) (Chad Kreimendahl)
            Improved debugging messages on Oracle connection failure
                (Imran Smith)
2002-02-28: New schema v105
            Added support for native Oracle date format
2002-01-16: Fixed double-free of signature if it could not be inserted into
                the database
2002-01-13: Properly escaped database fields with a quote character
2001-10-23: Truncate reference names larger than the underlying database
                schema will support
2001-10-04: Catch condition where the iphdr is NULL
2001-09-26: New schema v104
2001-09-06: Made Oracle error reporting more verbose
2001-08-29: Properly chose unique signatures from the database using
                 the signature name, ID, and revision number
2001-08-28: Cleaned up semi-colon use in SQL for Oracle
2001-08-11: Made ODBC error reporting more verbose
            Incorporated changes to create_oracle.sql from Andrew Stubbs
            Chris Reid contributed MSSQL support! Sweet!
            Fixed a couple FatalError() calls that should have been
                  ErrorMessage() calls.
2001-06-15: New schema v103
            Removed support for schema v0, v100-v102
            Removed duplicate logging of IP addresses as 4-byte octets
            Removed classification level priorities
            Removed classification description from schema
            Removed hard-coded classifications from the create_* scripts.
               Classification information is now logged like a reference;
               on the first instance of a rule, log its classification
            Added support for the 'priority', 'rev', 'sid' rule options
2001-02-16: Added "INSERT DELAYED" for MySQL
2001-01-18: Incorporated fragment logging patch.
2000-12-31: Incorporated Oracle Patch.
2000-10-05: Created README.database and removed documentation from
               spo_database.c
2000-10-03: Added sensor_name configuration option
2000-09-29: Added configuration option enabling user to connect
               the plugin to the alert or log facility
            Changed name from spo_log_database to spo_database
            Removed all old references to the log facility
            Fixed a logic error that prevented messages from
               the portscan preprocessor to be logged.
2000-08-24: Fixed the full logging of tcp fields
            Added encoding and detail to sensor table
            Added escaping for the ascii character '
            Added hex binary logging support
            Added detail and encoding to sensor table
            Slightly changed data table to make more sense
            Added encoding option so you can select hex, base64,
               or ascii for logging binary data
            Added the "detail" option so you can choose between
               full and fast logging.
2000-08-23: A lot of code cleanup.
            Added linked list to store queries before they are
               executed.
            Added all tcp, udp, and icmp fields
            Added support for tcp and ip options
            Added support for logging the packet payload
2000-08-14: Added usage, very verbose error messages and other
               small fixes. No real functional changes. This update
               is focused on making the plugin easier to install
               and configure.
2000-06-06: Multiple instantiations is now working
2000-06-06: Added restart and cleanexit functions
2000-06-02: Bugfixes, better error reporting
2000-05-09: Bugfixes, documentation fixes, and added some
            better error reporting
2000-04-13: Bugfixes
2000-04-03: Updated database structure
2000-03-28: Added unixODBC support
            Added MySQL support
            Changed database structure
2000-03-08: Added new table "sensor" and a new field to event
            table to represent the sensor
2000-03-08: Added locking on inserts to eliminate concurrency
               problem
2000-03-08: Changed "type" and "code" in icmphdr to int2 instead
               of char
2000-03-01: Added extra argument to RegisterOutputPlugin
2000-02-28: First release

V. Changelog of Database schema

2002-09-03 -- v106
  + ALL: added sensor.last_cid to store the last used cid for a
         given sid

2002-02-28 -- v105
  + ORACLE: event.timestamp redefined as a DATE

2001-09-26 -- v104
  + ALL: enlarged reference.reg_tag field ( TEXT or VARCHAR(100) )

2001-06-15 -- v103
  + ALL: removed 4-octet representation from iphdr
  + ALL: removed all classification/priority definitions from the
         DDL scripts
  + ALL: added support for signature priorities, ID, and revision ID

2001-05-12 -- v102
  + ALL: added support for signature classification

2001-05-07 -- v101
  + POSTGRESQL: fixed bug from v100 to properly define event.signature

2001-03-16 -- v100
  + ALL: normalization of the signature representation
  + ALL: created schema table to self-document the schema version
  + ALL: added support for signature references

2000-02-08 -- v0
  + initial release
Something went wrong with that request. Please try again.