What's new

New Threats to Asus Routers, few details.

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Indeed I did

To be abundantly clear since this is very important and you at one point said it was disabled, then said it was enabled:

Under Administration - System this is what you want

Note for the first one (SSH) you can also set it to "No". Just not LAN+WAN

If you had WAN access enabled for any period of time, personally I'd be doing a hard factory reset, update firmware with a clean, known good image, then hard factory reset again and reconfigure by hand, ensuring these are disabled (which they are by default). But if you look at the logs and running processes and don't see anything suspicious, you're "probably" ok - but is it worth the risk?

Even with these both disabled, use a non-obvious user name and strong password.


1685253276296.png
 
When using the Asus app, if you rush through the setup it’s easy to click the default enable WAN access. I am sure this is by design so you can use the app without using a vpn back into the router.

Bad idea….. :)
 
Small detour on this thread since it could be related ... Am I correct in thinking that "Enable Access Restrictions" = No is the safest (most restrictive) setting for this option? The option name almost makes you think 'no' is a bad answer.

1685281384812.png
 
Small detour on this thread since it could be related ... Am I correct in thinking that "Enable Access Restrictions" = No is the safest (most restrictive) setting for this option? The option name almost makes you think 'no' is a bad answer.

View attachment 50461

"No" is the least restrictive. It means any IP can hit the remote management (if enabled).
 
When using the Asus app, if you rush through the setup it’s easy to click the default enable WAN access. I am sure this is by design so you can use the app without using a vpn back into the router.

Bad idea….. :)

Yet another reason not to use the app.
 
"No" is the least restrictive. It means any IP can hit the remote management (if enabled).
Right, but if you don't have any remote management allowed, then I just want to make sure it is not allowing something that I am not aware of.

I wonder how well ASUS actually tests all of these on/off/remote/LAN combinations so that us peon consumers can have confidence that the router is doing what we told it to do.
 
I wonder how well ASUS actually tests

Repetitive Asuswrt issues and introduction of new ones with every firmware tells me the testing process is not very extensive. There are features broken for years, multiple copy/paste bugs from different firmware or models, things no one pays attention to. I recently had to fix some routers affected by ASD update bug and noticed Privacy page in GUI with copy/paste about AiProtection, Traffic Analyzer, etc... on a router that doesn't have any user configurable TrendMicro services. This entire GUI page is unrelated to the model, but still there.
 
To be abundantly clear since this is very important and you at one point said it was disabled, then said it was enabled:

Under Administration - System this is what you want

Note for the first one (SSH) you can also set it to "No". Just not LAN+WAN

If you had WAN access enabled for any period of time, personally I'd be doing a hard factory reset, update firmware with a clean, known good image, then hard factory reset again and reconfigure by hand, ensuring these are disabled (which they are by default). But if you look at the logs and running processes and don't see anything suspicious, you're "probably" ok - but is it worth the risk?

Even with these both disabled, use a non-obvious user name and strong password.


View attachment 50453
Thanks and yes after reviewing these are my settings
 
Right, but if you don't have any remote management allowed, then I just want to make sure it is not allowing something that I am not aware of.

I wonder how well ASUS actually tests all of these on/off/remote/LAN combinations so that us peon consumers can have confidence that the router is doing what we told it to do.

In theory, disabling all remote access and putting something like "10.0.0.1" there (something that would never hit it from the internet) could make it even more secure. In practice, would have to review the firewall rules, it might actually enable remote access if you do that. Having it disabled is what you really need, that's the important part (along with a strong password).
 
Which TBH is much more important than a custom port. As far as I know these routers do not block WAN port scans so easy enough to find what it is listening on.

A few years ago, I wanted to experiment and set up authorized keys (which I have been running for years). Doing a search back then on snbforums there wasn't enough specific information on how to do this.

