idnits 2.17.1 draft-rfced-info-gwinn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 364 has weird spacing: '...smu.edu or a...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 1997) is 9871 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Gwinn 2 INTERNET-DRAFT Networld+Interop NOC Team 3 Obsoletes: None April 1997 4 Category: Informational 6 Network Security For Large Trade Shows 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress". 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstract.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 This document is designed to assist vendors and other participants in 30 large trade shows, such as Networld+Interop, in designing effective 31 protection against network and system attacks by unauthorized 32 individuals. Generally, it has been observed that many system 33 administrators and trade show coordinators tend to overlook the 34 importance of system security at trade shows. In fact, systems at 35 trade shows are just as prone to attack as office-based platforms. 36 Trade show systems should be treated as seriously as an office 37 computer. A breach of security of a trade show system can render (and 38 has rendered) a vendor's demonstrations inoperable--quite possibly 39 for the entire show! 41 This dcoument is not intended to replace the multitudes of comprehensive 42 books on the subject of Internet security. Rather, its purpose is to 43 provide a checklist-style collection of frequently overlooked, simple 44 ways to minimize the chance of a costly attack. Vendors are 45 encouraged to pay special attention to this document and share it 46 with all associated representatives. 48 Physical Security 49 Before addressing the technical, one of the most frequently 50 underrated (and overlooked) security breaches is the simple low-tech 51 attack. The common victim is the one who leaves a console logged in, 52 perhaps as root, and walks away. Other times, an anonymous "helpful 53 soul" might ask for a password in order to assist the user in 54 "identifying a problem." This type of method allows an intruder, 55 especially one logged in as "root", access to system files. 57 Tips: 59 * Educate sales and support staff as to the importance of keeping 60 an eye on logged-in systems--especially "root" or other 61 privileged accounts. 62 * Identify individuals who are not using exhibit systems for their 63 intended purpose (i.e. playing "Quake" or "Doom" on one of 64 your workstations). 65 * Request identification from anyone wishing to access systems 66 for maintenance purposes unless they are known personally. 68 System Security 70 This section discusses technical security procedures for workstations 71 on the vendor network. Although primarily aimed at Unix systems, 72 many general procedures can be applied to other platforms. 74 Password Security 76 Lack of passwords or easy to guess passwords are a relatively low- 77 tech door into systems, but are responsible for a significant number 78 of breakins. Good passwords are a cornerstone of system security. 80 Tips: 82 * Check /etc/passwd for lack of passwords. Some vendors ship systems 83 with null passwords, in some cases even in root accounts. 84 * Change passwords, especially system passwords. 85 * Mix case, numbers and punctuation especially on root passwords. 86 * Change system passwords on a regular basis. 88 Extra "root" Accounts 90 Some system vendors have been known to ship systems with accounts, 91 other than root, that have root privileges (UID=0). For example, some 92 vendors may include a separate system administration account that 93 places a user in a specific administrative program. If a system does 94 not need additional root accounts, these can be disabled by placing 95 "*" in the password field of /etc/passwd. Check all systems for extra 96 "root" accounts and either disable them or change their password as 97 appropriate. 99 Use of Authentication Tokens 101 Authentication tokens such as SecureID, Cryptocard, DES Gold and 102 others, provide a method of producing "one-use" passwords for 103 specific access. The advantages are obvious. Remember that there are 104 many packet sniffers and other administration tools constantly 105 watching the network-especially at a large network-oriented trade 106 show. Typed passwords, by default, are sent clear text across the 107 network, allowing others to view them. Authentication tokens provide 108 a password that is only valid for that one instance, and are useless 109 after they are used. A logical extension of the use of authentication 110 tokens would be to use them for "return trips home" (show network 111 back to a home site) to minimize the chance of off-site security 112 problems. 114 Tips: 116 * Contact vendors of authentication tokens/cards for further 117 information as to how to integrate into specific environments, or 118 on to specific platforms. 119 * The public-domain utility "cryptosu" (csu), when used with a 120 Cryptocard, provides a replacement for Unix's "su" command, 121 employing a challenge/response style of authentication for root 122 access. 124 Anonymous FTP 126 Anonymous FTP accounts can easily turn into a security hole. The 127 simplest rule-of-thumb to follow is to disable this service if it is 128 not specifically needed. However, if anonymous FTP is to be used, 129 the following tips may provide assistance into securing it. 131 * When a user logs in as "anonymous", they should be locked into a 132 specific directory tree. Be sure that it properly chroots to the 133 appropriate directory. A "cd /" should put an anonymous user at the 134 top of a tree. 135 * Some systems may allow symbolic links to take a user outside the 136 allowed tree. Verify all links inside the anonymous hierarchy. 137 * Make sure that ftp's root directory is owned by someone other than 138 the 'ftp' account. Typically, it should be owned by "root". 139 * Examine the need for a world-writeable incoming directory. Many 140 sites use these as a way for outside users to transfer files into 141 the site. This, however, can turn into an archive (and frequently 142 does) for stolen software. Removing the "read" bit from the 143 directory permissions (chmod 733) prohibits an anonymous user from 144 being able to list the contents of a directory. Files can be 145 deposited as usual, but not retrieved unless the exact name of the 146 file is known. 148 NFS Exports 150 Exporting an writeable NFS filesystem to the world grants anyone the 151 ability to read and write any file in the exported mount point. If 152 this is done, for example, with a system directory such as "/" or 153 "/etc", it is a simple matter to edit password files to create one- 154 self access to a system. Therefore, /etc/exports should be closely 155 examined to be certain that nothing of a sensitive nature is exported 156 to anyone but another trusted host. Anything exported to the general 157 public should be exported "read-only". 159 Trusted Hosts 161 Trusted host entries are a method for allowing other hosts 162 "equivalent" security access to another host computer. Some vendors 163 ship systems with open trusted host files. This should be addressed. 165 Tips: 167 * Check for a '+' entry (all systems trusted) in /etc/hosts.equiv and 168 all ".rhosts" files (there may be multiple .rhosts files) and 169 remove it. 170 * Check for an "xhost +" entry in the "...X11/xdm/Xsession" file. 171 Most often, an "xhost" entry will appear with a pathname such as 172 "/usr/local/lib/xhost +". This should be disabled. 174 SetUID and SetGID binaries 176 The "suid" bit on a system executable program allows the program to 177 execute as the owner. A program that is setUID to "root" will allow 178 the program to execute with root privileges. There are multiple 179 legitimate reasons for a program to have root privileges, and many 180 do. However, it may be unusual to have suid programs in user 181 directories, or other non-system places. A scan of the filesystems 182 can turn up any program with its suid or sgid bit set. Before 183 disabling any programs, however, it is strongly suggested that the 184 legitimacy be confirmed. 186 Tips: 188 * "find / -user root -perm -4000 -print" will find any occurrence of 189 a setuid file anywhere in the system, including those on NFS 190 mounted partitions. 191 * "find / -group kmem -perm -2000 -print" will do the same for kmem 192 group permissions. 194 System Directory Ownership and Write Permissions 196 Check ownership of all system directories and permissions needed to 197 write or modify files. A directory with permissions such as 198 "drwxrwxrwx" (such as /tmp) is world-writeable and anyone can create 199 or modify files in such area. Pay special attention to "/" and 200 "/etc". These should be owned by some system account-not by an 201 individual user. If in doubt, contact the vendor of the system 202 software for confirmation of these settings. 204 Network Services in /etc/inetd 206 Any servers not needed should be disabled. The notorious "R services" 207 (rexec, rsh, and rlogin) are particularly prone to security problems 208 and should be disabled unless specifically needed. If "R services" 209 are required, pay particular attention to trusted hosts, and be aware 210 of the risk of IP spoofing attacks from machines "pretending" to be 211 trusted hosts. 213 Tips: 215 * Comment out "R services" (rexec, rsh, rlogin) in /etc/inetd. 216 * Check for unknown or unneeded services. 218 Trivial File Transfer Protocol (TFTP) 220 TFTP can be an easy way for an intruder to access system files. A 221 good practice is to disable TFTP if it is not needed. If it is 222 needed, check to see that sensitive files are not accessible. 223 Attempting to tftp files such as /etc/passwd or /etc/motd will verify 224 accessiblity of a system from the outside. 226 TCP Connection Montoring 228 Public domain software (TCP Wrappers or "tcpd") allows TCP 229 connections to be restricted and monitored on a host by host basis. 230 This software can be configured to notify an administrator (as well 231 as syslog) attempts to access the host by unauthorized parties. This 232 software is available from: 234 ftp://info.cert.org/pub/tools/tcp_wrappers/ 236 BIND (Berkeley Internet Name Daemon) 238 Earlier versions of BIND have been prone to various attacks. If a 239 host is going to be acting as DNS, the latest version of BIND should 240 be used. It can be downloaded from: 242 ftp://ftp.isc.org/isc/bind 244 Sendmail and Mailer Security 246 A great number of previous versions of Sendmail have known security 247 holes. All Sendmail versions should be checked for the most recent 248 version. Alternatively, operating system vendors should be consulted 249 for their most recent release. 251 Web Server cgi-bin Security 253 All server cgi-bin scripts and binaries should be checked (especially 254 the "...httpd/cgi-bin" directory) for those that allow shell commands 255 to be executed. Many attacks, of recent months, have centered around 256 the use of utilities such as "phf" for accessing /etc/passwd on a 257 target system. Any cgi that is not needed in the course of operation 258 of a web server should be removed. 260 Other Suggestions 262 * Check with the vendor of operating systems for known security 263 issues. Make certain that all systems have the latest version of 264 the software as well as any security patches to fix specific 265 problems. 267 * Examine log files on the host frequently. The "last" command will 268 furnish information on recent logins and where they came from. The 269 "syslogs" will contain more specific information on system events. 270 Web server logfiles (...httpd/log/access_log and 271 ...httpd/log/error_log) will contain information on who has been 272 accessing a WWW server, what has been accessed, and what has 273 failed. 275 * Good backups are the best defense against system damage. A 276 rule-of-thumb is to "back information up when it can't afford to be 277 lost". 279 General Network Security 281 As would be expected at trade shows (large or otherwise), there are 282 many entities running packet sniffers. Most are vendors who have a 283 legitimate need to run them during the course of product 284 demonstrations. A caveat to this is that there are many "listening 285 ears" on network segments-any of whom can "hear" or "see" information 286 as it crosses the net. Particularly prone to eavesdropping are telnet 287 sessions. A good rule of thumb is to assume that "when you type your 288 password, the only one that doesn't see it is you!" 289 It is a good practice to not log in (or "su") to an account with root 290 privileges, across the network if at all possible. As mentioned 291 previously, authentication tokens are a simple way to add security to 292 system account access. 294 Packet Filtering 296 Many routers support basic packet filtering. Below is listed a good 297 "general" packet filter approach. The approach itself is ordered into 298 categories: 300 * General global denials/acceptance. 302 * Specific global service denials. 304 * Specific service acceptance. 306 * Final denial of all other TCP/UDP services. 308 Based on this theory, a good approach to a filter ruleset, in order 309 of execution priority, might be: 311 General Global Denials/Acceptance 313 1 Filter spoofed source addresses by interface. Match source 314 addresses to routing information available for the interface. 315 Discard packets with source addresses arriving on one interface 316 (from the "outside" for example) claiming a source address on 317 another interface (the "inside"). 318 2 Filter all source routed packets unless source routing is 319 specifically needed. 320 3 Allow outbound connections from "inside" hosts. 321 4 Allow established TCP connections (protocol field contains 6 and 322 the TCP flags field either contains ACK or does NOT contain SYN 323 bit). Only filter requests for 'new' connections. 324 5 Filter 'new' connections with source port of 25. Prevents people 325 from pretending to be a remote mail server. 326 6 Filter loopback address (source address 127.0.0.1). Prevents 327 packets resulting from misconfigured DNS resolver. 329 Specific Global Service Denials 331 1 If not required, specifically block all "R-command" ports 332 (destination ports 512-515). 333 2 Block telnet (destination port 23) from any host not requiring 334 telnet access from the outside. 335 3 Add specific filters to deny other specific protocols to the 336 network, as needed. 338 Specific Host/Service Acceptance 340 1 Add general open access, if desired, to specific "public" hosts 341 (unsecure FTP or WWW servers). 342 2 Allow SMTP (source and destination port 25) for electronic mail. 343 3 Allow inbound FTP connections (source port 20). 344 4 Allow DNS (source and destination port 53, UDP & TCP). If zone 345 transfers are not needed, block the TCP ports. 346 5 Allow RIP packets in (source and destination port 520, UDP). 347 6 Add specific filters to allow other desired specific protocols 348 and/or open certain ports to specific machines. 350 Final Service Denial 352 1 Deny all other UDP and TCP services not addressed in the previous 353 filters. 355 Author's Address 357 R. Allen Gwinn, Jr. 358 Associate Director, Computing 359 Business Information Center 360 Southern Methodist University 361 Dallas, TX 75275 363 Phone: 214/768-3186 364 EMail: allen@mail.cox.smu.edu or allen@radio.net 366 INTERNET-DRAFT EXPIRES: OCTOBER 1997 INTERNET-DRAFT 368 Expire in six months