Additional firewall layer

These work on top of my existing host.

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

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.

2 Likes

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.

-cinergi

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.