If you're running their equipment, you may see your ISP provided modem's login page, which ideally should have whatever randomly generated password was on the sticker on the bottom of the modem when you got your service. A shade more secure than a router with default credentials.
I'd hope you don't even see that. Your ISP shouldn't be exposing that to the internet by default, either. Ideally you get connection refused or an eventual timeout.
Plenty of websites allow you to do it, although it's probably safer to grab a shell on any other host connected to the internet (could be even just your phone connected to its mobile network) and run a port scan (e.g. nmap) from there.
There are legit reasons to have a router be publicly accessible. How else would one remotely manage a router (top results in Google are businesses and universities, for example).
Since the default configuration of these routers is not to expose the router on the WAN interface, manually overriding this configuration usually demonstrates a sufficient enough understanding that the default credentials have likely also been changed.
The only real issue would be using a default password, which none of the top results shown on Google seem to have (thankfully). So, little-to-no issue here.
> There are legit reasons to have a router be publicly accessible.
No, there are not.
> How else would one remotely manage a router
Over a WireGuard connection to a secure management network.
> The only real issue would be using a default password
Uh, no. Try any number of CVEs or 0-days or unknown-until-it's too-late vulnerabilities, depending on what web daemon/frameworks are used by the router's management software.
Why is exposing a web service considered so much worse than exposing a VPN service? WireGuard is respected for low complexity and high quality, sure, but what prevents a web server from having the same characteristics? And there are plenty of VPN services whose huge public surfaces turned out to be vulnerable, why is running one of these any less crazy than running nginx?
Even if all of that is updated and secure; with the services exposed, it's less than trivial to make that service eat the small amount of memory it has to work with, and take down the network it manages.
Best practice for remote management of network devices is over a VPN or a remote access application designed for remote management, and it has been that way for decades. Web UIs on routers are designed for use on trusted networks, are notoriously full of vulnerabilities, and aren't typically hardened for exposure to the open internet. They often do not support any security features beyond a password. No fail2ban, no 2FA, no SSO, etc. Most router manufacturers will warn you against doing this for these exact reasons, even if they don't elaborate on why, and let you do otherwise.
The businesses and universities you see in the list are likely:
* a result of people hooking up rouge devices
* organizations operating without competent IT management
> Most router manufacturers will warn you against doing this for these exact reasons...
As opposed to actually solving that problem? I mean, if GMail, Jira, GitHub and GitLab all manage to provide secure web UIs, then what's the excuse of routers?
Why should the manufacturers just offload the technical complexity to the end user, as opposed to supporting something like 2FA through TOTP or an equivalent? Sure, that's not to say that any piece of software doesn't need extensive security testing, but at the very least they should attempt to establish a perimeter of sorts for their web application and use whatever popular auth mechanisms have been widely used in the industry in the last 5 years.
As for the eventual "routers don't receive updates" counterpoint: if my Debian boxes can receive unattended security updates, what makes it so that my router couldn't? If lots of self-hosted software like GitLab is relatively secure, what's to prevent routers from receiving a similar treatment and attention?
Personally, i'm just writing this to bring the odd juxtaposition to light - that things we oftentimes take for granted in regards to typical web apps are somehow not only not often implemented but also are unthinkable for some reason when it comes to devices like routers. I don't believe that this is a good thing and some sort of a convergence should happen sooner or later - GNU/Linux or BSD based router software that all of the vendors could adopt and, ideally, an open source web UI alongside mechanisms to keep it up to date automatically.
Of course, for some odd business reasons, that's unlikely to happen. Looking at the current state of routers, i find it extremely odd that every vendor has their own piece of software that's so different from the others out there, even down to many of the terms that are used to configure the operation modes etc. Yet, when we want to purchase a personal computer, we don't buy one with DellOS or HP-OS or what have you...
Are VPN's, secondary networks, etc reasonable to expect for a $100 MSRP device targeted at consumers? I think not...
Given what it is... it's as secure as it can be. Short of a 0-Day lurking somewhere, or an active CVE, the configuration is fine. Not to mention all the top results appear to be operated by organizations that certainly know what they are doing.
then yeah, you are definitely the type who should be also able to put a VPN to properly manage it. I don't really get your defense of this practice. It is bad and risky, and there are no good reasons to expect it to be a sane config for a router.
manually overriding this configuration usually demonstrates a sufficient enough understanding that the default credentials have likely also been changed
I don't think that's a reasonable assumption at all -- the router should ensure that the admin cred has been set to a (reasonably secure) password. Just because someone read on a web page that they should enable remote admin doesn't mean that they understand the risk.
And it should warn that exposing the admin interface to the internet may make the router more vulnerable to remote exploits - basically the same type warning that browsers show for a bad SSL cert should be shown for insecure router configs - tell the user that it's insecure and is a really bad idea before they do it.
1. Open the web browser and in the address bar type in:
http://192.168.1.1
2. Type the username and password in the login page. They are both admin by default.
3. Click Security->Remote Management on the left side
4. To enable this function, please change the Remote Management IP address from 0.0.0.0 to a specific authorized remote IP address.
Here's the warning they give at the bottom of the manual:
Few people read the entire manual, if they read it at all, they read enough to do what they want, and fewer still know what "Use this with caution" means. I don't even know what it means. I typed 255.255.255.255 carefully, is that sufficient caution?
Type 255.255.255.255 Remote Management IP Address means that you can connect to the router remotely from anywhere via Internet, this is not recommended and please use it with caution
We suggest changing the default log in Username and Password if the Remote Management feature is enabled, especially if you typed 255.255.255.255 as the Remote Management IP address.
That link isn't from the routers this post links to (specifically Archer C7 and C9 routers).
And, your link is old, to say the least. That screenshot is from the Windows XP era.
You're trying to lampoon TP-Link for things that simply are not true anymore, nor have been for a long while.
I'll repeat again - the defaults on these routers is to prohibit WAN access and they force a password change at setup. What more are you complaining about?
> Step 2 forces the default password to be changed. There is no way around that step.
Sure, and you can change that password to "foobar" or whatever bad password you want. And I bet that login page doesn't have any rate limiting or a lockout after too many failed logins.
Fortunately, though, I don't think there are any of these that enable remote admin by default, so the owner would need to do that explicitly. Hopefully they've paired that with a strong password. Even then, I still wouldn't advise anyone actually doing this...
(Your manual link is broken; it takes me to a page that just links to TP-Links main marketing website.)
Every single remote site we have is managed via a VPN connection. The VPN endpoints are mostly the site's firewall but you could just as easily manage the router from a TeamViewer (LOL) connection into a system behind it.
> The only real issue would be using a default password, which none of the top results shown on Google seem to have (thankfully). So, little-to-no issue here.
You might want to think twice about attempting to log in to a system you weren't authorized to use. That's illegal in most jurisdictions.