Trying to understand nature of "DoS attack: RST Scan" log messages
Disclaimer: I am a security engineer, so my questions which follow are not to understand what a DoS attack or RST scan are; I know what those are -- I'm trying to understand the behavior of my router and the nature of its logging.
Ok, here we go. I have a NETGEAR RAXE500 router, with latest updates, Armor running, in router mode (NAT), no UPnP turned on, no port forwarding, admin over HTTPS only, and access control turned on, meaning only whitelisted MAC addresses can successfully connect to the network. Additionally, this sits behind an enterprise-class firewall device running pfSense which also has no pass-through services or port forwarding enabled, and is also NAT'd. So the only devices on my network are from whitelisted MAC addresses, and the only inbound network communications which should reach clients inside the RAXE500 network are responses to requests which originated from known and whitelisted devices within the network. In other words, no connections initiated from the outside should succeed.
Every night, I have the RAXE500 email me router logs. Every day, that log email is loaded with lines indicating DoS attacks, specifically RST scan, such as the following:
[DoS attack: RST Scan] from source [IP ADDRESS REDACTED] ,port 443 Thursday, Oct 27,2022 23:52:37
There's a ton of these. I tracked down a few of these IP addresses and they appear to be associated with well-known video streaming services -- one belonging to a popular vendor of a TV streaming device (you all would recognize, in fact, many of you probably have one too), and the others one of the vendors or one of the more popular video streaming apps on mobile devices. So the common thread between the various IPs is that they appear to be associated with video streaming.
My questions:
This is a confusing (or perhaps better stated, incomplete) log message, because while there is a source IP address, no destination IP address is listed. Given the mention of port 443, I'm assuming it is looking for the WAN address, but on my network, the WAN IP address on my NETGEAR router is not a public IP, but a private IP, because as stated it is sitting behind another firewall. What would be the nature of an outbound connection which could even reach this router? All traffic outside my greater network (the Internet) does not reach my NETGEAR router. I'm suspecting this might be an aberration of a confusing log message, and I'm misunderstanding what it is actually saying.
What is the specific criteria which results in the NETGEAR router logging a DoS attack: RST scan?
Are these log messages the result of traffic exclusively initiated outside the network and destined for the router, or as packets being sent in response to client requests originating on the inside of the network?
Is anyone aware of any network connection management techniques particular to video streaming where many TCP RSTs might be sent to try to cleanup network connections, which might get mistakenly detected as a DoS attack?
Finally, If there's anyone from NETGEAR reading this, I hope you'll take this constructive suggestion to heart: your routers are way too expensive to have such lightweight logging, documentation, and visibility into their function. If there's any way to get to the low-level system logging in these devices without having to breakout, please let me know, as I'd really like to understand what is going on here. Feel free to contact me privately if necessary. Also, thanks in advance to anyone else who can shed a little light on this behavior. Thx so much!
Re: Trying to understand nature of "DoS attack: RST Scan" log messages
NETGEAR routers are famosly known for generating false DoS entries, even from your local devices. 98% of these can be discarded as they're false positives. It's a broken system. If you suspect an entry is valid, you can look up its IP. NG also reports attacks from your own devices and ISP. I wouldn't trust that system ever, unless they completely fix/rewrite it.
As these DoS attacks slow down the router by requiring processing (blocking) and logging, it's best to either disable logging or if that is not enough completely disable DoS protection - you're not missing much. I run 8 years without DoS protection and have yet to experience something disturbing/malicious/etc
Disclaimer: I am a security engineer, so my questions which follow are not to understand what a DoS attack or RST scan are; I know what those are -- I'm trying to understand the behavior of my router and the nature of its logging.
@microchip8 sums it up. Their answer should warn you that you are on a hopeless quest in trying to understand how your router behaves. That's because there doesn't seem to be any logic in there that you can fathom.
As things stand, as a security engineer you can probably tell us more than most about what is going on under the hood.
Re: Trying to understand nature of "DoS attack: RST Scan" log messages
Things that will get logged, are scans that will look for signs of a closed port (this is used to check if a host is live even if it can't get much info on what is actually using the port.
While it will use some resources, often it is less than 1% load even when you connect the WAN port directly to another PC and do a DOS attack directly to it. The router will not generate a separate log entry for each packet, thus it effectively self regulates to avoid flooding the log file with junk.
If you want the router to give you a nice set of a range of log entries, run this scan on all service ports. https://www.grc.com/shieldsup
Beyond that, many log entries of DOS and other attacks are very common and are simply what many people tend to refer to as internet background radiation. Often from random infected devices, e.g., the person still running windows XP that is still endlessly scanning the entire IPv4 range looking for systems to spread the sasser worm to, or other junk. Or people who have old IOT devices that never receive security updates and are now endlessly scanning the IPv4 space or even IPv6 space and endlessly running exploit toolkits on every host it finds. Overall, it is a constant thing and there is not much that can be done about it. For example, a 2 minute packet flood at 1Gbps will generate around 7 log entries.
As for destination, they are not really listed for such attacks since they are directed at your WAN IP. Devices behind the NAT are not exposed enough to be directly targeted unless you have a device deliberately exposing itself via port forwarding or UPnP.
PS most security entries with a destination IP are not blocked, and instead are listed for your information. For example, if you have a Verizon Fios DVR, and have the DVR connected to your netgear router using a MoCA to Ethernet bridge, and have the proper ports forwarded, then you will occasionally see entries beginning with "[LAN access from remote]", especially when you are using the remote DVR service to manage recordings.
As for the logging, I feel that they are intentionally kept to a minimum, especially considering that there is far more detail if you capture a debug log via the debug.htm page of the router.
As for using a separate firewall, what makes it through could depend on how it is configured and how it handles established connections, as they have to strike a balance between preventing unrequested traffic, but also allowing connections to be established by any LAN side device when a packet matches the LAN to Any ruleset. Sometimes things can get complex when a device may have other services running on different ports, e.g., if the company wants to grab analytics data or other stuff unrelated to your streaming.
In addition to that, many more advanced firewalls will also default to very permissive rules (unless they have a more security focused setup wizard), where you may have an allow all rule, and then a bunch of specific blocking rules, and things can be a lot more permissive than many default rules of many consumer routers, since the more advanced units focus on giving the user more control.
While normally a response due a LAN client's request will not result in a DOS or other flag in the logs, unrelated traffic from a device that you requested data from can still result in entries. For example, if you do the GRC scan, even though you requested traffic to the page, you did not request specifically each individual scan from that server, thus that traffic will be logged.
If you want the router to give you a nice set of a range of log entries, run this scan on all service ports
…
As for destination, they are not really listed for such attacks since they are directed at your WAN IP. Devices behind the NAT are not exposed enough to be directly targeted unless you have a device deliberately exposing itself via port forwarding or UPnP.
That’s just it though — the NETGEAR router does not have a publicly routable IP address. Its WAN IP is a private IP address/network sitting behind another firewall device which is NAT’ing all traffic, UPnP is off and there is no port forwarding whatsoever. This router isn’t even visible or reachable from the Internet. The only traffic which reaches it are responses to client network requests which originally initiated from inside the NETGEAR network. There is no ability to scan it from outside the network using ShieldsUp, Nmap, whatever. You can’t ping it. The log entries indicate the source hosts are public IPs — those can’t see the WAN IP — the only way network traffic from one of those public hosts could even reach the router is if it were a response in a TCP dialog initiated from within my network. Therein is a primary part of the question.
Also, this quote:
Or people who have old IOT devices that never receive security updates and are now endlessly scanning the IPv4 space or even IPv6 space and endlessly running exploit toolkits on every host it finds.
A compromised iOT device external to my network can scan all it wants to no avail — again, my NETGEAR router is not visible publicly, the network traffic won’t reach it — it would be dropped at the external firewall. If a compromised iOT device happened to be on my network (which it isn’t, but just for argument), that would not be network traffic coming from a public IP, it would be coming from a private IP on the local network destined for the router’s LAN IP, not the WAN IP.
There are any number of things which might be in play, but my gut says that either the log entry is best described as, to quote the meme-able “Princess Bride” movie, “I don’t think it means what you think it means”; or, this is a false positive, which is probably better described as just faulty criteria or implementation which is not understanding packet traffic properly — and possibly both.
I’ll see if I can’t get a packet capture on the router and the external firewall and compare the two, see what I can come up with. Thanks for taking the time to respond, I really appreciate it!
As things stand, as a security engineer you can probably tell us more than most about what is going on under the hood.
Well, what I know is that something here doesn’t make sense, The meaning of the log entry isn’t clear nor is the criteria which generates it; even if you knew all of that information, there doesn’t appear to be any mitigation options in the router for the likely possibilities. It kind of relegates all of the supposed security features to Christmas lights — they blink and flash and look pretty and makes you feel good that they’re there, but they don’t have much of a pragmatic use. (No knock on Christmas lights).
Improving usability surrounding logs, diagnostics, and documentation on low-level routing function would all be pretty low-hanging fruit to give these routers a giant leap forward. Seems like NETGEAR wants to follow the model of newer cars, sealed black boxes which you cannot fully administer and work on yourself. Too bad, much room for improvement here. Kind of screams for a Raspberry Pi Kickstarter.
Re: Trying to understand nature of "DoS attack: RST Scan" log messages
@microchip8 thanks for the reply. Yeah, you are probably right. My gut says these are all misunderstandings of network traffic passing through the router. The fact that there doesn’t seem to be the ability to look into the raw data triggering these log entries is kind of a tip-off that there really isn’t an intent to provide any further diagnosis of the problem. It’s kind of a “trust us, this is happening” and even if it is, there’s nothing to do about it.
I’m going to dig a little further, and see what I can find. Then consider what to do next.
Improving usability surrounding logs, diagnostics, and documentation on low-level routing function would all be pretty low-hanging fruit to give these routers a giant leap forward. Seems like NETGEAR wants to follow the model of newer cars, sealed black boxes which you cannot fully administer and work on yourself. Too bad, much room for improvement here. Kind of screams for a Raspberry Pi Kickstarter.
The issue of weird logs has been rattling around here for some time. Hence the boilerplate repose "check the sort of those attacks".
As to "it would be easy to fix" comments, I bow to your knowledge, but in many cases these demands come from people who don't know what it takes to code this sort of stuff. They also overlook the fact that coding is just a part of it. Qualification of the new firmware – getting it through quality control and the like – is probably more complicated than the coding. And as we see all too often, when broken firmware lands here, it is this bit of the process that fails.
But please keep digging. This has turned into an interesting conversation.
Re: Trying to understand nature of "DoS attack: RST Scan" log messages
Fact is, NG refuses to change the developer of its firmware (NG itself doesn't make the firmware) most likely due to economic issues. I'm absolutely sure NG is aware it has one of the worst firmware around, yet refuses to do anything. Delta Networks, inc (DNI) doesn't care that much as long as they get paid and offer a "good enough" firmware, regardless of bugs and other issues
If NG continues this path and doesn't change its priorities, they will fall further and further down.
That said, NG offers one of the best *hardware* devices around. They run cool, are very solid and reliable, and just work (unless the firmware throws crap)
As to "it would be easy to fix" comments, I bow to your knowledge, but in many cases these demands come from people who don't know what it takes to code this sort of stuff. They also overlook the fact that coding is just a part of it. Qualification of the new firmware – getting it through quality control and the like – is probably more complicated than the coding. And as we see all too often, when broken firmware lands here, it is this bit of the process that fails.
I have a few years developing software (30), so I can speak to that. Perhaps I should have said “relative ease”, because it would not be an exercise of development from scratch. All of the data is already being processed, and it appears that the “logs” the user are provided are more an aggregation or conclusion (which I’m guessing isn’t completely accurate) rather than just providing the raw logs.
I’ve been using NG networking equipment for about 25 years now, so I’m very familiar with the evolution of their hardware (and @microchip8 is right, good hardware), and the non-evolution of their admin consoles, so over time, using NG products seems to be synonymous with an ever-growing wish-list. (In fact, funny side note — I recently bought one of the old NG hubs on eBay, b/c w/o switching, it makes for a nice device to sniff network traffic for security research — I ended up paying more for it than when it retailed new!)
It is pretty clear that the NG roadmap is a lot like that of newer automobiles, to make products that are even further black-box, which the only knowledge / support can be performed by the vendor. I understand why this is (both good reasons and bad), but it would be nice if NG would embrace both. A model where folks who didn’t care could stick to the blinking lights and needles on the dashboard, and others who want to pop the hood could do so and really understand and perhaps improve the product could do so.
A comment / question:
- Last I checked, NG’s bug bounty program didn’t compensate security researchers for submitted vulnerabilities (it is a work-for-free deal) which is why I didn’t research on that program. It would be really nice if that changed, I have found vulnerabilities in the past just by using the thing, not even researching. I’ll check back to see the status of their program….haven’t looked at it in a while.
- Does anyone know if NG makes firmware available for community review / development? I know there’s a community that has sprung up around some Linksys router firmware. It would be really cool if NG would embrace what some video games and security tool vendors have (like OWASP, Cobalt Strike, Hak5), and leveraged the modding community. If that were possible, I’d work on NG firmware in a heartbeat.
I’d sum up my perspective here as wishing NG would see the cup half-full. There’s huge opportunity for innovation here….just need the optimism to embrace it. I’d love to contribute if it were worth my while.
Thx for replies…this has become an interesting discussion.
Re: Trying to understand nature of "DoS attack: RST Scan" log messages
Thank you @brado77 for a post on this topic I'm trying to learn more about.
I had 2 computers even before getting both the Tandy 1000EX and 1000SX (dual floppy / no HDD).
Fast forward to today. The last 2 evenings, the TV is buffering and game machine losing service brought me to looking at the logs. Could be the ISP due to solar activity (2/22/24) and AT&T outages? Central USA location.
The log shows DoS attacks within 2 minutes of reset. Most are Fraggle and RST. Thanks to reading this thread I realize it is more inherent to the firmware than real attacks. Fraggles show port 67. RST scans on port 443. Also ACK scan on port 993, resolves to googleplex, CA.
I bought a pfsense SG1100 last year. I've been trying to teach myself it's setup. Now with the new buffering problem, I'm going to install the Nighthawk AX5400 for computers (whitelisting) and the Nighthawk R7960P as an access point for IOT devices. That is until I feel good enough about rules and subnetting setup on the pfsense to implement it.
Just posting this to say thank you and others on the thread for the insights on the DoS log messages. Now I am off to read about email did not resolve topic.
Re: Trying to understand nature of "DoS attack: RST Scan" log messages
Hi. RAX54S-100NAS router here.
RE the DoS Fraggle attack, it would seem reporting this - maybe spuriously - is a Netgear firmware "feature", as this thread (above) seems to indicate.
After being forced to reset the password twice in conversation with Netgear support, I got on the phone with the ISP, Xfinity/Comcast because the "attack" origins were within their network. They didn't see anything going on (1-1/2 hours on the phone with network engineers following traffic, I think). Xfinity/Comcast folks said tentatively that it was likely router-related. So I took the advice of micro8 (above in this thread I think), went into the Advanced/Security/Log page, and un-checked the box for DoS. No problems logging in or otherwise any more. Also, maybe relevant, I set for login via https only.
Re: Trying to understand nature of "DoS attack: RST Scan" log messages
Since there’s been a little bit of recent activity on this thread, I thought you’d be interested in an update on this. I paid NETGEAR for Pro Support, talked to two different support reps on the phone, both who told me it had been escalated to NETGEAR engineers. I then posted repeatedly on my support ticket asking for status over the course of several months, and here’s how it concluded….
I never received a single update to my support ticket from NETGEAR, and I never received a single answer of any kind from NETGEAR, and after several months of silence, they closed my support ticket without comment or answer.
My conclusion after owning NETGEAR equipment for over 20 years and numerous support experiences not ending much differently:
NETGEAR routers are just that — fairly stable routers — no more, no less. The admin consoles and their mobile apps across all their routers are buggy, unstable, and poorly performing. What logging is present is woefully deficient, and as this thread attests, often inaccurate. Adequate logging for debugging or monitoring your networks is not present. I figured with the RAXE500 and integration with Bitdefender and Pro Support offering, that NETGEAR might finally up its game. I spent a good chunk of $$$ and gave it all a fair try.
Nope. My RAXE500 is now in AP mode (which disables most of its features) and just providing WiFi to part of my house. I have pfSense on a separate device managing my network (firewall, VLANs, DNS, DHCP, traffic monitoring, etc.).
I had hoped to be able to report something different, but hey, that’s NETGEAR Pro Support — charge your credit card, get your support tickets ignored for months and then closed with no answer.
