On Mon, Dec 01, 2014 at 04:55:55AM +0100, Christoph Anton Mitterer wrote: > On Sat, 2014-11-22 at 11:42 +0100, Wouter Verhelst wrote: > > Except that if a firewall "protects" a user from using their printer > > (random example, not sure how likely) > Well most security guys are probably sceptical about any automagical > confiugration of things like a printer... so "protects" can actually > really mean protect here. > > But apart from that, other distros seem to manage that problem (simply > allowing the CUPS ports?)
As said, "cups" is an example. It's not about cups specifically, it's about the fact that you want a computer to *do something*, not break because "firewall!" > > and they have no way of fixing > > that (or even understanding what's wrong), that's not very helpful. This > > is why I said "with the current state of affairs". > > > > Before we enable a firewall by default, we should, IMO, have the > > following: > > > > - A way for a user to configure it without understanding iptables. > IMHO, this is a bad idea. If a user doesn't know what he's doing that he > usually makes more harm than good. I didn't say "without knowing what they're doing", I said "without understanding iptables". There's a difference, and it's not subtle. > People probably have to accept the fact that they cannot blindly act > without any knowledge and this still work. Not in all cases, no, that much is true. However, there are a few common configurations where we *can* usefully provide a default configuration for the system. When my father uses his laptop, he never uses it for anything but "browsing the web", "printing out his writings", and "reading his mail". Any kind of server on such a machine is most likely *wrong*. This configuration is common, and easy to configure. Yes, there may be a few corner cases where the default firewall config will not do what is expected. That's not necessarily a problem. > > - A way for a user to debug (without understanding iptables) if things > > don't work. > Mhh, that I agree,... OTOH, having some basic knowledge on iptables and > debuggin is rather easy, at least speaking about simple cases like "I > block my CUPS port"... other cases like IPv6 needs ICMPv6 to work or > things that require protocol level knowledge are nothing that one can > really automagical debug for a user without the willingness to learn > about these things. I'm not talking about a default firewall that will interfere with ICMPv6 (or ICMPv4, for that matter; blocking ICMP is evil). I'm talking about a default firewall that will do things like close ports 80, 22, 25, etc. If a user tries to connect to port 22 from a remote machine and it doesn't work, this user should have an easy way of figuring out "why doesn't my SSH connection work". That's not too difficult to accomplish. > > - A way for a package maintainer to assert that this particular package > > needs a hole in the firewall to be useful, and that this hole needs to > > be available to a particular group of remote machines. E.g., cups > > would not expect connections from the other end of the world, while > > webservers would. > This is really a bad idea. Most sysadmins probably wouldn't want their > firewall rules to be automagically changed by some pseudo-smart > mechanism. Who said anything about "automatigically changing" or "pseudo-smart mechanism"? I'm suggesting that a package be able to communicate to some other part of the system that it needs a hole in the firewall. That other part of the system can then decide (based on user configuration or interactive input) to ignore the request, change the firewall (with a better understanding of how the firewall is configured), mail root, segfault, or spawn nasal daemons. Or just not exist, if the local sysadmin decides not to allow firewalls. > In fact, no one can really know how fire wall rules are set up, and even > the placement of a rule make completely change the semantics. Well, no, that's true. If we ship a default firewall, we know what the firewall looks like. If the user installs a different piece of firewall software, and that piece has understanding of this proposed mechanism, then it may assume it knows what the firewall rules look like. If the local sysadmin wrote their own scripts to handle firewall, and they incorporated support for this proposed mechanism, then they should damn well understand what they did. Here's what I'm suggesting: User: apt-get install apache Apache package: "Hello system. If you're a server, you will probably want to open port 80/tcp in the firewall." System firewall: "here you go." User: apt-get install cups Cups package: "Hello system. If you're a user machine and you're on something resembling a 'home network', you will probably want to open port 631/tcp". System firewall: "we're not on a home network, but I've stored that information for later reference, thanks." User: apt-get install ntpd Ntpd package: "Hello system. There are some useful configurations where you might want to open port 123/UDP" System: "Not sure what to do with that. User, what do you think?" User: "Hell no!" User: apt-get install squid Squid package: "Hello system. If you have a home network, you will want to open port 3128 on that network." System: "Ah, yes, thanks. eth1 is a home network. I'll open the port there. eth0 isn't, though, so I'll keep things closed there." User: apt-get remove <firewall package> User: apt-get install openssh-server openssh-server package: "Hello system. You will probably want to open port 22." System: (no reply) openssh-server package: "System? Hello?" System: (no reply) openssh-server package: "Ah well, I'll just assume the port is open, then." etc. The package's suggestion would be a *hint*. What happens with it, is fully and completely dependent on the local system's configuration. After all, I do not expect a desktop firewall to look the same way as would a server firewall. > > I'm sure the first of those exists, someone with more of an opinion > > about it than me should have a look at the available options and decide > > what should be made the default. > If Debian should really get a default set of rules, I didn't say a default set of rules, I said a default piece of software. This default may also be different depending on whether the user chose the "desktop" task or one of the other tasks. [...] > I've just proposed a small default set of rules which blocks most > incoming stuff that is not from ESTABLISHED/RELATED... > I've added the default rules which I'm using at the faculty... think > away the IPsec handling stuff, the way I specially handle fail2ban, and > add you printer rules,... and I think it should already work for 99% > cases. > These are actually the rules I'm using on my desktop as well, and so far > (except for CUPS or zeroconf stuff) I haven't seen any software having > network troubles with that. You may not like cups or zeroconf, but many of our users do; and zeroconf is also enabled by default (cups' network browsing isn't). To disable it (without providing an alternative) would be a regression from previous releases. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141201222926.ga29...@grep.be
