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.