Internet Engineering Task Force                            Tom Killalea
INTERNET-DRAFT                                             NorthWestNet
Valid for six months                                      December 1997




          Security Expectations for Internet Service Providers

                      <draft-ietf-grip-isp-02.txt>

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

   To learn the current status of any Internet Draft, please check the
   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).


Copyright Notice

   Copyright (C) The Internet Society (1997).  All Rights Reserved.


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                                                        [Page 1]


Internet Draft       Security Expectations for ISPs     18 December 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 Data Protection
     4.3 Training
     4.4 Registry Data Maintenance

   5 Network Infrastructure
     5.1 Routers
     5.2 Switches, Terminal Servers, Modems and other Network Devices
     5.3 Anonymous telnet and other unlogged connections
     5.4 The Network Operation Centre (NOC) and Network Management
     5.5 Physical Security
     5.6 Routing Infrastructure
     5.7 Ingress Filtering on Source Address
     5.8 Egress Filtering on Source Address
     5.9 Route Filtering
     5.10 Directed Broadcast

   6 Systems Infrastructure
     6.1 Policy
     6.2 System Management
     6.3 Backup
     6.4 Software Distribution

   7 Domain Name Service (DNS)
     7.1 DNS Server Management
     7.2 Authoritative Domain Name Service
     7.3 Resolution Service

   8 Email and Mail Services
     8.1 Mail Server Administration
     8.2 Secure Mail



Killalea                                                        [Page 2]


Internet Draft       Security Expectations for ISPs     18 December 1997


     8.3 Open Mail Relay
     8.4 Message Submission
     8.5 POP and IMAP Services

   9 News Service (NNTP)
     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

   14 Full Copyright Statement


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 to
   which they point with pride when selling their services.

   This document was written for the following audience:

     - ISPs




Killalea                                                        [Page 3]


Internet Draft       Security Expectations for ISPs     18 December 1997


     - People who make purchasing decisions for Internet services for
       an organisation, and the people at such organisations who take
       responsibility for site security.

   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 ISPs 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

     - inform the customer about the attack



Killalea                                                        [Page 4]


Internet Draft       Security Expectations for ISPs     18 December 1997


     - trace the 'apparent' source of the attack (inasmuch as the
       source address of the attack can be believed).  In cases where
       the source address is spoofed they could trace the point
       at which the bogusly addressed traffic entered the ISP's
       network.

     - 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].

     - protect evidence of the incident

   If the event continues then, at the customer's request, ISPs may also
   assist by logging in order to further diagnose the problem, or by
   filtering 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 ISP's
   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



Killalea                                                        [Page 5]


Internet Draft       Security Expectations for ISPs     18 December 1997


     - 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.

   ISPs should consider using common URLs for expanded details on the
   above (ie. http://www.ISP-name-here.net/security/).

   In addition, ISPs have a duty to make sure that their contact
   information, in Whois, in the routing registry [RFC1786] or in any
   other repository, 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, with law enforcement or with the press and
   general public.

   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.  The AUP
   should be reviewed each time the contract is up for renewal, and in
   addition the ISP should proactively notify customers as policies are
   updated.



Killalea                                                        [Page 6]


Internet Draft       Security Expectations for ISPs     18 December 1997


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 and following sections describe 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.

   Later sections cover in some detail issues related to specific
   services such as ingress filtering and open mail relays. Such issues,
   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.

   Cooperation can be put on legal ground.  For example prior to
   entering into peering agreements ISPs could specify the steps they
   will take to cooperatively track security incidents that involve both
   peers.


4.5 Data Protection

   Many jurisdictions have the good fortune to have Data Protection
   Legislation.  Where such legislation exists ISPs should consider the



Killalea                                                        [Page 7]


Internet Draft       Security Expectations for ISPs     18 December 1997


   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]).


4.6 Training

   It's important that all ISP staff be trained to be security-conscious
   at all times and to be able to make appropriate use of tools that
   enhance security.  Some issues that they should be particularly aware
   of include the use of secure channels for confidential information,
   the risk of attacks that use social engineering, management of data
   used for authentication, and so on.


4.7 Registry Data Maintenance

   ISPs are commonly responsible for maintaining the data that is stored
   in global repositories such as the Internet Routing Registry (IRR)
   and the APNIC, InterNIC and RIPE databases.  Updates to this data
   should only be possible using strong authentication.


5 Network Infrastructure

     ISPs are responsible for managing the network infrastructure of the
     Internet in such a way that it is

     - reasonably resistant to known security vulnerabilities

     - 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




