Suricata 1.4.6 pkg v1.0.1 Update – Release Notes
-
On a side note, I've found a bug.
On the Alerts tab, clicking on the Refresh Check Box and hitting Save, does not change the setting but reverts back to the original setting. On stays On. Off Stays Off.
Two of my boxes have this setting On which I cannot change, and another box has this setting Off which I can not turn On.
-
On a side note, I've found a bug.
On the Alerts tab, clicking on the Refresh Check Box and hitting Save, does not change the setting but reverts back to the original setting. On stays On. Off Stays Off.
Two of my boxes have this setting On which I cannot change, and another box has this setting Off which I can not turn On.
Thanks for the report. I will fix it.
In the interim, here is how you can patch the PHP file to fix it. It is a copy-paste error from the Snort GUI code that much of Suricata is derived from.
1. Edit the file /usr/local/www/suricata/suricata_alerts.php and find the single occurrence of the phrase "snortglobal". It is on line 413 in the file.
2. Change "snortglobal" to "suricata" and save the change. That should fix it. Your changes are actually being saved to the correct location, but it's just not displaying the changed value because of that typo.
If this does not fix it for you, please let me know.
Bill
-
I think I've found some bugs with Suricata;
1 -
On the Barnyard2 page, no matter how many times I delete the "Sensor Name", when I come back to the page, it defaults to the hostname.domain of the firewall.
I have barnyard2 logging to a mysql database, and if I don't blank the sensor name and retype the mysql password every time I make a change to the barnyard2 config, barnyard2 will fail authentication for mysql.
2 - I have Suricata logging to the local syslog, which then is sent to a logstash/kibana (and other NSM tools) box. When I first start Suricata, it logs fine, like below:
May 19 23:59:11 suricata[77956]: [1:2230002:1] SURICATA TLS invalid record type [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP}Right after Suricata does a live reload, it starts logging like this:
May 20 00:31:12 ^D[77956]: [1:2230002:1] SURICATA TLS invalid record type [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP}It has the control characters where it should be the program name in syslog. This is directly in the local syslog. And its not always the same control characters in the log:
May 20 01:49:07 \xE0\xEB^?M-^@^RM-^G[77956]: [1:2230002:1] SURICATA TLS invalid record type [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP}Any ideas or anything I can help with to correct?
-
I think I've found some bugs with Suricata;
1 -
On the Barnyard2 page, no matter how many times I delete the "Sensor Name", when I come back to the page, it defaults to the hostname.domain of the firewall.
I have barnyard2 logging to a mysql database, and if I don't blank the sensor name and retype the mysql password every time I make a change to the barnyard2 config, barnyard2 will fail authentication for mysql.
2 - I have Suricata logging to the local syslog, which then is sent to a logstash/kibana (and other NSM tools) box. When I first start Suricata, it logs fine, like below:
May 19 23:59:11 suricata[77956]: [1:2230002:1] SURICATA TLS invalid record type [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP}Right after Suricata does a live reload, it starts logging like this:
May 20 00:31:12 ^D[77956]: [1:2230002:1] SURICATA TLS invalid record type [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP}It has the control characters where it should be the program name in syslog. This is directly in the local syslog. And its not always the same control characters in the log:
May 20 01:49:07 \xE0\xEB^?M-^@^RM-^G[77956]: [1:2230002:1] SURICATA TLS invalid record type [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP}Any ideas or anything I can help with to correct?
Thank you for bug reports. #1 happens because the code defaults to "hostname" if the field is blank. I believe I can work around that, though, so if the user has saved it blank it will stay that way.
Bug #2 I'm not as sure about. That may be something internal to the Suricata binary itself. If so, that's not an easy fix. I will check it out.
Bill
-
I think I've found some bugs with Suricata;
1 -
On the Barnyard2 page, no matter how many times I delete the "Sensor Name", when I come back to the page, it defaults to the hostname.domain of the firewall.
I have barnyard2 logging to a mysql database, and if I don't blank the sensor name and retype the mysql password every time I make a change to the barnyard2 config, barnyard2 will fail authentication for mysql.
2 - I have Suricata logging to the local syslog, which then is sent to a logstash/kibana (and other NSM tools) box. When I first start Suricata, it logs fine, like below:
May 19 23:59:11 suricata[77956]: [1:2230002:1] SURICATA TLS invalid record type [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP}Right after Suricata does a live reload, it starts logging like this:
May 20 00:31:12 ^D[77956]: [1:2230002:1] SURICATA TLS invalid record type [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP}It has the control characters where it should be the program name in syslog. This is directly in the local syslog. And its not always the same control characters in the log:
May 20 01:49:07 \xE0\xEB^?M-^@^RM-^G[77956]: [1:2230002:1] SURICATA TLS invalid record type [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP}Any ideas or anything I can help with to correct?
Thank you for bug reports. #1 happens because the code defaults to "hostname" if the field is blank. I believe I can work around that, though, so if the user has saved it blank it will stay that way.
Bug #2 I'm not as sure about. That may be something internal to the Suricata binary itself. If so, that's not an easy fix. I will check it out.
Bill
Bill,
Thanks! You are always so quick to the punch - much appreciated! If there is anyway I can help, please don't hesitate to ask.
-
Bill,
Thanks! You are always so quick to the punch - much appreciated! If there is anyway I can help, please don't hesitate to ask.
The fix for Bug #1 (not keeping the sensor name blank) has been submitted as part of an open Pull Request for the next Suricata update. Hopefully it will get reviewed and merged this week.
Bug #2 is going to be harder to track down. It's most likely not a GUI package problem, but instead something in the binary itself. That is supposed to be printing the process name and then the process ID (PID) in the brackets. So the name is "suricata" and the PID in your example is [77956]. When Suricata does the live reload, it looks like it loses a pointer someplace to the process name (that's my current guess). That would explain why the characters seem random - it is referencing a defunct pointer.
Bill
-
Bill,
Thanks! You are always so quick to the punch - much appreciated! If there is anyway I can help, please don't hesitate to ask.
The fix for Bug #1 (not keeping the sensor name blank) has been submitted as part of an open Pull Request for the next Suricata update. Hopefully it will get reviewed and merged this week.
Bug #2 is going to be harder to track down. It's most likely not a GUI package problem, but instead something in the binary itself. That is supposed to be printing the process name and then the process ID (PID) in the brackets. So the name is "suricata" and the PID in your example is [77956]. When Suricata does the live reload, it looks like it loses a pointer someplace to the process name (that's my current guess). That would explain why the characters seem random - it is referencing a defunct pointer.
Bill
That makes total sense, and it's not the biggest of deals when shipping the log over, I think I can write a logstash pattern to deal with this.
-
Bill,
Thanks! You are always so quick to the punch - much appreciated! If there is anyway I can help, please don't hesitate to ask.
The fix for Bug #1 (not keeping the sensor name blank) has been submitted as part of an open Pull Request for the next Suricata update. Hopefully it will get reviewed and merged this week.
Bug #2 is going to be harder to track down. It's most likely not a GUI package problem, but instead something in the binary itself. That is supposed to be printing the process name and then the process ID (PID) in the brackets. So the name is "suricata" and the PID in your example is [77956]. When Suricata does the live reload, it looks like it loses a pointer someplace to the process name (that's my current guess). That would explain why the characters seem random - it is referencing a defunct pointer.
Bill
That makes total sense, and it's not the biggest of deals when shipping the log over, I think I can write a logstash pattern to deal with this.
I will look and see if I can verify my suspicion. I am working on updating the package to use the new 2.0 version of the Suricata binary. I will look and see if any bugs related to this got fixed in the 2.0 code tree as well.
Bill
-
Bill,
Thanks! You are always so quick to the punch - much appreciated! If there is anyway I can help, please don't hesitate to ask.
The fix for Bug #1 (not keeping the sensor name blank) has been submitted as part of an open Pull Request for the next Suricata update. Hopefully it will get reviewed and merged this week.
Bug #2 is going to be harder to track down. It's most likely not a GUI package problem, but instead something in the binary itself. That is supposed to be printing the process name and then the process ID (PID) in the brackets. So the name is "suricata" and the PID in your example is [77956]. When Suricata does the live reload, it looks like it loses a pointer someplace to the process name (that's my current guess). That would explain why the characters seem random - it is referencing a defunct pointer.
Bill
That makes total sense, and it's not the biggest of deals when shipping the log over, I think I can write a logstash pattern to deal with this.
I will look and see if I can verify my suspicion. I am working on updating the package to use the new 2.0 version of the Suricata binary. I will look and see if any bugs related to this got fixed in the 2.0 code tree as well.
Bill
Nice on the 2.0.. Do you know if it's compiled with JSON (libjansson) support?
-
Nice on the 2.0.. Do you know if it's compiled with JSON (libjansson) support?
My first private test of 2.0 was not, but I think I can include it in the production release.
Bill