EXPERIMENT​ ​- ​1

ADVANCED CYBER SECURITY -

4028

NAME: ​JITESH KUMAR SINGH

REGD NO: ​18BCN7062
PROFESSOR: ​Mr. Somya Ranjan Sahoo
1Q) Each line in the top pane of the Wireshark window corresponds to a
single packet seen on the network. The default display shows the time of
the packet (relative to the initiation of the capture), the source and
destination IP addresses, the protocol used and some information about
the packet. Learn Wireshark color coding from help documents.
Ans​:-
Wireshark color codes packets based on coloring rules. It comes with several of these built-in, but
not everyone knows you can define your own custom coloring rules. To view the built-in coloring
rules or to create your own, go to View > Coloring Rules.
The coloring rules are defined using the Wireshark display filter syntax based on individual
protocol dissectors, among other things. These are the same filter expressions you plug into the
filter bar at the top of the screen.

In most cases, I apply coloring rules to individual conversations.​ That’s even easier. Pick a
packet in a capture file, right-click it, and hover over Colorize Conversation. The slide-out menu
will reveal options that allow you to define the type of conversation (IPv4, IPv6, TCP, etc).
2Q) To locate specific packets related to individual requests or responses
from a within larger capture containing more traffic, we can perform even
more specific filtering using a variety of expressions relating to various
header fields and their contents. Study how to apply a display filter to the
captured packets.
Ans​:-
If you’re trying to inspect something specific, such as the traffic a program sends
when phoning home, it helps to close down all other applications using the
network so you can narrow down the traffic. Still, you’ll likely have a large amount
of packets to sift through. That’s where Wireshark’s filters come in.
The most basic way to apply a filter is by typing it into the filter box at the top of
the window and clicking Apply (or pressing Enter). For example, type “dns” and
you’ll see only DNS packets. When you start typing, Wireshark will help you
autocomplete your filter.

We can also click Analyze > Display Filters to choose a filter from among the
default filters included in Wireshark. From here, we can add our own custom
filters and save them to easily access them in the future.
Another interesting thing we can do is right-click a packet and select Follow >
UDP Stream.We’ll see the full TCP conversation between the client and the
server. We can also click other protocols in the Follow menu to see the full
conversations for other protocols, if applicable
Close the window and we’ll find a filter has been applied automatically. Wireshark
is showing us the packets that make up the conversation.
3Q) Use your Web browser to access a file from a Web server. Using Wireshark
captures the packets arriving at your computer. Also download a
Wireshark-readable packet trace from the Web server from which you
downloaded the file. Using this server trace

● Evaluate the performance of the TCP connection between your

computer and the Web server.
● Trace TCP’s window behavior, and infer packet loss, retransmission, flow
control and congestion control behavior, and estimated roundtrip time.
Ans​:-
● Find the packets that were generated by your own access of the
Web server.
Start up the Wireshark program (select an interface and press start to capture packets).

In your browser, go to Wayne State homepage by typing www.wayne.edu.

After your browser has displayed the http://www.wayne.edu page, stop Wireshark
packet capture by selecting stop in the Wireshark capture window. This will cause the
Wireshark capture window to disappear and the main Wireshark window to display all
packets captured since you began packet capture see image below:
You now have live packet data that contains all protocol messages exchanged between
your computer and other network entities! However, as you will notice the HTTP
messages are not clearly shown because there are many other packets included in the
packet capture. Even though the only action you took was to open your browser, there
are many other programs in your computer that communicate via the network in the
background. To filter the connections to the ones we want to focus on, we have to use
the filtering functionality of Wireshark by typing “http” in the filtering field as shown
below:

Notice that we now view only the packets that are of protocol HTTP. However, we also
still do not have the exact communication we want to focus on because using HTTP as
a filter is not descriptive enough to allow us to find our connection to
http://www.wayne.edu. We need to be more precise if we want to capture the correct set
of packets.

To further filter packets in Wireshark, we need to use a more precise filter. By setting the
http.host==www.wayne.edu, we are restricting the view to packets that have as an http
host the www.wayne.edu website. Notice that we need two equal signs to perform the
match “==” not just one. See the screenshot below:

● Analyze the client- and server-side traces to explore aspects of

TCP.
There are many transport layer protocols, of which TCP and UDP are the most popular.
TCP is an acronym for Transmission Control Protocol and it has the following
characteristics:

Connection based: ​In TCP, a connection is established between the two

