Projekt: | Trisquel |
Komponente: | Live System |
Kategorie: | Leistungsmerkmalanfrage |
Priorität: | normal |
Zugewiesen: | nicht zugewiesen |
Status: | won't fix |
I think it would be good to have a firewall on the Live/installation CD. ufw comes from default in Ubuntu and only weights 766 kb and, if there is room for it, perhaps gufw (1245 kb) would be even better for all type of users. Other distributions -e.g. Fedora- also includes a (graphical in this case) firewall in the default installation. Firestarter would perhaps also be fine, though it is bit heavier (2028 kb).
We do not even have a firewall in the servers, why would the users need one in the desktops? If you want a port not to be accessible you have to configure or disable the service. Also, if you install a new service you most likely want it to be accessible, so having a firewall by default would lead to users complaining about how they installed $server and it doesn't work.
I'm not closing this by now, but unless someone gives a reason why a firewall is needed I'll do.
Very briefly since I have not much time: if other distributions are doing it I guess it should not be such a bad idea (they may be doing silly things, of course). You may perhaps leave it fully open after installation but the user will be able to close it if willing to do so before actually connecting to the net. Besides, if anyone is going to install an additional service he/she will surely be able to configure the firewall properly. An additional though about Trisquel which I was willing to explore and comment with some more time and more information: Trisquel, unlike Ubuntu, installs by default an ssh-server which I understand is listening to the net and it also seems to have running in the kernel something called openvpn and samba. I do not know for sure what sort of implication those services/programs would have when you are connected to the net but that is clearly a different situation from Ubuntu which, as other distributions do, do not install any service unless required, leaving at the responsibility of the user to install it if so they wish. I actually learnt about the ssh-server in Trisquel reading the review at Distrowatch, something which did actually surprise me, since I thought Trisquel would install like Ubuntu (except for Gnome config and other minor things) and Ubuntu, as said before, does not install any listening service -that is why they claimed a firewall was not needed for them, though they now include one. As far as I know an ssh-server is mainly to connect to your computer from outside. How many users do actually need that? -I know no one needing it, actually- and, for sure, if anyone is needing it, he/she will be able to install and configure it. Perhaps this is one more reason to have a firewall in the default installation, though the best policy would perhaps be that of other distros which do not install what people do not need.
Wouldn't removing the ssh server from the default install be a better solution?
> if other distributions are doing it I guess it should not be such a bad idea
That's not a reason unless you explain the rationale behind their decision.
> Trisquel, unlike Ubuntu, installs by default an ssh-server which I
> understand is listening to the net and it also seems to have running
> in the kernel something called openvpn and samba. I do not know for
> sure what sort of implication those services/programs would have
Then no offence, but discussing this is pointless.
> I thought Trisquel would install like Ubuntu
No, it does not. We improve what we can, and providing more functionality -like the ability to securely connect to your computer from another- is an improvement. On the other hand, redundant functionality like a firewall is not.
> As far as I know an ssh-server is mainly to connect to your computer from
> outside. How many users do actually need that?
Anyone having a network can benefit from it, and since you are requesting a networking app -a firewall-, I'm guessing a lot.
> Wouldn't removing the ssh server from the default install be a better solution?
To what problem?
> That's not a reason unless you explain the rationale behind their decision.
I am not a computer scientist, so I can not give a technical reason. However, I understand that if other distributions include it, it must be because it is useful and needed -as far as I know there are plenty of reports on the net about attempts to enter into other people’s computers, in particular when those computers are running services which listen to the net. The only distribution clearly claiming not to need such software (firewall) was Ubuntu, for the above explained reasons but, even though, they include one now. By the way, I forgot to point to the fact that in order to configure iptables through ufw in Ubuntu, you actually need to enable it, since it is disabled by default, so I cannot see what problems might cause to anyone a firewall disabled by default. I can tell you that running Firestarter GUI -something which is not recommended for security reasons, anyway- through a 3G connection you can see attempts to reaching, login or whatever to your computer (I am talking about Ubuntu) so, perhaps, closing all incoming connections is a good thing unless you actually need an open port.
> Then no offence, but discussing this is pointless.
May I know why?...and this takes me back to what you said before:
> If you want a port not to be accessible you have to configure or disable
> the service.
In order to do that you need a technical knowledge which most people do not have, to start with, you need to know that ssh is running.
>> I thought Trisquel would install like Ubuntu
>No, it does not. We improve what we can, and providing more functionality -like the ability to
> securely connect to your computer from another- is an improvement.
a) Who does actually need such functionality?
b) Is it also, perchance, an added risk, particularly when the average user will not even know they have such service running? Again, without being a technician, it seems that the philosophy in the GNU/Linux world of enabling only those services you need -for the implied risks, presumably- is shared by quite a few people -just need to google a bit-. So, the idea, I guess, is not to disable what you do not need but not to install, to start with, what you do not need.
> On the other hand, redundant functionality like a firewall is not.
In what sense is it redundant in Trisquel? I think it is actually necessary if you do not want people try to login through the running ssh-service (if I am mistaken, please correct me).
>Anyone having a network can benefit from it, and since you are requesting a networking app -a >firewall-, I'm guessing a lot.
I, like many (most?) people, use the network to send and receive mail and browse the net. I do not need at all a ssh-service.
On the whole, I think it would be better to be a little more pedagogical about the need to have such services and the possible implied risks of using them, particularly when there seems to be quite a lot of documentation on the net insisting in the need to know how to properly configure and use them.
> To what problem?
The problem of security.
> The problem of security.
If we have a security problem, could you explain how to break into a default Trisquel installation and how a firewall could fix such problem?
> I understand that if other distributions include it, it must be because it is useful and needed
Other distros include a lot of different stuff, that's not a reason. In fact, one of the basic characteristics of Trisquel is that we do not include stuff just because others do.
> I forgot to point to the fact that in order to configure iptables through
> ufw in Ubuntu, you actually need to enable it, since it is disabled by default,
If your claim is "we need a firewall" I don't see how including a disabled one would help. Also, an iptables script which you need to edit before using would be the last thing to give to those people with no technical knowledge you talk about.
> without being a technician, it seems that the philosophy in the GNU/Linux
> world of enabling only those services you need -for the implied risks,
> presumably- is shared by quite a few people
You are presuming those services imply risks they don't, and assuming the user doesn't want to share files with other computers in their network or remotely manage their computer, which is wrong.
> In what sense is [a firewall] redundant in Trisquel?
Since Trisquel is already secure, adding a firewall is redundant. Including one -even disabled- could only lead to usability problems and to the perception by the user that a firewall is needed and thus, that Trisquel is not safe.
If you have found a security hole then tell us about it and we will fix it.
The security hole is that sshd runs without the knowledge of some users.
When a user is unaware that sshd runs on his system, he might think that it's not a big security risk when his user name and password are revealed to other people. He'll not find this a big security risk, because he'll think that the only way to log-in on his computer is by physically being on it. In fact I know people who use very simple user names and passwords, which they carelessly disclose, because of this same exact reason.
I don't think that installing a firewall is the best way to deal with this. I propose to either not install or start sshd by default (preferably), or make sure that the users are warned that their user names and password can be used in such a way.
As for the firewall issue, I understand:
a) Closing all ports to unrequested connections is an additional security measure which does not harm and probably helps, particularly if you run a service which is listening to the net. For example, as I understand it, Firestarter or Ufw could close port 22 which is the port used by the ssh-server. Again, if I am wrong, please correct me. If I am correct however, then, including a firewall could be a first step to "disable" in practice that server. As said before by some of us, perhaps the best option -as for the ssh-server in particular- would be not to install it by default.
b) Using a graphical (Firestarter/Gufw) or even command line tool such as ufw (e.g. “sudo ufw enable/deny”) does need a very limited “technical” knowledge and allows almost every user to configure iptables so as to close/reject all unwanted incoming connections.
As for the ssh-server, I enclose a passage from a non-technical document which I think summarizes what I was trying to say (http://security.yale.edu/sysadmin/server-guidelines.html):
Unnecessary services or applications
Reduce risk by not running any non-essential service or application. Nearly every piece of software code has some exposure in it and you should treat every service as an eventual security risk. Ironically, even services that are designed to enhance security (e.g., SSH server software) require ongoing security attention and should not be run unless needed.
(...)
Review the manufacturers' default installation and settings. Vendors have typically enabled all services “out of the box” and thus few default installations will be secure. It's also wise to remember that startup routines under most current operating systems can be complex and services get started in a variety of places. (...)
Again, as I understand it: a ssh-server is a door to your computer so, however safe that door might be, and even in the case that Trisquel’s default configuration for the ssh-server is perfectly safe -I assume that this is the case- all software has security flaws -hence the updates- and it seems to me an additional -and unnecessary to most people- risk. My question is: is it impossible for someone to try to login into your computer if you are running a ssh-server -no matter whether he is successful or not?
Perhaps you (quidam) consider that most Trisquel user are going to need or use that service and you might be right. However, in so far as I perceive the ssh-server as an additional risk, I cannot recommend Trisquel to the type of user I know -none of them will need nor use it, for sure, and most of them will not even know what it is-. So perhaps the thing is considering to what sort of audience Trisquel is intended.
As for the risk Mampir refers to, Trisquel’s default configuration for sshd-config comments the line “PasswordAuthentication yes”, so perhaps -I just do not know- it does not allow users to login using passwords (only using public keys?).
> As for the risk Mampir refers to, Trisquel’s default configuration
> for sshd-config comments the line “PasswordAuthentication yes”, so
> perhaps -I just do not know- it does not allow users to login using
> passwords (only using public keys?).
I've recently used SSH to log-in on computer with a default Trisquel 4.0 system. I didn't need to configure anything, and I did it using only user name and password.
> I've recently used SSH to log-in on computer with a default Trisquel 4.0
> system. I didn't need to configure anything, and I did it using only user name > and password.
From my point of view that situation is clearly more worrying. How many people use weak names and/or passwords? I think this document is of interest: http://www.cisco.com/web/about/security/intelligence/ssh-security.html
and it seems to suggest that Trisquel policy of installing ssh by default should be revised.
Mampir, taking into account what you said, if you are using ssh in Trisquel, check the fact that default installation allows Root login -most people consider this very unsafe although someone claimed that it represents no risk in Ubuntu-like systems since root user is disabled (no idea)- and also that fact that it allows X11 forwarding which is also considered an added risk.
> If we have a security problem, could you explain how to break into a default Trisquel installation and how a firewall could fix such problem?
I just don't think so many people actually will use the ssh server to justify having it on the default install. Thus it will only give an attacker an avenue. My suggestion was instead of the firewall proposal.
Hi. I'm a new Trisquel user, but an old(!!!) *nix user and sysadmin.
Depending upon the default configuration settings (I haven't checked, but I will). running sshd on a machine operated by a naive user is most certainly a security risk. Naive users often employ easily guessed username/pwd combinations that are easily cracked with brute force/dictionary attacks.
Scanning the auth log on most any machine that has been connected to the net long enough to be found (and in a way that makes finding it fairly easy) will almost certainly reveal numerous attempts at unauthorized access via ssh. If your username is "bob" or "juan" and your pwd is "free" or "libre"--it won't take the crackers very long to get in.
The fact that root logins may be disallowed doesn't make any difference: In the kinds of cases we are discussing, "bob" is probably the administrative account, so once the cracker is in, sudo will work perfectly.
As others have pointed out, installing a firewall isn't the best solution. If ssh is going to work, the port has to be open, so a firewall won't help.
On any machine with sshd running, I also run denyhosts. Problem mostly solved.
Of course, unsophisticated users may also have trouble configuring software like denyhosts...
Anyway, I think the OP has pointed out a valid problem.
~Doug
> If ssh is going to work, the port has to be open, so a firewall won't help.
Ok, but just to know: if you setup the firewall so as to close all unrequested incoming connections -it should close all ports, I understand- will still the ssh-server be a risk or it will become just unusable and therefore not a risk?
By the way, thanks for your interesting comments.
PS.- My proposal of the firewall had nothing to do initially with the ssh-server issue, I was just proposing it as an additional protection. The ssh-server thing came about as a somewhat related issue. Anyhow, I am glad that it is being discussed.
"...if you setup the firewall so as to close all unrequested incoming connections -it should close all ports, I understand- will still the ssh-server be a risk or it will become just unusable and therefore not a risk?"
That's right. Close all ports (including TCP port 22, the ssh default) and ssh is unusable.
But it doesn't really make sense to both enable ssh *and* block the port, does it?
BTW, I just verified that the default ssh configuration on my 4.01 LTS permits ssh login using PAM. I logged in using my personal account and used sudo to write to the root directory.
This isn't a problem for experienced *nix administrators or geeky users, but it certainly opens a potential security hole for inexperienced users.
EDIT: I wasn't specific enough. I should have said that it doesn't make sense to close all ports (to traffic from the outside world) and then enable *sshd* (the ssh server). The ssh client (used to logon to other hosts) is a separate program and firewalls can be configured to allow outbound traffic while blocking inbound.
~Doug
> That's right. Close all ports (including TCP port 22, the ssh default) and ssh is unusable.
Thanks.
> But it doesn't really make sense to both enable ssh *and* block the port, does it?
No, not really. The only situation I can think that might be useful is for users who only need the ssh-server occasionally (e.g. staying away from home/office). In that case the server would be set up and ready to be used by just opening the port when needed. However, taking into account all what has already been said, it seems better not to include it in the default installation.
EDIT:
> EDIT: I wasn't specific enough. I should have said that it doesn't make sense
> to close all ports (to traffic from the outside world) and then enable *sshd*
> (the ssh server). The ssh client (used to logon to other hosts) is a separate
> program and firewalls can be configured to allow outbound traffic while
> blocking inbound.
Thanks, this is informative again.
Marking this as "won't fix". Please re-open if new information to this discussion can be provided.