Additional firewall layer

These work on top of my existing host.

accept TCP 25
accept TCP (DNS) 53
accept UDP 53
accept TCP (HTTP) 80
accept TCP 139
accept TCP 143
accept TCP 389
accept TCP (HTTPS) 443
accept TCP 465
accept TCP 475
accept TCP 587
accept TCP 636
accept TCP 993
accept TCP 995
accept TCP 1433
accept TCP 1434
accept TCP 3333
accept TCP 8011 - 8012
accept TCP 8020
accept TCP 8111 - 8112
accept TCP 8201 - 8204
accept TCP 9000
accept TCP 14000
accept TCP 50000
accept TCP 50001
drop any 0 - 65535

I am not sure what half of the open ports you have open are even for …

Personally I recommend sticking with what UFW recommends unless you change the SSH port or add WebMin or something similar.


Yeah, I missed this topic.

@alento is correct. Linux uses iptables, which are notoriously difficult to configure. Professionals screw them up all the time.

The ufw tool (“uncomplicated firewall”) is, by far, the best way to manage iptables.

1 Like

Is there a special reason not to have an intermediate layer at the cloud level between my host server and the web?

I understand the configurability is more granular, it’s just easier for me to set up.

For MiaB, it is already configuring its own firewall. Generally, if there is not a useful function for an extra thing, the extra thing represents an additional opportunity for failure.

1 Like

Having a slightly less restrictive firewall in the cloud with a more restrictive firewall on the server itself is redundant and adds complexity that you don’t need.

Just utilize the built in firewall config on MIAB and reduce your headaches.

1 Like

I have not really been actively researching the code comit process.

Who does the committing?. Is there a vetting process?

What is the likely hood of a bad actor tainting the repo?

Not that anyof that matters, but i intend to put the miab behind a ups/ids using netgate firewall.

Just remember that every step of complexity you add is going to make it that much harder to troubleshoot when something goes wrong.

I use the cloud-level firewall at my VPS provider (Vultr) in addition to MIAB’s built-in UFW firewall. I simply duplicated all the existing UFW rules in the VPS firewall settings, with the additional restriction of only allowing SSH logins from my own IP address. This has eliminated the constant SSH connection attempts from intruders on the Internet (if you look at your logs, you’ll see how many there are).

This setup has worked fine for me in the several months that I’ve been using MIAB; it was pretty much “set and forget” at the VPS level.


You are free to do with your server as you desire, but note that if MiaB project makes a change that requires a port not previously used, some functionality may be unavailable or broken until the external firewall rules are revised.

The attempts on the port 22 login are insignificant load on the server - openssh is designed that way.

Indeed, you are correct. That’s the tradeoff involved in having a custom firewall setup.

The other side of this is if there is a change in the external firewall it may start causing problems in MiaB that cannot be immediately diagnosed as a firewall issue, which can then generate a lot of time spent troubleshooting the wrong device.

Unless being installed to a local network (which always requires an external firewall), it is difficult to see any good reason to run MiaB behind a firewall for most users. The exception would be a highly visible server that might require some sort of DDoS protection, but that is a different matter, altogether.