<?xml version="1.0"?>
<Module projectID="1190" moduleID="1206">
	<ModuleName>mod2</ModuleName>
	<AU>mod2</AU>
	<Title>Sniffers</Title>
	<Subtitle>Sniffers</Subtitle>
	<LinkSet>links</LinkSet>
	<CourseMapSWFPath>../mod2/assets/coursemap.swf</CourseMapSWFPath>
	<NavBtns>
        <NavBtn>
			<ID>courseMenuBtn</ID>
			<Label>Course menu</Label>
			<RMAText>Course menu. Select this button to access the course menu.</RMAText>
			<ClickEventName>MainMenuButtonClicked</ClickEventName>
		</NavBtn> 	
		<NavBtn>
			<ID>moduleMapBtn</ID>
			<Label>Lesson Map</Label>
			<RMAText>Lesson Map.  Select this button to access the lesson map.</RMAText>
			<ClickEventName>CourseMapButtonClicked</ClickEventName>
		</NavBtn>
		<NavBtn>
			<ID>glossaryBtn</ID>
			<Name>Glossary</Name>
			<RMAText>Glossary. Select this button open the glossary.</RMAText> 
			<ClickEventName>GlossaryButtonClicked</ClickEventName>
		</NavBtn>
		<NavBtn>
			<ID>resourcesBtn</ID>
			<Label>Resources</Label>
			<RMAText>Resources. Select this button open the resources.</RMAText>
			<ClickEventName>ResourcesButtonClicked</ClickEventName>
		</NavBtn>
		<NavBtn>
			<ID>exitBtn</ID>
			<Label>Exit</Label>
			<RMAText>Exit.  Select this button to exit the course.</RMAText>
			<ClickEventName>ExitButtonClicked</ClickEventName>
		</NavBtn>
		<NavBtn>
			<ID>replayBtn</ID>
			<Label>Replay</Label>
			<RMAText>Replay. Select this button to replay the current screen.</RMAText>
			<ClickEventName>ReplayButtonClicked</ClickEventName>
		</NavBtn>
		<NavBtn>
			<ID>pauseBtn</ID>
			<Label>Pause</Label>
			<RMAText>Pause.  Select this button to pause the course.</RMAText>
			<ClickEventName>PauseButtonClicked</ClickEventName>
		</NavBtn>
		<NavBtn>
			<ID>resumeBtn</ID>
			<Label>Resume</Label>
			<RMAText>Resume. Select this button to resume the course.</RMAText>
			<ClickEventName>ResumeButtonClicked</ClickEventName>
		</NavBtn>
		<NavBtn prevBtn="true">
			<ID>previousPgBtn</ID>
			<Name>Previous Page</Name>
			<RMAText>Previous. Select this button to go to the previous screen.</RMAText>
			<ClickEventName>PreviousButtonClicked</ClickEventName>
		</NavBtn>
		<NavBtn nextBtn="true">
			<ID>nextPgBtn</ID>
			<Name>Next Page</Name>
			<RMAText>Next. Select this button to go to the next screen.</RMAText>
			<ClickEventName>NextButtonClicked</ClickEventName>
		</NavBtn>
	</NavBtns>
	<Topics>
		<Topic>
			<Title>Introduction</Title>
			<Subtitle/>
			<Pages>
				<Page>
					<Title>Objectives and Topics</Title>
					<Subtitle/>
					<Filename>idsal2_01</Filename>
					<PageNbr>1</PageNbr>
					<ShowText>
						<Txt frameNbr="1">Welcome to the lesson on sniffers. When you have completed this lesson, you will be able to describe what a sniffer is and how it works. You will also be able to identify some basic Berkeley Packet Filter, or BPF, filter constructs and some command-line options for command-line sniffers. Finally, you will be able to identify some strings you can use to analyze packet data. There are four topics in this lesson. After you have completed the introduction, you will learn what a sniffer is used for, about the two basic types of sniffers, and about three of the most commonly used command-line sniffers. Finally, you will learn the fundamentals of how sniffers work. This topic covers packet capture libraries, Berkeley Packet Filters, and strings. </Txt>
						<Txt frameNbr="1"/>
					</ShowText>
					
				<Sec508Data><ContentDescription frameNbr="1">For each screen you will hear a description. The description is cued by an audio tone. Listen to the description, and then select the play audio narration button to continue. Screen 1 of 11. Lesson title: Sniffers. Topic title: Introduction. Screen title: Objectives and Topics. Five lesson learning objectives display in support of audio. Four topics display. The first topic is titled Introduction. The second topic is titled What is a Sniffer? The third topic is titled How do Sniffers work? The fourth and final topic is titled Conclusion. A text box displays and states:  References to open source or freeware in this training product are for training purposes only, and should not be considered endorsements of these products. Please check with your command, service or agency for guidance on the use of these products.</ContentDescription></Sec508Data></Page>
			</Pages>
		</Topic>
		<Topic>
			<Title>What is a Sniffer?</Title>
			<Subtitle/>
			<Pages>
				<Page>
					<Title>Overview</Title>
					<Subtitle/>
					<Filename>idsal2_02</Filename>
					<PageNbr>2</PageNbr>
					<ShowText>
						<Txt frameNbr="1">Large computer networks communicate using a wide variety of protocols. This complexity requires tools that can monitor and troubleshoot network traffic. A network sniffer is a tool that listens to or &quot;sniffs&quot; the traffic traveling between networked devices. Also called a packet analyzer or protocol analyzer, a sniffer intercepts or &quot;captures&quot; raw data packets as they travel across the wire. Packet analysis can help you better understand what is happening on the network. A sniffer &quot;sees&quot; who is on the network who or what is utilizing bandwidth, and can help you identify possible attacks or malicious activity. The packet sniffing process can be broken down into three steps: collect, convert, and analyze. To accomplish the first step, collection, the sniffer requires putting the network interface into promiscuous mode. In promiscuous mode, the sniffer can &quot;see&quot; frames that aren't intended to be delivered to the system performing the sniffing. Typically, these frames would be ignored since they aren't destined for the system on which the sniffer is running. In the second step, the sniffer decodes the protocols and converts the data into a format you can read. The third and final step involves the actual analysis of the captured and converted data. Sniffers can correlate the corresponding layers of the OSI model. Take a few moments to review the information about network sniffers. Then we'll look at two types of sniffers more closely. </Txt>
						<Txt frameNbr="1"/>
					</ShowText>
					
				<Sec508Data><ContentDescription frameNbr="1">Screen 2 of 11. Topic title: What is a Sniffer? Screen title: Overview. Several workstation images appear with lines connecting them to create a matrix showing how the workstations are interconnected. Image changes to show only two workstations with two lines connecting them. A grid overlay displays between the workstations and over the connecting lines. Animation shows a circle moving along the lines from one workstation to the next. Cells within the grid fill in with different colors as the animated circles pass under the grid. Text displays in support of audio. A linear process diagram displays. The diagram has three components. Starting on the left, the first component is labeled collect. An arrow point from the first component to the second which is labeled Convert. An arrow points from the second to the third component which is labeled Analyze. Text displays in support of audio. A stack of seven boxes representing the seven layers of the Oh S Eye model displays. Starting at the bottom the layers are labeled: Physical, Data Link, Network, Transport, Session, Presentation and Application. The second through fourth layers become highlighted. These are the Data Link, Network and Transport layers. The top layer Application becomes highlighted. Bulleted text appears and states: Network Sniffers are tools that capture network traffic. They are also called network packet analyzers and network protocol analyzers. Sniffers collect raw data. This requires promiscuous mode access. Sniffers convert binary data into a readable form and understand and decode protocols. They analyze converted data packets and can see corresponding layers of On S Eye model. The text promiscuous mode access becomes a roll over which states: Putting an interface in promiscuous mode allows the system to capture frames that are not intended to be delivered to the system performing the sniffing. Typically, these frames are ignored since they are not destined for the system on which the sniffer is running. The acronym Oh S Eye becomes a rollover which states: Open Systems Interconnection. The data link layer of the Oh S Eye model becomes a rollover which states: A sniffer can see the Data Link Layer, which typically contains the Ethernet header. The Ethernet header identifies the source and destination MAC addresses of the devices communicating on the local network. The network layer in the Oh S Eye model becomes a rollover which states: A sniffer can see the Network Layer which typically contains Internet Protocol or Eye Pea headers. The Eye Pea header identifies the source and destination Eye Pea addresses. From this information, you can see if the sources are talking simply on a local switched network or to a remote network through routers. The transport layer in the Oh S Eye model becomes a rollover which states: A sniffer can look at the Transport layer where the Transmission Control Protocol, or T C P and User Datagram Protocol or U D P headers can be found. You can see which services are being used by looking at the source and destination port numbers. The application layer in the Oh S Eye model becomes a rollover which states: A sniffer can see the Application Layer, which can include headers indicating File Transfer Protocol or F T P, Hypertext Transfer Protocol or H T T P and Simple Mail Transfer Protocol or S M T P and other Application layer protocols.</ContentDescription></Sec508Data></Page>
				<Page>
					<Title>Two Types of Sniffers</Title>
					<Subtitle/>
					<Filename>idsal2_03</Filename>
					<PageNbr>3</PageNbr>
					<ShowText>
						<Txt frameNbr="1">There are a number of open source sniffers commonly used by network security administrators: Snort, tcpdump, WinDump, TShark, and Wireshark, to name a few. They are categorized as either a command-line sniffer or a GUI sniffer. Command-line sniffers like tcpdump and WinDump are basic sniffers that run quickly. The data captured can be interpreted only on a very basic level, leaving the majority of the analysis to you. For example, the contents of the data packets can be difficult to interpret because the sniffer only analyzes and displays, in the text output, some of the header fields. In the first line of proper output, &quot;172.16.1.1&quot; is the source IP address and dot 138 corresponds to the source port. The number &quot;172.16.255.255&quot; is the destination IP address and dot 138 corresponds to the destination port. The packet is UDP. This data doesn't show you that it's actually NetBIOS Name Service information being sent. You have to use a sniffer with advanced analysis capabilities in order to see the details of the NetBIOS Name Service protocol. On the positive side, the command-line sniffers can quickly write captured packets to a file for later analysis. And, because of their simplicity, they have a lower potential for vulnerabilities from coding errors, which is a security benefit. A GUI-based sniffer does much of the analysis for you. For example, Wireshark can help analyze a stream of packets to help detect intrusions. The header fields and payload data are analyzed by the sniffer. But because it's so complex, there is a higher potential for coding errors in the protocol analyzer. The resulting vulnerabilities may expose your system to compromise. So which type of sniffer should you use? A common approach is to capture packets with a command-line sniffer and write a packet capture file, then use a GUI-based sniffer to analyze the data. Next we'll look at three commonly used command-line sniffers. </Txt>
						<Txt frameNbr="1"/>
					</ShowText>
					
				<Sec508Data><ContentDescription frameNbr="1">Screen 3 of 11. Screen title: Two Types of Sniffers. Reprise of grid overlay between two workstations. Logos for open source sniffers display in support of audio. Two banners display. One banner is titled Command Line Interface or C L I Sniffer. The second banner is titled Graphical User Interface or gooey Sniffer. The Win Dump, T C P DUMP, T Shark and SNORT logos display under the command line banner. The Wireshark logo displays under the graphical user interface banner. An example of a command line data capture screen displays. Lines of data contain numerals, symbols and letters. An example of a Wireshark data capture screen displays. Bulleted text displays under the command line banner and states: Advantages: Available as open source, has fewer vulnerabilities, operates fairly quickly to capture packets and quickly writes data to a file for later analysis. Disadvantages: Shows only some header fields and requires knowledge of how to read packet data. Bulleted text displays under the gooey banner and states: Advantages: Available as open source, is capable of complex analysis of protocols, identifies header fields for intrusion detection and analyzes data payload. Disadvantages: is susceptible to coding errors. Each of the sniffer logos becomes a rollover. The rollover for the T C P DUMP logo states: T c p dump is an open source command line packet analyzer for Linux and U NIX systems. The rollover for the Win Dump logo states: Win Dump is an open source command line packet analyzer for Windows environments. The rollover for the SNORT logo states: Snort is an open source network intrusion detection and prevention system. It uses a command line format to display analysis results. The rollover for the T Shark logo states: T Shark is the command line version of Wireshark. It uses the packet capture filtering mechanism of t c p dump and has some of the analysis capabilities of Wireshark. The rollover for the Wireshark logo states: Wireshark is a free complex protocol analyzer that uses a graphical user interface or gooey to display analysis results. It can identify header fields for intrusion detection and analyze data payload. It was formerly known as Ethereal.</ContentDescription></Sec508Data></Page>
				<Page>
					<Title>Common Command-Line Sniffers</Title>
					<Subtitle/>
					<Filename>idsal2_04</Filename>
					<PageNbr>4</PageNbr>
					<ShowText>
						<Txt frameNbr="1">Tcpdump, WinDump, and Snort are three commonly used command-line sniffers. All three are open source. Tcpdump and WinDump are good basic sniffers, but they require an analyst with a thorough understanding of OSI and embedded protocols or higher level protocol analysis tools to perform most of the analysis. While Snort is classified as a command-line sniffer because of the way it presents data, it has greater analysis capabilities than tcpdump and WinDump. Select the sniffers for a brief description of each one. </Txt>
						<Txt frameNbr="1"/>
					</ShowText>
					<Popups>
						<Popup>
							<Title>Common Command-Line Sniffers</Title>
							<Subtitle/>
							<Filename>idsal2_04_01</Filename>
							<PageNbr>4</PageNbr>
							<ShowText>
								<Txt frameNbr="1"> Tcpdump and WinDump both read and write data packets traveling across the wire, but they provide limited protocol dissection. Tcpdump is the original command-line sniffer and is the default on most Linux and some UNIX systems. WinDump is the Windows version of tcpdump. </Txt>
								<Txt frameNbr="1"/>
							</ShowText>
							
						<Sec508TriggerName>TCPDUMP and WinDump</Sec508TriggerName><Sec508Data><ContentDescription frameNbr="1">Popup 1 of 2. Popup title: T C P DUMP and Win Dump. Reprise of T C P DUMP and Win Dump logos. Bulleted text displays in support of audio.



