always true.

nmap –sU sparky –p 32771-34000

WARNING: -sU is now UDP scan -- for TCP FIN scan use -sF

Starting nmap V. 2.12 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/) Interesting ports on sparky (1.1.1.100):

The following TCPdump output shows a sample from UDP port scanning. Any port in the scanned range that sparky does not generate an ICMP "port unreachable" message for is

assumed to be listening:

07:09:08.286810 verbo.62865 > sparky.32787: udp 07:09:08.286847 verbo.62865 > sparky.32775: udp 07:09:08.286878 verbo.62865 > sparky.32788: udp 07:09:08.286924 verbo.62865 > sparky.32789: udp 07:09:08.286969 verbo.62865 > sparky.32791: udp 07:09:08.287046 verbo.62865 > sparky.32774: udp 07:09:08.287094 verbo.62865 > sparky.32781: udp 07:09:08.287162 verbo.62865 > sparky.32772: udp 07:09:08.287229 verbo.62865 > sparky.32789: udp

07:09:08.287793 sparky > verbo: icmp: sparky udp port 32788 unreachable (DF) 07:09:08.977544 sparky > verbo: icmp: sparky udp port 32791 unreachable (DF) 07:09:09.657361 sparky > verbo: icmp: sparky udp port 32781 unreachable (DF) 07:09:10.157301 sparky > verbo: icmp: sparky udp port 32787 unreachable (DF) 07:09:10.817315 sparky > verbo: icmp: sparky udp port 32789 unreachable (DF)

UDP Length Field

The UDP length is the number of bytes found in the UDP header plus the number of bytes found in the UDP payload. The UDP header is 8 bytes so the minimum length for the UDP length is 8 bytes. The maximum theoretical byte length of an IP datagram is 65535. Given this, and that the IP header is a minimum of 20 bytes long, the theoretical maximum UDP length value is 65515.

Many UDP applications limit the length of the UDP datagram to 8192 bytes, although we saw where DNS limited the DNS payload to 512 bytes. Also, the TCP/IP stack of a given operating system as implemented in the kernel might limit the length of the UDP datagram.

ICMP

ICMP is another protocol that is fairly simple as far as the fields found in the header. Like UDP, ICMP does not guarantee delivery of the message, so its structure and fields are

straightforward. ICMP fields will be examined in terms of normal and malicious use.

Type and Code

Remember that ICMP has no ports. There must be a method indicating what type of ICMP message is being sent or received. The first two bytes of the ICMP message are the ICMP message type and code, respectively. The message code is a subcategory under the message type.

For instance, there are two possible message codes for a message type of 11, which represents the time exceeded category. If the message code is 0, it is a "time exceeded in-transit" message. If the message code is 1, it is an IP "reassembly time exceeded" message.Valid

values of ICMP message types and codes are found at www.iana.org/assignments/icmp-parameters.

Identification and Sequence Numbers

If you examine some ICMP requests such as the echo request, you'll find some additional fields in the ICMP header. These are the ICMP identifier found in bytes 4 and 5 offset of the ICMP header and the ICMP sequence number found in bytes 6 and 7 offset of the ICMP header. These fields are used in an echo request/echo reply pair to uniquely identify requests and match them with responses. For UNIX hosts, the ICMP ID is typically the process ID of the ping that generated the traffic. There can be several simultaneous ping commands so the identifier in both the echo request and echo reply informs the pinging host what reply is connected with what request. Each ping can generate several echo requests and the sequence number is the manner in which they are tracked in order to see if there are missing packets. Here is the

output from a ping request that demonstrates the change in ICMP sequence numbers.

PING sparky (1.1.1.100) from 1.1.1.5 : 56(84) bytes of data.

64 bytes from 1.1.1.100: icmp_seq=0 ttl=255 time=0.8 ms 64 bytes from 1.1.1.100: icmp_seq=1 ttl=255 time=0.9 ms 64 bytes from 1.1.1.100: icmp_seq=2 ttl=255 time=7.3 ms

16:33:07.400700 verbo > sparky: icmp: echo request

4500 0054 038d 0000 4001 bed1 0101 0105

0101 0164 0800 9e12 c402 0000 0391 8439 1d1d 0600 0809 0a0b 0c0d 0e0f 1011 1213

1415 1617 181916:33:07.401479 sparky > verbo: icmp: echo reply (DF)

4500 0054 7146 4000 ff01 5217 010018f64

010018f05 0000 a612 c402 0000 0391 8439 1d1d 0600 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819

Let's examine the ICMP identifier and sequence numbers in the context of the previous output's ping. We ping host sparky from verbo and see from the output that the sequence number begins at 0 and increments for each new echo request sent out. In this case, the ping process was aborted after the third echo request.

If you examine the hex dump, you'll see that the identifier is a hex c402 or decimal 50178. Because the pinging host is a Linux host, we assume this is the process ID of the ping. This value will remain static for all echo requests and replies associated with this ping. The sequence number, on the other hand, will increase by 1 for each new echo request sent and will be cloned in the associated echo reply. Had all the echo requests and replies associated with this ping process been displayed, we'd see four additional records, two echo requests, and two echo replies. The identifier would be the same for all, but the sequence number would be 1 for the second set of echo requests and replies, and it would be 2 for the third set.

Misuse of ICMP Identification and Sequence Numbers

Because the ICMP identifier and sequence number fields were not likely to receive careful