Snort 3
-
-
@talaverde @bmeeks I would be happy to join in on a bounty for accelerated package development with Snort 3. Snort has been a great tool for me, and Im all-in on pfSense, and I would be happy to support the package and the developer if I could.
-
@talaverde @bmeeks I would be happy to join in on a bounty for accelerated package development with Snort 3. Snort has been a great tool for me, and Im all-in on pfSense, and I would be happy to support the package and the developer if I could.
Sounds good. Busy week for me, but I'll try to organize something next week. If someone wants to take the lead before then, feel free. Hopefully we'll get some action on this! yay!
-
b
After some time, I have even more respect for your post.
-
With all the other coding projects I have on my plate (PowerShell, T-SQL, C#, dotNet), not to mention my corporate applications, making Snort packet interpretation a priority is WAY down the list.
-
I haven't given up on the 'Security' IPS Policy, but likely it's just a matter of time that I learn my lesson. Can you give me more detail why you went with a 'lower' level? To many false alerts? (Do the 'higher' levels cause more latency? (That's a burning question of mine)
-
For the Emerging Threat rules, I started with the four your mentioned, then tried to branch out. I've had alerts pop up, but I don't think they've had anything to do with my experimentation of ET rules. NEVERTHELESS. Any chance you want to expand on why you picked these four rules? If you were to add some more ET rules, what would you start with? (I realize that's asking a lot - very open ended question)
In short, I'm not as worried about false alarms. I can sort those out... I think (says the green little piglet). What has been MOST concerning to me recently is the added latency to my system as I've been adding more and more security measures. pfBlockerNG, Snort, FireFox and all it's fixins.. and so on. All these added up, I'm finding it taking longer and longer to connect to things like GoToMeeting. My RDP connections are dropping more frequently. I can't help but thing it has to do with all these filters, checks and balances.
Ah, balance. The key. I think that's what you might have been trying to get to. I may be willing to push that more than you, but I'd live to get more insight to your decisions.
So, again, why did you pick those ET rules? What made you drop your IPS Policy? To much noise? Latency?
BTW, you mentioned Selective Data Rules. At risk of admitting my ignorance, I don't know which ones those are? I ask because I've been getting credit card alerts. I'm almost positive they are false, but still makes me nervous. Why did you bring them up again?
I think I've hit my limit on questions. Hopefully you find yourself in a talkative mood in the near future.
Thanks again for your previous feedback.
-
-
Several long-winded answers follow:
@talaverde said in Snort 3:
I haven't given up on the 'Security' IPS Policy, but likely it's just a matter of time that I learn my lesson. Can you give me more detail why you went with a 'lower' level? To many false alerts?
The Snort team will tell you that their IPS Policies work like this:
-
IPS-Connectivity = good protection with minimal to zero false positives in most networks.
-
IPS-Balanced = better protection, but a higher risk of some false positives in most networks due to several more "hair-trigger" rules being enabled as compared to the IPS-Connectivity policy.
-
IPS-Security = best protection, but a very high risk (actually almost a certainty) of false positives in most networks due to the inclusion of many more rules that trigger on anomalies. (that "almost a certainty" quote is mine and not from the Snort team).
I downgraded from IPS-Security to IPS-Balanced because of false positives in my network. And I still have a few of the rules within that policy suppressed if I recall correctly. Again, that would be due to false positives in my environment.
@talaverde said in Snort 3:
Do the 'higher' levels cause more latency? (That's a burning question of mine). What has been MOST concerning to me recently is the added latency to my system as I've been adding more and more security measures. pfBlockerNG, Snort, FireFox and all it's fixins.. and so on. All these added up, I'm finding it taking longer and longer to connect to things like GoToMeeting. My RDP connections are dropping more frequently. I can't help but thing it has to do with all these filters, checks and balances.
The latency issue is a function of the number of rules being processed. The more rules a packet has to traverse, the longer it will take. So it's the number of enabled rules that has the biggest impact. And by the way, on pfSense, the latency you may notice with Snort would be due to CPU load and not because the packets have to get through Snort before going any place. Snort on pfSense works in a PCAP mode where Snort gets copies of every packet traversing the physical interface to analyze. The original packet went straight to the
pf
firewall and then on to the host stack. Snort analyzes its copy of the packet (or copies in the case of multiple packets in a stream) and then decides whether to block or not. It informs thepf
firewall when it wants to block the remaining packets from a stream. So if the CPU is busy doing Snort rule comparisons, it takes more time to answer interrupts from the NIC card to grab packets and send them on to the host stack. That will increase latency a little bit. Same with encrypting and decrypting every single packet across an interface for VPNs. That will increase latency.Layer in a lot of this CPU busy-work and you can definitely bog your firewall down. With Snort enabled with thousands of rules, and then pfBlocker-NG enabled with thousands of IP-address rules for the CPU to check every single packet against, it is self-evident something has to give somewhere. That's what makes IDS/IPS a balancing act. And getting it working well requires knowing your network hosts' exposure and the threats they are most vulnerable to, and mitigating just those. No sense having your CPU sort through a ton of DNS and mail server rules if you are not running exposed DNS or mail servers on your network. Those are just two examples, but there are many more.
@talaverde said in Snort 3:
- For the Emerging Threat rules, I started with the four your mentioned, then tried to branch out. I've had alerts pop up, but I don't think they've had anything to do with my experimentation of ET rules. NEVERTHELESS. Any chance you want to expand on why you picked these four rules? If you were to add some more ET rules, what would you start with? (I realize that's asking a lot - very open ended question)
Rules are designed for specific network environments. Maybe "targeted" is a better word than designed. Let's take an example - the ET-DNS rules. Those rules are designed primarily to detect attacks against a DNS server. They are not really focused on protecting DNS clients. So if I don't have DNS servers in my network, especially none exposed to the Internet, then those ET-DNS rules are useless in my setup. So why waste CPU resources examining traffic against those rules? Several other rule categories I eliminate using the same logic. I don't have any exposed attack surfaces that need those rules looking for threats. I chose the malware and bot-cc rules because that is probably the biggest risk area for any network, home or corporate. I use those ET-Open rule categories as an "extra set of eyes" looking at my network along with the Snort Subscriber Rules. There are Snort Subscriber Rules covering malware and bot-cc IP combos, but since I have the ET-Open rules and have the CPU resources to spare, I run those along with the Snort Subscriber Rules just in case one catches something the other misses. But I only chose to do that in what I think of as the higher risk categories for my network. Just a personal opinion and decision, though. There are no hard and fast rules for choosing rules and policies in the IDS/IPS world.
As for which other ET-Open categories I might choose, I would base the decision on the exposures in my network. If I ran a mail server, I would choose the emerging-smtp, emerging-pop3 and emerging-imap rules. If I had teenagers in the house or even pre-adolescents, I might enable the emerging-inappropriate rules to start catching that kind of stuff. It's simply a matter of trying to balance CPU and RAM usage against the threats your network is vulnerable to (or stuff you want to limit access to from within your network). And, in the end, it's simply a judgement call. I may judge right, or something may "get me" and I find out I judged wrong. If that happens, I learn from the mistake, take corrective action, and move on. The Equifax IT security guys recently graduated from that same school of "bad experience" ... .
@talaverde said in Snort 3:
What made you drop your IPS Policy? To much noise? Latency?
Mostly too many false positive alerts. For example, I would get alerts on "EXE download attempt" when Windows was simply trying to perform some security updates. Then there were always JavaScript alerts from the browser rules, but 99% of those are false positives triggering on obfuscated JavaScript. Once, long ago, that was "the thing" for hiding malicious code, but these days it is more likely to simply be the advertising networks trying to thwart ad blockers. Granted there still is malicious stuff out there, but every single piece of obfuscated JavaScript is not a malware payload; and you grow weary of getting blocks on half of the web sites you visit.
So I dialed down the Snort IPS Policy a bit and just make sure my machines stay updated with the latest security patches. I have all my computers on a UPS and they stay powered on and connected 24x7. Faithfully installing automatic updates from Microsoft and Linux land is the best security practice there is. That's better than 50,000 Snort rules ... . Even with all that, a zero-day can still get you. So backups are critical!
@talaverde said in Snort 3:
BTW, you mentioned Selective Data Rules. At risk of admitting my ignorance, I don't know which ones those are? I ask because I've been getting credit card alerts. I'm almost positive they are false, but still makes me nervous. Why did you bring them up again?
It's "Sensitive Data" instead of "Selective Data". They are part of the three built-in Snort rules bundles: (1) decoder rules, (2) preprocessor rules and (3) sensitive data rules. The Sensitive Data rules are not enabled by default. You have to turn on the Sensitive Data preprocessor on the PREPROCESSORS tab to enable these rules.
The Sensitive Data rules were designed to detect, through regular expression pattern matching, attempts to send credit card numbers, phone numbers, email addresses and social security numbers over a network connection. They simply look for patterns. For instance, a pattern of 3 digits, a dash, 3 more digits, another dash, and then 4 digits in a packet's payload is how phone numbers generally are written (area code-local exchange prefix-individual phone number). Way back when web traffic was plaintext HTTP, these rules could help a corporate network admin detect the outbound transmission of this potentially sensitive data. Now days, with web traffic being majority HTTPS with SSL encryption, the rules don't help much because they can no longer see the plaintext payload. Plus these rules can "false positive" easily because they are simply looking for ASCII code patterns. So if some random piece of encrypted payload happened to decode like this as ASCII data: "123-456-7890", the Sensitive Date rule for phone numbers might trigger. But this string sequence might really just be the random result of encrypting some entirely different set of data bytes. I don't think very many folks enable the Sensitive Data rules these days.
-
-
Since I maintain the Snort 2.9.x package on pfSense, I guess it's logical that I will be the one to create the Snort3 package...
What are we likely to get as a replacement for barnyard2?
I manage a growing number of various models of Netgate devices, all with Snort installed. To attempt to monitor them all from one screen i'm trying to use an external SIEM setup. This has proved problematical to say the least.
-
What are we likely to get as a replacement for barnyard2?
I manage a growing number of various models of Netgate devices, all with Snort installed. To attempt to monitor them all from one screen i'm trying to use an external SIEM setup. This has proved problematical to say the least.
Probably something like this blog post talks about. Except instead of Logstash something like Filebeats might work better on a FreeBSD platform like pfSense. I have not investigated any of that in much detail, though. Here is a tutorial on converting from Logstash Forwarder to Filebeats (or Beats in FreeBSD): https://www.elastic.co/guide/en/beats/filebeat/current/migrating-from-logstash-forwarder.html.
-
Do you think it will be posible to create IDS policies and apply them to firewall rules like in the commercial firewalls?
Basically you can create a policy with a personalized configuration and rules and apply this policy to a fw rule, so the traffic of that firewall rule is the only affected by that IDS policy.
THis can be to a firewall rule or to a port, or host. -
@l0rdraiden said in Snort 3:
Do you think it will be posible to create IDS policies and apply them to firewall rules like in the commercial firewalls?
Basically you can create a policy with a personalized configuration and rules and apply this policy to a fw rule, so the traffic of that firewall rule is the only affected by that IDS policy.
THis can be to a firewall rule or to a port, or host.No, that is not something that I predict is on the horizon. The packet filter firewall used by pfSense is totally unaware of the presence of any installed IDS/IPS package and any policies defined in the IDS/IPS. Today the IDS/IPS component sits completely outside of the firewall. Changing that would require substantially reworking the internal network plumbing of the FreeBSD kernel used beneath pfSense.
-
I was just curious if there was any update to this. I am very interested in using Snort 3 with Pfsense. Thanks!
-
I was just curious if there was any update to this. I am very interested in using Snort 3 with Pfsense. Thanks!
Snort3 will likely be a long time in coming -- if ever. I started working on a package for it, but the effort got to be very frustrating because so much is different from Snort 2.9.x. Migrating an existing pfSense Snort 2.9.x configuration over to Snort3 proved to be a tough challenge. That's one of the reasons I put the package development back into mothballs. I never did get a working system going with Snort3 on pfSense. The binary part is not really the issue. The difficulties are in the PHP GUI code and all the gymnastics required to create the LUA configuration file for the binary to use.
Anybody is free to take up the challenge and work on a Snort3 package if they desire, but my enthusiasm for it has evaporated for now.
-
@bmeeks Thank you for the update.
-
@Paych3ck I am not a developer nor have any vested interest in snort. But like you was curious and I came across this thread. Kinda bummed out that at this time no further development was going to be done and to be fair it is a large task at hand. But I wanted to offer others some context who are like us curious as about snort 3.
Checking the official snort blog:
https://blog.snort.org/
-https://blog.snort.org/2018/08/snort-3-beta-available-now.html -8/2018 beta releasedOther points from the snort download page:
-Up to now its been receiving updates (still beta stage)
-2.9.16 is still listed as stable but not 3.0So I dunno maybe another reason is that the dust hasn't settled.
-
According to twitter snort3 is on it's final beta with release later this year.
-
As the OP of this thread, I sorta felt bad because I lost interest. This is because I ended up installing Suricata, even if only just to try it out. Surprisingly, I was able to significantly drop the RAM used by my pfSense (VMs) and even noticed a slight improvement in speeds. I may have just had things mis-configured with Snort, but I'm happy at the moment. While I'll almost definitely try out Snort 3 when it's available, I'm not anxiously waiting, like I was before.
I have noticed many more alerts with Suricata, than with Snort. I don't know that that means more protection or more false alarms. It may be a little of both.
-
any updates on snort 3.0? Single Threading is killing my use of it but their rule sets are far and away cheaper than suricata. Single threading kill throughput to the point it's pointless to even use the package on higher end network speeds.
-
@beachbum2021 said in Snort 3:
any updates on snort 3.0? Single Threading is killing my use of it but their rule sets are far and away cheaper than suricata. Single threading kill throughput to the point it's pointless to even use the package on higher end network speeds.
No more progress, and I have no plans at present to resume work on a Snort3 package. If someone else wishes to tackle that project, they are welcome to do so.
-
@bmeeks thanks for the update