19:28:42.016237 10.10.10.155.www > codered.victim.com.2045: . ack 6 win 0 19:29:18.804962 codered.victim.com.2045 > 10.10.10.155.www: . 6:7(1) ack 1 win 8576 (DF)

19:29:18.805038 10.10.10.155.www > codered.victim.com.2045: . ack 6 win 0

We join our session after the faked ARP reply by the LaBrea host. For orienta-tion purposes, we see the three-way handshake completed by the Code Red victim host, codered.victim.com, and the LaBrea host pretending to be host 10.10.10.155. The codered.victim.com host then sends 5 bytes of data (in bold output) because that was the advertised window size of the bogus 10.10.10.155 host. The 10.10.10.155 LaBrea host responds with an acknowledgement of receipt of data, but a window size of 0. The codered.victim.com host waits a couple of seconds when it doesn't get any notification of a window size increase and sends a 1-byte window probe to 10.10.10.155. The LaBrea host lazily responds to the window probe essentially telling the inquirer to chill out; it is still alive and running, but is not ready for any data just yet. As you witness, this cycle is repeated with the probing host increasing its wait time for future probes and becoming tarpitted indefinitely.

UDP

UDP is a much less complicated protocol to discuss than TCP because it doesn't have any of the fields that ensure reliable delivery. UDP does not make any guarantees that data will be delivered and leaves this function to applications to handle. This section will examine the fields

found in the UDP header and how UDP port scanning is accomplished.

Ports

Just as with TCP ports, UDP port fields are two separate 16-bit fields in the TCP header—one for source and another for destination. The valid range of values is between 1 and 65535; the use of port 0 is typically a signature of unusual activity.

When a source host wishes to connect to a destination host, an ephemeral port is typically selected in the range of ports greater than 1023. For each new sending connection, a different ephemeral port should be selected.

UDP Port Scanning

Unlike TCP that responds with either a positive response (SYN/ACK) to a listening port or a negative response (RESET/ACK) to a non-listening port, UDP doesn't respond to an initial connection with any positive feedback. But, a live host responds with a negative response of ICMP "port unreachable" to a non-listening UDP port. This is how scanners determine if the UDP port is listening or not. This is another more stealthy way to scan for live hosts, assuming the site does not block outbound ICMP error messages.

So, the absence of an ICMP "port unreachable" error is construed as an open port. What if the scanning packet got dropped on its way to the target host? Or what if the target host responds with an ICMP "port unreachable" message, but the site blocks outbound ICMP messages? Or what if the site blocks inbound UDP and blocks all outbound ICMP or ICMP unreachable messages so that the scanner cannot receive an ICMP "admin prohibited" message to know this? This can be misconstrued as a listening port. Nmap scans the same UDP ports many times to try to deal with the case of dropped packets. If one packet is dropped and the network is not under duress or having problems, chances are one of the repeated packets will not be dropped. And once again, nmap is intelligent enough to know that the lack of any response is more likely an indication of filtering of some sort by the destination site than it is of all UDP ports listening. This is a UDP port scan in the 32771 to 34000 range to look for open Remote Procedure Call (RPC) ports on a Solaris host. Nmap found many of these ports open. It assumes that a port is open if no ICMP "port unreachable" message was returned. As we have discussed, this is not