Home ›

Securing UNIX Systems

 

What can enhance the security of your UNIX system?

1) Security starts with control over physical access. Nothing can be done in software to protect a system which is physically accessible to unauthorized users.

2) Dual-boot systems are inherently insecure because the operating system that is not running at any given time cannot protect against the one that is.

3) Security is generally inversely proportional to access. The more different users that have access to your system, the more security issues you will have to deal with. In other words, minimize the number of users where possible; if you cannot do that, expect lots more trouble and work to maintain the system.

4) Most systems are compromised remotely, so providing the absolute minimum number of remote services helps to reduce the probability that an exploit will be found for those services.

5) A remote service does not become secure just because you really "need" it. If you run a web server, your system security is not enhanced by it, so it better be the primary function for that system.

6) If you manage a multi-user machine, know your user base; not by name only, but by activity profile. Know who accesses the system, what applications they run, and when they are generally on the system. You will not be able to spot unusual access or activity patterns if you don't already know the usual ones.

7) Don't install software that is not required. Ideally each system should have a primary function, and be reserved for that use. The more software you install, the higher the probability you will install exploitable software.

8) Resist the temptation to provide large numbers of services from a single system. If the system is compromised and must be taken offline, you will avoid turning a big problem into a huge one (ie you will not have to take services offline that were not exploitable while repairing the one causing the trouble).

9) Keep all installed software up to date. Rarely is it justifiable to run releases more than one revision old. Check regularly (at least once a week) for patches to your system and install them promptly.

10) Never make "guest" accounts or allow any account to be used by multiple people. It goes without saying that accounts without passwords are unacceptable. Solving problems by making one account available to multiple users is really only defeating the security measures built-in to the operating system.

11) Expire accounts as soon as possible when access is no longer required. Remove software when it is no longer in use.

12) When you are purchasing a new system, demand vendor supplied and supported secure remote access facilities. If the vendor is unwilling to supply and support a secure access service like OpenSSH, refuse to do business with them. Let them know their lack of concern for secure remote access reflects the prespective that security is your problem, not theirs.

13) Implement a firewall. This should be a standard facility in any modern UNIX implementation. If it is an "extra cost" option, you can be sure security is at best an optional part of the OS.

14) Setup separate user/distribution file systems. Most UNIX systems can mount file systems with a "nosuid" option which prohibits the execution of setuid programs on that file system. All user-writeable areas (like /home, /tmp and /var/tmp) should be on file systems mounted nosuid.

15) Do not allow remote access to the root account (an option in ssh). Always use a normal user account for remote access, then su to root locally. This leaves an audit trail of who was running root when.

16) Accept the fact that to prioritize security means to compromise convenience.

17) Performance of monitoring activities:

System administrators should audit their systems at least once per week. Routine review and comparison of data is important for determining "normal" activity. Out-of-the ordinary activities will easily be detected if systems are regularly audited, and auditing provides a way to help determine if damage has been done to the system. System auditing should complement, rather than replace, other security measures (i.e. policy, password management, use of firewalls, use of malicious code protection software, performance of back-ups, presence of appropriate physical security measures, etc.)

Developing A Baseline

Determine what is normal activity- collect (document) as much data as possible during periods of expected low, medium and high activity and use the data as your baseline, and for comparison during future audits.

  • Know the difference between successful and failed logon attempts.

  • Know which ports should be open/active.

  • Be aware of permission, file, or registry changes.

  • Know who has permission to access the system.

  • Document user and group accounts and permissions, review periodically for appropriateness, and monitor non-active user sessions.

Performing an Audit

  • Schedule audits, determine how they are to be performed and how long the data will be retained.

  • Use verification procedures to determine that data are accurate.

  • Prepare auditing tools on removable media (do not store them on the system).

  • Keep auditing tools secure.

  • Use a dedicated, secure system for data review/audit.

  • Vary the times the audit is performed.

  • Automate your audits.

  • Report suspicious activity to the Information Security Team.

In General

UNIX uses log files to record audit trails:

  • /var/run/utmp- current login "snapshot"

  • /var/log/wtmp- login-logout history

  • /var/log/btmp- bad login history

  • /var/log/messages- messages from the syslog facility

  • /var/log/secure- access and authentication

Activate user account auditing.

Activate or create wtmp and btmp and ensure that only root can write to them.

Edit the .tcshrc or equivalent shell resource file so that the "who" command is executed when a new shell is started.

Use syslogd, the system log facility (/etc/syslog.conf), to provide centralized support for logging system messages (timestamp, hostname, program name, message) and to provide support for remote logging.

Review the messages file for system messages- /var/log/messages.

Install/configure TCP Wrapper to monitor incoming requests for Internet services (ftp, telnet, finger, ssh, etc.). Messages from TCP Wrapper are stored in the /var/log/secure file.

Configure the access control lists (/etc/hosts.allow and /etc/hosts.deny) to allow or disallow services to hosts.

Audit and keep a list of all suid and sgid files and copy list to removable media.

Use lsof to find information on open/hidden files.

Look for hidden disk space.

Run /etc/inetd.conf, netstat, and lsof to identify network connections.

18) Performance and storage of appropriate back-ups:

  • Determine which method will be used to back-up (tape, disk, server, other location).

  • Determine if full configurations or partial (incremental/differential) configurations will be saved.

  • Choose the software which will be used to back-up systems.

  • Determine which administrators will have primary and secondary back-up responsibilities.

Back-Up Procedures

Use tar, dump, dd, cpio to back-up to relative (current) or absolute paths:

  • tar- used to create an archive, copies contents of one directory to another

  • dump- gives option to archive full or incremental file systems; supports local UNIX file systems; can only dump an entire file system

  • dd- provides an image of the disk (bit-by-bit); ability to copy tape to tape; ability to read from non-UNIX platform or UNIX systems with different byte order

  • cpio- used on systems that do not support dd; copies files to and from a cpio or tar archive; ability to read from non-UNIX platform or UNIX systems with different byte order

Use restore to read archives created by dump.

Run dump after an upgrade or reinstallation of an operating system.

In General

  • Schedule back-ups to run regularly.

  • Run full back-ups at least once a week.

  • Document back-up procedures.

  • Verify and log that back-ups were completed successfully.

  • Maintain a written log of tape usage and properly label tapes.

  • Write protect tapes as appropriate.

  • Check every tape before usage.

  • Determine length of time tapes will be saved and if they will be reused.

  • Keep recovery media safe (off-site).

  • Practice, or test, system restorations (files, directories, systems) before you actually need to perform a real restoration.

  • Seek training in use of back-up software if appropriate.

  • Review manufacturer recommendations for tape and tape drive maintenance.