OPNsense Forum
English Forums => Intrusion Detection and Prevention => Topic started by: yeraycito on January 29, 2021, 03:20:17 am
-
Opnsense 21.1
-
Clean install Opnsense. Rules: ET Telemetry
-
Nothing works. In the Rulesets section which states that if nothing is selected it applies to everything does not work. And if you select everything it doesn't work either. There is no way to select the rules in blocking. It worked so well before blocking the categories of rules in the Download section, why do you change it?
-
Do you have the Checkbox for IPS enabled?
-
Yes. If I activate the lock setting in the Policy tab according to the following screenshot it does not work.
-
I just tried another test with a different configuration and it still doesn't work.
-
More screens
-
One last test with another configuration. It still does not work. The rule shown in the image as DROP is manually activated.
-
More screens
-
Last image
-
can you set description to your policy and then go to "Rules" and filter rules with matched_policy\"your_policy"?
-
Same here,
since the upgrade I see that the rules allow traffic instead of dropping it. I am using the same config as in 20.7 by implementing the "imported legacy import filter" Still no drops.
Maybe there is some configuration to be changed in the policy but the official documentation is not very helpful to be honest.
Is there a how to guide how to enable suricata so it drops packets by implementing the policies?
Filtering as per Policy shows nothing
-
I went back to the original config before the upgrade.
Now with the legacy rule untouched I see the rules are configured to block traffic
-
it seems that it may not be related to policies. also stopped blocking traffic on the test VM. deleted policies - not helped. turned off and on the checkboxes on the Settings tab (enabled, IPS, promisc) applying after each checkbox. IPS starts working after that.
may be some .yaml issue after update?
already completely blocked access to any remote management by including everything in the new policy and specifying the drop action 8)
play carefully with policies ;D
-
Yes, agreed. It’s totally unclear on how it is supposed to work. It worked so well before the update too.
-
@logandzwon
do not agree. quite intuitive and logical. I got what I wanted (the fact that I blocked everything was not important to me. quick results :D).
and the documentation has been updated
the only pity is that not all rulesets are filled with metadata and such rules will still have to be controlled rule-by-rule
-
+1 to this issue.
Updated to 21.1 without issue...however noticed the Xbox X had issues with DLing from Gamepass on attempt last night. Thought it was a MS issue, but today the same.
Turned Suricata off and all is back to normal....turn it back on and DL hangs.....turn it back off and DL resumes.
Worked flawlessly prior to 21.1 upgrade so I would say that something broke in the back end. FWIW
-
@fright
do not agree. quite intuitive and logical. I got what I wanted (the fact that I blocked everything was not important to me. quick results :D).
To be honest I do not get the new interface. The description here https://docs.opnsense.org/manual/ips.html?highlight=intrusion (https://docs.opnsense.org/manual/ips.html?highlight=intrusion) is not that helpful in my opinion.
Could you please shed some light here?
In case you do not choose anything in the Rules and keep it as "Nothing selected" ist this to be interpreted as "Select all"?
When you look at action, you can choose to select "Disabled, Alert Drop", does that mean that if you choose only "Alert" this Policy applies top all rules which are set per default to "Alert" and does not apply to those which are set to diesabled or block per default?
In the "New Action" Selection one can choose to enable, disable,.... those rules at a bunch without the need to manually touch them?
Thank you in advance.
-
@amichel
sorry, i start to play with policies again and the results became unpredictable when I started adding more policies.
I'll take the time to figure it out about the behavior of the policies or my brains.. I will not say anything yet, so as not to say nonsense )
-
@amichel
sorry, i start to play with policies again and the results became unpredictable when I started adding more policies.
I'll take the time to figure it out about the behavior of the policies or my brains.. I will not say anything yet, so as not to say nonsense )
So it looks like we are in the same situation.
Thank you Fright
Gesendet von meinem IN2023 mit Tapatalk
-
Hi
so yes, its my brains :-[
I created a not entirely correct rule for checking the triggering of IDS / IPS: I made a rule for icmp ping, which did not trigger alert for every packet by itself. Corrected the rule and the picture became more logical.
It is a little difficult to remember when exactly the __manual__ policy is assigned to a rule: any rule to which a change is made outside of the policies (the rule disabled by default is enabled or the action is changed) goes into the __manual__ policy and stay there no matter what. Rules with default (as in source ruleset file) state have no policy by default.
Therefore, if you start creating a policy on a ready-made configuration, you will most likely get a result in which some of the rules with the parameters specified in the policy will be included in the policy, and some will not. It seemed to me the easiest to understand first to achieve that there were no rules in the __manual__ policy (you can filter the rules by policy on the Rules tab and try to revert this rules to default state), and then create policies and watch the result.
playing with switching rules and policies for 2 hours - while everything works as expected.
in general, how did it work out for me:
In case you do not choose anything in the Rules and keep it as "Nothing selected" ist this to be interpreted as "Select all"?
yes. taking into account the priority value. so if there a policy with suitable parameters and a lower priority value then this policy will be applied to the rule
does that mean that if you choose only "Alert" this Policy applies to all rules which are set per default to "Alert" and does not apply to those which are set to diesabled or block per default?
exactly (again: if rule is in default state. any rule with manualy changed state or action will be in __manual__ policy)
those rules at a bunch without the need to manually touch them?
yes. and this is the idea of applying policies, if I understand correctly
disclaimer: I just tested this for myself. it would be great if the team joined and checked everything I said here )
-
Hello
My brain hurts. Thought I understood the basics of the new policies...
When I was using ET Open I had a policy just like this and all rules swapped from alert to block.
Just opted in for ET Telemetry rulesets. I've disabled all rules, re-defined policy, re-download rules, re-apply suricata on settings-home several times. The IPS is working just fine. But since switching over to ET Telemetry the policy doesn't appear to toggle rules from default alert to drop.
Please review screenshot - am I being retarded? This there anyway to see what policy a rule belongs too?
-
AHA - Yup - Full retard.
One must define policy - following - ENSURE THE TOP SELECTOR FOR ALL/PREFERRED RULES IS CHECKED (NOT JUST ENABLED) then press download and update.
Now that rules are download with associated filter policy I can toggle policy back and forth alert/drop without re-downloading rules - however must reapply via settings-home.
Edit: Reviewed and tested a bit - For noobs like me that are looking for simple - Don't use the matching criterias "Affected_product" Any" like my screenshot (unless you know what your doing) - it will filter / exclude rules despite the "any"
The Easiest I've found for basic policy layout is:
Download - Enable list you want
Policy - Policy 0 - Select lists you like to drop with. Action: Alert , New Action - drop
Policy - Policy 1 - No selected lists (all) - Action alert , New action - Default
Back to download rules - select all of them - download and apply
Settings - Apply
-
The Easiest I've found for basic policy layout is:
Download - Enable list you want
Policy - Policy 0 - Select lists you like to drop with. Action: Alert/Drop (both are selected) , New Action - drop
Policy - Policy 1 - No selected lists (all) - Action alert , New action - Default
Back to download rules - select all of them - download and apply
Settings - Apply
I actually do one easier.
Download - Enable list you want
Policy - Policy 0 - Select lists you like to drop with. Action: Alert , New Action - drop
Back to download rules - select all of them - download and apply (note: with snort rules, i had to run this twice the first time....possibly a timeout on the initial fetch)
Settings - Apply
The defaults seem to be set to "alert". So you shouldn't need a policy set for this. I have noticed multiple policies can have a direct impact on performance (though i have been onboarding and tweaking settings a ton and it may have been some of the other settings. I need to test policy layers specifically.)
And as I add new rulesets (assuming they haven't been previously selected in that policy) they will default to alert. When im ready to move them to drop i just edit the policy and select the rulesets/lists and hit apply.
You can generally verify in the rules tab using filters
action/alert and status/enabled
or
action/drop and status/enabled
-
This thread helped a lot! tbh i had no idea my IPS wasn't working ;D but after checking everythin was "Allowed", followed the instructions here and now it's back to working again :)
thanks for this :D
-
OK, so my problem is that I activated and downloaded all rules, did my policies, etc. but since a couple of days my Suricata stopped working.
I threw an error 0145 about not being able to bind an interface (did not change anything). However, after rebooting, deselecting and selecting the IFs again, Suricata not boots up again and reports itself running.
BUT: it does not give any alerts, typically I get tons of since my Fritz!Repeater sends some unverified UPnP IPv6 packages through the net which have been detected and dropped ever since.
Is there anything left I can do?
P.S. SOMETIMES it goes "error when installing IDS rules - cannot install IDS rules" but only with a pop-up in the web GUI.
P.P.S. And I see ET open rules even if I remove the package. When I install it, I see the ET open rules doubled. Strange ...
-
Got similar issues ...
v21.5
Any idea how to solve this?
-
OK, I have no idea but now it works ...
Suricata gives alerts again.
But what I do not get is that nothing seems to be blocked?
See the screen shots (IDS mode enabled).
If I click on the magnifier icon on the right, it tells me the corresponding rule is "enabled" and "drop", but as you see, the package is "allowed".
What is wrong here?
EDIT: LOL, now, after posting this and refreshing the log (AND ABSOLUTELY CHANGING NOTHING IN THE MEANTIME) it now blocks the same rule per the "Alerts" pane.
Although it seems to work now, the implementation of Suricata seems to be ... optimizable. I have no good gut feeling about the reliability of IPS / IDS in the current v21.1.5.
BTW: What catches a incoming package first? Firewall rules or IDS block policies?
-
OK, so for everyone else having similar problems, here's the step by step guide again:
1. Define Policy "Alert to Drop" -- Apply
2. Download & Update Rules
2.1. Check within the Rules Tab (Enabled) ===> Are all rules on drop?
3. Settings -- Apply
IMPORTANT: On my APU4D4 Board it takes about 15mins (sic!) from "rule reload complete" in the log until the "net open" messages, that the interfaces are actually been listened to. Avoid hasty clicking and give IDS / IPS some time to load, especially when using lots of rules!
My problem still is, that the ET Open rules sometimes time out during reload which ends up with the error message I posted. This problem is still not solved. Sometimes it works, sometimes it does not. I would wish some asynchronous GUI for the IDS / IPS plugin. The GUI regularly freezes, unfortunately.