Jumat, 28 Desember 2007

Testing Connectivity Protocols

Testing Connectivity Protocols

Contents:

Packet Injection Tools
Network Emulators and Simulators
Microsoft Windows
This chapter and the next describe tools used to investigate protocol-specific behavior. In this chapter, I describe tools used to explore connectivity protocols, protocols that work at the network and transport levels to provide connectivity. Chapter 10, "Application-Level Tools" focuses on tools used in testing protocols at the application level.

I begin with a description of packet generation tools. Custom packet generators, like hping and nemesis, will allow you to create custom packets to test protocols. Load generators, like MGEN, will let you flood your network with packets to see how your network responds to the additional traffic. We conclude with a brief discussion of network emulators and simulators.

Many of the tools described in this chapter and the next are not tools that you will need often, if ever. But should the need arise, you will want to know about them. Some of these tools are described quite briefly. My goal is to familiarize you with the tools rather than to provide a detailed introduction. Unless you have a specific need for one of these tools, you'll probably want to just skim these chapters initially. Should the need arise, you'll know the appropriate tool exists and can turn to the references for more information.

9.1. Packet Injection Tools

This first group of tools generates and injects packets into your network. Basically, there are two different purposes for generating packets, each with its own general approach and its own set of tools.

First, to test software configuration and protocols, it may be necessary to control the content of individual fields within packets. For example, customized packets can be essential to test whether a firewall is performing correctly. They can also be used to investigate problems with specific protocols or to collect information such as path MTU. They are wonderful learning tools, but using them can be a lot of work and will require a very detailed knowledge of the relevant protocols.

The second reason for generating packets is to test performance. For this purpose, you typically generate a large number of packets to see how your network or devices on the network respond to the increased load. We have already done some of this. In Chapter 4, "Path Characteristics", we looked at tools that generated streams of packets to analyze link and path performance. Basically, any network benchmark will have a packet generator as a component. Typically, however, you won't have much control over this component. The tools described here give you much greater control over the number, size, and spacing of packets. Unlike custom packet generators, load generators typically won't provide much control over the contents of the packets.

These two uses are best thought of as extremes on a continuum rather than mutually exclusive categories. Some programs lie somewhere between these two extremes, providing a moderate degree of control over packet contents and the functionality to generate multiple packets. There is no one ideal tool, so you may want to become familiar with several, depending on your needs.

9.1.1. Custom Packets Generators

A number of different programs will construct custom packets for you. The utilities vary considerably in the amount of control you actually have. As all require a thorough understanding of the underlying protocols, none of these tools are particularly easy to use. All of the ones I am familiar with are command-line programs. This is really a plus since, if you find yourself using these programs heavily, you will want to call them from scripts.

Two programs, hping and nemesis, are briefly described here. A number of additional tools are cited at the end of this section in case these utilities don't provide the exact functionality you want or aren't easily ported to your system. Of the two, hping is probably the better known, but nemesis has features that recommend it. Neither is perfect.

Generally, once you have the idea of how to use one of these tools, learning another is simply a matter of identifying the options of interest. Most custom packet generators have a reasonable set of defaults that you can start with. Depending on what you want to do, you select the appropriate options to change just what is necessary -- ideally as little as possible.

Custom packet tools have a mixed reputation. They are extremely powerful tools and, as such, can be abused. And some of their authors seem to take great pride in this potential. These are definitely tools that you should use with care. For some purposes, such as testing firewalls, they can be indispensable. Just make sure it is your firewall, and not someone else's, that you are testing.

9.1.1.1. hping

hping, or hping2 as it is sometimes called, was written by Salvatore Sanfilippo. The documentation is a little rough at times and suggests uses that are inappropriate. Nonetheless, it is a powerful, versatile program.

When run with the default parameters, it looks a lot like ping and is useful for checking connectivity: 

