CU195 Testing - WireGuard IPS ramblings

[Adam Gibbons <adam.gibbons@ipfire.org>]

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