NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
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...
michaelkenward thanks for the reply.
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.
Anyway, thx again for the response.
brado77 wrote:
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.