Red Hat Bugzilla – Bug 437811
sshd defaults "on" on default installation ( also in previous releases )
Last modified: 2013-01-09 23:36:43 EST
Description of problem: sshd defaults to on ( SSH server running why??? ) and on top of that the sshd port defaults to open ( hased in s-c-f ) so if noob users gets himself a copy of Fedora installs it by pressing NEXT NEXT NEXT etc done and *NEXT* through firstboot he's vulnerable to bruteforce attacks. Version-Release number of selected component (if applicable): This has been going on for some releases.. How reproducible: Sit down with somebody who has no understanding of computers and make them install Fedora... Without intervention Or just next/ok/done your self through the installation like any noob user would do... Steps to Reproduce: 1. 2. 3. Actual results: sshd is running... and s-c-f leaves the sshd port open (port 22 ) Expected results: sshd should not be running... and s-c-f should have port sshd unhashed.. Additional info: I guess there must be some good reason for this. From my perspective this is an security risk and fails QA for enduser...
Please read the discussion in bug 136289 and bug 147557 But system-config-firewall should not leave the port open by default. That seems to be a regression.
anaconda is telling lokkit (system-config-firewall) to open the port in firewall.py. anaconda should not open services or ports by default. BTW: anaconda is not using the service option of lokkit. Reassigning to anaconda.
Let me just point this out before I get the some *words of wisdom* from some of those persons that commented on the bug 136289 and bug 147557 bugs. Today we have the tools to make a "headless respin" !!!!
The fact that tools exist to allow people to respin doesn't mean that we should be trying to push lots of users in that direction. Especially as that then requires them to have another Fedora machine available to do the build on. Also, with the rise of virtualization, there are even more cases where you want to have ssh available rather than depending on the fact that there's a console.
Sorry Jeremy need to go head on head with you on this one. Have asked Fedora QA board to take this to issue up on next meeting with input from Fedora-Security team. Then after this has received a proper discussion a QA board member can close this with good explanation why or this can be fixed..
sshd in many cases should default to on. Anyone doing servers will want it this way. Home users on the other hand may not want sshd running as they prefer to get rooted via avahi or samba or that web server they left on by accident. For anyone that wants sshd running, there is a fair amount of configuring that you must do before you leave it alone: disable protocol 1, setup login group, add login accounts to that group, create an allowgroups entry in sshd.conf, setup tcp_wrappers, setup iptables, setup the pam stack, turn off ipv6, etc. We are looking to address this complexity with some lockdown tools in the F10 time frame. I think we could do a couple things to make the current situation better, but I don't think it should be disabled by default.
Actually, protocol 1 has been shut off by default since Feb of 2008.
Steve What ever the user turns on after he has been delivered a secure product is not our responsibility, but it is our responsability when we deliver unsecured product to the end user in the first place. And yes if only sshd was disabled and the end user had to go through the steps you mentioned to enable it or simple we would not ship sshd by default and the user who is actually gonna use it would simple have to select it in the package selection in anaconda and install not a rocket science is it but no nobody can touch sshd. Is this lockdown yet another step to M$ way of doing things.. Selinux + policykit == bad, selinux + policykit + yet another lockdown == Worse