communicating hosts, and the state of this connection is maintained on the two hosts.
Usually, the two hosts are named client and server and the client is the host who
initiates the connection to the server.
Reliable: ​TCP is a reliable protocol. It will add a checksum to data and headers to
ensure that the received bytes are exactly what was sent. Also, it monitors the state of
transmitted packets and tries to do retransmission for packets that are lost on the way to
their destination.
The TCP is a connection between two hosts

Server:​ This host is normally listening on a certain IP address and a port number
waiting for connections from clients
Client:​ This is the host that initiates the connection to the server

The TCP defines a 3-way handshake mechanism to initiate the connection.

a)​The client starts by sending a synchronization packet (SYN) to the server it needs to
connect to and waits for the server response.
b)​The server responds with a packet containing both an acknowledgement (ACK) that it
received the client’s SYN and a SYN directed to the client.
c)​The client should then reply with an ACK indicating that it received the server SYN
too.

The following sequence diagram illustrates the 3-way handshake process

And this is how the handshake is captured by Wireshark

During this handshake, the client and the server also declare their capabilities for each
other to agree on the common connection parameters to be used between them. Also
during the handshake, each side informs the other one what is its initial sequence
number (ISN).
Every time a host sends a TCP packet, it will contain a sequence number which is the
total number of sent bytes. The sequence number is not initialized with zero, it’s
initialized with a random number ISN for each side of the connection.

The expert view of Wireshark for each TCP packet will display packet parameters, flags,
and options.
The generic TCP parameters on each packet are:
Source port:​ The port number of the side who transmitted this packet
Destination port:​ The port number of the side who should receive this packet
Stream index: ​This is not a real TCP parameter. It’s only a Wireshark representation of
the connection 4 values (source address, source port, destination address, and
destination port). If one of these values changes, the sequence number will differ. This
can happen for example if you are capturing at the server-side and there is more than
one client connected to the server, then each connection will have its sequence number.
TCP segment length: The size of the data contained on this packet
Sequence number:​ This is a Wireshark more readable representation of the sequence
number. It’s calculated starting from 0, so it’s easier to track packets.
Sequence number (raw):​ The actual sequence number sent on the packet — the one
starts from the ISN
Next sequence number:​ Normally it’s the current sequence number + the length of
data in the current packet. This rule doesn’t apply to this packet as it’s a SYN packet,
and the SYN is considered as 1 byte, so the next sequence number increased by 1
seven if there is no data on the packet.
Acknowledgment number:​ This represents the total number of bytes the current
transmitting host received from the other side. This field is also a Wireshark added field
to make it easier to analyze the TCP capture by counting the acknowledgment number
from 0.
Acknowledgment number (raw):​ The real Acknowledgment number.
Header length: ​The TCP header length. This can range from 20 to 60 bytes depending
on the TCP options in the packet.
Window size value:​ This is the receive buffer size in the current transmitting host. The
host here is informing the other side host how many bytes it can receive to avoid the
case of the other side replying with a large number of bytes that can’t be handled.
Checksum:​ Checksum of the TCP packet. This is used by the receiving host to verify
that the received packet is OK
Checksum status:​ By default Wireshark is not verifying the packet checksum, but there
is an option to enable checksum verification.

Congestion window reduced:​ The transmitting host reduced its transmit rate
ECN-Echo:​ the transmitting host received an earlier congestion notification
Urgent:​ Flag the packet as an urgent to inform the OS to handle it in a higher priority
Acknowledgment:​ This flag indicates if the current packet contains an ACK
Push:​ The receiving host should pass the data to the receiving APP as soon as
possible.
Reset:​ Indicates that the connection has some problem and it’s reset from the
transmitting host side.
Syn: ​Indicates that this packet is a SYN packet
Fin: ​Indicate that this is a finalization FIN packet. Will see this later when talking about
closing the TCP connection.
To close the TCP connection, the closing side should send a FIN packet which also
contains an ACK for the last data this side received, then the other side should reply
with an ACK that it received the FIN and notify the application that the other side is
closing the connection. Usually, the application will close the connection too which leads
to another FIN to be sent to the side initiate the close, and wait for an ACK to know that
connection is now closed completely from both sides.
This is the TCP connection close sequence diagram assuming that the client initiated
the connection termination
And this is how the connection close is captured in Wireshark

