doc: Add RFC documents

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]
+