wireshark练习及答案lab-udp

实验五Wireshark Lab: UDP一、实验目的1.通过wireshark抓包理解应用层UDP协议。

二、实验器材1.PC机电脑一台。

2.Wireshark软件。

三、实验内容1．依照Wireshark Lab 提供的实验步骤完成实验。

2．回答实验中的问题。

四、实验操作实践与步骤The Assignment1. Select one packet. From this packet, determine how many fields there are in the UDP header. (Do not look in the textbook! Answer these questions directly from what you observe in the packet trace.) Name these fields.UDP header fieldThere are 4 fields in the UDP header. They are source port, destination port, length and checksum.2. From the packet content field, determine the length (in bytes) of each of the UDP header fields.Every length of each of the UDP header fields is (4*4)bits. It is equal to 2B. So the length of each of the UDP header fields is 2B.3. The value in the Length field is the length of what? Verify your claimwith your captured UDP packet.55=8+47The value in the Length field is 8 bytes of the UDP header fields and 47 bytes of data fields.4. What is the maximum number of bytes that can be included in a UDPpayload?The maximum number of bytes that can be included in a UDP payload is (2^16-1-8)=65527.5.What is the largest possible source port number?The largest possible source port number is (2^16-1)=65535.6. What is the protocol number for UDP? Give your answer in bothhexadecimal and decimal notation. (To answer this question, you’ll need to look into the IP header.)the protocol numberfor UDP7. Search “UDP” in Google and determine the fields over which the UDP checksum is calculated.The following passage is from the RFC 768.8. Examine a pair of UDP packets in which the first packet is sent by your host and the second packet is a reply to the first packet. Describe the relationship between the port numbers in the two packets.Port numberUDP sent by my hostPort numberUDP reply to my hostThe relationship between the port numbers in the two packets is that:the soure port of the UDP packet sent by my host is the same as the destination port of the reply packet to my host; and the destination port of the UDP packet sent by my host is the same as the source port of the reply packet to my host.Extra Credit1.Capture a small UDP packet. Manually verify the checksum in thispacket. Show all work and explain all steps.Checksum:Checksum=c80bTake the following fields from the packet containing 20 bytes of data shown in figures above.All calculations are done using the hex values.IP header : Source 0a 02…88 29Destination ea 22…17 eaProtocol: UDP 00 1116 bit UDP Length 00 1c五、实验结论通过抓包实验理解并掌握了UDP报文段的各自段含义，对基于UDP运输层的程序加深了记忆，把课文中的知识点有可更深入的了解。

以下是一些可能的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实验⼀答案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。

卓越计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?答：没有看到。

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.。

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.。

实训二利用WireShark分析UDP与DNS包一、实训目的1.学会使用nslookup工具查询并分析Internet 域名信息或诊断DNS 服务器。

2.会用wireshark分析DNS协议。

对DNS协议有个全面的学习与了解。

二、实训器材1.接入Internet的计算机主机；2.抓包工具WireShark。

三、实训内容一、DNS包分析实验1.启动WireShark，并开始抓包。

2.运行 nslookup 发现广工大或其它大学的官方DNS服务器。

如：nslookup –type=NS （或其它网址，如：中大，剑桥大学，北大，……）实验结果举例：3.运行nslookup 向其中一个DNS服务器请求Yahoo!的地址。

实验结果举例：4.停止抓包，显示过滤DNS包，查看其请求包和响应包的运输层协议是UDP 还是 TCP?答：都是UDP。

5.DNS请求包的目的端口及 DNS响应包的源端口号分别是多少？答：都是53。

6.DNS 请求包是发往哪个地址的？用ipconfig查看你的本地DNS服务器的IP地址，它们两个相同吗？答：它们两个地址相同。

7.检查DNS 请求包，其类型是什么？请求包里有应答信息吗？答：DNS请求包的类型是UDP,没有应答信息。

8.检查DNS应答包，其中包含多少“answers”,其中含有什么信息？答：包含3个answers.其中type类型为CNAME，说明规范主机名为，IP地址为115.239.210.26，115.239.210.2,79.查看接下来你的主机发出的一些TCP SYN 包，其中的目的IP地址是否有刚才DNS应答包中的IP地址?答：有。

10.访问网页，当网页中包含图片时，取回这些图片之前，是否会触发一个新的DNS请求？答：根据具体情况会有不同的结果。

11.查看DNS应答包，你选择的新的DNS服务器应答包提供了什么？其中包括你选择的新DNS服务器的IP地址码？答：所提供的信息如下，其中包括自己的IP地址12.查看DNS请求包的目的地址、是否是你的本地DNS服务器的地址？若不是，这些IP地址指的是什么？答：是。

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.。

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……。