Is it normal that I see others’ Redis data on shared hosting?(stackoverflow.com)
stackoverflow.com
Is it normal that I see others’ Redis data on shared hosting?
https://stackoverflow.com/questions/60477527/is-it-normal-that-i-see-others-redis-data-on-shared-hosting
34 comments
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
Will that be mutual TLS (require a valid client cert) or just one way?
It appears that they use mTLS: https://redis.io/topics/encryption
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.
(Edit: Clarified text above somewhat)
> 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)
>(it'd be weird but it could work)
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.
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.
TLS authentication isn't that hard once you understand the fundamentals.
This comment from SO seems relevant:
“ 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.”
“ 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.”
this is it. most likely.
This doesn’t sound likely at all. What makes you so confident?
yeah who would want to use a random stranger's redis instance? what possible reason would you have for doing that?
> The technical support response was: everything is ok.
Oh 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.
Oh 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.
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.
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.
This. It's essentially "hey, I can see other users' data in /tmp". Don't write to public directories if you care about privacy.
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.
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.
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.
"Is it normal?" is kind of a nonsensical question without any further context.
I hope they don't go crazy looking. BEGET.RU is the hosting provider. It took two minutes to find on a phone.
beget.ru seems to have Redis as a service product indeed - https://beget.com/en/news/2015/redis (it's in Russian)
> 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.
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 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).
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.
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.
> I put a real MySQL there once; they deleted all the tables and created a new one asking for bitcoin to get them back.
Database ransomware: Are you vulnerable - Next year on Scareware Conference.
Database ransomware: Are you vulnerable - Next year on Scareware Conference.
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.
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.
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.
Lots of folks want to run arbitrary php, though.
VPS and a little time to manage, Google App Engine, Azure App Service, etc.
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.
[deleted]
[1] http://www.antirez.com/news/96