This is why I like to use both a host-based firewall __as well as__ a network-based firewall. For the VPS's that I have running on the internet, I always use the hosting provider's firewall offering in addition to iptables (or ufw).
Re:Dockerfile Security Best Practices
by MaxBarraclough on Wednesday October 14, 2020 @05:41PM
(#24781962)
This is something AWS gets right, and Digital Ocean and Linode both get wrong (they offer no cloud firewall of any sort, to my knowledge).
It should be trivial for me to lock down the ports of my instance, from the VPS web UI. AWS lets me create a new instance which is entirely closed to incoming connections except for port 22, which is closed except for whitelisting my IP address. This gives me good assurances even if my instance is running a vulnerable SSH server. It's also trivial to block outgoing connections, where that's appropriate.
It also means my instance is spared from constant probing, which keeps the logs clear.
> Digital Ocean and Linode both get wrong (they offer no cloud firewall of any sort, to my knowledge)
DO has had a cloud firewall for a while now (a year or 2?) https://www.digitalocean.com/docs/networking/firewalls/. It's free too.
Looks like Linode has one coming soon https://www.linode.com/products/firewall/.
I mainly use Vultr for low cost VPS's and they also have had a firewall service for quite a while too.
Thanks for pointing this out, I just setup the DO firewall on my account.
Re:Dockerfile Security Best Practices
by MaxBarraclough on Wednesday October 14, 2020 @06:14PM
(#24782310)
That's good news, thanks.
So if you had 6379:6379 published anyone from the internet could connect to your Redis container. Oops.
> Always restrict your mapped ports to localhost (as in 127.0.0.1:3306:3306) unless you really want to expose it to the world
It's also worth pointing out that typically you don't even need to publish your database port. If you omit it, containers on the same network can still communicate with each other.
Very rarely do I end up publishing ports in production. If you wanted to connect to postgres you could still docker exec into the container on the box it's running on and interact with your db using psql that's already installed in that container.
A while back I wrote a blog post on the difference vs exposing and publishing ports at https://nickjanetakis.com/blog/docker-tip-59-difference-betw....