4Q) Using Wireshark explores the use of the ICMP protocol in the ping and
traceroute commands.
Ans​:-
a) What is the IP address of your host? What is the IP address of the
destination host?
 The IP address of my host is ​103.110.144.26​. The IP address of the destination
host is 143.89.12.134.
b) Why is it that an ICMP packet does not have source and destination port
numbers?

The ICMP packet does not have source and destination port numbers because
it was designed to communicate network-layer information between hosts and
routers, not between application layer processes. Each ICMP packet has a
"Type" and a "Code". The Type/Code combination identifies the specific
message being received. Since the network software itself interprets all ICMP
messages, no port numbers are needed to direct the ICMP message to an
application layer process.
c) Examine one of the ping request packets sent by your host. 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?

The ICMP type is 8, and the code number is 0. The ICMP packet also has
checksum, identifier, sequence number, and data fields. The checksum,
sequence number and identifier fields are two bytes each.
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0x4d3e [correct]
[Checksum Status: Good]
Identifier (BE): 1 (0x0001)
Identifier (LE): 256 (0x0100)
Sequence Number (BE): 29 (0x001d)
Sequence Number (LE): 7424 (0x1d00)
Data (32 bytes)
Data:
6162636465666768696a6b6c6d6e6f7071727374757677616263646566676869[
Length: 32]

d) 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?
 The ICMP type is 0, and the code number is 0. The ICMP packet also has
Checksum, identifier, sequence number, and data fields. The checksum,
sequence number and identifier fields are two bytes each.
Type: 0 (Echo (ping) reply)
Code: 0
Checksum: 0x553e [correct]
[Checksum Status: Good]
Identifier (BE): 1 (0x0001)
Identifier (LE): 256 (0x0100)
Sequence Number (BE): 29 (0x001d)
Sequence Number (LE): 7424 (0x1d00)
[Response time: 88.235 ms]
Data (32 bytes)
Data:
6162636465666768696a6b6c6d6e6f7071727374757677616263646566676869[
Length: 32]
e) What is the IP address of your host? What is the IP address of the target
destination host?
 The IP address of my host is ​103.110.144.26​. The IP address of the destination
host is 128.93.162.83.
f) If ICMP sent UDP packets instead (as in Unix/Linux), would the IP protocol
number still be 01 for the probe packets? If not, what would it be

No. If ICMP sent UDP packets instead, the IP protocol number should be
0x11
g) Examine the ICMP echo packet in your screenshot. Is this different from the
ICMP ping query packets in the first half of this lab? If yes, how so
 The ICMP echo packet has the same fields as the ping query packets.
h) Examine the ICMP error packet in your screenshot. It has more fields than
the ICMP echo packet. What is included in those fields?

The ICMP error packet is not the same as the ping query packets. It contains
both the IP header and the first 8 bytes of the original ICMP packet that the
error is for.
i) Examine the last three ICMP packets received by the source host. How are
these packets different from the ICMP error packets? Why are they different

The last three ICMP packets are message type 0 (echo reply) rather than 11
(TTL expired). They are different because the datagrams have made it all the
way to the destination host before the TTL expired.
j) Within the tracer measurements, is there a link whose delay is significantly
longer than others? Refer to the screenshot in Figure 4, is there a link
whose delay is significantly longer than others? On the basis of the router
names, can you guess the location of the two routers on the end of this
link?

There is a link between steps 7 and 8 that has a significantly longer delay. This is
 a transatlantic link from Mumbai to Marseille, France. In figure , the link is from
Mumbai to MArseilie, France.

