Security: A Multi-Tiered Approach - Part 1
Mark Nassal It has been said that the only secure computer is a single-user system in a locked room with a squad of armed Marines at the door. Although such a system may be reasonably secure, it also does not provide much utility. Connectivity is the key to working productively in today's computing environment, and in most cases connectivity is defined in terms of network connections - both local and Internet based. Such connectivity, however, carries with it a need for network security. In this two-part article I explore one approach to network security and discuss utilities that I have found useful for implementing the described security scheme. This month I will focus on passwords and group IDs, and next month I will discuss outside threats related to services and protocols. A proper network security scheme requires a multi-tiered approach. Sometimes a firewall guarding the perimeter isn't enough to keep your data safe. In many instances the attacker comes from within. If an employee becomes the threat, a firewall provides very little resistance. That employee is probably not going to come through the path of the firewall or else has clearance to do so. Sometimes the risk comes from users innocently sharing bits of information. They don't realize they have become a risk because they don't understand how much information they have given. When a fragment of information is combined with other bits and pieces, it can create a key. For example, at a recent seminar on Internet security products, the speaker asked everyone to write their email password on a piece of paper and fold it in half. He then went around the room collecting the papers. Several attendees freely handed their passwords to the speaker before he made his point. None of the attendees should have willingly given away such information, but they did. Only two of us refused to write down our passwords. These users did not intentionally breach security. But their innocent actions could have been just as damaging as an intentional breach. I recently read that up to half the reported security breaches are from the inside. So, regulating access from inside is as important as restricting access from outside. Monitoring users is not enough; we must also check ourselves. Human error on the administration side can have serious repercussions. An improperly configured firewall or a careless approach to log monitoring or password management can provide the means for unauthorized entry. It is important to use tools that provide some sort of validation. When you enter large bodies of information into configuration files, it is easy to make mistakes. Visual feedback in the form of text or a graphical display can be very helpful. That is why when I recommend firewall solutions, I promote GUI-based tools. At a glance the administrator can see openings and conflicts. There are going to be errors; the trick is to build traps to catch them. If your network is connected to the outside world through the Internet, T1, dial-in or UUCP, then you face attack from several directions. Penetration from the outside is usually through services such as telnet, RPC, ftp/tftp, finger, X11, and SMTP. From the inside, compromise usually comes from unattended terminals, improper passwords, SUID/SGID files, poor systems management, or a user offering too much information. To combat all the possible points of entry and forms of attack, you must use multiple tools. That is where the multi-tiered approach comes in. This approach includes:
I will not discuss firewall and proxy server issues in this article, simply because they deserve an article of their own. My focus will be on tightening the other facets of internal and external security, and this month I will focus specifically on passwords and user and group IDs. Possible Risks and Resolutions Before building defense strategies, you need to understand your environment. What are you protecting? Who has access to the systems? How many ways can data be accessed? What measures have already been taken, and can your network be reached from the outside? By evaluating each of these areas, you can build a picture of the environment. With that you can appraise the areas of risk. Networks are vulnerable to different risks based on connectivity. If your network is connected to the outside world through the Internet, dial-in, or direct connection, the chance of attack is much greater. Some of the more common modes of attack are through network services, including telnet, ftp/tftp, RPC and its associated protocols, SMTP, and X Window. Beyond basic service attacks, there is the strong possibility of packet sniffing, whereby an outside or inside attacker monitors network connections. Applications such as snoop allow the capture of IP packets, which can contain passwords and source/destination addresses. This information can later be used to enter the network. You must also deal with internal security issues such as passwords, unattended terminals, file permissions, and physical security. It is important to list each possible risk so that you can prepare for the unthinkable (a security compromise). List each possible attack and the damage that could occur. Next, formulate safeguards based on the information in this article. Finally, decide how actions will be audited. Without an audit trail, you may not know the network has been compromised, and you will have little recourse against the attacker. Fortunately UNIX and UNIX-like operating systems allow for detailed logging. With a little help from Perl or shell scripts, you can create customized reports delivered to your desktop. Passwords Passwords are the network's first line of defense. The problem is that they are also one of the most overlooked holes. It is dangerous to assume that just because there is an entry in the /etc/passwd file, that it is a good password. The following are not good passwords:
Passwords should be at least eight characters long, formed from an alphanumeric string. The more random the string, the better. Remember, the easier the password is for your user to remember, the easier it is to crack. To make sure that your users are creating passwords properly, it is a good idea to scan the servers once a month. Applications such as Cops allow administrators to scan password files for incorrect entries. The package comes with both C code and Perl scripts. The configuration files can be modified for local needs and run via cron. To get a copy, visit:
http://ciac.llnl.gov/ciac/SecurityTools.html If the server being scanned uses shadow passwords, you will need to merge /etc/shadow and /etc/passwd into one file before cracking. Listing 1 is an example of a Perl script that will merge the files. (Listings 1 and 2 are available from ftp.mfi.com in pub/sysadmin.) You can also download a copy of the file from my Web site http://www.tiac.net/users/nassalm. Once you have finished checking the merge file, make sure to delete it (/var/tmp/filtered). Leaving the file in /var/tmp for an extended period of time can cause a security problem. Since /var/tmp is open to the world, unauthorized access to the file could occur. If an intruder manages to capture a password, you will want to make sure it has a limited life span. To accomplish this, password aging should be used. Password aging allows administrators to set an expiration date for passwords. Be forewarned, many users become aggravated by having to regularly change their passwords, but it's worth the complaints. Don't become obsessive with updating passwords, however. Changing passwords every two or three months is enough. More frequently than that, the users may get confused. That confusion will more than likely result in phone calls and complaints. Or worse, frequent password changes may induce users to write their passwords on a slip of paper and keep it near their computer. Password aging usually requires that shadow passwords are used. The expiration date and warning date are set in /etc/shadow. Below is an example of a shadow entry:
mxn:G3bW0Y4RJ33js:10004::90:5::: Each line is split into nine fields separated by colons.
username: The user's login name, mxn in this case Empty fields are ignored. The above example says that mxn's password will expire in 90 days and that he will be warned 5 days before expiration. Solaris has a few unique files that can be modified to increase login security. Global password aging can be accomplished by editing the file /etc/default/passwd. Simply add the entries:
MAXWEEKS=12 Number of weeks before required password change. MINWEEKS=1 Minimum number of weeks before the password can be changed. The reason for a minimum is to prevent users from changing their password, and then immediately changing it back to their old one. To prevent users from logging in without a password, add the entry PASSREQ=yes to /etc/default/login. While you are editing this file, make sure that the line CONSOLE=/dev/console is uncommented. This entry will prevent users from logging in remotely as root. Using shadow passwords is a good idea even if you are not performing password aging. The /etc/shadow file is used to store the encrypted passwords instead of /etc/password. The reason is that /etc/passwd is readable by the world, which allows regular users to run password-cracking applications on the file. By moving the passwords to /etc/shadow, they are protected from normal viewing. The file mod is set to 600 (read, write by owner, which is root). Most modern UNIX and UNIX-like operating systems allow shadow passwords. There is usually a file called /usr/sbin/pwconv (Sys V) or /usr/sbin/pwconv5 (Linux) that performs the conversion. Below are examples from /etc/passwd and /etc/shadow. From /etc/passwd: mxn:x:798:100:Mark Nassal:/home/mxn:/bin/bash
From /etc/shadow: mxn:G3bW0Y4RJ33js:10004::90:5:::
Note that the password field in /etc/passwd has been replaced with x. That is because the encrypted password now lives in /etc/shadow. If you want to temporarily disable an account, simply add * to the beginning of the password. The user will not be able to log in, but root can still su to the account. Before: mxn:G3bW0Y4RJ33js:10004::90:5:::
After: mxn:*G3bW0Y4RJ33js:10004::90:5:::
To reactivate the account with the original password just remove the *. On Solaris, system access can be limited for an account by using the restricted shell. It is a version of the shell that limits user actions. The user cannot change directories, set the $PATH environment, specify a path, or redirect output. When using this shell make sure to get the right one. The restricted shell is /usr/lib/rsh and is often confused with /usr/bin/rsh (Remote shell). Whichever shell you choose, make sure it is valid. Without a valid shell, the user will be dropped to root /. Remember that passwords are one of the lowest levels of a security scheme and one of the most important. User and Group IDs More than just a good password is needed to protect files and directories. Passwords provide an all or nothing choice; they either allow entry or not. Fortunately UNIX provides several other tools for managing permissions. UIDs (user IDs), GIDs (group ID), and file mods are used in combination with passwords. This combination allows you to specify whether everyone has access to a file, a group of users, or just a single user. The added flexibility these tools provide can also make systems more vulnerable. If any of the permissions are set incorrectly, an opening may become available to an attacker. Thus, it is important to understand how they work, and I will review each of these tools. User IDs are a numeric equivalent to the user name. When the computer checks permissions based on a user request, it validates against the UID. UIDs are formed from a 16-bit number. Values between 0 and 9 are normally reserved for the system (root, bin, daemon, lp, etc...). Non-system users are typically assigned numbers starting at 100. Each UID is stored in /etc/passwd. Entries in the passwd file are divided into seven colon-separated fields.
user_name:password:UID:GID:fullname:home_dir:shell The example below shows that the user mxn has a UID of 100.
mxn:x:100:300:Mark Nassal:/home/mxn:/bin/csh It is possible for more than one user to share a UID.
root:x:0:0:root:/root:/bin/csh mxn:x:0:100:root login for mxn:/:/bin/csh This is an important item to remember when reviewing your passwd file. A person who has temporary root privileges can easily create a new account with the UID of 0 (root). That person can then log in with all the privileges of superuser (root). You could easily set up a cron to run each night to check for Trojan superusers. Simply grep the /etc/passwd file for the UID of 0.
grep :x:0 /etc/passwd > /home/protected dir/uidlog In this example, I used grep to search through /etc/passwd for UIDs of 0 and then print the output to a log file. Note the output directory should be invisible to all but root. Also, note that the password file is one that uses /etc/shadow. That is why there is an x in the password field. Group names also have a numeric equivalent. The relationship between the group name and the GID is defined in the /etc/group file. Each entry is broken into four fields, separated by colons. The fields of /etc/group are: group_name:passwd:GID:user list, in which: "group_name" is the text name for the group, and "passwd" is the encrypted password for the group. This field is not often used. "GID" is the numeric name of the group, and "user list" is a list of users who belong to the group, separated by commas. Below is an excerpt from /etc/group.
games::20:mxn gopher::30: dip::40: ftp::50: users::100: The group file makes it easy to assign identical permissions to more than one person at a time. For example, if a group of people want to access a directory named data and restrict all others, you can create a "data" group. Everyone who belongs to the data group then has access to the files. When a user is added to the /etc/passwd file, he or she is given a default GID.
mxn:x:100:100:Mark Nassal:/home/mxn:/bin/csh >In the example above, the user mxn is in the GID of 100. From the /etc/group excerpt, you can see that the GID of 100 is the user's group. Looking at the group file again, you will see that mxn is also a member of the games group (20). Users can belong to multiple groups. But different flavors of UNIX handle multiple memberships differently. System V allows users to belong to only one active group at a time. To receive the privileges of another group, you must change your active group. This is accomplished by issuing the command newgrp followed by the group name.
newgrp games The string above will change mxn's active group to games. If the group has a passwd entry, you will be prompted for a password. An interesting note about the password field in /etc/group is that most UNIX versions allow for the field but do not offer an easy way to create the encrypted password. In general, this field is not used. What most people do to secure sensitive groups is to enter * in the passwd field. The asterisk prevents users from switching to that group. For systems groups such as root it makes sense to take this extra step. You don't want users to be able to use the group privileges that root offers. Berkeley UNIX allows users to actively belong to several groups at one time. After a user logs on, /etc/login searches /etc/group for all the groups the user belongs to, and sets permissions accordingly. The newgrp command is not needed since all designated groups are active on login. It is important to monitor the group file as well as the passwd file. As with the passwd file you can create a script to run from cron. A simple method is to grep for your sensitive groups and dump the results to a file. You can then review the information in the morning. Make sure there is an asterisk in the passwd field and that there aren't any Trojan members. UNIX uses a series of alpha or numeric symbols to determine the permissions of files and directories. In general, UNIX allows you to set six types of privileges on a file or directory.
Read - Allows the user to view the file. To change or create privileges on a file or directory you must be the owner or root. The command ls is used to view the permissions of files. By adding the switch -l (long), the files permissions, owner, group, file size, last date modified, and the name are displayed.
[root@jasmine /etc]# ls -l smb.conf -rw-r--r-- 1 root root 3314 Mar 20 19:29 smb.conf
The permissions field displays a list of characters or dashes representing the files access privileges. As I mentioned, there are six options (read, write, execute, SID, GID, and sticky). Each of the options is displayed as a single character.
Read = r The field is further broken down into permissions for the owner, group, and all others. Each group is given three positions in the field. The three positions represent Read (r), Write (w), and Execute (x).
-rwxr--r-- This example says that the owner can read, write, and execute the file, while the group and others may only view the file. If the file is set to SUID, the x in the owner's section is replaced with an s. If the file is GUID, the x in the group section is replaced with an s. If the sticky bit is turned on, then a t is added to the end of the string.
-rwsr--r-- SUID -rwxr-sr-- GUID -rwxr--r--t Sticky The permissions can be added to a file by entering a text or numeric string. I am a proponent of the numeric method. I have found that fewer mistakes are made when this method is employed. Each of the permissions discussed can be represented by a number.
Owner of file
Read = 0400 Others
Read = 0004 To come up with the final value, simply add the numbers together. Using the earlier example (-rwxr--r--), you get a value of 0744.
0400 - r owner 0200 - w owner 0100 - x owner 0400 - r group 0400 - r other ==== 0744 - -rwxr--r-- If we added SUID to the permissions, it would appear as 4744. To apply the permissions to a file or directory, use the command chmod. Simply type the command followed by the permission value and file or directory name.
chmod -R 0744 /some_directory The changes can also be made recursively by adding the -R switch.
chmod -R 0755 /some_directory The recursive method can be quite dangerous if issued by root, since it can change the permissions of an entire tree. Make sure you know what files will be changed by this action before issuing the command. These permissions are very important when securing your system. As mentioned earlier, the wrong settings can have detrimental effects. Check system executables periodically with ls -l or ls -al to ensure that permissions have not been changed. Most UNIX operating systems also provide a chart that lists the proper permissions for the system tree. You can refer to these charts if you think something has changed. Depending on the flavor of your UNIX, there may be extended switches available to you. Review the man page on chmod for any extensions. You may also want to scan your system for files and directories that are writable by all. Run the command below or modify the script in Listing 2.
find / -xdev -perm -2 ! \( -type l -o \ -type p -o -type s \) -print The command will search the given file system for files that are writeable by all. Since the -xdev option has been added, it will not search past the file system boundary. You will need to change the path for each file system you want to check. The Chameleon Although SUID and GUID are needed by the system, they can also pose a serious threat. Certain executables must be run as root to perform their duties. An example is /usr/bin/passwd. The passwd command needs to be accessible to all users so they can change their passwords. However, the functions it performs are only allowed by the superuser. To get by this problem, the file is tagged as SUID.
-r-sr-xr-x 1 root bin 19031 Aug 26 1996 /usr/bin/passwd When a regular user executes the program, it switches to the UID of root. This allows the password entry to be changed in /etc/passwd and /etc/shadow. The user doesn't have to be root because the executable takes on the privileges of root. GUID functions in a similar manner, but instead of changing the effective UID, it changes the GID. Note that the owner does not have to be root. Any user can create a file that is tagged as SUID or GUID. When the file is run, it switches the effective SUID or GUID of that owner. If normal users create S and GUID files, it can defeat the purpose of user permissions. A common way attackers use this tag is to create shells with privileges of root. If a user can gain temporary access to root, he or she can create a shell with all the permissions of the superuser. All the attacker needs to do is make a copy of the shell used by root, and change the file mod.
cp /bin/csh /home/me/root-shell chmod 4755 /home/me/root-shell Then every time the user enters commands through root-shell, they are executed as root. Thus, it is a good idea to monitor your systems for bogus SUIDs and GUIDs. To do this, first search your system for all files with the mod of 4000 and 2000. Then write the results to a file. That file will become your reference point. As you scan your system weekly compare the new results against your original results. A simple script can perform the search for you. See Listing 2 for a sample Perl script that will search selected file systems for SUID and GUID files. I recommend that if you use this Perl script that you change the output directory and file name. The log file should not be stored where normal users can view it. Again, as with passwords, Cops can be used to monitor permissions for you. The application can be configured to scan /etc/passwd, /etc/group, and file systems for SUID and GUID. Well, this should give you enough to chew on for this month. Next month we will cover service and protocol related threats. Remember you can't be too paranoid; they really are out to get you.n About the Author
Mark Nassal is a senior UNIX administrator at Harte Hanks Data Technologies in Billerica, MA. They operate a predominantly UNIX network with NT 3.5 and 4.0 as the standard desktop OS. He has been in the Computer/Telecommunications industry for nine years, and much of his work has centered around UNIX/Microsoft integration. Mark can be reached at: nassalm@tiac.net or http://www.tiac.net/users/nassal.
|