@ -12,7 +12,7 @@ I have always wanted to try self-hosting things that are clearly better done by
If I had gone with a more fully-featured cloud hosting provider, such as [DigitalOcean](https://www.digitalocean.com/) or [Linode](https://www.linode.com/) (not affiliated with either), I would have been able to configure my VPS's firewall through a UI console. However, I had already purchased a really large server for cheaper with another provider. This meant I needed to set up my firewall right on the server myself. As a software developer, I am horrible at SysAdmin by nature; the idea of setting up critical iptables shook me to my very core. This was why I chose to configure my firewall with the easier to use ufw.
If I had gone with a more fully-featured cloud hosting provider, such as [DigitalOcean](https://www.digitalocean.com/) or [Linode](https://www.linode.com/) (not affiliated with either), I would have been able to configure my VPS's firewall through a UI console. However, I had already purchased a really large server for cheaper with another provider. This meant I needed to set up my firewall right on the server myself. As a software developer, I am horrible at SysAdmin by nature; the idea of setting up critical iptables shook me to my very core. This was why I chose to configure my firewall with the easier to use ufw.
The setup I needed was as follows: deny all incoming traffic by default, allow all outgoing by default, then allow traffic on the ports I needed (namely SSH, HTTP, and HTTPS).
The setup I needed was as follows: deny all incoming traffic by default, allow all outgoing by default, then allow traffic on the ports I needed (namely SSH, HTTP, and HTTPS).
What scared me the most was potentially locking myself out of my server. Working directly with iptables put me at risk of this, as iptable rules operate at the kernel level. If I changed one wrong thing, I could completely lock myself out of my server. ufw didn't have this problem, because it runs as a service; I could configure all of my ufw and start the service when I felt everything was ready. I dry-ran the following commands on a temporary tiny VPS to make sure I wouldn't lock myself out (`sudo` removed for brevity):
What scared me the most was potentially locking myself out of my server. Working directly with iptables put me at risk of this, as iptable rules operate at the kernel level. If I changed one wrong thing, I could completely lock myself out of my server. ufw didn't have this problem, because it runs as a service; I could configure all of my ufw and start the service when I felt everything was ready. I did a dry-run on a temporary tiny VPS to make sure I wouldn't lock myself out (`sudo` removed for brevity):
```bash
```bash
ufw default deny incoming
ufw default deny incoming
ufw default allow outgoing
ufw default allow outgoing
@ -22,7 +22,7 @@ ufw allow https
ufw allow 25565 # I have a Minecraft server running on this machine already!
ufw allow 25565 # I have a Minecraft server running on this machine already!
ufw enable
ufw enable
```
```
After doing this, I disconnected and tried to ssh into the server again. It worked as expected, and now that I'd verified it worked on the test VPS I ran them on my main VPS, with similar success.
After doing this, I disconnected and tried to ssh into the server again. It worked as expected, and now that I'd verified it worked on the test VPS, I ran them on my main VPS with similar success.
Time to come clean though; this wasn't the first thing I did. This was actually one of the last things I did (hence why I was extra scared of locking myself out). The main reason I did this was to make sure my server wouldn't accept connections to `http://<ip>:<port>`. This worked for some of my services, but not for one of them. The reason it didn't work is because ufw by default cannot stop Docker from accepting connections directly to published ports. On install, Docker makes entries in the iptable rules that are evaluated before ufw's. I tried a veritable cornucopia of bad solutions before finding [this repo](https://github.com/chaifeng/ufw-docker) that provided the perfect solution for me.
Time to come clean though; this wasn't the first thing I did. This was actually one of the last things I did (hence why I was extra scared of locking myself out). The main reason I did this was to make sure my server wouldn't accept connections to `http://<ip>:<port>`. This worked for some of my services, but not for one of them. The reason it didn't work is because ufw by default cannot stop Docker from accepting connections directly to published ports. On install, Docker makes entries in the iptable rules that are evaluated before ufw's. I tried a veritable cornucopia of bad solutions before finding [this repo](https://github.com/chaifeng/ufw-docker) that provided the perfect solution for me.
