Server Hardening Best Practices

[Splines]

Hey there, thanks for Kamal as an amazing tool. I was wondering how the community here keeps their servers secure.

• What tools do you use? Do you invoke custom .sh scripts via Kamal? Do you use software like ansible? Do they work nicely together?
• Are there any best practices on server hardening, especially thought in conjunction with a Rails app that uses Kamal to deploy their Docker Containers?

I'm asking beyond using Docker Hardened Images, e.g. how to set up firewall rules, ip tables, ssh access, keeping apt dependencies up-to-date. Of course, this is individual per project, but I'm sure there are some common defaults one could build upon. Just wondering what the take from the Kamal community on server security is, thanks for any pointers.

[Splines]

I just also found out about this discussion: #1625

[Splines]

Related: #1682

[Splines]

Maybe it'd be an idea to also have a small section about security in the Kamal docs? This section could point users to some other websites offering good guides to server security.

Furthermore, such a page could mention security considerations for Kamal itself like the one described in this blog post:

When you define a Postgres accessory in your deploy.yml and expose its port, Docker adds its own iptables rules that bypass your server’s firewall. If you are using UFW (which most Ubuntu servers do), you might assume that running ufw deny 5432 will block external access to your database. It will not. Docker operates on the NAT table of iptables, while UFW operates on the filter table. Traffic destined for your Docker container’s published port never passes through UFW’s rules at all.

This is not a Kamal-specific problem. It is a Docker problem that Kamal inherits. But because Kamal’s documentation encourages you to run Postgres as an accessory on the same host, you are very likely to encounter it. The solution is to bind the Postgres port to localhost only by configuring the port as 127.0.0.1:5432:5432 instead of 5432:5432 in your accessory configuration. But if you do not know to do this, your database is sitting on the public internet with whatever password you chose, and UFW will happily report that port 5432 is blocked while it absolutely is not.