This provides a quick summary of things that need doing.


The aim of this page is to list the things that typically need to done on a long-lived virtual.  For a short-lived (throw away) virtual you can probably dispense with these issues, though some of them will still be relevant to the people who created the image.

Note that many of these tasks can be performed using Chef and the NeCTAR-cookbooks "setup" recipe, as described here.  This avoids you having to figure out (and remember) how to do these things on your particular Linux distro.

Managing user accounts

The NeCTAR recommendation is to keep the number of accounts on your virtuals to a minimum.

You should disable root login over SSH and password authentication over SSH. Password login over SSH is a common attack vector. Disabling password authentication is a simple way to avoid this type of attack. Ensure the following lines are in /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no

You should also also ensure that you have an emergency recovery account ('root' or an account with sudo rights) that you can use to log in via the VNC console on the NeCTAR dashboard. This allows you to recover from a networking issue without rebooting the machine. This account should have a strong password.

If you decide not to use 'root' as your emergency recovery account, then it is wise to disable the password for the 'root' account.  One way to do this is to run the following command as root:

passwd -l root

But whatever you do, do NOT leave your 'root' account with no password. That leaves your machine horribly insecure, even after disabling SSH root login.

(If someone has some good ideas on integrating VM-level access control with other access control (e.g. AAF, University-level LDAP) please contribute them.)

Set up and use sudo

It is bad practice (dangerous!) to do tasks requiring administrator privilege from a "root" shell.  Set up "/etc/sudoers" so that the appropriate users can run "sudo".  It is a traditional to grant sudo access to users in the "wheel" group, but with Chef-based systems the "sysadmin" group is used instead.

The advantages of using "sudo" rather than a root shell include:

  • You get a log of the commands that were run using "sudo". This is useful for audit purposes.
  • You avoid the problem of forgetting that you are in a root shell and doing something dangerous / destructive.
  • The "sudo" credentials can be set to time out without locking the screen or logging you out.

Setup a firewall inside your virtual

Openstack security groups are not a substitute for effective firewall rules. There are tools that you can use to simplify the process of implementing a good set of firewall rules (see
(If someone has a good guide for some common techniques like rate limiting or intrusion detection with some of the more user friendly tools that sit on top of iptables, then please contribute them.)

Applying operating system patches

Install and configure yum-updatesd (or equivalent) to apply (at least) security-related patches automatically.

Configure root email

Various system-level services (typically 'cron' tasks) report their activity by sending an email to (by default) the "root" account on the local system.  Unless someone is watching this, important events can go unnoticed.  Generally speaking you need to:

  • Create a mail alias (e.g. in /etc/aliases) to forward "root" email to a person or mailing list.  Typically this will be off-system.
  • Install (if necessary) and configure a mail transfer agent (MTA) to relay out-bound email to an appropriate external SMTP server.  Postfix is a good choice on typical Linux distros.

Checking logs

Implement 'logwatcher' or similar to analyse and summarize the system logs.  By default, 'logwatcher' will report on things file system levels, successful and failed user access attempts, use of "sudo" and other security events.

If you are implementing your own service, consider configuring 'logwatcher' to scan the service log files.  Also consider adding the service log files to the system's log file rotation scheme to help keep disc usage under control.

Implementing backups

The important topic of backups is covered in:

System Hardening

If possible, run SELinux in enforcing mode.  (This is the default for RHEL-based Linux distros!) SELinux may entail some short term pain ... and a learning curve ...

Other system hardening tools:

  • AppArmour - an alternative to SELinux

Other things to do:

  • Lock down SSH access.  Key-only access is best, with personal accounts and personal keys. (NeCTAR recommendation!)
  • Turn off root login ... except for emergency use via the management console. (NeCTAR recommendation!)
  • Configure "sudo" ... so that administrators don't need to login as root.  (Obviously, only grant administrator access to people who know what they are doing.)
  • Require everyone with "sudo" access to use strong passwords for their accounts.
  • Make sure you stay up to date with security patches.  If possible, configure your virtual to apply (at least) security patches automatically. (There is a risk that unattended patch application will cause something to stop working at an inconvenient time, but this is better than being hacked!)

Things to avoid:

  • Don't set up an FTP or Samba service unless you really need to.
  • Don't run a website / wiki / content management system unless you really need to.  Use someone else's.
  • Don't enable WebDAV unless you really need to.

These things can be done safely, but there are inherent risks if you make a mistake in the configuration, or if you don't keep up-to-date with security patching.  (And sometimes these measures are insufficient!) 

Note that the consequences of you running an insecure system may ultimately fall on the people who use your machine.  For example, it could become a source of virus infected files, or a vehicle for spreading browser malware.  If you are providing a service, you have a moral responsibility to do it safely.


Linux systems are generally thought to be less vulnerable to viruses than Windows systems, but this does not mean that you can ignore the issue.  The first line of defence is to keep "bad files" off your system in the first place.  For instance, don't run services that accept data from users, especially users who are not adequately authenticated.  However, if you do need to do these or similar things:

  • Try to confine the potentially infected content to specific areas.
  • Use a Linux-specific virus checker to detect and quarantine infected files.
  • If possible / appropriate, enable virus checking at the point at which files are accepted.

If you are looking for a free anti-virus for Linux, take a look at ClamAV.