Let's assume we have an example machine connected to the internet. This machine is typically a client one, and it has no services like ssh running on. Does this kind of machines need any firewall to restrict incoming connections? On the one hand, there's no services that would accept the network packets, so there's no threat to the system, but is it really safe to accept such packets without DROP'ing them? Is there any possibility that the linux kernel would misinterpret such packets and behave in unpredictable way?
This is close to ask whether a shutdown computer needs updates. The answer is not if and only if you are sure that it will always stay off. Your question should receive a similar answer: if you are sure that no listening services are active and will never be you do not need to block incoming connections.
But in real world, no network service at all is hard to achieve. At least XWindow is a network oriented protocol and many services are installed and are active by default on a newly installed system.
Furthermore, a firewall should not be limited to blocking incoming connections, but should also control which outgoing connections are allowed. Doing so can prevent that a user just downloads or receives by mail (through legitimate outgoing connections...) in infected application that later will try to leak private informations or even worse will open a tunnel giving the attacker a local access. The stricter the outgoing filter the harder it will be for the attacker.
Does a machine with no listening services strictly need a firewall? Not really.
Does a machine with no listening services exist in practice? Not really, if we're talking about the more common desktop & server operating systems.
If you somehow identify and disable every single service that listens on a TCP or UDP port, an update to a package could introduce a new one at a later date. If your checks missed IPv6 services, you could be unknowingly exposing sensitive services. A firewall is an excellent compensating control for this scenario.
The other problem is that not all network services are based on TCP or UDP. It's entirely possible that you have services running SCTP, DCCP, RSVP, or other transport layer protocols that would be prohibited by a firewall's default-block policy. If you've only looked at TCP and UDP on IPv4/IPv6, you'll have probably missed anything that's listening on other protocols.
In this context, there's absolutely no value in not running a firewall. Your
iptables setup could consist solely of a default-DROP policy on
FORWARD, plus a single rule that allows inbound TCP packets that are related to existing connections - about as simple as firewall rules get. Filtering outbound traffic is advisable but not mandatory.
Ultimately this comes down to defence in depth. Your security controls should offer protection in the current state of the system, but should also offer protection in foreseeable future states. This includes potential changes introduced by updates, as well as any possible mistakes you might make in future while managing the system.
It depends on the risk profile and the stakes involved (these in turn depend on what the machine is used for).
Just a few reasons why you MAY need a firewall:
- A lurking vulnerability in the machine's network stack may enable an attack even if no open TCP or UDP ports exist.
The famous "ping of death" attack comes to mind.
There may be a vulnerability that exploits an outgoing connection as well.
In modern, bloatware-ladden computers one can never be sure what is exactly hooked to the network stack.
Did you ever bothered to disable IRDP? IGMP anyone?
A reason you may NOT want a firewall:
- Added attack surface
If a machine has simple enough function and software stack, the firewall itself (both internal or external) may offer to an attacker a valuable additional possible vulnerabilities to pick from. I remember at least one case when a naively configured MS ISA server enabled an attack that ended up as the attacker owning the whole AD domain.
- Added complexity / cpu and memory load / cost / point of failure / point of maintenance
All these things are bad in themselves. The cost may outweigth the possible benefits.
In short, no. Using firewalls for this is really a bad practice (a form of treating the network layer as access control, a big Considered Harmful), which inevitably leads to bad things like insecure services being left open to LAN or to localhost, in ways that can be exploited. But if you use an operating system with tons of default services that are hard or impossible to remove without breaking things, a firewall may be your only easy option.
One way in which firewalls historically sometimes provided additional protection was back in the days of "nuke" and "ping of death" attacks where most OS network stacks had bugs whereby malformed packets could crash (or sometimes even achieve arbitrary code execution on!) the targeted system's kernel. If the firewall was running on a separate router/gateway machine, it could fully block these (although perhaps crashing itself). On the same host, though, it varied a lot as to whether the firewall would catch the packet at a layer before or after the one it caused the crash at.
Another way in which a firewall still can be beneficial is by preventing OS fingerprinting and resource waste from replying (with rejection) to unwanted connection attempts.
Although you probably don't really need a firewall if there no listening service, it can be hard to be sure that there aren't any. Suppose the user of the machine clicks on a trojan horse that installs a listening service, now your premise no longer applies.
Firewalls can also be useful for restricting outgoing connections by policy. For instance, if malware installs zombie software, it will usually connect to the control server. Firewalls can block connections to known C&C addresses. Corporate firewalls may also block access to porn and/or gaming sites.
No perfectly configured, bug-free server needs a firewall, listening services or not. After all, what does the FW actually do? It blocks connections to ports where anyway we aren't listening, and lets them through on the ports we are listening. So it actually doesn't change a thing.
So we don't use firewalls to block off unused ports. We use firewalls as an additional layer in a defense-in-depth strategy. Because in the real world, our servers aren't always perfectly configured and neither are they bug-free. That service you turned off could be turned on again by accident when someone updates the system configuration, or as the result of a bug or malware. Additionally, modern firewalls and application-layer firewalls, WAFs, etc. do more than just port-blocking. They can sanitize the packets coming in, inspect them, redirect them and a dozen other things. Not least of all: Log them or forward them to a SIEM.
The straight answer is that the risk that the Linux kernel will behave strangely upon receiving a packet to a port with no listening service on it is negliegable. Not zero - it's software, you never know - but close enough for practical purposes. What is not zero is the chance someone (including you) accidentally starts an unsafe service, such as when updating the system, not looking closely enough at the prompts and overwriting your carefully crafted config with the package maintainer's default.