idnits 2.17.1 draft-ietf-grip-isp-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 6 months document validity. ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1501 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2182' is mentioned on line 807, but not defined == Unused Reference: 'RFC1034' is defined on line 1289, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 1292, but no explicit reference was found in the text == Unused Reference: 'RFC1834' is defined on line 1303, but no explicit reference was found in the text == Unused Reference: 'RFC1835' is defined on line 1306, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DPR1998' -- Possible downref: Non-RFC (?) normative reference: ref. 'GAR1997' -- Possible downref: Non-RFC (?) normative reference: ref. 'HUG1995' ** Obsolete normative reference: RFC 977 (Obsoleted by RFC 3977) ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Downref: Normative reference to an Informational RFC: RFC 1786 ** Downref: Normative reference to an Informational RFC: RFC 1834 ** Downref: Normative reference to an Historic RFC: RFC 1835 ** Obsolete normative reference: RFC 2010 (Obsoleted by RFC 2870) ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) ** Downref: Normative reference to an Informational RFC: RFC 2196 ** Obsolete normative reference: RFC 2267 (Obsoleted by RFC 2827) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' -- Possible downref: Non-RFC (?) normative reference: ref. 'SPE1994' -- Possible downref: Non-RFC (?) normative reference: ref. 'SSH1997' -- Possible downref: Non-RFC (?) normative reference: ref. 'VIX1995' Summary: 17 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Tom Killalea 2 INTERNET-DRAFT neart.ie 3 Valid for six months December1998 5 Security Expectations for Internet Service Providers 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. This Internet Draft is a 15 product of the GRIP Working Group of the IETF. 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet 20 Drafts as reference material or to cite them other than as a 22 To learn the current status of any Internet Draft, please check the 23 directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Copyright Notice 29 Copyright (C) The Internet Society (1998). All Rights Reserved. 31 Abstract 33 The purpose of this document is to express the general Internet 34 community's expectations of Internet Service Providers (ISPs) with 35 respect to security. 37 It is not the intent of this document to define a set of requirements 38 that would be appropriate for all ISPs, but rather to raise awareness 39 among ISPs of the community's expectations, and to provide the 40 community with a framework for discussion of security expectations 41 with current and prospective service providers. 43 Table of Contents 45 1 Introduction 46 1.1 Conventions Used in this Document 48 2 Incident Response 49 2.1 ISPs and Security Incident Response Teams (SIRTs) 50 2.2 Assistance with Inbound Security Incidents 51 2.3 Assistance with Outbound or Transit Security Incidents 52 2.4 Notification of Vulnerabilities and Reporting Incidents 53 2.5 Contact Information 54 2.6 Communication and Authentication 56 3 Appropriate Use Policy 57 3.1 Announcement of Policy 58 3.2 Sanctions 60 4 Protection of the Community 61 4.1 Cooperation 62 4.2 Data Protection 63 4.3 Training 64 4.4 Registry Data Maintenance 66 5 Network Infrastructure 67 5.1 Routers 68 5.2 Switches, Terminal Servers, Modems and other Network Devices 69 5.3 Anonymous telnet and other unlogged connections 70 5.4 The Network Operation Centre (NOC) and Network Management 71 5.5 Physical Security 72 5.6 Routing Infrastructure 73 5.7 Ingress Filtering on Source Address 74 5.8 Egress Filtering on Source Address 75 5.9 Route Filtering 76 5.10 Directed Broadcast 78 6 Systems Infrastructure 79 6.1 Policy 80 6.2 System Management 81 6.3 Backup 82 6.4 Software Distribution 84 7 Domain Name Service (DNS) 85 7.1 DNS Server Management 86 7.2 Authoritative Domain Name Service 87 7.3 Resolution Service 89 8 Email and Mail Services 90 8.1 Mail Server Administration 91 8.2 Secure Mail 92 8.3 Open Mail Relay 93 8.4 Message Submission 94 8.5 POP and IMAP Services 96 9 News Service (NNTP) 97 9.1 News Server Administration 98 9.2 Article Submission 99 9.3 Control Messages 100 9.4 Newsfeed Filters 102 10 Web-related Services 103 10.1 Webhosting Server Administration 104 10.2 Server Side Programs 105 10.3 Data and Databases 106 10.4 Logs and Statistics Reporting 107 10.5 Push and Streaming Services 108 10.6 Commerce 109 10.7 Content Loading and Distributed Authoring 110 10.8 Search Engines and other tools 112 11 References 114 12 Acknowledgements 116 13 Security Considerations 118 14 Author's Address 120 15 Full Copyright Statement 122 1 Introduction 124 IMPORTANT NOTE: 126 AS A RESULT OF DISCUSSIONS IN THE GRIP WORKING GROUP MEETING AT THE 127 43RD IETF, THIS IS THE LAST VERSION OF THIS DOCUMENT THAT YOU WILL 128 SEE. IT WILL BE REPLACED BY 3 NEW DOCUMENTS IN JANUARY 1999. - tomk. 130 The purpose of this document is to express the general Internet 131 community's expectations of Internet Service Providers (ISPs) with 132 respect to security. 134 A goal is that customers could have a framework that facilitates the 135 discussion of security with prospective service providers; 136 regrettably, such a discussion rarely takes place today. 138 Additionally, in informing ISPs of what the community hopes and 139 expects of them, a further goal is to encourage ISPs to become 140 proactive in making security not only a priority, but something to 141 which they point with pride when selling their services. 143 Under no circumstances is it the intention of this document to 144 dictate business practices. 146 This document is addressed to Internet service purchasing decision- 147 makers (customers) and to ISPs. 149 It has been argued that vendors begin to care about security only 150 when prompted by customers. I hope that this document will encourage 151 both parties to more readily express how much they care about 152 security, and that discussion between the community and its ISPs will 153 be increased. 155 1.1 Conventions Used in this Document 157 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", 158 and "MAY" in this document are to be interpreted as described in "Key 159 words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 161 2 Incident Response 163 A Security Incident Response Team (SIRT) is a team that performs, 164 coordinates, and supports the response to security incidents that 165 involve sites within a defined constituency. The Internet 166 community's expectations of SIRTs are described in "Expectations for 167 Computer Security Incident Response" [RFC2350]. 169 Whether or not an ISP has a SIRT, they should have a well-advertised 170 way to receive and handle reported incidents from their customers. 171 In addition, they should clearly document their capability to respond 172 to reported incidents. 174 2.1 ISPs and Security Incident Response Teams (SIRTs) 176 Some ISPs have SIRTs. However it should not be assumed that either 177 the ISP's connectivity customers or a site being attacked by a 178 customer of that ISP can automatically avail themselves of the 179 services of the ISP's SIRT. ISP SIRTs are frequently provided as an 180 added-cost service, with the team defining as their constituency only 181 those who specifically subscribe to (and perhaps pay for) Incident 182 Response services. 184 Thus it's important to determine what incident response and security 185 resources are available to you, and define your incident response 186 escalation chain BEFORE an incident occurs. 188 Customers should find out whether their ISP has a SIRT, and if so 189 what the charter, policies and services of that team are. This 190 information is best expressed using the SIRT template as shown in 191 Appendix D of "Expectations for Computer Security Incident Response" 192 [RFC2350]. If the ISP doesn't have a SIRT they should describe what 193 role if any they will take in incident response, and should indicate 194 if there is any SIRT whose constituency would include the customer 195 and to whom incidents could be reported. 197 2.2 Assistance with Inbound Security Incidents 199 When a security incident targeting one of their connectivity 200 customers occurs ISPs should inform the customer of the attack. The 201 ISP may also provide assistance to 203 - trace the 'apparent' origin of the attack and attempt to 204 determine the veracity of each step in the path (keeping in 205 mind that the source address may be spoofed). In cases where 206 the source address is spoofed the ISP could trace the point 207 at which the bogusly addressed traffic entered the ISP's 208 network. 210 - obtain contact information for the source of the attack using 211 whois [RFC1834 and RFC1835], the DNS [RFC1034 and RFC1035] or 212 relevant common mailbox names [RFC2142]. 214 - collect and protect evidence of the incident and guard against 215 its destruction or unintentional announcement. 217 If the event continues then, at the customer's request, ISPs may also 218 assist by logging in order to further diagnose the problem, or by 219 filtering certain types of traffic. 221 2.3 Assistance with Outbound or Transit Security Incidents 223 In the case where one of their connectivity customers appears to be 224 the source of a security incident an ISP will frequently be 225 contacted. The ISP may facilitate the administrators at the source 226 and the target of the incident getting in contact with each other, 227 normally by passing contact information for the target to the ISP's 228 customer. 230 An ISP may also be contacted to assist with incidents that traverse 231 their network but use bogus source addresses, such as SYN flooding 232 attacks [CA-96.21.tcp_syn_flooding]. Assistance in this case might 233 consist of using network traces on a hop by hop basis to identify the 234 point at which the bogusly addressed traffic entered the ISP's 235 network. In tracing such incidents it's frequently necessary to 236 coordinate with adjacent ISPs to form a complete chain of response 237 teams along the path of the attack. 239 2.4 Notification of Vulnerabilities and Reporting of Incidents 241 ISPs should be proactive in notifying customers of security 242 vulnerabilities in the services they provide. In addition, as new 243 vulnerabilities in systems and software are discovered they should 244 indicate whether their services are threatened by these risks. 246 When security incidents occur that affect components of an ISP's 247 infrastructure the ISP should promptly report to their customers 249 - who is coordinating response to the incident 251 - the vulnerability 253 - how service was affected 255 - what is being done to respond to the incident 257 - whether customer data may have been compromised 259 - what is being done to eliminate the vulnerability 261 - the expected schedule for response, assuming it can be 262 predicted 264 2.5 Contact Information 266 [RFC2142] states that sites (including ISPs) must maintain a mailbox 267 called SECURITY for network security issues, ABUSE for issues 268 relating to inappropriate public behaviour and NOC for issues 269 relating to network infrastructure. It also lists additional 270 mailboxes that are defined for receiving queries and reports relating 271 to specific services. 273 ISPs should consider using common URLs for expanded details on the 274 above (e.g., http://www.ISP-name-here.net/security/). 276 In addition, ISPs have a duty to make sure that their contact 277 information, in Whois, in the routing registry [RFC1786] or in any 278 other repository, is complete, accurate and reachable. 280 2.6 Communication and Authentication 282 ISPs SHOULD have clear policies and procedures on the sharing of 283 information about a security incident with their customers, with 284 other ISPs or SIRTs, with law enforcement or with the press and 285 general public. 287 ISPs SHOULD also be able to conduct such communication over a secure 288 channel. Note, however, that in some jurisdictions secure channels 289 might not be permitted. 291 3 Appropriate Use Policy 293 Every ISP should have an Appropriate Use Policy (AUP). 295 Whenever an ISP contracts with a customer to provide connectivity to 296 the Internet that contract should be governed by an AUP. The AUP 297 should be reviewed each time the contract is up for renewal, and in 298 addition the ISP should proactively notify customers as policies are 299 updated. 301 An AUP should clearly identify what customers shall and shall not do 302 on the various components of a system or network, including the type 303 of traffic allowed on the networks. The AUP should be as explicit as 304 possible to avoid ambiguity or misunderstanding. For example, an AUP 305 might prohibit IP spoofing. 307 3.1 Announcement of Policy 309 In addition to communicating their AUP to their customers ISPs should 310 publish their policy in a public place such as their web site so that 311 the community can be aware of what the ISP considers appropriate and 312 can know what action to expect in the event of inappropriate 313 behaviour. 315 3.2 Sanctions 317 An AUP should be clear in stating what sanctions will be enforced in 318 the event of inappropriate behaviour, and ISPs should be forthcoming 319 in announcing to the community when such sanctions are imposed. 321 4 Protection of the Community 323 ISPs play a crucial role in helping to improve the security of the 324 Internet. This and following sections describe a number of issues 325 which, should they be addressed by ISPs in a coordinated and timely 326 way, would have a very positive effect on the security of the 327 network, and would make it much more difficult for the perpetrators 328 to cover their tracks. 330 Later sections cover in some detail issues related to specific 331 services such as ingress filtering and open mail relays. Such issues, 332 if addressed by all the ISPs in a concerted way, could have a very 333 positive effect. 335 4.1 Cooperation 337 This section is about protecting the community. This requires that 338 we as a community work together to that end. It's worth observing 339 that many of the most significant successes in securing the Internet 340 could not have been achieved by anyone acting alone. 342 Cooperation may be put on legal ground. For example prior to 343 entering into peering agreements ISPs might specify the steps they 344 will take to cooperatively track security incidents that involve both 345 peers. 347 4.2 Data Protection 349 Many jurisdictions have Data Protection Legislation. Where such 350 legislation applies, ISPs should consider the personal data they hold 351 and, if necessary, register themselves as Data Controllers and be 352 prepared to only use the data in accordance with the terms of the 353 legislation. Given the global nature of the Internet ISPs that are 354 located where no such legislation exists should at least familiarise 355 themselves with the idea of Data Protection by reading a typical Data 356 Protection Act (e.g., [DPR1998]). 358 4.3 Training 360 It's important that all ISP staff be trained to be security-conscious 361 at all times and to be able to make appropriate use of tools that 362 enhance security. Some issues that they should be particularly aware 363 of include the use of secure channels for confidential information, 364 the risk of attacks that use social engineering, management of data 365 used for authentication, and so on. 367 4.4 Registry Data Maintenance 369 ISPs are commonly responsible for maintaining the data that is stored 370 in global repositories such as the Internet Routing Registry (IRR) 371 and the APNIC, InterNIC and RIPE databases. Updates to this data 372 should only be possible using strong authentication. 374 ISPs should 'SWIP' (Shared WhoIs Project) the address space that they 375 assign to their customers so that there is more specific contact 376 information for the delegated space. 378 5 Network Infrastructure 380 ISPs are responsible for managing the network infrastructure of the 381 Internet in such a way that it is 383 - reasonably resistant to known security vulnerabilities 385 - not easily hijacked by attackers for use in subsequent attacks 387 5.1 Routers 389 Routers are an excellent platform from which to launch a security 390 attack, as well as being attractive targets of themselves. 392 Many routers allow an attacker to do dangerous things such as: 394 - sniff transit traffic 396 - manipulate routing tables to redirect traffic 398 - manipulate interface states to disrupt service 400 - create routing flaps which could potentially cause Denial of 401 Service for large parts of the Internet 403 - create packets with spoofed addresses, and with any desired flags 404 set 406 - initiate ICMP packet storms and other Denial of Service attacks 408 - 'black hole' traffic (e.g., by holding a local route to a null or 409 invalid interface, by holding a local route to an invalid 410 next-hop (one which does not itself have a corresponding route, 411 and does not have a default), or worst yet, by using a dynamic 412 routing protocol to advertise availability of a low-cost route 413 and thus actively drawing traffic toward the black hole) 415 - launder connections to third-party destinations, facilitated by 416 the router's lack of logging 418 Such threats are amplified because of the central part in the 419 networking infrastructure that routers occupy, and the large 420 bandwidth frequently available to them. 422 So access to routers SHOULD be based on one-time passwords or better 423 (e.g., Kerberos) and should be as restricted as possible. 424 Connections to the router should be logged to a different system. 426 If the router supports different levels of authorisation these levels 427 should be used to restrict privileged access to the router. 429 Sessions should be encrypted to prevent sessions or data from being 430 stolen and to avoid replay attacks. 432 Routers should not run the 'small services', which are often enabled 433 by default. These may include bootp, chargen, daytime, discard, echo 434 and finger. 436 5.2 Switches, Terminal Servers, Modems and other Network Devices 438 ISPs should be similarly vigilant in their configuration of other 439 network devices. Unfortunately many such devices deployed in the 440 field support only minimal authentication, do authorisation on an 441 all-or-nothing basis and do little or no logging. In the past ISPs 442 have been left with no trail to follow after their switches were 443 reconfigured, their terminal servers were used to launch attacks on 444 third parties or their Uninterruptable Power Supplies were shut down. 446 Where possible access to such devices should be restricted only to 447 legitimate network administrators. 449 Network infrastructure devices frequently don't support extensive 450 internal logging because they have no long-term storage, like hosts' 451 hard drives. Many support syslog or SNMP traps however, or at least 452 a short internal event log or debugging mode which can be captured 453 through the console or a through a remote logging session. 455 Router or switch configurations should always be maintained on a file 456 server, so that they can be restored to previous configuration easily 457 and quickly. These backup configurations should obviously be 458 protected so that they cannot be transferred by unauthorised parties, 459 or overwritten with new bogus configurations. 461 5.3 Anonymous telnet and other unlogged connections 463 There are many network devices ranging from low-end routers to 464 printers that accept telnet connections without prompting for a 465 password. Obviously such devices, many of which don't maintain audit 466 trails, are very popular among attackers who wish to cover their 467 tracks. 469 If ISPs have such devices on their own network they should restrict 470 access to them. In addition, they should encourage their customers 471 to block access to such devices from outside of the customer's 472 network. 474 The use of telnet to manage network elements is strongly discouraged. 476 5.4 The Network Operation Centre (NOC) and Network Management 478 A NOC is a crucial part of an ISP's infrastructure, and should be 479 operated with appropriate regard to security. 481 A NOC frequently has management control over the configuration 482 information of network devices, and should be vigilant in restricting 483 access to that information. Loading of configuration information 484 into network devices is still frequently done using the TFTP protocol 485 [RFC1350], which not only lacks authentication and uses an insecure 486 channel, but calls for great care in configuration at the server end 487 [CA-91:18.Active.Internet.tftp.Attacks]. 489 A NOC will generally perform a network monitoring function by polling 490 (e.g., with ICMP Echo) a set of network devices periodically. In 491 selecting the set of devices to be polled the crucial role of the 492 devices in 5.2 shouldn't be overlooked. 494 Beyond simple polling a NOC may also use a network management 495 protocol such as SNMP to communicate with network devices. Usually 496 this will be used to 'get' the value of various variables, such as 497 the number of packets received on a particular interface. However 498 the protocol can be used to 'set' variables, perhaps with serious 499 results (e.g., the device can be reconfigured). In any case, SNMPv1 500 uses only trivial authentication. Where possible SNMP should be used 501 as a read-only tool to 'get' information from remote devices, and the 502 information gotten should be treated as confidential. 504 A further use of SNMP is in trap reporting, whereby a management 505 station is notified when certain exceptions occur. This information 506 should also be considered confidential, and the NOC should take care 507 that such trap reporting cannot of itself become a Denial of Service 508 attack. 510 5.5 Physical Security 512 The physical security of every installation should be given 513 appropriate consideration. This is particularly so for co-located 514 facilities to which people from different organisations and with 515 different security policies have access. 517 Three types of co-location arrangements are of particular interest: 519 - customers co-locating equipment at an ISP's facility 521 - ISPs co-locating equipment at an external facility with 522 authorised 'remote hands' 524 - ISPs co-locating equipment at an external facility with no 525 authorised physical access 527 The first case is most likely to directly concern the customer. If 528 an ISP has a co-location facility for the hosting of customer-owned 529 equipment many issues arise surrounding customer access to their co- 530 located equipment. 532 Ideally every customer would have a fully enclosed locking 'cage', 533 akin to a small room with walls and ceiling of heavy wire mesh 534 fencing, containing the racks in which their equipment is mounted. 535 Customers are allowed access to their own cage under escort by one of 536 the ISP's employees, or with keys that grant access specifically to 537 their cage. 539 This assignment of separate cages is expensive in terms of space 540 however, so many ISPs compromise by putting all co-located equipment 541 together in a single machine room, and managing the actions of 542 escorted customers very closely. However this may be insufficient to 543 prevent mishaps such as the accidental disconnection of another 544 customer's equipment. If a single machine room is used then the ISP 545 should provide separate locking cabinets for each co-location 546 customer in preference to an open common area. 548 A customer should always be supervised while in the physical presence 549 of any equipment that is not their own, and should not be allowed to 550 touch, photograph, or examine equipment belonging to another 551 customer. 553 Also of concern is layer 2 security of co-located equipment. 554 Customer equipment should not be allowed to share a physical network 555 segment with hosts belonging to anyone else, whether another customer 556 or the ISP themselves. It's common for crackers to exploit weak 557 security or unencrypted remote logins on co-located customer-owned 558 equipment to take control of that equipment and put it into 559 promiscuous listening mode on the local network segment, thereby 560 potentially compromising the privacy and security of any other 561 devices on that segment. 563 When ISPs co-locate network infrastructure components outside of 564 their own premises, such as at peering points or remote POPs, 565 security considerations are extremely important. These locations 566 often play a pivotal role in the network topology, and may be 567 particular targets for attack or vulnerable to accidents. Equipment 568 should ideally be fully enclosed in locking cabinets or cages to 569 limit physical access. If on-site spares are kept, they should 570 likewise be protected from tampering. Whenever possible, security 571 systems and logging card-swipe locks should be employed. 572 Installations should be inspected periodically for the addition of 573 unauthorised equipment which might be used to 'tap' a connection. As 574 with any other facility, hosts should not be attached to transit 575 segments, and hosts should never have unused physical interfaces 576 attached to network segments. 578 5.6 Routing Infrastructure 580 An ISP's ability to route traffic to the correct destination depends 581 on routing policy as configured in the routing registries [RFC1786]. 582 ISPs should ensure that the registry information that they maintain 583 can only be updated using strong authentication, and that the 584 authority to make updates is appropriately restricted. 586 Due care should also be taken in determining in whose routing 587 announcements you place greater trust when a choice of routes are 588 available to a destination. In the past bogus announcements have 589 resulted in traffic being 'black holed', or worse, hijacked. BGP 590 authentication should be used with routing peers. 592 The internal routing protocol that an ISP uses should be chosen with 593 security in mind. It should not be configured with the assumption 594 that route recalculations are rare and expensive as this would leave 595 the way open for a Denial of Service attack. Routing updates should 596 use the highest level of authentication supported by the internal 597 routing protocol. 599 If more specific routes to parts of the ISP's allocated address space 600 are heard from external peers then the ISP needs to be judicious in 601 deciding whether to accept the announcement. Only ISPs who have 602 allowed their CIDR address allocations to become fragmented (by 603 allowing customers to take addressess with them when they change 604 providers) have to face this decision. 606 5.7 Ingress Filtering on Source Address 608 The direction of such filtering is from the edge site (customer) to 609 the Internet. 611 Attackers frequently cover their tracks by using forged source 612 addresses. To divert attention from their own site the source 613 address they choose will generally be from an innocent remote site or 614 indeed from those addresses that are allocated for private Internets 615 [RFC1918]. In addition, forged source addresses are frequently used 616 in spoof-based attacks in order to exploit a trust relationship 617 between hosts. 619 To reduce the incidence of attacks that rely on forged source 620 addresses ISPs should do the following. At the boundary router with 621 each of their customers they should proactively filter all traffic 622 coming from the customer that has a source address of something other 623 than the addresses that have been assigned to that customer. For a 624 more detailed discussion of this topic see [RFC2267]. 626 There are (rare) circumstances where ingress filtering is not 627 currently possible, for example on large aggregation routers that 628 cannot take the additional load of applying packet filters. In 629 addition, such filtering can cause difficulty for mobile users. 630 Hence, while the use of this technique to prevent spoofing is 631 strongly encouraged, it may not always be feasible. 633 In these rare cases where ingress filtering at the interface between 634 the customer and the ISP is not possible, the customer should be 635 encouraged to implement ingress filtering within their networks. In 636 general filtering should be done as close to the actual hosts as 637 possible. 639 5.8 Egress Filtering on Source Address 641 The direction of such filtering is from the Internet to the edge site 642 (customer). 644 There are many applications in widespread use on the Internet today 645 that grant trust to other hosts based only on ip address (e.g., the 646 Berkeley 'r' commands). These are susceptible to IP spoofing, as 647 described in [CA-95.01.IP.spoofing]. In addition, there are 648 vulnerabilities that depend on the misuse of supposedly local 649 addresses, such as 'land' as described in [CA-97.28.Teardrop_Land]. 651 To reduce the exposure of their customers to attacks that rely on 652 forged source addresses ISPs should do the following. At the 653 boundary router with each of their customers they should proactively 654 filter all traffic going to the customer that has a source address of 655 any of the addresses that have been assigned to that customer. 657 The circumstances described in 5.7 in which ingress filtering isn't 658 feasible apply similarly to egress filtering. 660 5.9 Route Filtering 662 Excessive routing updates can be leveraged by an attacker as a base 663 load on which to build a Denial of Service attack. At the very least 664 they will result in performance degradation. 666 ISPs should filter the routing announcements they hear, for example 667 to ignore routes to addresses allocated for private Internets, to 668 avoid bogus routes and to implement route dampening and aggregation 669 policy. 671 ISPs should implement techniques that reduce the risk of putting 672 excessive load on routing in other parts of the network. These 673 include 'nailed up' routes, aggressive aggregation and route 674 dampening, all of which lower the impact on others when your internal 675 routing changes in a way that isn't relevant to them. 677 5.10 Directed Broadcast 679 The IP protocol allows for directed broadcast, the sending of a 680 packet across the network to be broadcast on to a specific subnet. 681 Very few practical uses for this feature exist, but several different 682 security attacks (primarily Denial of Service attacks making use of 683 the packet multiplication effect of the broadcast) use it. 684 Therefore, routers connected to a broadcast medium SHOULD NOT be 685 configured to allow directed broadcasts onto that medium. 687 If it is a packet to which the router would respond if received as a 688 unicast, it MAY send a (single) response. If it is not responding 689 (either because it's not appropriate, or because it's been configured 690 not to) it MAY send an ICMP error. It is also appropriate to 691 silently discard such packets. In any case such packets should be 692 counted to detect possible attempts to abuse this feature. 694 6 Systems Infrastructure 696 The way an ISP manages their systems is crucial to the security and 697 reliability of their network. A breach of their systems may 698 minimally lead to degraded performance or functionality, but could 699 lead to loss of data or the risk of traffic being eavesdropped (thus 700 leading to 'man-in-the-middle' attacks). 702 In general a 'horses for courses' approach to the provision of 703 systems services should be adopted (i.e., separate systems should be 704 used to deliver each distinct service). Apart from the benefits that 705 accrue in terms of easing systems administration it's widely 706 acknowledged that it's much easier to build secure systems if 707 different services (such as mail, news and web-hosting) are kept on 708 separate systems. 710 The services discussed in later sections will all benefit from strong 711 security at a lower layer when IPSec is deployed. 713 6.1 Policy 715 An ISP's policy with regard to privacy, authentication, 716 accountability, application of security patches, availability and 717 violations reporting should all be of interest to their customers, 718 and should be published in a public place such as the ISP's web site. 720 A more detailed discussion of Security Policy can be found in the 721 Site Security Handbook [RFC2196]. 723 6.2 System Management 725 All systems that perform critical ISP functions such as mail, news 726 and web-hosting, should be restricted such that access to them is 727 only available to the administrators of those services. That access 728 should be granted only following strong authentication, and should 729 take place over an encrypted link. Only the ports on which those 730 services listen should be reachable from outside of the ISP's systems 731 networks. 733 If the ISP provides login accounts to customers then the systems that 734 support this service should be isolated from the rest of the ISP's 735 systems networks. 737 If applications such as rdist are used for software distribution and 738 synchronisation then they should be used over a secure channel and 739 with strong authentication, for example over Secure Shell (ssh) 740 [SSH1997]. 742 A system should not be attached to transit segments. 744 If reusable passwords are permitted then users should be educated 745 about how to choose and care for a password, and proactive password 746 checks, password aging and password guessers should be employed. 748 6.3 Backup 750 The importance of backups need not be stressed here. However backups 751 can become the weakest link in a system's security if appropriate 752 care isn't taken of backup media. 754 If backups are done across the network then a secure channel should 755 be used. If volumes are dumped to staging disks during the backup 756 process then access to the images on those staging disks should be as 757 restricted as possible. 759 Backups take on additional significance as audit data following a 760 security incident. 762 Ageing backup media should be destroyed rather than discarded. 764 The customers of a system or service should be informed of what is 765 and is not backed up. Further, if customers have been informed that 766 certain data is not backed up then it should not be backed up. 768 6.4 Software Distribution 770 ISPs frequently engage in application software distribution. The 771 integrity of the software should be assured by distributing with it a 772 checksum that has been produced with a strong digest function such as 773 SHA-1 [SHA]. 775 7 Domain Name Service (DNS) 777 The DNS is critical to the daily activities of millions of Internet 778 users. Regrettably applications have frequently placed blind trust 779 in the information contained in the DNS, and in the availability of 780 the DNS. However prior to DNSSEC [RFC2065] the DNS protocol lacked 781 security, while widely used implementations of the DNS protocol 782 contain further severe vulnerabilities [VIX1995]. 784 While this section indicates some methods in which the DNS can be 785 made more trustworthy and reliable it cannot be stressed too strongly 786 that name based authentication is inherently insecure. 788 7.1 DNS Server Administration 790 In addition to issues raised in section 6 ISPs will need to address 791 the following issues in administering their DNS servers: 793 - Service Monitoring. 794 The service availability (ability to answer queries) should be 795 monitored. 797 - Clock synchronisation. 798 Servers should synchronise their clocks using the NTP protocol 799 [RFC1305] with authentication. At least two NTP servers should 800 be used. 802 7.2 Authoritative Domain Name Service 804 An Authoritative Server is one that knows the content of a DNS zone 805 from local knowledge, and thus can answer queries about that zone 806 without needing to query other servers. Customers should consider 807 [RFC2182] when choosing secondary DNS servers. 809 ISPs commonly operate as secondary (or slave) servers for their 810 customers, and these servers may provide service for thousands of 811 zones. Regardless of the number of zones, administrators of these 812 servers should familiarise themselves with the Operational Criteria 813 for Root Name Servers [RFC2010] as a basis for deciding how to 814 provide highly available service. In particular they should follow 815 these guidelines: 817 - Recursion should be disabled for queries. 819 - Zone transfer should be restricted. 820 Apart from the significant load presented by zone transfer 821 with resultant exposure to Denial of Service attacks, ISPs 822 should recognise that some of their customers will consider the 823 contents of their zone files to be private. 825 - Performance Monitoring. 826 Key variables such as queries per second and average latency 827 should be monitored. 829 7.3 Resolution Service 831 ISPs commonly operate DNS resolution service for their customers. In 832 this scenario customers configure their DNS resolver (client) to 833 resolve queries from the ISP's DNS resolution servers. For 834 resolution servers ISPs should follow these guidelines: 836 - Recursion must be enabled for queries. 837 An implication is that ISPs should not use the same servers for 838 resolution service and authoritative DNS service. 840 - Zone transfer should be disallowed. 841 Even though there may be no zones to transfer, allowing zone 842 transfers would expose the servers to Denial of Service attacks. 844 - Performance Monitoring. 845 Key variables such as queries per second and average latency 846 should be monitored. In addition, the hosts generating the 847 highest number of requests should be periodically reported. 849 - Name server software. 850 A name server package should be run that is not vulnerable to 851 server cache poisoning where malicious or misleading data 852 received from a remote name server is cached and is then made 853 available to resolvers that request the cached data. 855 8 Email and Mail Services 857 Email has been the target of some of the most widely reported 858 security attacks, as well as thousands of juvenile hoaxes and pranks. 860 ISPs have a major role in protecting the community from abuse and in 861 educating their customers in appropriate technologies and in 862 appropriate uses of the technology. 864 8.1 Mail Server Administration 866 In configuring mail servers ISPs should follow these guidelines: 868 - Mail software. 869 If possible software that uses a separate receiving/sending agent 870 and a processing agent should be used. A goal is that the 871 receiving/sending agent, which interfaces with remote mail 872 servers, can be run with reduced privilege. 874 - Restrict remote message queue starting. 875 On-demand queue runs (to facilitate customers who receive mail at 876 their own domain and don't have permanent connections) should be 877 restricted, preferably using a strong authentication mechanism. 878 Remote message queue starting is implemented using a variety of 879 mechanisms, one of which is the ETRN SMTP service extension as 880 described in [RFC1985]. 882 - Disable VRFY and EXPN. 883 No more should be revealed about local users or delivery 884 mechanisms than is necessary. 886 - Clock synchronisation. 887 Servers should synchronise their clocks using the NTP protocol 888 [RFC1305] with authentication. At least two NTP servers should 889 be used. 891 - Exception Reporting. 892 Exceptional conditions such as repeated authentication failures, 893 mail loops and abnormal queue length should be trapped and 894 reported. 896 - Restrict Access to mail logs. 897 Mail logs should only be readable by system administrators. 899 8.2 Secure Mail 901 As indicated in 2.6, It's critical that ISPs, and in particular their 902 Security Incident Response personnel, have access to tools that allow 903 them to exchange email securely. 905 8.3 Open Mail Relay 907 An SMTP mail server is said to be running as an 'open' mail relay if 908 it is willing to accept and relay to non-local destinations mail 909 messages that do not originate locally (i.e., neither the originator 910 nor the recipient address is local). Such open relays are frequently 911 used by 'spammers' to inject their Unsolicited Bulk E-mail (UBE) 912 while hiding their identity. There are only very limited 913 circumstances in which an administrator can make a justifiable case 914 for leaving a mail relay on the Internet completely open. 916 The processes for restricting relaying are well documented. It's 917 regrettable that some major software vendors ship their Message 918 Transfer Agents (MTAs) with relaying open by default. 920 While this is an issue for the whole community, ISPs should be 921 particularly vigilant in disabling open relaying on mail servers that 922 they manage because their high-bandwidth connectivity makes them the 923 preferred injection point for UBE. 925 ISPs should also strongly encourage their customers to disable open 926 relaying on their mail servers. Sanctions for running an open mail 927 relay should be covered in an ISP's AUP. 929 8.4 Message Submission 931 To facilitate the enforcement of security policy message submission 932 should be done through the MAIL SUBMIT port (587) as proposed in the 933 work in progress called "Message Submission and Relay", rather than 934 through the SMTP port (25). In addition, message submissions should 935 be authenticated using the AUTH SMTP service extension as described 936 in the work in progess called "SMTP Service Extension for 937 Authentication". In this way the SMTP port (25) can be restricted to 938 local delivery only. 940 These two measures not only protect the ISP from serving as a UBE 941 injection point, but also help in tracking accountability for message 942 submission in the case where a customer sends UBE. Furthermore, 943 using the Submit port with SMTP AUTH has additional advantages over 944 IP address-based submission restrictions in that it gives the ISP's 945 customers the flexibility of being able to submit mail even when not 946 connected through the ISP's network (for example, while at work), is 947 more resistant to spoofing, and can be upgraded to newer 948 authentication mechanisms as they become available. 950 The (undocumented) XTND XMIT POP3 extension which allows clients to 951 send mail through the POP3 session rather than using SMTP may also be 952 considered. It also provides a way to support mobile users at sites 953 where open relaying is disabled, and has the benefit of an 954 authenticated connection and a better audit trail. 956 8.5 POP and IMAP Services 958 ISPs who provide POP or IMAP access to mailboxes to their customers 959 should, at a minimum, support the CRAM-MD5 [RFC2195] or APOP 960 [RFC1939] authentication mechanisms. Support for stronger mechanisms 961 should be considered, as should disabling plaintext (user/password) 962 authentication. 964 9 News Service (NNTP) 966 As in the case of SMTP, the NNTP protocol [RFC977] used by News 967 suffers from a lack of authentication, so it's trivial to forge news 968 postings. Forgeries can bypass the moderation process, cancel 969 legitimate articles and create havoc for sites that maintain an 970 active file. 972 The lack of encryption in the protocol and the manner in which many 973 news systems are maintained lead to privacy issues in that it's easy 974 for others to detect what newsgroups and articles you are reading. 976 9.1 News Server Administration 978 In configuring news servers ISPs should follow these guidelines: 980 - News software. 981 A news software package should be run that is not vulnerable to 982 maliciously formed news control messages or buffer overflows. 984 - Disable other services. 985 Given news' propensity to consume all available disk space and 986 CPU cycles it's particularly important that news systems do not 987 perform other services. 989 - Do not interpret batches. 990 If incoming batches of articles are supported they should not 991 be fed to a command interpreter. 993 - Restrict Access to news logs. 994 News logs should only be readable by system administrators. 996 - Authenticate approved headers. 997 If possible support for cryptographic authentication of approved 998 messages should be supported, particularly in the case of group 999 control messages. 1001 9.2 Article Submission 1003 As many of the issues relating to open mail relays (8.3) apply to 1004 news, ISPs should restrict article submission only to approved 1005 customers. Further, the networks from which posting is allowed and 1006 the newsgroups to which posting is allowed should be as restricted as 1007 possible. 1009 9.3 Control Messages 1011 Control messages attempt to cause the news server to take action 1012 beyond filing and passing on the article. Certain control messages, 1013 because of the ease with which they can be forged, should be handled 1014 with care. While it is up to the ISP to decide whether to take 1015 action they must at least propagate control messages even if they do 1016 not understand them. 1018 - 'whogets', 'sendsys', 'version' should be ignored by ISPs. 1020 - While 'cancel' messages must be acted on and propagated their 1021 sheer volume can sometimes swamp service, and the fact that much 1022 of that volume is computer-generated is worrying. 1024 - Systems that require the maintenance of an active file should 1025 exercise extreme caution in choosing which if any group control 1026 messages (checkgroups, newgroup, rmgroup) will be acted upon. 1028 9.4 Newsfeed Filters 1030 The most obvious form of security problem with news is 'leakage' of 1031 articles which are intended to have only restricted circulation. The 1032 flooding algorithm is extremely good at finding any path by which 1033 articles can leave a subnet with supposedly restrictive boundaries. 1034 Substantial administrative effort is required to ensure that local 1035 newsgroups remain local [SPE1994]. 1037 ISPs who provide customers with the ability to remotely manipulate 1038 their inbound filters should use strong authentication for this 1039 service. 1041 ISPs should not propagate articles that are excessively crossposted. 1042 10 or more cross-postings is commonly considered to be excessive. 1044 ISPs should impose an upper limit on the article size that they will 1045 propagate. 1047 10 Web-hosting Services 1049 Sites frequently choose to out-source the operation and 1050 administration of their site to an ISP, and security is often a 1051 prominent motivator for doing so. The hosting of such sites and 1052 provision of related services is the subject of this section. 1053 Further information on the topic can be found in [GAR1997] and 1054 [HUG1995]. 1056 10.1 Webhosting Server Administration 1058 In addition to issues raised in section 6 ISPs will need to address 1059 the following issues in administering their web-hosting servers: 1061 - Service Monitoring. 1062 The service availability (ability to answer HTTP requests) should 1063 be monitored. 1065 - Clock synchronisation. 1066 Servers should synchronise their clocks using the NTP protocol 1067 [RFC1305] with authentication. At least two NTP servers should 1068 be used. 1070 - DNS. 1071 DNS lookups should not be performed on web clients when they 1072 connect because they expose the web servers to DNS-based Denial 1073 of Service attacks, and they adversely affect performance. 1075 - Process User and Group. 1076 The web daemon should be run as a user and group that is set up 1077 specifically for that purpose, and that user/group should have 1078 minimal privilege. This user should be different from the 1079 maintainers of the web content. 1081 - DocumentRoot. 1082 Everything below this directory should be subject to the 1083 strictest scrutiny. If possible chroot should be used to change 1084 the HTTP daemon's root directory. 1086 - UserDir. 1087 Users other than administrators should not be permitted on the 1088 server. If users have accounts then the 'UserDir' directive, if 1089 permitted, should not access their private accounts. In 1090 particular, scripts should not be permitted to be run from their 1091 accounts. 1093 - Partitioning of Virtual Sites. 1094 A single server that hosts multiple sites (virtual domains) 1095 SHOULD be set up such that all data, programs and logs for the 1096 different sites are partitioned from each other such that no 1097 access to the configuration or data of each other's sites is 1098 possible. In addition, it should not be possible to access the 1099 data or programs of one customer's site using a URL that has 1100 the name of another customer's site in it's host part. 1102 - Access Control. 1103 Restricted access to certain parts of a site should be 1104 facilitated using a strong authentication mechanism such as a 1105 certificate or a one-time password device. An alternative is 1106 to use well-chosen passwords in conjunction with SSL which at 1107 least avoids passwords being passed across the network in 1108 plaintext. 1110 - Security Patches and Service Packs. 1111 The stakes in running a web server are particularly high, so 1112 administrators should be particularly vigilant in applying 1113 security patches and Service Packs as they are released. 1115 10.2 Server Side Programs 1117 Server side programs such as those that use the Common Gateway 1118 Interface (CGI) or other server side interfaces are important to the 1119 flexibility of the web as a communications medium. However that 1120 flexibility introduces security risks and a weak program might 1121 threaten all of the virtual hosts on the server that runs it. An 1122 ISP's policy with regard to what programs it will allow is a good 1123 indicator of security policy in general. 1125 ISPs should consider the guidelines on server side programs and CGIs: 1127 - Security Policy. 1128 ISPs should give their customers clear guidelines about how to 1129 write secure programs for their hosting environment, and give 1130 specific indications about what programming practices will result 1131 in a program being rejected. 1133 - Program Installation. 1134 Customers should not be allowed to install their own programs. 1135 All programs and scripts should be submitted to the ISP first to 1136 be checked for conformance with security policy. The programs 1137 SHOULD be installed such that only the server administrators have 1138 permission to modify them. 1140 - Process User and Group. 1141 Programs should be run as a user and group that is set up 1142 specifically for that purpose, and that user/group should have 1143 minimal privilege (many sites use 'nobody'). 1145 - Display by Browsers. 1146 Programs SHOULD never be allowed to be viewed by browsers. One 1147 implication of that is that they SHOULD NOT be put under the 1148 DocumentRoot. 1150 - Partitioning of Virtual Sites. 1151 Programs SHOULD NOT be accessible through the site of another 1152 customer on the same server, or to the webmaster of that other 1153 customer. 1155 - User Input. 1156 Expressions SHOULD NOT be evaluated based on user input except 1157 when used with the equivalent of Perl's tainting features. 1159 - Processing Limit. 1160 All programs SHOULD have a limit set on real and CPU time, and on 1161 the amount of disk space that they can consume. 1163 - Paths. 1164 All paths SHOULD be full or starting at DocumentRoot, and the 1165 PATH variable should be set by the server administrator. 1167 10.3 Data and Databases 1169 Data that is written by server-side programs should be considered 1170 confidential. To prevent them being read by browsers their 1171 permission should be such that they're not readable by the web daemon 1172 process. 1174 If access to a back-end database is provided then programs that 1175 facilitate such access should have the least privilege that is 1176 absolutely necessary. 1178 Data that relates to state management (cookies) that is stored on the 1179 server should be considered confidential and should not be accessible 1180 from browsers. 1182 10.4 Logs and Statistics Reporting 1184 The logs generated by the web daemon process can be useful from the 1185 security viewpoint in providing an audit trail of site activity, 1186 however their more common use is for billing and for market and site 1187 analysis. 1189 These logs should be considered highly confidential. 1191 - The only manipulation of them done by the ISP should be that 1192 which is necessary to generate billing information and 1193 periodically rotate them. 1195 - They should be stored outside of DocumentRoot to prevent access 1196 by a browser to them. 1198 - Access to them, whether in raw or summarised format, should be 1199 provided to the customer over a secure channel. 1201 10.5 Push and Streaming Services 1203 ISPs frequently provide their customers with the ability to deliver 1204 content using protocols other than HTTP. Where such add-on services 1205 are provided, both the customer and the ISP should be aware of the 1206 security implications of providing such services. 1208 10.6 Commerce 1210 Many ISPs set up the means whereby their customers can sell goods and 1211 services through their web-hosted sites. Though a server that can 1212 exchange information with a browser over SSL is sometimes described 1213 as a 'secure server' this term can be misleading, and ISPs that host 1214 commerce applications should consider the following: 1216 - Encrypted Transactions. 1217 Transactions should never be stored on the server in unencrypted 1218 form. Public key cryptography may be used such that only the 1219 customer can decrypt the transactions. However even when 1220 transactions are passed directly to a financial institution and 1221 to the customer some part of the transaction will have to be 1222 stored by the ISP for audit trail purposes. 1224 - Transaction Transfer. 1225 If transactions are not processed immediately but instead are 1226 transferred to the customer in batches then that transfer should 1227 occur over a secure channel such as SSL and only after strong 1228 authentication has taken place. Transaction files should be 1229 carefully rotated so that every transaction occurs exactly once. 1231 - Backups. 1232 If transactions are written to backup media then the physical 1233 security of the backup media should be assured. 1235 10.7 Content Loading and Distributed Authoring 1237 The loading of content onto the ISP's server should happen over a 1238 secure channel. 1240 If server support for Distributed Authoring tools is enabled, then 1241 this should be administered with great care to ensure that strong 1242 authentication takes place and that access is given only to the 1243 customer's virtual site, and only to that customer's content 1244 maintainer. 1246 10.8 Search Engines and other tools 1248 ISPs frequently install tools such as search engines, link checkers 1249 and so on for use by their customers. Many such tools create a very 1250 great processing overhead when run and so running them on-demand 1251 should not be allowed to avoid Denial of Service attacks. 1253 Search engines should be configured so that their searches are 1254 restricted to those parts of a site that are available to all. 1256 The output of link checkers should be considered confidential, and 1257 should only be available to the content maintainer of the customer's 1258 site. 1260 11 References 1262 [CA-91:18.Active.Internet.tftp.Attacks] "Active Internet tftp 1263 Attacks", ftp://info.cert.org/pub/cert_advisories/ 1265 [CA-95.01.IP.spoofing] "IP Spoofing Attacks and Hijacked Terminal 1266 Connections", ftp://info.cert.org/pub/cert_advisories/ 1268 [CA-96.21.tcp_syn_flooding] "TCP SYN Flooding and IP Spoofing 1269 Attacks", ftp://info.cert.org/pub/cert_advisories/ 1271 [CA-97.28.Teardrop_Land] "IP Denial-of-Service Attacks", 1272 ftp://info.cert.org/pub/cert_advisories/ 1274 [DPR1998] The UK "Data Protection Act 1998 (c. 29)", 1275 http://www.hmso.gov.uk/acts/acts1998/19980029.htm 1277 [GAR1997] Garfinkel, S., "Web Security and Commerce", 1278 O'Reilly and Associates, Sebastopol, CA, 1997. 1280 [HUG1995] Hughes Jr., L., "Actually Useful Internet Security 1281 Techniques", New Riders Publishing, Indianapolis, IN, 1995. 1283 [RFC977] Kantor, B and P. Lapsley, "Network News Transfer Protocol", 1284 RFC 977, February 1986. 1286 [RFC1350] Sollins, K. R., "The TFTP Protocol (revision 2)", STD 33, 1287 RFC 1350, July 1992. 1289 [RFC1034] Mockapetris, P. V., "Domain names - concepts and 1290 facilities", STD 13, RFC 1034, November 1987. 1292 [RFC1035] Mockapetris, P. V., "Domain names - implementation and 1293 specification", STD 13, RFC 1035, November 1987. 1295 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 1296 Specification, Implementation", RFC 1305, March 1992. 1298 [RFC1786] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M., 1299 Karrenberg, D., Terpstra, M., and J. Yu, "Representation of IP 1300 Routing Policies in a Routing Registry (ripe-81++)", RFC 1786, 1301 March 1995. 1303 [RFC1834] Gargano, J., and K. Weiss, "Whois and Network Information 1304 Lookup Service", RFC 1834, August 1995. 1306 [RFC1835] Deutsch, P., Schoultz, R., Faltstrom, P., and C. Weider, 1307 "Architecture of the WHOIS++ service", RFC 1835, August 1995. 1309 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 1310 J., and E. Lear, "Address Allocation for Private Internets", BCP 5, 1311 RFC 1918, February 1996. 1313 [RFC1939] Myers, J., and M. Rose, "Post Office Protocol - Version 1314 3", RFC 1939, May 1996. 1316 [RFC1985] De Winter, J. "SMTP Service Extension for Remote Message 1317 Queue Starting", RFC 1985, August 1996. 1319 [RFC2010] Manning, B., and P. Vixie, "Operational Criteria for Root 1320 Name Servers", RFC 2010, October 1996. 1322 [RFC2065] Eastlake 3rd, D., and C. Kaufman, "Domain Name System 1323 Security Extensions", RFC 2065, January 1997. 1325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1326 Requirement Levels", RFC 2119, March 1997. 1328 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and 1329 Functions", RFC 2142, May 1997. 1331 [RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP 1332 AUTHorize Extension for Simple Challenge/Response", RFC 2195, 1333 September 1997. 1335 [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September 1336 1997. 1338 [RFC2267] Ferguson, P., and D. Senie, "Network Ingress Filtering: 1339 Defeating Denial of Service Attacks which employ IP Source 1340 Address Spoofing", RFC 2267, January 1998. 1342 [RFC2350] Brownlee, N., and E. Guttman, "Expectations for Computer 1343 Security Incident Response", RFC 2350, June 1998. 1345 [SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. 1347 [SPE1994] Spencer, H., "News Article Format and Transmission", 1348 ftp://ftp.zoo.toronto.edu/pub/news.txt.Z 1350 [SSH1997] SSH (secure Shell) Remote Login Program, 1351 http://www.cs.hut.fi/ssh/ 1353 [VIX1995] Vixie, P., "DNS and BIND Security Issues", 1354 ftp://ftp.vix.com/pri/vixie/bindsec.psf, 1995. 1356 12 Acknowledgements 1358 I gratefully acknowledge the constructive comments received from 1359 Nevil Brownlee, Randy Bush, Bill Cheswick, Barbara Y. Fraser, Randall 1360 Gellens, Erik Guttman, Larry J. Hughes Jr., Klaus-Peter Kossakowski, 1361 Michael A. Patton, Don Stikvoort and Bill Woodcock. 1363 13 Security Considerations 1365 This entire document discusses security issues. 1367 14 Author's Address 1369 Tom Killalea 1370 1516 2nd Ave 1371 Seattle, WA 98101 1372 USA 1374 Phone: +1 206 694-2196 1375 E-Mail: tomk@neart.ie 1377 15 Full Copyright Statement 1379 Copyright (C) The Internet Society (1998). All Rights Reserved. 1381 This document and translations of it may be copied and furnished to 1382 others, and derivative works that comment on or otherwise explain it 1383 or assist in its implmentation may be prepared, copied, published and 1384 distributed, in whole or in part, without restriction of any kind, 1385 provided that the above copyright notice and this paragraph are 1386 included on all such copies and derivative works. However, this 1387 document itself may not be modified in any way, such as by removing 1388 the copyright notice or references to the Internet Society or other 1389 Internet organisations, except as needed for the purpose of 1390 developing Internet standards in which case the procedures for 1391 copyrights defined in the Internet Standards process must be 1392 followed, or as required to translate it into languages other than 1393 English. 1395 The limited permissions granted above are perpetual and will not be 1396 revoked by the Internet Society or its successors or assigns. 1398 This document and the information contained herein is provided on an 1399 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1400 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1401 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1402 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1403 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1405 This document expires June 20, 1999.