WDIFF

draft-ietf-grip-isp-00.txt --> draft-ietf-grip-isp-01.txt

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

Security Expectations for Internet Service Providers

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

<draft-ietf-grip-isp-01.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
'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]

Internet Draft Security Expectations for ISPs 19 October 2 November 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 Data Protection
4.3 Open Mail Relay Training
4.4 Anonymous telnet and other unlogged connections
4.5 Broadcast ping (and smurfing)
4.6 Registry Data Protection 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.4 Network Management
5.5 Physical Security
5.5
5.6 Routing Infrastructure
5.7 Ingress Filtering on Source Address
5.8 Route Filtering
5.9 Directed Broadcast

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 Email and Mail Services
8.1 Mail Server Administration
8.2 Secure Mail

Killalea [Page 2]

Internet Draft Security Expectations for ISPs 2 November 1997

8.3 Open Mail Relay
8.4 Message Submission
8.4
8.5 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

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 them, a further goal is to encourage ISPs to become
proactive in making security not only a priority, but something to
which they point to with pride when selling their services.

This document was written for the following audience:

- ISPs

Killalea [Page 3]

Internet Draft Security Expectations for ISPs 2 November 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]. [draft-ietf-grip-
framework-irt-06.txt].

2.1 ISPs and Security Incident Response Teams (SIRTs)

Some ISP's 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 [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

Killalea [Page 4]

Internet Draft Security Expectations for ISPs 2 November 1997

source address of the attack can be believed) 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] 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 logging in order to further diagnose the problem, or discarding 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 ISPs 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

- what is being done to respond to the incident

Killalea [Page 5]

Internet Draft Security Expectations for ISPs 2 November 1997

- 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
information, in Whois and 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 SIRTs, with law enforcement or with the press. 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 2 November 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 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

Cooperation can be from an innocent remote site or
indeed from those addresses that are allocated for private Internets
[RFC1918].

To prevent attacks that rely put on forged source addresses legal ground. For example prior to
entering into peering agreements ISPs should
proactively filter at the boundary router with each of their customers
all traffic that has a source address of something other than could specify the
addresses that have been assigned steps they
will take to cooperatively track security incidents that customer. (It's
regrettable that major router vendors don't make involve both
peers.

4.5 Data Protection

Many jurisdictions have the application of good fortune to have Data Protection
Legislation. Where such filters the default behaviour).

In addition, legislation exists ISPs should filter and 'black hole' all traffic with
source addresses from consider 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
personal data they hold and, if
it is willing to accept necessary, register themselves as
Data Controllers and relay mail messages that do not orginate
locally be prepared to non-local destinations. Such relays are frequently used
by spammers make data available according to inject their Unsolicited Commercial E-mail (UCE) while
hiding their identity. There is no justification

Killalea [Page 7]

Internet Draft Security Expectations for any mail relay
on ISPs 2 November 1997

the Internet being left completely open, and terms of 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 legislation. Given the whole community global nature of the
Internet 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 located where no such devices, many of which don't maintain audit trails,
are very popular among attackers who wish to cover their tracks.

ISPs legislation exists
should limit access to such devices on their own network, and
work at least familiarise themselves with their customers responsibilities by
reading a Data Protection Act (eg. [DPR1984]).

4.6 Training

It's important that all ISP staff be trained to block access be security-conscious
at all times and to such devices from
outside be able to make appropriate use of tools that
enhance security. Some issues that they should be particularly aware
of include the customer's network.

4.5 Broadcast ping (and smurfing)

Smurfing (named after a program 'smurf.c' used to carry out use of secure channels for confidential information,
the
attack) is a type risk of Denial attacks that use social engineering, management of Service (DoS) attack in which an ICMP
Echo [RFC792] is sent to the broadcast address data
used for a network.
Usually authentication, and so on.

4.7 Registry Data Maintenance

ISPs are commonly responsible for maintaining the source address data that is forged 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 address network infrastructure of the
Internet in such a host way that
the attacker it is trying

- reasonably resistant 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 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

- create routing flaps which could potentially cause Denial of
Service for large parts of the Internet

Killalea [Page 8]

Internet Draft Security Expectations for ISPs 2 November 1997

