To the reader: if this is your first exposure to finding things that aren't supposed to be exposed to the internet and you're finding it interesting enough to want to learn more, there's a tool commonly used among security practitioners called Shodan that enables a much more tunable search for exposed assets.
It's also a super basic intro to proper google-fu (which you can google to find others' takes on how to become somewhat effective at, erm, googling). Back when I used to blog on Microsoft-related topics, it was common to construct extremely narrow queries to find exposed confidential documents in Skydrive accounts which we could then sift through to find bloggable material.
e.g site:[skydrive domain] filetype:.pptx "Microsoft Confidential" etc.
And we don't concentrate on a single type of device/ service (the article mentions SCADA). We identify everything from industrial control systems (1) to Minecraft servers (2). The news coverage makes it sound like we're skewed towards ICS, webcams or vulnerabilities but our focus is on providing a comprehensive view of what's connected to the Internet.
If you want to quickly check if your IP is exposing anything unexpected to the Internet simply visit:
Entirely unrelated fun fact: my love for your service started a good number of years ago when you worked with me directly on a specific challenge (subject: "Any way to pay for shodan without Paypal?"). Glad to see the service is continuing to thrive! And that you're engaged in conversation/feedback on HN.
That's not how it works. Shodan continuously checks all IPs on the Internet. When you visit the website you're checking for existing information in the database. Your use of the Shodan website/ API doesn't change how Shodan crawls the Internet.
It doesn't matter. We check every IPv4 regardless. And for our regular crawling we don't ping before we try to connect as a lot of firewalls block ICMP.
It looks like it just redirects to https://www.shodan.io/host/<IP>, so you should be able to just plug your server's IP in instead in your regular browser.
Conflict of interest is totally separate from the reliability of sources issue. I think the thing that would be encouraged in this situation is to detail what you would want changed on the talk page, and have a neutral wikipedian look at it and make the changes if appropriate. See also https://en.wikipedia.org/wiki/Wikipedia:Plain_and_simple_con...
Was about to reply with this exact sentiment. If the page is about you or your service, propose the updates in the talk page (ideally with reliable third-party sources).
I've definitely seen posts by community managers used as reference for some gaming-related articles, which I assume would fit under "Self-published or questionable sources as sources on themselves."
But, of course, none of those posts specifically targeted their Wikipedia articles.
> I wonder if you could use a forum post of someone saying what's wrong on their page as a source to edit the page though.
You could. The person themselves couldn't. (There are guidelines about the risk of bias from primary sources, which apply very much to someone talking about themselves or their own company, so you shouldn't just blindly copy what they say into Wikipedia, but you absolutely can use them as a source)
Off-topic: this discussion reminds me a bit of what happened about five years ago when I offered to host a reddit AMA about anesthesia and anesthesiology and related subjects (I was board-certified in 1980).
The moderator asked me for proof that I was who I was, so I had to spend a couple days digging through my files to find my medical school diploma, board-certification document, medical licenses, etc., then scan and email them to reddit.
I did all that, and they said it wasn't sufficient proof: I needed to take a selfie with the documents and my driver's license to "prove" my bona fides.
fyi, "for official use only" or "fouo" is a slightly more than meaningless designation to shield stuff against FOIA inquiries. most of the stuff you'll find is pretty boring.
a little more: https://en.wikipedia.org/wiki/For_Official_Use_Only#United_S...
I worked for a government lab some time ago, and FOUO wasn't used to shield against FOIA. Indeed, OUO documents can be released to a FOIA request. It was more or less just the default because no one wants to get in trouble for not making things that are supposed to be marked.
What I've seen used as a shield against FOIA is the label, "DRAFT - For Discussion Purposes Only." This is meant to ivoke the "deliberative process" exemption.
+1. I don't think I ever saw a document marked UNCLASSIFIED// that was not marked UNCLASSIFIED//FOUO. I'm not convinced that there is such a thing as a document that should be marked unclassified that should not also be marked FOUO.
I'd imagine you could generalize that observation to any intentionally published work of the government. That's also my understanding of FOUO from when I needed to know: the agency I worked with thought of it as a magic word for "not meant for release" (in spirit, not legality).
Note that Shodan doesn't try to login using default credentials. If you see banners advertising their defaults it just means that the device is telling you what its defaults are - it doesn't mean that the device is still using them.
That being said, a ton of devices still use default credentials but we don't have any numbers on how many exactly.
I wasn't implying Shodan did this.
Shodan just lets you find things. Google reveals default passwords quite readily though. It's alarming how often they work to login.
On Konica-Minolta printers the password is almost always the same. My school IT admin explained that they're pretty much always rented or "bought" with a mandatory support contract and the contractors get really annoyed when the admin password isn't the default one, since it's supposed to be "their" password.
Not that I didn't know about its existence, but I just entered the IP of my VPS and noticed that Portainer was bound to 0.0.0.0... I thought I had it bound to the docker bridge so now I've got to put in some time to see if all is ok.
You can create a long complicated link to share with other people, even people without Skydrive/OneDrive/Dropbox/Google Drive accounts. But sometimes people publish these links somewhere where a search engine's crawler sees it and follow it.
I remember spotting someone's URL to a Google Doc on their screen which their camera caught in their YouTube video. I manually typed it into my browser's URL bar and voila, I could read that document. Nothing juicy though.
Step 2 of first time setup forces a default password change. There is no way around this step.
The defaults for the router also do not allow router access from the WAN port.
This means:
1) These routers all have secured passwords that are non-default.
2) These routers were deliberately placed on the internet by people that knew enough about them to do so.
Just because it's not how you would configure your router doesn't make it wrong. There are legit reasons to place a router on the internet, so long as it's secured properly... how else would you remotely manage a router at a different physical location, for instance.
__Lastly__ click "Next Page" on the OP search results. The estimated 7,000+ results becomes 21. Many of which are HN aggregators reporting on this thread here.
So... out of the possible millions of routers TP-Link has sold in this model line, less than 21 are on the public internet - many of which no longer load via IP address (indicating they are no longer publicly accessible), and the rest have professional CNAME's attached, indicating professional management.
> Folks - these routers are secure. There is nothing to see here, move along.
If experience is any guide, they are not.
Consumer routers have horrible track of embarrassing, easily exploitable vulnerabilities. That are not patched for a long time or ever.
And exposing your router to public like that suggests the owner knows very little about security. This typically goes in hand with other neglect. Tell me, how many home users that are not security conscious keep their routers regularly patched and will replace the router when the manufacturer stops supporting them?
Buy something well supported by OpenWRT; that typically correlates to at least OK hardware that is known to work well enough. Ideally you'd also install OpenWRT on it, or another choice of OSS rather than factory firmware.
Funny enough, I recently purchased one of the latest TP-Link Archer 5400x (AX73) routers. Ended up not needing it, so I opened it up and connected via UART.
Once you log in it appears to be running a version of OpenWRT, although they don't specify that on their website.
Is it too much to ask to have competently built hardware with competent software for a reasonable price enabled by mass production?
I mean, just don't make stupid things like open access to it from a single point of failure where a single engineer can loose their AWS key and enable attackers to access million networks?
Or build devices that overheat placed on an open shelf in home office in truly unreasonably hot Polish climate?
It depends on your experience. For me it didn't require much time at all. You might also consider it a valuable learning experience so worth making the time. I would highly recommend being on top of your own home network as you really never know when networking skills will come in handy.
I have some ops experience but that was 20 years ago. Nowadays if I need to do something like that I have to do a bunch of research and spend a lot of time on it. Which I would prefer spending, for example, with my son teaching him programming.
I can sympathize with people that don't have technical background -- these are practically defenseless.
I'm willing to invest time once to get something better working. I'm not willing to invest time on an on-going basis to keep my router secure. My normal router is a !@#$%, but the company does push out security updates.
Most of the DIY projects I've seen require me to do it manually.
Yeah, I love the older Ubiquiti stuff (Edgerouter) and the Unifi access points, but all their new routers (like the UNMS ones) seem to require cloud hook-in which I really don't want.
When the EdgeRouter-4 I have dies, I suspect I'm going to need to find a new hardware brand, this time preferably running OpenWRT. Potentially it could get to the point where I'll have to look for an ARM based server with low enough power usage and a few independent network interfaces and just run pfSense or VyOS or something...
Yeah, I’ve used Microtik gear, and I never liked their software. I hear the performance has improved a lot though (that was a big selling point of the Ubiquiti gear when I got into it with their hardware acceleration).
I expect I will eventually move to embedded server hardware (even maybe Xeon-D) on a machine running vSphere or something with a router VM and other VMs for stuff I want to run. Just have a few separate NICs and pair it with a separate managed switch (which I already have anyway).
I've had good experience as a basic home user with Fritzboxes. I can't vouch for them in terms of security or unusual and fun uses that people here may have for their home network though.
Owner of a C7 v4 here. There has not been a firmware update from TP-Link since December 2019 (note that v4 is the second-most recent HW revision). No way these are not affected by at least some CVE somewhere in their stack. Calling them secure is a leap of faith that TP-Link does not deserve.
I recently flashed openwrt exactly to be able to be on a more recent stack.
I would never dream exposing that UI to the Internet as-is. They don't even have any form of brute forcing protection. If they really needed access to the router remotely, it would be much saner to expose an SSH server with pubkey-only access or VPN, both with brute forcing protection, and allow tunnelling to the router UI only from the LAN side.
Either who set those up really has nothing to lose if they get owned, or they do not know what they are doing. In both cases, it does not qualify as being a secure setup. (Sure, they may also be honeypots - in which case your argument was incorrect anyway, as they are secure, but they are not routers)
Same model, but the interface showed build 20180316 as "up to date", and when I've tried manually downloading the 2019 build it showed "invalid type". Swapped it with DD-wrt not long ago (DD-wrt support was why I've decided on this model, but I was too lazy to do that before).
> If they really needed access to the router remotely, it would be much saner to expose an SSH server with pubkey-only access or VPN, both with brute forcing protection, and allow tunnelling to the router UI only from the LAN side.
> it would be much saner to expose an SSH server with pubkey-only access or VPN
It would be safer to leave open to the public only a secure protocol based on strong cryptographic keys instead of a password. Or you have to be signed in to a VPN to see the page.
> brute forcing protection
Try too many passwords? Try again in 1 minute. Again? 30 minutes
> allow tunnelling to the router UI only from the LAN side
I think this one means don't expose it to the internet at all. Just from your local network.
>
Exposing your router's admin page to the internet is not good security practice. These routers are protected by nothing but a password, and I couldn't see anything in the manual that enforces password length/complexity. So while the password might be non-default, it could still be incredibly insecure.
Also, to expose these routers to the internet, all it takes is a single checkbox to enable "Remote management". So your assumption that these have all been deliberately placed on the internet also doesn't hold up because I can definitely see a curious home user playing with these settings without realising the impact of this. There have been tons of similar reports in the past where home users have exposed things to the internet without realising the impact.
> The estimated 7,000+ results becomes 21. Many of which are HN aggregators reporting on this thread here.
Nope, Google is just collapsing them because they are all identical copies of the same "page", being the same login screen. Most of them look like routers, you can ask Google to "include" them all and see for yourself. https://www.google.com/search?q=%22Please+log+in+with+router...
Disagree. In my current country of living, I'm not even sure how I'd properly expose the router I use to the public internet since I sit behind the ISP's NAT-ing, and even when I lived in the US, I am not confident I could tell you how to publicly expose the modem provided by Comcast for non-local access, much less how someone without any tech experience might do this.
If this was a prevalent problem because of default settings, I'd expect far more than 7800 results; I am not willing to concede every instance is intentional, but 7800 out of the billions of routing devices in the world showing up on this search enforces my understanding that these 7800 entries are special in some way.
>I doubt there's MFA or even rate limiting.
MFA is not common at all on consumer routers, which at least quite a few on the first page result are, same with rate limiting.
Even for Enterprise grade gear, the threat isn't the user-defined password, it's the manufacturer backdoors, which we've seen many of in the last few years. Rate limiting doesn't do much if you have a fair chance that you've got a back door.
What likely __does__ help is that as far as I know, "Enable Web Access from WAN" is by default *disabled* on most consumer routers (and enterprise? that I'm not sure of), so I think that this leads credence to the devices on the Google results being exposed intentionally to some degree. (The owners' knowledge level not withstanding, this is a fairly out of the way setting, at least on my Asus router)
> I am not confident I could tell you how to publicly expose the modem provided by Comcast for non-local access
You likely couldn't. That setting is usually gated behind some sort of "technician" or "mso" account (or not present, or only accessible from the devices telnet/ssh interface). Of course, it's probably not difficult to guess Comcast's password; past experience with other companies suggests you try things like "comcast" or "C0mc4s7". (Not even joking, Suddenlink and Spectrum/TWC.)
> much less how someone without any tech experience might do this.
Easy. It's a button that their kid clicked while playing around.
> MFA is not common at all on consumer routers, which at least quite a few on the first page result are, same with rate limiting.
Are you trying to say that's a positive for exposing it on the internet...?
> but 7800 out of the billions of routing devices in the world showing
Click "Next Page" - estimated results turns into 21 results in total... of which a bunch are dead links, a bunch are HN aggregators... leaving just a small handful of actual devices on the internet.
These are not high end enterprise grade kit, folks. Expecting things like MFA, secondary VPN endpoints, etc is just absurd for the target audience of this device.
Again, just because you wouldn't configure it this way doesn't make it wrong. It's as secure as it can be, short of throwing a bunch of other kit in front of it, and then why would you be using a $100 consumer router anyway?
The only vulnerability here is the possibility of a 0-Day. Everything else is either misguided or screaming for the sake of it.
> That's not exactly uncommon in cheap consumer routers.
That's, in my opinion, the only fair criticism available here.
> No rate limiting is as good as no authentication.
Trying to even load some of the links found in Google takes 10's of seconds. That's effectively a rate limit, even if it doesn't temp-ban per IP address.
Someone would have to dump the firmware to find out, but it would be trivial for each device to generate their own salt - making a potential lack of rate limit a non-issue.
> Someone would have to dump the firmware to find out, but it would be trivial for each device to generate their own salt - making a potential lack of rate limit a non-issue.
Salting does nothing to protect against bruteforce attacks, which are what rate limiting defends against. Salting is done to protect passwords in the event the password data is stolen.
The load times are most likely primarily caused either by slow JS or high RTT/multiple requests, either of which could be trivially bypassed by an attacker. Or an attacker could just fire off 100 requests at the same time and saturate the bandwidth anyway, despite a high latency. And any high latency would likely be significantly lower if you happen to be in the same geographic area.
I'm a big fan of rate limiting (and even rate limit my static pages) but if your password is secure enough, the lack of a rate limit isn't going to help attackers.
I kind of agree with the comment that started this thread -- people that have explicitly decided to expose their consumer-grade routers directly to the Internet probably know about password managers. Even if you do guess the password and compromise the router, all you'll have is some remote office that is getting TLS errors because of your MITM, and best case control of some unpatched Windows 3.1 machine and maybe some developer's local MySQL install happily listening on port 3306 somewhere. That's not great, but it's a risk that some people are willing to take.
> maybe some developer's local MySQL install happily listening on port 3306 somewhere.
And usually with default password because not on the internet. People often forget or underestimate lateral movement and metasploit reverse shell kits.
> The only vulnerability here is the possibility of a 0-Day.
You do realize that the last security update for these routers was in 2019, right? So by zero day, you mean something more like 700 day? Yeah, no way anyone could've discovered a system takeover in the last 2 years, when up against the security prowess of... TPLink?
I think it might be a good idea to edit your original comment, you'll save some face.
> 1) These routers all have secured passwords that are non-default.
Who said secure password? Yes, they are not the default, but people are terrible at choosing password, most will choose weak password that are easy to exploit with a dictionary attack.
> 2) These routers were deliberately placed on the internet by people that knew enough about them to do so.
A people that know what it's doing would never expose a router web interface on the internet. Most people doesn't know how to configure his router, and let the ISP technician configure it, and they probably expose the router interface so they can access it remotely for maintenance, but it's not a great idea...
> There are legit reasons to place a router on the internet, so long as it's secured properly...
There aren't. Also you can choose a secure password, but these router interfaces are full of bugs, and highly exploitable. Add to this the fact that the manufacturer rarely updates the firmware of these devices...
> how else would you remotely manage a router at a different physical location, for instance.
With a VPN? By creating an SSH tunnel to one machine inside the local network? By connecting remotely (via RDP, VNC, TeamViewr, whatever) to one PC inside the local network? There are a ton of better solutions.
Also if you don't have a static public IP address, as it's in most situations nowadays, how do you access it remotely anyway? With dynamic DNS but it's not reliable. The best solution to me is using a VPN (I can connect to my home network from anywhere in the world and access all the hosts, including router and other networking equipment of course).
> These routers all have secured passwords that are non-default.
Secure passwords is just a tiny subset of non-default passwords. Chances of an average human being being able to come up with a password with enough entropy to be called as secure is pretty low.
> These routers were deliberately placed on the internet by people that knew enough about them to do so.
This means these people knows how to expose the management interface to the internet. It does not mean these people have enough knowledge on securing their devices -- based on their actions, it is more likely that the opposite is true.
So you think the chance of human beings to come up with 4 random words is pretty low?
You can't brute force millions of guesses per second through a web interface. 40 bits of entropy is already plenty for internet usage especially when the password is properly hashed with something like bcrypt.
> Secure passwords is just a tiny subset of non-default passwords
Actually the exact opposite is true. Since only low entropy and publicly known (which are mostly low entropy) passwords are insecure there are much more secure than non secure passwords.
For the sake of argument, let's say all passwords with less than 40 bits of entropy are insecure. Even if we restrict the set of possible passwords to only 10 characters of lowercase a-z we have about 47 bits of entropy. So the set of insecure passwords would only be about 1/128 or less than 1% of all allowed passwords.
> > Secure passwords is just a tiny subset of non-default passwords
> Actually the exact opposite is true. Since only low entropy and publicly known (which are mostly low entropy) passwords are insecure there are much more secure than non secure passwords.
You're confusing "passwords that are in use" with the set "passwords that are possible". We have data via password dumps that suggests of the "passwords that are in use" the set that qualifies as "secure" is indeed a tiny subset of passwords.
Well, real people won't choose any random 10 characters as a CSPRNG would do. Even when picking words from a dictionary, instead of four words, most people would probably just use one (or maybe two). For those are more inclined, they might mess with the capitalisation and sprinkle some numbers to make it "more secure" and adhere to certain password policies. This does not really contribute to the odds as you might expect.
Anyway, the point is, people are terrible at generating (and remembering) secure passwords. By ruling out the default password just means it is not going to be the most insecure one, but the chances of the custom password being secure is still pretty low.
I think most of this comes down to bad education on how to choose a secure password and not an innate inability. And for the most part we software engineers are at fault for advocating and enforcing mostly useless policies for more than two decates.
I would love for more websites to implement something like the zxcvbn password strength meter [1], but unfortunately I keep seeing new services or recently refreshed ones using outdated and hurtful policies like requiring numbers and special characters.
>So you think the chance of human beings to come up with 4 random words is pretty low?
I've always wondered how effective the random words thing is. sure, there are like 100k english words in current use according to google, but it seems like a list of the most common few hundred of those words would crack a lot of passwords.
If you assume the password to be only based on the 200 most common words you already have 30.5 bits of entropy to brute force or 1.6 billion guesses and you're assuming your attacker knows you're using this password strategy. The Wikipedia entry on Basic English [1] suggests there are about 850 core words for daily life and I could immediately think of simple words like well-known animals you would see in the zoo that are not included. So how many of these "4 words that you could draw as a picture"-passwords actually fall into even the most common 850 words?
30 bits of entropy isn't particularly secure against locally cracking a password hashed with sha256 or a similar non password hash. However at 1000 guesses per second it would already take 28 days to brute-force and 1000 guesses per second is pretty fast against any password stored with a properly configured password hash like bcrypt.
I personally auto-generate readable passwords for most websites at ~70 entropy pure brute-force and ~50 entropy if my algorithm and set of inputs would be exposed.
You also need to be aware that in this case, the attacker is/would not targeting any specific device. For brute forcing, all it takes is a dictionary of most common passwords and a list of devices that are exposed. Attackers won't spend too much time on any single device as there are so many options out there.
OP. I'm posting this because I discovered a box at the hostel I'm at on Google after fat fingering the IP by mistake. (It's disconnected already.) The password was easily guessable.
Aside from the anecdata, a counter argument is that the router manufacturer has taken no steps to obscure the routers from search engines. Sure someone could simply IP scan, but you have to admit this is a little absurd.
not every tp-link model (or revision, or locale, or firmware version) that shares a web interface with the c7 requires you to manually set a password. even if that were the case, there are bound to be users who aren't security savvy and chose a very weak password (e.g. "password", "admin").
many tp-link routers also have configurable vpn servers built in, which can open up the whole network to malicious actors.
There are significantly more than 21 results listed on Google. Google automatically hides what it considers "duplicate results". There's an option to "repeat the search with the omitted results included" on page 2, which reveals all of the 7,000+ results, of which the vast majority are different routers.
There is a lot here. Some of these are university routers. Tells me that the sysadmin wanted to open up the router so s/he can manage from home. Nifty. But not secure. And they are no way taking the extra effort to make their system secure.
The sensible way to secure it would be to have a device behind the router, in an isolated network which is the only network/device allowed to access the management interface. Then you tunnel/vpn/wire guard into that device.
I know what I'm doing. I would be fine with this in some circumstances. There are legitimate reasons adding a VPN to a backdoor like this can make it worse. The trick to "knowing what you are doing" in this case is defense in depth and knowing what's actually accessible from a world-open interface, and how much of that would be really annoying to get to while simultaneously fixing your homebrew VPN that fell over six months ago and that you never got around to fixing.
Most routers are perfectly fine with a limited set of knobs accessible to the public Internet behind reasonably secure access ports. Bastion it behind SSH and/or SOCKS if you're paranoid, but seriously, as long as we're not talking a $50 Target 'router', it's probably fine. My Ubiquiti gear is indexed. It also reliably e-mails me when it successfully authenticates a user and can distinguish between inside and outside access to ACL what it can do.
Just saying, easy with the "if you know what you're doing" thing, because opinions differ (particularly with beyondcorp in an IT setting). Gluing a VPN back together through an SSH tunnel so you can get at the "fail over to my DSL connection" button inside your network is a really crappy deal at 3 a.m. with a few beers in you and 200ms in between.
> I would be fine with this in some circumstances.
Maybe it’s just a matter of difference of criteria, but I would certainly not be fine with this. You have a lot of ways to prevent this from happening, and it only opens an attack surface to APTs.
Being indexed means being searchable, being searchable means exposing yourself to automated targeted attacks.
I just checked if my router's admin was open to public access by connecting with my public IP. It connected! Oh no! That's embarrassing, I thought. Turns out it was just NAT hairpinning. I can't connect from my mobile network.
Some of these routers can be crazy insecure. Just some fun from my own experience: before I got mine switched into bridge mode by my ISP I managed to disable the wifi on it despite the ISP blocking that functionality. How? By removing the disabled attribute from the select element via the devtools. I also know a friend who found his password in plaintext in a script tag in his router’s login page. I understand that nothing is absolutely secure but this is just tempting fate.
There are thousands of TP-LINK routers whose WAN port 80/443 is exposed to the Internet, allowing access to their administration interface if you know the password (or a vulnerability is present).
And I'd bet a nice amount that most of them have the default passwords.
Some years ago I wrote a little tool to iterate all of an ISP's ip addresses and around 90% were using default passwords. Mostly homes, but some businesses.
I was planning to host a simple website on my RasberryPi using Dynamic DNS - which I think requires me to expose port 80 to the internet. Is that safe?
It's as safe as whatever software stack you'd be using on the Raspberry Pi to serve the site, same as if you'd be hosting it on a VPS in someone's cloud (though in your case if there's a vulnerability of a particular kind, someone could gain access to your local network).
Since you're not hosting the site on the router itself, presumably you're forwarding port 80 from the router to the Raspberry Pi, so unless the security of the Pi ends up being broken, the router should be safe.
(Also I'd recommend using Let's Encrypt to get an automatically-renewing TLS cert so you can serve https on port 443 as well, and even redirect port 80 to it. It's not that difficult to set up, and you'll be improving the privacy and security of those who visit your site.)
I was considering self hosting at home. If the local network should be disconnected IMHO only a DMZ will help. My router doesn't support that so the setup will be:
If it's a static site? Probably safe-ish, I suppose bots and bored teens could DDOS it. You could also choose a non-standard port, that might cut down on the noise.
It depends entirely on what technologies you are specifically exposing. If you are serving a page with a web server application like Nginx or Apache, you should read about securing those applications. If you are writing a NodeJS application, you should read something specific to that.
Please don't do that. It's a terrible idea because CloudFlare will then get to decide who gets to see your website or not (and CloudFlare hates privacy tech like Tor), and also because then CloudFlare will terminate the HTTPS (TLS) connection on their side so they essentially get to know all your passwords.
I've selfhosted on 64Kbit/s modem then xDSL for years without a problem (apart from bots trying default passwords). If you are really afraid you'll run into DDOS attacks and whatnot, consider using a small 2-5$/mo VPS as reverse-proxy instead of CloudFlare to retain control of your infrastructure.
> I was planning to host a simple website on my RasberryPi using Dynamic DNS - which I think requires me to expose port 80 to the internet. Is that safe?
It's a demonstration of google dorking. Construct a google search term that returns attackable hosts.
Skip past the first few results, then you'll see a list of likely easily-hackable home routers. If you were to try user/pass combos like "admin"/"admin" on these results I bet you'd have successful logins on several of them.
Don't actually do this (seriously, the penalties aren't light), the demonstration of the search results is enough to make the point.
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?
I would (and do) place more trust in a battle-hardened VPN than a router web interface that's designed for local access.
Additionally, Wireguard (to pick a favourite) listens for connections on a specific port, and only opens a tunnel if it's presented with the correct string, otherwise it's completely silent, an attacker wouldn't even know it was there. These routers are presenting a full web server and the web UI to an attacker.
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?
OK so what? Nothing you've stated here applies to the original post. You're fabricating some outrage about nothing relevant. The original post shows Archer C7 and C9 routers...
What original post? It was a google search that reveals some router's remote admin page, that search doesn't mention any specific router brand or model.
But regardless, I was responding specifically to your comment:
manually overriding this configuration usually demonstrates a sufficient enough understanding that the default credentials have likely also been changed
(That's why I quoted it in my reply)
And the point I was trying to make is that merely being able to override the default remote admin setting does not ensure that the user has any idea what the ramifications are. I'm surprised you're even arguing against that.
> What original post? It was a google search that reveals some router's remote admin page, that search doesn't mention any specific router brand or model.
It does, click any of the links. The specific search string OP used returns only C6, C7 and C9 routers (I clicked through 2 pages of results).
You saw TP-Link and went off about things that were valid to complain about in the past... but are not specifically with these routers, and probably no new model TP-Link or any sane manufacturer is turning out today.
> And the point I was trying to make is that merely being able to override the default remote admin setting does not ensure that the user has any idea what the ramifications are
Again, if you actually clicked through the OP, you'd notice most of the bare IP address results are dead (meaning they are no longer on the internet), and the ones with CNAME's attached appear to be professionally managed. The assumption is sound.
> 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.
Welcome to your Password Manager. Manage your saved passwords in Android or Chrome. They're securely stored in your Google Account and available across all website .
That is such an easy fix. I can't believe this is not the default on all devices with an HTTP server. Of course this wouldn't stop attacks or even entire-internet scans (does Shodan respect that?) but would make discovery way harder.
Brb going through all software I ever wrote looking whether they could benefit from this too.
I've done something similar once to find Dell iDRAC [0] and Exchange Outlook Web App [1] instances open to the internet. Just goes to show how forgetting a simple robots.txt (if it's even an option) can expose something you don't want, even if it's password protected.
You can set up a VPN and connect directly to their network. You can put one of their computers into the DMZ and expose all its open ports to the internet. You could engage in denial of service by blocking their devices or messing with the WAN configuration. You could set their network to use a malicious DNS server and direct them to hosts that you control.
The issue isn't the router installing something onto connected devices. I suppose that's not technically impossible, but the issue is someone accessing connected devices through the router and compromising connected devices more directly.
This would be even easier if-- because a person putting their router on the internet might not understand good security practices-- they might also be more likely to do things like punch holes through NAT without understanding the risks and proper precautions.
Even without the user misusing NAT, a router will often give a list of connected devices, internal IP, and other details. An attacker with admin access to the router can easily punch their own holes through NAT to any of those devices, run port scans, and find vulnerabilities to exploit.
On a side not, it's super annoying when you want to log in into your router, and google chrome auto completes / suggests it with 192.168.l.l, or ends up doing a google search for 192.168.0.1.
I suggest anyone wanting to see the pages in the search result to click on the google cache version instead of clicking on the link itself exposing your IP address.
I am quite sure there are enough preload/prefetch links in the Google results pages to make this irrelevant (and crash the poor routers' owners' downstream links).
One way I suppose is this: there are indexed sites on Google that just basically list all known IP addresses (eg. ip to location services) in hope of SEO juice. If those IPs are linked to by said websites then the Google spider will follow and index them.
Click "Next Page" folks - estimated 7,000+ results turns into 21 results - many of which are dead, many others are HN aggregators, leaving the total amount of these model routers on the public internet to be a small handful - all of which appear to be professionally managed with CNAMEs, etc.
>In order to show you the most relevant results, we have omitted some entries very similar to the 22 already displayed.
If you like, you can repeat the search with the omitted results included.
True claim: When I click on "next page" I get "Page 2 of about 7,520 results" BUT when I click on "next page" again I do get "Page 3 of about 21 results".
iirc, there's a certain query that's similar to this one which you could type into Google and control various security cameras around the world which are all on the WAN. Not only can you view the picture being recorded by the cameras, but you could rotate the cameras right from the web interface too.
I (un)fortunately can't remember the certain query needed, but it's not too hard to find it — I'm sure it's been mentioned on various news articles or YouTube videos. If I remember, it relied on the cameras all sharing the same filename for the PHP page to access the interface.
These routers are very well designed, receive regular firmware updates and are overall very solid. The only router that I haven't had to reboot since I've owned it (for nearly 18 months now). Had no random configuration resets, interface bugs, WiFi drop-outs, QoS issues ... just, solid.
So seeing that people have exposed it to the internet - sure, that's not recommended. But I don't think that it is something to be overly concerned about. It doesn't feel like your normal internet of crap router.
And as others have said, this is not the default setting, and you're actually warned when you try and enable external access. But for some, this is useful. Since this router supports a VPN server, external access could be the only way to troubleshoot it if you're not on-site.
A security problem is a bug. If their track record is quality (i.e. no bugs), you can extrapolate that their process is pretty good at dealing with security problems as well. Until proven otherwise.
Of course, nothing is unhackable. If a state actor wants to get inside your router, you'll lose no matter what. And you don't need to have https:// exposed on WAN to get hacked in that way. The 0-day could just as easily be on the transceiver or on the WAN layer itself.
The only way to protect yourself from a 0-day is to live in a tin foil bubble and simply never use a mobile phone or the internet.
They're a (consumer) router manufacturer. I don't care how good they are within that field, no, their track record is NOT quality. Worse yet, 90% of their code comes from the same vendors as every other router manufacturer.
> you can extrapolate that their process is pretty good at dealing with security problems as well.
That is a complete non sequitur; plenty of businesses have made useable, functional (widely-used!) software but had a head-in-the-sand approach to security.
> Of course, nothing is unhackable.
Exactly, which is why only things which must be exposed to the public should be exposed to the public.
The rest of your argument is assuming the attack surface is the same whether remote management is on or off; or that the amount of attack surface doesn't matter. Either way is simply not correct. By the way, an issue in the "transceiver" would require physical proximity. I'm not sure what the "WAN layer" is, but if you mean like... the Ethernet port and interface, that would require physical access.
If the remote management was off, you would likely be targeting nothing more than the units IP/TCP, UDP, whatever stack. With the remote management ON, you could target that, you could target the HTTP server, or you could target the admin panel running on it. Each of those are much more likely to have security holes for several reasons, but moreover there's simply no reason for them to be accessible publicly, while the routing and NAT functions are necessary to the purpose of the device.
I think this is more the fault of manufacturers than end users.
Routers should be secure by default, and it should be hard to do something that will make it insecure. The router manufacturers are the supposed experts when it comes to networking, expecting every consumer to even know the risks of exposing their router admin interface to the world is not a reasonable assumption.
These routers are secure by default. This is only visible because users have chosen to have their routers expose their admin pages to the public internet.
I have never seen a router that had its admin page visible to the WAN by default.
You are making a very good point: the order of gear shifting was tightly regulated after a lot of accidents caused by NDLR order (instead of the now-standard PRNDL). In fact most automotive interfaces have regulations to standardize them after enough accidents were caused by people getting new cars that had different interfaces.
Do you want to require that router users pass a government proficiency test and carry insurance to cover their liability for unsafe network use? Otherwise the analogy with driving a car is not quite complete.
Lackluster comparison (a modern consumer router should be more like a self steering car), but modern cars indeed have safety features to prevent you from crashing.
Of course, both with the car and the router there are good arguments that you should be able to do the dumb thing if you know you need it. If it has to be explicitly enabled after intense warnings, the protective duty (as someone knowing better) can possibly be considered fulfilled - or you can still argue that it should be especially hard to do to block out people who don’t listen to warnings.
I haven't bought a consumer router in well over a decade that isn't secure by default. Universally they all prohibit accessing the router via the WAN interface, and have reasonable firewall defaults. Many these days even include a randomized unique password for every router, stuck to the side of the device with a sticker.
These routers were put on the internet on purpose, by people that seem to know what they are doing (universities and businesses), and none seem to have default credentials. Seems reasonable to me.
https://en.wikipedia.org/wiki/Shodan_(website) - deeper reading. I'm not affiliated.
---
It's also a super basic intro to proper google-fu (which you can google to find others' takes on how to become somewhat effective at, erm, googling). Back when I used to blog on Microsoft-related topics, it was common to construct extremely narrow queries to find exposed confidential documents in Skydrive accounts which we could then sift through to find bloggable material.
e.g site:[skydrive domain] filetype:.pptx "Microsoft Confidential" etc.
Or one which still works:
https://www.google.com/search?q="Microsoft+Confidential"+sit...
lmao I'm going to have some fun tonight.