Suricata 1.4.6 pkg v1.0.1 Update – Release Notes
-
So enlighten me Ermal ;)
Security is paramount! Performance is second…
Tan people like you say but this is not stable and its breaking my environment,
you people cannot make something usable just patch over patch.Don't be picky. it simple to bash about things but give it a second thought before posting.
I know you would kill the lesser equipped systems like Soekris and the Atom based boxes, but running Enterprise networks, its more or less irrelevant.
@ermal:
So the PFSense core team doesnt want true inline IPS….
Thats a scary thought!!!
Thanks again for all your hard work!
So basicly this is an alternative to Snort. When do you think Suricata Inline will be ready?
And what are the advantages between the Suricata vs Snort Packages now?Inline mode is going to be a while. In fact, that mode is totally dependent upon the pfSense team making some edits within the pf and ipfw modules used on pfSense. I've had some e-mail conversations with them about that. To be honest, I don't sense a huge appetite for this feature from the team. The feedback I've gotten is the throughput will be low (topping out at maybe 50-70 megabits/sec). The analogy they suggested was to look at the performance of the current Layer 7 shaper. I've not tested the Layer 7 performance personally, so if someone else has, I would be interested in any throughput limits they may have noticed. Perhaps some input to the Core Team from other users would help sway the tide of opinion on inline mode… ;)
As for the Snort vs. Suricata thing: both appear to be quite good at what they do. Snort has the advantage for a newbie with its pre-defined IPS Policy settings. However, Suricata offers many more features for logging and subsequently viewing exactly what is traversing its sensors. The file capture feature, the HTTP logging, TLS logging, and some others can be very useful when inspecting an alert. There are also some new features in Suricata 2.0 like the eve-json logging stream to directly feed a SIEM. On balance, I believe Snort is easier to setup for a new user, but Suricata offers more features for an experienced user.
One last note on Suricata. I have the latest 2.0 release of the binary running on a pfSense VM. I created a PBI package that compiles and installs on 2.1.x of pfSense. The next step is to get all the new features of the 2.0 binary incorporated into the GUI. That's going to take a little while, but look for Suricata 2.0 on pfSense in the relatively near future.
Bill
So you cannot f**cking live without a drama and that is scary thought as well!
If you cannot understand things do not make statements you do not even know what they mean.
-
It didnt really answer my question did it??? ;)
And Bill. But aside from the better log options in certain situations, then if Suricata is not inline, then why should we migrate from Snort?
Pfsense should have the inline IPS mode as a natural thing. Everything else would be unnatural for a firewall this capable. And if its just a matter of cores and memory, to get the performance needed, then I dont see issues rolling out inline IPS.
-
It didnt really answer my question did it??? ;)
Sure it did just you do not realize.
It is expected to function properly when its done.
Presently it will not for whatever combination you would like.
If you do not belive so please provide your implementation and convince otherwise.And Bill. But aside from the better log options in certain situations, then if Suricata is not inline, then why should we migrate from Snort?
Suricata has some nice features starting from a more modern architecture.
I would love to see Bro as well in the IPS garden since it has even some benefits for certain deployments.Pfsense should have the inline IPS mode as a natural thing. Everything else would be unnatural for a firewall this capable. And if its just a matter of cores and memory, to get the performance needed, then I dont see issues rolling out inline IPS.
Sure but step by step.
Or if you badly wanted budget after budget, no? :) -
I believe there is a lot of us wanting to get IPS inline and would be willing to contribute to a bounty getting it done.
Estimated budget for developing this feature Ermal?
-
Well it has to be done through the pfsense development not the bounty, because of time commitments and not clashing calendars.
-
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