You should, yes. I run a firewall (I usually use ufw) on all of my Internet-connected devices, since all of my devices run Linux. There's not really any good reason not to in 2025.
But is there a good reason to run one on a server? Any port that's not in use won't allow traffic in. Any port that's in use would be added to the firewall exception anyway.
The only reasons I can think of to use a firewall are:
- some services aren't intending to be accessible - with containers, this is really easy to prevent
- your firewall also does other stuff, like blocking connections based on source IP (e.g. block Russia and China to reduce automated cyber attacks if you don't have users in Russia or China)
Be intentional about everything you run, because each additional service is a potential liability.
Because it's easy to accidentally run services or set up services temporarily and forget that you left them running. With UPnP being able to automatically/dynamically open ports, a firewall is just another layer of protection. You can also configure firewalls to ignore packets silently or log dropped packets, and if applications ever get new versions and end up listening on new ports, you would have to manually allow the ports. Maybe you want to have one part of an application accessible through the firewall but not another part of the application.
Plus, like you said, country blocking is another feature which personally I think is nice to have, and there are also other features too like being able to throttle connections, especially with things like fail2ban.
It's just another layer of protection, and it ensures that everything you run is deliberate.
It honestly depends on how you run things.
If everything is in containers, chances are you're already getting the benefits of a firewall. For example, with podman or docker, you already explicitly expose ports, which is already a form of firewall. If you're running things outside of containers, then yeah, I agree with you, there's too much risk of something opening up a port you didn't expect.
Everything I run is with podman, which exposes stuff with iptables rules. That's the same thing a basic firewall does, so adding a firewall is superfluous unless you're using it to do something else, like geoip filtering.
When in doubt, use a firewall. But depending on the setup, it could be unnecessary.
IMHO, security measures are necessary. I have a tendency to go a bit heavy on security because I really hate having to mop up after a breach. So the more layers I have, the better I feel. Most of the breaches I've experienced were not some dude in a smokey, dimly lit room, wearing a hoody, and clacking away at a keyboard, while confidently announcing 'I'm In!' or 'Enhance!'. Most are bots by the thousands. The bots are pretty sophisticated now days. They can scan vulnerabilities, attack surfaces, et al. They have an affinity for xmrig too, tho those are easy to spot when your server pegs all resources.
So, for the couple days investment of implementing a good, layered security defense, and then the time it takes to monitor such defenses, is worth it to me, and lets me sleep better. To each their own. Not only are breaches a pain in the ass, they have serious ramifications and can have legal consequences such as in a case where your server became a hapless zombie and was orchestrated to attack other servers. So, even on the selfhosted side of things, security measures are required, I would think.
It takes about 5 minutes to set up UFW which would be the absolute minimum, I would think.
I like to run ufw on all my machines but I'm also a tinfoil-hat wearing wacko who believes that no computer should ever really be trusted. Just trusted enough to do specific tasks.
If someone somehow busts into one of my VLANs, at least the other machines on that net will still have some sort of protection.
I only bind applications to ports on the Internet facing network interfaces that need to be reachable from outside, and have all other ports closed because nothing is listening on them. A firewall in this case would bring me no further protection from external threats, because all those ports have to be open in the firewall too.
But Linux comes with a firewall build in, so I use it even if it is not strictly needed with my strict port management regime for my services. And a firewall has the added benefit to limit outgoing network traffic to only allowed ports/applications.
One thing that hasn't been said in this thread is the following: Do you trust your router? Do you have an isp that can probe your router remotely and access it? In those cases, you absolutely need a firewall
Absolutely. Even if your ISP is firewalling, never trust they will maintain it, and some of these cheapshit routers they use are awful. Use your own router and put it on the ISP routers DMZ.
You have a firewall. It’s in your router, and it is what makes it so that you have to VPN into the server. Otherwise the server would be accessible. NAT is, effectively, a firewall.
Should you add another layer, perhaps an IPS or deny-listing? Maybe it’s a good idea.
Op means, as they said, a firewall on the server itself.
NAT is, effectively, a firewall.
No it isn't. Stop giving advice on edge security.
Are you saying that NAT isn’t effectively a firewall or that a NAT firewall isn’t effectively a firewall?
NAT simply maps IPS across subnet boundaries in such a way that upstream routing tables don't need updating.
If you use destination NAT forward rules to facilitate specific destination port access, you are using a firewall.
What sort of isp supplied residential equipment doesn’t block inbound connections? Pedantically, you’re correct.
Assuming it's not a 1-1 NAT it does make for a functional unidirectional firewall. Now, a pure router in the sense of simply offering a gateway to another subnet doesn't do much, but the typical home router as most people think of it is creating a snat for multiple devices to reach out to the internet and without port forwarding effectively blocks off traffic from the outside in.
Assuming it's not a 1-1 NAT it does make for a functional unidirectional firewall.
That's like saying a router and firewall are the same thing. NAT appears to be a "firewall" because it's usually deployed with one. NAT itself has no filtering functions the way you're describing.
Now, a pure router in the sense of simply offering a gateway to another subnet
A "pure" router, as you put it, understands upstream subnets and routing tables. NAT does not, and is usually overlayed on top of an existing routing function.
You can set up NAT between two subnets as an experiment with no iptables and it will do its job.
In practice a stateful NAT is the same as a stateful Firewall. I've never heard of a NAT that isn't a Firewall. A port forward is the same as a Firewall allow rule.
What you might call a stateful NAT is really a 1-1 NAT, anything going out picks up an IP and anything retuned to that IP is routed back to the single address behind the NAT. Most home users a many to one source nat so their internal devices pick up a routable IP and multiple connections to a given dest are tracked by a source port map to route return traffic to the appropriate internal host.
Basically yes to what you said, but a port forward technically is a route map inbound to a mapped IP. You could have an ACL or firewall rule to control access to the NAT but in itself the forward isn't a true firewall allow.
Same basic result but if you trace a packet into a router without a port forward it'll be dropped before egress rather than being truly blocked. I think where some of the contention lies is that routing between private nets you have something like:
0.0.0.0/0 > 192.168.1.1 10.0.0.0/8 > 192.168.2.1
The more specific route would send everything for 10.x to the .2 route and it would be relayed as the routing tables dictate from that device. So a NAT in that case isn't a filter.
From a routable address to non-route 1918 address as most would have from outside in though you can't make that jump without a map (forward) into the local subnet.
So maybe more appropriate to say a NAT 'can' act as a firewall, but only by virtue of losing the route rather than blocking it.
NAT in the sense used when people talk about at home is a source nat, or as we like to call it in the office space a hide address, everyone going to the adjacent net appears to be the same source IP and the system maintains a table of connections to correlate return traffic to.
The other direction though, if you where on that upstream net and tried to target traffic towards the SNAT address above the router has no idea where to send it to unless there's a map to designate where incoming connections need to be sent on the other side of the NAT so it ends up being dropped. I suppose in theory it could try and send it to everyone in the local side net, but if you get multiple responses everything is going to get hosed up.
So from the perspective of session state initiation it can act as a firewall since without route maps it only will work from one side.
How is NAT not a firewall? Sure theoretically it isn't but I've yet to see a implementation of NAT that doesn't act as a Firewall
Because NAT acts as a firewall with a "default deny" policy for incoming packets, but no other rules. You cannot prevent a device on the private subnet side of a NAT from attempting to communicate with an "outside" ip with nat alone, nat doesnt understand the concepts of accept/deny/drop.
All nat does is rewrite address headers.
The machines behind a NAT box are not directly addressable because they have private IP addresses. Machines out on the general Internet cannot send IP packets to them directly. Instead, any packets will be sent to the address of the NAT box, and the NAT box looks at its records to see which outgoing packet an incoming packet is in reply to, to decide which internal address the packet should be forwarded to. If the packet is not in reply to an outgoing packet, there's no matching record, and the NAT box discards the packet.
It's a confused topic because for a lot of people, nat does essentially everything they want. As soon as you get into more complex networking where a routing table needs to be updated, or bidirectional fw rules, it becomes apparent why routing + fw + nat is the most common combo.
If your router is setup to only allow in the ports with a service hanging off it, like SSH. Then a firewall wont add anything your router doesnt.
On the flip side, if your running any kind of VPS or directly accessible server, like a VPS or dedicated server. Then a firewall is required.
Now protecting your server from other things on your local network might something you want to do, think IoT stuff getting popped and being used to hack other things on the network
In your case: no need for a fw if you can trust your local network.
Generally: services can have bugs - reverse proxy them. Not everybody needs to access the service - limit access with a firewall. Limit brute-force/ word-list attempts - MFA / fail2ban.
You don't. Providing you have an upstream gateway that do the firewall for you, provided you don't have an open WiFi, provided you use a reverse proxy, provided you have sane network settings all around, provided you run linux(or similar).
Even better if you are behind CGNAT.
Provided you know what you are doing.
On the other hand, setting up a firewall in a safe way is no easy task either.
I use an opnSense on top of my home network, given all the above "provided".
Before that, I never run a firewall and never had an issue. Always being cg-nat tough.
My personal advice, secure it down to only permitting what needs it, regardless of your trust to the network.
Treat each device as if they've been compromised and the attacker on the compromised device is now trying to move laterally. Example scenario: had you blocked all devices except your laptop or phone to your server, your server wouldn't have been hacked because someone went through a hacked cloud-connected HVAC panel.
I lock down everything and grant access only to devices that should have access. Then on top of that, I enable passwords and 2FA on everything as if it were public... Nothing I self host is public. It's all behind my network firewall and router firewall, and can only be accessed externally by a VPN.
I use OpenWRT on my network and each server I have is on its own VLAN. So in my case, my router is the firewall to my servers. But I do have on my todo list to get the local firewalls working as well. As others have said, security is about layers. You want an attacker to have to jump multiple hurdles.
Why did you put each server in its own vlan? You now have a bunch of separate broadcast domains that need a router to move traffic between them. Switching is much faster since it is done in hardware most of the time.
Mainly for security reasons. Both servers have some limited exposure to the internet. Are you saying doing it that way has performance implications? I haven't noticed any problems its all fast just like before when everything was on the same LAN
It will impact server to server performance significantly.
If the servers are independent that's fine but don't do a file share or some other performance critical component across vlans.
Interesting, I haven't noticed anything, in fact since I switched everything has felt faster. And I'm constantly sending large files to devices on other VLANs.
It will be slower with more latency and CPU usage.
I would highly recommend you read up on networking and the OSI model. Switching is extremely fast because it is done in hardware. Routing is slow because it goes though the CPU.
If all else fails you could create a dedicated vlan for storage access.
That depends. If you have exposed services, you could use some features of the firewall to geoip restrict incoming requests to prevent spam from China and Russia and whatnot.
If you don't have any services running on a publicly accessible port, then what would the firewall protect?
I just went done this road and i'd say it is worth it even only for the learning part. I've set counter per application in nftable, and via a python script send them in SVG graph format to Glance dashboard. The result is I can monitor my whole network per application and the best part it all add up very well so I know there is no 'unknown' outgoing or ingoing traffic on my machine.
No
If it's just one server you probably already use a firewall on the server.
I can recommend cockpit for managing the firewall
You do not even need a port based firewall when the server is open on the internet.
When you configure the software to not have unnecessary open ports over the internet connected interface then a port based firewall is providing zero additional security.
A port based firewall has the benefit that you can lock everything down to the few ports you actually need, and do not have to worry about misconfigured software.
For example, something like docker circumvents ufw anyway. And i know ppl that had open ports even tho they had ufw running.
Is it directly exposed over the Internet? If you only port forward the VPN on your router, I wouldn't worry about it unless you're worried about someone else already on your LAN.
And even then, it's really more like an extra layer of security against accidentally running something exposed publicly that you didn't intend to, or maybe you want some services to only be accessible via a particular private interface. You don't need a firewall if you have nothing to filter in the first place.
A machine without a firewall that doesn't have any open port behave practically the same from a security standpoint: nothing's gonna happen. The only difference is the port showing as closed vs filtered in nmap, and the server refusing to send any response not even a rejection, but that's it.
Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!