OPNSense vulnarable for tcp middlebox reflection?

[reijnders@tor.nl]

Apologies for bringening this up again (I posted a message about this in 24.1 Production Series 2 weeks ago).

I've been warned by my Internet Provider (KPN) that my internet connection is vulnarable for 'tcp middlebox refelction'. This is based on scan of shadowserver.org. Basically that the firewall is responding to SYN requests in a non-compliant way.

See
https://www.akamai.com/blog/security/tcp-middlebox-reflection
https://www.redwolfsecurity.com/understanding-and-running-middlebox-tcp-reflected-amplification-attacks-with-the-redwolf-platform/#:~:text=TCP%2Dreflected%20amplification%20attacks%20exploit,headers%20with%20a%20blocked%20site.

The latter defines 'TCP middlebox reflection' as follows:

TCP-reflected amplification attacks exploit middleboxes that are deployed in a non-TCP-compliant way by responding to out-of-state packets and applying content restriction policies. Attackers take advantage of this by sending an out-of-state spoofed source IP packet containing host headers with a blocked site.

My internet fibre connection is directly attached to the OPNSense firewall (its on VLAN6). I've got a subnet of 8 ip-addresses and the issue is reported on the DMZ ip addresses, so not in the IP address that forwards HTTP trafic to an interanal server.

One on the proposed solutions is to filter out all SYN/!Ack packages that are larger than 100 bytes. Should I add such a rule to /usr/local/etc/ipfw.rules directly (as OPNSense itself cannot filter on package size)? And how would the rule from the artice:

deny tcp any eq 80 host x.x.x.x match-all +syn -ack packet-length gt 100

translate to ipfw?

Or should I try to check the setting Firewall->Settings->Advanced->Bind states to interface (as this has to do with state management)?

Any help or insight is greatly appreciated!

Tom

[Greg_E]

Would Suricata block this "attack"? You'd need to dive through the rules and see if there is one to block this, but it might be that easy.

[reijnders@tor.nl]

Hmm, that seems like a bit of overkill to me. I'll look into it. Thanks for the sugestion.

[AHAutomation]

Hi Tom,

We also being warned by KPN. With an reply to them i recevieved additional information when the event took place.
Since 1 july got 5 ddos-amplification events.
Instead of OPNSense we use PFSense, but those are basiclly the same.
We use the PFSense CE version, but funky stuff almost basic setup.

My only option is to update everything we have on the network.

Did you find any causes or ways to find out where it came from?

[really_lost]

A few comments:

That first link seems to imply this is from some blocking tool sending website info. That sounds like something like ZenArmor set up to respond with a blocking web page info.

Any chance you have dns filtering set up to respond on the WAN interface?

ShadowServer.org describes how they do this: https://www.shadowserver.org/what-we-do/network-reporting/vulnerable-ddos-middlebox-report/

It's definitely doing a GET against a blocked URL. This is not something a stock opnsense box will do. This is being done by some plug-in mistakenly set to block WAN traffic.

If you have static IPs, you can sign up with ShadowServer to get reports on your IP's with exact timestamps.