</ContentDescription></Sec508Data></Popup>
						<Popup>
							<Title>Common Command-Line Sniffers</Title>
							<Subtitle/>
							<Filename>idsal2_04_02</Filename>
							<PageNbr>4</PageNbr>
							<ShowText>
								<Txt frameNbr="1"> Snort has three main modes in which it can be configured: sniffer, packet logger, and network intrusion detection system. The sniffer mode simply reads the packets off the network and displays the data in a continuous stream on the console. The packet logger mode logs the packets to a disk. The network intrusion detection mode is the most complex and configurable option. It monitors all the traffic on a network to look for suspicious activity. The power of Snort, as an IDS, comes from its highly configurable detection engine and the flexible rule set used by that detection engine. The engine can filter packets, look for attack-signatures, and create an alert on a potential malicious event. The Snort IDS functionality can be configured with a combination of three detection methods: signature-based, anomaly-based, and protocol-based. </Txt>
								<Txt frameNbr="1"/>
							</ShowText>
							
						<Sec508TriggerName>SNORT</Sec508TriggerName><Sec508Data><ContentDescription frameNbr="1">Popup 2 of 2. Popup title: SNORT. Reprise of SNORT logo. Bulleted text displays in support of audio. The word signature based becomes a rollover which states: The signature based method of detection looks for specific patterns of an attack within the network traffic.Snort examines network traffic for particular patterns or characteristics that represent an attack. Because many attacks today have distinct signatures, the patterns are preconfigured by the I D S vendor or created by the analyst using the system. The word anomaly based becomes a rollover which states: The anomaly based method of detection looks for traffic activity that falls outside of normal traffic patterns. Snort samples current network traffic activity against the baseline in order to detect whether or not the traffic is within baseline parameters. The word protocol based becomes a rollover which states: The protocol based method of detection analyzes the protocol activity against standard protocol behaviors. Snort examines the behavior and state of a protocol in use by the system. For example, for a web server Snort would monitor the H T T P or H T T P S communications to determine if the protocol is being implemented and utilized properly as determined by protocol design specifications.</ContentDescription></Sec508Data></Popup>
					</Popups>
				<Sec508Data><ContentDescription frameNbr="1">Screen 4 of 11. Screen title: Common Command Line Sniffers. Reprise of T C P DUMP, Win Dump and SNORT logos. The T C P DUMP and Win Dump logos become selectable as a popup. The SNORT logo becomes selectable as a popup.

