firewalld vs iptables vs ? as default (was Comparison to Workstation Technical Specification)

[Miloslav Trmač]

2014-02-26 18:39 GMT+01:00 Simo Sorce <simo at redhat.com>:

> To be honest my question is more about: what is the point of doing
> this ?
>
> Do we have applications that we do not trust and open unwanted ports ?
> If we do not trust them why do we install them ?
> If we trust them why do we firewall them ?
>
> Considering that the default policy on Fedora is not not start daemon
> automatically I am trying to understand why having a firewall configured
> by default is a good idea.
>

AFAICS there are basically these possible ways to answer the question, each
valid in some situations:

0) The computer is a router, and applying policy on traffic is its specific
job.  (This is clearly a special situation that doesn't affect the question
of default setup.)

1) The computer is assumed to be competently administered[1] on a
homogenous network.  This implies that any service running with an open
port is intended to run and have that port open, so there is no point with
restricting it with a firewall.  There is obviously no point in restricting
closed ports with a firewall.  With this assumption, firewall should be
either completely absent or permitting almost all traffic (or perhaps
enforcing some kind of minimal policy, filtering out clearly bogus packets)
by default.

2) The computer is assumed to be administered by people who make mistakes
from time to time; in such a situation having a firewall by default serves
as an extra step that "nudges" the administrators to revisit their
assumptions and intentions: "Now that your httpd/database is running, did
you really want it accessible by the net, or only by localhost?"  With this
assumption, a firewall should be present, and blocking incoming connections
by default; it makes sense to make it fairly easy to enable access to a
service after setting it up.

3) The computer is assumed to be running on a non-homogenous network, e.g.
providing some services to an internal network and fewer services to a
public-facing network.  It is unsafe, or at least risky, to expose
internal-only services on the public network.  With this assumption, a
firewall should be present, and blocking incoming connections by default;
the system shouldn't be enabling access to a service after setting it up,
and leave this to manual administrators' action (unless the system
understands how precisely is the network non-homogenous).

4) The computer is assumed to be already compromised, or highly likely to
be compromised.  In that case, a firewall blocking incoming connections by
default would stop *some* communication, but it makes *almost no difference*:
Instead of opening a port and waiting for an incoming connection, the
attacker can make an outgoing connection, which is not restricted by the
usual firewall setup.  Because most home routers doing NAT implicitly act
as firewalls that block incoming connections, it would be almost
*unexpected* if the attacker tried to open a listening port nowadays.
Overall, I don't think the firewall is effective in this scenario in most
cases, so this scenario doesn't matter in the discussion.[2]

Note that apart from 4), the assumptions are about the *computer*, not th*e
individual services*, and are mutually exclusive; it doesn't make sense to
treat one set of ports differently from another.  This is the reason for my
objections to the suggestion that the default setup of the firewall should
differ between roles.
     Mirek


[1] ... and competently designed; let's assume that's true for Fedora
Server :)

[2] One thing to consider, and other OSes have been moving in that
direction, is to have a firewall that doesn't block *ports* but blocks
*executables*.  This makes the attacker's work somewhat harder, in that
they couldn't just use a standardized shell code to download a new binary
and execute it, but they would have to continue manipulating an existing
process to make the connections on their behalf.  In a sense, we already
have this capability with SELinux; and It's unclear how much difference
does it make - would this only cause the attacker to add a socket() call to
the shell code, and leave the rest of the activity to a subprocess, for
example?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140303/2c7fa85a/attachment-0001.html>