Suricata Inline and Rules
-
Well, I was fine tuning Suricata rules per my fave: https://github.com/jflsakfja/suricata-rules/blob/master/list.txt
However, I notice several IPv6 in the alert log been dropped...so out of curiosity, since I disabled IPv6 from both interfaces, I decided to look it up and discovered this document: https://www.l-com.com/multimedia/whitepapers/wp_Layer3RoutingNetworkEdge.pdf
So, after reading, I realized I need to disable the rules that causing the flood of alerts...see image below.
So now I would like to remove it from the alert logs altogether since it just my internal system talking (edge pfSense, Mikrotik, Netgear managed switch) to route to the devices. Now, I wish there was a search available to go to the exact rules...so far I found 2100411 under Emerging-icmp_info.rules - GPL ICMP_INFO Router Advertisement.
Is there a way to find all PIM protocol and disable or do I need to go through all rule set to pick them out? They're not in numerical order.
-
First of all, there is no reason whatsoever for those rules to be set to DROP. All of the decoder rules (and most of the events rules) are really designed for alerts, not drops. Leave them at their default setting of ALERT and don't change them to DROP.
On the ALERTS tab, you can sort by clicking some of the column headers. The SRC and DST port columns are sortable along with the GID:SID column. So to arrange all the identical GID:SID alerts, simply click that column header to sort the alerts by GID:SID. Then disable any rules you don't wish to see alerts for by clicking the red X to disable the rule. When you disable a GID:SID, all further instances of that alert will show up with a new icon. Just scroll down the list and disable the rules you want to.
Also a word of caution -- that old thread you are following is quite dated now and was created based on a much older version of Suricata that lacked many of the features of the current package. So take what you read in that old thread with some grains of salt.
-
@bmeeks said in Suricata Inline and Rules:
First of all, there is no reason whatsoever for those rules to be set to DROP.
Thank you Bill for responding...had hoped you would. Yes, I know after the fact that they were harmless...so, out of caution, I had dropped them.
@bmeeks said in Suricata Inline and Rules:
Also a word of caution -- that old thread you are following is quite dated now and was created based on a much older version of Suricata that lacked many of the features of the current package. So take what you read in that old thread with some grains of salt.
Intuitively, I thought that and checked each list see whether the rules are the same and still apply. It's real tedious to go through and I had done all except Emerging-policy.rules as it's so long list. I want to clean up my mess before getting to policy rules. I also have to find what's blocking iTunes Internet Radio.
I'll follow your direction and report back
-
@bmeeks said in Suricata Inline and Rules:
On the ALERTS tab, you can sort by clicking some of the column headers. The SRC and DST port columns are sortable along with the GID:SID column. So to arrange all the identical GID:SID alerts, simply click that column header to sort the alerts by GID:SID. Then disable any rules you don't wish to see alerts for by clicking the red X to disable the rule. When you disable a GID:SID, all further instances of that alert will show up with a new icon. Just scroll down the list and disable the rules you want to.
Bill, I was surely surprised how easy it was...just clicked on the GID:SID and there was all the PIM protocol alerts...thank you!
Now to find the rule stopping iTunes Internet radio...any ideas? All streaming had been disabled so it's not that.
-
Okay, I fixed the iTunes Internet radio streaming issue which had also affected iTunes video streams as well. The fix was to unselected all categories and selecting each one at a time to see whether it would break iTunes services. After selecting all, except the ones posted here: https://github.com/jflsakfja/suricata-rules/blob/master/list.txt the stream services were never broken...so, I am confused on what had broken it in the first place.
-
@NollipfSense said in Suricata Inline and Rules:
Okay, I fixed the iTunes Internet radio streaming issue which had also affected iTunes video streams as well. The fix was to unselected all categories and selecting each one at a time to see whether it would break iTunes services. After selecting all, except the ones posted here: https://github.com/jflsakfja/suricata-rules/blob/master/list.txt the stream services were never broken...so, I am confused on what had broken it in the first place.
The user that created that guide you are referencing was an IT admin for a fairly large business in Greece (if I am recalling the country correctly). And a business IT department usually has very stringent rules for employee usage of the company network. Those rules frequently want to exclude social media, streaming services, questionable or potentially offensive content, etc. So setting up Suricata or Snort to protect and enforce the usage policies of a business network is quite a bit different than for a home network. In particular, you will break a lot of stuff home network users want to use if you follow a standard business network setup.
A corporate network does not want employees to have access to iTunes, Hulu, Netflix, etc. They want that stopped, so they configure security that way. A home network most definitely generally wants those services available, so you can't just go copying someone's list of rules and suppress listings unless you fully understand what those rules are actually doing.
-
@bmeeks said in Suricata Inline and Rules:
A corporate network does not want employees to have access to iTunes, Hulu, Netflix, etc. They want that stopped, so they configure security that way. A home network most definitely generally wants those services available, so you can't just go copying someone's list of rules and suppress listings unless you fully understand what those rules are actually doing.
I understand Bill; however, all rules under stream-events.rule had been disabled as well as the only iTunes rule under Emerging-policy.rule had been disabled. I believe the author was from England.
What about these two rules: 1:2009582 ET SCAN NMAP -ss window 1024 and 1:2027863 ET INFO Observed DNS Query to .biz TLD...I am getting lots alert so they were dropped.
-
@NollipfSense said in Suricata Inline and Rules:
@bmeeks said in Suricata Inline and Rules:
A corporate network does not want employees to have access to iTunes, Hulu, Netflix, etc. They want that stopped, so they configure security that way. A home network most definitely generally wants those services available, so you can't just go copying someone's list of rules and suppress listings unless you fully understand what those rules are actually doing.
I understand Bill; however, all rules under stream-events.rule had been disabled as well as the only iTunes rule under Emerging-policy.rule had been disabled. I believe the author was from England.
What about these two rules: 1:2009582 ET SCAN NMAP -ss window 1024 and 1:2027863 ET INFO Observed DNS Query to .biz TLD...I am getting lots alert so they were dropped.
My opinion, and the advice I give home network users, is to enable the Snort rules download and then enable the IPS Policy - Connectivity setting. That's really all you need. Enable no other rules. That provides plenty of protection from most of the threats out there, especially if you keep your Windows machines updated with the latest security patches (in other words, leave Windows Update enabled and have your machines on a UPS so they just are on all the time and update late at night). If an admin has a good bit of IDS/IPS experience and also quite a bit of networking theory knowledge, then he can experiment with maybe the IPS Policy - Balanced setting and perhaps enable some additional Emerging Threats rules. But be prepared to have Google on speed-dial so you can quickly research potential false positives.
All those events rules provided with a default Suricata installation are designed to simply detect deviations from RFC behaviors. They are triggering on protocol anomalies, and nearly 100% of the time those anomalies are completely harmless. So never set those rules to DROP, and if the alerts bother you, then disable those rules entirely. But don't obsess with them triggering, as they tend to false positive like crazy.
Those ET DNS query rules are also only marginally useful at best. As you see, they will trigger quite often on even normal web traffic. Some of them will even false positive fairly often. For home users these kinds of rules are more of a bother than an addition to security. I don't run them on my system. If you keep your PC software updated, that's 95% or more of the network security battle won right there!
Some IDS/IPS users want to start out with a whole bunch of enabled rules because they think it will make their setup "secure", but they quickly get frustrated because so many things (apps) get broken - and sometimes in very strange ways. Take my advice, keep it simple for many months as you get your feet wet administering an IDS/IPS.
I have what I believe is a very secure setup for my home network using Snort. I may one day get zapped with a zero-day -- who knows, but I am pretty confident that my setup is secure. And my iTunes works, my Netflix works, my Facebook and YouTube videos work, and all the web sites I visit open up and display properly. I honestly do not know the last time Snort crashed or gave me any issue on my firewall, and I've been running it for many years. I get maybe one alert per month on average on my LAN from Snort. I do get several an hour on my WAN, but that's simply because I run a handful of ET rules there solely to generate alerts on purpose so I have data to use when I'm working on Snort package development tasks.