lnx1# hping 205.153.63.30
eth0 default routing interface selected (according to /proc)
HPING 205.153.63.30 (eth0 205.153.63.30): NO FLAGS are set, 40 headers + 0 data
bytes
46 bytes from 205.153.63.30: flags=RA seq=0 ttl=126 id=786 win=0 rtt=4.4 ms
46 bytes from 205.153.63.30: flags=RA seq=1 ttl=126 id=1554 win=0 rtt=4.5 ms
46 bytes from 205.153.63.30: flags=RA seq=2 ttl=126 id=2066 win=0 rtt=4.6 ms
46 bytes from 205.153.63.30: flags=RA seq=3 ttl=126 id=2578 win=0 rtt=5.5 ms
46 bytes from 205.153.63.30: flags=RA seq=4 ttl=126 id=3090 win=0 rtt=4.5 ms

--- 205.153.63.30 hping statistic ---
5 packets tramitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 4.4/4.7/5.5 ms
At first glance, the output looks almost identical to ping's. Actually, by default, hping does not send ICMP packets. It sends TCP packets to port 0. (You can change ports with the -p option.) Since this port is almost never used, most systems will reply with a RESET message. Consequently, hping will sometimes get responses from systems that block ping. On the other hand, it may trigger intrusion detection systems as well. If you want to mimic ping, you can use the -1 argument, which specifies ICMP. Or, if you prefer, you can use -2 to send UDP packets.

When using ICMP, this is what one of the replies from the output looks like: 

46 bytes from 205.153.63.30: icmp_seq=0 ttl=126 id=53524 rtt=2.2 ms
Otherwise, the output will be almost identical to the default behavior.

If you want more information, you can use -V for verbose mode. Here is what a reply looks like with this option: 

46 bytes from 172.16.2.236: flags=RA seq=0 ttl=63 id=12961 win=0 rtt=1.0 ms
             tos =          0 len =         40
             seq =          0 ack =  108515096
             sum =       a5bc urp =          0
There is also a debug mode if you are having problems with hping.

Other options that control the general behavior of hping include -c to set the number of packets to send, -i to set the time between packets, -n for numeric output (no name resolution), and -q for quiet output (just summary lines when done).

Another group of options allows you to control the contents of the packet header. For example, the -a option can be used to specify an arbitrary source address for a packet. Here is an example: 

lnx1# hping2 -a 205.153.63.30 172.16.2.236
eth0 default routing interface selected (according to /proc)
HPING 172.16.2.236 (eth0 172.16.2.236): NO FLAGS are set, 40 headers + 0 data
bytes

--- 172.16.2.236 hping statistic ---
4 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
In this case, the packet has been sent from a computer whose actual source address is 172.16.3.234. The packet, however, will have 205.153.63.30 in its IP header as the source address. Of course, any reply from the destination will go back to the spoofed source address, not the actual source address. If this a valid address that belongs to someone else, they may not look kindly on your testing.

Spoofing source addresses can be useful when testing router and firewall setup, but you should do this in a controlled environment. All routers should be configured to drop any packets with invalid source addresses. That is, if a packet claims to have a source that is not on the local network or that is not from a device for which the local network should be forwarding a packet, then the source address is illegal and the packet should be dropped. By creating packets with illegal source addresses, you can test your routers to be sure they are, in fact, dropping these packets. Of course, you need to use a tool like ethereal or tcpdump to see what is getting through and what is blocked.[36]

[36]If this is all you are testing, you may prefer to use a specialized tool like egressor.

The source port can be changed with the -s option. The TTL field can be set with the -t option. There are options to set the various TCP flags: -A for ACK, -F for FIN, -P for PUSH, -R for RST, -S for SYN, and -U for URG. Oddly, although you can set the urgent flag, there doesn't seem to be a way to set the urgent pointer. You can set the packet size with the -d option, set the TCP header length with the -O option, and read the packet's data from a file with the -E option. Here is an example of sending a DNS packet using data in the file data.dns: 

bsd2# hping -2 -p 53 -E data.dns -d 31 205.153.63.30
hping generated an error on my system with this command, but the packet was sent correctly.

Be warned, constructing a usable data file is nontrivial. Here is a crude C program that will construct the data needed for this DNS example: 

