Security - A Multi-Tiered Approach, Part 2
Mark Nassal Last month I covered the building blocks of network security. They included general security principals, passwords, and file permissions. In this article, I will discuss protocols, file sharing, and logging. Networks and Protocols Because the majority of outside attacks are service related, I will discuss the more common threats. There are numerous protocols and services that can cause problems, and every week I receive bulletins regarding new ones. But most attacks are based on seven services and related protocols. These services are telnet, SMTP, ftp, finger, tftp, X11, and RPC. telnet - The telnet service allows remote users to log into a host as if located at the console. Since telnet allows connections to be made across the entire network, its effects can be far reaching. telnet is a two way street. IP packets flow back and forth between client and server. If the intended server is also a router, all kinds of information is traveling across the wire. Applications such a tracert and snoop can be used to capture the packets as they travel from source to destination. By monitoring packets, user names, passwords, and IP addresses can be sifted out. That information can then be used to enter your network. telnet does, however, require a password to login, which brings us back to our first line of defense: passwords. SMTP - This protocol provides mail services to internal and external networks. By default, SMTP monitors port 25 for incoming requests. Port 25 is just as happy accepting mail services as it is accepting telnet sessions, which makes it a choice entry point. If an intruder has the correct UID and password, then the door is wide open. Thus, most admins remove the protocol if it is not needed on the server. Another way intruders capitalize on SMTP is through denial of service. One trick is to send so many messages to a server that it essentially shuts down. When this happens, you have a denial of service. The action usually doesn't cause permanent damage, but can seriously inconvenience users. ftp - The File Transfer Protocol allows remote users to move files between client and server. Its basic function makes it a danger. False /etc/passwd, /etc/group, and /etc/hosts tables can be injected into a system or the real ones can be moved. Depending on the client version of ftp, files can be deleted or renamed, and permissions can be changed. Again, since passwords are required it can be a good source for sniffing. TFTP (Trivial File Transport Protocol) - This protocol poses an even greater risk, since it is UDP based and provides no security. finger - By itself, finger doesn't pose a real threat. But the information retrieved through the application can. finger provides information such as who is logged into the server, how long they have been on, the source IP addresses, and even their phone number. As shown in Listing 1, there is quite a bit of information available. The bad news is that a user does not have to log into the system to get the information. Simply issuing the command finger@servername will display all the active users on a server. This service should be turned off on any external servers. X11 - The X11 protocol allows remote users to display application output on a terminal other than the originator. When used incorrectly, control of the screen, keyboard, and other devices can be circumvented by another computer. If the command xhost + is used, host can redirect output to and from the machine that issued the command. This means that information intended for local viewing may actually be displayed elsewhere. There are X applications used by intruders that will echo everything on the screen to a remote server. If an admin is updating the /etc/passwd file, that information could be sent to an intruder. The proper way to use xhost is to add a list of hosts that are allowed to connect.
xhost +myserver, billsserver, yourserver This will limit vulnerability by limiting the servers that can connect. RPC - RPC and its related services (NFS, NIS, and automount/amd) can create some serious holes. If NFS is configured incorrectly, key file systems such as / and /etc can be mounted remotely. This provides a wealth of information to unauthorized users. RPC depends on the portmap service to determine which services are acceptable and which services are rejected. portmap monitors numbered IP ports for specified service requests. If the configuration file /etc/services is replaced by a Trojan, unauthorized services can become available on the system. Regardless of these gloomy possibilities, there are still ways of protecting your network while retaining its functionality. The first step is to install a top quality firewall. You should be filtering source and destination IP address as well as services. The ability to associate protocols with source and destination IP addresses is important. With this method, you can say that computer A can use ftp when connecting to computer B, but computer B can't use ftp when connecting to A. By making such associations, you can stop all traffic from one direction while allowing specified traffic from another. Next you should stop any unneeded protocols. In fact, you may want to go one step further by removing the protocols. For example, if you don't think you will need sendmail on the outside server, remove the daemon. If the file doesn't exist, then it can't be started by an intruder. To stop services such as finger, ftp, telnet, and pop mail, comment out the services in the file inetd.conf. This file lives in /etc/inet on Solaris, and in /etc on Linux. To remove smtp and tftp, delete the associated rc file links. Finally, monitor your log files. Check firewall and system logs daily. If you don't check your logs, you may not know there is a problem until too late. Sharing Can be Dangerous NFS (Network File System) allows UNIX systems to share files and directories across the network and enterprise. Without NFS, UNIX servers would be severely crippled. Remote users can mount file systems from a server as though the drives were attached locally. Depending on permissions, files can be edited, copied, or executed transparently. This is how group and home directories are provided to client machines. NFS in general uses RPC and UDP to communicate. For security and reduced time-outs, Solaris 2.51 and above now provides NFS 3, which uses TCP instead of UDP (for Solaris-to-Solaris connections). UDP provides a quick transfer rate, but little security or error correction. One of the major security problems with NFS is that it does not require user authentication to mount directories. A user can simply log into the local system and issue the mount command. If the file system has been exported by the server, it will be mounted and available for use. The /etc/exports file is used by NFS to determine which file systems are shared (note /etc/dfs/dfstab on Solaris). Since Solaris uses a slightly different format, each will be discussed separately. The /etc/exports file uses a fairly simple command structure. Each file system that is to be shared is entered on a separate line with its associated options.
directory -options[, extended options] The available options are pretty straightforward. access=machine:machine - Determines which machines or groups of machines are allowed to access the share. ro - File system is shared as read-only. rw=machine:machine - File system is writable to machines in list. root=machine:machine - Gives remote superusers root privileges on the mounted file system. NFS normally converts the UID of 0 (root) to -2 (nobody). When the root option is used, the UID stays at 0. anon=UID - Allows you to specify the anonymous user ID. If you enter -2, it will use the account nobody. secure - Tells NFS to use AUTH_DES authentication instead of AUTH_UNIX. A sample exports file may look like this:
# ****************************************** # Sample exports file # ****************************************** # allow access to /usr/local by screamer and jasmine /usr/local -access=screamer:jasmine> # allow access to /opt/local by screamer and madman /opt/local -access=screamer:madman # allow read-only access to /cdrom by all stations /cdrom -ro After making changes to /etc/export, you will need to run the command:
exportfs -a The executable is found in /usr/sbin (Linux), /usr/etc (SunOS). Running exportfs will then make the exported file systems available to remote stations. Solaris uses the file /etc/dfs/dfstab instead of /etc/exports. The general principals are the same, but the structure and options are different. Each exported file system is listed on a separate line beginning with the word share.
share [-F fstype] [ -o options] [-d "<description>"] \ <pathname> [resource] The example from /etc/exports will appear as:
#**************************************** # Sample dfstab file #**************************************** share -F nfs -o rw=screamer:jasmine -d "/usr/local" /usr/local share -F nfs -o rw=screamer:madman - d "/opt/local" /opt/local share -F nfs -o ro The options and switches for share are: -F - Type of file system. -o - Proceeds any of the following option switches. rw=machine:machine - File system is read-only for station other than those listed. Associating machines with read and write functions requires that NIS or NIS+ be running. ro - File system is shared read-only for all stations. -d - Text name for the share (i.e., My_Share). When changes are made, the exported file systems are made available with the command share -a. Share provides the same type of function as exportfs. To increase the security of your NFS hosts, there are some simple guidelines you can follow. Don't share any more file systems than necessary, and don't allow access to sensitive file systems. Use the rw switch to limit the number of stations with write access to the shared files. Whenever possible share the data as read-only. There are other measures that can be taken such as using AUTH_DES, but they can adversely effect network performance. If the rest of your security measures (i.e., passwords, groups, and permissions) are up to snuff, limiting access should be provide a reasonable level of security. Back Door to Doom Dial-in services and modems can be a security manager's nightmare. They are usually difficult to monitor and often pop up without proper authorization. I will discuss some simple rules. Modems connected directly to servers or workstations can be a potential risk. Logs are rarely if ever viewed on workstations, and they are usually unattended at night. In many cases, you wouldn't know if someone broke in. Such connections should be limited, and logs must be monitored. It is also wise to set up the modem for dialback. Users must dial-in to the modem and then wait for the modem to call back to a predefined number. This limits the connections to phone numbers within the configuration file. In general any dial-in services (whether modem, terminal server, or ISDN) should be routed through a firewall. These connections are extremely risky, especially if they provide PPP (Point-to-Point Protocol) connections. The Attacker's Fingerprint Monitoring log files is an important administrative function. In many cases the only way you will know that a system has been compromised is by the trail left in the log files. UNIX provides numerous log files throughout the system, and there are six that I will concentrate on: sulog, messages, lastlog, utmp, wtmp, and acct. Each flavor of UNIX logs and stores information with slight differences, but essentially, they track the same actions. Here are brief explanations: sulog - This file is found on System V computers in the /var/adm directory. The purpose of the log is to track users switching to another UID through the su command. Every time someone changes to UID, the transaction is logged, whether successful or not.
SU 05/12 22:03 + pts/3 notesadm-opsr SU 05/13 00:14 + pts/3 notesadm-opsr SU 05/13 09:42 + pts/5 mxn-sysadmb SU 05/13 10:08 + pts/3 dfk-sysadmb SU 05/13 11:10 + pts/5 mxn-sysadmb SU 05/13 22:17 + pts/1 notesadm-opsr As seen in this example, each UID change logs the date, time, port, and user names. This can be pretty valuable information. You can very quickly see who is switching to what and when. messages - The messages file is used on all flavors of UNIX. On SunOS and Solaris, it is located in /var/adm. Linux stores the file in /var/log. Messages that are echoed to the console are also sent to this file. Items such as initialized hardware, errors, change of UID to root, and mount actions are sent to this file. It can grow quite large if not maintained. The message file needs to be rotated on a weekly basis. If your system does not already have a cron script to rotate these logs, you can use this one:
#! /bin/sh # Rotate log files # # change to your log dir cd /var/log mv messages2 messages3 mv messages1 messages2 mv messages messages1 cp /dev/null messages This script will keep a 4-week history of the messages file and zero the active file (messages). Just add a pointer to your crontab and have the script run once a week. lastlog - Last log records every user's recent login and is available in all the flavors of UNIX. This file is not accessed directly by administrators. The finger command is used to retrieve the information (see Listing 1). utmp - This is used to track users who are currently logged into the system, and is another log file that is not accessed directly. The w or who commands are used to retrieve information from the file. To see who is logged into the system and what processes they are running, use the w. If the command is issued without argument, all currently logged users are displayed (see Listing 2). If a user name is given as an argument only information relating to that user will be displayed (see Listing 3). The who command displays currently logged in users with login date and time, port, and source address.
[root@walleye /var]# who mxn tty1 Jun 2 06:15 mxn ttyp0 Jun 2 06:16 (:0.0) mxn ttyp1 Jun 2 06:16 (:0.0) You should find this log file and associated command on all UNIX platforms. Linux has it in /var/run, and Solaris and SunOs keep it in /var/adm. wtmp - This file stores information on each login and logout. The file should not be accessed directly, but through the command last. Typing last at the command line will list all of the recent logins.
[root@walleye1 log]# last mxn ttyp3 :0.0 Fri Jun 6 06:29 still logged in mxn ttyp3 :0.0 Fri Jun 6 05:52 - 06:29 (00:36) mxn ttyp3 :0.0 Fri Jun 6 05:42 - 05:52 (00:10) SunOS and Solaris maintain the file in /var/adm, while Linux keeps it in /var/log. acct - This file stores information on system accounting. It logs each process run on the computer. Upon the completion of a process, the system writes a line to /var/adm/acc (SunOs / Solaris), /var/log/pacct (Linux).
bash S root ?? 0.58 secs Fri Jun 6 11:23 There are four common flags for each record:
S - Executed by the superuser The example above shows a process started by the superuser, because there is an "S" in the second field. To view the file use the command lastcomm. It will display the contents in the same format as our example. The acct log file gets very big very quickly and needs to be removed daily. Create a cron that issues the command sa and then zeroes the file. When sa is run, it will create a summarized list of processes and store the result in /var/adm/savacct (SunOs/Solaris), or /var/log/savacct (Linux).
38 0.02re 0.71cp 3 0.01re 0.50cp ***other 11 0.00re 0.12cp bash 11 0.00re 0.07cp atrun 11 0.00re 0.02cp crond* 2 0.00re 0.00cp bash* Once the summary file is created, run the string:
cp /dev/null /var/log/pacct or cp /dev/null /var/adm/acct
This will zero the file for the next day. For each of the message sources, there are eight levels of emergency.
emerg - Problems such as system crash When syslogd starts, it reads the configuration file /etc/syslog.conf. Each transaction type and log method is entered on its own line. The first field represents the type of transaction, and the second is the device or file to send the log information to.
authpriv.* /var/log/secure
In this article, we are really only concerned with the transaction type auth or authpriv (Linux). In the example above from /etc/syslog.conf, the messages from authpriv are logged to /var/log/secure. This log contains information about each remote connection made to the server.
Apr 2 16:29:08 walleye in.ftpd[6723]: connect from 194.104.36.44 Apr 7 09:44:08 walleye in.ftpd[28317]: connect from 194.104.36.44 This is a good file to check daily. It shows who has connected and what services they used. If you see an IP address that should not be there, you know you have a problem. Straw Houses All the tools and traps that I have discussed can become negated if physical security is not enforced. Open terminals, unlocked doors, and unmonitored access are invitations to disaster. There is no better physical defence than a lock and key. All too often backup tapes are left for the taking, and consoles are left open. A system backup can provide a lot of information, and an open terminal makes it even easier. Take the time to build secured computer areas for your more sensitive machines. A more recent threat has emerged with portable computing. Laptop computer thefts are increasing and can cause problems. Laptops usually contain a hosts table, user passwords, dial-in access numbers, and client or co-worker information. This is the loss you should be concerned with. A thief has just been given all the information required to successfully access your network. Rather than trying to clean up after a theft, the objective is to prevent it from happening in the first place. Most laptops have a ring or swing-out connector so the device can be chained to a desk. There are also connectors that will lock into the floppy drive. The key to making these work is getting your clients to use them. Encryption software packages can also be added to the system. The entire hard drive is encrypted and requires a login password. Whether the computer is a desktop, server, or laptop, employee awareness is one of your best tools. Users must be educated on potential risks and ways that they can help to reduce them. If someone can walk out the door with a computer and not be questioned, you have a problem. Conclusion I have covered a lot of information in these two articles, but I have really only scratched the surface. My intention was to provide a road map to get you started. Computer security in a large organization can be a full-time job, and the trick is to automate as much of the process as possible. The scripts and utilities mentioned here work fine for small networks, but you will probably want to modify and create your own scripts to meet your environmental needs. Other Resources There are numerous resources available on computer and network security, such as: CIAC - U.S. Department of Energy's Computer Incident Advisory Committee: http://ciac.llnl.gov CERT - A focal point for the computer security concerns of Internet users: http://www.cert.org NCSA - National Computer Security Association: http://www.ncsa.com
UNIX Network Security - An Architectural Overview Concepts of UNIX network security: http://www.alw.nih.gov/ \ Security Programs - Software utilities for the UNIX operating system: http://www.alw.nih.gov/Security/security-prog.html Implementing Internet Security by Cooper, Goggans, Halvey, Hughes, Morgan, Siyan, Stallings, and Stephenson. New Riders Publishing. Building Internet Firewalls by D. Brent Chapman and Elizabeth D. Zwicky. O'Reilly & Associates, Inc. Practical UNIX & Internet Security by Simson Garfinkel & Gene Spafford. O'Reilly & Associates, Inc. Computer Crime by David Icove, Karl Seger & William VonStorch. O'Reilly & Associates, Inc. Computer Security Basics by Deborah Russel & G. T. Gangemi, Sr. O'Reilly & Associates, Inc. UNIX System Administration Handbook by Nemeth, Snyder, Seebass & Hein. Prentice Hall PTR.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.
|