I have been setting up stateful firewalls on various machines at home using iptables for over a year now, following the guide on the Arch Wiki: https://wiki.archlinux.org/title/Simple_stateful_firewall
I would now like to learn how to tighten security even more by not setting the OUTPUT chain policy to ACCEPT. I want to allow only that which I need, following the philosophy of least privilege or default to deny, if you will. https://www.youtube.com/watch?v=aP8j9dgpAs0
Question: is it as simple as copy-pasting the rules for the INPUT chain into the OUTPUT chain, reversing the “-s/–source” options to “-d/–destination” and changing ESTABLISHED states to NEW? My guess is… Probably not? Because I would need to add ports 80 and 443 for web browsing, for starters, right? And also any outgoing port for my torrent client? And any port that I have chosen for my ssh server? Do I need to add the loopback interface there too?
Any guidance and referral to further reading would be appreciated! Unsolicited advice to use the newer front end nftables is… Well, not sought for at this moment
Hear me out. I highly suggest you checkout UFW https://wiki.archlinux.org/title/Uncomplicated_Firewall which wraps iptables (or nftables)
When you use UFW and get it working the way you want you can then go look at iptables directly and see how it’s implemented.
firewalld is also a decent choice.
PSA for those who haven’t read the docker docs in detail: If you run docker with UFW or any other iptables based firewall, it will often overwrite and break your firewall rules.
Many people running containers on public hosts get burned by this, because they’re expecting their firewall to block outside traffic from hitting the container.
Firewalld is a solid alternative that does not suffer from the same failure model; highly recommend.
Did not know this. thanks!
Thanks! That looks like a great way to learn what’s going on “under the hood”.
Been a minute since I touched iptables, but IIRC, not quite that simple.
You’d want to allow outbound connections to destination ports of 80/443/22 and then also allow responses from any established connection (because the server replies won’t likely be going back to your port 80/443/22 as their dest). Unless you’re running dns over https across your whole system, you’ll need to allow that too.
Nothing against doing things the hard way, but you might like OpenStitch if you’re looking to control traffic in a practical manner.
also allow responses from any established connection
You shouldn’t need to as iptables is stateful, you would need to for stateless firewalls though.
You’d also need to open UDP 123 for NTP, I see that mistake a lot.
Thank you! I will check out OpenStitch.
I’m not sure I really follow: what is the purpose of blocking outbound traffic on a system you control? I guess the main point is in case of infection from malware you’d be blocking their traffic. But malware will most probably be using port 80 or 22. Otherwise I guess you could install some software which you wish to use offline and not communicate outside, for which I’d just block that door or execute it in an isolated container or one of those systemd traps.
Feels more like a pain if this is a computer you use. I guess this is doable on a server as more or less you know what will be running there, but every time you install something you’ll have to check all ports it needs and go into iptables to edit the config.
Does the firewall on Linux work like Windows where you allow/block by process or executable name? Because that will stop malware or apps connecting to places you don’t like.
Not with the front end
iptables. Linux can filter packets based on their source and destination IP, port and MAC address. It can also filter packets based on their state, bring NEW,ESTABLISHED, RELATES,INVALID and UNTRACKED. You can check what processes are establishing connections with for instancessorlsof -iand what commands or binaries/executables stand for those processes with for instanceps.I know of no userland utility with which one could specify processes, command names or binaries/executables to block. Which might seem like a hassle from a Windows perspective, but the level of control that you achieve with Linux’s packet filtering is neat and it has taught loads about how networking and the Internet works. :)
The purpose is to block any connections that I haven’t explicitly allowed, since I don’t have the skills to vet all my binaries. Linux packages are as we know not immune.
It’s a pretty static system and I imagine I could write a script that notifies me if and when iptables blockes something outgoing (or when the kernel complains thereof).
Then again, if it is malware you’re worrying about I don’t really see how that could help. If they’re exfiltrating stuff they’re likely doing it on port 80 or 22. By blocking other ports you may prevent them from spawning a client for a command centre of a bonnet or something like that, but that would also be often done through port 80 or 22.
But well, if you do want to block everything going outside that you did not specifically allow your approach is correct: deny everything by default and allow just what you need. I’d open as much software as I need and use
psto check all the ports they are using and allow them.I finally understand your point. That’s true though with or without the use of a firewall. Not becoming infected by malware through ports that are otherwise used for common connections can preemptively only be achieved with good cyber hygiene. Once infected, I guess I’d need access control lists and/or software that blocks code execution based on signatures, but I’m not aware of such software for Linux.
