Hardening Doc Update 2

[Stuart Ellis]

On Sat, 08 Jan 2005 12:00:35 -0800, "tuxxer" <tuxxer at cox.net> said:
> Please feel free to make comments, constructive criticism, etc.
> Depending upon the amount of feedback I get, I'll post a final here,
> then post that to the bug tracker.

I think that it's a really useful document, so please take these as
comments rather than criticism.    The points below mainly relate to Red
Hat or Linux-specific quirks.


General points)

- FWIW, I handled root commands in the Installation Guide by bracketing
them with su -c.  My worry with "login as root" is that it is ambiguous
and a new user may start logging in to X as root.  If you move the
sections on disabling root logins and sudo to the top you could also
promote the use of sudo for admin commands throughout the rest of the
document.

- The wheel group used by sudo can also be used in a broader way - if
you put "AllowGroups wheel" in sshd_config as well as "PermitRoot no"
you implicitly block remote logins from all accounts other than the
users you manually added to the wheel group, which mitigates the risks
of compromised service accounts (Section 1.6).  This isn't specific to
wheel, but it just reduces overhead if you reuse the group rather than
create a new one.

These definitely aren't official in any way.

- You might also want to mention the role of the built-in firewall -
even enabled services like SSH are effectively closed unless the
administrator alters the default firewall settings.

- SMTP has a specific security role as messaging service, so I feel that
it shouldn't be disabled.  Daily LogWatch log analysis, smartd disk
monitoring, SELinux context checkers, crond etc. all send mail to the
address that root is aliased to in /etc/aliases (or
/etc/postfix/aliases).  The default configurations of the SMTP services
supplied with FC are to reject connections from other hosts, so they
cannot be used as relays unless the administrator changes the config.  I
find LogWatch is incredibly useful as a early warning system on our
public-facing Red Hat servers.


Section 1.1) 

You might want to consider the role of Installation Types here - the
user can pick an Installation Type and then customise the package groups
(which ties in with role selection in 1.2).   Anaconda essentially
mandates certain packages, so you don't really get the flexibility that
you mention.   Even using the "Minimal" package group will install
sendmail, CUPS, SSH and NFS (and mDNS on FC3, I think).

"If you know that the system you are installing will be used as only a
webserver, then there shouldn't be any reason to install sendmail"

See above.

Section 1.4)

The automatic update feature of yum could be mentioned here.  The
incantation would be:

su -c '/sbin/chkconfig --level 345 yum on; /sbin/service yum start'

Section 1.5.1)

<nitpick>You've listed snortd, which doesn't ship with Fedora
Core</nitpick>.

In the GUI you have to untick the boxes on service levels 3, 4 and 5 to
really enable/disable a service.  Certain key services are also active
at runlevel 2 - sendmail and SSH.

Section 1.5.2)

I really like the idea of the serviceslist.txt.  If you put an example
listing in then users will be able to copy and paste, which should give
them more confidence to do it.

Section 1.6)

Strictly IMHO, disabling service accounts is often excessive and causes
a maintenance problem.  They can't login locally, and you can easily
block remote logins (see above).


Section 3)

I like this section (that's all).


Section 4.2)

"Then, either reboot your system, or issue the command pkill -1 sshd.
The pkill command will force sshd to re-read it's configuration file.
This will force users to login as a normal user account and then su to
root, or utilize sudo."

Are you doing this to ensure that active SSH sessions are terminated ? 
If so, it's probably worth noting.  The non-disruptive way to apply a
config. change in Red Hat/Fedora is:

su -c '/sbin/service sshd reload'
--

Stuart Ellis
s.ellis at fastmail.co.uk