Hi all,
Recently I’ve been keeping myself busy testing the newly released CU195
testing build, which includes WireGuard support (insert ITS_ABOUT_TIME
emoji here). Today I wanted to test if the IPS was actually inspecting
and blocking traffic on the newly added interface.
I thought I’d share my testing approach and findings, in case it’s
useful, interesting to anyone else, or for documentation.
Test Methodology:
- Set up a Fedora VM, connected to IPFire via WireGuard as a Host-To-Net
peer (roadwarrior).
- Enabled IPS only on the WireGuard interface (disabled on RED and GREEN
etc).
- To check if Suricata was properly inspecting traffic inside the
tunnel, I looked for a rule that would be safe and easy to trigger on
purpose.
I settled on this rule:
GPL MISC source port 53 to <1024 (sid:2100504)
https://threatintel.proofpoint.com/sid/2100504
I picked this because it’s straightforward to match, unlikely to cause
noise or false positives, and works well for a basic end-to-end test.
How I triggered the rule:
From the Fedora VM (192.168.26.5), I used hping3 to send a SYN packet
with source port 53 to IPFire’s external IP on port 80:
hping3 -S -p 80 -s 53 <ENDPOINT_IP>
This created exactly the traffic the rule is looking for.
Result:
The alert appeared in Suricata’s log:
Date: 05/20 21:43:21
Name: GPL MISC source port 53 to <1024
Priority: 2
Type: Potentially Bad Traffic
IP info: 192.168.26.5:53 -> <ENDPOINT_IP>:80
SID: 2100504
This test confirms IPS is inspecting WireGuard tunnel traffic as
intended in CU195.
Bug reports are great, but it's better when something just works.
Cheers,
Adam
