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.
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
