| TOC |
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright © The Internet Society (1997). All Rights Reserved.
This document is designed to assist vendors and other participants in trade shows, such as Networld+Interop, in designing effective protection against network and system attacks by unauthorized individuals. Generally, it has been observed that many system administrators and trade show coordinators tend to overlook the importance of system security at trade shows. In fact, systems at trade shows are at least as prone to attack as office-based platforms. Trade show systems should be treated as seriously as an office computer. A breach of security of a trade show system can render -- and has rendered -- an exhibitor's demonstrations inoperable -- sometimes for the entire event!
This document is not intended to replace the multitudes of comprehensive books on the subject of Internet security. Rather, its purpose is to provide a checklist-style collection of frequently overlooked, simple ways to minimize the chance of a costly attack. We encourage exhibitors to pay special attention to this document and share it with all associated representatives.
| TOC |
2. Password Security
3. Use of Authentication Tokens
4. Anonymous FTP
5. Network File Sharing
6. Trusted Hosts
7. SetUID and SetGID binaries (Unix systems)
8. System Directory Ownership and Write Permissions
9. Network Services
10. Trivial File Transfer Protocol (TFTP)
11. BIND (Berkeley Internet Name Daemon)
12. Sendmail and Mailer Security
13. Web Server Scripting Security
14. Other Suggestions
15. General Network Security
16. Packet Filtering
17. Contributing Writer
§ Author's Address
§ Intellectual Property and Copyright Statements
This section discusses technical security procedures for workstations on the vendor network. Although specifics tend to be for Unix systems, general procedures apply to all platforms.
Lack of passwords or easy to guess passwords are a relatively low- tech door into systems, but are responsible for a significant number of breakins. Good passwords are a cornerstone of system security.
By default, PC operating systems like Windows 95 and MacOS do not provide adequate password security. The Windows login password provides no security (hitting the "ESC" key allows the user to bypass password entry). Password security for these machines is possible, but is beyond the scope of this document.
* Check /etc/passwd on Unix systems and the user administration application on other systems for lack of passwords. Some vendors ship systems with null passwords, in some cases even for privileged accounts.
* Change passwords, especially system and root passwords.
* Mix case, numbers and punctuation, especially on privileged accounts.
* Change system passwords on a regular basis.
* Do not use passwords relating to the event, the company, or products being displayed. Systems personnel at Networld+Interop, when asked to assist booth personnel, often guess even root passwords!
Extra Privileged Accounts
Some system vendors have been known to ship systems with multiple privileged accounts (for example, Unix systems with accounts that have root privileges [UID=0]). Some vendors may include a separate system administration account that places a user in a specific administrative program. Each additional privileged account presents yet another opportunity for abuse.
Generally, if a Unix system does not need additional root accounts, these can be disabled by placing "*" in the password field of /etc/passwd, or by using the administrative tool when a system employees enhanced security. Verify all systems for extra privileged accounts and either disable them or change their password as appropriate.
Make certain that privileged accounts are inaccessible from anywhere other than the system console. Frequently systems rely on files such as /etc/securettys for a list of "secure" terminals. As a general rule, unless a terminal is in this file, a root login is not possible. Specific use of this feature should be covered in the system's documentation files.
* Check /etc/passwd on Unix systems and the user administration application on other systems for additional privileged accounts.
* Disable remote login for privileged accounts.
* Disable any unnecessary privileged accounts.
* Limit logins from root accounts to "secure" terminals or the system console.
Authentication tokens such as SecureID, Cryptocard, DES Gold and others, provide a method of producing "one-time" passwords. The principle advantage in a trade-show environment is to render worthless, packets captured by sniffers on the network. It should be treated as fact, that there are many packet sniffers and other administration tools constantly (legitimately) watching the network- -especially at a large network-oriented trade show. Typed passwords, by default, are sent clear text across the network, allowing others to view them. Authentication tokens provide a password that is only valid for that one instance, and are useless after that. A logical extension of the use of authentication tokens would be to use them for "trips home" (from the show network to a home site) to minimize the chance of off-site security problems. An alternative to these tokens is the secure shell ("ssh") protocol which provides an encrypted connection between clients and servers. This connection can carry both login traffic and arbitrary port-to- port communication, and is a powerful tool for securing an in-booth network and communications to and from remote systems.
* Contact vendors of authentication tokens/cards for further information as to how to integrate into specific environments, or on to specific platforms.
* The public-domain utility "cryptosu" (csu), when used with a Cryptocard, provides a replacement for Unix's "su" command, employing a challenge/response style of authentication for root access.
* Explore the use of ssh clients and servers.
Anonymous FTP accounts can easily turn into a security hole. Disable this service if not specifically needed. In the event that anonymous FTP is to be used, the following tips may help secure it.
* When a user logs in as "anonymous", they should be locked into a specific directory tree. Be sure that FTPd properly chroots to the appropriate directory. A "cd /" should put an anonymous user at the top of the "public" tree, and not the system's root directory.
* Some systems may allow symbolic links (or "shortcuts") to take a user outside the allowed tree. Verify all links inside the anonymous FTP hierarchy.
* Make sure that ftp's root directory is "owned" by someone other than the 'ftp' account. Typically, it should be owned by "root".
* Do not use a world-writable incoming directory unless absolutely necessary. Many sites use these as a way for users to transfer files into the site. This can, and frequently does, turn into an archive for stolen software (referred to by the pirate community as "warez").
* Removing read permissions from the directory permissions (chmod 733 on Unix systems) prohibits an anonymous user from being able to list the contents of a directory. Files can be deposited as usual, but not retrieved unless the user knows the exact name of the file.
Writable file shares without some form of security are invitations to destruction of information and demonstrations. Whether using NFS on Unix systems, or PC sharing facilities like CIFS, AppleShare, or NetWare, close attention should be paid to security of the files exported. Keep in mind that one's competition frequently shares the same network at a trade show! Security for both read and write access should be employed and each access point examined.
Exporting a writable NFS filesystem to the world grants anyone the ability to read and write any file in the exported mount point. If this is done, for example, with a system directory such as "/" or "/etc", it is a simple matter to edit password files to create one- self access to a system. Therefore, /etc/exports should be closely examined to be certain that nothing of a sensitive nature is exported to anyone but another trusted host. Anything exported to the general public should be exported "read-only", and verified for the information that is available via the file shares.
* Do not provide file sharing space unless needed.
* Verify where exported information will be "visible".
* Do not maintain any writable shares unless absolutely necessary!
Trusted host entries are a method for allowing other hosts "equivalent" security access to another host computer. Some vendors ship systems with open trusted host files. Make certain that this issue is addressed.
* On Unix systems, check for a '+' entry (all systems trusted) in /etc/hosts.equiv and all ".rhosts" files (there may be multiple .rhosts files) and remove it.
* Check for an "xhost +" entry in the "...X11/xdm/Xsession" file. Most often, an "xhost" entry will appear with a pathname such as "/usr/local/lib/xhost +". Remove this.
On Unix systems, the "suid" bit on a system executable program allows the program to execute as the owner. A program that is setUID to "root" will allow the program to execute with root privileges. There are multiple legitimate reasons for a program to have root privileges, and many do. However, it may be unusual to have suid programs in individual user directories or other non-system places. A scan of the filesystems can turn up any program with its suid or sgid bit set. Before disabling any programs, check the legitimacy of the files.
* "find / -user root -perm -4000 -print" will find any occurrence of a setuid file anywhere in the system, including those on NFS mounted partitions.
* "find / -group kmem -perm -2000 -print" will do the same for kmem group permissions.
Check ownership of all system directories and permissions needed to write or modify files. There is no simple way to do this on PC operating systems like Windows NT without simply checking all files and directories or using a version of "ls" that will list ACLs.
On Unix systems, a directory with permissions such as "drwxrwxrwx" (such as /tmp) is world-writable and anyone can create or modify files in such area. Pay special attention to "/" and "/etc". These should be owned by some system account-not by an individual user. When in doubt, contact the vendor of the system software for confirmation of the appropriate directory or file permissions.
Any servers not needed should be disabled. The notorious "R services" (rexec, rsh, and rlogin) are particularly prone to security problems and should be disabled unless specifically needed. Pay particular attention to trusted hosts files, and be aware of the risk of IP spoofing attacks from machines "pretending" to be trusted hosts.
* On Unix systems, comment out "R services" (rexec, rsh, rlogin) in /etc/inetd.conf.
* Check for other unknown or unneeded services.
TFTP can be an easy way for an intruder to access system files. It is good general practice to disable TFTP. If TFTP is needed, verify that only files targeted for export are accessible. A simple way to check security is to attempt to tftp files such as /etc/passwd or /etc/motd to check accessiblity of system files. TCP Connection Monitoring
Public domain software (TCP Wrappers or "tcpd" for Unix systems) allow restriction and monitoring of TCP connections on a host by host basis. Systems can be configured to notify an administrator and syslog when any unauthorized party attempts to access the host. This software is available from:
Earlier versions of BIND have been prone to various attacks. If a host is going to be acting as DNS, use the latest version of BIND. It is available at:
A great number of previous versions of Sendmail have known security holes. Check installed sendmail for the most recent version. Alternatively, consult the operating system vendor to get the most recent release for the platform.
All Web server scripts and binaries should be checked (especially the "...httpd/cgi-bin" directory) for those that allow shell commands to be executed. Many attacks in recent months have focused on the use of utilities such as "phf" for accessing /etc/passwd on a target system. Remove any script that is not needed in the course of operation of a web server.
* Check with the vendor of the operating system for known security issues. Make certain that all systems have the latest version of software--especially security patches to fix specific problems.
* Examine log files on the host frequently. On Unix systems, the "last" command will furnish information on recent logins and where they came from. The "syslogs" or "Event Viewer" will contain more specific information on system events.
* Web server logfiles (...httpd/log/access_log and ...httpd/log/error_log) will contain information on who has been accessing a WWW server, what has been accessed, and what has failed.
* Good backups are the best defense against system damage. Perform backups before placing a system on the trade show network then continue backups throughout the show and again following the event. A final backup set is useful to examine for possible attempts at (or successful) penetrations of system security.
As would be expected at network trade shows (large or otherwise), there are many entities running packet sniffers. Most are exhibitors who have a legitimate need to run them during the course of product demonstrations. However, be aware that there are many "listening ears" on network segments--any of whom can "hear" or "see" information as it crosses the net. Particularly prone to eavesdropping are telnet sessions. A good rule of thumb is to assume that "when you type your password, the only one that doesn't see it is you!"
It is a good practice to not log in (or "su") to an account with privileges across the network if at all possible. As mentioned previously, authentication tokens and ssh are a simple way to add security to system account access.
Many routers support basic packet filtering. If a router can be deployed between the local network and the show's network, general basic packet filtering should be employed. Below is a good "general" packet filter approach. The approach itself is ordered into categories:
* General global denials/acceptance.
* Specific global service denials.
* Specific service acceptance.
* Final denial of all other TCP/UDP services.
Based on the theory of denying everything that you don't know is acceptable traffic, a good approach to a filter ruleset, in order of execution priority, might be: General Global Denials/Acceptance
1 Filter spoofed source addresses by interface. Match source addresses to routing information available for the interface. Discard packets with source addresses arriving on one interface (from the "outside" for example) claiming a source address on another interface (the "inside").
2 Filter all source routed packets unless source routing is specifically needed.
3 Allow outbound connections from "inside" hosts.
4 Allow established TCP connections (protocol field contains 6 and the TCP flags field either contains ACK or does NOT contain SYN bit). Only filter requests for 'new' connections.
5 Filter 'new' connections with source port of 25. Prevents people from pretending to be a remote mail server.
6 Filter loopback address (source address 127.0.0.1). Prevents packets from a misconfigured DNS resolver.
Specific Global Service Denials
1 Specifically block all "R-command" ports (destination ports 512-515).
2 Block telnet (destination port 23) from any host not requiring telnet access from the outside. (If you use ssh, you can block it from all hosts!)
3 Add specific filters to deny other specific protocols to the network, as needed.
Specific Host/Service Acceptance
1 Add specific access to specific "public" hosts' services (unsecure FTP or WWW servers).
2 Allow SMTP (source and destination port 25) for electronic mail to the mail server(s).
3 Allow inbound FTP connections (source port 20) to the FTP server(s).
4 Allow DNS (source and destination port 53, UDP & TCP) to name servers. If zone transfers are not needed, block the TCP ports.
5 Allow RIP packets in (source and destination port 520, UDP), if appropriate.
6 Add specific filters to allow other desired specific protocols or to open certain ports to specific machines.
Final Service Denial
1 Deny all other UDP and TCP services not allowed by the previous filters.
Stephen S. Hultquist President Worldwide Solutions, Inc. 4450 Arapahoe Ave., Suite 100 Boulder, CO 80303 Phone: +1.303.581.0800 EMail: email@example.com
|R. Allen Gwinn, Jr.|
|Associate Director, Computing|
|Business Information Center|
|Southern Methodist University|
Copyright © The Internet Society (1997). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.