rfc2179.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 564 行 · 第 1/2 页

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]