Several forum members were kind enough to offer leads that helped me to understand how to do this with my asus router/SSH.
 
 
... and using passwordless login with authorized keys.
I'm actually surprised I haven't seen something already in his thread calling out if you really need external connectivity then VPN with certificate based authentication is the way forward rather than basic ssh/https.

It never ceases to amaze me that people expose basic user/password for this.
 
I'm actually surprised I haven't seen something already in his thread calling out if you really need external connectivity then VPN with certificate based authentication is the way forward rather than basic ssh/https.

It never ceases to amaze me that people expose basic user/password for this.

Ssh daemon with private key and VPN with private key have pretty much the same attack surface - both are open source and both are not immune to vulnerabilities. In fact, if someone gets into your VPN they gain a lot more access than if they get into your router, at least initially (they could launch their own VPN once in your router).
 
Ssh daemon with private key and VPN with private key have pretty much the same attack surface - both are open source and both are not immune to vulnerabilities. In fact, if someone gets into your VPN they gain a lot more access than if they get into your router, at least initially (they could launch their own VPN once in your router).

I'll add a couple of things...

SSH/HTTPS are TCP based - so fast/easy to scan, even if on non-standard ports.

Inbound OpenVPN or Wireguard - WG is UDP, and OpenVPN can be configured as such, UDP scans take forever as they don't respond at the UDP layer, but depend on the application to respond.

VPN connections - VPN's go both ways - most folks use the commercial servers for outbound connectivity, mostly to geo-unlock traffic - but once that trust relationship is established - inbound routing can be a significant risk.

If one is using VPN to access internal resources, and using a commercial service provider to do so - that means anyone inside that provider has the opportunity to do so as well - they just need to be logged into the same provider, and a misconfigured policy or two on their end -

well...

Game over bud...
 
Ssh daemon with private key and VPN with private key have pretty much the same attack surface - both are open source and both are not immune to vulnerabilities. In fact, if someone gets into your VPN they gain a lot more access than if they get into your router, at least initially (they could launch their own VPN once in your router).

Don't disagree on the attack surface and open source risk when it comes to vulnerabilities.

Per device signed certificates given more control than keys though - albeit the limits of the ASUS routers meaning you can't necessarily revoke a single certificate. MFA based connections would be better but consumer grade gear and all that...

If one is using VPN to access internal resources, and using a commercial service provider to do so - that means anyone inside that provider has the opportunity to do so as well - they just need to be logged into the same provider, and a misconfigured policy or two on their end -

well...

Game over bud...

I was going to say something along the lines of why would someone try that but the more I thought about it, the more I realised that there are a large number of people who pay for commercial VPNs thinking it makes them invisible with ultimate privacy and that a % would definitely try it not realising the irony.
 
Repetitive Asuswrt issues and introduction of new ones with every firmware tells me the testing process is not very extensive. There are features broken for years, multiple copy/paste bugs from different firmware or models, things no one pays attention to.

Clone the AsusWRT-NG code base from the @RMerlin github repo - you'll be amazed at the complexity of the codebase - recall that this has many years of legacy going all the way back to Linksys via Tomato and Shibby.

And it's not just a skin job, they have added so much extra functionality from the old baselines..

Asus support multiple versions of chipset vendor SDK's - Eric's is obvious Broadcom focused, but digging thru the code, you'll find references to other non-Broadcom SDK's, esp in the WebUI functions...

I recently dived into that code base looking to perhaps address a concern I've found over in WL_2G where certain UI configs can break wifi for non-Windows devices - making changes there are, for lack of a better word, daunting, as any change that touches the WL drivers has to be extensively tested, not just for the specific change, but everything else that WebUI, the Mobile App, and AImesh can change.

Not that I'm complaining - on the contrary, just shedding some light on something that many folks won't necessarily grasp unless one actively works on that codebase.

It is complex enough now that only a few people could possibly understand everything inside - and it's probably close to the point where starting fresh is going to be less expensive than maintaining the existing software.
 
Similar threads

Similar threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top