Managing Security

Security is a huge subject. The information we provide here is based on our experience, and you follow it at your own risk, we make no promises, warranties, etc., implied or otherwise. The Center for Internet Security publishes best practice guidelines tailored to all the major platforms as well as many important services: apache, various SQL database servers, etc. The Internet Storm Center collects and disseminates information about internet security threats on an ongoing basis, as well as providing useful tools for combating a variety of threats.

See also:

• CIS benchmarks for Red Hat Linux 5 (for RHEL 5) (i.e. Fedora)
• CIS benchmarks - pick your Operating System, Network Device, or Application
• CIS Benchmark FAQ

Practical, usable security

Security isn't secure if you won't use it! The initial configuration sequence for our minimally reasonable, responsible, and usable configuration is given here. Note that all the instructions are command-line, as GUI interfaces are much slower to use, and not generally appropriate for servers.

1. On initial install, your distribution will ask you to create a user account that you will use to administer the machine.
   • Each administrator needs their own account, as they will customize it to their own working style, and as the security system will log their activity. The user account is important because you should really never log in to your machine as root unless doing disaster recovery or for some other specialized purpose. So go ahead and create the account immediately. Let's call this account rosta (for sentimental reasons.)
2. You need to add rosta to group wheel.
   • Get your spiffy new linux box installed and configured per the distribution's instructions, and boot it into the OS. The configuration instructions may already have had you add rosta to wheel, but if not, here goes:
     1. Log in to root (this is one of those times.)
     2. add rosta to group wheel

        usermod -a -G wheel rosta

        (don't forget to take a minute or two now to read the usermod man page, as per RtFM)
3. follow the instructions under UseSudo to setup sudo
4. Using sudo
   1. follow the instructions under SshD to setup sshd on your server and ssh clients for any workstations that will access the server.
   2. install DenyHosts
   3. take a first pass through the relevant CIS (Center for Internet Security) benchmark, so that you are at least aware of all the issues involved.

Use Sudo!

[edit]

sudo is a system that (1) provides you with a log of everything you do as superuser, and (2) allows finer grained control over who can do what than simply putting trusted users into group wheel. Really, the only time you should ever use the su command to act as root is to setup sudo.

Getting started with sudo

We provide a crash course in setting up sudo , however, don't forget to RtFM as well, as it is your security that is on the line, not ours!!

The configuration file for sudo is /etc/sudoers. You have to use a special command, visudo, to edit /etc/sudoers . You can make visudo use your favorite editor (rather than vi ) by setting the environment variable EDITOR in your shell before invoking visudo , but that's properly the subject of another topic.

1. Log in to your privileged administrator account (we're calling it rosta for sentimental reasons.) Enter

   su

   at the prompt, followed by the root password to become the superuser. This is marginally better than logging in to the root account to work on your server...
2. type visudo at the prompt. An editor will open with the default configuration of /etc/sudoers. Work your way down to the line below the comment that says "Allows people in group wheel to run all commands" (don't choose the one that says "Same thing without a password" - you can do that later, if you decide to configure SshD to disable password logins and opt for certificate or public-key logins instead.)
3. make a copy of the existing line (much easier IMNSHO when scanning diff reports of configuration files later), then remove the comment # and space at the beginning of the line. Save your work. Log out and back in and check to be sure that you did things correctly by using sudo to acquire superuser privileges:

   sudo -s

4. Most of the time, you'll want to just prefix each command with sudo, as asking for superuser privileges is a dangerous habit.

Better use of sudo

It's really better not to just put folks in wheel and let them have full privileges. One of the wonderful things about sudo is it's ability to confer heightened privileges within a limited scope. So you can give privileges to mount and unmount media, but not other things, or to restart certain servers, for example.

back to top

denyhosts

[edit]

denyhosts is a python daemon that detects and thwarts brute-force ssh attacks. The configuration script, by the way, needs to be /etc/denyhosts.conf, but seems to be installed as /etc/denyhosts.cfg in some versions. Just read and follow the comments in the configuration file.

back to top

Ports & iptables

[edit]

On any new server, you'll need to ask to have any ports you want accessible from off campus explicitly entered into the university's firewall setup. Send email to the designated contact (this should really be a link to the appropriate entry in the IT directory, you know..., currently, for us, that's richard.uhler@csueastbayHYRUQAPZ.edu) with the request. You'll need to explain what ports you want open, and why.

One way to learn what we usually have open is to look at a sample IpTables configuration file with lots of comments and figure out what services apply to your server. Always ask for ports 50000 - 50500, as those are the Math and Computer Science research ports - ports on which we are free to take services up and down at will, but are not preallocated to anything in particular. If you reserve a particular port on a particular server for some long term use, you should add that info to the relevant entry in the LabData topic.

In combination with good security practices set out by the CIS guidelines (as well as those discussed in this twiki) such as using DenyHosts, ModSecurity, SpamAssassin, ..., having some externally open ports, even the research ports, has not proven to be a major issue.

Speaking of iptables (a firewall that runs on linux servers), we run iptables on all our machines. Don't open any ports unless you know what/why, even if a program wants you to do so. Ask for help. /etc/services lists all the port numbers with an incredibly terse description of the related service, but it will give you a key word to Google for.

back to top

sshd, the secure shell daemon

[edit]

The ISC guidelines cover most of the important ssh configuration information. We provide some more detail to help you get going, as well as explain how to prevent remote connections from getting dropped all the time!

Configuring ssh

Password authentication is inherently unsafe, not to mention a pain-in-the-you-know-what. Other forms of authentication, such as public key or certificate authentication may be a much better fit, depending on your lab setup.

The configuration we show here is for public key authentication (no passwords), with PAM (pluggable authentication modules) account and session checks. We show only the sshd_config settings we change from the default settings, and group them a bit differently than the order they appear in the file to make it easier to explain.

# HJH, duh!
PermitRootLogin no  

# HJH, per CIS_RHEL_Benchmark
IgnoreUserKnownHosts yes

# HJH, no password authentication
PasswordAuthentication no

# HJH, disable s/key passwords
ChallengeResponseAuthentication no

# HJH, enable PAM session processing
UsePAM yes

# HJH, poll client every 30 secs, so router doesn't
# drop connection. Settings give 25 minutes of inactivity.
ClientAliveInterval 30
ClientAliveCountMax 50

# HJH, as per CIS_RHEL5_Benchmark
Banner /etc/issue.net

Be sure to review the pam related packages to be sure that you have the appropriate ones installed on your system. We'd love to give you a canonical list, but they get re-factored all the time.

Configuring public-key authentication

The specifics vary somewhat according to the specific protocol, but the general outline is:

1. generate the private/public key pair on the laptop/workstation
2. upload the public key to the account on the server, and put it in the target account's .ssh directory with the appropriate name

back to top

[see also ManagingUnix]

---