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 http://gravatar.com/ctubbsii On Tue, Apr 15, 2014 at 12:13 PM, Andrew Lutomirski <luto@xxxxxxx> wrote: > On Tue, Apr 15, 2014 at 9:04 AM, Christopher <ctubbsii@xxxxxxxxxx> wrote: >> On Tue, Apr 15, 2014 at 11:40 AM, Andrew Lutomirski <luto@xxxxxxx> wrote: >>> On Tue, Apr 15, 2014 at 7:42 AM, Reindl Harald <h.reindl@xxxxxxxxxxxxx> 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 >>>>> works. >>>> >>>> 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 >>> screwed. >>> >>> 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 >>> intended. >>> >>> - 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 >> secure. >> > > 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. > > --Andy > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
