How to assess your ISP's security policy
Martin Cooper <mjc@cooper.org.uk>


As the world-wide Internet has developed, more and more organisations and
people have come to rely on it. This has made choosing an ISP (Internet
Service Provider) to make your network part of it, more important than
ever.

As with any network, consistent performance, reliability, and security are
paramount. In this article I will address the third of these; the question
of assessing your ISP's security policy.


Common security problems (in order of increasing complexity)

* Passwords. Often neglected. One of the most common methods of attack is
guessing obvious passwords.

* Broadcast networks.
- Packet sniffing by putting network cards into promiscuous mode.
Passwords and sensitive data can be harvested in this way (this is why
server, customer, and transit networks should be kept separate).

* Servers on transit networks.
- Reliable identification of hosts can be problematic, making servers
vulnerable to IP spoofing.

* Directed broadcasts.
- These allow the originator to request a router attached to a broadcast
network to convert a logical broadcast address (e.g. 192.168.10.255) to a
physical network broadcast address (e.g. FF:FF:FF:FF:FF:FF). This is
often used in Denial of Service attacks, sometimes in conjunction with
spoofed source addresses (e.g. the "smurf" attack, which causes the victim
host to generate broadcast floods directed at other networks, obscuring
the originator of the attack).

* Source routing.
- This allows the originator of traffic to specify the route that traffic
will take to its destination. This allows IP address based authorisation
to be circumvented because packets appear to come from the closest device
in the defined source route.

* Server based vulnerabilities
- Recent IMAP bug.
- Repeated sendmail bugs.
- INN and CGI data-driven attacks.
- Relaying of mail for random external networks/relaying spam
(unsolicited, possibly commercial) email.
- TCP "SYN flooding" (a SYN is the initial TCP segment used to synchronise
sequence numbers to be used in a TCP connection. Repeated SYNs without
further connection negotiation can cause the receiver to hang waiting for
acknowledgement - effectively a Denial of Service attack).
- TCP/IP stack based bugs e.g. the "teardrop" attack (a fragmented ICMP
packet of invalid size which crashed certain hosts).
- Windows bugs e.g. the "WinNuke" attack (malformed NetBIOS/NetBEUI
requests that crashed certain hosts).

* Routing table manipulation.
- New or bogus routing information introduced into the routing table by
being passed between network operators via unfiltered peering sessions.
This can be leveraged to bypass security access-lists, gain access to, and
spoof network servers (this is why server and customer networks should be
separate from transit networks).
- ISPs should particularly filter against accepting a default route (to
avoid much of their outbound traffic being diverted) and their own and
their customers' networks, for similar reasons.


ISP security measures

The ISP should keep up to date with the latest patches for
software/firmware to fix any known security problems. The Computer
Emergency Response Team (CERT) help track and collate bug reports and
patches. They run a mailing list and can be found on the web at
http://www.cert.org/

Control of network access to hosts and their associated services can be
achieved by means of packet filtering router or integrated transparent
proxy/packet filtering products.


Questions to ask your prospective ISP
(in order of how demanding they are for an ISP to meet)

1. Do you have a formal written security policy, and is it enforced ?

2. What measures do you take to prevent traffic taking unauthorised routes
into or via your network ?

3. Are the networks that support your production services, your server
customers, and your transit customers segmented by means of VLANs or
non-broadcast networks ?

4. Do you promptly apply security patches to your software/firmware
running on your production equipment ?

5. What general measures do you take to protect your Internet facing
equipment providing production services from Denial of Service attacks,
break-ins or spoofing ?

6. Do you have a standard means by which customers and Internet users can
report suspected or actual security incidents and get a response in
real-time ?

7. Do you have a monitoring system that detects host and/or network
attacks and gets a response in real-time ?

8. Do you regularly carry out port scanning on your transit customers'
networks and notify them of any abnormal findings ?

9. What additional support can you offer your customers in securing their
hosts and networks, and how much does it cost ?

10. Do you have a person and/or department devoted to security ?

11. Can we test your host and network security by mounting a deliberate
attack at a mutually agreed time ?


Testing your ISP's answers

Some of the things you may wish to consider when attempting to verify your
prospective ISP's answers include:

- Ask to see a copy of any written security policy.

- Ask to speak to a handful of reference customers.
Ask about:
 * Whether the ISP offers a (free) port scanning service.
 * Whether the customer received any (free) security advice from the ISP.
 * Whether they've ever had any problems reporting any security incidents
to the ISP or getting help resolving them.

- Check certificate and certification authenticity and validity if the ISP
provides a secure HTTP web service.

- Does the ISP allow random relaying through any of its Mail Transport
Agents ? (see http://maps.vix.com/tsi/ for a tool to assist in testing
this).

- Attempt an IP directed broadcast into the provider's network using ping.
e,g, for a network of the format x.x.x.0 use the broadcast address
x.x.x.255. This should fail.

- Attempt a source-routed traceroute into the network. This should fail
with a !S message, or at least a !H or !X first).

- Use telnet to connect to the port numbers of public TCP based services
provided by the ISP and check announced version numbers for currentness
and known security flaws. You can find helpful information in this regard
at http://www.cert.org/

- Does the ISP's registered routing policy specify that they don't accept
advertisements of their own networks ? You can check this by examining
their AS number entry in the IRRs (Internet Routing Registries) for lines
like:

AND NOT {0.0.0.0/0, <their networks here>}

On a UNIX host, use something like:

whois -h whois.ra.net AS<their AS>

or

whois AS<their AS>@whois.ra.net

- With the ISP's permission, attempt to probe/attack the ISP's network
using freely available tools: SATAN, mscan, ping, traceroute etc. Ask the
ISP to give you a report on how much of this their monitoring systems
picked up. Useful tools of this sort can be obtained from ftp.cert.org.


Ensuring your own security

Many of the security measures a competent ISP should take can also be
applied to your own hosts and network. Information on security tools
(mostly UNIX based) is available from CERT. Using these on your own
network from outside is often the best way to test your security.
Remember that good passwords are one of your best defences. Obviously it
is possible to go overboard here, and you should consider what it is that
you are trying to protect against, but as always, prevention is better
than cure.

Thanks to the UK ISP staff who assisted the author in researching this
article.