Table of Contents for
Mastering Wireshark 2

Version ebook / Retour

Cover image for bash Cookbook, 2nd Edition Mastering Wireshark 2 by Andrew Crouthamel Published by Packt Publishing, 2018
  1. Mastering Wireshark 2
  2. Title Page
  3. Copyright and Credits
  4. Mastering Wireshark 2
  5. Packt Upsell
  6. Why subscribe?
  7. PacktPub.com
  8. Contributor
  9. About the author
  10. Packt is searching for authors like you
  11. Table of Contents
  12. Preface
  13. Who this book is for
  14. What this book covers
  15. To get the most out of this book
  16. Download the color images
  17. Conventions used
  18. Get in touch
  19. Reviews
  20. Installing Wireshark 2
  21. Installation and setup
  22. Installing Wireshark on Windows
  23. Installing Wireshark on macOS
  24. Installing Wireshark on Linux
  25. Summary
  26. Getting Started with Wireshark
  27. What's new in Wireshark 2?
  28. Capturing traffic
  29. How to capture traffic
  30. Saving and exporting packets
  31. Annotating and printing packets
  32. Remote capture setup
  33. Prerequisites
  34. Remote capture usage
  35. Summary
  36. Filtering Traffic
  37. Berkeley Packet Filter (BPF) syntax
  38. Capturing filters
  39. Displaying filters
  40. Following streams
  41. Advanced filtering
  42. Summary
  43. Customizing Wireshark
  44. Preferences
  45. Appearance
  46. Layout
  47. Columns
  48. Fonts and colors
  49. Capture
  50. Filter buttons
  51. Name resolution
  52. Protocols
  53. Statistics
  54. Advanced
  55. Profiles
  56. Colorizing traffic
  57. Examples of colorizing traffic
  58. Example 1
  59. Example 2
  60. Summary
  61. Statistics
  62. TCP/IP overview
  63. Time values and summaries
  64. Trace file statistics
  65. Resolved addresses
  66. Protocol hierarchy
  67. Conversations
  68. Endpoints
  69. Packet lengths
  70. I/O graph
  71. Load distribution
  72. DNS statistics
  73. Flow graph
  74. Expert system usage
  75. Summary
  76. Introductory Analysis
  77. DNS analysis
  78. An example for DNS request failure
  79. ARP analysis
  80. An example for ARP request failure
  81. IPv4 and IPv6 analysis
  82. ICMP analysis
  83. Using traceroute
  84. Summary
  85. Network Protocol Analysis
  86. UDP analysis
  87. TCP analysis I
  88. TCP analysis II
  89. Graph I/O rates and TCP trends
  90. Throughput
  91. I/O graph
  92. Summary
  93. Application Protocol Analysis I
  94. DHCP analysis
  95. HTTP analysis I
  96. HTTP analysis II
  97. FTP analysis
  98. Summary
  99. Application Protocol Analysis II
  100. Email analysis
  101. POP and SMTP
  102. 802.11 analysis
  103. VoIP analysis
  104. VoIP playback
  105. Summary
  106. Command-Line Tools
  107. Running Wireshark from a command line
  108. Running tshark
  109. Running tcpdump
  110. Running dumpcap
  111. Summary
  112. A Troubleshooting Scenario
  113. Wireshark plugins
  114. Lua programming
  115. Determining where to capture
  116. Capturing scenario traffic
  117. Diagnosing scenario traffic
  118. Summary
  119. Other Books You May Enjoy
  120. Leave a review - let other readers know what you think

TCP/IP overview

In this section, we'll take a look at the basics of TCP/IP, how packets are built, and the resolution processes that are in place, such as DNS and ARP.

In networking, we have two models that we commonly use: OSI and TCP/IP. As shown in the following diagram, on the left side we have the OSI model and on the right side we have TCP/IP model, and I've tried to match them up so that you can see how the different layers of each model line up with each other:

When we use Wireshark, we're commonly concerned with layers 2 through 7 of the OSI model. And most commonly when you use Wireshark, it's probably because something that's often application-related is going on or the system is running an application. Most commonly, you'll find yourself using Wireshark to diagnose problems that are in the upper layers, especially layer 7. But you can certainly use it to troubleshoot connectivity issues between devices on layer 3 or layer 2. While there are a number of TCP/IP services and protocols that we use to help us communicate over a network, note that we reference the layer where that protocol resides based on the OSI model, not the actual TCP/IP model's layer.

