I have Droplet A and Droplet B running Django and Redis respectively. They're both on a VPC on digital ocean, and have public, and private ip addresses.
Below is my redis docker-compose. I'm trying to map the container redis port, to the host port, so I can connect to it via the VPC.
redis:
restart: always
image: redis
command: ["redis-server", "--appendonly", "yes"]
volumes:
- redis_data:/data
ports:
- 6379:6379
On Django - also connected to the VPC, I am connecting to redis this way:
CACHES = {
"default": {
"BACKEND": "django_redis.cache.RedisCache",
"LOCATION": "redis://private_ip:6379",
"OPTIONS": {
"CLIENT_CLASS": "django_redis.client.DefaultClient",
},
}
}
This works - I am able to interact with my redis droplet. However I suspected that ports: 6379:6379
may in fact open the redis droplet up to internet, and sure enough, if I try to connect via the public IP address, this works also. Even if I type in the public IP address of the droplet into a browser, like this: public_ip:6379, my redis installation detects it as a potential security threat - somehow the request gets through. How am I to block all http/public requests to the redis droplet and only allow traffic via private ip on the VPN?
This works also:
CACHES = {
"default": {
"BACKEND": "django_redis.cache.RedisCache",
"LOCATION": "redis://public_ip:6379",
"OPTIONS": {
"CLIENT_CLASS": "django_redis.client.DefaultClient",
},
}
}
UPDATE: On Droplet B (redis), this is the readout from UFW
To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
Then if I type the public IP address of the droplet into chrome, public_ip:6379
, my docker readout says this:
It looks like somebody is sending POST or Host: commands to Redis. This is likely due to an attacker attempting to use Cross Protocol Scripting to compromise your Redis instance. Connection aborted.
Not only that, but connecting to the redis droplet via the public IP address actually works?
there is a issue between Docker and UFW. UFW does not control the ports opened by Docker and unfortuantely this state of affairs does not show up on ufw status as well. there are many proposed solutions on this which you can google up but the one that i found most useful for me is:
https://jorisvergeer.nl/2019/11/03/let-docker-and-ufw-work-nicely/
however, since you are on DigitalOcean, a simpler way might be to create a DigitalOcean Firewall which only allows the authorised IP to access Droplet B at the port allowed. after you setup the firewall, place Droplet B inside and that should control the traffic to Droplet B well.