[Snort-users] Re: ACID Configuration

Jed Pickel jed at ...153...
Mon Nov 13 12:17:23 EST 2000


> Karl is absolutely right. Should the mysql daemon die or connectivity to
> it be impaired (be it extremely high network latency or actual
> disconnect), Snort will drop the alert after only a single attempt.  When
> this occurs, an error message like the following will probably appear:
> 
> "database: mysql_error: MySQL server has gone away"

I plan to start adding queuing and a number of fault tolerant, denial
of service prevention, etc... type features after we get snort v1.7
out the door. In the mean time there are a few options you have to
prevent loosing data.

First off I encourage people to use the tcpdump plugin to log the raw
packets as a backup. Once you have this there are a couple of options
for how to set things up depending on whether of not you are
interested in real time alerts.

If you do not need real time alerts you can completely avoid issues of
loosing data in database connectivity faults. Set up your production
sensors to log to tcpdump files. Pull those files using ssh or your
remote file copying tool of choice at some regular interval to a
central repository. Then replay them through another instance of snort
that has the sole purpose of populating your database. Then you can
use ACID or some other analysis tool to crunch through the data.

If you need real time alerts logged directly to your database, you
need to keep your eye out for the "MySQL server has gone away"
message. If you get that message, you can see how many alerts your
lost and what the possible time range they happened by looking for
gaps in the "cid" field. Here is an example I just cooked up.

In this example I was alerting on any TCP traffic and I shut down the
mysql server on purpose to simulate an error. You can notice a gap
between cid 8 and 21. This means 12 alerts were lost. 

mysql> select * from event;
+-----+-----+-----------+---------------------+
| sid | cid | signature | timestamp           |
+-----+-----+-----------+---------------------+
|   2 |   1 | TCP       | 2000-11-13 11:21:44 |
|   2 |   2 | TCP       | 2000-11-13 11:21:44 |
|   2 |   3 | TCP       | 2000-11-13 11:21:44 |
|   2 |   4 | TCP       | 2000-11-13 11:21:44 |
|   2 |   5 | TCP       | 2000-11-13 11:21:56 |
|   2 |   6 | TCP       | 2000-11-13 11:21:56 |
|   2 |   7 | TCP       | 2000-11-13 11:21:56 |
|   2 |   8 | TCP       | 2000-11-13 11:21:56 |
|   2 |  21 | TCP       | 2000-11-13 11:23:55 |
|   2 |  22 | TCP       | 2000-11-13 11:23:55 |
|   2 |  23 | TCP       | 2000-11-13 11:23:55 |
|   2 |  24 | TCP       | 2000-11-13 11:23:55 |
+-----+-----+-----------+---------------------+

You can see the lost alerts happened between 11:21:56 - 11:23:55. You
can then use those values with tcpslice to extract the alerts from
your backup tcpdump files and replay them through an instance of snort
to insert the lost alerts. This could probably be done with a simple
perl script; however, I don't have time to write it right now.

The other alternative is to use two databases and both of the methods
described above with one database having the purpose of handling real
time alerts and another used for archival and long term analysis
purposes.

* Jed



More information about the Snort-users mailing list