|
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: Michael Davis (mike
DATANERDS.NET)Date: Mon Oct 30 2000 - 20:22:53 CST
- Previous message: Robert Graham: "Re: Validating IDS Rulesets"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This should work as it is exactly what I used to get it working on
win32 and I wrote the snort-win32-mysql code ;)
Michael Davis
Chief Technical Officer
Data Nerds, LLC.
http://www.datanerds.net
- ----- Original Message -----
From: "Matt Baudendistel" <logicbox
PEAKNET.NET>
To: <FOCUS-IDS
SECURITYFOCUS.COM>
Sent: Monday, October 30, 2000 12:57 AM
Subject: Re: mysql & snort (win32)
> 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 jed
localhost;
>
> 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 "jed
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: log, mysql, dbname=snort user=jed
> host=localhost password=xyz
> <---- snip ---->
>
> Matt Baudendistel
> logicbox
peaknet.net
> ICQ: 13240420
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
iQA/AwUBOf4s+/iUqZ9dnoKsEQIKgwCgxhQJukq1Efb0gLot6XUXxCuNZdkAn287
ZFffCHVXXL+95Q6IQoYuZ82M
=/EPz
-----END PGP SIGNATURE-----
- Previous message: Robert Graham: "Re: Validating IDS Rulesets"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]