|
|
Snort Forums Archive
Archive Home » Snort Development » Snort 2.4.3 (Build 26) on OpenBSD 3.8/sparc64
Please note that the categories listed below represent an archived version of our forums pages. To view the current version and be able to post and reply to threads, please register and login here to go to the full forums pages.
[ Notice: Full Version of This Topic ]
Snort 2.4.3 (Build 26) on OpenBSD 3.8/sparc64
Posted by gramsa49 on December 23, 2005 18:00:11
I have run into an issue where Snort is unable to create events properly in mySql due to the date format sent to mySql. Here is the relevant portion of tcpdump output of the insert statement:
INSERT.IN
TO.event.(sid,ci
d,signature,time
stamp).VALUES.('
1',.'164',.'8',.
'2005-12-23.22:3
7:16.257698037'
When formatted, this states:
INSERT INTO event(sid,cid,signature,timestamp) VALUES ('1','164','8','2005-12-23 22:37:16.257698037');
mySql only supports storing date/time information to the precision of 1 second. This is attempting to send the time to the precision of 1/1000000000 second. When a value is inserted where the precisiion is greater than 1/100000 second, the value fails and the default defined for the column is used (which in this case is 0000-00-00 00:00:00). The insert succeeds, but the event time is not recorded.
I started looking through the source code for where this sql is generated and isolated it to spo_database.c. When looking through this file, there is a section that sets the precision of date/time values to 1 second for Oracle, but there is no complementary section defined for mySql.
By inserting the following code, I am able to resolve the problem:
1008 /* Added by Axton to fix the millisecond problem with mySQL */
1009 #ifdef ENABLE_MYSQL
1010 if (data->shared->dbtype_id == DB_MYSQL)
1011 {
1012 /* Oracle (everything before 9i) does not support
1013 * date information smaller than 1 second.
1014 * To go along with the TO_DATE() Oracle function
1015 * below, this was written to strip out all the
1016 * excess information. (everything beyond a second)
1017 * Use the Oracle format of:
1018 * "1998-01-25 23:59:59"
1019 */
1020 if ( timestamp_string!=NULL && strlen(timestamp_string)>20 )
1021 {
1022 timestamp_string[19] = '\0';
1023 }
1024 }
1025 #endif
Axton Grams |
|
Posted by brevizniak on January 06, 2006 15:20:14
What version of mysql?
If you would like to submit the patch for inclusion please reference doc/BUGS in the src distribution and send a unified diff to snort-team@sourcefire.com |
|
Posted by gramsa49 on January 06, 2006 15:33:44
mysql version:
mysql Ver 14.7 Distrib 4.1.16 for redhat-linux-gnu (i386) using readline 4.3
I'll read the doc/BUGS and see what I can do for a diff. This is the diff I presently have:
# diff -u -p /home/agrams/packages/snort-2.4.3/src/output-plugins/spo_database.c
/home/agrams/packages/snort-2.4.3_mod/src/output-plugins/spo_database.c
--- /home/xxx/packages/snort-2.4.3/src/output-plugins/spo_database.c
Fri Sep 23 16:58:10 2005
+++ /home/xxx/packages/snort-2.4.3_mod/src/output-plugins/spo_database.c
Fri Dec 23 23:09:14 2005
@@ -1005,6 +1005,27 @@ void Database(Packet *p, char *msg, void
}
}
#endif
+/* Added by Axton Grams on 12/23/2005 to fix the millisecond problem
+ * with mySQL event date/time.
+*/
+#ifdef ENABLE_MYSQL
+ if (data->shared->dbtype_id == DB_MYSQL)
+ {
+ /* Oracle (everything before 9i) does not support
+ * date information smaller than 1 second.
+ * To go along with the TO_DATE() Oracle function
+ * below, this was written to strip out all the
+ * excess information. (everything beyond a second)
+ * Use the Oracle format of:
+ * "1998-01-25 23:59:59"
+ */
+ if ( timestamp_string!=NULL && strlen(timestamp_string)>20 )
+ {
+ timestamp_string[19] = '\0';
+ }
+ }
+#endif
+
#ifdef ENABLE_ODBC
if (data->shared->dbtype_id == DB_ODBC)
{
|
|
Posted by brevizniak on January 06, 2006 15:50:54
Odd that it has never come up before. That should be sufficient for a bug report. |
|
Posted by gramsa49 on January 06, 2006 21:07:43
It may have something to do with my mysql configuration. I verified the acceptable levels of precision on my db by reducing the precision of what I retrieved with tcpdump by 1 decimal point at a time, until it worked. Anything with > 5 decimal places results in the column setting to the default (0000-00-00 00:00:00). Anything <= 5 decimal places precision went in fine.
Could someone with a different version of mysql verify this is true with that version as well?
I could find nothing configurable for mysql that would allow me to alter the acceptable precision level. Looked into my.cnf as well as some other config files.
Axton |
|
Posted by gramsa49 on January 08, 2006 07:48:35
I verified this on another machine using a slightly different verion of mysql. The first was a linux box, this one is a freebsd box.
In an attempt to drum up some enthusiasm to verify whether this is a mysql issue, here are a series of sql statements that can be used to reproduce/disprove the issue:
--- BEGIN SQL ---
mysql> create table test (col1 timstamp DEFAULT '0000-00-00 00:00:00');
Query OK, 0 rows affected (0.05 sec)
mysql> insert into test (col1) values ('2005-12-23 22:37:16.257698037');
Query OK, 1 row affected, 1 warning (0.00 sec)
mysql> commit;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from test;
+---------------------+
| col1 |
+---------------------+
| 0000-00-00 00:00:00 |
+---------------------+
1 row in set (0.00 sec)
mysql> drop table test;
Query OK, 0 rows affected (0.00 sec)
--- END SQL ---
If you get '0000-00-00 00:00:00' back, then this is probably a snort issue, if you get '2005-12-23 22:37:16' back, then something changed in mysql.
This has now been verified on the following platforms with MySQL
FreeBSD 4.10-RELEASE / mysql Ver 14.7 Distrib 4.1.15, for portbld-freebsd4.10 (i386) using readline 5.0
Linux 2.6.14-1.1653_FC4 i686 / mysql Ver 14.7 Distrib 4.1.16 for redhat-linux-gnu (i386) using readline 4.3
I need people with different versions to verify this, preferably someone with 5.x version and someone with a version earlier than 4.1.15.
Axton Grams |
|
|
|
