CU195 Testing - WireGuard IPS ramblings

CU195 Testing - WireGuard IPS ramblings

[Adam Gibbons]

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

Re: CU195 Testing - WireGuard IPS ramblings

[Adolf Belka]

Hi Adam,
On 20/05/2025 23:28, Adam Gibbons wrote:
> 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.

That is something I have been looking for, for my testing activities. My test systems are vm's and are behind my "production" IPFire system and therefore nothing much gets triggered in the IPS on my vm systems as it has all been filtered out by my main IPFire.
Your approach gives me something to create a condition that should be picked up.

I will be giving it a test to confirm I can get it working.

Thanks very much.

Regards,
Adolf.

> 
> Bug reports are great, but it's better when something just works.
> 
> Cheers,
> Adam
> 

Re: CU195 Testing - WireGuard IPS ramblings

[Adolf Belka]

Hi All,

On 25/05/2025 11:58, Adolf Belka wrote:
> Hi Adam,
> On 20/05/2025 23:28, Adam Gibbons wrote:
>> 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
>>

For information this rule can be found in emerging-misc.rules in the Emerging Threats community ruleset.

Regards,
Adolf.

>> 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.
> 
> That is something I have been looking for, for my testing activities. My test systems are vm's and are behind my "production" IPFire system and therefore nothing much gets triggered in the IPS on my vm systems as it has all been filtered out by my main IPFire.
> Your approach gives me something to create a condition that should be picked up.
> 
> I will be giving it a test to confirm I can get it working.
> 
> Thanks very much.
> 
> Regards,
> Adolf.
> 
>>
>> Bug reports are great, but it's better when something just works.
>>
>> Cheers,
>> Adam
>>
>