OPNsense Forum
Archive => 23.1 Legacy Series => Topic started by: steilfirn_8000 on February 05, 2023, 10:28:03 am
-
Hello there,
I am using a Mikrotik router in front of my OPNsense firewall (virtualized) to act as an internet border router and takes care of VPN, OSPF & BGP.
On OPNsense it is connected to my WAN interface and there are firewall routes which allow traffic from VPN sites to my subnets behind OPNsense.
In general this works.
As I am using Surricate IDS/IPS additional also on my WAN interface I recognized that there are a lot of blocking messages altough the blocked addresses are being allowed on the local/home network tab at Surricata.
What is strange: It still works - Surricata tells that it blocks the traffice but in the background it still works.
Is this an expected behavious?
-
Hi
"local/home network" not defines "allow" list. This list defines HOME_NET variable so suricata can correctly apply rules with flow direction
https://suricata.readthedocs.io/en/suricata-6.0.0/configuration/suricata-yaml.html?highlight=home_net#rule-vars
It still works
suricata should be in IPS mode to block traffic
-
Hello, thanks for the advice. Currently Surricata is using the IPS mode already.
In general is there an allow list which prevents such issues?
From a firewall perspective one local/home subnet ist behind and on would be in front of WAN interface
-
In general is there an allow list which prevents such issues?
you can create a "pass" rule at Services: Intrusion Detection: Administration: User defined tab
Currently Surricata is using the IPS mode already.
and it shows traffic as "blocked" in alerts, although it doesn't actually block?
-
Yeah, it shows something like that:
2001569 blocked WAN_500 192.168.101.11 52389 192.168.10.104 445 ET SCAN Behavioral Unusual Port 445 traffic Potential Scan or Infection
But SMB access itself works. I can open any SMB shares without any problems
-
Hi
But SMB access itself works. I can open any SMB shares without any problems
is this true for all "blocked" alerts or only for some rules (for example, those using tcp flags)?
-
All my internal network which was blocked accoring to Surricata (IPS was on) worked without any problems.
My active directory was in sync, DNS resolved without any issues, SMB worked as well.
That's why I was not sure about this alert.
-
sorry, please clarify, can you give more examples of alerts that are displayed as "blocked" but actually pass traffic?
it might be interesting
-
The error message would be exactly the same as already mentioned but for example would use tcp 135 (= RCP)
Unfortunately I have currently swapped the OPNsense to test some more lightweight distribution
-
got it, thanks. will try to reproduce
-
My setup was:
Remote site <-- Wireguard tunnel with OSPF --> Internet router (OSPF enabled) <-- 2x OPNsense with HA (OSPF enabled)
On both sides I had some AD domain controllers and windows server which used Microsoft typical ports (mostly RCP, SMB).
Surricata complained about both direction: From local site to remote but also from remote to local.
The subnet between OPNsense and my internet router was the WAN side according OPNsense firewall logic.
-
regarding the '2001569' rule: it seems to work as expected (although there are questions about the docs). full rule syntax:
alert tcp $HOME_NET any -> any 445 (msg:"ET SCAN Behavioral Unusual Port 445 traffic Potential Scan or Infection"; flow:to_server; flags: S,12; threshold: type both, track by_src, count 70 , seconds 60; reference:url,doc.emergingthreats.net/2001569; classtype:misc-activity; sid:2001569; rev:15; metadata:created_at 2010_07_30, former_category SCAN, updated_at 2017_05_11;)(you changed it to 'drop')
the rule drops the start packet (SYN flag) if 70 packets arrive from the source address in 60 seconds. in fact, this allows the protocol to work without problems. such a rule is actually only suitable for generating alerts, not for dropping packets.
if you modify the rule so that it does not have thresholds or flags, SMB will stop working ;)
--
I was not able to clarify this issue at the time: the docs states "Rule actions drop (IPS mode) and reject are applied to each packet." (https://suricata.readthedocs.io/en/suricata-6.0.0/rules/thresholding.html), but I checked against several rules and it seems that thresholds are also respected for drops. no one answered me on the suricata forum, and I didn’t have time to shovel the code..
so maybe it makes sense to try with a simpler rule to make sure that your suricata can actually drop packets
-
Thank you very much for your investigation.
What I forgot to mention is that I also created an "allow rule" for all my local and remote subnets.
Surricata still denied traffic.
Is this also an expected behaviour?
-
Surricata still denied traffic.
really denies or only messages appear?
i checked and the User defined "pass rule" actually works, although the drop event appears in the alert log.
Is this also an expected behaviour?
sort of.
I remembered that I had already wondered about the excessive noise in the eve-log. and it seems to be related to the eve-log settings in template.
https://github.com/opnsense/core/commit/573612d48ebe6142015befbe558a2c9829e85fcb
https://github.com/opnsense/core/issues/4841
At first glance, this does not give anything but noise. but apparently there were reasons for this change. suricata's docs is so non-obvious (for me at least).
need to dig deeper to see for myself first, and then try to convince the devs to try disabling drop event logging.
-
According to the log files it blocked the traffic.
But also as mentioned earlier: Even if Suricata mentioned it blocked it for me it worked without any issues.
-
Not sure if this is relevant for this topic but with my new router setup I am also using Suricata as IDS/IPS (from SELKS https://github.com/StamusNetworks/SELKS) with equal settings as on OPNsense.
With this setup it is not having any troubles with my LAN & remote sites.
-
Not sure if this is relevant for this topic
it's hard to say, since so far only false positive alerts (fixable) and possible misconfig are visible imho
-
for the ref.
https://forum.suricata.io/t/drop-log-false-positive-records-possible-since-6-0-6/3228/1
-
for the ref. false-drop records fixed in https://github.com/OISF/suricata/commit/517132b6ad0347c8402b3aace885d1b734609fec
although I still think it would be great to be able to disable drop-log on the OPN