diff options
Diffstat (limited to 'doc/rfc/rfc2179.txt')
| -rw-r--r-- | doc/rfc/rfc2179.txt | 563 |
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc2179.txt b/doc/rfc/rfc2179.txt new file mode 100644 index 0000000..d1c6f49 --- /dev/null +++ b/doc/rfc/rfc2179.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group A. Gwinn +Request for Comments: 2179 Networld+Interop NOC Team +Category: Informational July 1997 + + + Network Security For Trade Shows + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + 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. + +Physical Security + + Before addressing technical security issues, one of the most + frequently underrated and overlooked security breaches is the simple + low-tech attack. The common victim is the one who leaves a console + logged in, perhaps as root, and leaves the system. Other times, an + anonymous "helpful soul" might ask for a password in order to assist + the user in "identifying a problem." This type of method allows an + intruder, especially one logged in as "root", access to system files. + + + + + + + + +Gwinn Informational [Page 1] + +RFC 2179 Network Security For Trade Shows July 1997 + + + Tips: + + * Educate sales and support staff regarding system logins, especially + "root" or other privileged accounts. + * Identify individuals who are not using exhibit systems for their + intended purpose, especially non-booth personnel. + * Request identification from anyone wishing to access systems + for maintenance purposes unless their identities are known. + +System Security + + 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. + +Password Security + + 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. + + Tips: + + * 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! + + + + + + + + + + +Gwinn Informational [Page 2] + +RFC 2179 Network Security For Trade Shows July 1997 + + +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. + + Tips: + + * 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. + +Use of Authentication Tokens + + 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. + + + + +Gwinn Informational [Page 3] + +RFC 2179 Network Security For Trade Shows July 1997 + + + 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. + + Tips: + + * 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 + + 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. + +Network File Sharing + + 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 + + + +Gwinn Informational [Page 4] + +RFC 2179 Network Security For Trade Shows July 1997 + + + 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. + + Tips: + + * 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 Hosts + + 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. + + Tips: + + * 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. + +SetUID and SetGID binaries (Unix systems) + + 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. + + + + +Gwinn Informational [Page 5] + +RFC 2179 Network Security For Trade Shows July 1997 + + + Tips: + + * "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. + +System Directory Ownership and Write 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. + +Network Services + + 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. + + Tips: + + * On Unix systems, comment out "R services" (rexec, rsh, rlogin) in + /etc/inetd.conf. + * Check for other unknown or unneeded services. + +Trivial File Transfer Protocol (TFTP) + + 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. + + + + + + + + +Gwinn Informational [Page 6] + +RFC 2179 Network Security For Trade Shows July 1997 + + +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: + + * ftp://info.cert.org/pub/tools/tcp_wrappers/ + +BIND (Berkeley Internet Name Daemon) + + 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: + + * ftp://ftp.isc.org/isc/bind + +Sendmail and Mailer Security + + 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. + +Web Server Scripting Security + + 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. + +Other Suggestions + + * 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. + + + + + + + +Gwinn Informational [Page 7] + +RFC 2179 Network Security For Trade Shows July 1997 + + + * 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. + +General Network 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. + +Packet Filtering + + 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: + + + + + + + +Gwinn Informational [Page 8] + +RFC 2179 Network Security For Trade Shows July 1997 + + + 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. + + + + + +Gwinn Informational [Page 9] + +RFC 2179 Network Security For Trade Shows July 1997 + + +Author's Address + + R. Allen Gwinn, Jr. + Associate Director, Computing + Business Information Center + Southern Methodist University + Dallas, TX 75275 + + Phone: 214/768-3186 + EMail: allen@mail.cox.smu.edu or allen@radio.net + + +Contributing Writer + + Stephen S. Hultquist + President + Worldwide Solutions, Inc. + 4450 Arapahoe Ave., Suite 100 + Boulder, CO 80303 + + Phone: +1.303.581.0800 + EMail: ssh@wwsi.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gwinn Informational [Page 10] + |