RFC 2179

Network Security For Trade Shows 🎀

okay bestie, this is RFC 2179 🦋 It's an Informational doc from the Network Working Group, written by A. Gwinn of the Networld+Interop NOC Team, dated July 1997. It doesn't obsolete or update any other RFCs, so it's a standalone little guide 💅

---

Status of this Memo ✨

okay so the status part is super chill: this memo gives info to the Internet community, but it does not specify an Internet standard of any kind 🙈 Distribution is unlimited, so share it with everyone 💜

Abstract 🌸

this doc is here to help vendors and other people working at trade shows (think Networld+Interop) protect their stuff from network and system attacks by unauthorized people 🔥 Like, it's been noticed that a lot of sysadmins and trade show coordinators kinda sleep on security at these events 💀 Trade show systems are at least as easy to attack as office machines!! They should be treated as seriously as an office computer 😭 And a security breach can make an exhibitor's demos totally broken. Sometimes for the WHOLE event 😱

This isn't meant to replace the huge pile of comprehensive books on Internet security 📚 It's more of a checklist of easy-to-forget, simple moves that cut down the chance of a costly attack. Exhibitors, please pay extra attention and pass this along to all your reps 🫶

Physical Security 🔐

before we get into the technical stuff, the most underrated breach is the super low-tech one 🙈 The classic victim leaves a console logged in, maybe as root, and just walks away 💀 Other times, some anonymous "helpful soul" asks for a password so they can help the user with "identifying a problem." 🧚 That lets an intruder (especially one logged in as "root") get into system files. Yikes.

Tips:

• Educate sales and support staff about system logins, especially "root" or other privileged accounts 🎀
• Identify people who aren't using exhibit systems for their intended purpose, especially non-booth personnel 👀
• Ask for identification from anyone who wants to access systems for maintenance, unless their identities are known 🪪

System Security 💻

this section covers technical security procedures for workstations on the vendor network 💅 Even though the specifics mostly target Unix systems, the general procedures apply to all platforms 🌈

Password Security 🔑

lack of passwords or easy-to-guess passwords are a pretty low-tech way into systems, but they're behind a big chunk of breakins 😭 Good passwords are the cornerstone of system security, no cap.

By default, PC operating systems like Windows 95 and MacOS don't give you adequate password security 💀 The Windows login password gives you zero security (hitting the "ESC" key lets the user skip password entry, bestie what??). Password security for these machines is possible, but it's beyond the scope of this doc 🦋

Tips:

• Check /etc/passwd on Unix systems, and the user administration app on other systems, for missing passwords. Some vendors ship systems with null passwords, sometimes 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 🗓️
• Don't use passwords related to the event, the company, or the products being displayed. The systems people at Networld+Interop, when asked to help booth personnel, often guess even root passwords!! 😱

Extra Privileged Accounts 👑

some system vendors have been known to ship systems with multiple privileged accounts (like Unix systems with accounts that have root privileges [UID=0]) 💅 Some vendors may also include a separate system administration account that drops a user into a specific administrative program. Every extra privileged account is yet another opportunity for abuse 🙃

Generally, if a Unix system doesn't need extra root accounts, you can disable them by putting "*" in the password field of /etc/passwd, or by using the administrative tool when a system employs enhanced security 🔒 Check all systems for extra privileged accounts, then either disable them or change their passwords as needed 🫶

Make sure privileged accounts are only accessible from the system console 🖥️ Systems often rely on files like /etc/securettys for a list of "secure" terminals. As a general rule, unless a terminal is in that file, a root login isn't possible. Any 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 app 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 like SecureID, Cryptocard, DES Gold and others give you "one-time" passwords, which is so iconic ✨ The main perk at a trade show is that they make packets captured by sniffers on the network totally worthless 🗑️ You should treat it as fact that there are tons of packet sniffers and other admin tools constantly (legitimately) watching the network, especially at a big network-focused trade show 👀 Typed passwords are sent in clear text across the network by default, so others can read them. Tokens give you a password that's only valid for that one instance, and it's useless after that 💖 A logical extension would be using them for "trips home" (from the show network to a home site) to lower the chance of off-site security problems 🏠

An alternative to tokens is the secure shell ("ssh") protocol, which gives you an encrypted connection between clients and servers 🦋 This connection can carry both login traffic and arbitrary port-to-port communication, so it's a powerful tool for securing an in-booth network and talking to remote systems 🌸

