From the recent upgrade of Snort 2.4 to 2.6, we started encountering some weird issues with MySQL 5. What tends to happen if MySQL is restarted or there is a large gap between alerts, snort will complain that MySQL has gone away. I’m not sure where to point the problem, is this a MySQL problem or a Snort problem?
If you restart MySQL, Snort will constantly complain that MySQL has gone away. To remedy the problem, you need to restart Snort after every MySQL restart, and everything returns to normal.
The other issue that was extremely hard to track down was when a large gap of time (usually 4-6 hours) between alerts occurred. At this time Snort states that MySQL has gone away. It appears that Snort needs a persistent connection to MySQL, and when a gap occurs that connection is lost or ‘released’ due to timeout, and Snort doesn’t initiate a new connection to MySQL.
From the recent upgrade of Snort 2.4 to 2.6, we started encountering some weird issues with MySQL 5. What tends to happen if MySQL is restarted or there is a large gap between alerts, snort will complain that MySQL has gone away. I’m not sure where to point the problem, is this a MySQL problem or a Snort problem?
If you restart MySQL, Snort will constantly complain that MySQL has gone away. To remedy the problem, you need to restart Snort after every MySQL restart, and everything returns to normal.
The other issue that was extremely hard to track down was when a large gap of time (usually 4-6 hours) between alerts occurred. At this time Snort states that MySQL has gone away. It appears that Snort needs a persistent connection to MySQL, and when a gap occurs that connection is lost or ‘released’ due to timeout, and Snort doesn’t initiate a new connection to MySQL.
Here is an example of what the log looks like:
May 31 08:38:26 comp snort[20202]: database: mysql_error: MySQL server has gone away SQL=BEGIN
May 31 08:38:26 comp snort[20202]: database: mysql_error: MySQL server has gone away
May 31 08:38:26 comp snort[20202]: database: mysql_error: MySQL server has gone away
May 31 08:38:26 comp snort[20202]: database: mysql_error: MySQL server has gone away SQL=INSERT INTO sig_class (sig_class_name) VALUES ('mis
c-activity')
May 31 08:38:26 comp snort[20202]: database: mysql_error: MySQL server has gone away
May 31 08:38:26 comp snort[20202]: database: unable to write classification
May 31 08:38:26 comp snort[20202]: database: mysql_error: MySQL server has gone away SQL=INSERT INTO signature (sig_name,sig_priority,sig_re
v,sig_sid,sig_gid) VALUES ('ICMP PING CyberKit 2.2 Windows',3,6,483,1)
May 31 08:38:26 comp snort[20202]: database: mysql_error: MySQL server has gone away
May 31 08:38:26 comp snort[20202]: database: Problem inserting a new signature 'ICMP PING CyberKit 2.2 Windows': INSERT INTO signature (sig_
name,sig_priority,sig_rev,sig_sid,sig_gid) VALUES ('ICMP PING CyberKit 2.2 Windows',3,6,483,1)
May 31 08:38:26 comp snort[20202]: database: mysql_error: MySQL server has gone away
May 31 08:38:26 comp snort[20202]: database: mysql_error: MySQL server has gone away SQL=INSERT INTO reference_system (ref_system_name) VALU
ES ('arachNIDS')
May 31 08:38:26 comp snort[20202]: database: mysql_error: MySQL server has gone away
May 31 08:38:26 comp snort[20202]: database: Unable to insert unknown reference tag ('154') used in rule.
May 31 08:38:26 comp snort[20202]: database: mysql_error: MySQL server has gone away SQL=INSERT INTO event (sid,cid,signature,timestamp) VAL
UES (1, 35560, 0, '2007-05-31 08:38:26')
May 31 08:38:26 comp snort[20202]: database: mysql_error: MySQL server has gone away SQL=ROLLBACK
Now, one way to fix this ‘gap’ issue is to add the following to mysql/my.cnf
wait_timeout = 10000000
This adds an extremely long wait timeout, hopefully you’ll have a alert that will happen within that amount of idle time. Since I added this, my problems have gone away. Make sure you restart MySQL/Snort after you add this value.
Hopefully this will help someone else, since this problem was hard to track down and address.