Hello, I have questions about the effectiveness of ufw vs firewalld. I personally find firewalld to be more efficient but hard to use. I am curious what the overall consensus is on whether ufw or firewalld should be used and for what reasons. I know that Jay has a video on ufw that I have not watched as I usually just read the man page if I need to use ufw.
If people could leave their thoughts and opinions on both of services I’d love to read them.
AFAIK, both use iptables or nftables backend inside the kernel. UFW is keeping it somewhat simple. FirewallD always seemed to me like a workstation type firewall, with a laptop that changes networks like office, home, public wifi etc., in which you need different firewall profiles (zones). You define what rules apply to which network you are on and firewalld takes care of applying new firewall rulesets.
Both ufw and firewalld can be (and are more often than not) used on servers, that don’t change their subnets, meaning they just stay static.
Personally, I like using iptables. Probably because I got used to it. I’m only slightly curious about alpine-wall (only because I sometimes delve into alpine), but overall, I tend to stick to iptables. Between ufw and firewalld, basically pick your poison.
Ok thank you, this about what I assumed considering the lack of debate about which is better in a highly competitive community. I’ll have to check out iptables, because I barely prefer firewalld over ufw.
For simple rules, I prefer UFW since it’s much simpler but it’s true that it quickly becomes hard to read and write, at least for me. Firewalld is also much better documented so it’s easy to figure it out in case you don’t use it often or need something specific.
@ThatGuyB Do you have some tips to learn iptables more in-depth? Maybe some good tutorial or crash course online… I’m very scared of iptables 
Sorry, I had to learn it in production, where if you mess something up, you’re screwed, lmao.
I mostly used the man pages on iptables and a few online questions to find out some things, like what “limit burst” thing was all about (allow only an amount of traffic to go in, before blocking an IP or limiting it).
Nowadays, I just suggest people use things like fail2ban or CrowdSec, in combination with iptables. Just use some normal, small and “sane” rules (like allow port 22 in, allow 80 and 443 in if applicable, block everything else, keep it short), then these other 2 will take care of things like burst limit and such.
Iptables can get really complicated, especially if you go into multiple iptables chains. Avoid that and the mess it creates, just try using the default INPUT, OUTPUT, FORWARD (basically just first and last, as you don’t normally need to block output, unless you are blocking something like a facebook or something, if fb had a single IP address - which is normally easier to block via DNS, like pi-hole, adguard home or blocky and blacklisting it).
All the iptables commands you need to know are:
iptables -L -n -v --line-number
iptables -A <args> # append at the end of a chain, like -A INPUT
iptables -I <args> # insert at the top of a chain, like -I INPUT
iptables -I 4 # insert at line 4
iptables -D <args> # delete rule
iptables -D 4 # delete rule 4
iptables-save > /a/file
iptables-restore /a/file
iptables -I FORWARD -s <source> -d <destination> -m state --state RELATED,ESTABLISHED -j ACCEPT # mostly used for routing, but might have some uses if you block all input to a server; what this means is basically "allow connections that were established from destination initially to come in from a source which normally gets blocked by a deny-all rule"
And the basic formula for iptables (and nftables) is iptables -I <chain> [ -s <source ip> / -i <input ethernet interface> ] [ -d <destination ip> / -o <output ethernet interface> ] [ -p tcp / udp / icmp --dport / --sport <port> ] -j ACCEPT / DENY / DROP. Accept is obvious, deny is “return message immediately saying not allowed” and drop is “silently drop packets, pretending there’s no service running on that port.”
This is mostly what you need to learn for managing linux servers, but if you can, please use anything else as a network firewall, like OpenBSD / FreeBSD and pf. I’m still using iptables, only because initially on freebsd, I had no driver for a USB wifi 6 card (well, didn’t really have it in linux either, but had to compile a kernel module from github on 5.18 - after a few months, discarded that for a wifi 6 module instead, which seems to work in linux 6+ by default and it might work with freebsd or openbsd, which I’d probably change my router to).
If you have to use OpenWRT (which is good), then I’m sorry, you have to go through iptables. But at least you get a decent GUI to make some sense out of it. I’m migrating my whole network to OpenWRT wifi APs (although still keep my linux router for now).
This is what I’ve been doing so far: allow outbound and block inbound except a few selected ports for basic SSH and web traffic. It works great, and in reality I have no reason to mess with this but it’s always good to know how these things work, especially things like Docker who like to poke holes directly.
And thanks for the feedback!
Hopefully the OP did a little research and went with nftables. It is a lot nicer to work with than iptables, however, iptables is pretty darn straight forward if you edit the rules in a text file with vim. Doing the insert commands is impossible for me except for the most basic rule set. Just backup the file, open it and edit to your hearts content. It is all laid out there and organized. Reads like a book.
In a lot of ways it is easier to edit & comment than a GUI fw. I had one setup with over a couple hundred lines and using iptables in a text file was a breeze. For those reading this if you value your your sanity use a text file to config your rules. And use nftables in 2023.
We’ve gone back and forth on this one before and I respect your knowledge and personal preference, but on this one and for this user I disagree. You are recommending a completely new OS and FW syntax to a user who is trying to get his feet wet? Not to mention the BSDs are not were the growth is… to put it kindly. Setting up nftables to act as a perimeter FW is maybe three lines of config. Two more lines for forwarding. The BSD argument has dwindled down to a religious argument for a good decade or more now.
That works but why add all the code? I like using as little extra code as possible. Every time you add code you extend trust to another person(s). You can do this with maybe 4-5 lines in your nftables config. I can post my config but googling it is easy enough too.
Hope my $0.02 helps the next person down the line.
If he was already familiar with iptables, I’d suggest using nftables. But the switch from ufw and firewalld over to iptables is just as big of a jump from ufw and firewalld to pf.
Additionally, I wasn’t suggesting all the host get migrated to BSDs, only the main router + firewall of the network, if possible. The usage of a local linux firewall would still be required in the same subnet.
Not sure what you mean by this. A lot of huge companies like Netflix use FreeBSD. And even nowadays if you go to an interview and say you know freebsd, is a way better indicator of your knowledge than just saying you know linux. That’s because if you know a bsd, it can easily translate to linux, but not the other way around. That’s partially due to the way you learn the bsds, by reading docs and man pages (which are eons ahead of linux ones). While on linux, you mostly learn by asking a search engine a question and finding the answer (because most linux questions have already been answered).
The barrier of entry to bsds is higher than in linux. I’m not saying that’s either good or bad, it depends on the scenario, but growth wise, learning a bsd is never a bad thing.
I would argue the biggest growth we’re going to experience is with nixos, which I haven’t even brought up. There are a lot of insanely well paid nixos sysadmin jobs (at least in the US). And the prospects for nixos are probably likely to grow, because of how well it’s designed.
On the firewall side, nixos fw conf is easy if you already know configuration.nix. In fact, it’s too easy, although it gets hard when you get to configure routes with nftables (still manageable).
Compared to nix, bsds have a lower learning curve if you already know some linux basics.
Please let me know if I didn’t guess right what you meant with the growth part.
Besides enabling pf in rc.conf, setting up a pf fw is just as easy, but you have to keep in mind the order is reversed (unless you use the quick function, which you shouldn’t use often anyway).
Normally I’d agree with the argument, but these particular codes are useful for managing some stuff you can’t do just with a firewall (unless you want to script a few hundred or thousand lines of code to automate some rule applications based on your access logs). You can’t keep up with all the IP addresses that attackers will try to connect to your systems from, so it’s best to have something like crowdsec come into play (if someone is attacked, he automatically shares the knowledge and everyone has the same blocklist already configured).
Just look for Jay’s crowdsec hands-ons.
Say you are following best practices on your server setup (let’s say a router + fw), but you ought to manage it remotely via SSH from the internet, or if it’s OpenWRT, via its web gui (or both). So you have allow port 22 and 443 in, you are using ssh key auth and you disabled password auth on ssh, but you’re still using a password for the web conf. Everything else gets blocked by default.
You don’t know where from the internet you’ll be managing it, so you can’t simply define an “allow only from x ip” and have to allow all on port 22 and 443. That leaves you open to attacks. In nftables, what you’d be probably doing is setting up a burst allow (only n connections per minute). If more than that is detected, you start blocking. But then, an attacker will just use another IP to reach you (there’s insanely huge botnets out there).
What fail2ban does is it’ll allow you to connect successfully from anywhere and if there are multiple failed login attempts from any IP, just block that IP entirely, because you know it’s not you. And it can be automated to release that block after a while (particularly good for services hosted to the general public, but not in the scenario above). The attackers will still keep switching between IP addresses, but unlike a burst block how many attempt a script kiddie can hammer at your server, instead all the IPs get blocked altogether when the attempt limit is reached.
This is particularly why crowdsec is better, because that knowledge can be gathered from others when that happens, so you can potentially avoid all exploit hammering altogether, instead of just preventing the amount of hammering being done.
There is a big part of me that loves the overly technical solution to a simple problem. And you didn’t suggest so GUI fw, so I dig that! But learning a new OS and a syntax that doesn’t translate anywhere else, for one box (and only one box) is not as easy as just typing out a few lines of config and moving on with your life.
And doing it on a system (linux) that is used every where and by everybody (not just some of Netflix servers). But again, the nerd in me loves the technical challenge of it, so I understand why you are doing that.
Crowdsec sounds interesting. My nft rule is more like failtoban. I have it rate limit new connections per IP based on a timeout I set.
ct state new tcp dport 22 update @ssh_ratelimit { ip saddr limit rate 1/minute } accept comment "allow ssh with rate limit"
And yes, I use key based auth too and a jump box and logging… So my overall exposure is inconsequential. Sounds like crowdsec would be better, but I highly doubt I want to pay the “cost” of adding code and trusting how many additional developers. To wring out that last 0.001% of security efficiency is just not high on my priority list. In my head the cost would be more than the reward.
Plus, most of the time I just use wireguard. That is better in every way for my situation.
I’ve seen *BSD being mentioned many times though mostly in the context of networking.
What reasons exist for someone to step out of their comfort zone with Linux, in order to learn *BSD?
@jay Maybe going over some of the history and differences/similarities between Linux and *BSD, and the different versions that exist, would make for a good video?
To be as fair as I can be, you are asking for performance differences that are irrelevant in 2023. Security advantages too in a practical aspect. Arguments can be made in both sides, but we are only talking about stuff on the extreme margin.
With both source codes open to the public, any significant improvements get flat lined. At least on the linux side. The biggest issue I see is the developer momentum going towards linux. I wish the BSDs were healthier, but that just seems be getting worse as the years/decades roll on.
Sorry to break it to you, but I mentioned openwrt at least 2 times in this thread. You could manage it just on CLI, but its GUI is decent for beginners. There’s no shame in using a GUI if your threat model allows it. Mine would allow for one, but, to me, GUIs get in the way.
If you are referring to my choice of pf instead of something like pfSense or opnsense, that’s because the hand-holding in those OS is too much for my taste (not being elitist, but the system is getting in the way when setting up some rules, because you don’t start with a clean canvas, but with whatever defaults that each OS’s maintainers decide). Sure, it’s easy to get into, but it’s better to understand pf instead (or iptables / nftables if you go the linux fw).
That rule will only limit SSH connections to 1 per minute, unlike fail2ban which will trigger an INPUT -s <offending-ip> -p tcp --dport 22 -j DROP (or DENY, but I think DROP was the default). That’s why fail2ban is more powerful than just rate limit rules. Overkill for most scenarios? Sure. Less secure because you’re adding code? I believe to be the opposite. You can combine fail2ban and iptables to prevent distributed brute-force (particularly for web servers), but using just one or the other is not as good as using both.
Good. Most people should. For my situation however, at least because I’ve been using wireguard as soon as it came out as a kernel module (before it got built-in the kernel), I had to restart it from outside the network from time to time. I haven’t had the need to do that in about 2 or 3 years now, but at the beginning, it was really rough and I’m thankful I had ssh port-forwarded to the internet (it’s a remote site I own, I couldn’t easily go there and back then, sending someone to intervene would’ve taken at least a month or 2).
Lately I’ve been thinking if I should just set wireguard alone and forget about everything else, but I’m reluctant because of that .01% chance I might need to SSH to the server to restart wg (my threat model is not that high for that particular site, it’s just a remote DVR accessed from the internet through wireguard and that’s it, but I still like to be secure and not help hackers by having my hardware become part of a botnet).
Agreed on performance differences being irrelevant. Hardware these days is so powerful you can just throw more compute at the problem if you really need it (I’m using mostly ARM SBCs around here and even these are very good for my low-end purposes - besides, I save on power bills).
Performance-wise, sure. Security-wise, I’d argue openbsd is more secure, because of its lower attack surface and the drive of openbsd developers to remove code, instead of add more. I’m hoping to move to an openbsd router myself (also arm sbc), but last I tried, the wifi drivers sucked (I got wifi WAN). I might be able to get away by having an AP bridge, but I’d like to keep power usage to a minimum. I’ve got a new wifi card from last time I tried, but I haven’t had a chance to test openbsd with this one.
But openbsd has always been slower compared to linux and freebsd (the latter which adds more code to improve performance, just like what linux development does). Not a problem for me though.
I use freebsd whenever I can for its really easy to manage ctld and because of built-in zfs support. Both freebsd and linux are using the ZoL implementation, making neither better than the other. In terms of security, I don’t think freebsd is much more secure than linux, all things considered, but linux is more likely to be targeted, because of its adoption (although these days, most of those arguments are kinda moot, since you can just run a single binary rust or go program to take over a system - that’s where selinux has an advantage, not sure what the equivalent would be in freebsd, but my threat model is not that high to bother with it, the first thing I used to do on selinux distros was disabling it).
Maybe I’m biased, but I see linux, freebsd and openbsd, all growing, neither of them shrinking. Sure, the bsds don’t have as explosive growth as linux, but it’s still substantial enough to allow their continued growth (if you’ve been reading the drama on pfsense and truenas core development by adding less reliable code compared to what upstream freebsd has, you can easily see why I think freebsd is not dying, because it is still being developed by competent people, not mindless corporate drones, unlike the aforementioned appliances).
FreeBSD also started treating ARM as a first-class citizen recently, so I don’t think they’re lacking developers. OpenBSD has always been multi-architecture OS (given its netbsd roots), because you’ll always find bugs by porting the OS to another architecture, so they always maintained the code compatible between different cpu instruction sets.
Despite my preferences for certain bsds for certain applications (like NAS and firewalls), that’s not always possible, because of lack of support (because I keep using low power arm boards, lmao). My Odroid HC4 runs NixOS (backup server with ZFS). My main rockpro64 NAS runs freebsd. Rockpro64 router runs void (like I said, planning to move to openbsd). My old pi 3 router used to run alpine (I still have it around, just that it’s not used very often, but only when I’m on the go and need a VPN router). I also run nixos on a pi 4 as a network-wide ad-blocker (blocky).
I got some more hardware that’s currently just powered off, because I’m not doing anything with them, all of which run some linux distro (mostly because I got dragged down by the canonical overtake of lxd, waiting on updates on incus, but I’ve also been testing firecracker on the side whenever I had the chance).
I don’t think there’s needs to be unification under one kernel. Competition is good. Choice is good. And if bsd devs would stop working on bsds, they wouldn’t necessarily start working on linux. They might start working on other stuff, like desktop environments, or other OS, like Redox OS.
I hope you are right about the developer issue with the BSDs. My concern is the economics (monetary, academic, notoriety, etc) of kernel development favor a monopoly, but at least linux is an open source monopoly. Time will tell, but I hope you are right.
Even if I give the benefit of my doubt to grant openbsd a security edge, what are we talking about? Maybe 1%, or if we are being extremely generous 5%. So you learn a whole new OS and fw syntax for 1-5% bump in security? At best. And that is from a base (linux) that is already extremely secure, especially with a little configuration. The juice is not worth the squeeze. And that points back to the problem the BSDs have, even if they are better they are not better enough to change from the default. That goes for users and developers.
My firewall rule is a conditional allow, so skip past that and the default drop will do the same job. Again, even if I grant you the benefit of my doubt and say my rule is inferior. Well, how much better is the alternative? And at what cost (lots of new code running as root)?
Funny, we both keep ssh open as a back door to our vpn. I generally only open it if I travel, and I haven’t needed it in years so I closed it a while back. If I ever need it again I can just remove the pound character and be back in business.