In this scenario, we once again have a user who is unable to access the Internet from her workstation. However, unlike the user in the previous scenario, this user can access the Internet, but she cannot access her home page, http://
www.google.com/. When the user attempts to reach any domain hosted by Google, she is directed to a browser page that says “Internet Explorer cannot display the web page.” This issue is affecting only this particular user.
As with the previous scenario, this is a small network with a few simple switches and a single router serving as the default gateway.
Tapping into the Wire
To begin our analysis, we have the user attempt to browse to http://www.google.com/ while we listen to the traffic that is generated using a tap. The resulting file is nowebaccess2.pcap.
Analysis
The capture begins with an ARP request and reply, as shown in Figure 8-21. In packet 1, the user’s computer, with MAC address 00:25:b3:bf:91:ee and IP address of 172.16.0.8, sends an ARP broadcast packet to all computers on the network segment in an attempt to find the MAC address associated with the host’s IP address 172.16.0.102. We don’t immediately recognize this address.
Figure 8-21: ARP request and reply for another device on the network
In packet 2, the user’s computer learns that the IP address 172.16.0.102 is at 00:21:70:c0:56:f0. Based on the previous scenario, we might assume that this is the gateway router’s address, and that address is used so that packets can once again be forwarded to the external DNS server. However, as shown in Figure 8-22, the next packet is not a DNS request, but a TCP packet from 172.16.0.8 to 172.16.0.102. It has the SYN flag set, indicating that this is the first packet in the handshake for a new TCP-based connection between the two hosts .
Figure 8-22: TCP SYN packet sent from one internal host to another
Notably, the TCP connection attempt is to port 80 on 172.16.0.102 , which is typically associated with HTTP traffic. As shown in Figure 8-23, this connection attempt is abruptly halted when the host 172.16.0.102 sends a TCP packet in response (packet 4) with the RST and ACK flags set .
Recall from Chapter 6 that a packet with the RST flag set is used to terminate a TCP connection. However, in this scenario, the host at 172.16.0.8 attempted to establish a TCP connection to the host at 172.16.0.102 on port 80. Unfortunately, because that host has no services configured to listen to requests on port 80, the TCP RST packet is sent to terminate the connection. This process repeats twice. A SYN is sent from the user’s computer and replied to with a RST, before communication finally ends, as shown in Figure 8-24. At this point, the user receives a message in her browser saying that the page cannot be displayed.
Figure 8-23: TCP RST packet sent in response to the TCP SYN
Figure 8-24: The TCP SYN and RST packets are seen three times in total.
After examining the configuration of another network device that is working correctly, the ARP request and reply in packets 1 and 2 concern us because the ARP request is not for the gateway router’s actual MAC address, but some unknown device. Following the ARP request and reply, we would expect to see a DNS query sent to our configured DNS server in order to find the IP address associated with www.google.com, but we don’t. There are two conditions that could prevent a DNS query from being made:
1. The device initiating the connection already has the DNS name-to-IP address mapping in its DNS cache.
2. The device connecting to the DNS name already has the DNS name-to-IP address mapping specified in its hosts file.
Upon further examination of the client computer, we find that the computer’s hosts file has an entry for www.google.com associated with the internal IP address 172.16.0.102. This erroneous entry is the source of our user’s problems.
A computer will typically use its hosts file as the authoritative source for DNS name-to-IP address mappings, and will check that file before querying an outside source. In this scenario, the user’s computer checked its hosts file, found the entry for www.google.com, and decided that www.google.com was actually on its own local network segment. Next, it sent an ARP request to the host, received a response, and attempted to initiate a TCP connection to 172.16.0.102 on port 80. However, because the remote system was not configured as a web server, it would not accept the connection attempts.
Once the hosts file entry was removed, the user’s computer began communicating correctly and was able to access www.google.com.
TIPS To examine your hosts file on a Windows system, open C:\Windows\System32\drivers\etc\hosts. On Linux, view /etc/hosts.
This scenario is actually very common. It’s one that malware has been using for years to redirect users to websites hosting malicious code. Imagine if an attacker were to modify your hosts file so that every time you went to do your
online banking, it actually redirected you to a fake site designed to steal your account credentials!
Lessons Learned
As you continue to analyze traffic, you will learn both how the various protocols work and how to break them. In this scenario, the DNS query was not sent because the client was misconfigured, not because of any external limitations
or misconfigurations.
By examining this problem at the packet level, we were able to quickly spot an IP address that was unknown and also to determine that DNS, a key component of this communication process, was missing. Using this information, we were able to identify the client as the source of the problem.