AWS resources are secure by default which is a good thing. However, what happens when you want to open things up for testing and development?
\nConsider the case of making AWS-hosted Redis accessible outside of the AWS network.
\nOne option is elasticache. Elasticache can be configured to be accessible outside of AWS, but not without difficulty.
\nI took the DIY approach and installed Redis on a clean EC2 instance. Exposing Redis on an EC2 instance is relatively straightforward.
\n![](\"https://s3.amazonaws.com/contentkit/static/cjklurup00k0201739mflg9sz/redis.png\")
\nYou can use the command line tool redis-ec2 to spin up a redis instance automatically.
\n![](\"https://s3.amazonaws.com/contentkit/static/cjklurup00k0201739mflg9sz/hyper.gif\")
\nFind the security group associated with you EC2 instance and add a custom TCP inbound rule exposing whatever port you intend to use (in the screenshot below, port 6379).
\n![](\"https://s3.amazonaws.com/contentkit/static/cjklurup00k0201739mflg9sz/aws-ec2-redis-inbound-rule.png\")
\nNote that using the CIDR IP 0.0.0.0/0 whitelists all possible IP addresses on port 6379. Therefore you must password protect your Redis instance by uncommenting requirepass in your Redis configuration file.
\nRedis has full access to the filesystem (with the default configuration). If Redis is exposed on a port and no password is set it's trivially easy for malicious actors to co-opt your server by using Redis to write to ~/.ssh/authorized_keys:
\nYes. I successfully gained access as the Redis user, with a proper shell, in like five seconds. Courtesy of a Redis instance unprotected being, basically, an on-demand-write-this-file server, and in this case, by ssh not being conservative enough to deny access to a file which is all composed of corrupted keys but for one single entry. However ssh is not the problem here, once you can write files, even with binary garbage inside, it’s a matter of time and you’ll gain access to the system in one way or the other.\n
Edit your Redis configuration to disable protected mode:
\nsed -i 's/protected-mode yes/protected-mode no/' /path/to/your/redis.confsed -i 's/bind\\s127.0.0.1/bind 0.0.0.0/' /path/to/your/redis.confRedis is fast and millions of passwords can be checked per second. Therefore you need a really difficult password.
\nEdit your Redis configuration such that requirepass is uncommented or copy the following line.
\nsed -i \"s/# requirepass.*/requirepass MY_EXTREMELY_DIFFICULT_PASSWORD/\" /path/to/your/redis.confIf you're having trouble connecting to your EC2-hosted Redis, you may need to disable iptables.
\nservice iptables save\nservice iptables stop\nchkconfig iptables offSome notes on installation:
\nuser-data argument. user-data is just a bash script that is run automatically once on the instance after deployment. If you're creating your instance from the command line, AWS expects user-data to be a string, e.g., '#!/usr/bin/env bash....'. If you're using the AWS SDK, the parameter is named UserData and must be base64 encoded. For example: ec2.launchInstances({ UserData: fs.readFileSync('script.sh', { encoding: 'base64' }).