On Tue, Apr 15, 2014 at 9:04 AM, Christopher <ctubb...@apache.org> wrote: > On Tue, Apr 15, 2014 at 11:40 AM, Andrew Lutomirski <l...@mit.edu> wrote: >> On Tue, Apr 15, 2014 at 7:42 AM, Reindl Harald <h.rei...@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 >>>> 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