Killalea                                                        [Page 8]


Internet Draft       Security Expectations for ISPs     18 December 1997


     - 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 destinations, 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 based on one-time passwords or better
   (e.g. Kerberos) and should be as restricted as possible.

   Sessions should be encrypted to prevent sessions or data from being
   stolen and to avoid replay attacks.

   Routers should not run the 'small services', which are often enabled
   by default.  These may include bootp, chargen, daytime, discard,
   echo, and finger.


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 shut down.

   Where possible access to such devices should be restricted only to
   legitimate network administrators.


5.3 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.



Killalea                                                        [Page 9]


Internet Draft       Security Expectations for ISPs     18 December 1997


   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.

   The use of telnet to manage network elements is strongly discouraged.


5.4 The Network Operation Centre (NOC) and Network Management

   A NOC is a crucial part of an ISP's 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
   [RFC1350], which not only lacks authentication 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 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.
   Where possible SNMP should be used as a read-only tool to 'get'
   information from remote devices, and the information gotten should be
   treated as confidential.

   A further use of SNMP is in trap reporting, whereby a management
   station is 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.5 Physical Security

   [Bill Woodcock to supply more text]

   The physical security of every installation should be given
   appropriate consideration.  This is particularly so for co-located



Killalea                                                       [Page 10]


Internet Draft       Security Expectations for ISPs     18 December 1997


   facilities to which people from different organisations and with
   different security policies have access.


5.6 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 is 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.  BGP
   authentication should be used with routing peers.

   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
   use the highest level of authentication supported by the internal
   routing protocol.

   If more specific routes 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.


5.7 Ingress Filtering on Source Address

   The direction of such filtering is from the edge site (customer) to
   the Internet.

   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].  In addition, forged source addresses are frequently used
   in spoof-based attacks in order to exploit a trust relationship
   between hosts.

   To reduce the incidence of attacks that rely on forged source
   addresses ISPs should do the following.  At the boundary router with
   each of their customers they should proactively filter all traffic



Killalea                                                       [Page 11]


Internet Draft       Security Expectations for ISPs     18 December 1997


   coming from the customer that has a source address of something other
   than the addresses that have been assigned to that customer.  For a
   more detailed discussion of this topic see [draft-ferguson-ingress-
   filtering-03.txt].

   There are (rare) circumstances where ingress filtering is not
   currently possible, for example on large aggregation routers that
   cannot take the additional load of applying packet filters.  In
   addition, such filtering can cause difficulty for mobile users.
   Hence, while the use of this technique to prevent spoofing is
   strongly encouraged, I realise that it is not always feasible.

   In these rare cases where ingress filtering at the interface between
   the customer and the ISP is not possible, the customer should be
   encouraged to implement ingress filtering within their networks.  In
   general filtering should be done as close to the actual hosts as
   possible.


5.8 Egress Filtering on Source Address

   The direction of such filtering is from the Internet to the edge site
   (customer).

   There are many applications in widespread use on the Internet today
   that grant trust to other hosts based only on ip address (eg. the
   Berkeley 'r' commands).  These are susceptible to IP spoofing, as
   described in [CA-95.01.IP.spoofing].  In addition, there are
   vulnerabilities that depend on the misuse of supposedly locally
   addresses, such as 'land' as described in [CA-97.28.Teardrop_Land].

   To reduce the exposure of their customers to attacks that rely on
   forged source addresses ISPs should do the following.  At the
   boundary router with each of their customers they should proactively
   filter all traffic going to the customer that has a source address of
   any of the addresses that have been assigned to that customer.

   The circumstances described in 5.7 in which ingress filtering isn't
   feasible similarly apply to egress filtering.


5.9 Route Filtering

   Excessive routing updates can be leveraged by an attacker as a base
   load on which to build a Denial of Service attack.  At the very least
   they will result in performance degradation.

   ISPs should filter the routing announcements they hear, for example



Killalea                                                       [Page 12]


Internet Draft       Security Expectations for ISPs     18 December 1997


   to ignore routes to addresses allocated for private Internets, to
   avoid bogus routes and to implement route dampening and aggregation
   policy.

   ISPs should implement techniques that reduce the risk of putting
   excessive load on routing in other parts of the network.  These
   include 'nailed up' routes, aggressive aggregation and route
   dampening, all of which lower the impact on others when your internal
   routing changes in a way that isn't relevant to them.


