UFW Issues for whitelisted-IPs

Astraea

Bug type: Installer / Server
Plugin / server version: Any.
Homeserver name: N/A

Description:
Currently the installer allows for an option for the user to be able to remotely manage their Postgres database. It uses ufw for this, and it sets up the allowlist / ip-whitelisting there.

The problem:
The NAT table PREROUTING chain shows Docker DNATing port 5432 to 172.18.0.7:5432 for all sources (0.0.0.0/0). This happens before UFW even sees the packet. UFW's INPUT chain is irrelevant for forwarded/NATted traffic. The created UFW rule for 5432 is correct but fires too late in the netfilter pipeline, meaning that essentially the database is wide open, and I've seen bruteforcing on my postgres instance. Luckily we're not using a default database name and a simple password, but this is a problem.

The fix:

Remove the dependancy on ufw from the installer (it's simply not needed)
Use iptables to handle the ip whitelisting
Change the manage.sh script to alter iptables in stead of ufw.

dorbian

This warrant more scrutiny.
*tables is not different from UFW, as it depends on what is running on the Host.
Ideally we shouldn't touch anything on the host other then port 443 to ensure it's open for honse, and port 80 for traefik.
the database port when exposed within the Dockerfile/Containerfile will provide the intent the Host needs to allow connectivity.
for the rest we have to make sure they are running on the same network within docker.

Astraea

dorbian
Essentially:

Today:

We ask the server owner if they want to whitelist an ip for postgres access outside of the local machine
If they choose yes, we open the port (docker-compose) to the host system
If they choose yes, we set a ufw firewall entry allowing the server owners' ip on that port.

The issue:

Because Docker DNAT rules are happening BEFORE UFW rules (ufw is just a wrapper around iptables), the host system will open this port to the wide world currently.
There is no ip-whitelisting, it's open to all, as the UFW rule has lesser priority.
People can bruteforce postgres.
This is not a sane default for a server owner, so we need to do something.

So either:
1) We remove public whitelisted access to postgres from the installer and make it into a "guide" for advanced use
2) We keep the feature during install, and set iptables rules so that we actually block non-whitelisted IPs for postgres.

Keep in mind:
When running multi-filserver setups, you'll need to have a safe way to open postgres (ánd redis) ports regardless to whitelisted servers, so I'd rather be in control and offer a way to do this from the installer, in stead of hiding it in documentation. But then again - this is a more advanced scenario that really should only be attempted by people who know how to manage servers.

Your opinion(s) please @dorbian @mint @Katos

dorbian

With scrutiny i meant, let's not touch the host.
Provide instructions how to setup firewalling should be the enough if you ask me.

Astraea

I've decided to indeed remove "opening up" the host firewall to things like postgres, I will implement this in a new feature request, to keep things structured.

This bugfix is just correcting something that is broken in the current installaer, so I'll move this to completion.

https://forum.honse.farm/d/44-remove-installer-options-for-opening-up-ports-for-postgres