#include 
main(  )
{
FILE *fp;

fp=fopen("data.dns", "w");
fprintf(fp, "%c%c%c%c", 0x00, 0x01, 0x01, 0x00);
fprintf(fp, "%c%c%c%c", 0x00, 0x01, 0x00, 0x00);
fprintf(fp, "%c%c%c%c", 0x00, 0x00, 0x00, 0x00);
fprintf(fp, "%c%s", 0x03, "www");
fprintf(fp, "%c%s", 0x05, "cisco");
fprintf(fp, "%c%s%c", 0x03, "com", 0x00);
fprintf(fp, "%c%c%c%c", 0x00, 0x01, 0x00, 0x01);
fclose(fp);
}
Even if you don't use C, it should be fairly clear how this works. The fopen command creates the file, and the fprintf commands write out the data. %c and %s are used to identify the datatype when formatting the output. The remaining arguments are the actual values for the data. (I'm sure there are cleaner ways to create this data, but this will work.)

Finally, hping can also be put in dump mode so that the contents of the reply packets are displayed in hex: 

bsd2# hping -c 1 -j 172.16.2.230
HPING 172.16.2.230 (ep0 172.16.2.230): NO FLAGS are set, 40 headers + 0 data
bytes
46 bytes from 172.16.2.230: flags=RA seq=0 ttl=128 id=60017 win=0 rtt=2.1 ms
               0060 9706 2222 0060 088f 5f0e 0800 4500
               0028 ea71 0000 8006 f26b ac10 02e6 ac10
               02ec 0000 0a88 0000 0000 1f41 a761 5014
               0000 80b3 0000 0000 0000 0000


--- 172.16.2.230 hping statistic ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 2.1/2.1/2.1 ms
Numerous other options are described in hping's documentation. You can get a very handy summary of options if you run hping with the -h option. I strongly recommend you print this to use while you are learning the program.

9.1.1.2. nemesis

nemesis, whose author is identified only as Obecian in the documentation, is actually a family of closely related command-line tools designed to generate packets. They are nemesis-arp, nemesis-dns, nemesis-icmp, nemesis-igmp, nemesis-ospf, nemesis-rip, nemesis-tcp, and nemesis-udp. Each, as you might guess, is designed to construct and send a particular type of packet. The inclusion of support for protocols like OSPF or IGMP really sets nemesis apart from similar tools.

Here is an example that sends a TCP packet:

bsd2# nemesis-tcp -v -D 205.153.63.30 -S 205.153.60.236

TCP Packet Injection -=- The NEMESIS Project 1.1
(c) 1999, 2000 obecian 

205.153.63.30
[IP]  205.153.60.236 > [Ports] 42069 > 23
[Flags]
[TCP Urgent Pointer] 2048
[Window Size] 512
[IP ID] 0
[IP TTL] 254
[IP TOS] 0x18
[IP Frag] 0x4000
[IP Options]
Wrote 40 bytes

TCP Packet Injected
The -v option is for verbose mode. Without this option, the program sends the packet but displays nothing on the screen. Use this option to test your commands and then omit it when you embed the commands in scripts. The -S and -D options give the source and destination addresses. You can use the -x and -y to set source and destination ports. If you want to specify flags, you can use the -f option. For example, if you add -fS -fA to the command line, the SYN and ACK flags will be set. (Many firewalls will block packets with some combinations of SYN and ACK flags but will pass packets with different combinations. Being able to set the SYN and ACK flags can be useful in testing these firewalls.)

Here is an example setting the SYN and ACK flags and the destination port: 

bsd2# nemesis-tcp -S 172.16.2.236 -D 205.153.63.30 -fS -fA -y 22
Notice the program performs silently without the -v option. A number of additional options are described in the Unix manpages.

The other programs in the nemesis suite work pretty much the same way. Here is an example for sending an ICMP ECHO REQUEST: 

bsd2# nemesis-icmp -v -S 172.16.2.236 -D 205.153.63.30 -i 8