5.10 Directed Broadcast

   The IP protocol allows for directed broadcast, the sending of a
   packet across the network to be broadcast on to a specific subnet.
   Very few practical uses for this feature exist, but several different
   security attacks (primarily Denial of Service attacks making use of
   the packet multiplication effect of the broadcast) use it.
   Therefore, routers connected to a broadcast medium should not be
   configured to allow directed broadcasts onto that medium.

   If it is a packet to which the router would respond if received as a
   unicast, it MAY send a (single) response.  If it is not responding
   (either because it's not appropriate, or has been configured not to)
   it MAY send an ICMP error.  It is also appropriate to silently
   discard such packets.  In any case such packets SHOULD be counted to
   detect possible attempts to abuse this feature.


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 eavesdropped (thus
   leading to 'man-in-the-middle' attacks).

   In general a 'horses for courses' approach to the provision of
   systems services should be adopted.  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 and web-hosting) are kept on
   separate systems.


6.1 Policy

   An ISP's policy with regard to privacy, authentication,



Killalea                                                       [Page 13]


Internet Draft       Security Expectations for ISPs     18 December 1997


   accountability, application of security patches, availability and
   violations reporting should all be of interest to their customers,
   and should be published in a public place such as the ISP's web site.

   A more detailed discussion of Security Policy can be found in the
   Site Security Handbook [RFC2196].


6.2 System Management

   All systems that perform critical ISP functions such as mail, news
   and web-hosting, should be restricted such that access to them is
   only available to the administrators of those services.  That access
   should be granted only following strong authentication, and should
   take place over an encrypted link.  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.

   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 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.  If volumes are dumped to staging disks during the backup
   process then access to the images on those staging disks should be as
   restricted as possible.

   Backups take on additional significance as audit data following a
   security incident.



Killalea                                                       [Page 14]


Internet Draft       Security Expectations for ISPs     18 December 1997


   Ageing backup media should be destroyed rather than discarded.


6.4 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
   SHA-1 [SHA].


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.  Customers should consider
   [RFC2182] when choosing secondary DNS servers.

   ISPs commonly operate as secondary (or slave) servers for their



Killalea                                                       [Page 15]


Internet Draft       Security Expectations for ISPs     18 December 1997


   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




Killalea                                                       [Page 16]


Internet Draft       Security Expectations for ISPs     18 December 1997


   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 in
   appropriate 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.  A goal is that the
       receiving/sending agent, which interfaces with remote mail
       servers, can be run with reduced the privilege.

     - Restrict remote message queue starting.
       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.
       Remote message queue starting is implemented using a variety of
       mechanisms, one of which is the ETRN SMTP service extension as
       described in [RFC1985].

     - 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

   As indicated in 2.6, It's critical that ISPs, and in particular their
   Security Incident Response personnel, have access to tools that allow



Killalea                                                       [Page 17]


Internet Draft       Security Expectations for ISPs     18 December 1997


   them to exchange email securely.


8.3 Open Mail Relay

   An SMTP mail server is said to be running as an 'open' mail relay if
   it is willing to accept and relay to non-local destinations mail
   messages that do not originate locally (ie. neither the originator
   nor the recipient address is local).  Such open relays are frequently
   used by 'spammers' to inject their Unsolicited Bulk E-mail (UBE)
   while hiding their identity.  There are very limited cases in which
   an administrator can make a justifiable case for leaving a mail relay
   on the Internet completely open.

   The processes for restricting relaying are well documented.  It's
   regrettable that some 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 UBE.

   ISPs should also strongly encourage their customers to disable open
   relaying on their mail servers.  Sanctions for running an open mail
   relay should be covered in an ISP's AUP.


8.4 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].

   The POP3 XTND XMIT extension which allows clients to send mail
   through the POP3 session rather than using SMTP should also be
   considered.  It also provides a way to support mobile users at sites
   where open relaying is disabled, and has the benefit of an
   authenticated connection and a better audit trail.


8.5 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].





Killalea                                                       [Page 18]


Internet Draft       Security Expectations for ISPs     18 December 1997


9 News Service (NNTP)

   As in the case of SMTP, the NNTP protocol [draft-ietf-nntpext-base-
   02.txt] used by News suffers from a lack of authentication, and so
   it's trivial to forge news postings.  Forgeries can bypass the
   moderation process, cancel legitimate articles and create havoc for
   sites that maintain an active file.

   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 (8.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.





Killalea                                                       [Page 19]


Internet Draft       Security Expectations for ISPs     18 December 1997


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 excessive.

   ISPs should impose an upper limit on the article size that they will
   propagate.


10 Web-hosting Services

   Sites frequently choose to out-source 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]



