Protecting against TCP reflection attacks

[mjholgate]

Hi there, I just wondered if anyone had any tips on firewall rules to protect against TCP reflection attacks?

Behind my Opnsense box I have an HTTP server, and I have a NAT rule (with associated firewall rule) to redirect traffic from the external port 80/443 to the internal machine port 80/443. I also have a similar rule for IPv6, obviously without the NAT.

What I'm seeing is that I'm getting a lot of half-open connections made at a lowish rate - the remote end is sending a SYN, my server is responding with SYN-ACK (and then sending 5 retries), but I never receive the final ACK.

My guess is this is a reflection attack as because the source IP is repeated many times before changing to another IP in the same network, whereas an attack on my own server would presumably use a random IP every time? See the screenshot attached for an example.

The main problem for me is that it's filling up my log, so I could simply turn off the logging, but i prefer not to do that and also don't want to be the source of a reflection attack if I can help it!

I was looking at the advanced firewall rules to see if I could limit the number of half-open connection per source IP, but I can't find anything to do this specifically. The options available are:

- Max states - no use because this would prevent legitimate connections getting through from other IPs
- Max source nodes - no use because this just limits the total number of source IPs
- Max established - no use because the connections here are not established and still in the half-open state
- Max source states [per IP] - this is the closest thing I need but it would block legitimate clients that are in the established state or waiting to close because it doesn't match only half-open connections
- Max new connections - this would block legitimate clients as it's not per source IP.

Does anyone have any tips on mitigating this scenario?

Thanks
Matt.

[Patrick M. Hausen]

If you use port forwarding the SYN/ACK is not sent by OPNsense but by your internal server. You could try to enable SYN cookies on that one.

Or switch to a reverse proxy like Caddy instead of NAT, OPNsense has SYN cookies enabled by default, IIRC.

[mjholgate]

Thanks, but I'm not sure if SYN cookies help here, because it's not causing an issue filling my state table as such - it's more that it's causing damage by reflecting 5x the traffic in SYN-ACK replies to the spoof sender (which presumably it will still do even with SYN cookies enabled?).

[Patrick M. Hausen]

Then something like Crowdsec might fit your bill blocking known malicious actors?

Seriously now I am at a bit of a loss. You cannot cease accepting and answering SYN packets if you have publicly accessable services ...

Geoblocking might be another idea.

If you just want to brute force lower the number of retries, currently that needs to be done on the internal server as I wrote. Don't know from the top of my head which parameter that would be in either FreeBSD or Linux.

[mjholgate]

Thanks, yeah. I suspect as much.

I just wondered if there was a place for a new firewall option like "maximum number of states in half-open state per IP" which would presumably make this less of an issue as you could start to drop connection requests after (say) 10 or 20 half-open connections had been made from a given IP.

[mjholgate]

Crowdsec is a good call btw, I did install that the other day for blocking ssh brute forcing. Will check out the rulesets for that... thanks!

[cookiemonster]

Definitively a case for a reverse proxy. HAProxy plugin doesn't have all options enabled in the UI but could have additional options added to advanced options as pass through. Examples of hits https://www.haproxy.com/blog/application-layer-ddos-attack-protection-with-haproxy