5Q) Using Wireshark explore several aspects of the HTTP protocol: the basic
GET/reply interaction, HTTP message formats, retrieving large HTML files,
retrieving HTML files with embedded URLs, persistent and non-persistent
connections, and HTTP authentication and security.
Ans​:-
1.The Basic HTTP GET/response interaction :
Let’s begin our exploration of HTTP by downloading a very simple HTML file - one
that is very short, and contains no embedded objects. Do the following:
• Start up your web browser.
• Start up the Wireshark packet sniffer, as described in the Introductory lab (but don’t
yet begin packet capture). Enter “http” (just the letters, not the quotation marks) in the
display-filter-specification window, so that only captured HTTP messages will be
displayed later in the packet-listing window. (We’re only interested in the HTTP
protocol here, and don’t want to see the clutter of all captured packets).
• Wait a bit more than one minute, and then begin Wireshark packet capture.
• Enter the following to your browser
http://gaia.cs.umass.edu/wireshark-labs/HTTP-wireshark-file1.html
Your browser should display the very simple, one-line HTML file.
• Stop Wireshark packet capture.
the packet-listing window that four HTTP messages were captured: the GET message
(from your browser to the gaia.cs.umass.edu web server) and the response message
from the server to your browser. The packet-contents window shows details of the
selected message (in this case the HTTP GET message, which is highlighted in the
packet-
listing window).
Recall that since the HTTP message was carried inside a TCP segment, which was
carried inside an IP datagram, which was carried within an Ethernet frame, Wireshark
displays the Frame, Ethernet, IP, and TCP packet information as well. We want to
minimize the amount of non-HTTP data displayed (we’re interested in HTTP here, and
will be investigating these other protocols is later labs), so make sure the boxes at the
far left of the Frame, Ethernet, IP and TCP information have a plus sign (which means
there is hidden, undisplayed information), and the HTTP line has a minus sign (which
means that all information about the HTTP message is displayed). Note you should
ignore any HTTP GET and response for favicon.ico.

2. Retrieving Long Documents:

Start up your web browser, and make sure your browser’s cache is cleared.
• Start up the Wireshark packet sniffer
• Enter the following URL into your browser
http://gaia.cs.umass.edu/wireshark-labs/HTTP-wireshark-file3.html Your browser should
display the rather lengthy US Bill of Rights.
• Stop Wireshark packet capture, and enter “http” in the display-filter-specification
window, so that only captured HTTP messages will be displayed.
In the packet-listing window, you should see your HTTP GET message, followed by a
multiple-packet response to your HTTP GET request. This multiple-packet
response deserves a bit of explanation. Recall that the HTTP response message
consists of a status line, followed by header lines, followed by a blank line, followed by
the entity body. In the case of our HTTP GET, the entity body in the response is the
entire requested HTML file. In our case here, the HTML file is rather long, and at 4500
bytes is too large to fit in one TCP packet. The single HTTP response message is thus
broken into several pieces by TCP, with each piece being contained within a
separate TCP segment (see Figure 1.24 in the text). Each TCP segment is recorded as
a separate packet by Wireshark, and the fact that the single HTTP response was
fragmented across multiple TCP packets is indicated by the “Continuation” phrase
displayed by Wireshark.

3. HTML Documents with Embedded Objects:

Start up your web browser, and make sure your browser’s cache is cleared.
• Start up the Wireshark packet sniffer
• Enter the following URL into your browser
http://gaia.cs.umass.edu/wireshark-labs/HTTP-wireshark-file4.html
Your browser should display a short HTML file with two images. These two images are
referenced in the base HTML file. That is, the images themselves are not contained in
the HTML; instead the URLs for the images are contained in the downloaded HTML file.
As discussed in the textbook, your browser will have to retrieve these logos from the
indicated web sites. The publisher’s logo is retrieved from the www.aw-bc.com web site.
The image of the book’s cover is stored at the manic.cs.umass.edu server.
• Stop Wireshark packet capture, and enter “http” in the display-filter-specification
window, so that only captured HTTP messages will be displayed.

6Q)​ ​Using Wireshark perform a packet capture and analysis of an application that
uses UDP (for example, DNS or a multimedia application such as Skype). Also,
investigate the header fields in the UDP segment as well as the checksum
calculation.
Ans​:-
There 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; pick recommended 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.

1. Once Wireshark starts, select the Ethernet interface.

2. Wireshark will automatically start capturing packets on the network. Now, enter a
filter of udp.

3. When the capture is started, it will collect UDP traffic automatically.

4. Wait a little while (say 60 seconds) after you have stopped your activity to also
observe any background 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.
5. Use the Wireshark menus or buttons to stop the capture.
6. You should now have a trace with many UDP packets.

Different 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 middle 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 destined. Ports are the only form of addressing in UDP. The computer is
identified using the IP address 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.

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 by the higher-layer protocol that it carries, e.g., DNS, or RTP.

The figure below shows the UDP message structure as you observed. It shows the
position of the IP header, UDP header, and UDP payload. Within the UDP header, it
shows the position and size of each UDP field. Note how the Length field gives the
length of the UDP payload plus the UDP header. The checksum is 16 bits long and the
UDP header is 8 bytes long.
7Q) Using Wireshark lab perform capture and study the 802.11 frames exchanged
between a wireless laptop and an access point.
Ans​:-
Step 1: Inspect a Trace
1. Open the trace at:https://kevincurran.org/com320/labs/wireshark/trace-80211.pcap
You should see a screen as follows
We will look at the format of an 802.11 frame. There are many kinds of 802.11 frames
that will be captured in a trace; the Info field describes the type, such as Beacon, Data,
and Acknowledgement.

