As per Relevance of the word password, we have this rfc below:
Network Working Group A.
Request for Comments: 2179 Networld+Interop NOC
Category: Informational July 1997
Network Security For Trade
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This document is designed to assist vendors and other participants
trade shows, such as Networld+Interop, in designing
protection against network and system attacks by
individuals. Generally, it has been observed that many
administrators and trade show coordinators tend to overlook
importance of system security at trade shows. In fact, systems
trade shows are at least as prone to attack as office-
platforms. Trade show systems should be treated as seriously as
office computer. A breach of security of a trade show system
render -- and has rendered -- an exhibitor's
inoperable -- sometimes for the entire event
This document is not intended to replace the multitudes
comprehensive books on the subject of Internet security. Rather,
purpose is to provide a checklist-style collection of
overlooked, simple ways to minimize the chance of a costly attack
We encourage exhibitors to pay special attention to this document
share it with all associated representatives
Physical
Before addressing technical security issues, one of the
frequently underrated and overlooked security breaches is the
low-tech attack. The common victim is the one who leaves a
logged in, perhaps as root, and leaves the system. Other times,
anonymous "helpful soul" might ask for a password in order to
the user in "identifying a problem." This type of method allows
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,
"root" or other privileged accounts
* Identify individuals who are not using exhibit systems for
intended purpose, especially non-booth personnel
* Request identification from anyone wishing to access
for maintenance purposes unless their identities are known
System
This section discusses technical security procedures for
on the vendor network. Although specifics tend to be for
systems, general procedures apply to all platforms
Password
Lack of passwords or easy to guess passwords are a relatively low
tech door into systems, but are responsible for a significant
of breakins. Good passwords are a cornerstone of system security
By default, PC operating systems like Windows 95 and MacOS do
provide adequate password security. The Windows login
provides no security (hitting the "ESC" key allows the user to
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
application on other systems for lack of passwords. Some
ship systems with null passwords, in some cases even
privileged accounts
* Change passwords, especially system and root passwords
* Mix case, numbers and punctuation, especially on
accounts
* Change system passwords on a regular basis
* Do not use passwords relating to the event, the company,
products being displayed. Systems personnel at Networld+Interop
when asked to assist booth personnel, often guess even
passwords
Gwinn Informational [Page 2]
RFC 2179 Network Security For Trade Shows July 1997
Extra Privileged
Some system vendors have been known to ship systems with
privileged accounts (for example, Unix systems with accounts
have root privileges [UID=0]). Some vendors may include a
system administration account that places a user in a
administrative program. Each additional privileged account
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
/etc/passwd, or by using the administrative tool when a
employees enhanced security. Verify all systems for extra
accounts and either disable them or change their password
appropriate
Make certain that privileged accounts are inaccessible from
other than the system console. Frequently systems rely on files
as /etc/securettys for a list of "secure" terminals. As a
rule, unless a terminal is in this file, a root login is
possible. Specific use of this feature should be covered in
system's documentation files
Tips
* Check /etc/passwd on Unix systems and the user
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
system console
Use of Authentication
Authentication tokens such as SecureID, Cryptocard, DES Gold
others, provide a method of producing "one-time" passwords.
principle advantage in a trade-show environment is to
worthless, packets captured by sniffers on the network. It should
treated as fact, that there are many packet sniffers and
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
to view them. Authentication tokens provide a password that is
valid for that one instance, and are useless after that. A
extension of the use of authentication tokens would be to use
for "trips home" (from the show network to a home site) to
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")
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-
network and communications to and from remote systems
Tips
* Contact vendors of authentication tokens/cards for
information as to how to integrate into specific environments,
on to specific platforms
* The public-domain utility "cryptosu" (csu), when used with
Cryptocard, provides a replacement for Unix's "su" command
employing a challenge/response style of authentication for
access
* Explore the use of ssh clients and servers
Anonymous
Anonymous FTP accounts can easily turn into a security hole.
this service if not specifically needed. In the event that
FTP is to be used, the following tips may help secure it
* When a user logs in as "anonymous", they should be locked into
specific directory tree. Be sure that FTPd properly chroots to
appropriate directory. A "cd /" should put an anonymous user at
top of the "public" tree, and not the system's root directory
* Some systems may allow symbolic links (or "shortcuts") to take
user outside the allowed tree. Verify all links inside
anonymous FTP hierarchy
* Make sure that ftp's root directory is "owned" by someone
than the 'ftp' account. Typically, it should be owned by "root".
* Do not use a world-writable incoming directory unless
necessary. Many sites use these as a way for users to
files into the site. This can, and frequently does, turn into
archive for stolen software (referred to by the pirate community
"warez").
* Removing read permissions from the directory permissions (chmod 733
on Unix systems) prohibits an anonymous user from being able
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
Writable file shares without some form of security are invitations
destruction of information and demonstrations. Whether using NFS
Unix systems, or PC sharing facilities like CIFS, AppleShare,
NetWare, close attention should be paid to security of the
Gwinn Informational [Page 4]
RFC 2179 Network Security For Trade Shows July 1997
exported. Keep in mind that one's competition frequently shares
same network at a trade show! Security for both read and
access should be employed and each access point examined
Exporting a writable NFS filesystem to the world grants anyone
ability to read and write any file in the exported mount point.
this is done, for example, with a system directory such as "/"
"/etc", it is a simple matter to edit password files to create one
self access to a system. Therefore, /etc/exports should be
examined to be certain that nothing of a sensitive nature is
to anyone but another trusted host. Anything exported to the
public should be exported "read-only", and verified for
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
Trusted host entries are a method for allowing other
"equivalent" security access to another host computer. Some
ship systems with open trusted host files. Make certain that
issue is addressed
Tips
* On Unix systems, check for a '+' entry (all systems trusted)
/etc/hosts.equiv and all ".rhosts" files (there may be
.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
"/usr/local/lib/xhost +". Remove this
SetUID and SetGID binaries (Unix systems
On Unix systems, the "suid" bit on a system executable program
the program to execute as the owner. A program that is setUID
"root" will allow the program to execute with root privileges.
are multiple legitimate reasons for a program to have
privileges, and many do. However, it may be unusual to have
programs in individual user directories or other non-system places.
scan of the filesystems can turn up any program with its suid or
bit set. Before disabling any programs, check the legitimacy of
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
a setuid file anywhere in the system, including those on
mounted partitions
* "find / -group kmem -perm -2000 -print" will do the same for
group permissions
System Directory Ownership and Write
Check ownership of all system directories and permissions needed
write or modify files. There is no simple way to do this on
operating systems like Windows NT without simply checking all
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
files in such area. Pay special attention to "/" and "/etc".
should be owned by some system account-not by an individual user
When in doubt, contact the vendor of the system software
confirmation of the appropriate directory or file permissions
Network
Any servers not needed should be disabled. The notorious "R services
(rexec, rsh, and rlogin) are particularly prone to security
and should be disabled unless specifically needed. Pay
attention to trusted hosts files, and be aware of the risk of
spoofing attacks from machines "pretending" to be trusted hosts
Tips
* On Unix systems, comment out "R services" (rexec, rsh, rlogin)
/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
good general practice to disable TFTP. If TFTP is needed,
that only files targeted for export are accessible. A simple way
check security is to attempt to tftp files such as /etc/passwd
/etc/motd to check accessiblity of system files
Gwinn Informational [Page 6]
RFC 2179 Network Security For Trade Shows July 1997
TCP Connection
Public domain software (TCP Wrappers or "tcpd" for Unix systems
allow restriction and monitoring of TCP connections on a host by
basis. Systems can be configured to notify an administrator
syslog when any unauthorized party attempts to access the host.
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
host is going to be acting as DNS, use the latest version of BIND
It is available at
* ftp://ftp.isc.org/isc/
Sendmail and Mailer
A great number of previous versions of Sendmail have known
holes. Check installed sendmail for the most recent version
Alternatively, consult the operating system vendor to get the
recent release for the platform
Web Server Scripting
All Web server scripts and binaries should be checked (especially
"...httpd/cgi-bin" directory) for those that allow shell commands
be executed. Many attacks in recent months have focused on the use
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
web server
Other
* Check with the vendor of the operating system for known
issues. Make certain that all systems have the latest version
software--especially security patches to fix specific problems
* Examine log files on the host frequently. On Unix systems,
"last" command will furnish information on recent logins and
they came from. The "syslogs" or "Event Viewer" will contain
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
...httpd/log/error_log) will contain information on who has
accessing a WWW server, what has been accessed, and what
failed
* Good backups are the best defense against system damage.
backups before placing a system on the trade show network
continue backups throughout the show and again following the event
A final backup set is useful to examine for possible attempts
(or successful) penetrations of system security
General Network
As would be expected at network trade shows (large or otherwise),
there are many entities running packet sniffers. Most are
who have a legitimate need to run them during the course of
demonstrations. However, be aware that there are many "
ears" on network segments--any of whom can "hear" or "see
information as it crosses the net. Particularly prone
eavesdropping are telnet sessions. A good rule of thumb is to
that "when you type your password, the only one that doesn't see
is you!"
It is a good practice to not log in (or "su") to an account
privileges across the network if at all possible. As
previously, authentication tokens and ssh are a simple way to
security to system account access
Packet
Many routers support basic packet filtering. If a router can
deployed between the local network and the show's network,
basic packet filtering should be employed. Below is a good "general
packet filter approach. The approach itself is ordered
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
acceptable traffic, a good approach to a filter ruleset, in order
execution priority, might be
Gwinn Informational [Page 8]
RFC 2179 Network Security For Trade Shows July 1997
General Global Denials/
1 Filter spoofed source addresses by interface. Match
addresses to routing information available for the interface
Discard packets with source addresses arriving on one
(from the "outside" for example) claiming a source address
another interface (the "inside").
2 Filter all source routed packets unless source routing
specifically needed
3 Allow outbound connections from "inside" hosts
4 Allow established TCP connections (protocol field contains 6
the TCP flags field either contains ACK or does NOT contain
bit). Only filter requests for 'new' connections
5 Filter 'new' connections with source port of 25. Prevents
from pretending to be a remote mail server
6 Filter loopback address (source address 127.0.0.1).
packets from a misconfigured DNS resolver
Specific Global Service
1 Specifically block all "R-command"
(destination ports 512-515).
2 Block telnet (destination port 23) from any host not
telnet access from the outside. (If you use ssh, you
block it from all hosts!)
3 Add specific filters to deny other specific protocols to
network, as needed
Specific Host/Service
1 Add specific access to specific "public" hosts'
(unsecure FTP or WWW servers).
2 Allow SMTP (source and destination port 25) for electronic
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),
appropriate
6 Add specific filters to allow other desired specific
or to open certain ports to specific machines
Final Service
1 Deny all other UDP and TCP services not allowed by the
filters
Gwinn Informational [Page 9]
RFC 2179 Network Security For Trade Shows July 1997
Author's
R. Allen Gwinn, Jr
Associate Director,
Business Information
Southern Methodist
Dallas, TX 75275
Phone: 214/768-3186
EMail: allen@mail.cox.smu.edu or allen@radio.
Contributing
Stephen S.
Worldwide Solutions, Inc
4450 Arapahoe Ave., Suite 100
Boulder, CO 80303
Phone: +1.303.581.0800
EMail: ssh@wwsi.
Gwinn Informational [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