</ContentDescription></Sec508Data></Page>
			</Pages>
		</Topic>
		<Topic>
			<Title>How Do Sniffers Work?</Title>
			<Subtitle/>
			<Pages>
				<Page>
					<Title>Packet Capture Libraries</Title>
					<Subtitle/>
					<Filename>idsal2_05</Filename>
					<PageNbr>5</PageNbr>
					<ShowText>
						<Txt frameNbr="1">To capture raw network traffic, a sniffer uses a packet capture, or pcap, library as the framework for reading and writing data in a standard format. There are two primary pcap libraries - libpcap and WinPcap. Both are open source projects. Libpcap is the original library for packet capture. It's used by UNIX-like operating systems and is the pcap library used by tcpdump and most other sniffers on UNIX-like systems. WinPcap is the industry-standard pcap tool for Windows environments and is the pcap library used by WinDump and most other Windows based sniffers. By default, a sniffer will capture all traffic traveling across the wire. In a busy network, the data is voluminous and, if unfiltered, the data will scroll faster than you can read it. You can limit the amount of data captured by applying packet capture filters that specify search criteria for what type of data each library will &quot;read.&quot; Next you will learn about some basic filter expressions. </Txt>
						<Txt frameNbr="1"/>
					</ShowText>
					
				<Sec508Data><ContentDescription frameNbr="1">Screen 5 of 11. Topic title: How Does a Sniffer Work? Screen title: Packet Capture Libraries. Reprise of grid overlay between two workstations. A banner titled Packet Capture displays. The lib pea cap and win pea cap logos display. Bulleted text displays in support of audio. Each of the logos becomes a rollover. The lib pea cap rollover states: Lib pea cap is a portable C C plus plus packet capture library that provides the framework for reading and writing data in a standard format for t c p dump. It is used with U NIX like platforms. Lib pea cap is maintained by the T c p dump Group. For more information, access w w w dot t c p dump dot org. The win pea cap rollover states: Win pea cap provides the framework for reading and writing data in a standard format for Win Dump. It is based on the lib pea cap model and Berkeley Packet Filters for U NIX and runs on Win thirty two and Win sixty four platforms. Win pea cap is maintained by the Win pea cap Group. For more information, access w w w dot win pea cap dot org. The packet capture banner becomes a rollover which states: Pea cap provides the framework for sniffing packets and presents a raw packet in a standard binary file format. A raw packet is a packet that is left in its original, unmodified form as it traveled across the network from client to server.</ContentDescription></Sec508Data></Page>
				<Page>
					<Title>Berkeley Packet Filters</Title>
					<Subtitle/>
					<Filename>idsal2_06</Filename>
					<PageNbr>6</PageNbr>
					<ShowText>
						<Txt frameNbr="1">Libpcap and WinPcap implement BPFs. BPFs make it possible to narrow down the data a sniffer captures by allowing you to specify the types of packets to capture based on layer two through four header fields. Filter expressions are built from primitives, which are shortcuts for specifying desired contents of header fields. Select Primitives to see some commonly used shortcuts. </Txt>
						<Txt frameNbr="1"/>
					</ShowText>
					<Popups>
						<Popup>
							<Title>Berkeley Packet Filters</Title>
							<Subtitle/>
							<Filename>idsal2_06_01</Filename>
							<PageNbr>6</PageNbr>
							<ShowText>
								<Txt frameNbr="1"> Here are some common primitives you can use to instruct the sniffer to capture only specific packets. A primitive consists of an ID followed by a qualifier. The ID for the first primitive in the table is the word &quot;host&quot; followed by the qualifier, an IP address, or hostname, that specifies you want to filter for packets with a specific source or destination address. In contrast, the primitive &quot;src host 192.168.1.3&quot; filters packets with the specified source address and &quot;dst host 192.168.1.4&quot; filters packets with the specified destination address. Tcp captures only TCP packets. Udp captures only UDP packets. And, icmp captures only ICMP packets. Port 53 looks for TCP or UDP packets with the source or destination port of 53. Primitives can be combined with the logical operators &quot;and,&quot; &quot;not,&quot; and &quot;or&quot; to add another layer of filtering. In this example, &quot;host 192.168.1.5 and tcp and port 80&quot; the word &quot;and&quot; instructs the sniffer to capture all TCP port 80 packets going to and from the address. Using the words &quot;and&quot; and &quot;not&quot; together instructs the sniffer to look for all traffic that is going to or from the address, but not the ICMP traffic. In the example, &quot;port 80 or port 443&quot; the word &quot;or&quot; instructs the sniffer to capture either HTTP traffic traveling through port 80 or HTTPS traffic traveling through port 443.  </Txt>
								<Txt frameNbr="1"/>
							</ShowText>
							
						<Sec508TriggerName>Primitives</Sec508TriggerName><Sec508Data><ContentDescription frameNbr="1">Popup 1 of 1. Popup title: Primitives. Seven examples of primitive syntax display with an explanation of each primitive in support of audio. Text displays in support of audio. When the narrator talks about using the &quot;and&quot; and &quot;not&quot; logical operators in combination text displays and states: host one ninety two dot one sixty eight dot one dot five and not i c m p.</ContentDescription></Sec508Data></Popup>
					</Popups>
				<Sec508Data><ContentDescription frameNbr="1">Screen 6 of 11. Screen title: Berkeley Packet Filters. A diagram displays representing the flow of incoming I P traffic through a Berkeley Packet Filter or B P F. Two arrows point toward a screen that represents the B P F. The filtered traffic is represented by one arrow that moving away from the screen to an icon representing output packet data. Text displays and states: Packet capture and processing. Image of an individual data packet displays. Text displays in support of audio. The word primitives becomes selectable as a popup. Text displays in support of audio. The word primitives becomes selectable as a popup.</ContentDescription></Sec508Data></Page>
				<Page>
					<Title>Common Command-Line Options</Title>
					<Subtitle/>
					<Filename>idsal2_07</Filename>
					<PageNbr>7</PageNbr>
					<ShowText>
						<Txt frameNbr="1">In addition to specifying the types of packets to capture, there are command-line options or flags that you can use to narrow down and focus the output. Dash capital &quot;D&quot; will list the interfaces that you can sniff on and give a number for each interface. For UNIX, knowing the interface name is usually not too difficult. The name is fairly short and is usually &quot;e t h zero&quot; or &quot;e n zero.&quot; With Windows the interface names are based on the Globally Unique Identifier, or GUID, for each interface. These are 25 characters long. So, it will be easier to list the interfaces first and get the number for each when you want to specify which interface you want to sniff. The command-line option dash &quot;i&quot; and a number specifies the interface you want to sniff. If you do not specify an interface, you'll end up on some random interface that is unlikely to be the one you want to use. Dash &quot;n&quot; specifies &quot;don't resolve host,&quot; also known as DNS names. Dash &quot;s&quot; sets the snap length, the amount of data that is captured in bytes. Dash &quot;w&quot; and a filename writes the raw data to the file specified. This allows you to create a packet capture file, sometimes called a pcap file. You can read from a pcap file using dash &quot;r&quot; and the file name. Dash &quot;v&quot; indicates that you want to be verbose in displaying the data. Dash &quot;v v&quot; indicates to be even more verbose and decode more information about the packet. The additional information can help you better understand what is in the packet. Dash capital &quot;X&quot; displays the contents of the packet in hexadecimal format and the sniffer tries to interpret the data into ASCII to see if there is anything in plain text. You now know some of the common capture filters and command-line flags that can help you narrow down and focus sniffing. Next, we will look at a tool you can use to analyze packets. </Txt>
						<Txt frameNbr="1"/>
					</ShowText>
					
				<Sec508Data><ContentDescription frameNbr="1">Screen 7 of 11. Screen title: Common Command Line Options. Reprise of Berkeley Packet Filter diagram. Image of a workstation displays between the filter screen and the filtered I P traffic arrow. The workstation is labeled Command Line Options. Test and bulleted text displays in support of audio. The syntax dash n becomes a rollover which states: By default, most sniffers will attempt a reverse D N S lookup for all I P address unless the dash n is specified. If there is no D N S server or no response from the D N S server, this default behavior will slow displaying the sniffer output while the sniffer waits for the D N S lookup to time out. The syntax dash s becomes a rollover which states: The default snap length for most command line sniffers is either sixty eight or ninety four bytes, which in most cases is not enough to capture the entire packet. If you want to capture the entirety of every packet, specify the snap length as zero or dash s zero.</ContentDescription></Sec508Data></Page>
				<Page>
					<Title>Strings</Title>
					<Subtitle/>
					<Filename>idsal2_08</Filename>
					<PageNbr>8</PageNbr>
					<ShowText>
						<Txt frameNbr="1">A tool you can use during a first pass analysis of packet data is called &quot;strings.&quot; This tool searches binary pcap files looking for ASCII printable characters. By default, strings looks for a sequence of four or more printable characters ending with a nonprintable character such as a newline or null. The basic strings syntax is the word &quot;strings&quot; followed by an option of the minimum number of characters you want in the string. You'll typically want to use some number greater than four; otherwise you'll get a lot of noise from random ASCII strings that are in packet headers. Eight to twelve characters is a good value to produce useable results. The last part of the syntax is the name of the file or files you want to search. In this example, the text dash &quot;n&quot; with the number eight indicates we want strings to search for ASCII characters that have at least eight consecutive characters in the file named &quot;file one dot pcap.&quot; An additional tool you want to know about is &quot;more.&quot; More is a pagination tool that allows you to scroll downward through the output either one page or one line at a time. There is a similar tool called &quot;less&quot; that allows scrolling up or down in the text. In this example of strings output, 10 characters were specified as the minimum string of ASCII characters to search for. The search was piped through &quot;more&quot; to allow the viewer to page through the output. We can see some NetBIOS Name Service type strings identifiable by the all capital letter strings. In the bottom half of the example, we see the text &quot;This program cannot be run in DOS mode.&quot; It looks like some executable file was captured in this pcap. This gives you a clue of what to look for as you begin your analysis of the pcap file. In a nutshell, &quot;strings&quot; is a quick method to do a triage of what is in a packet capture. You can use the utility to identify suspicious traffic or start a &quot;dirty&quot; word list search. One final thing about strings you should know is that a strings tool is not, by default, available on Windows systems. You can download a version of strings from the Microsoft Sysinternals website that allows strings to run on a Windows system when you are performing an analysis. </Txt>
						<Txt frameNbr="1"/>
					</ShowText>
					
				<Sec508Data><ContentDescription frameNbr="1">Screen 8 of 11. Screen title: Strings. An example of packet capture data in a strings output screen displays. Animation shows magnifying glass moving across the data screen. Text displays in support of audio. An example of strings syntax displays and states: strings dash n eight file one dot pea cap. At the end of the example the vertical bar symbol and the word more displays. Reprise of string output screen. At the top of the data is the string syntax used to filter the data. The syntax states: strings dash n ten lab four dash one dot pea cap vertical bar more.</ContentDescription></Sec508Data></Page>
				<Page>
					<Title>Knowledge Check</Title>
					<Subtitle/>
					<Filename>idsal2_09</Filename>
					<PageNbr>9</PageNbr>
					<PageType>Knowledge Check</PageType>
					<AttemptCountLimit>1</AttemptCountLimit>
					<DfltQuestionWidth>500</DfltQuestionWidth>
					<DfltFBWidth>550</DfltFBWidth>
					<Questions>
						<Question qType="MC">
							<Txt>Berkeley Packet Filters allow you to specify the types of packets to capture based on layer two through four header fields.</Txt>
							<Response valid="true">
								<Txt>True, for statement: Berkeley Packet Filters allow you to specify the types of packets to capture based on layer two through four header fields</Txt>
							</Response>
							<Response>
								<Txt>False, for statement: Berkeley Packet Filters allow you to specify the types of packets to capture based on layer two through four header fields</Txt>
							</Response>
							<Feedback>
								<DfltCorrect>Correct. Berkeley Packet Filters (BPFs) make it possible to narrow down the data a sniffer captures based on OSI layers two through four header fields. BPFs are created from a filter expression called a primitive.</DfltCorrect>
								<DfltIncorrect>Incorrect. Berkeley Packet Filters (BPFs) make it possible to narrow down the data a sniffer captures based on OSI layers two through four header fields. BPFs are created from a filter expression called a primitive.</DfltIncorrect>
							</Feedback>
						</Question>
						
						<Question qType="MC">
							<Txt>By default, strings looks for a sequence of four or more printable characters ending with a nonprintable character such as newline or null.</Txt>
							<Response valid="true">
								<Txt>True, for statement: By default, strings looks for a sequence of four or more printable characters ending with a nonprintable character such as newline or null.</Txt>
							</Response>
							<Response>
								<Txt>False, for statement: By default, strings looks for a sequence of four or more printable characters ending with a nonprintable character such as newline or null.</Txt>
							</Response>
							<Feedback>
								<DfltCorrect>Correct. Strings search binary packet capture (pcap) files looking for ASCII printable characters.</DfltCorrect>
								<DfltIncorrect>Incorrect. Strings search binary packet capture (pcap) files looking for ASCII printable characters.</DfltIncorrect>
							</Feedback>
						</Question>
						
						<Question qType="MC">
							<Txt>Libpcap provides the framework for reading and writing packet data in a standard format for tcpdump.</Txt>
							<Response valid="true">
								<Txt>True, for statement: Libpcap provides the framework for reading and writing packet data in a standard format for tcpdump.</Txt>
							</Response>
							<Response>
								<Txt>False, for statement: Libpcap provides the framework for reading and writing packet data in a standard format for tcpdump.</Txt>
							</Response>
							<Feedback>
								<DfltCorrect>Correct. Libpcap is the packet capture (pcap) library used by tcpdump and most other sniffers on UNIX-like systems.</DfltCorrect>
								<DfltIncorrect>Incorrect. Libpcap is the packet capture (pcap) library used by tcpdump and most other sniffers on UNIX-like systems.</DfltIncorrect>
							</Feedback>
						</Question>
						
						<Question qType="MC">
							<Txt>The &quot;more&quot; tool allows scrolling downward through the output either one page or one line at a time.</Txt>
							<Response valid="true">
								<Txt>True, for statement: The &quot;more&quot; tool allows scrolling downward through the output either one page or one line at a time.</Txt>
							</Response>
							<Response>
								<Txt>False, for statement: The &quot;more&quot; tool allows scrolling downward through the output either one page or one line at a time.</Txt>
							</Response>
							<Feedback>
								<DfltCorrect>Correct. The word &quot;more&quot; in a strings expression is a pagination tool that allows you to scroll downward through the output either one page or one line at a time.</DfltCorrect>
								<DfltIncorrect>Incorrect. The word &quot;more&quot; in a strings expression is a pagination tool that allows you to scroll downward through the output either one page or one line at a time.</DfltIncorrect>
							</Feedback>
						</Question>
					</Questions>
					<ShowText>
						<Txt frameNbr="1">Now check your knowledge of the packet capture fundamentals. </Txt>
						<Txt frameNbr="1"/>
					</ShowText>
					
				<Sec508Data><ContentDescription frameNbr="1">Screen 9 of 11. Screen title: Knowledge Check. This knowledge check presents four questions. For each question there are two possible answers, true or false. Use your keyboard to cycle through the options.</ContentDescription></Sec508Data></Page>
				<Page>
					<Title>Knowledge Check</Title>
					<Subtitle/>
					<Filename>idsal2_10</Filename>
					<PageNbr>10</PageNbr>
					<PageType>Knowledge Check</PageType>
					<AttemptCountLimit>1</AttemptCountLimit>
					<DfltQuestionWidth>500</DfltQuestionWidth>
					<DfltFBWidth>550</DfltFBWidth>
					<Questions>
					
						<Question qType="MC">
							<Txt>Set snap length</Txt>
							
							<Response>
								<Txt>-D, for statement: Set snap length</Txt>
							</Response>
							<Response>
								<Txt>-i#, for statement: Set snap length</Txt>
							</Response>
							<Response>
								<Txt>-n, for statement: Set snap length</Txt>
							</Response>
							<Response>
								<Txt>-r, for statement: Set snap length</Txt>
							</Response>
							<Response valid="true">
								<Txt>-s, for statement: Set snap length</Txt>
							</Response>
							<Response>
								<Txt>-v, for statement: Set snap length</Txt>
							</Response>
							<Response>
								<Txt>-vv, for statement: Set snap length</Txt>
							</Response>
							<Response>
								<Txt>-w, for statement: Set snap length</Txt>
							</Response>
							<Response>
								<Txt>-X, for statement: Set snap length</Txt>
							</Response>
														
							<Feedback>
								<DfltCorrect>Correct. The option -s sets the snap length.</DfltCorrect>
								<DfltIncorrect>Incorrect. The option -s sets the snap length.</DfltIncorrect>
							</Feedback>
						</Question>
						
						<Question qType="MC">
							<Txt>List available interfaces</Txt>
							
							<Response valid="true">
								<Txt>-D, for statement: List available interfaces</Txt>
							</Response>
							<Response>
								<Txt>-i#, for statement: List available interfaces</Txt>
							</Response>
							<Response>
								<Txt>-n, for statement: List available interfaces</Txt>
							</Response>
							<Response>
								<Txt>-r, for statement: List available interfaces</Txt>
							</Response>
							<Response>
								<Txt>-s, for statement: List available interfaces</Txt>
							</Response>
							<Response>
								<Txt>-v, for statement: List available interfaces</Txt>
							</Response>
							<Response>
								<Txt>-vv, for statement: List available interfaces</Txt>
							</Response>
							<Response>
								<Txt>-w, for statement: List available interfaces</Txt>
							</Response>
							<Response>
								<Txt>-X, for statement: List available interfaces</Txt>
							</Response>
														
							<Feedback>
								<DfltCorrect>Correct. The option -D instructs the sniffer to list the available interfaces.</DfltCorrect>
								<DfltIncorrect>Incorrect. The option -D instructs the sniffer to list the available interfaces.</DfltIncorrect>
							</Feedback>
						</Question>
						
						<Question qType="MC">
							<Txt>Write data to a pcap file</Txt>
							
							<Response>
								<Txt>-D, for statement: Write data to a pcap file</Txt>
							</Response>
							<Response>
								<Txt>-i#, for statement: Write data to a pcap file</Txt>
							</Response>
							<Response>
								<Txt>-n, for statement: Write data to a pcap file</Txt>
							</Response>
							<Response>
								<Txt>-r, for statement: Write data to a pcap file</Txt>
							</Response>
							<Response>
								<Txt>-s, for statement: Write data to a pcap file</Txt>
							</Response>
							<Response>
								<Txt>-v, for statement: Write data to a pcap file</Txt>
							</Response>
							<Response>
								<Txt>-vv, for statement: Write data to a pcap file</Txt>
							</Response>
							<Response valid="true">
								<Txt>-w, for statement: Write data to a pcap file</Txt>
							</Response>
							<Response>
								<Txt>-X, for statement: Write data to a pcap file</Txt>
							</Response>
														
							<Feedback>
								<DfltCorrect>Correct. The option -w followed by a file name indicates where to write pcap files.</DfltCorrect>
								<DfltIncorrect>Incorrect. The option -w followed by a file name indicates where to write pcap files.</DfltIncorrect>
							</Feedback>
						</Question>
						
						<Question qType="MC">
							<Txt>Be verbose when printing</Txt>
							
							<Response>
								<Txt>-D, for statement: Be verbose when printing</Txt>
							</Response>
							<Response>
								<Txt>-i#, for statement: Be verbose when printing</Txt>
							</Response>
							<Response>
								<Txt>-n, for statement: Be verbose when printing</Txt>
							</Response>
							<Response>
								<Txt>-r, for statement: Be verbose when printing</Txt>
							</Response>
							<Response>
								<Txt>-s, for statement: Be verbose when printing</Txt>
							</Response>
							<Response valid="true">
								<Txt>-v, for statement: Be verbose when printing</Txt>
							</Response>
							<Response>
								<Txt>-vv, for statement: Be verbose when printing</Txt>
							</Response>
							<Response>
								<Txt>-w, for statement: Be verbose when printing</Txt>
							</Response>
							<Response>
								<Txt>-X, for statement: Be verbose when printing</Txt>
							</Response>
														
							<Feedback>
								<DfltCorrect>Correct. The option -v indicates to be verbose when printing to the screen.</DfltCorrect>
								<DfltIncorrect>Incorrect. The option -v indicates to be verbose when printing to the screen.</DfltIncorrect>
							</Feedback>
						</Question>
						
						<Question qType="MC">
							<Txt>Do not resolve host names</Txt>
							
							<Response>
								<Txt>-D, for statement: Do not resolve host names</Txt>
							</Response>
							<Response>
								<Txt>-i#, for statement: Do not resolve host names</Txt>
							</Response>
							<Response valid="true">
								<Txt>-n, for statement: Do not resolve host names</Txt>
							</Response>
							<Response>
								<Txt>-r, for statement: Do not resolve host names</Txt>
							</Response>
							<Response>
								<Txt>-s, for statement: Do not resolve host names</Txt>
							</Response>
							<Response>
								<Txt>-v, for statement: Do not resolve host names</Txt>
							</Response>
							<Response>
								<Txt>-vv, for statement: Do not resolve host names</Txt>
							</Response>
							<Response>
								<Txt>-w, for statement: Do not resolve host names</Txt>
							</Response>
							<Response>
								<Txt>-X, for statement: Do not resolve host names</Txt>
							</Response>
														
							<Feedback>
								<DfltCorrect>Correct. The option -n instructs the sniffer to NOT resolve host (DNS names).</DfltCorrect>
								<DfltIncorrect>Incorrect. The option -n instructs the sniffer to NOT resolve host (DNS names).</DfltIncorrect>
							</Feedback>
						</Question>
						
						<Question qType="MC">
							<Txt>Print data in hexadecimal and ASCII</Txt>
							
							<Response>
								<Txt>-D, for statement: Print data in hexadecimal and ASCII</Txt>
							</Response>
							<Response>
								<Txt>-i#, for statement: Print data in hexadecimal and ASCII</Txt>
							</Response>
							<Response>
								<Txt>-n, for statement: Print data in hexadecimal and ASCII</Txt>
							</Response>
							<Response>
								<Txt>-r, for statement: Print data in hexadecimal and ASCII</Txt>
							</Response>
							<Response>
								<Txt>-s, for statement: Print data in hexadecimal and ASCII</Txt>
							</Response>
							<Response>
								<Txt>-v, for statement: Print data in hexadecimal and ASCII</Txt>
							</Response>
							<Response>
								<Txt>-vv, for statement: Print data in hexadecimal and ASCII</Txt>
							</Response>
							<Response>
								<Txt>-w, for statement: Print data in hexadecimal and ASCII</Txt>
							</Response>
							<Response valid="true">
								<Txt>-X, for statement: Print data in hexadecimal and ASCII</Txt>
							</Response>
														
							<Feedback>
								<DfltCorrect>Correct. The option -X instructs the sniffer to print data in hexadecimal and ASCII.</DfltCorrect>
								<DfltIncorrect>Incorrect. The option -X instructs the sniffer to print data in hexadecimal and ASCII.</DfltIncorrect>
							</Feedback>
						</Question>
						
					</Questions>
					<ShowText>
						<Txt frameNbr="1">Now check your knowledge of tcpdump command-line options for capturing packet data. </Txt>
						<Txt frameNbr="1"/>
					</ShowText>
					
				<Sec508Data><ContentDescription frameNbr="1">Screen 10 of 11. Screen title: Knowledge Check. This matching knowledge check presents six statements and nine command line options. For each statement select the command line option this is described. Moving for left to right the options are dash capital D, dash i and number symbol, dash n, dash r, dash s, dash v, dash v v, dash w, and dash capital X. Use your keyboard to cycle through the options.</ContentDescription></Sec508Data></Page>
			</Pages>
		</Topic>
		<Topic>
			<Title>Conclusion</Title>
			<Subtitle/>
			<Pages>
				<Page>
					<Title>Summary and Conclusion</Title>
					<Subtitle/>
					<Filename>idsal2_11</Filename>
					<PageNbr>11</PageNbr>
					<ShowText>
						<Txt frameNbr="1">Congratulations! You have completed the Sniffers lesson. You should now be able to describe what a sniffer is and how it works. You should also be able to identify some basic BPF filter constructs and some command-line options for command-line sniffers. Finally, you should be able to identify some strings you can use to analyze packet data. </Txt>
						<Txt frameNbr="1"/>
					</ShowText>
					
				<Sec508Data><ContentDescription frameNbr="1">Screen 11 of 11. Topic title: Conclusion. Screen title: Summary and Conclusion. The word Congratulations appears in large text. Text and bullet points display lesson objectives. Bullet points turn into checkmarks in synch with audio.



</ContentDescription></Sec508Data></Page>
			</Pages>
		</Topic>
	</Topics>
</Module>
