4 ms·
This violates a direct security tenet espoused by Redis itself: "Redis is designed to be accessed by trusted clients inside trusted environments. This means th
by theonewolf 12y ago
This violates a direct security tenet espoused by Redis itself:
"Redis is designed to be accessed by trusted clients inside trusted environments. This means that usually it is not a good idea to expose the Redis instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port or UNIX socket." (http://redis.io/topics/security http://redis.io/topics/security)
Moreover, your channel, which could be accomplished with a safer read-only, verified script, enables write access to potentially production Redis servers.
Write access for a _monitoring_ service.
AUTH from Redis is _not_ the only concern in this case.
What if the Redis server has buffer overflows?
What if the Redis server has a bug lurking inside it like Heartbleed?
Even _without_ logging in with AUTH, attackers could still access and play with this Redis server because it is no longer firewalled---it has to allow you to connect to it.
As others suggest, I would figure out some _secure_ _read-only_ method of accessing the Redis server.
- opendais 12y agoRead only would require a separate daemon/install package which I'm sure they want to avoid. Tbh, my internal monitoring of Redis uses the same trick but I'm doing it on a racks inside our physical office.
- theonewolf 12y agoI'd be horrified at giving a _third-party_ write access to my production database. Heck, even _virus scanners_ from people like _Symantec_ can kill you with remote code execution---and they often have write access: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4953 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-495...
- theonewolf 12y agoIt could be a simple script with a couple of commands you setup as a cron job. Similar to Loggly setup. Easily verifiable by hand as well if you wanted to. A direct connection which arbitrarily sends commands to my server? Completely unverifiable as to what commands it could potentially send.
- opendais 12y agoYes, like I said they probably wanted to avoid an install process and I would only do this internally. :) That doesn't mean there isn't a cost v. benefit decision to be made that should be left up to the end user at some point. But basic precautions [such as securing the connection properly] need to be made at a minimum. I provided the TBH as part of the disclosure of 'I do this...but I do not use a 3rd party.' so it is viable if done internally.
- theonewolf 12y agoAlso, another random thought. The commands they run are not under my control, nor is even the _timing_ of their commands under my control. Their commands might impact my production workload negatively. At least with a cron job or scheduled monitoring job I could control _when_ it runs.