What I'd like to do is run through the building of a packet, which will give you an idea as to how the values are entered into a packet for the different fields. And since we're looking at these fields in Wireshark, it's certainly a good thing to know. So what I've done is, in a browser, I've opened up a connection to http://www.pbs.org/. What we'll do is follow through that connection and show how it found the resource and then send the first data packets to it.

The first thing that your system needs to figure out is what port number to use. When you open up your web browser and go to http://www.pbs.org/, depending on how you enter the address into the address bar of the browser, the application of the browser will know whether or not you want to use port 80; it would know by default for HTTP, or port 443 for SSL, or maybe some other custom port. So right away, your computer knows what port number it needs to start communicating on. Since I went to http://www.pbs.org/ without any sort of SSL connection, it by default knew that it will have to use port 80. The next thing it has to do is figure out where that service is. So I went to http://www.pbs.org/, but my system didn't know where http://www.pbs.org/ resides.

DNS deals with the resolution of a name to an address. So my system had a look at the DNS cache on my local system, which is a rolling cache of addresses that it has already resolved, and it looked for http://www.pbs.org/. It saw that http://www.pbs.org/ didn't exist in the cache, so it said that it needs to go send that out to my DNS server to hopefully get a response as to where this resource is located. My DNS server happens to be on my gateway, which is 0.6; this is common for standard home networks. It may not be there; it could have been a remote resource as well, such as a Google DNS server or open DNS, or some other. If this is a remote DNS server that I'm trying to connect to, then my system will take a look at my route table and figure out where it needs to go in order to access that DNS server. So, if it's remote, outside of my network, it's going to take a look at my route table and realize that it has to go out through my gateway in order to go talk to the DNS server.

And when it does, it'll check my ARP cache to see if there's a layer 2 address for my gateway so that it can send a frame to the gateway. If my system didn't have an ARP cache entry for my gateway, then my system would have sent an ARP packet out, looking for the physical address for 192.168.0.6. My system happened to have it in its ARP cache since I commonly accessed that IP address, and so we don't see an ARP packet here. What we can see here is that the first packet is a DNS packet, so my system saw that 0.6 was my DNS server, and it knew that it was a local resource. It checked my route table and realized that it's on my physical interface there and we're already connected to the 0 network, and also that I already have an ARP cache entry for 0.6. So it didn't need any of that information, and it automatically built the DNS packet. We can see in here in IPv4 that my destination is 0.6:

It built all that without having to produce any other packets to find this information. So my system then sent out its DNS request asking for http://www.pbs.org/. Now, if we go down and take a look at the UDP section, you can see that we're using port 53, which is for DNS:

And if we expand DNS, we can look at the Queries and see that we're asking for http://www.pbs.org/:

We then have to wait for the DNS response. Then, we see the next packet for DNS. We receive a standard query response for http://www.pbs.org/. If we look at DNS in the packet details pane, we can take a look at the Answers in this packet. And you'll see that http://www.pbs.org/ has a CNAME entry for address r53-vip.pbs.org, and then there's an A record entry at IP 54.225.198.196:

The A record entry is what we care about. So now my system has an IP address for http://www.pbs.org/ so that I can build a TCP handshake to http://www.pbs.org/ and to the web server so that it can then begin flowing HTTP data back and forth. So if we look at the next packet in line, we have our SYNs:

So, the highlighted packet in the preceding screenshot is the first packet in our three-way handshake for TCP. If you're familiar with TCP at all, it goes SYN, SYN, ACK, and ACK; that's your three-way handshake to open up a connection. So my first packet has a destination address of 205.185.216.10. If we look at that response that came back in DNS, the address that was provided for the A record is 205.185.216.10. So now my system knows what IP address to craft its TCP packet for. We now have a source of my local system and a destination to the server for http://www.pbs.org/ that it received, and then it sends out its handshake request. It then gets a SYN, ACK in response saying yes, I see your connection requests; let's create a connection. Then my system responds, saying yeah, that sounds great; I acknowledge. And then, finally, we begin our first HTTP packet. My system sends an HTTP packet out to that same server and says GET / HTTP, so it's saying please send me your beginning index.html and any other data for the HTTP resource. And again, it knew that it needed to use port 2869 HTTP unencrypted because when we entered that into the browser, the browser application let the stack know that it was using port 2869. And so that's the basics on how a TCP packet is built, and your system requests a resource from some sort of server or other device out there.