RedisMonitor: Free Redis monitoring service(redisgreen.net)
redisgreen.net
RedisMonitor: Free Redis monitoring service
http://www.redisgreen.net/redismonitor.html
30 comments
I would gladly pay a license fee to install this on my servers. I would not however, feel comfortable exposing my redis cluster to the whole wide world. I think they need to figure out how to offer this as an installable piece of software, that comes with either a usage or support license.
I'm not sure how they implemented this, but there is a way to implement this in a sane way, which is as a separated process that is able to access Redis, but totally mediates the communication with it in a secure way.
So you install this daemon alongside your Redis servers deployment, and it calls home (to avoid opening ports at all) with SSL in order to establish a secure communication channel with the web app.
Every request received by the web app is then verified and sent to the Redis server only after validation.
So you install this daemon alongside your Redis servers deployment, and it calls home (to avoid opening ports at all) with SSL in order to establish a secure communication channel with the web app.
Every request received by the web app is then verified and sent to the Redis server only after validation.
This is what scout_realtime[1] does, more or less.
[1] https://github.com/scoutapp/scout_realtime
[1] https://github.com/scoutapp/scout_realtime
Redsmin also offers the proxified approach - https://github.com/Redsmin/redsmin
It is interesting that this is open source and BSD licensed, so in theory RedisGreen could use the same stuff as well and join the effort. This is the common part of the infrastructure that makes somewhat sense to develop together.
This. 100% this.
I really liked the dashboard and presentation and saw immediate worth in the product.
I then completely didn't want to use it as it wanted a _direct_ connection to my Redis server.
And the code/commands would be coming from their servers to mine...at unspecified times...
I really liked the dashboard and presentation and saw immediate worth in the product.
I then completely didn't want to use it as it wanted a _direct_ connection to my Redis server.
And the code/commands would be coming from their servers to mine...at unspecified times...
Perhaps something similar to this? https://github.com/deftlabs/mongo-live
edit: Or this? https://github.com/junegunn/redis-stat
edit: Or this? https://github.com/junegunn/redis-stat
anyone interested in this, would you mind emailing bpo at redisgreen.net ?
I also don't want my internal servers connecting to untrusted 3rd parties and sending potentially sensitive info. We never transmit logs or perf data outside of our network.
Ya, this would be a much better model.
Hi, I helped build this. A few notes about security since people are asking...
RedisMonitor supports AWS security groups for people who are interested (just hit support and ask after signing up). This is the safest way to open up Redis for the security-conscious.
Standard security on a Redis server is a very long password checked at login (AUTH). All of the communication between client and server is unencrypted. We consider this reasonably safe within EC2, high risk over the open Internet.
Redis doesn't have TLS. A few clients have forks with TLS support, but we haven't audited their security at all yet and (frankly) we don't trust them at all.
RedisMonitor supports AWS security groups for people who are interested (just hit support and ask after signing up). This is the safest way to open up Redis for the security-conscious.
Standard security on a Redis server is a very long password checked at login (AUTH). All of the communication between client and server is unencrypted. We consider this reasonably safe within EC2, high risk over the open Internet.
Redis doesn't have TLS. A few clients have forks with TLS support, but we haven't audited their security at all yet and (frankly) we don't trust them at all.
You are actively encouraging a process that is vulnerable to MITM, not acknowledging that between regions AWS data transfer is over the public internet [http://stackoverflow.com/questions/9891419/can-ec2-instances...], etc.
I strongly suggest you evaluate something like http://www.tarsnap.com/spiped.html, a VPN, or a similar solution. This isn't just read-only access we are talking about.
I strongly suggest you evaluate something like http://www.tarsnap.com/spiped.html, a VPN, or a similar solution. This isn't just read-only access we are talking about.
I absolutely acknowledge that inter-region AWS usage is over the open Internet, and no one's encouraging bad habits like transferring unencrypted data between regions here.
VPNs are great. AWS security groups are reliable too.
VPNs are great. AWS security groups are reliable too.
I may have overreacted but I've seen people make statements like "We consider this reasonably safe within EC2..." and not realize the inter-region issue. That is why I wanted to force a clear statement.
I also think this really needs to be in your marketing copy or someone who is unaware of that is going to do that sort of thing.
Sorry if I'm being a pain but I think you are overestimating the average developer's knowledge of the potential security issues with exposing Redis like this.
I also think this really needs to be in your marketing copy or someone who is unaware of that is going to do that sort of thing.
Sorry if I'm being a pain but I think you are overestimating the average developer's knowledge of the potential security issues with exposing Redis like this.
Heroku offers 4 redis cloud providers. I wonder how many setups (if any) happen to go through inter-region, and if some of these providers support some kind of VPN/tunneling.
- https://addons.heroku.com/openredis - https://addons.heroku.com/rediscloud - https://addons.heroku.com/redistogo - https://addons.heroku.com/redisgreen
- https://addons.heroku.com/openredis - https://addons.heroku.com/rediscloud - https://addons.heroku.com/redistogo - https://addons.heroku.com/redisgreen
Redis Cloud instances are at the same region as Heroku's (both in the US and the EU) - don't know about the rest though.
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)
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.
"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)
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.
Read 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.
Tbh, my internal monitoring of Redis uses the same trick but I'm doing it on a racks inside our physical office.
I'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-495...
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-495...
It 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.
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.
Yes, 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.
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.
Also, 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.
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.
For the security-minded, SSL/TLS can be easily added to your Redis server (http://bencane.com/2014/02/18/sending-redis-traffic-through-...) and Redis Cloud offers SSL plans as well. Furthermore, Redsmin has SSL support and SSL-enabled clients for Python, Ruby, Java & PHP are also out there (we helped with that, so I can recommend them fully) - http://redislabs.com/blog/secure-redis-ssl-added-to-redsmin-...
"No Assembly Required
All you need to use RedisMonitor is a working Redis URL — there's no software to install, configure, and manage."
If you are suggesting they open up their Redis instance to the outside, you probably should make clear the security implications...
I'm assuming this works via http://redis.io/commands/monitor which means you'd have write access to their redis instance if you were compromised. :/
If you are suggesting they open up their Redis instance to the outside, you probably should make clear the security implications...
I'm assuming this works via http://redis.io/commands/monitor which means you'd have write access to their redis instance if you were compromised. :/
It is ridiculous to ask people to expose their Redis instances to the open internet while ignoring all the security risks associated with this, in addition to giving you full read/write access.
It wouldn't be much added complexity to require the use of something like stunnel or spiped. Or better yet a little daemon that streams the relevant data to your service; which can be audited and verified.
It wouldn't be much added complexity to require the use of something like stunnel or spiped. Or better yet a little daemon that streams the relevant data to your service; which can be audited and verified.
Does it mean that your Redis server is accessible from the outside? Can you even tunnel that in TLS?
(1) Probably _yes_ unless you are inside Amazon EC2 and use some special security group settings and (hope) that all traffic and access stays within EC2 networks.
(2) It is impossible with the current setup to do that.
also there's a (3) you didn't ask, but should think about:
(3) You are giving _write-access_ to a _monitoring_ service.
(2) It is impossible with the current setup to do that.
also there's a (3) you didn't ask, but should think about:
(3) You are giving _write-access_ to a _monitoring_ service.
This is a service that needs an agent type setup, I am disappointed by the number of services these days that require the ability to SSH or connect directly to my systems from some unknown network.
I am deliberately going to keep my Redis inside a VPC security group that permits zero outside connectivity, I only expect my webservers/workers/monitors to connect to a database so giving some third party access violates the whole point of VPC.
I'd invest the time to either use something like bsg75 mentioned or write your own Redis stat reporting in agent in something like Go.
I am deliberately going to keep my Redis inside a VPC security group that permits zero outside connectivity, I only expect my webservers/workers/monitors to connect to a database so giving some third party access violates the whole point of VPC.
I'd invest the time to either use something like bsg75 mentioned or write your own Redis stat reporting in agent in something like Go.
Yet another SaaS product that wants me to open access to my systems to the world.
I feel like I'm taking crazy pills - why would anyone think this was okay?
EC2 security groups are IP-based, which is easy to fake your way past, so even their limited "security" isn't actually secure.
If this was an installable product, it looks like it would be great on my local network. Otherwise, forget it.
I feel like I'm taking crazy pills - why would anyone think this was okay?
EC2 security groups are IP-based, which is easy to fake your way past, so even their limited "security" isn't actually secure.
If this was an installable product, it looks like it would be great on my local network. Otherwise, forget it.
Security groups: yes. Why no stunnel on top?