2. Inspect the #16 Data frame, which carries packets across 802.11 networks

3. Inspect the protocol layers recorded with the frame for these protocols by looking in
middle panel
• Frame is a record added by Wireshark with information about the time and length of
the frame; it does not capture bits that were sent “over the air”.
• Radiotap is also a record created by Wireshark to capture physical layer parameters,
such as the strength of the signal and the modulation. Skip this record for now; we will
investigate it later

• IEEE 802.11 is the bits of the 802.11 Data frame. This is the record we are looking for,
and we will go into its details shortly. It is selected and expanded in the next figure so
that you can see the internal fields (in the middle panel) and the portion of the frame it
occupies (highlighted in the lower panel and identified at bottom as 28 bytes long).

• Data is a record containing the frame payload data, i.e., that has higher-layer protocols
such as LLC, IP packets, etc. Alternatively, you may see the higher-layer protocols
themselves.
Note that If Wireshark can understand the contents of the Data frame payload, then it
will create protocol records for them. However, in many wireless settings (such as the
sample trace) the payload contents are encrypted and simply appear as one record. All
frames are then listed as protocol 802.11, rather than higher layer protocols such as
TCP. It is possible to tell Wireshark the wireless network key and have it decrypt the
payloads. However, we will skip that step since our interest is the 802.11 headers

4. Expand the IEEE 802.11 record of the Data frame & inspect the details of the various
header fields.
You can expand this block using the “+” expander or icon. The fields in Wireshark are:
• Frame Control. It encodes the frame Type and Subtype, e.g., Data, as well as various
flags. We
will look at these fields in more detail shortly.
• Duration. This field tells computers how much time is needed on the wireless medium
for additional packets that are part of this exchange.
• BSS identifier, source address, and destination address, in an order that depends on
the specifics
of the Data frame. These address fields identify who transmitted the packet and who
should receive it. The BSS identifier is the address of the wireless access point.
• Fragment and sequence number. These fields number the frame for reassembly and
retransmission, if needed. The sequence number is incremented with each new
transmission.
• Frame check sequence. This is a CRC over the frame. It comes at the end (click it and
you will see
its position in the frame) but is listed with the other 802.11 header fields for
convenience.
• There may also be a WEP or WPA2 field with security parameters in the case that the
frame payload is encrypted. We are not delving into wireless security here, so you can
ignore that field.

5. Expand the Frame Control field and look at it in detail. You find within it.
All 802.11 frames begin with a Frame Control field, and the details of the subfields and
flags determine the format of the rest of the message; it may be like the Data frame we
explored above or very different such as an Ack frame we will look at later. The
subfields are:
• Version, with a value of zero for the current version.
• Type and Subtype specify the type of frame, e.g., Data or Ack.

6. Expand the Flags field and look at it in detail. You find within it.
• To DS. This flag is set if the frame is sent from a computer to the wired network via the
AP.
• From DS. This flag is set if the frame is sent from the wired network to a computer via
the AP.
• More fragments. Set if there are more frames in this message.
• Retry. Set if the frame is a retransmission.
• Power management. Set if the sender will go into power-save sleep after transmission.
• More data. Set if the sender has more frames to send.
• Protected. Set if the frame is encrypted with WEP/WPA2.
• Order. Set if the receiver must keep the frames in order.
Different computers may use these flags differently depending on how they implement
802.11. For example, some computers may make heavy use of power-save or
encryption features while others may not. Combined with the fact that there are dozens
of different types of frames, this means that you will see all sorts of wireless traffic in
most traces.

7. Find the frequency by expanding the Radiotap header of any frame & look for
Channel frequency.
As you’ll see, the Channel frequency is 2462 MHz, or 2.462 GHz. It is known as
“802.11b/g channel 11”.

To look at the modulation we can observe the Data Rate value, and to look at the SNR
we can observe the SSI Signal value (combined with the SSI Noise value). The SSI
Signal value is more commonly known as the RSSI (Received Signal Strength
Indication). These fields will vary with different frames. To see them, first we must add
new columns to the main display.