So, you need to keep your Unix System Secure do you?

This article just to get you started; it’s not exhaustive. Please note that this is just a guide to get you started with security under Unix or Linux.

You should assume that every distribution is shipped insecure.

Following all the advice in this document will not make your system "absolutely secure" (there's no such thing in the real world) but will make it more secure than most others. Think of it like the neighbourhood watch; it doesn't so much prevent crime, it just makes it go elsewhere where pickings are easier.

You are the owner of a newly set up system; therefore you are the system administrator of a Linux/Unix box connected to the Internet. And if you have a global (not private) IP address, you are visible to the world. Possibly you are going to be the only user? Even if so, resist the temptation to run as root all the time; set yourself up a non-privileged account for normal day to day use. Why? Because mistakes under non-privileged accounts generally are not too serious; mistakes made as root can destroy a system. You have a responsibility to all of your systems’ users to keep your system secure. If it succumbs to intruder action, all your users' data is put at risk.

You also have a responsibility to all the other users of the local network; maybe less directly, the Internet. If your system succumbs (or is ‘compromised’ in computing jargon), it can be used to launch attacks on other systems elsewhere. If the root account is compromised on your system then every other system on your local area network is almost certainly compromised immediately. Not only can the intruder log into other systems remotely from yours, but passwords and usernames can be captured from other systems on the network. If you are lax in your security and as a result the rest of your group loses its machines you are not going to be popular! Spend at least a fortnight getting familiar with your brand new system. Understand what the common files and commands really do (but take care how you experiment and certainly never experiment as root(!).You need to be familiar with your particular machine and operating system to know how to fix the problems described later on. The problems are often generic; whereas the fixes are often machine-specific.

Take backups!

1) Make sure you know how to take full system backups.

2) Are any of your system partitions larger than your backup devices? If so, make sure you know how to take multi-volume backups.

3) Make sure you know how to take periodic (or incremental) backups as well.

4) Plan a regular timetable for backups. How often? How much can you afford to loose?

5) Keep to it!

6) Make sure you know how to do a restore that includes the main dump and subsequent incremental dumps. (Using multi-volume backups if necessary.)

7) Practice!

8) Keep your backups away from the machine.

9) Have more than one backup so that you are never in the situation where your only backup is lost or stolen with the machine it is a backup of.

Common Mistakes

Do you have any accounts with blank passwords? Look in /etc/passwd and any shadow password file your system might have.

Do you have any user accounts with the same numeric user ids?

Are your NFS exports correct? The design of NFS (network file system) can trick administrators into making dangerous mistakes. The default behaviour (without the correct options specified in their configuration files) is often to export read-write to the entire Internet!

Are your NFS imports correctly set up? Are imports from machines you don't trust marked nosuid and nodev? Some systems permit users to do NFS mounts (either directly from the command line, or through the automounter). You should either block this or at least ensure that user mounts are nosuid and nodev.

Are you using YP (also known as NIS) to share information between machines? If you are, check to see if your YP server(s) can be configured only to pass information to known hosts. Slightly more subtly, but important nonetheless, check to see if your YP clients can be constrained to accept information only from known hosts. Some vendors supply hooks for one or the other but not both. Are you still using the default (and therefore well-known) domain name noname?

If it exists, does your /etc/hosts.equiv file have safe contents? And how about your users' .rhosts files? (Warning: A "+" means that any machine on the internet is trusted.)

Does your X server start up without any X authorisation checking enabled? Run the command xhost and see what it says. Anything more than "access control enabled, - only authorized clients can connect" is cause for concern.

Are you offering an anonymous FTP service? (Possibly inadvertently?) Keep in mind that many network services are started by default when a system is set up. So -ftp to your own machine, try logging in as user anonymous and try to get a copy of your machine's /etc/passwd file. If you can do it, then so can anyone else! Even if you can't, do you really need to provide anonymous FTP?

If you do have to offer an anonymous FTP service, can it be used by third parties for uploading files, i.e. as a drop-box? Check that there are no directories to which you can upload a file and then download it again. Warning: if you are found with certain types of pornography on your system, you are guilty of a serious crime. No intent on your part need be proven in law.

It is wise to switch off explicitly any network facilities that you do not intend to use.

Check your start up scripts and the /etc/inetd.conf file to determine what network services you are providing. Remove or comment out those you do not require.

Run netstat -a and rpcinfo -p to see what TCP/UDP ports and RPC services you have open.

We have already covered FTP and TFTP. If you are providing FTP (anonymous or not) make sure that none of the non-user (anonymous) accounts can make incoming FTP connections.

If you do not intend to receive incoming mail on your system then disable the network mail (SMTP) listener.

Decide if you want to support external use of the finger and rusers commands to scan your machine's users.

Who can watch you type in your password?

If you only ever log on to your computer at its console then this section need not concern you.

Potentially, any machine on the same Ethernet as your machine can be made to read every piece of data you send out over the network, such as your userid and password. At least, if you use older protocols over the network, such as http, ftp, telnet, pop3, imap, smtp, remote login (which do not encrypt any passwords and usernames sent across the network). More modern equivilents (https, sftp, ssh, and pop3/imap/smtp over ssl) encrypt their passwords and other data and are much safer).

Typically, this means every machine in your organisation or site can read any data you transmit or receive over the network. This is also true across the public internet. So:

Think before you log in over the network, especially as root.

This is where judicious use of .rhosts files can be useful.

Use SSH rather than telnet or rsh. This provides fairly watertight security from network attacks, but doesn't help if the source or destination host is already compromised.

Read the relevant CERT advisories.

The CERT is the ``Computer Emergency Response Team''. It was set up after the early ‘Morris’ worm devastated the Internet way back in 1988 and made people aware that online security was important. (The Worm was a program written by Robert Morris Jr. that used Internet connectivity and certained security loopholes to spread itself from one Unix machine to many others. More recently, most such ‘worms’ affect Windows hosts, but Unix/Linux ones still appear from time to time.

It publishes ``advisories'' about specific security holes from time to time. These are published once the vendors concerned have produced ‘patches’ – (updates to software components which fix a given vulnerability), usually several weeks or months (and sometimes even years) after the holes are known to the enemy.

Install the appropriate security patches for your system. For Linux distributions, the site from which you obtained the distribution will advise you of such updates.

If you buy your Unix system directly from a vendor, arrange maintenance through that vendor. If the vendor or reseller proves to be useless, other online support services may be able to help. Educate your users to keep their accounts secure. Users should...

Never lend their password and usernames to someone else.

Be careful about what other users they trust.

Pick good passwords (the longer and more complex, the better)

Users should not leave their passwords lying around, stored in files or mobile devices which others have access to, written on a Post-It note, stuck to the monitor etc.

(This all sounds easy. Now consider what you will do if you discover it is your boss breaching these guidelines.)

Are your users secure from each other?

Your users in a group you are part of may all trust one another and may all actually be trustworthy. But if one user's account gets compromised and your system is internally insecure then all your other users are immediately vulnerable.

Do any of your users keep world-writable files?

Do any of your users keep passwords in world-readable files? (In fact, users should not keep passwords in any files. If root on your machine gets compromised then the contents of the file are exposed and this gives the enemy a trivial route into other systems.)

Service detection on a Unix system: The netstat command can provide details of what services are running on a Unix/Linux system and what processes are responsible for them. Whereas the lsof command is like a 'souped up' version of netstat, giving extra information about each process.