ICMP Packet Injection -=- The NEMESIS Project 1.1
(c) 1999, 2000 obecian 

[IP]  172.16.2.236 > 205.153.63.30
[Type] ECHO REQUEST
[Sequence number] 0
[IP ID] 0
[IP TTL] 254
[IP TOS] 0x18
[IP Frag] 0x4000

Wrote 48 bytes

ICMP Packet Injected
The -i option specifies the type field in the ICMP header. In this case, the 8 is the code for an ECHO_REQUEST message. The destination should respond with an ECHO_REPLY.

The -P option can be used to read the data for the packet from a file. For example, here is the syntax to send a DNS query. 

bsd2# nemesis-dns -v -S 172.16.2.236 -D 205.153.63.30 -q 1 -P data.dns

DNS Packet Injection -=- The NEMESIS Project 1.1
(c) 1999, 2000 obecian 

[IP]  172.16.2.236 > 205.153.63.30
[Ports] 42069 > 53

[# Questions] 1
[# Answer RRs] 0
[# Authority RRs] 0
[# Additional RRs] 0


[IP ID] 420
[IP TTL] 254
[IP TOS] 0x18
[IP Frag] 0x4000
[IP Options]

00 01 01 00 00 01 00 00 00 00 00 00 03 77 77 .............ww
77 05 63 69 73 63 6F 03 63 6F 6D 00 00 01 00 w.cisco.com....
01                                           .

Wrote 40 bytes

DNS Packet Injected
Although it appears the data has been sent correctly, I have seen examples when the packets were not correctly sent despite appearances. So, be warned! It is always a good idea to check the output of a packet generator with a packet sniffer just to make sure you are getting what you expect.

9.1.1.3. Other tools

There are a number of other choices. ipfilter is a suite of programs for creating firewalls. Supplied with some operating systems, including FreeBSD, ipfilter has been ported to a number of other platforms. One of the tools ipfilter includes is ipsend. Designed for testing firewalls, ipsend is yet another tool to construct packets. Here is an example: 

bsd2# ipsend -v -i ep0 -g 172.16.2.1 -d 205.153.63.30
Device:  ep0
Source:  172.16.2.236
Dest:    205.153.63.30
Gateway: 172.16.2.1
mtu:     1500
ipsend is not the most versatile of tools, but depending on what system you are using, you may already have it installed.

Yet another program worth considering is sock. sock is described in the first volume of Richard W. Stevens' TCP/Illustrated and is freely downloadable. While sock doesn't give the range of control some of these other programs give, it is a nice pedagogical tool for learning about TCP/IP. Beware, there are other totally unrelated programs called sock.

Finally, some sniffers and analyzers support the capture and retransmission of packets. Look at the documentation for the sniffer you are using, particularly if it is a commercial product. If you decide to use this feature, proceed with care. Retransmission of traffic, if used indiscriminately, can create some severe problems.

socket and netcat

While they don't fit cleanly into this or the next category, netcat (or nc) and Juergen Nickelsen's socket are worth mentioning. (The netcat documentation identifies only the author as Hobbit.) Both are programs that can be used to establish a connection between two machines. They are useful for debugging, moving files, and exploring and learning about TCP/IP. Both can be used from scripts.

You'll need to start one copy as a server (in listen mode) on one computer: 

bsd1# nc -l -p 2000
Then start another as a client on a second computer:

bsd2# nc 172.16.2.231 2000
Here is the equivalent command for socket as a server: 

bsd1# socket -s 2000
Here is the equivalent command for a client:

bsd2# socket 172.16.2.231 2000
In all examples 2000 is an arbitrarily selected port number.

Here is a simple example using nc to copy a file from one system to another. The server is opened with output redirected to a file: 

bsd1# nc -l -p 2000 > tmp
Then the file is piped to the client:

bsd2# cat README | nc 172.16.2.231 2000
^C punt!
Finally, nc is terminated with a Ctrl-C. The contents of README on bsd1 have been copied to the file tmp on bsd2. These programs can be cleaner than telnet in some testing situations since, unlike telnet, they don't attempt any session negotiations when started. Play with them, and you are sure to find a number of other uses.

9.1.2. Load Generators

When compared to custom packet generators, load generators are at the opposite extreme of the continuum for packet injectors. These are programs that generate traffic to stress-test a network or devices on a network. These tools can help you judge the performance of your network or diagnose problems. They can also produce a considerable strain on your network. You should use these tools to test systems offline, perhaps in a testing laboratory prior to deployment or during scheduled downtime. Extreme care should be taken before using these tools on a production network. Unless you are absolutely convinced that what you are doing is safe and reasonable, don't use these tools on production networks.

Almost any application can be used to generate traffic. A few tools, such as ping and ttcp, are particularly easy to use for this purpose. For example, by starting multiple ping sessions in the background, by varying the period between packets with the -i option, and by varying the packet sizes with the -s option, you can easily generate a wide range of traffic loads. Unfortunately, this won't generate the type of traffic you may need for some types of tests. Two tools, spray and mgen, are described here. The better known of these is probably spray. (It was introduced in Chapter 4, "Path Characteristics".) It is also frequently included with systems so you may already have a copy. mgen is one of the most versatile.

9.1.2.1. spray

spray is useful in getting a rough idea of a computer's network performance, particularly its interface. spray, on the local computer, communicates with the rpc.sprayd daemon on the remote system being tested. (You'll need to make sure this is running on the remote system.) It effectively floods the remote system with a large number of fixed-length UDP packets. The remote daemon, generally started by inetd, receives and counts these packets. The local copy of spray queries the remote daemon to determine the number of packets that were successfully received. By comparing the number of packets sent to the number received, spray can calculate the number of packets lost.

Here is an example of spray using default values:

bsd2# spray sol1
sending 1162 packets of lnth 86 to 172.16.2.233 ...
       in 0.12 seconds elapsed time
       191 packets (16.44%) dropped
Sent:   9581 packets/sec, 804.7K bytes/sec
Rcvd:   8006 packets/sec, 672.4K bytes/sec
Command-line options allow you to set the number of packets sent (-c), the length of the packets sent (-l ), and a delay between packets in microseconds (-d ).

You should not be alarmed that packets are being dropped. The idea is to send packets as fast as possible so that the interface will be stressed and packets will be lost. spray is most useful in comparing the performance of two machines. For example, you might want to see if your server can keep up with your clients. To test this, you'll want to use spray to send packets from the client to the server. If the number of packets dropped is about the same, the machines are fairly evenly matched. If a client is able to overwhelm a server, then you may have a potential problem.

In the previous example, spray was run on bsd2, flooding sol1. Here are the results of running spray on sol1, flooding bsd2 : 

sol1# spray bsd2
sending 1162 packets of length 86 to 172.16.2.236 ...
       610 packets (52.496%) dropped by 172.16.2.236
       36 packets/sec, 3144 bytes/sec
Clearly, sol1 is faster than bsd2 since bsd2 is dropping a much larger percentage of packets.

Unfortunately, while spray can alert you to a problem, it is unable to differentiate among the various reasons why a packet was lost -- collision, slow interface, lack of buffer space, and so on. The obvious things to look at are the speed of the computer and its interfaces.

9.1.2.2. MGEN

The Multi-Generator Toolset or MGEN is actually a collection of tools for generating traffic, receiving traffic, and analyzing results. The work of Brian Adamson at the Naval Research Laboratory, this sophisticated set of tools will give you a high degree of control over the shape of the traffic you generate. However, you aren't given much control over the actual UDP packets the utility sends -- that's not the intent of the tool. For its intended uses, however, you have all the control you are likely to need.

The traffic generation tool is mgen. It can be run in command-line mode or by using the -g option in graphical mode. At its simplest, it can be used with command-line options to generate traffic. Here is a simple example: 

bsd2# mgen -i ep0 -b 205.153.63.30:2000 -r 10 -s 64 -d 5

MGEN: Version 3.1a3
MGEN: Loading event queue ...
MGEN: Seeding random number generator ...
MGEN: Beginning packet generation ...
     (Hit  to stop)Trying to set IP_TOS = 0x0
MGEN: Packets Tx'd       :       50
MGEN: Transmission period:     5.018 seconds.
MGEN: Ave Tx pkt rate    :     9.964 pps.
MGEN: Interface Stats    :      ep0
            Frames Tx'd :       55
              Tx Errors :        0
             Collisions :        0
MGEN: Done.
In this case, 10 packets per second for 5 seconds yields 50 packets.

Other options for mgen include setting the interface (-i), the destination address and port (-b), the packet rate (-r), the packet size (-s), and the duration of the flow in seconds (-d ). There are a number of other options described in the documentation, such as the type of service and TTL fields.

The real strength of mgen comes when you use it with a script. Here is a very simple example of a script called demo : 

START NOW
00001 1 ON 205.153.63.30:5000 PERIODIC 5 64
05000 1 MOD 205.153.63.30:5000 POISSON 20 64
15000 1 OFF
The first line tells mgen to start generating traffic as soon as the program is started. (An absolute start time can also be specified.) The second line creates a flow with an ID of 1 that starts 1 millisecond into a run that has port 5000 on 205.153.63.30 as its destination. The traffic is 5 packets per second, and each packet is 64 bytes in length. The third line tells mgen to modify the flow with ID 1. 5000 milliseconds (or 5 seconds) into the flow, packet generation should switch to a Poission distribution with a rate of 20 packets per second. The last line terminates the flow at 15,000 milliseconds. While this script has only one flow, a script can contain many.

Here is an example of the invocation of mgen with a script: 

bsd2# mgen -i ep0 demo

MGEN: Version 3.1a3
MGEN: Loading event queue ...
MGEN: Seeding random number generator ...
MGEN: Beginning packet generation ...
MGEN: Packets Tx'd       :      226
MGEN: Transmission period:    15.047 seconds.
MGEN: Ave Tx pkt rate    :    15.019 pps.
MGEN: Interface Stats    :      ep0
            Frames Tx'd :      234
              Tx Errors :        0
             Collisions :        0
MGEN: Done.
Since a Poisson distribution was used for part of the flow, we can't expect to see exactly 225 packets in exactly 15 seconds.

For many purposes, mgen is the only tool from the MGEN tool set that you will need. But for some purposes, you will need more. drec is a receiver program that can log received data. mgen and drec can be used with RSVP (with ISI's rsvpd). You will recall that with RSVP, the client must establish the session. drec has this capability. Like mgen, drec has an optional graphical interface. In addition to mgen and drec, the MGEN tool set includes a number of additional utilities that can be used to analyze the data collected by drec.

One last note on load generators -- software load generators assume that the systems they run on are fast enough to generate enough traffic to adequately load the system being tested. In some circumstances, this will not be true. For some applications, dedicated hardware load generators must be used.

Diposting oleh di Tidak ada komentar:
Idle Scanning and Related IPID Games
Spanish Translation by ThiOsk (os_k&at&softhome.net)

Almost four years ago, security researcher Antirez posted an innovative new TCP port scanning technique. Idlescan, as it has become known, allows for completely blind port scanning. Attackers can actually scan a target without sending a single packet to the target from their own IP address! Instead, a clever side-channel attack allows for the scan to be bounced off a dumb "zombie" host. Intrusion detection system (IDS) reports will finger the innocent zombie as the attacker. Besides being extraordinarily stealthy, this scan type permits mapping out IP-based trust relationships between machines.

I assumed that a problem of this magnitude would generate an immediate response and patches from the OS vendors. Unfortunately, many have chosen to ignore the problem for years. Apparently, they believe this is just a "theoretical" issue which is not practical to exploit in the real world. To refute that position, and increase the pressure on vendors to fix the problem, I have released a robust Idlescan implementation in recent versions of Nmap. This paper describes the technique in detail and offers defenses that network administrators, ISPs, and OS vendors can use to mitigate the vulnerability.

Note that Idle scanning is only one of the security risks posed by predictable IPID sequence numbers. This paper describes several other information gathering attacks made possible by this characteristic.

Technique

While Idle scanning is rather sophisticated as far as port scanning methods go, one does not have to be a TCP/IP expert to understand it. You only need to understand a few basic facts:

By combining these traits, it is possible to scan a target network while forging your identity so that it looks like an innocent "zombie" machine did the scanning. This technique is easiest to describe via a diagram. In the picture below, an attacker, A, is scanning a Target machine, while blaming the scan on some Zombie, Z. The boxes represent machines, and the lines represent packets. Brief English descriptions of the packets are printed on top of the lines, while actual TCP flags and distinctive packet information is printed below them:

Idlescan technique diagram

As demonstrated by the diagram above, the target hosts responds differently to the Zombie depending on port state. If the probed port is open, the target sends a SYN|ACK to the Zombie. The Zombie does not expect this SYN|ACK, so it sends a RST back. By sending the RST, the Zombie causes its IPID sequence number to increment. The real attacker detects this in step 3. If the port is closed, the target sends a RST to the Zombie. Zombies ignore this unsolicited RST packet and do not increment their IPID sequence number.

Idlescan Advantages

The Idlescan techniques offer attackers many advantages over other popular scan types such as SYN and FIN scans. This is why we recommend important defenses to help protect your network against this attack. Here are some of the reasons attackers (or legitimate penetration testers) might utilize this scan method:

  • Ultimate stealth scan -- There are many techniques people can use to shield their identity when scanning. Examples include using decoys (nmap -D) or half-open scanning (nmap -sS). But even these techniques require an attacker to send some packets to the target from her real IP address. Idlescan, on the other hand, is completely blind -- no packets are sent to the target from the true source address.

    One upshot of this is that intrusion detection (IDS) systems will generally light up and send alerts claiming that the zombie machine has launched a scan against them!

  • Defeating packet filtering firewalls/routers -- IP source address filtering is a common security mechanism for limiting machines that may connect to a sensitive host. For example, a company database server might only allow connections from the public web server which accesses it. A home user might only allow ssh (interactive login) connections from his work machines.

    A more disturbing scenario occurs when some company bigwig demands that network administrators open a firewall hole so he can access internal network resources from his home IP address. This can happen when executives are unwilling or unable to use secure VPN alternatives.

    Idle scanning can frequently be used to map out these trust relationship. The key factor is that Idlescan results list open ports from the zombie host perspective. So a normal scan against the aforementioned database server might show no ports open. But performing an Idlescan while using the web server IP as the zombie could expose the trust relationship by showing the database-related service ports open.

    Mapping out these trust relationships can be very useful to attackers for prioritizing targets. The web server discussed above may seem mundane to an attacker until she notices its special database access.

Nmap Usage Examples

The first step is to find an appropriate zombie host. The host should not have much traffic (hence the name Idle Scan) and should offer predictable IPID values. Printers, Windows boxes, older Linux hosts, FreeBSD, and Mac OS boxes generally work fine. The latest versions of Linux, Solaris, and OpenBSD are immune as zombies, but any host can be a target of the scan. One way to determine host vulnerability is to simply try an Nmap Idle scan. Nmap will test the zombie and report whether it is reliable.

Performing these scans is quite easy. Simply provide a zombie hostname to the -sI option and Nmap does the rest. Here is a quick example: 

# nmap -P0 -p- -sI kiosk.adobe.com www.riaa.com

Starting nmap V. 3.10ALPHA3 ( insecure.org/nmap/ )
Idlescan using zombie kiosk.adobe.com (192.150.13.111:80); Class: Incremental
Interesting ports on 208.225.90.120:
(The 65522 ports scanned but not shown below are in state: closed)
Port       State       Service
21/tcp     open        ftp
25/tcp     open        smtp
80/tcp     open        http
111/tcp    open        sunrpc
135/tcp    open        loc-srv
443/tcp    open        https
1027/tcp   open        IIS
1030/tcp   open        iad1
2306/tcp   open        unknown
5631/tcp   open        pcanywheredata
7937/tcp   open        unknown
7938/tcp   open        unknown
36890/tcp  open        unknown

Nmap run completed -- 1 IP address (1 host up) scanned in 2594.472 seconds

From the scan above, we learn that the RIAA is not very security conscious (note the open PC Anywhere, portmapper, and Legato nsrexec ports). Since they apparently have no firewall, it is unlikely that they have an IDS. But if they do, it will show 'kiosk.adobe.com' as the scan culprit. The -P0 option prevents Nmap from sending an initial ping to the RIAA machine. This slows the scan down (less timing info available), but ensures that no packets are sent to the target from your real IP. The scan took a long time because all 65535 TCP ports were scanned -- skip the "-p-" option if you only want well known ports plus 1-1024. Be sure to find your own zombies -- kiosk is not very reliable and is likely disappear or be closely monitored.

Defenses

Fortunately, there are several defenses which can be deployed to prevent most IPID-related attacks:

Network Administrators:

Internet Service Providers (ISPs) OS Vendors
Idlescan Challenges

I was going to discuss implementation challenges of writing fast, accurate Idle scanners. But very few of you are doing that, and those who are can read the source code to Nmap and other scanners. So I will only outline a few important points. This section also includes some challenges encountered by tool users.

  • Performance -- Scanning one port at a time (as in the diagram above) would be horrendously slow for thousands of ports. Nmap gets around this by sending up to 100 probes in parallel. Normally, all ports will be closed and the Zombie IPID will not increment. If Nmap finds that the IPID did increment, it will narrow down on the open port(s) using a binary search approach.
  • Non-idle hosts -- Idle scanning works by counting the number of packets sent by a zombie and assuming those packets are responses to packets originated by your target. Thus, extraneous packets sent by a non-idle zombie cause significant confusion. Nmap tries to counter this problem with probe retransmission and other techniques to detect false results. For example, Nmap knows something is wrong if it probes 6 ports and the IPID increases by 10 or 20. Nmap adjusts its timing and parallelism to compensate for slightly active hosts or dropped packets when they are detected. However, Nmap will not be reliable with any heavily active zombies. One technique in dealing with highly active zombies is to send a large number (dozens or hundreds) of probes to each port. This "brute force" technique can hide a small amount of "white noise" traffic. Unfortunately, the cost is significant bandwidth, slow scans, and the possibility of SYN flooding your target. Thomas Olofsson demonstrated a tool for doing this at his 2001 Black Hat Briefings presentation. His (Powerpoint) presentation slides are available here.
  • Egress filtering -- If you cannot spoof packets due to egress filtering by your ISP, try a new ISP or (for advanced users) IP tunneling. You can also try bouncing off another machine on your same network (less likely to be filtered).
  • Unsuitable zombies -- Some hosts will not work as zombies due to a clever operating system or substantial traffic. In most cases you can simply use a different zombie.
More fun with IPID prediction

While this paper focuses on utilizing predictable IPID sequences for port scanning, there are many other devious ways to exploit this information. Here is a brief list:

Related Links
  • Nmap, which now includes Idlescan, is available at http://insecure.org/nmap/
  • The basic IPID scan technique was invented by Antirez (Salvatore Sanfilippo). His home page is at http://www.kyuzz.org/antirez/.
  • Antirez also developed the excellent Hping tool, which is tremendously useful for low-level IPID testing.
  • LiquidK posted a proof-of-concept IPID scanner and coined the name "idlescan" in 1999. The URLs in that posting no longer work, but the source is now available here.
  • Thomas Olofsson wrote and demonstrated an IPID scanning tool at the 2001 Black Hat Briefings. His (Powerpoint) presentation slides are available here and give a good overview of the basic technique. As mentioned earlier in this paper, his tool may be preferable to Nmap in cases where the "Idle zombie host" is not really Idle. Unfortunately, I do not have a working URL for his tool.
Diposting oleh di Tidak ada komentar:
Langganan: Postingan (Atom)