2009/6/24 Marc Herbert
<Marc Herbert gmail com>
Graham Lyon a écrit :
> 2009/6/24 Marc Herbert <
Marc Herbert gmail com>
>
>> Graham Lyon a écrit :
>>> I'll agree that if your system doesn't have ports open by default then
>>> you're fine, but if for instance your package manager pulls in mysql or
>>> postfix or similar as a dependency for some package that doesn't really
>> need it to use its network capabilities
> Yes, such a situation would be a misconfiguration. But, going on to say that
> because this is a misconfiguration issue and therefore there is no need for
> a firewall is a little foolish. The firewall would mitigate any threat that
> would exist (at least on public networks)
So I guess the problem is: how do you protect a minority of mysql users
from an unlikely and easy to fix packaging error, without bothering with
a firewall the vast majority of desktop users who do not care?
My point wasn't related to mysql directly, that was more of an example. I was hoping to raise the point of, if a packaging error does occur, then the firewall mitigates that issue until the bug is found/corrected and so lowers the potential for an exploit to take place in that time. I do, however, accept your point that the security vulnerability is, in this case, tied to the packaging error and that it should be corrected, not left because "the firewall stops the problem anyway".
> - belt and braces, etc....
Belt + braces is nice in theory but in reality people tend to give up
one once they started to use the others. Windows experience shows that a
firewall makes most people feel protected and not care any more about
network security.
I suppose I can see where you're coming from here. I myself have experience with this kind of person thinking "oh, well I have a firewall so nothing can get me now!"
> What's complicated about it?! Sorry - but that's really an incorrect
> statement. As for which user understands the configuration of their
> firewall, that's the whole point of this daemon - *it* understands and *it*
> can do the configuration, all the user has to do is say that it's a
> public/private network and the rest is taken care of.
>
> 1) You've just connected to a wireless network
> 2) Do you know whether this is a public or private network already? If not,
> ask.
> 3) If it's public, block all incoming traffic on that interface.
Please let me quote your message from yesterday:
> A firewall isn't only about prevention access to network listening
> daemons, it's about granularity in that restriction :)
And indeed, the first thing people will do is allowing skype and other
similar P2P software to escape their firewall (or worse: disabling their
whole firewall). Your configuration simplicity (or worse: your entire
firewall) is just gone. So now you have to manage an extra firewall
configuration, where managing just your network services gets you the
same result. Complexity is security's worst enemy.
Point taken. I was thinking that down the line we could have a D-bus or similar call that software could perform to request an interface be opened to them, then we can do the whole PolicyKit authentication with ticky boxes saying "always allow them to do this on this network". I realise this is extra dialog boxes etc, but I think that it would be worth it.
> Imagine you're a user who's decided
> you'd like to start learning php for the first time:
So for a start: I am definitely NOT the average desktop user.
Actually, the number of average desktop users I see trying this (or similar) things is large enough to take note of....
> you install apache,
> mysql and php. What's the first thing you do? Carefully comb the
> documentation and the default configuration files, looking for security
> holes and ways to tighten up the security of the setup or do you get
> straight in there with the programming and learning and only worry about the
> security aspects a few months down the line when you're about to put in your
> first production ready server? If your answer is the second one then you're
> a liar :)
My answer is that I use a Linux system which is not insecure by default,
meaning apache and mysql are bound to the loopback address by
default. Based on this, this system does not need and has no firewalling
by default. Moreover the package manager refuses to start MySQL until I
have input a non-default password, giving me some extra security. I can
safely skip reading the documentation and worry about the security
details later.
This is certainly not the case with Ubuntu as far as being bound to the loopback by default goes. You are correct on the MySQL password, though.
Once I need to test my server remotely, I spent no more than 5 minutes
learning how to unlock the loopback safety. Later I connect to a public
network. NetworkManager then runs a dead-simple "netstat -l" command and
warns me that I left my apache server running by accident. So I just stop
apache. Job's done.
And by the way, all this is (almost) already happening today. But not in
the Windows world for sure.
I wasn't aware of this, could you point me towards any discussions on this being implemented? I'd be interested to read where this is going.
> The point is that in a perfect world where we all carefully configure our
> systems to be secure, the daemons are all written with perfect code with no
> security weaknesses and that any code that we ourselves write (eg a
> php-based site running on the apache server, or similar) is also written
> perfectly and so will not have any weaknesses THEN we can not bother with a
> firewall. If you think we live in this world, you're a tad naive...
I can safely afford to be naive because I live in a non-Windows world
where the average desktop user is not running any daemon at all.
I understand that other users could use a firewall. But the minority
should never inflict the firewall plague to the majority. Else what
next? Antiviruses to make everyone's desktop twice slower? No thanks.
How many times have you heard the following support answer:
"please try to (temporarily...) disable your firewall?"
Too many, however this is unfortunately not something we can do anything about. Just because a few people tend to disable the firewall doesn't mean we shouldn't put it there to start with! ;)
> For instance without a firewall you can list all your security holes with
>> just a simple "netstat -l"; no added confusion.
>
> This could just be me, but I didn't actually know about that command before
> you mentioned it. Now what about your poor little idiot user who couldn't
> possibly comprehend a firewall - does he know about that command?
You are unfairly mixing concepts (firewalling) with low level commands
(iptables). The netstat command is an implementation detail. The
relevant concept is "network services enabled", certainly more intuitive
than the firewalling concept most people have no clue about. I have met
countless skilled system administrators helpless in front of firewall
configuration, even with a GUI interface.
My suggestion was for integration between NetworkManager and active
network services. NM would be the one running the netstat command (or
anything equivalent).
Oh and by the way, if you run "netstat -lp" as root you get the daemon name.
Oh, I wasn't aware that could happen! So, does that mean we could do more magic and discover which service it is that has started that daemon? I suspect that it would need a couple of features added to upstart (or other init daemons) but I suppose this could be possible.
> A firewall is hardly distant, and it's hardly a bad way of doing this. I'll
> admit that blocking it at the service-level would be better, but like I
> said; what if I want to then access it from another machine when I'm at
> home? Do I have to change the apache config? Didn't think so...
The alternative is to just shut down the daemon when you are in
public. It is most intuitive solution and nothing can be safer. Less is
more, especially in security.
> How many users do you see saying "I'd like to try out programming in php,
> what should I do to set it up?" on the forums every week?
> [...]
> Tell me that this, combined with
> the various other use cases out there, is not worth sorting something out
> for. Or are they power users and, as such, left out in the cold on their
> own?
I must admit this "middle-ground" category did not initially cross my
mind. I think the best for them would be... belt and braces by
default. I mean loopback+firewall. Then they can easily choose the
configuration that suits them best. But please make sure that this does
cause everyone else to have firewalling by default!
> In all likelihood, if we go down the route of disabling network services
> when we hit a public network, we are likely to miss one. This leaves a
> security weakness that simply adding a single firewall rule that blocks all
> incoming traffic on that interface would not leave.
I like it, as long as this applies only to the minority of people
actually running some network services. The majority of average end
users never running any (non-loopback) network service should never see
or be bothered by any firewall-related question, especially not when
trying to run skype or bittorrent.
You've created a slight issue here - if they're not to be bothered by firewall-related questions, why should they be bothered by daemon-related questions? In my opinion, it should be as simple as are you on a public/private network right now (not a tough question to answer for anyone) and then NM acts accordingly.
I will admit that disabling services hadn't really occured to me as plausable. Now that I know that netstat has (almost) all the functionality that would be needed to discover which services are the ones responsible then I have to admit that I am intrigued. Perhaps the answer would be that we build location-awareness into network manager (the functionality of asking whether the netwrk is public/private etc) and then we have a set of services that listen over D-bus (or are plugins to network manager) that would proceed to change settings appropriately for your location. This way you could have on plugin that would perform firewall adjustments, one plugin that would disable the services which could be exploited (and restart them when we leave the public network?). Perhaps a "plugable" solution like this would be most appropriate and would appease all of our use-cases?
I would point out that a firewall would definitely be better for those home users who are on a dual-homed system (two interfaces active at once) the obvious common case for this would be a user on their home wireless connection with an adsl/dial-up modem attached directly to their computer (I realise that most people have a home router, but this is still a very common use-case even today). In this case the modem-interface would be considered public and therefore untrusted and so should not have services exposed on it. However, they may want to have those services still running for doing things like file sharing with their family on the wireless network. In this case, disabling the services wouldn't do. Admittedly, Samba et al are likely to bind to private addresses only, but there will be some services that don't.
Thoughts?
-Graham
