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
Such a situation would be a default misconfiguration problem, and a
very bad one since it directly affects security. I assume no package
manager installs and starts MySQL behind the user's back, at least
not listening to the outside world with the default password!
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) - belt and braces, etc....
> then having the ability to turn on a firewall in public wifi
> networks for instance that blocks all traffic to those services
> would be a bonus, in my opinion.
IMHO firewalling is a complicated and error-prone workaround, not the
real fix to the misconfiguration problem above. Which Windows end user
understands anything to its firewall configuration?
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.
As a matter of fact, I don't see what's so difficult and complicated about this:
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.
One rule, that's all. I don't see this as error prone or complicated in the slightest.
> Why should I have to edit the httpd config?
Just because it is simpler and less error-prone than configuring a
firewall. It is simpler and safer to close the security hole
you created in the first place rather than from somewhere else.
Yes, however the firewall provides you with mitigation until you realise that you've created a security hole. Imagine you're a user who's decided you'd like to start learning php for the first time: 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 :)
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...
You also missed my point about how, with a location aware firewall, I could offer a service on my home network that I don't offer to my public wifi, although I suppose that this would be achieved by turning off all network listening daemons. For that to happen, however, we'd need all those daemons to advertise to the init daemon what port that they are running on. This would be difficult for daemons which can be configured to run on different ports, although I suppose that once you've configured it to run on a different port you're now a power user and so we no longer care about you and shouldn't assist you with anything - infact, you should stop using network manager and do all your network settings using ifconfig et al. That's taking it a bit far, but it's affectively what you're saying.
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?
If you need run an insecure apache instance on a regular basis,
then I think you should always watch it very closely, not from the
distance of a firewall.
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...
> Also, that was a single use case - I can think of many more.
... but thank God they do not affect the average end user.
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? I'd say there's atleast a couple per week. How many of the answers include the line "make sure you change your config to bind to the lo interface only" (or similar)? I'd say zero. Also consider the set of users who read the answer that was for someone elses question and follow the guide without asking themselves, that brings the total number of these users up a bit more. This is still only running with my simple apache example. 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?
> A firewall isn't only about prevention access to network listening
> daemons, it's about granularity in that restriction :)
Sure. But please leave this complex granularity only to the network
administrators who actually need it.
It doesn't have to be complex. I'm talking about a straight forward "do we trust this port or don't we?" configuration - at least to start with!
The average end user has only a few network listening daemons, most of
them bound to the loopback address, while the tiny rest is shut down
when he is connects outside of home.
Out of these two questions which is the more intuitive:
You are about to connect to an untrusted network, do you want to:
- disable file sharing?
- reconfigure your firewall?
Actually, I'd say that most people know what a firewall is. Further, they don't need to know. All they need to be asked is whether it's a public or private network, we can act accordingly and they don't need to care. Sure, they could click "more info" or similar and get an explanation of why we ask, but your "average end user" can just click the appropriate response and then job done.
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.
Sorry if I've come off as quite agressive in this email, I'm told that my writing style has that affect. Please don't take it as an attack on you or anything like that.
-Graham