Tips:

• Contact vendors of authentication tokens/cards for more info on how to integrate them into specific environments or onto specific platforms 📞
• The public-domain utility "cryptosu" (csu), used with a Cryptocard, replaces Unix's "su" command and uses a challenge/response style of authentication for root access 🧁
• Explore using ssh clients and servers 🔍

Anonymous FTP 📂

anonymous FTP accounts can turn into a security hole SO easily 😭 Disable the service if you don't specifically need it 🚫 If you do use anonymous FTP, these tips can help lock it down 🔐

• When a user logs in as "anonymous", they should be locked into a specific directory tree. Make sure FTPd properly chroots to the right directory. A cd / should put an anonymous user at the top of the "public" tree, 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 ftp's root directory is "owned" by someone other than the ftp account. Typically, it should be owned by "root" 👑
• Don't use a world-writable incoming directory unless it's absolutely necessary. Lots of sites use these so users can transfer files in, and this can, and frequently does, turn into an archive for stolen software (which the pirate community calls "warez") 🏴‍☠️
• Removing read permissions from the directory (chmod 733 on Unix systems) stops an anonymous user from listing the directory's contents. Files can still be deposited as usual, but they can't be retrieved unless the user knows the exact file name 🕵️

---

Part 1 of this one is done! 🌈 More of it is coming in part 2 💖

System Directory Ownership and Write Permissions ✨

okay so this one is about checking who owns your system directories and who can write to them 📁 there's no simple way to do this on PC systems like Windows NT without checking every single file and directory, or using a version of "ls" that lists ACLs. bestie, that's a lot 💀

On Unix systems, a directory with permissions like drwxrwxrwx (such as /tmp) is world-writable, which means anyone can create or modify files in that area 🙈 pay extra attention to / and /etc. These should be owned by some system account, not by an individual user 👑 when you're not sure, contact the vendor of the system software to confirm the right directory or file permissions 🫶

Network Services 🌸

any servers you don't need should be disabled. the notorious "R services" (rexec, rsh, and rlogin) are especially prone to security problems, so turn them off unless you specifically need them 😭 pay close 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 get at system files, so it's good general practice to disable it 💅 if you do need TFTP, verify that only files meant for export are accessible. a simple way to check is to try tftp on files like /etc/passwd or /etc/motd and see whether you can reach system files 🔍

TCP Connection Monitoring 🎀

there's public domain software (TCP Wrappers, or "tcpd" for Unix systems) that lets you restrict and monitor TCP connections on a host-by-host basis ✨ systems can be set up to notify an administrator and syslog whenever an unauthorized party tries to access the host 🚨 you can get this software 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 act as DNS, use the latest version of BIND 💖 it's available at:

• ftp://ftp.isc.org/isc/bind

Sendmail and Mailer Security 💌

a whole bunch of previous versions of Sendmail have known security holes 😬 check your installed sendmail for the most recent version. or, ask the operating system vendor for the newest release for your platform 🧚

Web Server Scripting Security 🕸️

check all Web server scripts and binaries (especially in the "...httpd/cgi-bin" directory) for anything that lets shell commands be executed 🙅‍♀️ lots of attacks in recent months have focused on utilities like "phf" for reaching /etc/passwd on a target system. remove any script that isn't needed to run your web server 🧹

Other Suggestions 💡

• check with the vendor of the operating system for known security issues. make certain all systems have the latest software, especially security patches for specific problems ✅
• examine log files on the host frequently 👀 on Unix systems, the "last" command shows recent logins and where they came from. the "syslogs" or "Event Viewer" have more specific info on system events 📜
• Web server logfiles (...httpd/log/access_log and ...httpd/log/error_log) record who has been accessing a WWW server, what has been accessed, and what has failed 🕵️‍♀️
• good backups are the best defense against system damage 💾 back up before placing a system on the trade show network, keep backing up throughout the show, and back up again after the event. a final backup set is useful for examining possible attempts at (or successful) penetrations of system security 🔐

General Network Security 🌐

as you'd expect at network trade shows (big or small), there are lots of entities running packet sniffers 🦈 most are exhibitors who have a legit need to run them during product demos. but be aware that there are many "listening ears" on network segments, and any of them can "hear" or "see" information as it crosses the net 👂 telnet sessions are especially prone to eavesdropping. 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's a good practice to not log in (or "su") to an account with privileges across the network if at all possible. as mentioned earlier, 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 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.

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