Hi,
I'm facing issues with outgoing traffic and possible DoS attacks. Here are my questions and observations:
A. How can I block outgoing traffic related to DoS attacks?
B. How do I change the priority of manually added firewall rules or lower the priority of automatically generated rules?
Background Details:
I've noticed repeated DoS alerts (RST Scan) in my Netgear router logs:
[DoS Attack: RST Scan] from source: 185.59.223.192, port 443, Sunday, December 29, 2024 20:23:56
My OPNsense logs show outgoing traffic to the same IP (185.59.223.192:443) despite having a rule to block it. The outgoing traffic seems to bypass my rule
due to an automatically generated floating rule: "let out anything from firewall host itself (force gw)"
Firewall (opnsense) Configuration:
I created an alias with a list of IPs (including 185.59.223.192) and added a rule to block outgoing traffic to those IPs.
Despite this, outgoing traffic is being allowed, as seen in the OPNsense logs:
2024-12-30T01:23:36 filterlog[10352] 75,,,ff761fc54aa881cf05997aa13783aa54,ue0,match,pass,out,4,0x0,,126,14261,0,DF,6,tcp,52,6x.8x.8x.x,185.59.223.192,6660,443,0,S,283913834,,64240,,mss;nop;wscale;nop;nop;sackOK
2024-12-30T01:23:36 filterlog[10352] 75,,,ff761fc54aa881cf05997aa13783aa54,ue0,match,pass,out,4,0x0,,126,14260,0,DF,6,tcp,52,6x.8x.8x.x,185.59.223.192,45650,443,0,S,730767861,,64240,,mss;nop;wscale;nop;nop;sackOK
1. What steps should I take to effectively block this outgoing traffic and stop the DoS?
2. How can I adjust the priority of manually added rules or lower the priority of the automatically generated "
let out anything from firewall host itself (force gw)" rule?
3. What exactly is this RST Scan, and how do I mitigate it?
Any guidance would be appreciated!
Network Setup:
Netgear Wi-Fi Router: 2x.2xx.2xx.2/24 (Wi-Fi network: 1x.1xx.1xx.1/4)
OPNsense LAN: 2x.2xx.2xx.1/24
WAN IP: 6x.8x.8x.x
The "let out anything from firewall host itself (force gw)" rule is not the one giving you trouble. This is the leg of traffic from the firewall, _after_ it was received from your network (LAN presumably). This is the first part where your own rules must be made to work.
So client sends traffic, arrives at the firewall, firewall sends it out.
As you can see, your rule needs to be applied immediately upon arriving.
That out of the way, we need to find why your rule to block it has not worked. Did you reset the state table after applying the new rule? If not, then connections established would continue.
Can you show your rules with a screenshot here (not linked)?
p.s. you probably also want to stop the traffic at the source.
sorry, no links for me. You can attach the screenshots to the post
If the connection is already established, I don't believe a new rule will affect it.
Your logs seem to indicate which client on your network is initiating traffic.
Why don't you look there for the process owning the source port?
BTW, are you not using RFC 1918 ranges on your LAN?
Edit: I'm actually not getting a clear picture of your topology. Internet and your 2 routers (OPN & Netgear).
I initially thought I could ignore the Netgear router log, but when I saw corroborating messages and connections in OPNsense, I realized I needed to investigate further.
From the Netgear router, I can't identify the source because the router's UI is very limited. However, on OPNsense, I can see that the traffic originates from the Netgear router and is going out to 185.59.223.192:443. I tried to block this traffic, but an automatically generated rule is allowing it to pass.
Regarding RFC 1918 compliance, there's one segment of my network that doesn't use an RFC 1918 range—the connection between the Netgear router and OPNsense.
Network Topology:- LAN (Netgear router): Multiple RJ45 and Wi-Fi connections using 1x.1xx.1xx.0/24.
- Netgear <-> OPNsense: Single RJ45 connection using 2x.2xx.2xx.0/24 (non-RFC 1918 range).
- OPNsense <-> Cable Modem: Single RJ45 connection using a public DHCP address assigned by the ISP (6x.8x.8x.x).
If you still have the connection, there's a state for it in Firewall > Diagnostics > States.
You can delete the state from there. If you now have a rule blocking that traffic, it should fail to reestablish...
Maybe you'll notice something stuck on a client.
In one of the Netgear forums posts I found with a quick search, the author had figured out it happened while streaming from reputable sources.
The fact that it's reported by your inner router on outgoing connections makes it fairly likely it's a false alarm IMO.
Putting the Netgear in AP mode (and changing OPN's LAN to match the Netgear range) would eliminate double NAT, make it way easier to identify the source and get rid of that intermediate routable range...