wireshark练习及答案lab-dns.doc
Wireshark_ICMP实验题目_v6.0
© 2005-21012, J.F Kurose and K.W. Ross, All Rights ReservedWireshark Lab: ICMP v6.0Supplement to Computer Networking: A Top-DownApproach, 6th ed., J.F. Kurose and K.W. Ross“Tell me and I forget. Show me and I remember. Involve me and Iunderstand.” Chinese proverbIn this lab, we’ll explore several aspects of the ICMP protocol:• ICMP messages generating by the Ping program;• ICMP messages generated by the Traceroute program;• the format and contents of an ICMP message.1 References to figures and sections are for the 6thedition of our text, Computer Networks, A Top-downApproach, 6th ed., J.F. Kurose and K.W. Ross, Addison-Wesley/Pearson, 2012. 2 If you are unable to runWireshark live on a computer, you can download the zip file /wireshark-labs/wireshark-traces.zip and extract the file ICMP-ethereal-trace-1. The traces in this zip file were collected by Wireshark running on one of the author’s computers, while performing the steps indicated in the Wireshark lab. Once you have downloaded the trace, you can load it into Wireshark and view the trace using the File pull down menu, choosing Open , and then selecting the ICMP-ethereal-trace-1 trace file. You can then use this trace file to answer the questions below.Before attacking this lab, you’re encouraged to rev iew the ICMP material in section 4.4.3 of the text 1. We present this lab in the context of the Microsoft Windows operating system. However, it is straightforward to translate the lab to a Unix or Linux environment. 1. ICMP and PingLet’s begin our ICMP a dventure by capturing the packets generated by the Ping program. You may recall that the Ping program is simple tool that allows anyone (for example, a network administrator) to verify if a host is live or not. The Ping program in the source host sends a packet to the target IP address; if the target is live, the Ping program in the target host responds by sending a packet back to the source host. As you might have guessed (given that this lab is about ICMP), both of these Ping packets are ICMP packets.Do the following 2:•Let’s begin this adventure by opening the Windows Command Prompt application (which can be found in your Accessories folder).•Start up the Wireshark packet sniffer, and begin Wireshark packet capture.•The ping command is in c:\windows\system32, so type either “ping –n 10 hostname” or “c:\windows\system32\ping –n 10 hostname” in the MS-DOS command line (withoutquotation marks), where hostname is a host on another continent. If you’re outside of Asia,you may want to enter t.hk for the Web server at Hong Kong University of Scienceand Technology. The argument “-n 10” indicates that 10 ping messages should be sent. Then run the Ping program by typing return.•When the Ping program terminates, stop the packet capture in Wireshark.At the end of the experiment, your Command Prompt Window should look something like Figure 1. In this example, the source ping program is in Massachusetts and the destination Ping program is in Hong Kong. From this window we see that the source ping program sent 10 query packets and received 10 responses. Note also that for each response, the source calculates the round-trip time (RTT), which for the 10 packets is on average 375 msec.Figure 1 Command Prompt window after entering Ping command.Figure 2 provides a screenshot of the Wireshark output, after “icmp” has been entered into the filter display window. Note that the packet listing shows 20 packets: the 10 Ping queries sent by the source and the 10 Ping responses received by the s ource. Also note that the source’s IP address is a private address (behind a NAT) of the form 192.168/12; the destination’s IP address is that of the Web server at HKUST. Now let’s zoom in onthe first packet (sent by the client); in the figure below, the packet contents area provides information about this packet. We see that the IP datagram within this packet has protocol number 01, which is the protocol number for ICMP. This means that the payload of the IP datagram is an ICMP packet.Figure 2 Wireshark output for Ping program with Internet Protocol expanded.Figure 3 focuses on the same ICMP but has expanded the ICMP protocol information in the packet contents window. Observe that this ICMP packet is of Type 8 and Code 0 -a so-called ICMP “echo request” packet. (See Figure 4.23 of text.) Also note that this ICMP packet contains a checksum, an identifier, and a sequence number.Figure 3 Wireshark capture of ping packet with ICMP packet expanded.What to Hand In:You should hand in a screen shot of the Command Prompt window similar to Figure 1 above. Whenever possible, when answering a question below, you should hand in a printout of the packet(s) within the trace that you used to answer the question asked. Annotate the printout3 to explain your answer. To print a packet, use File->Print, choose Selected packet only, choose Packet summary line, and select the minimum amount of packet detail that you need to answer the question.You should answer the following questions:3 What do we mean by “annotate”? If you hand in a paper copy, please highlight where in the printout you’ve found the answer and add some text (preferably with a colored pen) noting what you found in what you ‘ve highlight. If you hand in an elect ronic copy, it would be great if you could also highlight and annotate.1.What is the IP address of your host? What is the IP address of the destination host?2.Why is it that an ICMP packet does not have source and destination port numbers?3.Examine one of the ping request packets sent by your host. What are the ICMP type and codenumbers? What other fields does this ICMP packet have? How many bytes are the checksum, sequence number and identifier fields?4.Examine the corresponding ping reply packet. What are the ICMP type and code numbers?What other fields does this ICMP packet have? How many bytes are the checksum, sequence number and identifier fields?2. ICMP and TracerouteLet’s now continue our ICM P adventure by capturing the packets generated by the Traceroute program. You may recall that the Traceroute program can be used to figure out the path a packet takes from source to destination. Traceroute is discussed in Section1.4 and in Section 4.4 of the text.Traceroute is implemented in different ways in Unix/Linux/MacOS and in Windows. In Unix/Linux, the source sends a series of UDP packets to the target destination using an unlikely destination port number; in Windows, the source sends a series of ICMP packets to the target destination. For both operating systems, the program sends the first packet with TTL=1, the second packet with TTL=2, and so on. Recall that a router will decrement a packet’s TTL value as the packet passes through the router. When a packet arrives at a router with TTL=1, the router sends an ICMP error packet back to the source. In the following, we’ll use the native Windows tracert program. A shareware version of a much nice Windows Traceroute program is pingplotter (). We’ll use pingplotter in our Wireshark IP lab since it provides additional functionality that we’ll need there.Do the following4:•Let’s begin by opening the Windows Command Prompt application (which can be found in your Accessories folder).•Start up the Wireshark packet sniffer, and begin Wireshark packet capture.•The tracert command is in c:\windows\system32, so type either “tracert hostname” or “c:\windows\system32\tracert hostname” in the MS-DOS command line (without quotationmarks), where hostname is a host on another continent.4If you are unable to run Wireshark live on a computer, you can download the zip file/wireshark-labs/wireshark-traces.zip and extract the file ICMP-ethereal-trace-2. The traces in this zip file were collected by Wireshark running on one of the author’s computers, while performing the steps indicated in the Wireshark lab. Once you have downloaded the trace, you can load it into Wireshark and view thetrace using the File pull down menu, choosing Open, and then selecting the ICMP-ethereal-trace-2 trace file. You can then use this trace file to answer the questions below.(Note that on a Windows machine, the command is “tracert” and not “traceroute”.) Ifyou’re outside of Europe, you may want to enter www.inria.fr for the Web server atINRIA, a computer science research institute in France. Then run the Traceroute programby typing return.•When the Traceroute program terminates, stop packet capture in Wireshark.At the end of the experiment, your Command Prompt Window should look something like Figure 4. In this figure, the client Traceroute program is in Massachusetts and the target destination is in France. From this figure we see that for each TTL value, the source program sends three probe packets. Traceroute displays the RTTs for each of the probe packets, as well as the IP address (and possibly the name) of the router that returned the ICMP TTL-exceeded message.Figure 4 Command Prompt window displays the results of the Traceroute program.Figure 5 displays the Wireshark window for an ICMP packet returned by a router. Note that this ICMP error packet contains many more fields than the Ping ICMP messages.Figure 5 Wireshark window of ICMP fields expanded for one ICMP error packet.What to Hand In:For this part of the lab, you should hand in a screen shot of the Command Prompt window. Whenever possible, when answering a question below, you should hand in a printout of the packet(s) within the trace that you used to answer the question asked. Annotate the printout to explain your answer. To print a packet, use File->Print, choose Selected packet only, choose Packet summary line, and select the minimum amount of packet detail that you need to answer the question.Answer the following questions:5.What is the IP address of your host? What is the IP address of the target destination host?6.If ICMP sent UDP packets instead (as in Unix/Linux), would the IP protocol number still be01 for the probe packets? If not, what would it be?7.Examine the ICMP echo packet in your screenshot. Is this different from the ICMP pingquery packets in the first half of this lab? If yes, how so?8.Examine the ICMP error packet in your screenshot. It has more fields than the ICMP echopacket. What is included in those fields?9.Examine the last three ICMP packets received by the source host. How are these packetsdifferent from the ICMP error packets? Why are they different?10.Within the tracert measurements, is there a link whose delay is significantly longer thanothers? Refer to the screenshot in Figure 4, is there a link whose delay is significantlylonger than others? On the basis of the router names, can you guess the location of the tworouters on the end of this link?3. Extra CreditFor one of the programming assignments you created a UDP client ping program. This ping program, unlike the standard ping program, sends UDP probe packets rather than ICMP probe packets. Use the client program to send a UDP packet with an unusual destination port number to some live host. At the same time, use Wireshark to capture any response from the target host. Provide aWireshark screenshot for the response as well as an analysis of the response.。
wireshark题目
以下是一些可能的Wireshark题目及其解答示例：1. 题目： 如何使用Wireshark捕获网络流量？解答：- 打开Wireshark应用程序。
- 在顶部菜单栏中选择 "Capture"，然后选择 "Interfaces"。
- 在弹出的窗口中，选择你要捕获流量的网络接口。
- 点击 "Start" 开始捕获流量。
- 在捕获过程中，你可以暂停或停止捕获，也可以应用过滤器来筛选特定的流量。
- 捕获完成后，可以选择保存捕获的数据包以便后续分析。
2. 题目： 如何在Wireshark中过滤HTTP流量？解答：- 在Wireshark的主界面，点击顶部菜单栏的 "Filter"，然后选择 "Apply a display filter..."。
- 在显示过滤器输入框中输入 "http"，然后按回车键。
- 这样Wireshark就会只显示HTTP协议的相关数据包。
3. 题目： 如何在Wireshark中查找特定的字符串？解答：- 在Wireshark的主界面，点击顶部菜单栏的 "Edit"，然后选择 "Find Packet..."。
- 在弹出的查找窗口中，选择 "String" 或 "Bytes"，然后在搜索框中输入你要查找的字符串。
- 可以选择搜索的方向（向上或向下）和匹配的模式（精确匹配、包含匹配等）。
- 点击 "Find" 开始搜索，Wireshark会高亮显示匹配到的数据包。
4. 题目： 如何在Wireshark中分析TCP三次握手过程？解答：- 使用Wireshark捕获网络流量。
- 应用显示过滤器 "tcp.flags.syn == 1" 来只显示TCP SYN标志设置为1的数据包，这些数据包通常是TCP三次握手的第一步。
wireshark实验一答案
wireshark实验⼀答案1.What is the IP address and TCP port number used by the clientcomputer (source) that is transferring the file to /doc/8d460b7e8e9951e79b892738.html ?Ip address 192.168.1.36TCP port number：19572.What is the IP address of /doc/8d460b7e8e9951e79b892738.html ? On what port numberis it sending and receiving TCP segments for this connection?the IP address of /doc/8d460b7e8e9951e79b892738.html ：128.119.245.12port number：803.What is the sequence number of the TCP SYN segment that is usedto initiate the TCP connection between the client computer and /doc/8d460b7e8e9951e79b892738.html What is it in the segment that identifies the segment as a SYN segmentsequence number:0syn 被设置为1说明是syn段4.What is the sequence number of the SYNACK segment sent bygaia.cs.umass.ed to the client computer in reply to the SYN? What is the value of the ACKnowledgement field in the SYNACK segment?How did /doc/8d460b7e8e9951e79b892738.html determine that value? What is it in the segment that identifies the segment as a SYNACK segment?The sequence number of the SYNACK segment sent by /doc/8d460b7e8e9951e79b892738.html is:0 SYNACK segment 中ACKnowledgement 的值为1；ACKnowledgement number的值为SYN消息中sequencenumber加上1所得；SYN 和Acknowledgement f都置为1说明这是⼀个SYNACK segment.5.What is the sequence number of the TCP segment containing theHTTP POST command?第11号报⽂段是包含HTTP POST 命令的TCP segment。
WiresharkLabHTTPv6.1答案
卓越计Y111欧晓强2011004030581. Is your browser running HTTP version 1.0 or 1.1? What version of HTTP is the server running? 答：2. What languages (if any) does your browser indicate that it can accept to the server?答：3. What is the IP address of your computer? Of the server?答：本机IP地址：172.17.171.204，服务器IP地址：128.119.245.124. What is the status code returned from the server to your browser?答：5. When was the HTML file that you are retrieving last modified at the server?答：6. How many bytes of content are being returned to your browser?答：7. By inspecting the raw data in the packet content window, do you see any headers within the data that are not displayed in the packet-listing window? If so, name one.答：没有。
8. Inspect the contents of the first HTTP GET request from your browser to theserver. Do you see an “IF-MODIFIED-SINCE” line in the HTTP GET?答：没有看到。
wireshark练习及答案lab-protocol-layers
Lab Exercise – Protocol LayersObjectiveTo learn how protocols and layering are represented in packets. They are key concepts for structuring networks that are covered in the text.The trace for this lab is here:/~kevin/com320/labs/wireshark/trace-protocol-layers.pcap(although the main trace you will look at is from a site you pick such as in the exam-ples which follow).RequirementsWireshark: This lab uses the Wireshark software tool to capture and examine a packet trace. A packet trace is a record of traffic at a location on the network, as if a snapshot was taken of all the bits that passed across a particular wire. The packet trace records a timestamp for each packet, along with the bits that make up the packet, from the lower-layer headers to the higher-layer contents. Wireshark runs on most operating systems, including Windows, Mac and Linux. It provides a graphical UI that shows the sequence of packets and the meaning of the bits when interpreted as protocol headers and data. It col-or-codes packets by their type, and has various ways to filter and analyze packets to let you investigate the behavior of network protocols. Wireshark is widely used to troubleshoot networks. You can down-load it from for your personal computer. It is an ideal packet analyzer for our labs –it is stable, has a large user base and well-documented support that includes a user-guide /docs/wsug_html_chunked), and a detailed FAQ, rich functionality that in-cludes the capability to analyze hundreds of protocols, and a well-designed user interface. It operates in computers using Ethernet, serial (PPP and SLIP), 802.11 wireless LANs, and many other link-layer tech-nologies (if the OS on which it is running allows Wireshark to do so). It is already installed in the labs.A quick help guide to Wireshark display filters is here: /wireshark_filters.php Wireshark is a c ore tool for any wireless ‘man in the middle’ or similar snooping attack. It is simply in-dispensable for those who wish to examine packets being transferred over a network –good or bad…..Wireshark & Packet Sniffing BackgroundThe basic tool for observing the messages exchanged between executing protocol entities is called a packet sniffer. As the name suggests, a packet sniffer captures (“sniffs”) messages being sent/received from/by your computer; it will also typically store and/or display the contents of the various protocol fields in these captured messages. A packet sniffer itself is passive. It observes messages being sent and received by applications and protocols running on your computer, but never sends packets itself. Simi-larly, received packets are never explicitly addressed to the packet sniffer. Instead, a packet sniffer re-ceives a copy of packets that are sent/received from/by application and protocols executing on your machine.Figure 1 shows the structure of a packet sniffer. At the right of Figure 1 are the protocols (in this case, Internet protocols) and applications (such as a web browser or ftp client) that normally run on your computer. The packet sniffer, shown within the dashed rectangle in Figure 1 is an addition to the usual software in your computer, and consists of two parts. The packet capture library receives a copy of eve-ry link-layer frame that is sent from or received by your computer. Messages exchanged by higher layer protocols such as HTTP, FTP, TCP, UDP, DNS, or IP all are eventually encapsulated in link-layer frames that are transmitted over physical media such as an Ethernet cable.Figure 1: Packet Sniffer StructureIn Figure 1, the assumed physical media is an Ethernet, and so all upper-layer protocols are eventually encapsulated within an Ethernet frame. Capturing all link-layer frames thus gives you all messagessent/received from/by all protocols and applications executing in your computer.The second component of a packet sniffer is the packet analyzer, which displays the contents of all fields within a protocol message. In order to do so, the packet analyzer must “understand” the structure of all messages exchanged by protocols. For example, suppose we are interested in displaying the various fields in messages exchanged by the HTTP protocol in Figure 1. The packet analyzer understands the format of Ethernet frames, and so can identify the IP datagram within an Ethernet frame. It also under-stands the IP datagram format, so that it can extract the TCP segment within the IP datagram. Finally, it understands the TCP segment structure, so it can extract the HTTP message contained in the TCP seg-ment. Finally, it understands the HTTP protocol and so, for example, knows that the first bytes of an HTTP message will contain the string “GET,”“POST,” or “HEAD,”.Step 1: Capture a Traceunching WiresharkYou can type Wireshark in the run box of main Windows 8 start screen. Press the Windows key on the keyboard and type “wireshark”. If a problem launching it then see here1.Figure 2: Wireshark in lab2.Just close the dialog box which prompts you to install a new version. You will then see a startupscreen, as shown next.Figure 3: Initial Wireshark Screen3.Take a look at the left hand side of the screen –you’ll see an “Interface list”. This is the list ofnetwork interfaces on your computer. Choose Ethernet.1 It should load but there can be a problem with the new lab configuration for Wireshark and npf driver. Therefore if this is not working…. then please do the next step. Launch Wireshark as follows. Click desktop icon on main windows screen & use the file explorer to browse to C:\local Disk (C)\Program Files\Wireshark. Finally, RIGHT CLICK on Wireshark as “Run as administrator”.4.Next, click Start (as shown below).5.Wireshark will capture all packets on that interface. Click on the network card on the particularmachine you are working on. In the example above, it is the Ethernet Driver to start packet cap-ture (i.e., for Wireshark to begin capturing all packets being sent to/from that interface), ascreen like the one below will be displayed, showing information about the packets being cap-tured. Once you start packet capture, you can stop it by using the Capture pull down menu and selecting Stop.We want this trace to look at the protocol structure of packets. A simple Web fetch of a URL from a server of your choice to your computer, which is the client, could also serve as traffic.6.Open your browser, e.g. Chrome and pick a URL & fetch it e.g.”.7.Close unnecessary browser tabs and windows. By minimizing browser activity you will stop yourcomputer from fetching unnecessary web content, and avoid incidental traffic in the trace.8.Now return to Wireshark and you will see a screen similar to below.That is all for now. Next you will read a little more about Wireshark and tracing packets.Main Wireshark InterfaceThe Wireshark interface has five major components:Figure 4: Wireshark Graphical User Interface, during packet capture and analysis• The command menus are standard pull down menus located at the top of the window. The File menu allows you to save captured packet data or open a file containing previously captured packet data. The Capture menu allows you to begin packet capture.• The packet-listing window displays a one-line summary for each packet captured, including the pack-et number (assigned by Wireshark; this is not a packet number contained in any protocol’s header), the time at which the packet was captured, the packet’s source and destination addresses, the protocol type, and protocol-specific information contained in the packet. The packet listing can be sorted accord-ing to any of these categories by clicking on a column name. The protocol type field lists the highest-level protocol that sent or received this packet, i.e., the protocol that is source or ultimate sink for this packet.• The packet-header details window provides details about the packet selected (highlighted) in the packet-listing window. (To select a packet in the packet-listing window, place the cursor over the pack-et’s one-line summary in the packet-listing window and click with the left mouse button.). These details include information about the Ethernet frame (assuming the packet was sent/received over an Ethernet interface) and IP datagram that contains this packet. The amount of Ethernet and IP-layer detail dis-played can be expanded or minimized by clicking on the plus minus boxes to the left of the Ethernet frame or IP datagram line in the packet details window.• The packet-contents window displays the entire contents of the captured frame, in both ASCII and hexadecimal format. Towards the top of the Wireshark graphical user interface, is the packet display fil-ter field, into which a protocol name or other information can be entered in order to filter the infor-mation displayed in the packet-listing window.Filtering TrafficNow return to your Wireshark trace captured earlier. We will look to see how we can isolate the Web Page traffic from the other protocol packets.9.You have two options. You can simply type “tcp.port==80” in the main filter box on the mainscreen like below.10.Instead of the method above, you can also filter by typing “port 80” in the filter box like below.This filter will record only standard web traffic and not other kinds of packets that your comput-er may send. The checking will translate the addresses of the computers sending and receivingpackets into names, which should help you to recognize whether the packets are going to orfrom your computer. Your capture window will be similar to the one pictured in next screenshot.Figure 5: Setting up the capture options11.When the capture is started, visit a site which uses http (not https). This time, the packets will berecorded by Wireshark as the content is transferred. Try again, in your browser.12.After the fetch is successful, return to Wireshark and use the menus or buttons to stop the trace.If you have succeeded, the upper Wireshark window will show multiple packets, and most likely it will be full. How many packets are captured will depend on the size of the web page, but there should be at least 8 packets in the trace, and typically 20-100, and many of these packets will be colored green. I recommend you stop recording by pressing the Red Stop button on the inter-face as this will make it easier for you to scroll back to the start of the request to find the “200 OK” packet. An example is shown below. Congratulations, you have captured a trace!Figure 6: Packet trace of web browsing trafficStep 2: Inspect the TraceSelect a packet for which the Protocol column is “HTTP” and the Info column says it is a GET. It is the packet that carries the web (HTTP) request sent from your computer to the server. (You can click the column headings to sort by that value, though it should not be difficult to find an HTTP packet by inspec-tion.) Let’s have a closer look to s ee how the packet structure reflects the protocols that are in use. Since we are fetching a web page, we know that the protocol layers being used are as shown below. That is, HTTP is the application layer web protocol used to fetch URLs. Like many Internet applications, it runs on top of the TCP/IP transport and network layer protocols. The link and physical layer protocols depend on your network, but are typically combined in the form of Ethernet (shown) if your computer is wired, or 802.11 (not shown) if your computer is wireless.Figure 7: Protocol stack for a web fetchWith the HTTP GET packet selected, look closely to see the similarities and differences between it and our protocol stack as described next. The protocol blocks are listed in the middle panel. You can expand each block (by clicking on the “+” expander or icon) to see its details.• The first Wireshark block is “Frame”. This is not a protocol, it is a record that describes overall information about the packet, including when it was captured and how many bits long it is.• The second block is “Ethernet”. Note that you may have taken a trace on a computer using 802.11 yet still see an Ethernet block instead of an 802.11 block. Why? It happens because we asked Wireshark to capture traffic in Ethernet format on the capture options, so it converted the real 802.11 header into a pseudo-Ethernet header.• Then come IP, TCP, and HTTP, which are just as we wanted. Note that the order is from the bot-tom of the protocol stack upwards. This is because as packets are passed down the stack, the header information of the lower layer protocol is added to the front of the information from the higher layer protocol, as in Fig. 1-15 of your text. That is, the lower layer protocols come first in the packet “on the wire”.HTTPTCPIP Ethernet ClientServer HTTP TCP IPEthernetpacketStep 3: Inspect the Trace AgainNow find another HTTP packet, the response from the server to your computer, and look at the structure of this packet for the differences compared to the HTTP GET packet.This packet should have “200 OK” in the Info field, denoting a successful fetch. In our trace, there are two extra blocks in the detail panel as seen in the next figure.•The first extra block says something like “[... reassembled TCP segments …]”. Details in your cap-ture will vary, but this block is describing more than the packet itself. Most likely, the web re-sponse was sent across the network as a series of packets that were put together after they ar-rived at the computer. The packet labeled HTTP is the last packet in the web response, and the block lists packets that are joined together to obtain the complete web response. Each of these packets is shown as having protocol TCP even though the packets carry part of an HTTP re-sponse. Only the final packet is shown as having protocol HTTP when the complete HTTP mes-sage may be understood, and it lists the packets that are joined together to make the HTTP re-sponse.•The second extra block says “Line-based text data …”. Details in your capture will vary, but this block is describing the contents of the web page that was fetched. In our case it is of typetext/html, though it could easily have been text/xml, image/jpeg, or many other types. As with the Frame record, this is not a true protocol. Instead, it is a description of packet contents that Wireshark is producing to help us understand the network traffic.Figure 8: Inspecting a HTTP “200 OK” response1.Locate the HTTP GET packet which has “200 OK (text/html)” in the Info field, denoting asuccessful fetch. See below for instance in the third line in white.2.Scroll down in the middle pane to [+] Line-based text data: text/html and rightclick with your mouse. (See above)3.From the context menu which now appears, select Copy -→ Bytes → Printable Text Only Youshould see a window similar to the following popup window below.4.This copies all the code for the Ulster home page.5.Open up a text editor such as notepad++ and paste this HTML code into a new document. Saveas UlsterHomePage.html in a directory such as W: or downloads. Next open up explorer and scroll to where you have saved the file and open it in the default browser by clicking on it.6.Note how much of the Ulster home page actually gets sent over the wire to your PC.Step 4: Packet StructureExamine a HTTP GET packet that shows the position and size in bytes of the TCP, IP and Ethernet proto-col headers. Note the range of the Ethernet header and the Ethernet payload that IP passes to Ethernet to send over the network. Note also the range of the IP header and the IP payload.To work out sizes, observe that when you click on a protocol block in the middle panel (the block itself, not the “+” expander) then Wireshark will highlight the bytes it corresponds to in the packet in the lower panel and display the length at the bottom of the window. For instance, clicking on the IP version 4 header of a packet in our trace shows us that the length is 20 bytes. (Your trace will be different if it is IPv6, and may be different even with IPv4 depend-ing on various options.) You may also use the overall packet size shown in the Length column or Frame detail block. AnswerFigure 9: Protocol layer structure of the HTTP GET packet There are several features to note:• The order of the headers (Ethernet, IP, TCP, HTTP) is the protocol stack from the bottom up-wards because the lower layers are outermost in the packet as it travels through the network. • Observant students will note some differences between the Ethernet header size in Wireshark and in the text that will be explored in later labs.• The size of the IP and TCP headers is normally around 20 bytes each, but it may be larger in some cases depending on the OS, e.g., IPv6 instead of IPv4 and optional TCP header fields might double these numbers.• The size of the HTTP message will vary depending on what tool and URL is used to send the web request. For wget/curl, it is likely to be around 100-300 bytes.• The Ethernet payload comprises everything beyond the Ethernet header. That is, Ethernet does not understand the IP / TCP / HTTP internal structure; it is up to higher layers to determine their headers and message boundaries.• Similarly, the IP payload comprises everything beyond the IP header. Note that neither the IP header nor payload covers the Ethernet header. HTTP EthernetIP TCP 14 bytes 20 bytes20 bytes 112 bytesEthernet header Ethernet payload166 bytes totalStart of packetIP header IP payloadStep 5: Demultiplexing KeysWhen an Ethernet frame arrives at a computer, the Ethernet layer must hand the packet that it contains to the next higher layer to be processed. The act of finding the right higher layer to process received packets is called demultiplexing. We know that in our case the higher layer is IP. But how does the Ethernet protocol know this? After all, the higher-layer could have been another protocol entirely (such as ARP). We have the same issue at the IP layer – IP must be able to determine that the contents of IP message is a TCP packet so that it can hand it to the TCP protocol to process. The answer is that proto-cols use information in their header known as a “demultiplexing key” to determine the higher layer. Look at the Ethernet and IP headers of a download packet in detail to answer the following questions:1.Which Ethernet header field is the demultiplexing key that tells it the next higher layer is IP?What value is used in this field to indicate “IP”?Answer. The demultiplexing key for Ethernet is the Type field. It holds 0x800 when the higherlayer is IP.2.Which IP header field is the demultiplexing key that tells it the next higher layer is TCP? Whatvalue is used in this field to indicate “TCP”?Answer: The demultiplexing key for IP is the Protocol field. It has value 6 when the higher layer is TCP.。
wireshark练习及答案lab-ipv4
Lab Exercise – IPv4ObjectiveTo learn about the details of IP (Internet Protocol). IP is the network layer protocol used throughout the Internet. We will examine IP version 4, since it is ubiquitously deployed, while the IP version 6 is partly deployed.The trace is here: /~kevin/com320/labs/wireshark/trace-ipv4.pcapThe text file is here: /~kevin/com320/labs/wireshark/trace-ipv4.txt RequirementsWireshark: This lab uses the Wireshark software tool to capture and examine a packet trace. A packet trace is a record of traffic at a location on the network, as if a snapshot was taken of all the bits that passed across a particular wire. The packet trace records a timestamp for each packet, along with the bits that make up the packet, from the lower-layer headers to the higher-layer contents. Wireshark runs on most operating systems, including Windows, Mac and Linux. It provides a graphical UI that shows the sequence of packets and the meaning of the bits when interpreted as protocol headers and data. It col-or-codes packets by their type, and has various ways to filter and analyze packets to let you investigate the behavior of network protocols. Wireshark is widely used to troubleshoot networks. You can down-load it from if it is not already installed on your computer. We highly recommend that you watch the short, 5 minute video “Introduction to Wireshark” that is on the site.wget / curl: This lab uses wget (Linux and Windows) and curl (Mac) to fetch web resources. wget and curl are command-line programs that let you fetch a URL. Unlike a web browser, which fetches and executes entire pages, wget and curl give you control over exactly which URLs you fetch and when you fetch them. Under Linux, wget can be installed via your package manager. Under Windows, wget is available as a binary; look for download information on /software/wget/. Under Mac, curl comes installed with the OS. Both ha ve many options (try “wget --help” or “curl --help” to see) but a URL can be fetched simply with “wget URL” or “curl URL”. traceroute / tracert: This lab uses “traceroute” to find the router level path from your computer to a remote Internet host. traceroute is a standard command-line utility for discovering the Internet paths that your computer uses. It is widely used for network troubleshooting. It comes pre-installed on Win-dow and Mac, and can be installed using your package manager on Linux. On Windows, it is called “tracert”. It has various options, but simply issuing the command “traceroute .au” will cause your computer to find and print the path to the remote computer (here .au).Step 1: Capture a TraceProceed as follows to capture a trace assuming that your computer has IPv4 connectivity; alternatively, you may use a supplied trace. The trace we want to gather is a simple web fetch from a remote server, which will cause your computer to send and receive IP packets, followed by a traceroute to the re-mote server to find the path it uses over the Internet.1.Pick a URL at a remote server, e.g., .au/ and check that you can fetch thecontents with wget or curl, e.g., “wget .au/” or “curl.au/”. This will fetch the resource and either write it to a file (wget) or to the screen (curl). With wget, you want a single response with status code “200 OK”. Ifthe fetch does not work then try a different URL; keep in mind that you may be referring to aURL by a shortcut for which browsers must do work to find the intended content, e.g., may really be /index.html. If no URLs seem to work then de-bug your use of wget/curl or your Internet connectivity.2.Perform a traceroute to the same remote server to check that you can discover informationabout the network path.On Windows, type, e.g., “tracert .au”. On Linux / Mac, type, e.g., “traceroute .au”. If you are on Linux / Mac and behind aNAT (as most home users or virtual machine users) then use the –I option (that was a capital i)to traceroute, e.g., “traceroute –I .au”. This will cause traceroute to send ICMP probes like tracert instead of its usual UDP probes; ICMP probes are better ableto pass through NAT boxes. A successful example is shown below; save the output as you willneed it for later steps. Note that traceroute may take up to a minute to run. Each line shows information about the next IP hop from the computer running traceroute towards the tar-get destination. T he lines with “*”s indicate that there was no response from the network toidentity that segment of the Internet path. Some unidentified segments are to be expected.However, if traceroute is not working correctly then nearly all the path will be “*”s. In thiscase, try a different remote server, experiment with traceroute, or use the supplied traces.Figure 1: Running traceroute (as tracert on Windows)unch Wireshark and start a capture with a filter of “tcp port 80“. Make sure to check“enable network name resolution”. We use this filter to record only standard web traffic. Name resolution will translate the IP addresses of the computers sending and receiving packets into names. It will help you to recognize whether the packets are going to or from your computer.Your capture window should be similar to the one pictured below, other than our highlighting.Select the interface from which to capture as the main wired or wireless interface used by your computer to connect to the Internet. If unsure, guess and revisit this step later if your capture is not successful. Uncheck “capture packets in promiscuous mode”. This mode is useful to over-hear packets sent to/from other computers on broadcast networks. We only want to record packets sent to/from your computer. Leave other options at their default values. The capture filter, if present, is used to prevent the capture of other traffic your computer may send or re-ceive. On Wireshark 1.8, the capture filter box is present directly on the options screen, but on Wireshark 1.9, you set a capture filter by double-clicking on the interface.Figure 2: Setting up the capture options4.After the capture is started, repeat the wget/curl command above. This time, the packets willalso be recorded by Wireshark.5.After the command is complete, return to Wireshark and stop the trace. You should now have ashort trace similar to that shown in the figure below, along with the output of a traceroute you ran earlier to the corresponding server.Figure 3: Trace of wget/curl traffic showing the details of the IP headerStep 2: Inspect the TraceSelect any packet in the trace and expand the IP header fields (using the “+” expander or icon) to see the details. You can simply click on a packet to select it (in the top panel). You will see details of its structure (in the middle panel) and the bytes that make up the packet (in the bottom panel). Our interest is the IP header, and you may ignore the other higher and lower layer protocols. When you click on parts of the IP header, you will see the bytes that correspond to the part highlighted in the bottom panel. We have expanded the IP header and clicked on all the IP header fields in the figure above.Let us go over the fields in turn:•The version field is set to 4. This is “IPv4” after all.•Then there is the header length field. Observe by looking at the bytes selected in the packet da-ta that version and header length are both packed into a single byte.•The Differentiated Services field contains bit flags to indicate whether the packet should be handled with quality of service and congestion indications at routers.•Then there is the Total Length field.•Next is the Identification field, which is used for grouping fragments, when a large IP packet is sent as multiple smaller pieces called fragments. It is followed by the Flags and the Fragmentoffset fields, which also relate to fragmentation. Observe they share bytes.•Then there is the Time to live or TTL field, followed by the Protocol field.•Next comes the header checksum. Is your header checksum carrying 0 and flagged as incorrect for IP packets sent from your computer to the remote server? On some computers, the operat-ing system software leaves the header checksum blank (zero) for the NIC to compute and fill in as the packet is sent. This is called protocol offloading. It happens after Wireshark sees thepacket, which causes Wireshark to believe that the checksum is wrong and flag it with a differ-ent color to signal a problem. A similar issue may happen for the TCP checksum. You can remove these false errors if they are occurring by telling Wireshark not to validate the checksums. Select “Preferences” from the Wireshark menus and expand the “Protocols” area. Look under the list until you come to IP v4. Uncheck “Validate checksum if possible”. Similarly, you may uncheckchecksum validation for TCP if applicable to your case.•The last fields in the header are the normally the source and destination address. It is possible for there to be IP options, but these are unlikely in standard web traffic.•The IP header is followed by the IP payload. This makes up the rest of the packet, starting with the next higher layer header, TCP in our case, but not including any link layer trailer (e.g., Ether-net padding).Step 3: IP Packet StructureTo show your understanding of IP, sketch a figure of an IP packet you studied. It should show the position and size in bytes of the IP header fields as you can observe using Wireshark.Since you cannot easily de-termine sub-byte sizes, group any IP fields that are packed into the same bytes. Your figure can simply show the frame as a long, thin rectangle. Try not to look at the figure of an IPv4 packet in your text; check it afterwards to note and investigate any differences.To work out sizes, observe that when you click on a protocol block in the middle panel (the block itself, not the “+” expander) Wireshark will highlight the corresponding bytes in the packet in the lower panel, and display the length at the bottom of the window. You may also use the overall packet size shown in the Length column or Frame detail block. Note that this method will not tell you sub-byte positions.By looking at the IP packets in your trace, answer these questions:1.What are the IP addresses of your computer and the remote server?2.Does the Total Length field include the IP header plus IP payload, or just the IP payload?3.How does the value of the Identification field change or stay the same for different packets? Forinstance, does it hold the same value for all packets in a TCP connection or does it differ for each packet? Is it the same in both directions? Can you see any pattern if the value does change?4.What is the initial value of the TTL field for packets sent from your computer? Is it the maximumpossible value, or some lower value?5.How can you tell from looking at a packet that it has not been fragmented? Most often IP pack-ets in normal operation are not fragmented. But the receiver must have a way to be sure. Hint: you may need to read your text to confirm a guess.6.What is the length of the IP Header and how is this encoded in the header length field? Hint: no-tice that only 4 bits are used for this field, as the version takes up the other 4 bits of the byte.You may guess and check your text.Step 4: Internet PathsThe source and destination IP addresses in an IP packet denote the endpoints of an Internet path, not the IP routers on the network path the packet travels from the source to the destination. traceroute is a utility for discovering this path. It works by eliciting responses (ICMP TTL Exceeded messages) from the router 1 hop away from the source towards the destination, then 2 hops away from the source, then 3 hops, and so forth until the destination is reached. The responses will identify the IP address of the router. The output from traceroute normally prints the information for one hop per line, including the measured round trip times and IP address and DNS names of the router. The DNS name is handy for working out the organization to which the router belongs. Since traceroute takes advantage of common router implementations, there is no guarantee that it will work for all routers along the path, and it is usual to see “*” re sponses when it fails for some portions of the path.Using the traceroute output, sketch a drawing of the network path. If you are using the supplied trace, note that we have provided the corresponding traceroute output as a separate file.Show your computer (lefthand side) and the remote server (righthand side), both with IP addresses, as well as the routers along the path between them numbered by their distance on hops from the start of the path. You can find the IP address of your computer and the remote server on the packets in the trace that you captured. The output of traceroute will tell you the hop number for each router.To finish your drawing, label the routers along the path with the name of the real-world organization to which they belong. To do this, you will need to interpret the domain names of the routers given by traceroute. If you are unsure, label the routers with the domain name of what you take to be the or-ganization. Ignore or leave blank any routers for which there is no domain name (or no IP address).This is not an exact science, so we will give some examples. Suppose that traceroute identifies a router along the path by the domain name . Normally, we can ig-nore at least the first part of the name, since it identifies different computers in the same organization and not different organizations. Thus we can ignore at least “arouter” in the domain name. For ge-neric top-level domains, like “.com” and “.edu”, the last two domains give the domain name of the or-ganization. So for our example, it is “”. To translate this domain name into the real-world name of an organization, we might search for it on the web. You will quickly find that is the University of Washington. This means tha t “cac” portion is an internal structure in the University of Washington, and not important for the organization name. You would write “University of Washington” on your figure for any routers with domain names of the form *. Alternatively, consider a router with a domain name like .au. Again, we ignore at least the “arouter” part as indicating a computer within a specific organization. For country-code top-level domains like “.au” (for Australia) the last three domain s in the name will normally give the organization. In this case the organization’s domain name is .au. Using a web search, we find this domain represents AARNET, Australia’s research and education network. The “syd” por-tion is internal structure, and a good guess is that it means the router is located in the Sydney part of AARNET. So for all routers with domain names of the form *.au, you would write“AARNET” on your figure. While there are no guarantees, you should be able to reason similarly and at least give the domain name of the organizations near the ends of the path.Step 5: IP Header ChecksumWe will now look at the IP header checksum calculation by validating a packet. The checksum algorithm adds the header bytes 16 bits at a time. It is computed so that re-computing the sum across the entire IP header (including the checksum value) will produce the result of zero. A complicating factor for us is that this is done using 1s complement arithmetic, rather than 2s complement arithmetic that is normally used for computing. The steps below explain how to perform the necessary computation.From the trace, pick a packet sent from the remote server to your computer and check that you have a non-zero value in the checksum field. The checksum value sent over the network will be non-zero, so if you have a zero value it is because of the capture setup. Try a packet that has an IP header of 20 bytes, the minimum header size when there are no options, to make this exercise easier.Follow these steps to check that the checksum value is correct:1.Divide the header into 10 two byte (16 bit) words. Each word will be 4 hexadecimal digits shownin the packet data panel in the bottom of the Wireshark window, e.g., 05 8c2.Add these 10 words using regular addition. You may add them with a hexadecimal calculator(Google to find one), or convert them to decimal, add them, and convert them back to hexadec-imal. Do whatever is easiest.3.To compute the 1s complement sum from your addition so far, take any leading digits (beyondthe 4 digits of the word size) and add them back to the remainder. For example: 5a432 will be-come a432 + 5= a437.4.The end result should be 0xffff. This is actually zero in 1s complement form, or more precise-ly 0xffff is -0 (negative zero) while 0x0000 is +0 (positive zero).If you cannot get your sum to come out and are sure that the checksum must be wrong, you can get Wireshark to check it. See whether it says “[correct]” already. If it does not then use the menus to go to Preferenc es, expand Protocols, choose IPv4 from the list, and check “validate header checksum”. Now Wireshark will check the checksum and tell you if it is correct.Extra - Explore on your ownWe encourage you to explore IP on your own once you have completed this lab. Some ideas: •Read about and experiment with IPv6. Modern operating systems already include support for IPv6, so you may be able to capture IPv6 traffic on your network. You can also “join the IPv6”backbone by tunneling to an IPv6 provider.•Learn about tunnels, which wrap an IP packet within another IP header.•Read about IP geolocation. It is the process of assigning a geographical location to an IP address using measurements or clues from its name administrative databases. Try a geolocation service.•Learn about IPsec or IP security. It provides confidentiality and authentication for IP packets, and is often used as part of VPNs.。
计算机网络上机答案
5. What is the destination port for the DNS query message? What is the source port
of DNS response message?
The destination port for the DNS query is 53 and the source port of the DNS response is 53.
DNS response message.
10. This web page contains images. Before retrieving each image, does your host
issue new DNS queries?
No
PART 3b
Screenshot for DNS query Screenshot for DNS response
Data length: 4
Addr: 209.173.57.180
: type A, class IN, addr 209.173.53.180
Name:
Type: A (Host address)
Class: IN (0x0001)
default local DNS server? If not, what does the IP address correspond to?
The query is sent to 18.72.0.3 which corresponds to .
21. Examine the DNS query message. What “Type” of DNS query is it? Does the
wireshark练习及答案lab-arpattack
Lab Exercise – Snooping on other traffic in Lab through ARP Poison AttackObjective - To demonstrate a Man in the middle (MITM) hack with the Ettercap tool.Ettercap is a multipurpose sniffer/interceptor/logger for switched LAN, and pretty much the Swiss army knife of ARP poisoning. Every security researcher should include it in his toolbox. It is included in Backtrack – the popular Linux distribution. Ettercap features a GUI and a command line text mode tool.1. Download Ettercap from /~kevin/com320/labs/ettercap.exe.2. Follow the instructions to install it. See figure below.Figure 1: Ettercap installation in progress3. Go to Run button in bottom left and type "ettercap". You should see it appear as in the following fig-ure. Of course, you can also run it from All programs menu in Windows as well.Figure 2: Running Ettercap in Lab4. Next select Unified Sniffing from the Sniff menu option as show in figure 3.Figure 3: Step 1 in process of snooping5. Select the first Etternet interface (in this case it is “eXtreme Gigabit Ethernet Driver” network interface (see figure 4).Figure 4: Selection of network interface1.Next you should be presented with a series of menu options including Start, Targets, Hosts, ViewMitm, Filters, Logging and Plugins. You should select the Hosts option and choose Scan for Hosts.See figure 5.Figure 5: Selection of hosts to scan on LAN2.Once you select Scan for hosts, you should see a pop up window displaying the progess when all255 hosts on the local network are scanned. See figure 6.Figure 6: Hosts being scanned locally3.Next you should select Hosts List from the Hosts menu. You should then see a screen similar tofigure 7 with a list of hosts that have been found.Figure 7: Hosts that were scanned locally4.Please ask permission from a colleague to allow you to select their computer to be scanned.They should confirm their IP address to you. That can be found as in previous weeks by typing cmd in the windows start menu and opening a command prompt. Then in the command prompt, type ipconfig and note the ipv4 address displayed. You may need to scroll up to see it in the command prompt window. Here in figure 8, host 193.61.190.73 is being selected for scanning.Figure 8: host 193.61.190.73 is being selected for scanning5.Once you have the target selected with your mouse, then select the Add to Target 1 button. Seefigure 9.Figure 9: host 193.61.190.73 is being added to Target 1.6.Select the Targets menu option and then select C urrent Targets as shown in figure 10.Figure 10: Targets being selected7.Now you should only see your class mates computer shown as in figure 11.Figure 11: host selected for attack8.Now go to the mitm option as show in figure 12. Select Arp poisoning.Figure 12: ARP Poisoning selection9.Once Arp poisoning is selected, you will be presented with the dialogue window as shown in fig-ure 13. Simply click OK.Figure 13: Options for ARP poison attack10.You will then be presented with a window once again which is similar to figure 14. The ARP poi-son attack however is happening underneath. You now have access to all the traffic which is be-ing routed to the IP address which you have entered earlier. We will now move to Wireshark to see the power of an ARP poison mitm attack.Figure 14: Main window after attack has been started11.Open Wireshark by typing wireshark at the run programs option. You will then select the usualEtternet Intel Interface and Start a capture. In the display filter, type the following:ip.src==yourfriendsipaddress&&tcp.port==80 e.g. ip.src==193.61.191.88 &&tcp.port==80. See figure 15.Figure 15: Sample scan of web traffic on IP address 193.61.191.8812.Get your friend to browse to any site. In this example below, I have gone to a CNN page whichdiscusses Coca-Cola remarks from the CEO. It is at/2013/02/05/business/coke-ceo-muhtar-kent-capitalism-evolve/Figure 16: Sample page surfed.13.Once your friend has started to surf, you should start to see a lot of HTTP and TCP packets ap-pear in your packet list window. After some time you can stop the capture. You may also choose to stop the mitm attack. You can always resume the attack to see ‘fresh’ traffic remotely. You should then select the page that he surfed through e.g. CNN and right click on it as displayed be-low and select Follow TCP Stream.Figure17: Sample page from CNN being selected in the Wireshark interface. Note the ip address and port filtering14.The TCP Follow Stream should lead you to a window such as displayed below. Note the contentsof the GET and HOST on the first two lines. When we put them together we get the location of the site visited which is /2013/02/05/business/coke-ceo-muhtar-kent-capitalism-evolve/. This should now show you that all surfing can be snooped on a LAN.Figure18: CNN page after selecting Follow TCP Stream20.Now get your friend to go to a site which requires a login or passing information such as cnnweather at: /weather. Here type a city such as Belfast:21. Next, examine the wireshark tr ace, you should see a captured packet with “cit y-Search/json/true HTTP/1.1” showing the ‘sensitive data’.22.Finally, please return to the ettercap program and select Mitm and click on Stop mitm attack(s).This will ensure that the ARP tables return to normal and no unnecessary snooping of a newco-mer to your friend’s machine takes place. See figure 19.Figure19: Stopping the man in the middle ARP attack23.The following popup windows should confirm that all man in the middle attacks have stopped.People are now safe again in the lab.Figure 20: Confirmation of mitm attack being stopped.24.Finally, you can exit the program.Figure 21: Ensuring you exit the attack vector programPlease be responsible with this new knowledge……。
通信网络基础抓包作业答案
网络协议数据获取与TCP/IP协议分析一、实验环境介绍网络接入方式：校园网宽带接入，IP获取方式：DHCP；操作系统为windows7旗舰版；本机MAC地址为5c:f9:dd:70:6a:89，IP地址为10.104.5.53。
图1 网络状态截图二、实验步骤1. 启动wireshark；2. 启动一个网页浏览器，并键入一个URL地址，如：。
注意此时不要按下回车键；3. 清除电脑中的DNS缓存，启动wireshark，开始抓包；4. 在浏览期网页位置按下回车键，开始访问指定的网页。
5. 一旦网页内容下载完毕，立即停止Microsoft Network Monitor抓包，并将抓到的数据包存入文件中，同时将显示的网页存储下来，以便后面参考。
三、实验过程使用wireshark前清除DNS缓存截图如下。
图2 清除DNS缓存抓取协议如下图所示：图3 抓取协议四、协议分析1. 抓取的协议类型检查在Microsoft Network Monitor顶端窗口的协议一列，确认你已经抓到了DNS、TCP和HTTP数据包。
答：由图3可看出抓到了DNS、TCP、HTTP数据包。
2. 以太网帧，IP分组和UDP数据报(1) 检查客户端发出的第一个DNS分组a.确定客户端的以太网地址和IP地址答：如图4，客户端的MAC地址为5c:f9:dd:70:6a:89；IPv4地址为：10.104.5.53。
b.以太网帧结构的TYPE字段是什么内容？答：如图所示，以太网帧结构的TYPE字段为：0x0800，表示该帧是IP协议。
c.目的以太网地址和目的IP地址分别是什么？这些地址对应哪些计算机？解释这些结果与你连接到Internet 的计算机有关系。
答：目的以太网地址：00: 0f:e2:d7:ef:f9，目的IP地址：10. 0. 0.10对应的计算机：以太网地址对应要访问的的源地址，IP地址是本地局域网域名服务器的IP地址。
因为我们访问网络时用的是域名，只有经过域名服务器经过域名解析得到要访问的网络IP地址，才能进行交换数据。
计算机网络实验课 WiresharkDNS
• 12. To what IP address is the DNS query message sent? Is this the IP address of your default local DNS server?(答案请截图)
• 21. Examine the DNS query message. What “Type” of DNS query is it? Does the query message contain any “answers”? (答案请截图)
• 22. Examine the DNS response message. How many “answers” are provided? What does each of these answers contain? (答案请截图)
• DNS查询
9
开始三次握手
DNS resource records (p.165-168)
Eg: 1. (, 145.37.93.126, A) 2. (, , NS) 3. (, , CNAME) 4. (, , MX)
• 17. Examine the DNS query message. What “Type” of DNS query is it? Does the query message contain any “answers”?(答案请截图)
• 18. Examine the DNS response message. What MIT name servers does the response message provide? Does this response message also provide the IP addresses of the MIT name servers? (答案请截图)
wireshark练习及答案lab-udp
Lab Exercise – UDPObjectiveTo look at the details of UDP (User Datagram Protocol). UDP is a transport protocol used throughout the Internet as an alternative to TCP when reliability is not required. It is covered in §6.4 of your text. Re-view that section before doing this lab.The trace file is here: /~kevin/com320/labs/wireshark/trace-udp.pcapStep 1: Capture a TraceThere are many ways to cause your computer to send and receive UDP messages since UDP is widely used as a transport protocol. The easiest options are to:•Do nothing but wait for a while. UDP is used for many “system protocols” that typically run in the background and produce small amounts of traffic, e.g., DHCP for IP address assignment and NTP for time synchronization.•Use your browser to visit sites. UDP is used by DNS for resolving domain names to IP addresses, so visiting fresh sites will cause DNS traffic to be sent. Be careful not to visit unsafe sites; pickrecommended sites or sites you know about but have not visited recently. Simply browsing the web is likely to cause a steady stream of DNS traffic.•Start up a voice-over-IP call with your favorite client. UDP is used by RTP, which is the protocol commonly used to carry media samples in a voice or video call over the Internet.Proceed as follows to capture a trace of UDP traffic; alternatively, you may use a supplied trace:unch Wireshark and start a capture with a filter of “udp“.Figure 1: Setting up the capture options2.When the capture is started, perform some activities that will generate UDP traffic. We de-scribed several options above, e.g., browse the web or start a short VoIP call.3.Wait a little while (say 60 seconds) after you have stopped your activity to also observe anybackground UDP traffic. It is likely that you will observe a trickle of UDP traffic because system activity often uses UDP to communicate. We want to see some of this activity.e the Wireshark menus or buttons to stop the capture. You should now have a trace with pos-sibly many UDP packets. Our example is shown below. We have selected a packet and expand-ed the detail of the UDP header.Figure 2: Trace of UDP traffic showing the details of the UDP headerStep 2: Inspect the TraceDifferent computers are likely to capture different kinds of UDP traffic depending on the network setup and local activity. Observe that the protocol column is likely to show multiple protocols, none of which is UDP. This is because the listed protocol is an application protocol layered on top of UDP. Wireshark gives the name of the application protocol, not the (UDP) transport protocol unless Wireshark cannot determine the application protocol. However, even if the packets are listed as an application protocol, they will have a UDP protocol header for us to study, following the IP and lower-layer protocol headers. Select different packets in the trace (in the top panel) and browse the expanded UDP header (in the mid-dle panel). You will see that it contains the following fields:•Source Port, the port from which the UDP message is sent. It is given as a number and possibly a text name; names are given to port values that are registered for use with a specific application.•Destination Port. This is the port number and possibly name to which the UDP message is des-tined. Ports are the only form of addressing in UDP. There computer is identified using the IPaddress in the lower IP layer.•Length. The length of the UDP message.•Checksum. A checksum over the message that is used to validate its contents. Is your checksum carrying 0 and flagged as incorrect for UDP messages sent from your computer? On some com-puters, the operating system software leaves the checksum blank (zero) for the NIC to compute and fill in as the packet is sent. This is called protocol offloading. It happens after Wireshark sees the packet, which causes Wireshark to believe that the checksum is wrong and flag it with a dif-ferent color to signal a problem. You can remove these false errors if they are occurring by tell-ing Wireshark not to validate the checksums. Select “Preferences” from the Wireshark menusand expand the “Protocols” area. Look under the list until you come to UDP. Uncheck “Validate checksum if possible”.That is it. The UDP header has different values for different messages, but as you can see, it is short and sweet. The remainder of the message is the UDP payload that is normally identified the higher-layer pro-tocol that it carries, e.g., DNS, or RTP.Step 3: UDP Message StructureTo check your understanding of UDP, you should sketch a figure of the UDP message structure as you ob-served. It should show the position of the IP header, UDP header, and UDP payload. Within the UDP header, show the position and size of each UDP field you can observe using Wireshark. Your figure can simply show the message as a long, thin rectangle.Try not to look at the figure of a UDP segment in the answer on next page. To work out sizes, observe that when you click on a protocol block in the middle panel (the block itself, not the “+” expander) then Wireshark will highlight the bytes it corresponds to in the packet in the lower panel and display the length at the bottom of the window.By looking at the details of the UDP messages in your trace, answer these questions:1.What does the Length field include? The UDP payload, UDP payload and UDP header, or UDPpayload, UDP header, and lower layer headers?2.How long in bits is the UDP checksum?3.How long in bytes is the entire UDP header?(Please note that answers are on next page).Solutions – Step 3 UDP Message StructureFigure 1: Structure of a UDP messageThis drawing shows the same UDP header fields as in the book in a slightly different format and with lengths given in bytes, not bits. It also shows the relation of the IP header and UDP payload to the UDP header.The answers to the questions are:1.The Length field gives the length of the UDP payload plus the UDP header.2.The checksum is 16 bits long.3.The UDP header is 8 bytes long.[END]Step 4: UDP UsageTo complete our understanding of UDP, we will look at how UDP is used in practice as a transport by ap-plications. Beginning with IP, the next lower protocol layer, there are several issues we can consider. A first issue is how IP knows that the next higher protocol layer is UDP. The answer is that there is a Proto-col field in the IP header that contains this information.1.Give the value of the IP Protocol field that identifies the upper layer protocol as UDP.A second issue is how UDP messages are typically addressed at the IP layer. You might be surprised to find UDP messages in your trace that neither come from your computer or are sent only to your com-puter. You can see this by sorting on the Source and Destination columns. The source and destinations will be domain names, if Network layer name resolution is turned, and otherwise IP addresses. (You can toggle this setting using the View menu and selecting Name resolution.) You can find out the IP address of your computer using the “ipconfig” command (Windows).The reason you may find UDP messages without your com puter’s IP address as either the source or des-tination IP address is that UDP is widely used as part of system protocols. These protocols often send messages to all local computers who are interested in them using broadcast and multicast addresses. In our traces, we find DNS (the domain name system), MDNS (DNS traffic that uses IP multicast), NTP (for time synchronization), NBNS (NetBIOS traffic), DHCP (for IP address assignment), SSDP (a service discov-ery protocol), STUN (a NAT traversal protocol), RTP (for carrying audio and video samples), and more. Your trace may have other protocols you have not heard about; it is OK, as there are a lot of protocols out there. You can look them up on the web for fun.2.Examine the UDP messages and give the destination IP addresses that are used when your com-puter is neither the source IP address nor the destination IP address. (If you have only your com-puter as the source or destination IP address then you may use the supplied trace.)Finally, let us look at the lengths of typical UDP messages. We know that UDP messages can be as large as roughly 64Kbytes. But as you browse you should see that most UDP messages are much shorter than this maximum, so that UDP messages fit in a single packet.3.What is the typical size of UDP messages in your trace?(Please note that answers are on next page).Solutions to Step 4: UDP UsageThe answers to the questions are:1.The IP Protocol field value of 17 indicates UDP.2. A variety of broadcast and multicast addresses may be found. These include the Internet broad-cast address of 255.255.255.255, subnet broadcast addresses such as 192.168.255.255 (where the 192.168 portion is the subnet number and the .255.255 portion means broadcast), and mul-ticast IP addresses such as 224.0.xx.xx (such as 224.0.0.251 for multicast DNS).3.This answer will vary with your trace. Most often they are a few hundred bytes or less, and oftenmay be around 100 bytes. That is, many messages are relatively short packets.。
实训一 用WireShark抓包并分析ARP与DNS协议
计算机学院网络工程2012（1）班学号：3112006354 姓名：詹德超实训一网络分层及ARP、DNS协议分析一、实验目的1．学习WireShark协议分析软件的使用方法，学会利用WireShark进行抓包分析。
2．学习过滤数据包，并对数据包的构成进行分析，直观感受协议分层及各层协议数据单元的格式及相应关系。
3．通过分析ARP与DNS数据包，了解网络各层地址构成。
二、实训内容1. 阅读协议分析工具WireShark的用户手册，重点学习用户界面操作，了解WireShark的基本使用方法；2. 利用Wireshark进行数据包的抓取、过滤；3. 对抓取到的数据包进行协议分析，包括数据帧二进制数据组成、协议分层、各数据包包头信息、数据包之间的关系（ARP解析、DNS解析）等。
三、实验工具PC机，Windows，WireShark软件四、实验步骤与分析（一）学习使用WireShark软件进行网络数据分析1．本机arp –a，查看ARP缓存。
2．本机 arp –d，删除ARP缓存。
本机arp –a，查看ARP缓存。
3．本机ipconfig /displaydns，查看DNS缓存。
4．本机 ipconfig /flushdns，删除DNS缓存。
5．运行WireShark软件，启动抓包6．打开浏览器，访问一个网站7．点击网站内容8．停止抓包9．本机ipconfig /displaydns，查看DNS缓存。
10．填写下列表格：要求：透彻理解协议分层及各层的地址的内容和意义；理解数据包的数据及其组成。
（二） DNS实验1. 对所抓包设置过滤条件为：“dns”2．找到有你访问网站URL的DNS请求包和应答包3．分析DNS请求包要求：理解该请求包的功能；理解该数据包如何从源端传输到目的端。
4．分析DNS应答包5．选中上述DNS应答包，清除过滤，检查接下来的数据包有没有从上述应答包所告知的IP地址的访问，是什么类型的访问，请截图并分析。
wireshark练习及答案lab-http
Lab Exercise – HTTPObjectiveHTTP (HyperText Transfer Protocol) is the main protocol underlying the Web. The trace file is here: /~kevin/com320/labs/wireshark/trace-http.pcapStep 1: Capture a TraceCapture a trace of your browser making HTTP requests as follows; alternatively, you may use a supplied trace. Now that we seen how a GET works, we will observe your browser as it makes HTTP requests. Browser behavior can be quite complex, using more HTTP features than the basic exchange, so we will set up a simple scenario. We are assuming that your browser will use HTTP in this simple scenario rather than newer Web protocols such as SPDY, and if this is not the case you will need to disable SPDY.e your browser to find two URLs with which to experiment, both of which are HTTP (not HTTPS)URLs with no special port. The first URL should be that of a small to medium-sized image,whether .jpg, .gif, or .png. We want some static content without embedded resources. You canoften find such a URL by right-clicking on unlinked images in web pages to tell your browser toopen the URL of the image directly. The second URL should be the home page of some majorweb site that you would like to study. It will be complex by comparison. Visit both URLs to check that they work, then keep them handy outside of the browser so you can cut-and-paste them.2.Prepare your browser by reducing HTTP activity and clearing the cache. Apart from one freshtab that you will use, close all other tabs, windows to minimize HTTP traffic.unch Wireshark and start a capture with a filter of “tcp port 80”.We use this filter be-cause there is no shorthand for HTTP, but HTTP is normally carried on TCP port 80.Figure 2: Setting up the capture options4.Fetch the following sequence of URLs, after you wait for a moment to check that there is noHTTP traffic. If there is HTTP traffic then you need to find and close the application that is caus-ing it. Otherwise your trace will have too much HTTP traffic for you to understand. You will paste each URL into the browser URL bar and press Enter to fetch it. Do not type the URL, as this may cause the browser to generate additional HTTP requests as it tries to auto-complete your typing.a.Fetch the first static image URL by pasting the URL into the browser bar and pressing“Enter” or whatever is required to run your browser.b.Wait 10 seconds, and re-fetch the static image URL. Do this in the same manner, andwithout using the “Reload” button of your browser, lest it trigger other behavior.c.Wait another 10 seconds, and fetch the second home page URL.5.Stop the capture after the fetches are complete. You should have a window full of trace in whichthe protocol of some packets is listed as HTTP – if you do not have any HTTP packets there is a problem with the setup such as your browser using SPDY instead of HTTP to fetch web pages.Figure 3: Trace of HTTP traffic showing the details of the HTTP headerStep 2: Inspect the TraceTo focus on HTTP traffic, enter and apply a filter expression of“http”. This filter will show HTTP re-quests and responses, but not the individual packets that are involved. Recall that an HTTP response car-rying content will normally be spread across multiple packets. When the last packet in the response ar-rives, Wireshark assembles the complete response and tags the packet with protocol HTTP. The earlier packets are simply TCP segments carrying data; the last packet tagged HTTP includes a list of all the ear-lier packets used to make the response. A similar process occurs for the request, but in this case it is common for a request to fit in a single packet. With the filter expression of “http” we will hide the in-termediate TCP packets and see only the HTTP requests and responses. With this filter, your Wireshark display should be similar to the figure showing our example.Select the first GET in the trace, and expand its HTTP block. This will let us inspect the details of an HTTP request. Observe that the HTTP header follows the TCP and IP headers, as HTTP is an application proto-col that is transported using TCP/IP. To view it, select the packet, find the HTTP block in the middle panel, and expand it (by using the “+” expander or icon). This block is expanded in our figure.Explore the headers that are sent along with the request. First, you will see the GET method at the start of the request, including details such as the path. Then you will see a series of headers in the form of tagged parameters. There may be many headers, and the choice of headers and their values vary from browser to browser. See if you have any of these common headers:•Host. A mandatory header, it identifies the name (and port) of the server.•User-Agent. The kind of browser and its capabilities.•Accept, Accept-Encoding, Accept-Charset, Accept-Language. Descriptions of the formats that will be accepted in the response, e.g., text/html, including its encoding, e.g., gzip, and language.•Cookie. The name and value of cookies the browser holds for the website.•Cache-Control. Information about how the response can be cached.The request information is sent in a simple text and line-based format. If you look in the bottom panel you can read much of the request directly from the packet itself!Select the response that corresponds to the first GET in the trace, and expand its HTTP block. The Info for this packet will indicate “200 OK” in the case of a normal, successful transfer. You will see that the re-sponse is similar to the request, with a series of headers that follow the “200 OK” status code. However, different headers will be used, and the headers will be followed by the requested content. See if you have any of these common headers:•Server. The kind of server and its capabilities.•Date, Last-Modified. The time of the response and the time the content last changed.•Cache-Control, Expires, Etag. Information about how the response can be cached.Answer the following questions: (answers on next page)1.What is the format of a header line? Give a simple description that fits the headers you see.2.What headers are used to indicate the kind and length of content that is returned in a response?Answers to Inspect the Trace1.Each header line consists of the name of the header field and its value separated by a colon.There can be whitespace before (and after) the value. The line ends with a “carriage return, line feed” pair of characters, often written CRLF or “\r\n”.2.The type of the content is given by the Content-Type header, and its length is normally given bythe Content-Length header. (It is possible but unlikely that these headers are not present.)Step 3: Content CachingThe second fetch in the trace should be a re-fetch of the first URL. This fetch presents an opportunity for us to look at caching in action, since it is highly likely that the image or document has not changed and therefore does not need to be downloaded again. HTTP caching mechanisms should identify this oppor-tunity. We will now see how they work.Select the GET that is a re-fetch of the first GET, and expand its HTTP block. Likely, this will be the second GET in the trace. However, look carefully because your browser may issue other HTTP requests for its own reasons. For example, you might see a GET for /favicon.ico in the trace. This is the browser request-ing the icon for the site to use as part of the browser display. Similarly, if you typed in the URL bar your browser may have issued GETs as part of its auto-completion routine. We are not interested in this background browser activity at the moment.Now find the header that will let the server work out whether it needs to send fresh content. We will ask you about this header shortly. The server will need to send fresh content only if the content has changed since the browser last downloaded it. To work this out, the browser includes a timestamp tak-en from the previous download for the content that it has cached. This header was not present on the first GET since we cleared the browser cache so the browser had no previous download of the content that it could use. In most other respects, this request will be the same as the first time request. Finally, select the response to the re-fetch, and expand its HTTP block. Assuming that caching worked as expected, this response will not contain the content. Instead, the status code of the response will be “304 Not Modified”. This tells the browser that the content is unchanged from its previous copy, and the cached content can then be displayed.Answer the following questions (answer on next page).1.What is the name of the header the browser sends to let the server work out whether to sendfresh content?2.Where exactly does the timestamp value carried by the header come from?Answers to Content Caching1.The header is called “If-Modified-Since”, i.e., it asks the server to send the content if it has beenmodified since a given time.2.The timestamp value comes from the “Last-Modified” header of the most recent download ofthe content. It is a server timestamp for when the content last changed – it is not a timestamp according to the browser clock, and it is not a timestamp of the time of the downloadStep 4: Complex PagesNow let’s examine the third fetch at the end of the trace. This fetch was for a more complex web page that will likely have embedded resources. So the browser will download the initial HTML plus all of the embedded resources needed to render the page, plus other resources that are requested during the ex-ecution of page scripts. As we will see, a single page can involve many GETs!To summarize the GETs for the third page, bring up a HTTP Load Distribution panel. You will find this panel under “Statistics” and “HTTP”. You can filter for the packets that are part of the third fetch by re-moving the packets from the earlier part of the trace by either time or number. For example, use “frame.number>27” or “frame.time_relative>24” for our trace.Looking at this panel will tell you how many requests were made to which servers. Chances are that your fetch will request content from other servers you might not have suspected to build the page. These other servers may include third parties such as content distribution networks, ad networks, and analytics networks. Our panel is shown below – the page fetch involved 95 requests to 4 different serv-ers!Figure 4: HTTP Load Distribution panelFor a different kind of summary of the GETs, bring up a HTTP Packet Counter panel. You will also find this pane l under “Statistics” and “HTTP”, and y ou should filter for the packets that are part of the third fetch as before. This panel will tell you the kinds of request and responses. Our panel is shown in the figure below. You can see that it consists entirely of GET requests that are matched by 200 OK responses. However, there are a variety of other response codes that you might observe in your trace, such as when the resource is already cached.Figure 5: HTTP Packet Counter panelYou might be curious to know what content is being downloaded by all these requests. As well as seeing the URLs in the Info column, you can get a summary of the URLs in a HTTP Request panel under “Statis-tics” and “HTTP”. Each of the individual requests and responses has the same form we saw in an earlier step. Collectively, they are performed in the process of fetching a complete page with a given URL.For a more detailed look a t the overall page load process, use a site such as Google’s PageSpeed or . These sites will test a URL of your choice and generate a report of the page load activity, telling what requests were fetched at what times and giving tips for decreasing the overall page load time. We have shown the beginning of the “waterfall” diagram for the page load corresponding to our trace in the figure below. After the initial HTML resource is fetched there are many subsequent quick fetches for embedded resources such as JavaScript scripts, CSS stylesheets, images, and more.Figure 6: Start of waterfall graph for (from ) Homework - Explore Your Network Explore HTTP on your own once you have finished this lab. Some suggestions:• Study how web pages lead to a pattern of HTTP requests. Many popular web sites have relative-ly complex pages that require many HTTP requests to build. Moreover, these pages may contin-ue to issue “asynchronous” HTTP requests once they appear to have loaded, to load interactive displays or prepare for the next page, etc. You will see this activity when you find HTTP requests that continue after a page is loaded.• Look at video streaming HTTP traffic. We have looked at web HTTP traffic, but other applica-tions make HTTP requests too. It is common for streaming video clients embedded in browsers like Netflix to download content using a HTTP fetches of many small “chunks” of video. If y ou look at other applications, you may find that many of them use HTTP to shift about content, though often on a port different than port 80... .。
wireshark练习及答案lab-dhcp
Lab Exercise – DHCPObjectiveTo see how DHCP (Dynamic Host Configuration Protocol) works. The trace is here: /~kevin/com320/labs/wireshark/trace-dhcp.pcap Network SetupRecall that DHCP is normally used to assign a computer its IP address, as well as other parameters such as the address of the local router. Your computer, the client, uses the DHCP protocol to communicate with a DHCP server on the local network. Other computers on the local network also interact with the DHCP server. In deployments, there are several variations. For example, the local agent may be a DHCP relay that relays messages between local computers and a remote DHCP server. Or the DHCP server may be replicated for reliability, so that there are two or more local DHCP servers. For our purposes, it is suf-ficient to think about a single DHCP server.The complete DHCP exchange involves four types of packets: Discover, for your computer to locate the DHCP server; Offer, for the server to offer an IP address; Request, for your computer to ask for an of-fered address; and Ack, for the server to grant the address lease. However, when a computer is re-establishing its IP address on a network that it has previously used, it may perform a short exchange in-volving only two types of DHCP packets: Request, to ask for the same IP address as from the same server as was used before; and ACK for the server to grant the address lease.Figure 1: DHCP message sequencesYour computer DHCP serverShortexchange Complete exchangeStep 1: Capture a TraceProceed as follows to renew your IP address and gather a trace of DHCP traffic. Note, however, that the following procedure will not work in the unlikely case that your computer’s IP address is statically a s-signed. Alternatively, you may use a supplied trace. Take care not to perform this lab remotely, since when you tell your computer to shut down and restart its network interface you will lose connectivity!unch Wireshark and start a capture with a filter of “(udp port 67) or (udp port 68)”.There is no shorthand to indicate DHCP, so we filter traffic using the UDP ports reserved forDHCP. (Note, in the display filter on main screen you can also type udp.port==67 II udp.port==68)Figure 2: Setting up the capture options2.When the capture is started, release and renew your IP address with the command given below.This procedure may cause your computer to lose network connectivity temporarily, and depend-ing on the operating system it may disrupt network connections. To minimize the disruption,close any programs that are using remote servers and enter the commands into a local window.Windows: T ype the command “ipconfig /release” followed by “ipconfig/renew”.(See figure below.)If on Linux: Find the name of the main network interface by typing “ifconfig” and observing the output.The interface may be called “eth0” or something else. Now use the “dhclient” command to first r e-lease the leased IP address and then to renew the lease. Type, for example, “sudodhclient –reth0” to do the release followed by “sudodhclient eth0” to renew the lease.Figure 5: Releasing and renewing the IP address on Windows 3.Once you have captured some DHCP traffic, stop the capture.Step 2: Inspect the TraceIn this step and the steps that follow, we will inspect only the short DHCP exchange described above. This is because the traffic you have captured can vary widely across settings. You may have as few as two DHCP packets on a quiet network or many DHCP packets on a busy network (especially if a class is running this lab!). The details of DHCP packets may vary depending on how the computers implement DHCP. There may be multiple packets of a single kind in an exchange due to replicated servers, and dif-ferent types of DHCP packets too.Look for the shortDHCP exchange (of a DHCP Request packet followed by a DHCP Ack packet) in your trace. Select the DHCP Request packet, and observe the protocol stack to see how DHCP messages are carried. The link protocol is likely Ethernet, and the next higher protocol is IP. Then comes UDP, so each DHCP message is carried in a UDP packet. On top of UDP, Wireshark is likely to say BOOTP (Bootstrap Protocol) instead of DHCP. This is a bit confusing, but DHCP is implemented as an extension of an older protocol called BOOTP. You can think of the BOOTP section as the DHCP header and message. An exam-ple window is shown below.Figure 3: Capture of DHCP packets, showing details of a DHCP RequestExpand the BOOTP (DHCP) section (using the “+” expander or icon) to look at the details of a DHCP Re-quest message. There are many fields, and we will only point out a few rather than cover them all. These fields are carried in all DHCP messages, though they have different values in different messages.∙The message begins with a Message Type. It is a Boot Request, which is used for all DHCP mes-sages sent from your computer to a DHCP server.∙After a few fields there is a Transaction ID field. All DHCP packets in a specific exchange betweena client and server carry the same transaction ID; that is how both ends know that the packetsbelong to the exchange rather than another concurrent DHCP operation.∙There are several IP address fields. These fields are used to carry IP addresses such as the one that the computer is being assigned.∙There is a Magic Cookie field. It carries a value that indicates the rest of the message contains a series of DHCP Options. That is, this really is a DHCP message, not a BOOTP message.∙Each DHCP option is self-contained, with a type code saying what it represents, along with a length and value. The first option is DHCP Message Type, which says what kind of DHCP message is being carried. The other options vary with the type of DHCP message. For example, a DHCPRequest will have aRequested IP Address option to ask for a specific address, which a DHCP Ack will have a IP Address Lease Time option to say for how long the IP address is being assigned.Now select a DHCP Ack packet and compare the BOOTP fields. We will ask questions about these fields in the next section, but for now want you to observe that the DHCP Ack has the same overall format, but different values for the fields and carries different DHCP options.You can browse the options for DHCP Requests and Acks to learn about DHCP. You can see, for example, how long the IP address is assigned by the server, whether seconds, minutes, hours or days.You will also see the other configuration parameters that are assigned by the DHCP server, such as the IP address of the domain name server and router, the subnet mask, the domain name for the host, and more.You can also try to make out the whole sequence of DHCP messages that is exchanged for your network setup. If may be as simple as the short exchange of Request and Ack, or it may be the complete ex-change of Discover, Offer, Request and Ack. It may have additional messages such as Release, and it may have multiple of the messages (e.g., two or more Offers or Acks) due to multiple local DHCP servers. Complicating the exchange with your computer is that the trace may capture concurrent DHCP traffic from other local computers. You can use the Transaction IDs to separate the different exchanges, and look at the Ethernet source address to see which DHCP messages were sent by your computer. It is likely that other DHCP traffic is mixed in with your exchange.Step 3: Details of DHCP MessagesSpend time understanding DHCP. Note the position of the Ethernet, IP, UDP, and BOOTP protocol block. Answer the following questions based on your examination of the BOOTP/DHCP fields for both the DHCP Request and DHCP Ack. Answers on next page.1.What are the two values of the BOOTP Message Type field?2.How long is the Transaction ID field? Say whether it is likely that concurrent DHCP operationsdone by different computers will happen to pick the same Transaction ID.3.What is the name of the field that carries the IP address that is being assigned to the client?Youwill find this field filled in on the DHCP Ack, as that message is completing the assignment.4. What is the value of the Magic Cookie that stands for DHCP?5.The first DHCP option is DHCP Message Type. What option value stands for this type?6.DHCP Requests will typically have a Client Identifier option. Look at the value of this option. Howdoes it identify the client? Take a guess.7.DHCP Acks will typically have a Server Identifier option. Look at the value of this option. Howdoes it identify the server? Take a guess.8.What option value stands for the Requested IP Address option? And for the IP Address LeaseTime option?9.How does the recipient of a DHCP message know that it has reached the last option?Step 3: Answers to details of DHCP MessagesFigure 1: Structure of a DHCP message1. The two values are Boot Request (1) and Boot Reply (2).2. The Transaction ID is 4 bytes long. Thus it is very unlikely that there will be collisions in a relative-ly small number of concurrent DHCP operations (until that number approaches 216!)3.The “Your (client) IP address” field carries the IP address being leased to the client. 4.The DHCP magic cookie value is 0x63825363. 5. The option value of 53 stands for DHCP Message Type.6. It is typical for the Client Identifier to carry the Ethernet address of the client, but possible to use some other kind of identifier (e.g., hostname, serial number).7. It is typical for the Server Identifier to carry the IP address of the DHCP server, but possible to use some other kind of identifier.8. The option value of 50 stands for Requested IP Address and the value of 51 stands for IP Address Lease Time.9. The end of the DHCP options is identified with a DHCP option called End with value 255. Ether-net IP header UDP header BOOTP fields DHCP Op-tionsStep 4: DHCP Message AddressingNow we will look at how DHCP messages are addressed to computers at the UDP, IP and Ethernet layers. This is interesting because DHCP is used to assign IP addresses – a computer requesting a DHCP address may neither have its own IP address nor know the IP address of the DHCP server.Start by selecting a DHCP Request packet and looking at its UDP details in the middle Wireshark panel. We will only look at the DHCP Request message to keep things simple, as the details of addressing differ for other DHCP messages. Answers on next page.1.What port number does the DHCP client use, and what port number does the DHCP server use?Ports matter because UDP messages are addressed using ports. Both of these port numbers are on the Request in the source and destination port fields (and you will also see them on the Ack). Now look at the IP addresses in the IP protocol header of the packet for the next question. Do not look inside the BOOTP fields for the DHCP parameters, as we care about how DHCP messages are addressed at lower protocol layers. When the request is sent, your computer has no IP address and may not even know the IP address of the DHCP server, so the IP addressing differs from a routine IP packet.2.What source IP address is put on the Request message?It is a special value meaning “this hoston this network” used for initialization.3.What destination IP address is put on the Request message? It is also a reserved value designedto reach the DHCP server wherever it is on the local network.Finally, look at the Ethernet addresses for the next question.4.What source Ethernet address is put on the Request message, and what destination Ethernetaddress is put on the Request message? One of these addresses is a reserved address. Looking at the addressing should help you to understand why your computer may record the DHCP traf-fic of other local computers in your trace. Since the IP addressing is not yet established, many DHCP messages are sent to all computers on the local network. This makes sure every computer receives DHCP messages intended for them, but it poses a difficulty: one computer may receive DHCP messages intended for another computer.5.How does a computer work out whether a DHCP message it receives is intended as a reply to itsDHCP Request message, and not a reply to another computer? Hint: if you are not sure then go over the fields you inspected previously in Step 2 above.Step 4: Answers to DHCP Message Addressing1. The DHCP client (your computer) uses UDP port 68 and the DHCP server uses UDP port 67.2. The source IP address is 0.0.0.0. It is a special address used during address initialization.3. The destination IP address is 255.255.255.255. It is the broadcast address, which means the mes-sage is intended for all computers on the network. (It is not possible to use a more restricted subnet broadcast, e.g., 192.168.255.255, as the subnet mask is not yet known by the client.)4. The source Ethernet addres s is simply your own computer’s Ethernet address, since that is a l-ready assigned to your NIC. The destination Ethernet address is ff:ff:ff:ff:ff:ff, the reserved broadcast Ethernet address, so that the packet reaches all computers on the local network.5. The DHCP messages in a single exchange carry the same Transaction ID. Thus a computer looks for a DHCP reply such as an Ack with a Transaction ID that matches the value it placed on the earlier DHCP message such as a Request. (This is in addition to any Ethernet address filtering: if the reply is un-icast then it will have the computer’s Ethernet address as its destination.)。
项目3 DNS参考答案
1.安装 DNS
（1）先打开虚拟机的添加角色功能在以下选项中勾选 DNS 服务器，然后完 成安装。
（2）右击我的电脑，点开属性－＞更改设置－＞更改计算机名－＞改名为 孔余（提示重启－＞重启）
（3）打开设置，点击网络适配器，设置虚拟机网卡为ＶＭｎｅｔ８
（4）打开虚拟机的网络和共享中心，关闭防火墙，设置 IP 地址为 192.168.85.35，DNS 服务器为 192.168.85.35
（5）打开物理机的网络和共享中心，打开更改适配器设置，点击 VMn）进入虚拟机的 NDS，配置 DNS 的一个主机
二、验证配置结果 1.步骤说明
从物理机 ping 刚配置的 DNS，输入 DNS 的域名，从虚拟机 ping 刚配置的 DNS， 输入 DNS 的域名，ping 效果如下：
DNS习题
DNS习题
一、填空
⒈ DNS是一个分布式数据库系统，它提供将域名转换成对应的（）信息。
⒉域名空间由（）和（）两部分组成。
二、选择
⒈ DNS区域有三种类型分别是：( )
A. 标准辅助区域
B．逆向解析区域
C. Active Directory 集成区域
D. 标准主要区域
2. 应用层DNS协议主要用于实现哪种网络服务功能( )
A. 网络设备名字到IP地址的映射
B. 网络硬件地址到IP地址的映射
C. 进程地址到IP地址的映射
D. 用户名到进程地址的映射
3.测试DNS主要使用以下哪个命令( )
A. Ping
B. IPcofig
C. nslookup
D. Winipcfg
三、问答
⒈简述DNS服务器的工作过程？
⒉什么是域名解析？
第十章 DNS答案
一．填空：
1. IP地址
2. 根域、顶级域
二．选择：
1．ACD
2．A
3. C
三．问答：
1．用户要想通过使用InternetExplorer来访问万维网服务器，则用户必须首先获得与万维网服务器的正式域名相关的IP地址，依靠DNS及WINS将主机名称转换为IP地址，这个过程被称为主机名称解析（NameResolution）。
一旦用户的计算机将WWW服务器的正式名称解析为它的IP地址，它就可以与WWW服务器建立起TCP/IP网络通信。
2．将主机名称转换为IP地址，这个过程被称为主机名称解析（域名解析）。
使用Wireshark查看局域网内安全系统问地训练题目
使用Wireshark查看局域网内安全问题早就听说过局域网的安全性有问题，但是也一直没放在心上，祥子是计算机专业毕业的，平时上网行为很规矩，从不上那些乱七八糟的网站，小方格子里有自己专用的电脑，里面装着网络版的杀毒软件，定时更新病毒库，系统里装着360安全卫生，系统的漏洞啊、补丁啊什么的都堵上和补上了，这样在局域网还能不安全吗？至少，自己认为是安全的，而且相对于同事们经常重装系统的行为，自己的系统重装的次数是少多了，那么真的是这样吗？让我们用几款软件试试吧。
虚拟机：安全检测的有效工具为什么要这样，那些检测局域网安全性的软件不能直接安装在机器上吗，当然不能，第一，这些软件很多会被杀毒软件当作病毒给杀掉，第二，你打算直接拿这些软件来对别人的机器进行测试吗？不安全，太不安全了，无论是对别人还是对自己来说都太不安全了。
所以我们要先装一个虚拟机，里面装一个“裸奔”的XP系统就可以了，所有的软件都装在这个虚拟的系统里面，自己对自己进行测试，学习了，再拿到局域网中进行实验，这样无论对别人还是自己都是负责任的，虚拟机本次安装的是VMware6.0.2这个版本。
用Sniffer工具抓取用户名/密码SNIFFER软件有很多，比如大名鼎鼎的Sniffer Pro 4.7，但是这款软件太大了，不好上手（但是经典就是经典，祥子以后会为大家介绍这款软件的使用的），这次我们选一个轻量级的Wireshark，它的使用也是非常简单，这没什么说的，双击该程序的图标启动即可。
点击“List the available capture interfaces”按钮，按中自己的网卡，再点“Options”，再点“Start”，就可以开始监控本网段内的一切网络活动了。
我们在真实的机器上进行一次FTP操作，查看捕获到用户名/密码：这时就可以看到有数据记录了，点“Stop”，再选中“Info”栏中带有“ftp[SYN]”字样的一栏（因为在FTP的同步过程中会传输用户名和密码），点右键，选择“Follow TCP Stream”如图1所示，我们就得到了一次FTP操作的用户名和密码。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Lab Exercise – DNSObjectiveDNS (Domain Name System) is the system & protocol that translates domain names to IP addresses . Step 1: Analyse the supplied DNS TraceHere we examine the supplied trace of a browser making DNS requests as follows.The trace is here: /~kevin/com320/labs/wireshark/trace-dns.pcapunch Wireshark and start a capture with a filter of “udp port 53”.We use this filterbe-cause there is no shorthand for DNS, but DNS is normally carried on UDP port 53.Figure 3: Setting up the capture optionsStep 2: Inspect the TraceTo explore the details of DNS packets, select a DNS query expand its Domain Name System block (by us-ing the “+” expander or icon). Your display should be similar to the one shown in our figure, with a series of packets with protocol DNS.. We have selected the first DNS message.Figure 3: Trace of DNStraffic showing the details of the DNS headerLook for the following details:∙The DNS block follows the IP and UDP blocks. This is because DNS messages are carried in UDP segments within IP packets. You will see that the UDP port used by a nameserver is 53.∙The DNS header starts with a Transaction ID that is used to link a request and the corresponding reply – they both carry the same Transaction ID.∙Next come a set of flags that you can expand. They indicate whether the DNS message is a query or response, amongst other details.∙Then comethe number of query, answer, authority and additional records. These fields conclude the header.∙After the DNS header, the remainder of the message consists of the indicated number of query, answer, authority and additional records. Often there will be only one query – for the IP address of the domain name we are seeking – but there may be many of the other records. Theserecords are grouped in sections, such as the Authority section for all of the authority records.Each query has a Type code that indicates the kind of record sought, whether an IP address orotherwise. Each of the other recordsalso has a Type code that indicates whether it carries an IP address of a host, the name of a nameserver, or something else. The format of an individualrecord depends on its type. The entire DNS message is designed to fit within one UDP message.∙Wireshark may show other information, such as the number of the packet that carries the re-sponse to this request or the response time for the DNS exchange, but this is derived informa-tion. It is not actually carried on any packet.Repeat the above to look at a DNS response. You should see a larger set of records in this message; while DNS queries mostly serve to carry the query, DNS responses often return a set of useful information.Step 3: Details of DNS MessagesSelect the first DNS querypacket in your trace, with the first several packetscorresponding to earlier dig commands. To check, see if there are several queries that list the domain you chose in the Info column, each followed by a response.Look at the DNS header, and answer the following questions: (Answers on next page).1.How many bits long is the Transaction ID? Based on this length, take your best guess as to howlikely it is that concurrent transactions will use the same transaction ID.2.Which flag bit and what values signifies whether the DNS message is a query or response?3.How many bytes long is the entire DNS header? Use information in the bottom status line whenyou select parts of the packet and the bottom panel to help you work this out.Now examine the responses to DNS queries in the trace.The initial response should have provided another nameserver one step closer to the nameserver, but not the final answer. You should find that it includes the original query in its Query section. It will also include records with both the name of the nameservers to contact next, and the IP addresses of those nameservers. The final response in this se-ries will include the IP address of the domain name – this is the answer to the query.Look at the body of the DNS response messages, and answer the following questions: (answers overleaf)4.For the initial response, in what section are the names of the nameservers carried? What is theType of the records that carry nameserver names?5.Similarly, in what section are the IP addresses of the nameservers carried, and what is the Typeof the records that carry the IP addresses?6.For the final response, in what section is the IP address of the domain name carried?Answers to Step 3: Details of DNS Messages1.The Transaction ID is 16 bits long, which makes collisions unlikely,. Since the host computer issetting this value, it can use all 2^16 choices before repeating. This means that 2^16query/response pairs would need to be outstanding at the same time to cause a collision. For a normal computer, this is an extremely or implausibly high DNS workload.2.The first flag bit signifies query or response. A “0” indicates a query, and hence a “1” a response.3.The DNS header is 12 bytes long.4.The names of name servers are carried in the Authority section in an NS (NameServer) record.5.The IP addresses of the name servers are carried in the Additional section. The Type of record isA, for an IPv4 address, or AAAA for an IPv6 address.6.The IP address of the queried domain name is carried in the Answer section (in an A or AAAArecord.)Step 4: DNS Response TimeTo conclude this lab, we will look at the DNS response time of the DNS queries. This is a normal DNS usage, in which a computer sends a single query and receives the answer in the response. The response time is the delay between when the computer sends the query to the local nameserver and when it receives the response from the local nameserver. This time includes the time taken by the local name-server to contact remote nameservers, if the answer is not cached. Since this response time can delay connections to sites, it should be as small as possible.Proceed as follows to generate an “IO Graph” of the DNS response time s. IO graphs are a standard fea-ture of Wireshark available under the Statistics menu. By default, this graph shows the rate of packets over time. We will tweak it to show the DNS response time over the trace with the following changes: ∙On the x-axis, adjust the tick interval and pixels per tick for viewing. The tick interval should be small enough to see into the behavior over the trace.One second is probably a good choice foryour trace. The pixels per tick can be adjusted to make the graph wider or narrower to fill thewindow; you can also adjust the width of the window.∙On the y-axis, change the unit to be “Advanced”. The default is Packet/Tick. “Advanced” is a special keyword that will let us access different data values to graph. Once you select it, a new“Calc:” box will appear to let us specify the data values.∙Enter “dns.time” into the calculation box and set the pull-down menu to be“MAX(*)”.dns.time is a virtual field calculated by Wireshark from the query and responsemessages. It is shown with DNS responses, and gives the DNS response time. Choosing “MAX(*)”will let us see the largest DNS response time in every tick interval so that we can spot outliers.“AVG(*)” would also be a reasonable choice.∙Press Enter, and click the “Graph” button ifnecessary. You may need to do this to trigger a redis-play. You should now have a graph of response times similar to our graph in the figure below. We expect that you will see many small DNS response times, and a scattering of larger DNS response times. In our graph, most times are very small, likely because the correct answer is cached by the local nameserver. In some cases, however, there is a longer delay of hundreds of milliseconds as remote na-meservers must be queried. You can click a point on the graph to be taken to the nearest point in the trace if there is a feature you would like to investigate.Figure 4: DNS response time via an IO graphIf you look over the DNS traffic caused by your browser, you are likely to see a greater range of beha-viors than in the DNS traffic caused by the dig commands. This behavior might include new types of records, such as CNAME (canonical name, to provide information about aliases when one machine is known by multiple names), answers that indicate that a name does not exist, and so forth. Explore Your NetworkWe encourage you to explore DNSon your own once you have completed this lab. Some ideas:∙Look up other types of DNS records, such as MX to find the mail server for a domain, and AAAA to find the IPv6 address of a domain.∙Google provides an alternate DNS nameserver system that you may use called “Google P ublic DNS”. Look it up, and follow the configuration instructions to test it out. Experiment to see ifthis DNS service is faster than your existing DNS arrangement.。