In terms of security measures, there are few differences between a Unix (Solaris, AIX, HP-UX, Linux, *BSD, etc) server and a client. Both by default run many services, and thus both must be considered servers. Any servers connected to a CLASnet network should follow our server connection policy. Those outside our college should consider drafting a similar policy.

Unix servers are by design multi-user machines. Even a machine with a single user on the console actually has multiple user-ids running at any time -- a person on the console, a printer daemon, NFS users, a web daemon perhaps, and the super-user root. Any of these accounts can theoretically use security holes in the operating system to crack root, or become the super-user. Once root is compromised, the cracker may gather passwords from other users on the system (via UFC-Crack or modified system binaries), from the network (via a sniffer), or use the machine as a jumping off point to attack other systems on or off campus.

How do we defend/secure against such attacks?

The best way to increase security is secure your current system, then limit exposure against future break-ins.

Start with a known secure version.

You need to make sure the machine hasn't already been compromised. The best method for this is to install the OS in single user mode while disconnected from the network. If your install requires networked access (ie, NFS-server or "JumpStart" install), create a non-routed network that only the existing server and newly installed machine can access.

Inventory your OS

Compare your installed operating system against a known-secure version. The CD your OS came from is a good starting point. For RedHat Linux systems, you can use rpm -v to verify each installed file/package against their database.

After your OS is known secure, make an inventory. We recommend the tripwire package. You should modify its database to monitor all SUID binaries, as well as commonly used programs.

Limit exposure to rogue SUID binaries

Many exploits require fooling an existing privileged program into creating an SUID shell with the same privileges that the cracker can then use. If you can limit where SUID programs can reside, you can severely curtail this type of attack.

System SUID binaries usually reside in /usr and /. Make those two partitions unwritable by normal users. Next, make the user-writable partions nosuid. This includes:

• /tmp
• /var
• /usr/tmp
• /home
• /usr/home

For Solaris, this involves editing /etc/vfstab and adding the nosuid option to each filesystem in question, then rebooting. As an example:

 swap    -       /tmp    tmpfs   -       yes     nosuid,size=32m
 

Limit user database to secured accounts with known owners

Many systems, such as SGI, come with a variety of guest or demo programs with no or well-known passwords. These accounts should be removed or given a new password. Though these accounts may not have super-user status, a cracker can use these accounts to access your system, and then use other bugs to gain super-user access.

Similarly, you should limit the number of people who have accounts on your system. An account granted to a visiting faculty member should be removed as soon as he or she leaves, lest a cracker find the account's password and start using it as his own with noone the wiser. A secure system should have an account policy stating who can have an account, how long the account will exist, and under what conditions the account should be used. Thus, you will have a responsible person for each account.

Limit installed/running daemons and programs

For flexibility, many systems come with multiple system programs (ie, daemons) installed and running by default. You probably won't use more than half of them, even at a large site. However, bugs in a daemon you're not even aware of may make it possible for a cracker to access your system without an account. Thus, you should examine /etc/inittab and /etc/inetd.conf and turn off (comment out) any non-required programs.

Similarly, you should disable or remove any non-required SUID programs. A cracker with access to your system could use bugs in a program you don't even know is installed to gain super-user access. You can check for SUID/SGID programs by using the find(1) command:

  find / \( -perm -4000 -o -perm -2000 \) -ls -o -fstype nfs -prune
  

Secure your users' passwords

Most Unix systems now use an /etc/shadow or equivalent file to hold local users' encrypted passwords out of the cracker's reach. However, network passwords are typically stored in an NIS or Netinfo database which any user can download, read, and brute-force crack.

You need to move those password strings out of the user space. Switch to NIS+C2 (passwd.adjunct), NIS+, Kerberos, rdist'ed /etc/shadow, or some similar method of sharing accounts/passwords between your networked machines.

Also, use the cracker's tool, crack, and check your own users' passwords against the dictionary words. Be aware that this can be computationally expensive, and some organizations may have policies against this (not that this will stop the crackers, mind you).

Secure your network

If crackers compromise a machine, they may install a network sniffer to look for people telnet'ing between hosts, and thus gain their username/password combinations. The best way to limit such exposure is by encrypting your inter-machine traffic.

The current standard on campus for encrypted remote access is the Secure Shell software, aka SSH.

If at all possible, install and use non-promiscuous ethernet cards. However, since many servers may require promiscuous mode, make sure they are on switched networks, instead of shared-media hubs.

Patch your OS

From time to time, Unix vendors will release patch reports which list their recommended patches, their relevance to security, and how to download them via the web. You should check these web pages at least once a month looking for new security patches. The vendors may also have a mailing list.

• Sun Solaris
• IBM AIX
• RedHat Linux
• Debian Linux

Sometimes, it is easier to replace certain system binaries with third-party versions. Some versions are merely upgrades, while others are equivalent function programs from another source.

• SSH replaces telnet, rlogin, rsh, rcp.
• Sendmail v8.9 replaces all earlier sendmail versions.
• BIND v8 replaces all earlier BIND versions.
• RDist v6 replaces existing UCB rdist (v4).
• XNTP is a time-sync program. Much better than rdate.

OS-Specific information

Certain operating systems have known security holes that do not exist on other platforms. If you know of any, please let us know, and we'll add them here.

• Sun Solaris
• IBM AIX
• RedHat Linux from UF Physics.
• SGI Irix
• Compaq Digital Unix

---

Last updated: Aug 03, 2004 (09:19:59 AM EDT)
URL: http://www.clasnet.ufl.edu/security/unix.shtml