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
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.