Finding hosts by querying Domain Name Servers (DNS), Active Directory, or other information databases doesn’t tell you everything you want to know about the network you’re operating on. Here’s a list of the information that you won’t usually get from a query:
Network topology
Network infrastructure systems
Network access controls
Control systems
Telephone switches and systems
Systems not joined to managed domains
Rogue domains
Unauthorized cross-connections to other networks
By contrast, when you sweep a network, the information you gather often proves critical to network security. On a large network, the security team and even some of the operations team might not know about all the connections that are available or about new networks. Regularly sweeping your network to discover network topology, existing hosts, and multihomed systems can provide valuable information. For example, one network administrator did a sweep and discovered a user was tunneling through the firewall to make his system dual-homed between the Internet and the internal network. If a user did that with a vulnerable system and a worm infected it, the internal network could be severely disrupted.
This book doesn’t provide tools to sweep networks, and that’s intentional for the following reasons: a large number of tools already exist, new tools come along all the time, and you can use most of these tools to cause mayhem. If you’re going to cause mayhem, you will not do it with a tool provided here. The material in this chapter will help you use existing tools safely and get more accurate results.
In the IPv4 world, it is possible to sweep large network areas quickly. Some tools can sweep a Class A network—that’s 224 or about 16 million possible IP addresses—in less than a day. You can speed up the process even further by using more systems and different techniques. However, as we move toward an IPv6 world, network sweeping techniques will become infeasible.
IPv6 divides a 128-bit address space into 64 bits for the network address and 64 bits for the local (host) portion of the address. Sixty-four bits is a large space—1.8 × 1019 addresses. Let’s assume you’re on a fast network and you can send 30,000 probes per second; in practice, most networks can handle only a fraction of this packet rate. You’d need 467 million years to probe just your local network. Even trying to discover the network portions of the address space by brute force is infeasible. Fortunately, you can use broadcast packets to discover cooperative hosts on a local network, but it is essential to know where the routers are located and how to query them. Security administrators do experience inconvenience, but attackers are inconvenienced as badly or worse, and entire classes of scanning worms become obsolete. Worms won’t disappear—they’ll just get smarter about finding hosts.
Network sweeping techniques can be grouped according to the protocol used to sweep the network. The Internet Control Message Protocol (ICMP) is one of the most commonly used protocols, and of the many varieties of ICMP packets, the ICMP echo request or ping packet is used most often. UDP packets can be used in cases where ICMP packets are blocked. Unfortunately, both UDP and ICMP suffer from the same problem, which is that the protocols themselves are unreliable.
Consider what happens when you use an unreliable technique on a network containing a number of remote offices that connect to the main network with 56-Kb modem links. On a good day, you can shove 56,000 bits of data per second down that network link—in and out. That’s 7000 bytes per second.
Now consider that an IP header can never be fewer than 20 bytes, the Media Access Control (MAC) address at the network layer is another 6 bytes, and a minimum ICMP packet contains 8 more bytes. Add in a typical 32 bytes of data, and you’re sending 66 bytes per packet, and this isn’t even counting link layer frames, which could vary depending on the type of underlying network. Fewer than 106 packets per second will fill the pipe, and that’s assuming 100 percent efficiency (70 percent is more reasonable). If you exceed 106 packets per second, none of the responses will be able to get back to you, and some portions of your echo requests will never arrive.
Meanwhile, employees at the remote office think their link to the home office has failed, point-of-sale applications running might not function, and the network people are going to be unhappy when they figure out that you’re the cause of their pagers going off. A rate of around 35 packets per second is reasonable across a 56k link (as shown in Figure 10-1), though you can go a little faster if you reduce the size of the data.
In contrast to using a ping sweep, using a TCP scan means that an initial timeout will cause a total of two more automatic retries, each of which has a longer timeout period. Any one connection will now tie up ports on your local system, the connection itself requires three packets to be exchanged, and tearing down the connection requires four more.
So you might think, "Gee, I’m on a 100-Mb network. Using the calculation just given, I ought to be able to pump about 66,000 packets per second. No problem!" Not so fast. Network speeds are rated in terms of total bandwidth. You’ll achieve this rate by using large packets—about 1500 bytes on a typical Ethernet network. What the network equipment makers don’t tell you unless you read the fine print is that routers are normally limited by the number of packets per second. Imagine living with an overworked, cheap PC that was being used as a router and was breaking down at packet rates above 700 packets per second—and on a 100-Mb network! That’s an extreme case, but it actually happened several years ago. The point is that you might encounter similar problems on networks you’re probing. Bringing down a network, even temporarily, and claiming that it was a good thing you found the denial of service (DoS) attack before the attackers did will save your hide only some of the time. It is always best to try to be considerate of the networks you’re operating on and stay on good terms with the people running them.
There are a large number of different ICMP packets. A complete listing can be found at http://www.iana.org/assignments/icmp-parameters, and additional IPv6 ICMP packets are listed at http://www.iana.org/assignments/icmpv6-parameters. ICMP packets are identified by a 1-byte type designator and a 1-byte code. A typical ICMP sweep uses a ping or echo request packet, which is type 8, code 0. The echo reply is type 0, code 0. A ping is the traditional method of determining whether a host is actually running, although other ICMP packet types will work on some networks. It is unusual to see ping packets filtered, especially on internal networks. External networks might filter inbound ICMP at the borders to reduce the impact of DoS attacks. It is also possible to conduct an ICMP sweep with other packet types, such as timestamp requests.
More Info
Ofir Arkin has done extensive work cataloging how various systems respond to the various types of ICMP probes, and how ICMP packets can be used to determine system type, or "fingerprint" a given system. Arkin’s very thorough paper on ICMP scanning techniques can be found at http://www.sys-security.com. (Host identification will be covered in more detail in Chapter 12.)
When evaluating an ICMP sweeping tool, consider whether it can control the send rate, the number of resends, and the size of the data packet. It is best if you can send different types of ICMP requests. When using the tool, a few controlled experiments are in order. Start slow and keep raising the speed until you start to find fewer hosts. This is the point at which you create a bottleneck on some portion of the network. You should be operating at about half this speed, perhaps even slower—again, being considerate of the network administrators is important. You won’t get many penetration tests conducted while dealing with someone’s boss’s boss who thinks you should be banned from sweeping the network because of the business losses you’re creating.
More than one type of ICMP request can be used to scan networks. In most cases, types other than echo request (type 8) are used for fingerprinting systems, which is discussed in more detail in Chapter 12. Take a quick look at some of the types that have been available since the original specification (obsolete types are omitted):
Type 0 – Echo response. These are echo responses; they cannot be used to perform network sweeps.
Type 3 – Destination unreachable. You will often receive unreachable responses from your scans. Host Unreachable and Network Unreachable are typical responses to a ping.
Type 4 – Source quench. Used to regulate a system’s send rate. Do not use these to sweep a network.
Type 5 – Redirect. Used to notify a host or router of a change in routing. Do not use these in a sweep. They don’t provoke a response and can cause a serious denial of service.
Type 8 – Echo request. Also known as ping; typically used in a sweep.
Type 9 – Router advertisement. Do not use these to sweep networks.
Type 10 – Router solicitation. This packet type can be used in a sweep to find routers.
Type 12 – Parameter problem. This is a response-only packet.
Type 13, 14 – Timestamp request and reply. Many systems will reply to timestamp requests, although implementation can vary from one operating system to another. If you find that echo request packets are blocked, timestamp requests can be used to discover some hosts.
Type 15, 16 – Information request and reply. Information request is obsolete. This type may be useful when fingerprinting but isn’t a reliable sweeping technique.
Type 17, 18 – Address mask request and reply. Although not obsolete, not all systems respond to these types of packets; they are more useful for fingerprinting than sweeping.
If a network has inbound ICMP blocked, a UDP sweep often can be used to find hosts quickly and efficiently. A UDP packet is used in much the same way as an ICMP packet. (UNIX systems traditionally use UDP packets to conduct traceroute checks.) The procedure is to send a UDP packet to a port that you hope isn’t listening—a port above 32,000 is usually a good choice. When the operating system receives the UDP packet, the standard states that it should reply with an ICMP port unreachable message (type 3, code 3).
If your tool allows setting the source port, try setting it to UDP port 53. Port 53 is normally used for DNS queries, and many firewall or router filters will allow UDP packets with a source port of 53. Because UDP packets are unreliable, it’s usually smart to try a few retries. Tuning the tool so that it does not abuse the network in the same way you would tune a ping sweeper is advised.
One possible but rare problem with UDP sweeps is that if the system you’re probing is listening on some odd port, it might not reply at all or it might reply with another UDP packet. Your listening thread that is looking for ICMP port unreachable responses won’t receive anything, and you’ll erroneously believe that no system is there. If there are large network segments for which you don’t receive any replies, you should suspect that you’re being filtered at some point and another technique should be used.
Another situation to look out for is getting different results from sweeping the same space. This indicates that you’re being throttled at the network level, and you should reduce your scanning rate.
Using TCP port probes to find systems is one of my favorite techniques. This technique is slower, and it is harder to write a high-performance tool, but it tends to be more accurate. TCP port probes also often find systems on external networks. A paranoid—or smart—network administrator will block incoming ICMP, block any UDP that isn’t needed, and allow only the TCP ports that are in use. Blocking all incoming ICMP packets should be done with care. Many networks are configured to allow destination unreachable packets back in. If ICMP packets are blocked, MTU discovery should also be disabled, which is often a good idea on Internet-exposed servers. On a large network, it is too much trouble and overhead on the routers to set filters on every system, and so you’ll often find that port 80 (World Wide Web) is left open to all the external systems.
When you attempt to connect to a TCP port, you’ll usually get one of three responses: a completed connection; a reset (RST) packet telling you that the port isn’t open; or a timeout, which indicates that no host is present or you’re being filtered. Not all port scanners can tell you why the connection failed. Make sure the one that you’re using can provide these details.
At the Black Hat 2002 conference, Dan Kaminsky presented an approach to TCP port scanning that he termed "stateless pulse scanning." Instead of performing a full three-way handshake to complete the connection, you create and send out raw packets much the same as in a UDP or ICMP sweep, and then you collect the SYN/ACK or RST replies. This scan can be done very quickly; Dan claims it takes as little as 4 seconds to sweep a Class B system (64,000 hosts). Although this is possible, reliability becomes an issue, and you also should be concerned with causing network congestion. Packet rates as low as 3000 per second might cause smart switches to remove systems from the network. This is a nuisance if only your system is removed; you’re facing quite another problem if it takes down a link between two routers or a Virtual Private Network (VPN) connection. You’ll also be doing the equivalent of a SYN flood, but sending only two or three SYN packets per host-port combination is unlikely to cause any real problems.
Attackers will scan a large range of IP addresses in an attempt to identify an open port and launch their attacks. One fairly insipid and popular denial of service attack is the "Smurf" attack. This type of attack has caused a lot of trouble for many network administrators. It relies on the ability to send a relatively few spoofed packets in a directed broadcast, resulting in many more packets getting sent to the victim in reply. (Using the exact network address is a directed broadcast; sending to 255.255.255.255 is a local broadcast.)
In response to these kinds of attacks, most operating systems (including Microsoft’s) generally do not reply to broadcasts, and many network administrators have configured routers so that they do not forward directed broadcasts onto the networks they serve. As a result, broadcast sweeps often are not very useful in locating individual hosts on a network. However, a broadcast sweep can be useful in fingerprinting specific hosts. For example, a network printer will typically respond to a broadcast ping.
On an internal network, trying to block network sweeps is often more trouble than it is worth. Blocking ICMP packets internally can result in host unreachable messages not being received, which causes applications to hang while waiting for a reply or sending retries to a port that isn’t listening. Also, some applications depend on echo request and echo reply packets working. One approach that can be used to block network sweeps by unmanaged systems is enabling IPSec on all managed hosts on your network. Microsoft is in the process of doing this on internal networks as of this writing.
More Info
More information about how Microsoft secures its own network can be found at http://www.microsoft.com/technet/itsolutions/msit/security/mssecbp.mspx. Microsoft’s network operations group (OTG) shares many security practices and lessons learned through the Microsoft IT Showcase series of articles.
On an external network, you might want to block all inbound ICMP packets or block only the types and codes that are used to solicit replies. Allowing a port unreachable message into your network can yield performance benefits that outweigh the risks, and enabling echo requests, timestamp requests, and other types of requests probably benefits your attackers more than it benefits you.
Blocking UDP sweeps requires a little more work, but it is possible. The main problem you’ll encounter is that you have to allow DNS to function. The best way to solve this problem is illustrated in Figure 10-2. Configure all your systems to use specific DNS servers that you control to resolve name queries, set your filters to allow only UDP traffic to those systems, and then allow traffic only to and from port 53 (assuming either a high port or 53 as the source). Once you have these safeguards in place and make sure your real DNS servers can correctly query other DNS servers, you can block inbound and outbound UDP to your external systems—unless there are other protocols to be considered, such as load balancing.
The only effective way to block TCP sweeps is to set router or firewall filters for individual systems. Another approach is to use a firewall, such as ISA Server, to publish hosts. In this way, only the service being published is available. Another good countermeasure is to use an intrusion detection system (IDS) to flag sequential TCP scans. A problem to be aware of when using stateless packet filters for protection, however, is that TCP packets can be constructed with illegal options and used to probe whether a system is present—for example, a spurious SYN/ACK often will make it past a filter, and the RST reply will indicate the host is present. (This topic is covered more thoroughly in Chapter 11.)
Understanding how a network is linked together can provide you with essential information. Topology discovery isn’t just learning where the routers are on a network. You also need to know where the multihomed systems—authorized or not—are located and what controls are placed on traffic.
Router security is one of the aspects of security that is often neglected. An insecure router can result in sniffing attacks, man-in-the-middle (MITM) attacks, and a severely compromised network. Multihomed systems provide links between networks, and securing these systems is critical; or you can just eliminate them if the systems aren’t authorized. If they are authorized, think long and hard about whether this is the correct network design. Figure 10-3 shows the fundamental danger of unauthorized multihomed hosts.
A trace route uses the value in the time-to-live (TTL) field in an IP header to determine the path that a given packet takes to get to a given destination. To keep packets from bouncing around the Internet forever when encountering routing loops, each host that forwards a packet decreases the TTL by 1 and checks to see whether the value is still greater than 0. If it is greater than 0, the packet is forwarded. If it is not greater than 0, an ICMP time exceeded message (type 11, code 0) is sent back to the packet originator.
A trace route uses this restriction by first sending a packet with a TTL of 1 and then increasing it to find the location of the routers. On Windows systems, the tracert command does this by sending an ICMP echo request. On UNIX (and UNIX-derived) systems, the traceroute command uses a UDP packet sent to a high port. As you’ll see later, any type of packet can be used to trace route. Take a look at an example of the tracert command:
C:>tracert.exe dns1.cp.msft.net Tracing route to dns1.cp.msft.net [207.46.138.20] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms firewall.mynet.local [192.168.0.7] 2 145 ms 136 ms 153 ms sdn-ap-008wataco230C.dialsprint.net [65.176.94.9] 3 144 ms 135 ms 132 ms 65.176.94.17 4 141 ms 127 ms 136 ms sdn-bb11-tac-2-0.dialsprint.net [63.180.128.198] 5 * * * Request timed out. 6 136 ms 130 ms 132 ms sl-bb22-tac-14-0.sprintlink.net [144.232.17.90] 7 135 ms 134 ms 135 ms sl-bb20-sea-0-0.sprintlink.net [144.232.9.150] 8 * * * Request timed out. 9 140 ms 139 ms 137 ms pos0-0.core2.sea2.us.msn.net [207.46.33.185] 10 140 ms 132 ms 139 ms 207.46.33.237 11 212 ms 137 ms 162 ms 207.46.36.78 12 135 ms 137 ms 139 ms 207.46.155.21 13 138 ms 139 ms 144 ms iuscsecurc6m01-vl-101.msft.net [207.46.129.9] 14 159 ms 157 ms 155 ms dns1.cp.msft.net [207.46.138.20] Trace complete.
In this example, you first find the exit point from my home network to the outside world—something interesting to know on nontrivial networks. You then progress through several routers belonging to Sprint, and hit a couple of systems at hops 5 and 8 that are configured to not return time exceeded messages. (These are probably boundary systems or core routers.) At hop 9, you enter the Microsoft network and see that there are five routers before you get to one of the authoritative name servers. Conducting a traceroute to all the systems in the range of your network sweep will show most of the routers you’re concerned with, and you’ll typically find that routers have DNS names that disclose location—for example, pos0-0.core2.sea2.us.msn.net tells you that it is a core router, and sea2.us.msn probably means that it is located in Seattle, in the United States, and is operated by MSN.
Naming conventions also can be helpful when trying to track down the owner of a system. A trace route to find the last-hop router will usually let you know what portion of the network the host is plugged in to. Although individual systems might be inaccurately cataloged, routers are usually closely tracked, and often the network operations people can help you locate owners. If it is an emergency—say, a worm infection—they can also disconnect insecure systems.
Firewalking is a neat-sounding term for something that’s really nothing more than a traceroute, except that it uses specially crafted packets to determine not just the network path but also the network controls. For example, assume you have located a host and want to see whether you can send packets to UDP port 137 to perform a NetBIOS name table query. Your query then times out. You are being filtered, but by what? Sending a UDP packet to port 137 with an incrementally increasing TTL will show you where you stop getting time exceeded messages and where you start getting timeouts. In many cases, the filtering will be performed in the last few hops before you get to the host. Figure 10-4 shows a typical network.
Using Figure 10-4 as an example, you would first send a packet with a TTL of 1 and the destination address of the server. You’d then either get a timeout or a time exceeded reply. In the figure, you’d get a time exceeded response for Router 1 and Router 2. Once the TTL is set to 3, you’ll then timeout, depending on the configuration and type of the firewall—it is possible it would also reply with a time exceeded message (though it should not). If you get a timeout, you can conclude that the firewall is blocking you. If the firewall sends a time exceeded reply, you cannot determine whether the firewall or the host is blocking you.
Once you determine which router is filtering you, you have a few options. The first and most difficult option is to compromise the router directly and insert a special rule that allows you to do exactly what you want. Be careful because, unlike a real attacker, you care whether the network continues to operate. Before you start trying an exploit you found on the Web, you might want to get in touch with the operations people first in case of a disruption.
The second, less risky option is to catalog all the systems protected by that router. If one of these systems can be compromised, you can possibly launch further attacks and tests from the second system. If an easily compromised system is located behind the same control device that is protecting important systems, you’ve found a serious security problem.
A third option is to see how well the filters are protecting the system. It could be that a name table query from a high-source port will get filtered, whereas a source port of 53 (DNS) will yield results.
The only workable countermeasure you can use is to block outbound time exceeded messages. If you do this at your border routers, external people won’t be able to easily discover your routers’ names or where they are located. One problem with blocking outbound time exceeded messages is that a single compromised host behind your border routers can be used to find the same information. You could block time exceeded messages, but it is likely that your operations people will complain that you’ve made their jobs more difficult and that their inconvenience outweighs the tiny bit of obscurity you gained. They are probably correct.
Q. | Why is network sweeping important for my penetration tests? |
A. | Knowing which IP addresses have live hosts behind them and which don’t will greatly help you focus your efforts. The more time you spend testing actual hosts, ultimately, the better your results will be. |
Q. | What about discovering network topology? |
A. | Same reason as for network sweeping for hosts to penetration test. Knowing the architecture with which you have to work during penetration tests helps your tests become more precise and effective. Otherwise, you’ll really just be shooting in the dark and hoping you get lucky. For enterprise security, betting the farm on luck is a sure path to failure. |
Q. | So what if an attacker is able to enumerate all the hosts in my organization’s network or determine its architecture? Why should I bother with masking these when I could be spending resources on securing the hosts themselves? |
A. | You should be concentrating on things like securing hosts as well as making the attacker’s job as hard as possible. As stressed in Chapter 8, the more hoops you can make attackers jump through to get to your organization’s hosts, the more likely the attackers will fail and give up. |