Part of the fault is on the customers who are putting their data into what is essentially a publicly-available Redis provided by accident, instead of paying for the real, private Redis.
I wouldn't blame the hosting provider alone unless they explicitly marketed that shared Redis as something being available. Presumably it's just there because of a misconfiguration and since it doesn't hurt anyone nobody noticed or bothered to turn it off.
On the other hand, sometimes I see this sort of thing on LowEndBox.com's forums, you realize OP is paying like $0.50/mo, and I'm wondering what they expected.
"Is it normal?" is kind of a nonsensical question without any further context.
And how did you arrive at that conclusion? Reverse image lookup to find other things written by the same person seemed the most promising, but I did not find anything within 2 minutes. :-)
> Also I bet there's someone unethical who's right now going through all Redis hosting services trying to repro this and get some data.
There are basically people doing this continuously in a loop. Open up port 3306 and watch people trying to connect to your MySQL instance with common passwords. IPv4 addresses are easily enumerable and the bad guys already thought of everything. (I put a real MySQL there once; they deleted all the tables and created a new one asking for bitcoin to get them back.)
I know MySQL is not Redis but the same principle applies; someone is scanning you for open services right now.
I had that happen to a test redis instance on aws (my bad for missing the port auto-routing in the cloudformation script I was trying out). About 24 hours and a bot had placed what I think was a Bitcoin mining program on it through the redis persistence mechanism.
I once put an (intentionally) bad root password on a machine to be able to log in to the physical console, then configured the machine (it was supposed to be a router) and put it on the Internet, forgetting the bad password.
I remembered a few hours later, gone back to rebuild the machine as I assumed it would be compromised, and sure enough, there was some crypto miner on it. Sadly for them, the machine didn't have anywhere enough processing power to make it worth it and they should've instead been smarter and made better use of it (it had a very beefy network connection so plenty of potential for DoS attacks or hosting malicious content, as well as being in a privileged position to capture potentially sensitive unencrypted traffic).
Yup. I recently setup a new VM on a new cloud provider at work and that poor thing got hammered with 2-4 authentication requests per minute from the get-go. By the time the UI of the cloud provider displayed the VM as running, there'd been 23 failed login requests already. I guess this means: if you're not careful, you might lose the VM before you can even login.
Our base image now comes with a hardened sshd and raised firewalls so the first provisioning-run of the configuration management actually has to reduce the firewall protection.
“
Potentially is just your own DB being exposed and now being utilized by someone else (such as hosting a covert/malicious site)... I had this happen once when accidentally left a testing (non-production, no real data/usage) redis server exposed on the internet. Came back in a couple days to find it full of someone else's data.”
As the creator of Redis states (whether we like it or not) Redis is: "a software which is designed (as we explain in our security page here http://redis.io/topics/security) to be totally insecure if exposed to the outside world" [1]
that has been the historical stance, but (for example) TLS is coming in the next release so it's going to be capable of being locked down unlike in the past
Given that Redis is not known for being something that's only deployed by security-savy people I expect their line:
> In addition, it is necessary to specify a CA certificate bundle file or path to be used as a trusted root when validating certificates.
... will not cause many real users to do what they actually need to do here. That's certainly the experience with lots of software that has this sort of feature. Users tend to fill this out with the CA certificate corresponding to the server. Now, if what you've done is spin up your own CA just for Redis, mint a certificate for the server and then you're going to do the same for all clients this could work (it'd be weird but it could work) but just as likely you'll use a nice Let's Encrypt certificate for the server - and now you're telling the server "By the way, anybody with a Let's Encrypt cert is trusted as a client". This is, let's say, very unlikely to be what you actually wanted.
This is how it works with zookeeper and kafka as well. I don't know why those projects are such a pain in the butt but I certainly don't want to learn two completely different over complicated authentication systems when all I really wanted is the ability to set a password. I'll just use TLS for authentication and be done with it.
Seems to be fairly standard indeed - elastic, mysql, postgres, .. all do the same thing. If reloading works properly, our hashicorp vault-based TLS stack could handle that out of the box including aggressive rotation.
TLS authentication isn't that hard once you understand the fundamentals.
Shared hosting doesn't really make a lot of sense these days. If you don't need much you use Wix or hosted wordpress, hosted ecomm, etc. If you know enough to keep your server updated and locked down, you use DO, Linode, or similar.
VPS requires managing. GAE is pretty much the same thing, but technically better at the expense of higher barrier to entry. Would you feel better if LAMP hosts rebranded as PaaS?
Unix permissions alone are pretty weak separation, both performance and security wise. That seems to be the point of the story. The justification in the past was that shared hosting was cheap. "Management" of shared hosting is also often worse than just running apt-get update/upgrade periodically.
Bytemark and pair are cheap, have shared and colo rented servers and have 24/7 phone and email support for free. VPSes can easily cheat you with oversubscription of bare metal.
34 comments
[ 6.2 ms ] story [ 140 ms ] threadOh my, I can already see storm the provider will get on social media once we find out who's such a moron.
Also I bet there's someone unethical who's right now going through all Redis hosting services trying to repro this and get some data.
I wouldn't blame the hosting provider alone unless they explicitly marketed that shared Redis as something being available. Presumably it's just there because of a misconfiguration and since it doesn't hurt anyone nobody noticed or bothered to turn it off.
I don't know why they'd offer a publicly accessible redis other than for testing maybe, but if they communicate it, it's on the user.
"Is it normal?" is kind of a nonsensical question without any further context.
There are basically people doing this continuously in a loop. Open up port 3306 and watch people trying to connect to your MySQL instance with common passwords. IPv4 addresses are easily enumerable and the bad guys already thought of everything. (I put a real MySQL there once; they deleted all the tables and created a new one asking for bitcoin to get them back.)
I know MySQL is not Redis but the same principle applies; someone is scanning you for open services right now.
Database ransomware: Are you vulnerable - Next year on Scareware Conference.
I remembered a few hours later, gone back to rebuild the machine as I assumed it would be compromised, and sure enough, there was some crypto miner on it. Sadly for them, the machine didn't have anywhere enough processing power to make it worth it and they should've instead been smarter and made better use of it (it had a very beefy network connection so plenty of potential for DoS attacks or hosting malicious content, as well as being in a privileged position to capture potentially sensitive unencrypted traffic).
Our base image now comes with a hardened sshd and raised firewalls so the first provisioning-run of the configuration management actually has to reduce the firewall protection.
“ Potentially is just your own DB being exposed and now being utilized by someone else (such as hosting a covert/malicious site)... I had this happen once when accidentally left a testing (non-production, no real data/usage) redis server exposed on the internet. Came back in a couple days to find it full of someone else's data.”
Also: the Internet is big enough for people to exist who do it "just for fun".
In either case this makes no sense at all.
[1] http://www.antirez.com/news/96
> In addition, it is necessary to specify a CA certificate bundle file or path to be used as a trusted root when validating certificates.
... will not cause many real users to do what they actually need to do here. That's certainly the experience with lots of software that has this sort of feature. Users tend to fill this out with the CA certificate corresponding to the server. Now, if what you've done is spin up your own CA just for Redis, mint a certificate for the server and then you're going to do the same for all clients this could work (it'd be weird but it could work) but just as likely you'll use a nice Let's Encrypt certificate for the server - and now you're telling the server "By the way, anybody with a Let's Encrypt cert is trusted as a client". This is, let's say, very unlikely to be what you actually wanted.
(Edit: Clarified text above somewhat)
This is how it works with zookeeper and kafka as well. I don't know why those projects are such a pain in the butt but I certainly don't want to learn two completely different over complicated authentication systems when all I really wanted is the ability to set a password. I'll just use TLS for authentication and be done with it.
TLS authentication isn't that hard once you understand the fundamentals.