Finally, you descend from the sublime to the ridiculously abnormal activity.
This is much like the evolution of a budding courtship. Both partners are on their best behavior at first because good manners are expected. The comfort zone seeps in after awhile, and the expected fine etiquette deteriorates from furled pinkies while drinking tea to random slurps. Familiarity certainly breeds bad manners as time passes and the first hardy belch rumbles.
The Personal Hazards of Working with False Positives
Several months ago, I was driving to work when I saw a simultaneous red flash of both the battery and brake indicator lights appear on the dashboard of my car. They disappeared immediately, but it concerned me. This happened several more times on the remainder of the commute.
I am the first to admit that I am a mechanical moron and should never question anything my car professes to tell me because it is far smarter than I am about its health. Yet, it seemed strange to me that these seemingly unrelated lights flashed together. After all, unless I had battery-powered brakes (and I was almost certain I didn't), there was no logical correlation in my mechanically challenged mind of the two different lights. I tried to explain it away as a false positive convincing myself that perhaps a loose wire of some sort was the culprit instead of real mechanical problems.
Some time passed and the problem got worse, so I gave in and called the service shop. I told the service manager about the problem and her response told me she was doing her very best not to yell, "You moron! " into the phone. Despite her training in customer relations, she could barely contain her rage at my stupidity. She told me that it was my car's alternator and I could be stranded— or some other catastrophic things could happen like the car could blow up, or I could put an eye out, yadayadayada. Needless to say after hearing the "sky-is-falling" prognosis of my car and my life, I brought the car in to be repaired right away, and the problem went away.
I got to thinking about the incident and began to reflect that I had been a relatively conservative and cautious person most of my life who, years ago, would have taken the car into the shop at the first sign of trouble. What had changed in all these years? My only guess is that I'm so used to looking at NIDS outputs of false positives that I try to explain everything away in that same light. In other words, I believe nothing any more because everyone and everything is a liar!
The Expected
What the heck is normal traffic anyway? It would be an exercise in futility— and undoubted head-bobbing boredom—to try to demonstrate all aspects of normal behavior. To make this a more manageable and interesting task, this section reviews situations and traffic patterns that are likely to be the bulk of what you will see on your network. Specifically, the response behaviors of hosts and routers are examined when different traffic is sent and received under different conditions with different protocols.
A very hard challenge in developing this material was trying to elucidate what is "normal." Because expected behavior entails so many facets and dimensions, it is impossible to discuss them all here. Ironically, normal might best be described as not abnormal. For this reason, this
book discusses many examples of deviant behavior.
Request for Comments
Is there some kind of standard baseline for what is expected? Request for Comments (RFCs)
contain the foundation documentation for the Internet. They elaborate the expected standards for individual protocols. The Internet is best viewed as a series of different protocols, each documented by one or more RFCs. RFCs do not change after they are issued; protocol enhancements are documented by issuing new RFCs. Some of the most pertinent RFCs for this section include the following:
●RFC 793. This RFC discusses the Transmission Control Protocol (TCP), describing the functions to be performed by TCP, the program that implements it, and its interface to programs or users requiring its services.
●RFC 768. This RFC discusses the functioning of the User Datagram Protocol (UDP), which is an unreliable connectionless protocol.
●RFC 791. This RFC discusses the Internet Protocol (IP), the protocol that provides for transmitting blocks of data called datagrams from sources to destinations.
●RFC 792. This RFC discusses the Internet Control Message Protocol (ICMP), the protocol that deals with errors in datagram processing.
You can find more information about RFCs at www.rfc-editor.org.
TCP Stimulus-Response
This section examines responses to an attempted telnet connection made under various conditions such as a host that doesn't listen on the telnet port or a router blocking the connection. Telnet is used as a representative TCP application. You will see some of the varied responses to the identical stimulus. Obviously, this is not an exhaustive list of all conditions that might be encountered with an attempted telnet connection. The particular set of conditions has been selected for illustration because it represents some of the most common.
Destination Host Listens on Requested Port
A host, tel_client.com, attempts to telnet to myhost.com, which listens on port telnet (TCP port 23).
Stimulus:
tel_client.com.38060 > myhost.com.telnet: S 3774957990:3774957990(0) win 8760
<mss 1460> (DF)
myhost.com offers telnet and connection is permitted.
Response:
myhost.com.telnet > tel_client.com.38060: S 2009600000:2009600000(0) ack 3774957991 win 1024 <mss 1460>
The previous TCPdump output examines the expected response when client host tel_client.com attempts to connect to the telnet port on destination host myhost.com. You have already been exposed to the concept of the three-way handshake for TCP session establishment. If you remember, the first part of the process is for the client to initiate a TCP connection with the SYN flag set to the server to signal the desire to connect. tel_client.com issues such a SYN connection request to myhost.com to connect to the telnet port.
Now, if myhost.com offers telnet, access is permitted, and no other impediments arise; you see the expected response of myhost.com replying to the request with a SYN/ACK. This says that myhost.com is listening at the telnet port and can establish this telnet connection. The final part of the three-way handshake not shown would be tel_client.com responding to myhost.com with a TCP connection with only the ACK flag set.
Destination Host Not Listening on Requested Port
Look at the following TCPdump output to see the response from the same attempted telnet connection. This time, the scenario changes and myhost.com does not listen for telnet connections. The expected response is a RESET/ACK that is an abrupt termination to the connection.
Stimulus:
tel_client.com.38060 > myhost.com.telnet: S 3774957990:3774957990(0) win 8760
<mss 1460> (DF)
myhost.com does not offer telnet.
Response:
myhost.com.telnet > tel_client.com.38060: R 0:0(0) ack 3774957991 win 0
In the response, you see that the ACK number 3774957991 from myhost.com is one more than the tel_client.com's SYN of 3774957990. This means that myhost.com received the telnet attempt, and this would be the expected sequence number of the next data byte.Yet, the R in the response indicates a connection RESET or termination because myhost.com does not listen on port telnet. After the RESET/ACK is issued by myhost.com, there should be no reply from tel_client.com.
Destination Host Doesn't Exist
What happens if tel_client.com attempts a telnet connection to myhost.com, but myhost.com doesn't exist? Looking at the following TCPdump output, you see an example of such an exchange. Often a router responds to a situation such as this in which a host cannot respond. In this case, router.com, the default router for the subnet on which myhost.com was formerly found, informs tel_client.com using ICMP that myhost.com is unreachable.
Stimulus:
tel_client.com.38060 > myhost.com.telnet: S 3774957990:3774957990(0) win 8760
<mss 1460> (DF) myhost.com doesn't exist.
Response:
router.com > tel_client.com: icmp: host myhost.com unreachable
This implies that myhost.com is a host with a registered domain name system (DNS) IP address, but the IP number is no longer active or the host is currently down or suffering from some kind of misconfiguration preventing it from responding. The response from router.com informs of this unreachable error condition using ICMP as the protocol to deliver the message to tel_client.com.
Destination Port Blocked
The next TCPdump output shows another possible condition. What if a filtering router blocks the telnet port? What kind of response will you see? Again, the router for myhost.com,
router.com, informs tel_client.com that myhost.com is unreachable and qualifies that this is because of an admin prohibited filter, meaning that the access was blocked.
router.com was just trying to be helpful and informative in this and the previous situations
examined, but it is giving out some valuable reconnaissance information if someone is probing your network. It is possible to silence Cisco routers by putting a no ip unreachables
statement in the access control list of the appropriate interface as you learned in "ICMP." This prevents the router from being as verbose and limits the information that it divulges.
Stimulus:
tel_client.com.38060 > myhost.com.telnet: S 3774957990:3774957990(0) win 8760
<mss 1460> (DF)
Router responds to blocked telnet request.
Response:
router.com > tel_client.com: icmp: myhost.com unreachable - admin prohibited filter
Destination Port Blocked, Router Doesn't Respond
This TCPdump output illustrates what happens when a router blocks traffic, but the router has been muzzled from issuing unreachable messages. Because no ICMP error message informs
tel_client.com that something is amiss, it stubbornly continues to send retries to connect. The number of retries and the time intervals in which they are sent are based on the TCP/IP stack of the operating system of the host sending the retries. Finally, the host tel_client.com gives up on the connection after it has exhausted the maximum number of retries.
Stimulus:
17:14:18.726864 tel_client.com.38060 > myhost.com.telnet: S 3774957990:3774957990(0) win 8760 <mss 1460> (DF)
Router does not respond to blocked telnet request.
Response:
17:14:21.781140 tel_client.com.38060 > myhost.com.telnet: S 3774957990:3774957990(0) win 8760 <mss 1460> (DF) 17:14:27.776662 tel_client.com.38060 > myhost.com.telnet: S 3774957990:3774957990(0) win 8760 <mss 1460> (DF) 17:14:39.775929 tel_client.com.38060 > myhost.com.telnet: S 3774957990:3774957990(0) win 8760 <mss 1460> (DF)
The topic of retries or retransmissions will be examined in greater detail in Chapter 9, "Examining
Embedded Protocol Header Fields."
UDP Stimulus-Response
A DNS query is used in this section to examine how UDP responds to different stimuli. Specifically, a listening domain port and a nonlistening port are inspected. Because the other stimuli examined in the previous section for TCP (such as a host that doesn't exist or the domain port blocked at the router) elicit very similar responses for the UDP DNS query, they don't merit repetition.
Destination Host Listening on Requested Port
Looking at the following example, you see nslookup.com does a DNS query to myhost.com on a port domain from the preceding TCPdump output. Chapter 6, "DNS," explains the TCPdump DNS output more thoroughly. You see a DNS identification number, 51007, which is used to pair up responses with requests. myhost.com receives the query and responds. myhost.com communicates on port domain (53) to nslookup.com, responding to DNS identification number 51007. The 1/0/0 is TCPdump DNS jargon for returning one answer resource record, no authority records, and no other records. As with TCP, you see that the UDP exchange was done using an ephemeral port, 45070, on the client and the well-known domain server port. The response from myhost.com uses these established ports.
Stimulus:
nslookup.com.45070 > myhost.com.domain: 51007+ (31) (DF) myhost.com runs the domain service and responds.
Response:
myhost.com.domain > nslookup.com.45070 51007 1/0/0 (193) (DF)
Destination Host Not Listening on Requested Port
Observe the following TCPdump output. In this case, myhost.com responds with an ICMP message that UDP port domain is unreachable. Again, this produces some good reconnaissance about what services a target host does or does not offer. This time it is a looselipped host, not a router that offers more detail than necessary.
Stimulus:
nslookup.com.45070 > myhost.com.domain: 51007+ (31) (DF) myhost.com doesn't run the domain service and responds.
Response:
myhost.com > nslookup.com: icmp:myhost.com udp port domain unreachable
In Chapter 9, you will learn that nmap can scan for listening UDP ports. It attempts to do this by assuming that scanned target host UDP ports for which no ICMP "port unreachable" messages are returned are listening ports. This is sometimes referred to as inverse mapping because there is no direct indication that the ports are listening.