F21 System Wide Change: Workstation: Disable firewall
ctubbsii at apache.org
Tue Apr 15 16:22:49 UTC 2014
I think you and I disagree that "b" is broken. In my mind "b"
(listening w/firewall closed) is precisely what the firewall is
designed to do... act as a failsafe in the event of an unexpected
application listening when a user doesn't really know or want it to.
Christopher L Tubbs II
On Tue, Apr 15, 2014 at 12:13 PM, Andrew Lutomirski <luto at mit.edu> wrote:
> On Tue, Apr 15, 2014 at 9:04 AM, Christopher <ctubbsii at apache.org> wrote:
>> On Tue, Apr 15, 2014 at 11:40 AM, Andrew Lutomirski <luto at mit.edu> wrote:
>>> On Tue, Apr 15, 2014 at 7:42 AM, Reindl Harald <h.reindl at thelounge.net> wrote:
>>>> Am 15.04.2014 16:28, schrieb Christian Schaller:
>>>>> There was a long thread about this on the desktop mailing list, and I was
>>>>> not in the 'disable the firewall' camp in that discussion, but nobody in
>>>>> that thread or here have articulated how the firewall exactly enhance security
>>>>> in the situation where we at the same time need to allow each user to have any
>>>>> port they desire opened for traffic to make sure things like DLNA or Chromecast
>>>> that is pretty easy - defaults have to be closed anything and the user
>>>> have to make a choice for, otherwise if there are cirtical security
>>>> updates after a release you have *exactly* the same as WinXP SP2
>>> WinXP SP2 needed a firewall because MS didn't want to close ports 139
>>> and 445 for real. So instead they hacked it up with a firewall. This
>>> meant that, if you had the firewall blocking those ports, you were
>>> okay, but if they were open (e.g. because you were at home), you were
>>> This is *not* a good thing.
>>> Can someone explain what threat is effectively mitigated by a firewall
>>> on a workstation machine? Here are some bad answers:
>>> - Being pwned via MS's notoriously insecure SMB stack? Not actually
>>> a problem for Fedora.
>>> - WebRTC, VOIP, etc. issues? These use NAT traversal techniques that
>>> are specifically designed to prevent your firewall from operating as
>>> - DLNA / Chromecast / whatever: wouldn't it be a lot more sensible
>>> for these things to be off until specifically requested? Who actually
>>> uses a so-called "zone" UI correctly to configure them? How about
>>> having an API where things like DLNA can simply not run until you're
>>> connected to your home network?
>>> Also, having a firewall on exposes you to a huge attack surface in
>>> iptables, and it doesn't protect against attacks targeting the
>>> kernel's IP stack.
>>> I'm all for "secure by default", but I'm not at all convinced that
>>> current desktop firewalls add any real security.
>> Ideally, users would have complete knowledge of the behavior of every
>> piece of software in their system that utilizes the network, in which
>> case, they could very easily get by without a firewall. However, that
>> is not a reasonable expectation. A firewall protects users with
>> incomplete knowledge of their software.
>> Example: user installs software X... but oops, they didn't realize it
>> was going to listen on port Y.... but that's okay, because no firewall
>> rule has been enabled to allow traffic on port Y, so the user is
> This sounds like a problem that should be separately fixed. Even in
> the current state of affairs, either software X doesn't support
> firewalld, in which case we have the problem that caused this change
> request in the first place, or it does support firewalld, in which
> case it's unlikely that there will be a benefit.
>> Even worse: user installs software X, but which has no network
>> features so the user feels safe, but oops, it depends on system
>> service Y, which does open network ports, was previously disabled, but
>> is now turned on by software X. Firewalls protect against this sort of
>> incomplete user knowledge. What if software Y only enables the network
>> periodically, to perform some maintenance function? Even a pedantic
>> user checking netstat isn't necessarily going to notice network
>> services listening on ports periodically.
> Arguably this should also be fixed by cleaning up all those network services.
> With firewalls, a service, system or otherwise, can be in one of three
> states: a) listening w/ firewall open, b) listening w/ firewall
> closed, c) and not listening.
> c is secure regardless. a is equally secure regardless. b is IMO
> just broken. Yes, a firewall can work around case b, at the cost of a
> lot of UI hassles and incomprehensible failures, but I think it's a
> crappy solution.
> I keep thinking that, if I had unlimited time, I'd write a totally
> different kind of firewall. It would allow some policy (userspace
> daemon or rules loaded into the kernel) to determine when programs can
> listen on what sockets and when connections can be accepted on those
> sockets. This avoids the attack surface of iptables, it will be
> faster, it can cause programs to actually report errors if you want
> them to, and it could be a lot easier to configure.
> Wouldn't it be great if, when you start some program that wants to
> listen globally, your system could prompt you and ask whether it was
> okay, even if that program didn't know about firewalld?
>> Then, of course, there's separation of responsibilities. A network
>> admin at a company might care about firewall configuration, but
>> permits actual workstation user might just run/install whatever
>> software they like.
> Fedora's default configuration will never solve that.
>> I'm a bit surprised that a case must be made to demonstrate that
>> firewalls provide real security, in 2014, but hopefully these examples
>> provide some demonstration that they do add real security. (Note, I
>> realize that in each of these cases, a firewall could be turned on
>> after the fact. These examples are to show the value of firewalls,
>> which is being questioned, not the value of having them turned on by
>> default. That's a different argument.)
> I think no one would argue that firewalls didn't add security ten
> years ago. Things have changed.
> devel mailing list
> devel at lists.fedoraproject.org
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
More information about the devel