Network Monitoring

Network Monitoring
Dr.MohitBansal Profile Pic
Published Date:26-10-2017
Your Website URL(Optional)
Network Capture Sooner or later, you will connect your system to a network, whether it is a LAN seg- ment at work, a cable or DSL modem at home, or even a dial-up connection on the road. You will send and receive packets from a variety of computers that you know almost nothing about. Being able to monitor, capture, and analyze those packets can be incredibly useful, either to troubleshoot network performance, debug a problem- atic networking program, or capture an attack for later analysis or as evidence for prosecution. This chapter is meant to give you a short introduction to the essential tools of captur- ing and manipulating traffic. For additional resources, I strongly recommend Wire- shark & Ethereal Network Protocol Analyzer Toolkit, by Orebaugh et al. (Syngress) and Network Intrusion Detection, by Steven Northcutt and Judy Novak (SAMS). 18.1 tcpdump tcpdump is a command-line packet sniffer for Unix-based operating systems. In order to capture packets other than those addressed to the host’s MAC address, it must enable Promiscuous Mode on the card, which requires superuser/root access. Most versions of Unix will not let you run tcpdump unless you are root, because being able to see packets from other users would violate Unix’s security model. tcpdump was originally written by Van Jacobson, Craig Leres, and Steven McCanne when they worked at Lawrence Berkeley National Laboratory (LBNL) Network Research Group (NRG), just up the hill from the main UC Berkeley campus. Because of this, the filtering language used in tcpdump is known as the Berkeley Packet Filter- ing (BPF) language. 607 Acquiring tcpdump is fairly straightforward; most Linux/Unix/POSIX distributions 18.1 (you need both to capture traffic). If an install package isn’t available for your distro, the source is available from Compiling from source is a fairly straightforward operation. Once installed, log in as root (or use sudo as discussed in Section 14.3) and run it: tcpdump By default, it picks up the first interface it finds (excluding the loopback, typically eth0 for Linux) and displays each packet it sees on that interface as a single line; for example: 12:55:09.459181 IP server.ssh P 887280:887396(116) 12:55:09.459039 IP server.ssh: . ack 887032 win 65535 ack 3693 win 9648 Ctrl-C quits the capture. If you did the above capture remotely through SSH, you receive a torrent of packets similar to the ones just shown. You are essentially seeing yourself, then telling yourself you are seeing yourself. This capability is not terribly useful, although sometimes it can be enough to know whether your network is work- ing properly. Note that if tcpdump knows the service name from the /etc/services file, it displays the service name instead of the port number (e.g., .ssh in the example). Also if it knows the reverse lookup for a particular address, it resolves it by default— this can be useful, or it can be bad. Consider this: if you are doing a covert packet capture between you and a remote tar- get, or between two targets on a port-mirrored switch (or you broke its CAM table), and then you start doing reverse-DNS lookups on the hosts you are collecting against, you are leaking information that someone else may be able to monitor and detect, revealing your otherwise untraceable activities. To disable name lookups, use the –n option: tcpdump -n What if you want to ssh in on one interface and then monitor on another? A neat trick is to have the second interface simply up, but with no IP address assigned to it. This allows you to monitor a network without being detected on that network or directly attacked. In order to specify which interface you are going to capture on, use the –i option and then the name of an interface; for example: tcpdump -i eth1 Say your Unix system is also forwarding traffic, perhaps modifying it on the way or maybe even dropping traffic (due to an inline IDS or a proxy server), and you want to see traffic that it is forwarding; or suppose your machaine is multi-homed, or you’re connected to multiple span ports, etc. If it is a Linux-based system, you can easily cap- ture traffic to and from any interfaces with theany interface keyword; for example: tcpdump -i any 608 Chapter 18: Network Capture18.1 If you decide to save packets to disk (discussed later) by using this technique, the resulting capture file is typically called a Linux cooked capture. Also keep in mind that this does not set the interfaces to promiscuous mode and only packets destined to or sent from the system are captured. To get a list of available capture interfaces, use the -D option: tcpdump -D 1.eth0 2.eth1 3.eth2 4.eth3 5.any (Pseudo-device that captures on all interfaces) 6.lo My example shows four Ethernet interfaces, the Linux any interface, and the loop- back interface. Berkeley Packet Filter (BPF) Up until now, you have been capturing any old packet that comes across the wire. And while this may be handy, it is not always desirable (consider the problem of sshing into a box, then performing a tcpdump and capturing your own SSH session in the process). As mentioned earlier, the gents from Berkeley came up with a filtering language to specify packets of interest, which became known as the Berkeley Packet Filter (BPF) language. It can be as simple or as complex as you like. We will start out with some basics. Anything that comes after the specified options when tcpdump is run is considered a BPF expression. Expressions consist of one or more primitives, which generally con- sist of an identifier (either name or number) and a qualifier. There are three different kinds of qualifiers: Type Defines what kind of item the qualifier refers to. Valid qualifiers include: host Defines a specific host to capture. By default, it assumes the protocol setting is ip and can therefore be an IP address or domain name (as long as the name can be resolved to an IP address); for example, tcpdump host or tcpdump host net Defines a specific network to capture. If one byte is given, it assumes a class A netmask; for two bytes, it assumes a class B netmask; and for three bytes, it assumes a class C netmask. For example, tcpdump net 10.1 would match any packets whose source or destination addresses matched 10.1.x.x. 18.1 tcpdump 60918.1 port Defines a specific port (TCP and UDP) to capture; for example tcpdump port 80. Also supports service names if defined in /etc/services; for example,. tcpdump port ssh. portrange Defines a specific port range (TCP and UDP) to capture; for example, tcpdump portrange 135-139. Direction Defines a direction to filter on. Valid qualifiers include: src Specifies a source address; for example, tcpdump src net 10.1.1. dst Specifies a destination address; for example, tcpdump dst net 10.1.1. Protocol Defines a protocol to filter on. Valid qualifiers include: ether Ethernet protocol options. fddi FDDI protocol options (actually an alias for ether, as they are treated the same). tr TR protocol options. wlan Wireless options. ip IP addresses. ip6 IPv6 addresses. arp Address Resolution Protocol (ARP) options. rarp Reverse Address Resolution Protocol (RARP) options. Here’s a simple example; say you want to filter on only IP protocol packets (no ARP or IPX). You could use the IP primitive to create the following filter: tcpdump -i eth1 ip You can take these different primitives and combine them, using Boolean logic (and, not, or); for example: tcpdump -i eth1 tcp port 80 and ether host 00:0C:F1:F1:B6:20 610 Chapter 18: Network Capture18.1 This would listen on interface eth1 for HTTP traffic that was sent or received by a system with a MAC address of 00:0C:F1:D1:B6:20. This next example is very useful: tcpdump -i eth2 not tcp port 22 This captures everything except SSH, which is really handy when you have ssh’d in remotely and are commanding the box to capture traffic, but you want to exclude your encrypted (and therefore useless) SSH session. Writing Packets to Disk Watching packets fly over the wire is interesting, for about 10 seconds. Under nor- mal circumstances, the packets are going by so quickly that you are not going to have the reflexes to see them long enough for it to make much sense. Sure, you can page it with your favorite paging program (e.g., more, less), but it would be so much more useful if you could save these packets to disk. Fortunately, tcpdump has a switch to do just that—the write option -w. By specifying a filename after the -w option, packets are written to disk instead of displayed: tcpdump -i eth2 -w eth2-all-but-ssh.pcap not tcp port 22 By default, tcpdump generally examines only the first 68 bytes of each packet (96 with SunOS NIT), which is enough to snag the IP header and an ICMP, TCP, UDP, or similar header, but not go much into the payload space. This is to save on mem- ory (packet buffers) and to increase performance. Saving just the packet headers to disk is not useful most of the time. To ensure the entire packet is captured (includ- ing payload), use the snaplen option of -s and set it to zero, which captures the entire packet regardless of its length; for example: tcpdump -s 0 -i eth2 -w eth2-all-but-ssh.pcap not tcp port 22 These are the most common options I use when I’m creating pcaps for later review. One problem with writing packets to disk is the sheer volume of data that gets writ- ten. This can be countered with some good BPF-fu to get more precise captures, but there are times when we cannot do filtering because we do not know what we are looking for, when we need to capture a lot of data before we find something interest- ing, or when we need to capture for a very long time. All of these scenarios result in very large pcap files. Since most systems can handle 2 GB files these days without any problems, this could be considered a non-issue, except for that fact that eventually you will want to view these pcaps. Viewing a 2 GB pcap file is not something I have ever tried, as I do not have 3–4 GB of RAM, nor the 30–45 minutes of free time to watch it load. tcpdump has a -C (chunk) option that allows you to spread a capture 18.1 tcpdump 61118.1 across several files. The -C option takes a file size parameter (in millions of bytes, not megabytes) that if exceeded, starts a new capture file and closes the old one; for example: tcpdump -s 0 -C 100 -i eth2 -w eth2-all-but-ssh.pcap not tcp port 22 This would create several files, as close to 100 million byte files as possible of pcap data until you told it to stop with a Ctrl-C. The variance in file size occurs because tcpdump does not split a packet between two capture files. New files are named the same as the -w option filename, with a number appended to the end, starting at 1 and going up from there. Unfortunately, if you name your files correctly and place a .pcap extension on the end, it will do the wrong thing and number them .pcap1, .pcap2, .pcap3, etc. The -C option can be combined with the -W (wrap) option to set a limit on how many files are created. When this number is reached, the oldest file is overwritten, creating a rolling buffer. This can be useful if you are doing a really long-term capture but do not want to crash the process because you ran out of hard drive space. This makes 10 pcap files of 100 million bytes each (for a total of about a gigabyte): tcpdump -s 0 -C 100 -W 10 -i eth2 -w eth2-all-but-ssh.pcap not tcp port 22 I’d normally have the -W option higher, say 100 or even 500, to ensure I do not lose data right away. Advanced BPF Filtering Berkeley Packet Filters support some fairly complex and detailed filter options, but it gets ugly fast and is not for the faint of heart. A full, advanced BFP document could fill its own book. BPF actually results in a compiled virtual machine that filters pack- ets when tcpdump is executed. It is capable of some very complicated relational com- parisons, including bit-level operations such as masking and shifting. Thankfully, many of the commonly used header masks, such as TCP flags or ICMP types, are precalculated. Using the built-in offset/field value of tcpflags and tcp-rst, you can filter on TCP flags; for example: tcpdump -i eth0 'tcptcpflags & tcp-rst =0' This gives us any packet that had a TCP RST flag set. Note that because we are using the ampersand (&) to perform a logical AND, we must encapsulate the expression inside tick marks or the shell interprets it a different way (i.e., as an execute-in- background operation). Advanced Dump Display There are a variety of different options for displaying data. I will cover the most important two: Verbosity and Format. 612 Chapter 18: Network Capture18.1 Verbosity is controlled with the -q and various -v options: -q (Quiet) Prints minimal protocol information. -v (Slightly Verbose) IP TTL, IP Identification, IP Length, IP Options are displayed; IP and ICMP checksums are validated. If used with the -w option, instead it displays a packet count every 10 seconds. -vv (More Verbose) In addition to the above, TCP and UDP checksums are validated and the application-layer data is displayed for common local-LAN protocols, such as NFS, SMB, NBT, and more. This is only useful if the -s option (for example, -s 0) is also used to extend into the application layer to see how much of the packet is examined by tcpdump. -vvv (Total Verbosity) In addition to the above, detailed protocol information are displayed, such as Telnet options. Format controls how the data is displayed. There are a few options for this: -A (ASCII) Prints out payload data in ASCII format; you also need to engage at least -v in order for this to work. Good for printable-text protocols such as HTTP, and SMTP, SIP, but less useful for binary-based protocols such as SMB, ARP, and Peer-to-Peer or Chat. -x (Hex-Only) Prints out payload data in Hexadecimal format; also needs at least a -v to work. This can be useful, but only if you are really good at reading hex format. -xx (Hex-With-Link-Layer) Same as -x, except it includes the link layer, which shows you neat layer 2 details such as MAC address. -X (Hex-Plus-ASCII) This option prints both Hex and ASCII side-by-side. Like the others, it works only with at least one -v. This is a good compromise when viewing binary-based or mixed binary/ASCII protocols. -XX (Hex-Plus-ASCII-With-Link-Layer) Same as -X, except that it also includes the link layer. Generally, I use tcpdump for captures and view them later with Wireshark (see Sec- tion 18.2). But sometimes you want to check to make sure your capture is working, so data display can be important. If I am playing with a printable protocol, I usually use -A, while if I’m working on a binary or mixed protocol, I use -X. Once I know I have my filter settings set correctly, I switch out the -A or -X for a -w and save to disk for later analysis. 18.1 tcpdump 61318.2 Using tcpdump to Extract Packets You can write packets to disk with the -w (write) option and do extensive filtering with BPF, and when you combine that with the -r (read) option, you can also take in a packet capture created previously with the -w option and filter out only the packets you want from it. Want to extract all HTTP traffic from a packet capture (pcap) and save it to a new file? Try this: tcpdump -r capture.pcap -w http.pcap tcp port 80 Your resulting http.pcap file has only the HTTP sessions found in the original pcap. Got a pcap of a port-scanning event? You will see thousands and thousands of SYN’s, but what you really care about is the Selective Negative ACK packets that your system sent back, indicating an open port. To filter out those packets, try this: tcpdump -r port-scan.pcap -w snack-packets.pcap 'tcptcpflags = 0x12' The 0x12 is the value of the ACK bit (position 1 on the high-nibble) plus the SYN bit (position 2 on the low-nibble). This pattern is exceptionally useful when testing fire- wall rules. Configure your firewall as you like and then use a port scanner to test it. Use the BPF above to see only which ports respond to the scan as open, then com- pare to your scanner’s output. By saving these to disk, your resulting Selective Nega- tive ACK packets.pcap shows only those packets that responded to a connection request with an open connection reply. 18.2 Ethereal/Wireshark Wireshark (née Ethereal; see for details) is the pre- mier free open source multiplatform packet capture and protocol analysis tool. It outperforms tools costing thousands of dollars. It really does deserve its own book (in fact, there already are several), so this is a quick-and-dirty overview of how to use Wireshark in common situations. If this tool excites you, I recommend digging deeper; there is a lot under the hood. Wireshark itself does not actually capture packets; it leverages libpcap (or WinPcap if on Windows) to perform those duties. Incidentally, you can install Wireshark without these libraries, and it works fine for analyzing static pcaps; it just does not capture new ones. libpcap and WinPcap both use the Berkeley Packet Filter (BPF) syntax, just like tcpdump does, which is handy since you do not have to learn yet another filtering language to use it. Once packets are captured, they are then analyzed by Wireshark and displayed. One of the powerful aspects of Wireshark is just how much detail gets parsed; each layer of the packet is broken out in exquisite detail. In the sea of data created by Wire- shark, finding what you want about the simplest packet capture can sometimes be overwhelming, which is why Wireshark has its own advanced display (not capture) 614 Chapter 18: Network Capture filtering language that is based upon the fields it creates during the analysis.18.2 This concept is important when using Wireshark. BPF filters control what is loaded into memory for analysis, while Wireshark Display Filters (WDF) controls what gets shown on the screen at any one moment. If you know what you are looking for, use libpcap/BFP to prescreen what gets loaded into memory and then your pcap file becomes much more manageable. If you do not know what you are looking for, leave your libpcap/BPF filter very permissive and be prepared for a larger pcap file. What if you want a console-based packet capture utility such as tcpdump, but still use the advanced display filters that Wireshark provides? Say hello to TShark (née tethereal), Wireshark’s console-based little brother. TShark even lets you use display filters to select which packets to save to disk (see the section “TShark Techniques” later in this chapter). Wireshark and TShark also support reading pcap files captured from other sniffers (such as tcpdump) in almost every conceivable packet capture format, and can also save pcaps into several formats as well, making it a sort of pcap file conversion pro- gram as well. Basics Getting Wireshark installed depends on your operating system, of course, but it comes as a precompiled binary for Windows. Several distributions of Unix also include precompiled binary packages, most notably OS X (through Darwin Ports or Fink), Debian, FreeBSD, Gentoo (although compiling is recommended), HP-UX, Mandriva, NetBSD, OpenPKG, Red Hat/Fedora Core, rPath, and Sun Solaris. More distros are adding Wireshark (instead of Ethereal) as a package, so check with your distribution’s package manager to make sure. If your distro is not supported with a precompiled package, you can always download source from http:// and compile it by hand. Figure 18-1 shows the initial startup screen from the Windows version of Wire- shark, but thanks to GTK+, other operating systems look very similar. Initially, the screen is mostly blank, but that is because no packets are loaded. Below the main menu bar is the button toolbar, and below that, the display filter bar. This third element is very important later on, so make a note of where the filter bar is cur- rently. This bar has a Filter text box and buttons labeled Expression…, Clear, and Apply. When you start with display filters, you will use the text box a lot. Starting a Capture The button bar across the top has some very useful buttons. The first one we are going to play with is the second button from the left. This is the Capture Options configuration button, shown in Figure 18-2. Before we can tell Wireshark to capture 18.2 Ethereal/Wireshark 61518.2 Figure 18-1. Wireshark ready for capture for us, we need to tell it what we want to capture and from what interface. Click the wrench to open the Capture Options window shown in Figure 18-3; alternatively, you can press Ctrl-K or select Capture➝ Options from the menu bar. Figure 18-2. Capture Options toolbar button This is where you tell Wireshark what you want to do. Of utmost importance is to select the correct interface. Nothing is worse than getting everything all set up (so you think), starting your capture, and generating the traffic you’re interested in cap- turing—only to discover you forgot to set the correct interface. Windows has a boat- load of virtual interfaces that get selected as the first interface instead of something useful such as your Ethernet card. Other useful options in the Capture Options dia- log box are discussed here, section by section. Capture Interface As mentioned, it is important to select the correct interface, otherwise you miss out on what packets you are interested in. Look for Ethernet (for wired cap- tures) or Wireless, Wi-Fi, or 802.11 (for wireless captures), and avoid interfaces with names such as Virtual or Tunnel unless you really know you want to cap- ture on those interfaces. Limit each packet to X bytes This is similar to the -s (snaplen) option in tcpdump. You generally want to leave this unchecked to obtain the full data payload, unless your goal is specifically 616 Chapter 18: Network Capture18.2 Figure 18-3. Wireshark Capture Options window looking at packet headers or at the first N-bytes of each packet. Turning this on reduces the pcap size, but at the cost of losing important payload data. Capture Filter Use the text box next to the button to type in your own BPF-syntax capture fil- ter or click the button to display a list of saved BPF filters (or create your own and save them here). Setting a BPF limits what Wireshark captures, so if you are unsure of what you are looking for, leave this blank (your pcap will be larger). Capture File(s) Specifies a file for Wireshark to dump packets to in real time. This is useful to ensure your packets are saved right away (in case of a crash), but if you have a slow hard drive, you may experience packet loss due to sluggish hard drive I/O. Multiple Files Useful when capturing a lot of packets, either over a long period of time or in a high-bandwidth environment. Unlike tcpdump, it is smart about file extensions, and for multiple files, it creates filenames appropriately. It generates sequential 18.2 Ethereal/Wireshark 61718.2 files starting with the name you provided, followed by an underscore and then a 5-digit incremental number, followed by another underscore and the 4-digit year, 2-digit month, 2-digit day, and 24-hour time; this is followed by the exten- sion you provided (for example, specify Capture.pcap; it makes Capture_00002_ 200707051645.pcap). Next file every X kilo-mega-giga-bytes Very useful for breaking a capture into manageable chunks, and is similar to tcpdump’s -C option. Be careful not to specify too low of a number if using the kilobyte option. Because Wireshark does not split a packet across two pcap files, Wireshark crashes with a missing file error if you specify a size smaller than your maximum packet size (Ethernet is typically 1,500 bytes, while FDDI is 4,500). Next file every X seconds/minutes/hours/days Useful for long-term captures where you want to break the file by days; for instance, if you want to correlate a firewall activity log from a certain date with a pcap. By using this option, you know which files to look through for that event. Can be used in tandem with the size restriction setting. Ring buffer with X files Similar to the wrap (-W) option in tcpdump. This creates a maximum of X pcap files and rotates through them, overwriting the oldest pcap file with a new one. Stop capture after X files Useful for not completely filling up your hard drive. Set a maximum number of files and when this limit is reached, the pcap automatically stops. Display Options Update list of packets in real time You want to turn this on in order to watch the packets appear in the analysis window as they are captured. If you do not enable this, you are not able to do any analysis until you stop the capture. Leave this off if you are capturing a high- bandwidth stream so the system can devote resources to capturing packets (to prevent packet drops). The chances are good that the packets will be flying by so fast that you will not be able to watch anyway. Automatic scrolling in live capture Only relevant if the “Update list of packets in real time” option is set. Always scrolls the display so the last packet (at the bottom) is displayed. Can be frustrat- ing in a high-bandwidth environment in case you are trying to select one packet you saw, but the display keeps scrolling. Very useful in medium-to-low band- width situations; otherwise, leave it off. This can also be set on the fly with the Auto Scroll Packet List in Live Capture button on the toolbar. See Figure 18-4 for an example of the Autoscroll Button. Hide capture info dialog When you start capturing, a nice capture statistics window pops up, showing you how many different kinds of packets are captured. If you are analyzing the packets in real time, this can clutter the display. Turn off at your discretion. 618 Chapter 18: Network Capture18.2 Figure 18-4. Autoscroll Toolbar button Name Resolution Enable MAC name resolution A network card’s burned-in MAC address consists of six bytes—the first three are the Organizationally Unique Identifier (OUI) assigned to the manufacturer by the IEEE (see for a searchable database), while the last three are a generally incremented serial number gener- ated by the manufacturer. The database is about 1.5 MB and is included in Wireshark. What this means from a practical standpoint is that Wireshark can guess at the manufacturer of the NIC you are capturing. Turning on this option enables the display (Wireshark uses an internal database to determine the manu- facturer). If you want to hunt down a machine, turning this on might help, as companies such as IBM and Dell sometimes use their OUI’s for their systems. Enable network name resolution This feature performs a reverse-DNS lookup for all IP addresses it sees, generat- ing additional traffic. This can be useful under the right circumstances; for example, performing a network capture in an environment where reverse-DNS is set up properly, and you are not doing any covert capturing. Otherwise, it is not the best idea. If you are doing a covert capture, you must leave this off or risk tipping off the people you are monitoring, since Wireshark does a DNS lookup for every IP address. So who would maintain the reverse-DNS records for the IP addresses of people attacking you? The attackers, possibly. Furthermore, reverse-DNS is not always configured correctly. This option is off by default, and I generally leave it that way. Enable transport name resolution This is another internal-lookup option that decodes the transport layer of a packet. This is worth leaving on. My settings vary slightly depending on what I am try to accomplish, but generally I select the correct interface, apply a basic BPF filter to cut down on chatter (ip is a good one to remove ARP requests/BDU packets, or tcp port X if I know a particular port I would be looking for), and turn on all three display options. If you are using Windows Remote Desktop Protocol (RDP) to remote into a system that you are using Wireshark to capture traffic, it is also smart to filter out RDP traf- fic using not tcp 3389. This is similar to the not tcp 22 filter (mentioned in Section 18.1) when performing tcpdumps from an SSH session. 18.2 Ethereal/Wireshark 61918.2 When you have had enough capturing, click the Stop button in the Capture Info dia- log window (if you have not disabled it), click on the Stop button on the toolbar (as shown in Figure 18-5), press Ctrl-E, or select Capture➝ Stop from the menu. If you are not already displaying in real-time during the capture, the different display panes now fill with packets and packet details. Figure 18-5. Stop Capture toolbar button Loading a Previously Created Capture If instead of capturing packets live on your system, you want to analyze a previously captured pcap, you can select File ➝ Open from the menu bar, press Ctrl-O, drag- and-drop a pcap file into an open Wireshark window, or just double-click on a pcap file to open it (if your system is configured to use Wireshark as your default pcap file handler). If it is an especially large pcap, a progress bar displays showing you how long it takes to load the entire pcap. I tend to avoid pcaps larger than 20 MB. Viewing a Capture Once you have a pcap in memory (either from performing a capture or from loading a file), you will see three different panes (by default, they are arranged top-to-bottom as Packet List, Packet Details, and Packet Bytes, which can be adjusted in the preferences). The Packet List pane at the top provides a list of all packets in memory; it should be quite colorful. This is where you select which packet to view the details of; click a line to select that packet for viewing. The Packet Details pane in the middle shows a tree-branch hierarchy of each layer of data in the selected packet. Clicking the + button expands the tree for that layer to show more details. Typical layers include the Frame, Ethernet, IP, TCP/UDP/ICMP, higher layer transports, and protocols. Wireshark supports FDDI, 802.11, 802.1Q, and other transports, but our example here shows the work with the most common traffic. The Packet Bytes pane at the bottom shows the raw packet bytes in both hexadeci- mal and ASCII. As you select different fields in the Packet Details pane, this bottom pane updates, highlighting where this field is in the raw bytes. The panes themselves 620 Chapter 18: Network Capture are resizable: hover your mouse over the partition between panes and the mouse cur- sor changes to a resize pointer, allowing you to drag the bar to your desired size. See Figure 18-6 for an example of a packet capture loaded in Wireshark.18.2 Figure 18-6. HTTP pcap loaded into Wireshark Take a look at Figure 18-6 for a bit—see how there is a bar highlighting a packet in the upper pane (packet 4)? The bar appears as light blue on the screen. This shows you which packet detail you see in the middle pane. Now look at the bar highlight- ing the GET / HTTP 1.1 line in the middle pane. This shows what is being selected for highlight in the bottom pane. The bottom pane shows the raw bytes from the packet, and the GET / HTTP 1.1 is highlighted in both hexadecimal (to the left) and ASCII text (to the right). Basic Wireshark Display Filters Wireshark analyzes each packet layer by layer and breaks out all kinds of useful information. Sometimes, there’s just too much information to see what we are look- ing for—the proverbial needle in the haystack. This is where the Wireshark Display Filters come in handy (i.e., the Filter bar underneath the button toolbar). Earlier ver- sions of Ethereal placed the Filter bar at the very bottom of the window (and in fact, you can move it back down there by changing a preferences parameter). The bar is color-coded to indicate when a properly formatted display filter has been set—red for error, green for valid. One quick way to set a display filter is to right-click on a TCP packet in the top dis- play and select Follow TCP Stream. This option creates an automatic display filter that isolates packets belonging to just this session, then pulls up a session display window. 18.2 Ethereal/Wireshark 62118.2 This session display window is extremely useful. By default, it opens in ASCII mode (which is useful for printable protocols such as HTTP, SMTP, FTP, and POP3). It displays client-side packets (the side that started the connection) in red and server- side packets in blue. In ASCII, EBCDIC, and Raw modes, it streams packet payloads together in a continuous stream, while in Hex Dump and C Arrays modes, it dis- plays each packet payload’s content as a separate element. See Figures 18-7 and 18-8 for examples. Figure 18-7. Follow TCP Stream window in ASCII mode As you can see from Figure 18-7, ASCII mode is especially useful at viewing print- able protocol stream contents. Looking back at the main packet-viewing window, you see this also generated a fil- ter similar to the following: (ip.addr eq and ip.addr eq and (tcp.port eq 80 and tcp.port eq 47438) Notice that the syntax for WDF is decidedly different than BPF. We can still use Boolean logic and even nesting, but there is also a sense of object model or structure here. You select a decoder as your base filter object and then use dots to select 622 Chapter 18: Network Capture18.2 Figure 18-8. Follow TCP Stream window in Hex Dump mode parameters from that decoder. In this case, the ip and tcp decoders are being lever- aged and we are checking the addr subparameter on the ip decoder as well as the port parameter on the tcp decoder. As new decoders are added, additional filter options are created. The ability to use add-on modules to expand its features is one of the powerful aspects of Wireshark. Another useful filter is http.request, which gives you all HTTP URLs. The following combination cleans out any non-IP traffic and ignores SSH and RDP: ip && (ssh tcp.port == 3389) In addition, nearly any decoded field can be turned into an instant filter. To do so, right-click a parameter, and drill-down a layer (for example, Hypertext Transfer Pro- tocol ➝ GET ➝ Request Method), and the menu appears (where we used Follow TCP Stream earlier); this time, note the “Apply as Filter” and “Prepare as Filter” options, which are shown in Figure 18-9. The difference between the two is that Apply as Filter creates and applies the new fil- ter, while Prepare as Filter simply creates the new filter without applying it. The ben- efit of this is if you are crafting a complicated or multistep filter against a very large pcap file, you do not want to apply each incremental filter as they are created, since it would refilter after each application, which could take time. Going into either of these submenus gives you additional menu options: Selected Replaces the existing filter with a filter that looks for the selected value in the selected parameter. 18.2 Ethereal/Wireshark 62318.2 Not Selected Replaces the existing filter with a filter that looks for anything except the selected value in the selected parameter. And Selected Appends to the existing filter an additional filter that looks for the selected value in the selected parameter with a Boolean AND; for example, both filters must match. Or Selected Appends to the existing filter an additional filter that looks for the selected value in the selected parameter with a Boolean OR; for example, either filter can match. And Not Selected Appends to the existing filter an additional filter that looks for anything except the selected value in the selected parameter with a Boolean AND; for example, both filters must match. Or Not Selected Appends to the existing filter an additional filter that looks for anything except the selected value in the selected parameter with a Boolean OR; for example, either filter can match. So by simply poking around your pcap, seeing things you want to see more of (or not see more of), and clicking and selecting appropriately, you can make some very com- plicated and powerful filters. Advanced Wireshark Display Filters As neat as selecting packet decoder parameters and creating filters that way are, your filter gets pretty messy after a while. To get a feel for all the parameters there are to use for filtering, take a look at the Wireshark Display Filter Expression Editor. To use this tool, click on the Expression… button of the Filter bar. Figure 18-10 shows the Wireshark Filter Expression window, which provides an alphabetical list of every single decoder module installed with your version of Wire- shark. The actual contents of this list may vary, depending on what modules you received with your build. From a quick glance, however, it is easy to see that the list is extensive. By clicking in the lefthand pane (that lists the decoders) and then typing the first few letters of the decoder name you are looking for, you’ll jump right to it. Drilling down into a decoder reveals all its parameters you can then use to filter on and what kinds of comparators that parameter supports, such as is present, ==, =, , , as well as any pre-defined values (for example, the ip decoder’s ip.tos.precedence parameter supports the well-known definitions of routine, priority, immediate, flash, flash override, CRITIC/ECP, internetwork control, and network control so you do not need to look up what those values would be in hexadecimal). 624 Chapter 18: Network Capture18.2 Figure 18-9. Apply as Filter Using this editor to craft a filter and clicking OK will insert the resulting filter code into your Filter bar (wherever the cursor was when you clicked the Expression… but- ton), but not apply it. If you wish to chain several of these together, you will have to do the appropriate Boolean relations (&& for AND, for OR) and the appropriate groupings with parenthesis. Saving Select Packets to Disk One of the handy things you can do once you’ve filtered your packets such as you want them is to save just those packets to disk. The interpacket timing is maintained. To do so, just choose File➝ Save As, which will bring up the Save As dialog box. This next step is important and typically forgotten. To save only those packets filtered by a dis- play filter, change the radio button at the bottom of the dialog from Captured to Dis- played. Finally, give the file a new name and click the Save button. Your new pcap file will have only those packets that were allowed by the display filter. 18.2 Ethereal/Wireshark 62518.2 Figure 18-10. Wireshark Filter Expression window Packet Colorization You may have noticed that the packet display pane can get quite colorful, and you may have wondered what those colors mean. Click on the Edit Coloring Rules tool- bar button shown in Figure 18-11 or choose View ➝ Coloring Rules to display the packet Coloring Rules window shown in Figure 18-12. Figure 18-11. Edit Coloring Rules toolbar button You’ll have to use your imagination for Figure 18-12, since the book is in black and white (or just fire up a copy of Wireshark, and this will make more sense). The color- ing rules use Wireshark Display Filters to colorize packets so they stand out from other packets. You can check what the colors mean in this window and either change the ordering, delete rules, or create your own rules. Use the tricks and techniques you learned in the previous Wireshark Display Filter sections to craft specific rules used for packet coloring. Overriding Default Protocol Decoders As shown earliier in the filtering discussion, Wireshark comes with a staggering amount of protocol decoder modules. These protocol decoder modules are bound to 626 Chapter 18: Network Capture

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.