The former, which is why people use it. It shows you what you want to see and will genuinely enjoy seeing.
That is why TikTok is more popular than platforms that only focus on engagement, because those platforms will show content that you will engage with even if it's in frustration.
Not a purely musical mashup, but one of my all-time favorite youtube videos features a mashup song with the beatles, joan jett etc and clips of the 250 top imdb movies in 2 1/2 minutes:
https://www.youtube.com/watch?v=U0x9HtYgVqA
I do not want to know how long that took to create.
Technically I think this is the greatest mashup of all time, although it is mashing up preacher and famous tune rather than two separate tunes https://www.youtube.com/watch?v=pdXek5d2ocw
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.
It does act as a secure, transferable store of value. In the event that you have to flee your home country or its financial system is compromised you could go anywhere and retain some portion of your personal wealth.
At a minimum the last few on the mood list (depressed obsessive thoughts, apathetic, very self-critical) seem like great indicators of when someone might be the most receptive to advertising for SSRIs.
The fact that you can advertise these things at all is kind of shocking to me. I’d expect psychiatric drugs to be prescribed by a psychiatrist on their medicinal merits rather than purchased on an advertising-driven whim.
Oh, I mean there's all manner of conflict-of-interest, perverse-incentive type stuff going on there - you kind of expect that (sadly) in big business - but it's another whole level of dodginess marketing prescription pharmaceuticals directly to laypeople. It seems only one step above roaming the streets giving out "free samples" wrapped in twists of aluminium foil.
Same. I thought it was just part and parcel with me being a procrastinator by nature. I'm sure that's part of why it resonates so much. But yeah, it's always nice to know you're not as alone in your head as you think you are.
It's like Glacier, but it's smaller and moves more quickly. I think this is one of the dumb-codenames-turned-real that crop up from time to time. Fargate is another notable example.
> Chime
A chime is a notification. That's about all I got.
> Route 53
DNS runs on port 53, Route 66 is a famous highway.
> Sumarian
It's a really niche joke about the novel Snow Crash, that popularized the concept of digital "avatars".
Redshift - Oracle’s brand colors are Black and Red. Redshift was built to help Amazon “shift” from using Oracle.
Route 53 - DNS runs on port 53
Chime - when you want to talk about something “let me Chime in”.
Snowball and Sumerian. I got nothing. I didn’t even know what Sumerian was until I looked it up and I thought I had at least heard of most AWS services.
