New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Isolating Redis on Shared Hosting Environment
I’m running a shared hosting environment with HestiaCP and have implemented a local Redis server. By default, Redis exposes all data across the shared environment, which is obviously not ideal for multi-user setups.
Right now, I’m using ACLs to isolate each user’s Redis access.
Has anyone here tried similar setups or found better approaches for securely isolating Redis in shared hosting? Any suggestions or best practices would be appreciated.
Comments
How could you exploit redis in shared env?
Redis does not ship with a default password.
So, you may intentionally change values of your shared hosting neighbour?
I’m running my own shared hosting business and have implemented isolated Redis with ACLs. I’m just looking for feedback to see if there are other solutions. I’m not a cracker.
Every user should have own redis server. Other better solution is to spawn redis server per website (if user need that/will enable redis in website options). If you are running one instance per all clients remember to increase connection limit and change other default settings.
This is a very big problem because Redis can be used as a database or a cache. Therefore, the database may contain cookies, passwords, and other sensitive data.
If you need isolation and redis in shared env, a redis container per a client would be good choice.
I'm pretty sure cPanel and DirectAdmin spawn separate Redis instances for each user, and each user uses their own Unix socket address to connect. If I recall correctly, multiple websites under the same user will share the same Redis instance though.
Using ACL is less ideal as that adds up significant management overhead. You also only have limited capability to allocate and constrain the resources to certain users/websites, not to mention the complication in security and isolation.
So if I build websites for several clients, they would all share the same Redis connection? That would mean these clients’ sites could access each other’s Redis data, right? I still think it’s better to use ACLs to isolate Redis on a per-user + per-domain basis. In my case, I’m just running WordPress sites, so I create a unique password for each user + domain and write it into the
wp-config.phpfor each separate WordPress installation.No, I thought my wording was clear enough.
Each client has his own Redis instance and connection, isolated and not shared. Multiple websites under the same client share the same instance. This is how cPanel/DA handles Redis..
Deleted post. Doing more research into this...
I just use a UNIX socket, following what Namecrane implemented. I register a systemd service to keep them available whenever the server restarts. Then, I restrict the config and socket files to be accessible only by each HestiaCP user in their home directory, and call it a day. Though I wouldn't be able to do this without Steveorevo, who created the library to extend HestiaCP easily by just hooking a page, like WordPress hooks.
You could search for "HestiaCP" and "Redis" on GitHub. You should be able to find my public repository. I created several extra features, like per-site PHP settings and resource usage on a whim.
Thanks for sharing your solution. I do have a question though - in your setup, do all websites under the same HestiaCP user share the same Redis connection?
My concern is this: if I’m a single HestiaCP user and I create multiple sites for my different clients (say a.com, b.com, and c.com), wouldn’t they all be using the same Redis connection? That would mean one site could potentially expose or interfere with another site’s Redis data under that user, which doesn’t seem safe for clients.
Yep, they share the same instance since my implementation is per-user based. Technically, you can make it per-site, but I've never thought of doing that, as all my clients usually only have one site, and only a few of them actually use Redis.
You can basically create as many Unix sockets and systemd services as you wish. If I had to modify my current code, I would need to check how many sites each user has and use each site's primary domain as identification for my Unix socket and systemd service filename instead of their username. When they press start or enable, it will trigger the related Redis systemd service to start the Redis connection.
Don't forget to restrict users to only be able to read the config so they won't modify it unless you put those files outside their home dir. Read permission is needed because the Redis instance will use it as the configuration and allocate max memory according to what we've set for their hosting plans.
The only downside of using a Unix socket is that it's not plug and play. Users have to define the source of the connection, for example, in their WordPress plugin settings, so it knows where the socket location is.
For HestiaCP, I think it’s better to use Redis ACLs rather than relying on Unix sockets or systemd services.
For example, when setting up WordPress, you can implement something like this:
This way, each website gets its own Redis account (username_domain), and users are limited to only the data they’re allowed to access.
It improves isolation and security, especially if you’re running multiple sites on the same user.
Each user getting their own process is ideal since then you can limit the CPU/RAM of it (cloudlinux does this). There's no chance of an ACL failure (be it at configure time, be it changes between versions) suddenly allowing cross contamination.
The unix socket resides in the users homedir, so no one else can poke it, assuming you have some sort of home directory containment.
cPanel doesn't officially support user redis, everyone offering it is either using their own implementation, or maybe riding on litespeed's addon.
Francisco
For this solution, my concern is that all sites under the homedir would share the same Unix socket. If these sites are all my personal ones, then it’s fine. However, if the sites are built for different clients, then these clients would be able to see each other’s Redis cache data. I’m not sure whether my concern exists in the Unix socket solution?
Why not just create new user account for each client website...that would definitely keep each redis separate...subscribe for a reseller account,then create as many sub account as you are allowed...
Edit: oops, you are running your own hestiacp server...wouldnt that panel allow you to create multiple user account?and wasnt that each account have their own redis...?
There are many ways to achieve it.
I don't see anything wrong with either of these two methods, or the port method that I remember some old cPanel shared hosting still did this with an "auth key" I believe.
Each method has its own pros and cons. We consider which one works the best for us. In my case, unix socket and systemd suit me more.
100% agree ✅
The best thing you can do is forget Redis and useSQLIte object cache plugin using SQLite+APCu+igbinary PHP extensions. I measured it recently and it's way faster, especially on shared hosting. Just reading from REDIS was 50 microseconds to 28 miliseconds, time fluctuated so much. Sqlite stack was 10 microseconds when cache was empty and 5 when full, all the time, no fluctuations.