Re: No logging to mysql in snort 2.4.x

On Fri, 3 Feb 2006, Dirk Geschke wrote:
> > My question is why snort 2.4 doesn't work when there's no problems with 2.3.
> are you really sure about this? If the connection to the database is
> interrupted you have to re-connect. This is never done in the database
> output plugin. The connect to the dabase is done on startup of snort,
> never ever later again.

Yes I'm sure. You must remember things incorrectly.

> Use 2.3 again, kill the database, wait for some alerts and restart the
> database without touching snort and see if there arrive any new alerts...

Now I have tried it, and 2.3 works fine while 2.4 doesn't.
See the full test scheme below.

> This is one of the reasons why you should not use the database output
> plugin, there are better solutions available.

Yes, I'm aware of this. I run barnyard on the "live system", but it is 
nice to have the option to log directly to the database for testing 
purposes.


I also got the following tip from Thomas Seiler:
> > Snort 2.4.3-build-27 stops logging to mysql after a few minutes or
> > hours.
> We have had issues with mysql and snort 2.4.3 aswell. It seems that
> either snort or libmysqlclient is trashing the stack and then we lose
> the connection to the mysql database.
>
> I don't understand what's happending, the trashed stack makes debugging
> really hard.
>
> It helped however to compile snort using -O1 instead of -O2. When using
> -O1, the mysql connection was stable (for several days already).
> BTW: we used gcc version 3.3.6 (Gentoo)
> Could you give it a try using -O1 or -O0 and see it its stable then ?

I have now compiled snort 2.4 with -O1 but it still doesn't work.



Test scheme:

Everything is run from the same client machine and towards the same mysql 
server.

I use the following output plugins:

  output log_tcpdump: $SENSOR_NAME-snort.tcpdump
  output alert_fast: $SENSOR_NAME-snort.alert
  output database: log, mysql, user=$DB_USER password=$DB_PASSWORD
    dbname=$DB_NAME host=$DB_HOST sensor_name=$SENSOR_NAME


01.
I'm running snort-2.3-build-8 with mysql support. It is logging alerts 
directly to the mysql database via tcp/3306.
I have a tcp connection from the client (tcp/3152) to the server (tcp/3306).
Everything is working fine. Alerts are inserted into the database.


02.
I block port tcp/3306 in the firewall to simulate an ISP failure and then 
force a new alert to be triggered.

I see 13 tcp retransmission attempts for the SQL BEGIN query. After this, 
snort gives up and send a RST. The tcp connection is dropped.

I force a new alert to be triggered. Now I see 9 retransmissions of tcp 
SYN packets from the client (tcp/2170) to the server (tcp/3306).

I force a new alert to be triggered. Now I see 9 retransmissions of tcp 
SYN packets from the client (tcp/2336) to the server (tcp/3306).


03.
Now I remove the 3306 filter from the firewall and force a new alert to be 
triggered.

The client performs a tcp three way handshake with the mysql server and 
then send the BEGIN, SELECT, INSERT (event, tcphdr, iphdr and data) and 
COMMIT commands. (from client port tcp/1128)

All new alerts that are triggered now use this tcp session from tcp/1128 
to tcp/3306. Everything is working fine.

Conclusion: snort-2.3-build-8 can handle an ISP failure since it 
automaticly reconnects to the database (you only loose the alerts during 
the downtime).

---

04.
Now I run snort-2.4.3-build-27 with mysql support.
I have a working connection from tcp/2413 to tcp/3306 and alerts are 
inserted into the database.


05.
I simulate an ISP failure.
Again, I see 13 retransmissions and finally the RST packet.
After this I don't see any tcp SYN packets to tcp/3306!
No more alerts are logged to the database. Logging to the local harddrive 
(alert_fast, log_tcpdump) is still working though.

Conclusion: snort-2.4.3-build-27 does NOT automaticly reconnect to the 
database after a failure.

---

06.
Now I run snort-2.4.4-build-28 with mysql support, compiled with -O1 gcc 
flags as hinted by Thomas Seiler.
I have a working connection from tcp/4693 to tcp/3306 and alerts are 
inserted into the database.


07.
I simulate an ISP failure.
Again, I see 13 retransmissions and finally the RST packet.
After this I don't see any tcp SYN packets to tcp/3306!
No more alerts are logged to the database. Logging to the local harddrive 
(alert_fast, log_tcpdump) is still working though.

Conclusion: snort-2.4.4-build-28 does NOT automaticly reconnect to the 
database after a failure. The optimization of the compilation have nothing 
to do with this.

---

Why is the automatic reconnect function removed from snort v2.4?
Can you please put it back?

Regards,
/Martin Olsson


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642