HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 02:32:09 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 21 Oct 1997 13:41:00 GMT ETag: "2eda29-a490-344cb0ec" Accept-Ranges: bytes Content-Length: 42128 Connection: close Content-Type: text/plain Internet Engineering Task Force Tom Killalea INTERNET-DRAFT NorthWestNet Valid for six months October 1997 Security Expectations for Internet Service Providers Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. This Internet Draft is a product of the GRIP Working Group of the IETF. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a 'working draft' or 'work in progress.' To learn the current status of any Internet Draft, please check the '1id-abstracts.txt' listing contained in the Internet Drafts shadow directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract The purpose of this document is to express the general Internet community's expectations of Internet Service Providers (ISPs) with respect to security. It is not the intent of this document to define a set of requirements that would be appropriate for all ISPs, but rather to raise awareness among ISPs of the community's expectations, and to provide the community with a framework for discussion of security expectations with current and prospective service providers. Killalea Internet Draft [Page 1] Security Expectations for ISPs 19 October 1997 Table of Contents 1 Introduction 2 Incident Response 2.1 ISPs and Security Incident Response Teams (SIRTs) 2.2 Assistance with Inbound Security Incidents 2.3 Assistance with Outbound or Transit Security Incidents 2.4 Notification of Vulnerabilities and Reporting Incidents 2.5 Contact Information 2.6 Communication and Authentication 3 Appropriate Use Policy 3.1 Announcement of Policy 3.2 Sanctions 4 Protection of the Community 4.1 Cooperation 4.2 Route Filtering 4.3 Open Mail Relay 4.4 Anonymous telnet and other unlogged connections 4.5 Broadcast ping (and smurfing) 4.6 Data Protection 5 Network Infrastructure 5.1 Routers 5.2 Switches, Terminal Servers, Modems and other Network Devices 5.3 The Network Operation Centre (NOC) and network management 5.4 Physical Security 5.5 Routing Infrastructure 6 Systems Infrastructure 6.1 Policy 6.2 System Management and Incident Detection 6.3 Systems and Services, horses for courses 6.4 Backup 6.5 Software Distribution 7 Domain Name Service (DNS) 7.1 DNS Server Management 7.2 Authoritative Domain Name Service 7.3 Resolution Service 8 Mail Services 8.1 Mail Server Administration 8.2 Secure Mail 8.3 Message Submission 8.4 POP and IMAP Services 9 Usenet News Service 9.1 News Server Administration 9.2 Article Submission 9.3 Control Messages 9.4 Newsfeed Filters 10 Web-related Services 10.1 Webhosting Server Administration 10.2 Server Side Programs 10.3 Data and Databases 10.4 Logs and Statistics Reporting 10.5 Push and Streaming Services 10.6 Commerce 10.7 Content Loading and Distributed Authoring 10.8 Search Engines and other tools 11 References 12 Security Considerations 13 Author's Address Killalea Internet Draft [Page 2] Security Expectations for ISPs 15 April 97 1 Introduction The purpose of this document is to express the general Internet community's expectations of Internet Service Providers (ISPs) with respect to security. A goal is that customers could have a framework to facilitate the discussion of security with prospective service providers; regrettably, such a discussion rarely takes place today. Additionally, in informing ISPs of what the community hopes and expects of them a further goal is to encourage ISPs to become proactive in making security not only a priority, but something they point to with pride when selling their services. It has been argued that vendors begin to care about security only when prompted by customers. It is hoped that, with the encouragement of this document, both parties will more readily express how much they care about security. It is the author's and the GRIP working group's sincere hope that, with the help of this document, discussion between the community and its ISPs will be increased. 2 Incident Response A Security Incident Response Team (SIRT) is a team that performs, coordinates, and supports the response to security incidents that involve sites within a defined constituency. The Internet community's expectations of SIRTs are described in [draft-ietf-grip-framework-irt-06.txt]. 2.1 ISPs and Security Incident Response Teams (SIRTs) Some ISP's have SIRTs. However in many cases the ISP's connectivity customers cannot automatically avail of the services of the SIRT, as the team defines as their constituency only those who specifically subscribe to (and doubtless pay for) Incident Response services. Though it seems too obvious to state, it's important to know to whom you can turn for assistance in incident response BEFORE an incident happens. Customers should find out if their ISP has a SIRT, and if so what the charter, policies and services of that team are. This information is best expressed using the SIRT template [draft-ietf-grip-framework-irt-06.txt Appendix D]. If the ISP doesn't have a SIRT they should describe what role if any they will take in incident response, and should indicate if there is any SIRT whose constituency would include the customer and to whom incidents could be reported. 2.2 Assistance with Inbound Security Incidents When a security incident targeting one of their connectivity customers occurs ISPs should provide assistance to - trace the 'apparent' source of the attack (inasmuch as the source address of the attack can be believed) - obtain contact information for the source of the attack using whois [RFC1834 and RFC1835] the DNS [RFC1034 and RFC1035] or relevant common mailbox names [RFC2142]. If the event continues then, at the customer's request, ISPs may also assist by filtering or discarding certain types of traffic. 2.3 Assistance with Outbound or Transit Security Incidents In the case where one of their connectivity customers appears to be the source of a security incident an ISP will frequently be contacted, and in this case they should provide contact information so that the administrators at the source site can be reached by the target site. An ISP may also be contacted to assist with incidents that traverse their network but use bogus source addresses, such as the widely reported SYN Flood attacks of 1996. Assistance in this case would consist of using network traces on a hop by hop basis to identify the point at which the bogusly addressed traffic entered the ISPs network. 2.4 Notification of Vulnerabilities and Reporting of Incidents ISPs should be proactive in notifying customers of security vulnerabilities in the services they provide. In addition, as new vulnerabilities in systems and software are discovered they should indicate whether their services are threatened by these risks. When security incidents occur that affect components of an ISP's infrastructure the ISP should promptly report to their customers - who is coordinating response to the incident - the vulnerability - how service was affected - what is being done to respond to the incident - whether customer data may have been compromised - what is being done to eliminate the vulnerability 2.5 Contact Information [RFC2142] states that sites (including ISPs) must maintain a mailbox called SECURITY for network security issues, ABUSE for issues relating to inappropriate public behaviour and NOC for issues relating to network infrastructure. It also lists additional mailboxes that are defined for receiving queries and reports relating to specific services. In addition, ISPs have a duty to make sure that their contact information in Whois and in the routing registry [RFC1786] is complete and accurate. 2.6 Communication and Authentication ISPs should have clear policies and procedures on the sharing of information about a security incident with their customers, with other ISPs or SIRTs or with the press. ISPs should also be able to conduct such communication over a secure channel. 3 Appropriate Use Policy An Appropriate Use Policy (AUP) should spell out what customers shall and shall not do on the various components of a system or network, including the type of traffic allowed on the networks. The AUP should be as explicit as possible to avoid ambiguity or misunderstanding. Whenever an ISP contracts with a customer to provide connectivity to the Internet that contract should be governed by an AUP. 3.1 Announcement of Policy In addition to communicating their AUP to their customers ISPs should publish their policy in a public place such as their web site so that the community can be aware of what the ISP considers appropriate and can know what action to expect in the event of inappropriate behaviour. 3.2 Sanctions An AUP should be clear in stating what sanctions will be enforced in the event of inappropriate behaviour, and ISPs should be forthcoming in announcing to the community when such sanctions are imposed. 4 Protection of the Community ISPs play a crucial role in helping to improve the security of the Internet. This section describes a number of issues which, should they be addressed by ISPs in a coordinated and timely way, would have a very positive effect on the security of the network, and would make it much more difficult for the perpetrators to cover their tracks. While later sections cover issues related to specific services in greater detail this section addresses issues that, if addressed by all the ISPs in a concerted way, could have a very positive effect. 4.1 Cooperation This section is about protecting the community. This requires that we as a community work together to that end. It's worth observing that many of the most significant successes in securing the Internet could not have been achieved by anyone acting alone. 4.2 Route Filtering Attackers frequently cover their tracks by using forged source addresses. To divert attention from their own site the source address they choose will generally be from an innocent remote site or indeed from those addresses that are allocated for private Internets [RFC1918]. To prevent attacks that rely on forged source addresses ISPs should proactively filter at the boundary router with each of their customers all traffic that has a source address of something other than the addresses that have been assigned to that customer. (It's regrettable that major router vendors don't make the application of such filters the default behaviour). In addition, ISPs should filter and 'black hole' all traffic with source addresses from the address space allocated for private Internets. 4.3 Open Mail Relays An SMTP mail server is said to be running as an 'open' mail relay if it is willing to accept and relay mail messages that do not orginate locally to non-local destinations. Such relays are frequently used by spammers to inject their Unsolicited Commercial E-mail (UCE) while hiding their identity. There is no justification for any mail relay on the Internet being left completely open, and the processes for restricting relaying are well documented. (It's regrettable that major software vendors ship their Message Transfer Agents (MTAs) with relaying open by default). While this is an issue for the whole community ISPs should be particularly vigilant in disabling open relaying on mail servers that they manage because their high bandwidth connectivity makes them the preferred injection point for UCE. Sanctions for running an open mail relay should be covered in an ISP's AUP. 4.4 Anonymous telnet and other unlogged connections There are lots of network devices from low-end routers to printers that accept telnet connections without prompting for a password. Obviously such devices, many of which don't maintain audit trails, are very popular among attackers who wish to cover their tracks. ISPs should limit access to such devices on their own network, and work with their customers to block access to such devices from outside of the customer's network. 4.5 Broadcast ping (and smurfing) Smurfing (named after a program 'smurf.c' used to carry out the attack) is a type of Denial of Service (DoS) attack in which an ICMP Echo [RFC792] is sent to the broadcast address for a network. Usually the source address is forged to be the address of a host that the attacker is trying to crash. If broadcast pings are enabled on the target network then all the hosts on the broadcast network will respond with an Echo Reply to the (victim) source address. The success of the attack depends on the network to which the broadcast ping is sent having very good connectivity, thus ISP's networks are commonly used. ISPs should configure their routers so that the router responds to the ICMP Echo rather than sending the packet to the broadcast address. (It's regrettable that major router vendors don't make this the default behaviour). 4.6 Data Protection Many jurisdictions have the good fortune to have Data Protection Legislation. Where such legislation exists ISPs should consider the personal data they hold and, if necessary, register themselves as Data Controllers and be prepared to make data available according to the terms of the legislation. Given the global nature of the Internet ISPs that are located where no such legislation exists should at least familiarise themselves with their responsibilities by reading a Data Protection Act (eg. [DPR1984]). 5 Network Infrastructure ISPs are responsible for managing the network infrastructure of the Internet in such a way that it is - resistant to security attacks - not easily hijacked by attackers to be used in subsequent attacks 5.1 Routers Routers are an excellent platform from which to launch a security attack, as well as being attractive targets of themselves. Some of the dangerous things routers allow an attacker to do are: - sniff transit traffic - manipulate routing tables to redirect traffic - create routing flaps which could potentially cause Denial of Service for large parts of the Internet - create packets with spoofed addresses, and with any desired flags set - initiate ICMP packet storms and other Denial of Service attacks - 'black hole' traffic - launder connections to third-party connections, facilitated by the router's lack of logging Such threats are amplified because of the central part in the networking infrastructure that routers occupy, and the large bandwidth frequently available to them. So access to routers should be as restricted as possible, and strong authentication should be used for all connections. 5.2 Switches, Terminal Servers, Modems and other Network Devices ISPs should be similarly vigilant in their configuration of other network devices. Unfortunately many such devices deployed in the field support only minimal authentication, do authorisation on an all-or-nothing basis and do little or no logging. In the past ISPs have been left with no trail to follow after their switches were reconfigured, their terminal servers were used to launch attacks on third parties or their Uninterruptable Power Supplies were shutdown. Where possible access to such devices should be restricted only to legitimate network administrators, 5.3 The Network Operation Centre (NOC) and network management A NOC is a crucial part of an ISPs infrastructure, and should be operated with appropriate regard to security. A NOC frequently has management control over the configuration information of network devices, and should be vigilant in restricting access to that information. Loading of configuration information into network devices is still frequently done using the TFTP protocol [RFC783], which not only lacks authorisation and uses an insecure channel, but calls for great care in configuration at the server end [CA-91:18.Active.Internet.tftp.Attacks]. A NOC will generally perform a network monitoring function by polling (usually with ICMP Echo) a set of network devices periodically. In selecting the set of devices to be polled the crucial role of the devices in 5.2 shouldn't be overlooked. Beyond simple polling a NOC will also use a network management protocol such as SNMP [RFC1446] to communicate with network devices. Usually this will be used to 'get' the value of various variables, such as the number of packets received on a particular interface, however the protocol can be used to 'set' variables, perhaps with serious results. In any case, SNMPv1 used only trivial authentication and it's use should be restricted and phased out where possible. Even with the improved authentication in SNMPv2 where possible it should be used as a read-only tool to 'get' information from remote devices, and access to the information gotten should be treated as confidential. A further use of SNMP is in trap reporting, so that a management station can be notified when certain exceptions occur. This information should also be considered confidential, and the NOC should take care that such trap reporting cannot of itself become a Denial of Service attack. 5.4 Physical Security The physical security of every installation should be given appropriate consideration. This is particularly so for co-located facilities to which people from different organisations and with different security policies have access. 5.5 Routing Infrastructure An ISP's ability to route traffic to the correct destination depends on routing policy as configured in the routing registries [RFC1786]. ISPs should ensure that the registry information that they maintain can only be updated using strong authentication, and that the authority to make updates be appropriately restricted. Due care should also be taken in determining in whose routing announcements you place greater trust when a choice of routes are available to a destination. In the past bogus announcements have resulted in traffic being 'black holed', or worse, hijacked. The internal routing protocol that an ISP uses should be chosen with security in mind. It should not be configured with the assumption that route recalculations are rare and expensive as this would leave the way open for a Denial of Service attack. Routing updates should only be permitted from authenticated sources. If more specific routes are announced to parts of the ISP's allocated address space are heard from external peers then the ISP needs to be judicious in deciding whether to accept the announcement. Unfortunately many ISPs have allowed their CIDR address allocations to become fragmented, and so this scenario is all too common. 6 Systems Infrastructure The way an ISP manages their systems is crucial to the security and reliability of their network. A breach of their systems may minimally lead to degraded performance or functionality, but could lead to loss of data or the risk of traffic being ease-dropped (thus leading to 'man-in-the-middle' attacks). 6.1 Policy An ISP's policy with regard to privacy, authentication, accountability, application of security patches, availability and violations reporting should all be of interest to their customers. A more detailed discussion of Security Policy can be found in the Site Security Handbook [RFC2196]. 6.2 System Management and Incident Detection All systems that perform critical ISP functions such as mail, news, web-hosting, should be restricted such that access to them is only available to the administrators of those services, and that access should be granted only following strong authentication. Only the ports on which those services listen should be reachable from outside of the ISP's systems networks. If the ISP provides login accounts to customers then the systems that support this service should be isolated from the rest of the ISP's systems networks. If applications such as rdist are used for software distribution and synchronisation then they should be used over a secure channel and with strong authentication, for example over Secure Shell (ssh) [SSH1997]. A system should never be placed on a network that will be used for transit by the ISP's customers. If reusable passwords are permitted then users should be educated about how to choose and care for a password, and proactive password checks, password aging and password guessers should be employed. 6.3 Systems and Services, horses for courses Apart from the benefits that accrue in terms of easing systems administration it's widely acknowledged that it's much easier to build secure systems if different services (such as mail, news, web-hosting) are kept on separate systems. 6.4 Backup The importance of backups need not be stressed here. However backups can become the weakest link in a system's security if appropriate care isn't taken of backup media. If backups are done across the network then a secure channel should be used. Backups take on additional significance as audit data following a security incident. 6.5 Software Distribution ISPs frequently engage in application software distribution. The integrity of the software should be assured by distributing with it a checksum that has been produced with a strong digest function such as MD5 [RFC1321]. 7 Domain Name Service (DNS) The DNS is critical to the daily activities of millions of Internet users. Regrettably applications have frequently placed blind trust in the information contained in the DNS, and in the availability of the DNS. However prior to DNSSEC [RFC2065] the DNS protocol lacked security, while widely used implementations of the DNS protocol contain further severe vulnerabilities [VIX1995]. While this section indicates some methods in which the DNS can be made more trustworthy and reliable it cannot be stressed too strongly that name based authentication is inherently insecure. 7.1 DNS Server Administration In addition to issues raised in section 6 ISPs will need to address the following issues in administering their DNS servers: - Service Monitoring. The service availability (ability to answer queries) should be monitored. - Clock synchronization. Servers should synchronize their clocks using the NTP protocol [RFC1305] with authentication. At least two NTP servers should be used. 7.2 Authoritative Domain Name Service An Authoritative Server is one that knows the content of a DNS zone from local knowledge, and thus can answer queries about that zone without needing to query other servers [RFC2182]. ISPs commonly operate as secondary (or slave) servers for their customers, and these servers may provide service for thousands of zones. Regardless of the number of zones, administrators of these servers should be familiar with the Operational Criteria for Root Name Servers [RFC2010], and in particular should follow these guidelines: - Recursion should be disabled for queries. - Zone transfer should be restricted. Apart from the significant load presented by zone transfer with resultant exposure to Denial of Service attacks, ISPs should recognise that some of their customers will consider the contents of their zone files to be private. - Performance Monitoring. Key variables such as queries per second and average latency should be monitored. 7.3 Resolution Service ISPs commonly operate DNS resolution service for their customers. In this scenario customers configure their DNS resolver (client) to resolve queries from the ISP's DNS resolution servers. For resolution servers ISPs should follow these guidelines: - Recursion must be enabled for queries. An implication is that ISPs should not use the same servers for resolution service and authoritative DNS service. - Zone transfer should be disallowed. Even though there may be no zones to transfer, allowing zone transfers would expose the servers to Denial of Service attacks. - Performance Monitoring. Key variables such as queries per second and average latency should be monitored. In addition, the hosts generating the highest number of requests should be periodically reported. - Name server software. A name server package should be run that is not vulnerable to server cache poisoning where malicious or misleading data received from a remote name server is cached and is then made available to resolvers that request the cached data. 8 Email and Mail Services Email has been the target of some of the most widely reported security attacks, as well as thousands of juvenile hoaxes and pranks. ISPs have a major role in protecting the community from abuse and in educating their customers in appropriate technologies and uses of the technology. 8.1 Mail Server Administration In configuring mail servers ISPs should follow these guidelines: - Mail software. If possible software that uses a separate receiving/sending agent and a processing agent should be used to reduce the privilege requirement for the receiving/sending agent which interfaces with remote mail servers. - Restrict on-demand queue runs. On-demand queue runs (to facilitate customers who receive mail at their own domain and don't have permanent connections) should be restricted, preferably using a strong authentication mechanism. - Disable VRFY and EXPN. No more should be revealed about local users or delivery mechanisms than is necessary. - Clock synchronization. Servers should synchronize their clocks using the NTP protocol [RFC1305] with authentication. At least two NTP servers should be used. - Exception Reporting. Exceptional conditions such as repeated authentication failures, mail loops and abnormal queue length should be trapped and reported. - Restrict Access to mail logs. Mail logs should only be readable by system administrators. 8.2 Secure Mail It's critical that ISPs, and in particular their Security Incident Response personnel, have access to tools that allow them to exchange email securely. 8.3 Message Submission Message submission should be done through the MAIL SUBMIT port (587) rather than the SMTP port (25) to facilitate the enforcement of security policy [draft-gellens-submit-05.txt]. 8.4 POP and IMAP Services ISPs who provide POP or IMAP access to mailboxes to their customers should use the Challenge Response Authentication Mechanism (CRAM) as described in [RFC2195]. 9 Usenet News Service As in the case of SMTP, the NNTP protocol [draft-ietf-nntpext-base-02.txt] used by Usenet News suffers from a lack of authentication, and so it's trivial to forge news postings. Using forgeries the moderation process can be bypassed, articles can be cancelled and active file maintenance havoc can be created. The lack of encryption in the protocol and the manner in which many news systems are maintained lead to privacy issues in that it's easy for others to detect what newsgroups and articles you are reading. 9.1 News Server Administration In configuring news servers ISPs should follow these guidelines: - News software. A news software package should be run that is not vulnerable to maliciously formed news control messages or buffer overflows. - Disable other services. Given news' propensity to consume all available disk space and CPU cycles it's particularly important that news systems do not perform other services. - Do not interpret batches. If incoming batches of articles are supported they should not be fed to a command interpreter. - Restrict Access to news logs. News logs should only be readable by system administrators. - Authenticate approved headers. If possible support for cryptographic authentication of approved messages should be supported, particularly in the case of group control messages. 9.2 Article Submission As many of the issues relating to open mail relays (4.3) apply to news ISPs should restrict article submission only to approved customers. Further, the networks from which posting is allowed and the newsgroups to which posting is allowed should be as restricted as possible. 9.3 Control Messages Control messages attempt to cause the news server to take action beyond filing and passing on the article. Certain control messages, because of the ease with which they can be forged, should be handled with care. While it is up to the ISP to decide whether to take action they must at least propagate control messages even if they do not understand them. - 'whogets', 'sendsys', 'version' should be ignored by ISPs. - While 'cancel' messages must be acted on and propagated their sheer volume can sometimes swamp service, and the fact that much of that volume is computer-generated is worrying. - Systems that require the maintenance of an active file should exercise extreme caution in choosing which if any group control messages (checkgroups, newgroup, rmgroup) should result in action being taken. 9.4 Newsfeed Filters The most obvious form of security problem with news is "leakage" of articles which are intended to have only restricted circulation. The flooding algorithm is extremely good at finding any path by which articles can leave a subnet with supposedly-restrictive boundaries. Substantial administrative effort is required to ensure that local newsgroups remain local [SPE1994]. ISPs who provide customers with the ability to remotely manipulate their inbound filters should use strong authentication for this service. ISPs should not propagate articles that are excessively crossposted. 10 or more cross-postings is widely agreed to be as excessive. ISPs should impose an upper limit on the article size that they will propagate. 10 Web-hosting Services Sites frequently choose to outsource the operation and administration of their site to an ISP, and security is often prominent on the list of arguments for doing so. The hosting of such sites and provision of related services is the subject of this section. Further information on the topic can be found in [Gar1997] and [Hug1995]. 10.1 Webhosting Server Administration In addition to issues raised in section 6 ISPs will need to address the following issues in administering their web-hosting servers: - Service Monitoring. The service availability (ability to answer queries) should be monitored. - Clock synchronization. Servers should synchronize their clocks using the NTP protocol [RFC1305] with authentication. At least two NTP servers should be used. - DNS. DNS lookups should not be performed on web clients when they connect. - DocumentRoot. Everything below this directory should be subject to the strictest scrutiny. - UserDir. Users other than administrators should not be permitted on the server. If users have accounts then the 'UserDir' directive , if permitted, should not access their private accounts. In particular, scripts should not be permitted to be run from their accounts. - Process User and Group. The web daemon should be run as a user and group that is set up specifically for that purpose, and that user/group should have minimal privilege. - Partitioning of Virtual Sites. A single server that hosts multiple sites (virtual domains) should be set up such that all data, programs and logs for the different sites are partitioned from each other such that no access to the configuration or data of each other's sites is possible. In addition, it should not be possible to access the data or programs of one customer's site using a URL that has the name of another customer's site in it's host part. - Access Control. Restricted access to certain parts of a site should be facilitated using a strong authentication mechanism such as certificate or one-time password device. An alternative is to use passwords in conjunction with SSL so that passwords aren't passed across the network in plaintext. - Security Patches. The stakes in running a web server are particularly high, so administrators should be particularly vigilant in applying security patches as they are released. 10.2 Server Side Programs Server side programs such as those that use the Common Gateway Interface (CGI) are crucial to the flexibility of the web as a communications medium. However that flexibility introduces security risks and a weak program threatens all of the virtual hosts on the server that runs it. An ISP's policy with regard to what programs it will allow is a good indicator of security policy in general. ISPs should follow these guidelines on server side programs and CGIs: - Security Policy. ISPs should give their customers clear guidelines about how to write secure programs for their hosting environment, and give specific indications about what programming practices will result in a program being rejected. - Program Installation. Customers should never be allowed to install their own programs. All programs and scripts should be submitted to the ISP first to be checked for conformance with security policy. The programs should be installed such that only the server administrators have permission to modify them. - Process User and Group. Programs should be run as a user and group that is set up specifically for that purpose, and that user/group should have minimal privilege (many sites use 'nobody'). - Display by Browsers. Programs should never be allowed to be viewed by browsers. One implication of that is that they should not be put under the DocumentRoot. - Partitioning of Virtual Sites. Programs should be not accessible through the site of another customer on the same server, or to the webmaster of that other customer. - User Input. Expressions should not be evaluated based on user input except when used with the equivalent of Perl's tainting features. - Processing Limit. All programs should have a limit set on real and CPU time. - Paths. All paths should be full or starting at DocumentRoot, and PATH should be set by the server administrator. 10.3 Data and Databases Data that is written by server-side programs such as CGI scripts should be considered confidential and to prevent them being read by browsers their permission should be such that they're not readable by the HTTP daemon process. If access to a back-end database is provided then programs that facilitate such access should have the least privilege that absolutely necessary. Data that relates to state management (cookies) that is stored on the server should be considered confidential and should not be accessible from browsers. 10.4 Logs and Statistics Reporting The logs generated by the HTTP daemon process can be useful from the security viewpoint in providing an audit trail of site activity, however their more common use is for billing and for market and site analysis. These logs should be considered highly confidential. - The only manipulation of them done by the ISP should be that which is necessary to generate billing information and periodically rotate them. - They should be stored outside of DocumentRoot to prevent access by a browser to them. - Access to them, whether in raw or summarised format, should be provided to the customer over a secure channel. 10.5 Push and Streaming Services ISPs frequently provide their customers with the ability to deliver content using protocols other than HTTP. Where such add-on services are provided, both the customer and the ISP should be aware of the security implications of providing such services. 10.6 Commerce Many ISPs set up the means whereby their customers can sell goods and services through their web-hosted sites. Though a server that can exchange information with a browser over SSL is sometimes described as a 'secure server' this term can be misleading, and ISPs that host commerce applications should consider the following: - Encrypted Transactions. Transactions should never be stored on the server in unencrypted form. Ideally they should be passed directly to the financial institution and customer without being stored on the server at all, however if they must be stored on the server then public key cryptography should be used such that only the customer can decrypt the transactions. - Transaction Transfer. If transactions are not processed immediately but instead are transferred to the customer in batches then that transfer should occur over a secure channel such as SSL and only after strong authentication has taken place. Transaction files should be carefully rotated so that every transaction occurs exactly once. - Backups. If transactions are written to backup media then the physical security of the backup media should be assured. 10.7 Content Loading and Distributed Authoring The loading of content onto the ISP's server should happen over a secure channel. If server support for Distributed Authoring tools is enabled, then this should be administered with great care to ensure that strong authentication takes place and that access is given only to the customer's virtual site. 10.8 Search Engines and other tools ISPs frequently install tools such as search engines, link checkers and so on for use by their customers. Many such tools create a very great processing overhead when run and so running them on-demand should not be allowed to avoid Denial of Service attacks. Search engines should be configured so that their searches are restricted to those parts of a site that are available to all. The output of link checkers should be considered confidential, and should only be available to the webmaster of the customer site. 11 References [DPR1984] UK Data Protection Act 1984 (c. 35), http://www.hmso.gov.uk/acts/acts1984/1984035.htm [GAR1997] Garfinkel, S., "Web Security and Commerce", O'Reilly and Associates, Sebastopol, CA, 1997 [HUG1995] Hughes Jr., L., "Actually Useful Internet Security Techniques", New Riders Publishing, Indianapolis, IN, 1995 [SPE1994] Spencer, H., "News Article Format and Transmission", ftp://ftp.zoo.toronto.edu/pub/news.txt.Z [SSH1997] SSH (secure Shell) Remote Login Program, http://www.cs.hut.fi/ssh/ [VIX1995] Vixie, P., "DNS and BIND Security Issues", ftp://ftp.vix.com/pri/vixie/bindsec.psf, 1995 12 Security Considerations This entire document discusses security issues. 13 Author's Address Tom Killalea NorthWestNet, Inc. 15400 SE 30th Place, Ste. 202 Bellevue, WA 98007-6546 USA Phone: +1 425 649-7417 E-Mail: tomk@nwnet.net This document expires April 24, 1998. Killalea Internet Draft [Page nnn]