- 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

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

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.

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.

Killalea [Page 9]

Internet Draft Security Expectations for ISPs 2 November 1997

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 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 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, 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.5 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.6 Routing Infrastructure

Killalea [Page 10]

Internet Draft Security Expectations for ISPs 2 November 1997

An ISP's ability to route traffic to third-party connections, facilitated by
the router's lack of logging

Such threats are amplified because of the central part correct destination depends
on routing policy as configured in the networking infrastructure routing registries [RFC1786].
ISPs should ensure that routers occupy, and the large
bandwidth frequently available to them.

So access to routers should registry information that they maintain
can only be as restricted as possible, and updated using strong
authentication should be used for all connections.

5.2 Switches, Terminal Servers, Modems authentication, and other Network Devices

ISPs that the
authority to make updates be appropriately restricted.

Due care should also be similarly vigilant taken in their configuration of other
network devices. Unfortunately many such devices deployed determining in the
field support only minimal authentication, do authorisation on an
all-or-nothing basis and do little or no logging. whose routing
announcements you place greater trust when a choice of routes are
available to a destination. In the past ISPs bogus announcements have been left with no trail to follow after their switches were
reconfigured, their terminal servers were used to launch attacks on
third parties
resulted in traffic being 'black holed', or their Uninterruptable Power Supplies were shutdown.

Where possible access to such devices worse, hijacked. BGP
authentication should be restricted only to
legitimate network administrators,

5.3 used with routing peers.

The Network Operation Centre (NOC) and network management

A NOC is a crucial part of internal routing protocol that an ISPs infrastructure, and ISP uses should be chosen with
security in mind. It should not be
operated configured 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 assumption
that information. Loading of configuration
information into network devices is still frequently done using the
TFTP protocol [RFC783], which not only lacks authorisation route recalculations are rare and uses
an insecure channel, but calls for great care in configuration at expensive as this would leave
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) way open for a set Denial of network devices periodically.
In selecting Service attack. Routing updates should
use the set highest level of devices to be polled authentication supported by the crucial role internal
routing protocol.

If more specific routes to parts of the
devices in 5.2 shouldn't ISP's allocated address space
are heard from external peers then the ISP needs to be overlooked.

Beyond simple polling a NOC will also use a network management
protocol such as SNMP [RFC1446] judicious in
deciding whether to communicate with network devices.
Usually 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

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 'get' exploit a trust relationship
between hosts.

To prevent attacks that rely on forged source addresses ISPs should
do the value of various variables,
such as following. At the number boundary router with each of packets received on their
customers they should proactively filter all traffic coming from the
customer that has a particular interface,
however source address of something other than the protocol can be used
addresses that have been assigned 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 that customer.

There are circumstances where
possible. Even with ingress filtering is not currently
possible, for example on large aggregation routers that cannot take
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 additional load. In addition, such filtering can cause
difficulty for mobile users. Hence, while the information gotten should be
treated as confidential.

A further use of SNMP this technique
to prevent spoofing is in trap reporting, so strongly encouraged, I realise that a management
station it is not
always feasible.

Killalea [Page 11]

Internet Draft Security Expectations for ISPs 2 November 1997

5.8 Route Filtering

Excessive routing updates 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 leveraged by an attacker as a base
load on which to build a Denial of Service attack.

5.4 Physical Security

The physical security of every installation At the very least
they will result in performance degradation.

ISPs should be given
appropriate consideration. This is particularly so filter the routing announcements they hear, for co-located
facilities example
to which people from different organisations and with
different security policies have access.

5.5 Routing Infrastructure

An ISP's ability ignore routes to addresses allocated for private Internets, to
avoid bogus routes and to implement route traffic to dampening and aggregation
policy.

ISPs should implement techniques that reduce the correct destination depends risk of putting
excessive load on routing policy as configured in other parts of the routing registries [RFC1786].
ISPs should ensure that the registry information that they maintain
can only be updated using strong authentication, network. These
include 'nailed up' routes, aggressive aggregation and that route
dampening, all of which lower the
authority to make updates be appropriately restricted.