Killalea                                                       [Page 20]


Internet Draft       Security Expectations for ISPs     18 December 1997


   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 because they expose the web servers to DNS-based Denial
       of Service attacks, and they adversely affect performance.

     - 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.  This user should be different from the
       maintainers of the web content.

     - 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.




Killalea                                                       [Page 21]


Internet Draft       Security Expectations for ISPs     18 December 1997


     - Access Control.
       Restricted access to certain parts of a site should be
       facilitated using a strong authentication mechanism such as a
       certificate or a one-time password device.  An alternative is
       to use well-chosen passwords in conjunction with SSL which at
       least avoids passwords being 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.




Killalea                                                       [Page 22]


Internet Draft       Security Expectations for ISPs     18 December 1997


     - 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, and on
       the amount of disk space that they can consume.

     - Paths.
       All paths should be full or starting at DocumentRoot, and the
       PATH variable 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 web daemon process.

   If access to a back-end database is provided then programs that
   facilitate such access should have the least privilege that is
   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 web 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



Killalea                                                       [Page 23]


Internet Draft       Security Expectations for ISPs     18 December 1997


       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. Public key cryptography should be used such that only the
       customer can decrypt the transactions.  Even when transactions
       are passed directly to a financial institution and the customer
       some part of the transaction will have to be stored by the ISP
       for audit trail purposes.

     - 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



Killalea                                                       [Page 24]


Internet Draft       Security Expectations for ISPs     18 December 1997


   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, and only to that customer's content
   maintainer.


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 content maintainer of the customer's
   site.


11 References

   [CA-91:18.Active.Internet.tftp.Attacks] "Active Internet tftp
     Attacks", ftp://info.cert.org/pub/cert_advisories/

   [CA-95.01.IP.spoofing] "IP Spoofing Attacks and Hijacked Terminal
     Connections", ftp://info.cert.org/pub/cert_advisories/

   [CA-97.28.Teardrop_Land] "IP Denial-of-Service Attacks",
     ftp://info.cert.org/pub/cert_advisories/

   [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.

   [RFC1350] Sollins, K. R., "The TFTP Protocol (revision 2)", STD 33,
     RFC 1350, July 1992.

   [RFC1034] Mockapetris, P. V., "Domain names - concepts and
     facilities", STD 13, RFC 1034, November 1987.

   [RFC1035] Mockapetris, P. V., "Domain names - implementation and



Killalea                                                       [Page 25]


Internet Draft       Security Expectations for ISPs     18 December 1997


     specification", STD 13, RFC 1035, November 1987.

   [RFC1305] Mills, D., "Network Time Protocol (Version 3)
     Specification, Implementation", RFC 1305, March 1992.

   [RFC1786] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M.,
     Karrenberg, D., Terpstra, M., and J. Yu, "Representation of IP
     Routing Policies in a Routing Registry (ripe-81++)", RFC 1786,
     March 1995.

   [RFC1834] Gargano, J., and K. Weiss, "Whois and Network Information
     Lookup Service", RFC 1834, August 1995.

   [RFC1835] Deutsch, P., Schoultz, R., Faltstrom, P., and C. Weider,
     "Architecture of the WHOIS++ service", RFC 1835, August 1995.

   [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
     J., and E. Lear, "Address Allocation for Private Internets", BCP 5,
     RFC 1918, February 1996.

   [RFC1985] De Winter, J. "SMTP Service Extension for Remote Message
     Queue Starting", RFC 1985, August 1996.

   [RFC2010] Manning, B., and P. Vixie, "Operational Criteria for Root
     Name Servers", RFC 2010, October 1996.

   [RFC2065] Eastlake 3rd, D., and C. Kaufman, "Domain Name System
     Security Extensions", RFC 2065, January 1997.

   [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and
     Functions", RFC 2142, May 1997.

   [RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP
     AUTHorize Extension for Simple Challenge/Response", RFC 2195,
     September 1997.

   [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September
     1997.

   [SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 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",



Killalea                                                       [Page 26]


Internet Draft       Security Expectations for ISPs     18 December 1997


     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


14 Full Copyright Statement

   Copyright (C) The Internet Society (1997).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."




Killalea                                                       [Page 27]


Internet Draft       Security Expectations for ISPs     18 December 1997


This document expires Jun 23, 1998.


















































Killalea                                                       [Page 28]