Hello,
I'm trying to validate a new OPNsense Business 26.4.1 installation using the new Rules [new] + Divert IPS architecture.
The firewall is deployed as a transparent bridge.
Physical topology
Internet
|
Ethernet (ISP)
|
OPNsense Business 26.4.1
(transparent bridge)
|
Fritz!Box
|
Switches
|
LAN
The firewall is not the router.
The Fritz!Box remains the router/NAT/DHCP device.
Suricata configuration
OPNsense Business 26.4.1
Capture mode: Divert (IPS)
Home Networks configured
ET/Open rules downloaded
SID 2100498 enabled
Tested with both Alert and Drop
Syslog alerts enabled
EVE syslog output enabled
Firewall configuration
Using Firewall -> Rules [new].
Test rule:
Interface: WAN
Action: Pass
Direction: tested with In and Both
Protocol: TCP
Source: any
Destination: any
Divert-to: Intrusion Detection
Quick enabled
Originally I also tested Divert on the bridge interface, but after reading the documentation I moved the test rule to the physical WAN interface.
System configuration
Verified according to the documentation:
net.link.bridge.pfil_bridge = 1
net.link.bridge.pfil_member = 0
Hardware checksum offload disabled
TCP segmentation offload disabled
Large receive offload disabled
Test performed
curl http://testmynids.org/uid/index.html
This is the test described in the Suricata documentation for SID 2100498.
Expected result
I expected at least:
GPL ATTACK_RESPONSE id check returned root
to appear in the Suricata Alerts.
Changing the SID action from Alert to Drop also produces no difference.
No alert.
No drop.
Question
At this point I'm trying to understand what I may have missed.
Is there anything specific to Divert IPS in transparent bridge mode that would prevent SID 2100498 from triggering?
Is there a recommended procedure to validate that traffic is actually reaching Suricata when using the new Divert architecture?
Thanks in advance.
Quote from: phubert61 on Today at 10:45:02 AM[...]Originally I also tested Divert on the bridge interface, but after reading the documentation I moved the test rule to the physical WAN interface.[...]
Did you try it on the bridge? pf rules applied to an interface will not be evaluated when the interface is a member of a bridge (regardless of the bridge sysctl settings, in my testing).