Due care should also be taken in determining in whose routing
announcements you place greater trust impact on others when your internal
routing changes in a choice of routes are
available way that isn't relevant to a destination. In the past bogus announcements have
resulted in traffic being 'black holed', or worse, hijacked. them.

5.9 Directed Broadcast

The internal routing IP protocol that an ISP uses should be chosen with
security in mind. It should not be configured with allows for directed broadcast, the assumption
that route recalculations are rare and expensive as this would leave sending of a
packet across the way open for 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 attack. Routing updates should
only be permitted from authenticated sources.

If more specific routes are announced to parts attacks making use of
the ISP's allocated
address space are heard from external peers then packet multiplication effect of the ISP needs broadcast) use it.
Therefore, routers connected to a broadcast medium should not be
judicious in deciding whether
configured to accept allow directed broadcasts onto that medium.

If it is a packet to which the announcement.
Unfortunately many ISPs have allowed their CIDR address allocations 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 become fragmented, and so
detect possible attempts to abuse this scenario is all too common. 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 ease-dropped eavesdropped (thus
leading to 'man-in-the-middle' attacks).

6.1 Policy

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

Killalea [Page 12]

Internet Draft Security Expectations for ISPs 2 November 1997

accountability, application of security patches, availability and
violations reporting should all be of interest to their customers. 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 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 services. That access
should be granted only following strong authentication. 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 by the ISP's customers.
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 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) 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.

Killalea [Page 13]

Internet Draft Security Expectations for ISPs 2 November 1997

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.

Aging backup media should be destroyed rather than discarded.

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

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

Killalea [Page 14]

Internet Draft Security Expectations for ISPs 2 November 1997

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

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

Killalea [Page 15]

Internet Draft Security Expectations for ISPs 2 November 1997

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

Killalea [Page 16]

Internet Draft Security Expectations for ISPs 2 November 1997

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 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 mail messages that do not originate
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 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 authentication. At least two NTP servers relaying open by default.

While this is an issue for the whole community, ISPs should be used.

- Exception Reporting.
Exceptional conditions such as repeated authentication failures,
particularly vigilant in disabling open relaying on mail loops and abnormal queue length should be trapped and
reported.

- Restrict Access to servers that
they manage because their high-bandwidth connectivity makes them the
preferred injection point for UCE.

Sanctions for running an open mail logs.
Mail logs relay should only be readable by system administrators.

8.2 Secure Mail

It's critical that ISPs, and covered in particular their Security Incident
Response personnel, have access to tools that allow them to
exchange email securely.

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

8.4

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

Internet Draft Security Expectations for ISPs 2 November 1997

9 Usenet News Service

As in the case of SMTP, the NNTP protocol
[draft-ietf-nntpext-base-02.txt] [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.

Killalea [Page 18]

Internet Draft Security Expectations for ISPs 2 November 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" '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 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] [GAR1997]

Killalea [Page 19]

Internet Draft Security Expectations for ISPs 2 November 1997

and [Hug1995]. [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.
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.

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

Killalea [Page 20]

Internet Draft Security Expectations for ISPs 2 November 1997

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 so that which at
least avoids passwords aren't 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.

- Partitioning of Virtual Sites.

Killalea [Page 21]

Internet Draft Security Expectations for ISPs 2 November 1997

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

Killalea [Page 22]

Internet Draft Security Expectations for ISPs 2 November 1997

- 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 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
this should be administered with great care to ensure that strong
authentication takes place and that access is given only to the

Killalea [Page 23]

Internet Draft Security Expectations for ISPs 2 November 1997

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

[CA-91:18.Active.Internet.tftp.Attacks] "Active Internet tftp
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 1997.

[HUG1995] Hughes Jr., L., "Actually Useful Internet Security
Techniques", New Riders Publishing, Indianapolis, IN, 1995 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
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.

Killalea [Page 24]

Internet Draft Security Expectations for ISPs 2 November 1997

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

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

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

Killalea [Page 25]

Internet Draft Security Expectations for ISPs 2 November 1997

Phone: +1 425 649-7417
E-Mail: tomk@nwnet.net

14 Full Copyright Statement

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

This document expires April 24, May 7, 1998.

Killalea Internet Draft [Page nnn] 26]

----