Default Fedora installation suffers from egregious configuration flaw

[Joe McManus]

As a compromise why not change IP Tables to only allow connections
from the local subnet to SSH on reboot/firstboot ?

i.e. DHCP gets IP address 192.168.1.200 with subnet mask 255.255.255.0
so connections are allowed in from 192.168.1.0/24.


-Joe


Message: 8
Date: Thu, 19 May 2011 07:18:38 -0600
From: Kevin Fenzi <kevin at scrye.com>
Subject: Re: Default Fedora installation suffers from egregious
      configuration flaw
To: <security at lists.fedoraproject.org>
Message-ID: <20110519071838.5f49864a at ohm.scrye.com>
Content-Type: text/plain; charset="us-ascii"

On Wed, 18 May 2011 17:35:38 -0700
dirk cummings <sexynaya2010 at hotmail.com> wrote:

>
> On a default install of Fedora 14, and also the latest release
> candidate for 15, the user is presented with:
>
> An iptables rule that opens port 22 to the worldsshd service
> automatically startedsshd_config with default option: PermitRootLogin
> yes It's like every new install comes with the keys to the castle
> hanging on outside of the door for anyone who comes knocking.
>
> I find this situation a serious oversight in light of the fact that
> Fedora obviously values security (like selinux, or how the installer
> forces a minimum password length, etc)
>
> Any experienced linux user will know to check iptables and disable
> unnecessary services, but I wouldn't expect this from a new linux
> user (exactly the people the refreshed GNOME experience is supposed
> to attract).  I think the default configuration should be in the name
> of security, and sshd should not be listening on a default port with
> an open rule with root login enabled.

The reason for this has been headless installs. Ie, if you install via
vnc or the like, and finish the install and reboot and don't have
access to the physical console, ssh is your only way to access the
newly installed machine and setup accounts, etc.

If someone can come up with a solution that covers this case, we could
revisit this, but it's not an case thats easy to fix in any kind of
clean way. ;(

If it's brute force attacks that are the vector of concern, perhaps we
could look at a default hashlimit rule in front of the ssh. (ie, 1
attempt per minute or the like).

kevin