Suricata 1.4.6 pkg v1.0.1 Update – Release Notes
-
Thanks Ermal,
It's great news to see that inline and BRO is on the pfSense Radar…
What would be missing is a logging software to tie all of these packages together (firewall logs, snort/suricata, Bro, Argus etc...)
Another great addition would a HIDS program called OSSEC, which I believe it almost completed by one of the users but he has unfortunately stalled in completing the x64 development portion.
I am using a IDS installation called Security Onion, which is installed behind my pfSense LAN interfaces which has all of these features and it works great. But having these features implemented also in pfSense would be a fantastic improvement in security.
Thanks for all your efforts thus far, we offer any help we can extend...
-
Thanks Ermal and Bmeeks for the explanations.
I agree that getting pfSense into the FreeBSD 10 codebase is much more important. -
We all want essentially the same things for IDS/IPS on pfSense. Once pfSense is in production on the FreeBSD 10 code base, some other options become available that may be the best way forward for IPS. These options are not in the current 8.x code base.
I also like the idea of having a small suite of IDS/IPS applications to choose from for pfSense. This would allow admins to select the one best suited for their particular network environment and needs. I can take a look at Bro in the future and see what it would take to create a package around it. That would bring three IDS/IPS tools to the pfSense world.
However, I would next like to find a tool that can quickly and rather easily grab all the logs and files (pcaps and extracted files) these tools can generate and push them to an external logging system (or a SIEM). I've looked at logstash, but it is Java based. Java apps on a firewall is a security travesty in my opinion :'(. If you have any suggestions, please send them my way. The preference is something that is already ported to FreeBSD.
Bill
-
There is one other point to throw into this IPS discussion– the DAQ module that is at the heart of the network "hook" in Snort can also work in an inline IPS mode with some configurations. For FreeBSD, it would need more or less the same setup as Suricata. So the upshot here is that it is quite possible that both Suricata and Snort could someday offer inline modes as an option.
As to Supermule's question of why anyone might prefer Suricata over Snort, it really comes down to personal preference for now (since both offer the same kind of blocking on pfSense). Suricata offers a few additional capture options for logging data around alerts, but in my view there is no tangible difference in offered protection between the two. The main goal in creating the Suricata package was just to offer a viable alternative to Snort. This gives admins choice.
Bill
-
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
