section 1 (25 points) - clemson universityyfeaste/cybersecurity/cpsc424/exa… · private class...

1

CPSC 424/624

Exam 2 Solutions (last update: 5/3/2017)

Take home- open everything except other people!!!

Spring 2017

(Note: there are no questions that are just for 624 students)

Please submit to turnitin

Name:

Section 1 (25 points)

Please answer the following T/F, fill in the blank or short answer questions (2 points each, except Q1.11 is 3 points)

Q 1.1 The difference between end user authentication and message authentication is that the latter also provides message data confidentiality. (True or False)

Solution: False.

Q 1.2 If the setuid bit is set on an executable file, when run, the program will have the privileges of the ______________ of the file instead of the real user.

Solution: the privileges of the owner of the file. Other acceptable answers: author,

Not acceptable : root,

Q 1.3 Assume we run the apache web server on our VM. In a directory containing content, I issue the following command

>ls -lt hw1-sol.pdf

-rw-rw-rw- 1 jjm cuuser 465020 Mar 4 11:25 hw1-sol.pdf

Use the appropriate unix command to set the file permissions to be more reasonable for a content file.

What does the ‘1’ field represent?

Solution:

chmod 644 hw1-sol.pdf,

2

chmod g-w w

The 1 represents the number of links to the file.

Q 1.4 Identify the most appropriate method to determine if a particular package has been installed on your Ubuntu VM.

Solution: sudo apt-cache search mpstat or sudo dpkg –s (or –l) pkgname

Note that apt-cache is a bit more helpful… example using mpstat. This is a program that is included in sysstats package. Apt-cache search mpstat tells you that, dpkg –l mpstat does not. But both work with a valid pkgname (such as sysstats).

We will not count ‘which pkgname’ . This will tell us if a program (like mpstat) is installed. But it does not tell us about the package.

Also, we won’t count the use of find. If we issue ‘find / -name sysstats –ls’ it won’t find the package.

Q 1.5 Consider the following four commands from a bash terminal. What gets displayed by the echo ?

a=”5+2”

b=(5+2)

c=$((5+2))

echo “$a $b $c”

Solution: echo "$a $b $c"

5+2 5+2 7

Note, a=’5+2’ gives same result as a=”5+2” Q 1.6 Give an example of a Unix signal. And then give two example dispositions for the signal. Solution: a SIG-INT (CNT-C). The disposition is the action taken by the process or program when the signal is received. Two examples: a program can catch the signal; a program can chose to ignore the signal.

3

Q 1.7 The paper “The UNIX Time-Sharing System” indicates that ______________ files are used to abstract I/O devices using the Unix file system interface.

Solution: special files. For example a disk drive might have a special file called /dev/sda1.

Q 1.8 One difference between indirect and direct IP forwarding is that indirect forwarding involves a ___________________.

Solution: router

Q 1.9 Network Address Port Translation (NAPT) allows multiple hosts on a _____________ network to share a single public IP address.

Solution: private

Q 1.10 In several homework and exercises we used one of our VMs (call it VM1) as a router. We setup a private network (called a host only network in Virtual Box) between VM1 and VM2. We then had to perform two network configuration steps at VM1 in order for the other VM (VM2) to communicate to the Internet through VM1. What were these two additional steps? I don’t expect you to know the exact details of the two steps, just give a 3-4 word description of the purpose of each step.

Solution: First we configured VM1 to enable IP forwarding.

Second, we enabled NAT for packets flowing from the private network side to the interface that was used by VM1 to communicate with the base host OS’s networking stack.

Q 1.11 In our Virtual Box setup, VM1 (described above) is assigned a 32 bit IP address of 10.0.2.15.

a. Indicate if this address is class A, B, or C….please explain your answer. b. Explain why this address is referred to as ‘private’. Give a 2 sentence

definition of private IP addresses. Solution: Look at the first few bits of the most significant octet (10): 0000 1010 The first bit is 0 which makes this a class A address.

4

Certain blocks of 32 bit IP addresses are designated as ‘private’. One block of private class “A” addresses is 10/24. TCP/IP does not treat a private IP address any different from non-private IP addresses with one exception: packets that contain a private address (either as the source or destination) can NOT be routed over the public Internet. Further, they could be routable within an organization’s network if it is designed correctly. This means that within an organization, if 10/24 IPs are routed, there can not be two networks with the same network address. As long as these rules are met, private addresses can be reused any number of times. This, along with the use of NAT to allow private IPs to internetwork with the Internet, greatly helps ensure there are enough IPv4 addresses. Q 1.12 When you login to a website (for email or some web service) you typically provide a userid and a secret password. Two-factor authentication adds more security. In fact, our campus VPN now requires two-factor authentication. . Identify two different techniques that can be used to provide the second factor.

Solution: The second factor is usually ‘something you have’. So it might send you an email with a second, temporary password. The book says the second factor might be a challenge/response of some sort. A second example therefore could be if the web site asks you one of the security questions it had asked you when your account was first setup.

5

Section 2 Security Questions (20) Q2.1 One simple substitution cipher is the Ceasar Cipher. In one sentence explain how a Ceasar Cipher works. Solution: A Ceasar Cipher is a substitution cipher in which each letter in the plaintext is 'shifted' a certain number (i.e., the key) of places down the alphabet. Additionally, please encrypt the following cleartext using a Ceasar Cipher assuming a key of 2. You do not need to worry about the spaces….for simplicity assume your algorithm retains spaces. Assume only lowercase letters. Cleartext message: “i hope i do well on this exam” Solution: abcdefghijklmnopqrstuvwxyz i hope i do well on this exam k jqrg k fq ygnn qp vjku gzco The following is a line of ciphertext that has been encrypted using a Ceasar Cipher. You do not know the key. Crack the code….identify the cleartext message. Ciphertext message: “j xjmm ep xfmm” Solution: Cleartext message: “i will do well” based on a key of 1 Q2.2 Issue a man of openssh and md5sum. Read this page that talks about using md5 hashes for manually checking the data integrity of a downloaded ISO. https://help.ubuntu.com/community/HowToMD5SUM

On some web sites that host files or packages for download (e.g., Linux ISO’s), they might include a message digest. Find one such example, download the file, compute the md5 hash on your VM and compare with the published md5. In your answer, indicate the web link, cut and paste the posted md5 and the results from your local md5 (md5sum is probably the easiest to use). Explain why, for example, we would want to do this when downloading a Linux ISO.

6

Solution: if you used another hash such as sha that is ok…also you did not need to specifically find a ISO for your example.

Part 1 - One example is here : http://releases.ubuntu.com/16.04.2/MD5SUMS

This contains the md5 hash for a set of ISO downloads. You would download one of the files to your VM. Run md5sum on the ISO and it should be exactly what is shown in the MD5SUMS file.

As another example, iperf3 (https://iperf.fr/download) has many versions if iperf and maintains the sha256 hash of each in the file sha256.txt . For example, iperf3-3.1.3 has an entry :

e34cf60cffc80aa1322d2c3a9b81e662c2576d2b03e53ddf1079615634e6f553 iperf-3.1.3-source.tar.gz

You would just need to run sha256sum iperf-3.1.3-source.tar.gz and it shows a matching hash

Part 2 - The simple answer (which is fully correct) is that if you provide a file (ISO, tar.gz, or whatever) for others to download, you can generate a hash (like md5) and post this as well. If someone downloads your file – they can run md5sum on the downloaded file and compare with your posted hash. They should be the sum. If not then that person should not use the file they downloaded.

The more complex answer (which is correct) is that the person in the example above that downloaded your file trusts that the data download from you. Similar to the issue of Bob encrypting a message for Alice that uses Alice’s public key. How does he know that Alice’s public key is really from Alice? We need trusted PKI.

For the download problem, it appears that most web sites post signed versions of the hash. So you download the signed hash and then obtain the public key from the web site. A tool such as Gnupg makes it very easy to sign documents, to verify a signed document, to verify and unpack a signed document.

https://www.gnupg.org/gph/en/manual/x135.html

http://releases.ubuntu.com/16.04.2/MD5SUMS

https://iperf.fr/download

7

Section 3 Network.Security Questions (55) Q3.1 Name 4 pieces of information in an IP packet header AND another 4 pieces of information in a TCP header. Solution:

Any of the fields are acceptable - even IP or TCP options. Although we will accept only one option for IP fields and one option for TCP fields. Q3.2 Issue a wget http://www.cs.clemson.edu/~jmarty/data.dat on your VM. Prior to downloading the file, start tcpdump to get a packet trace of the TCP transfer writing the trace to a file. Use tcpdump a second time to read the trace file to produce the human readable form of the trace (just a summary, one packet producing one line of trace information). To answer some of these questions you might need to create a readable trace that includes the data in hex/asci. You can use wireshark, but your answer must show results from terminal based tcpdump.

Show/list this summary trace (not including the data in hex/asci!!)

MAC Header IP Header TCP Header TCP Application Data

First bit Last bit

TCP Segment

http://www.cs.clemson.edu/~jmarty/data.dat

8

Show the details of the first three packets (the three way handshake) - include the data in hex/asci.

In the data of each packet, circle the following : o The IP header length field, and interpret the data to show the size of

the header in bytes. o The IP total length field and interpret the data to show the size of the

packet in bytes. o The TCP offset field and interpret the data to show the size of the TCP

header in bytes Show the growth of the TCP window of the sending side (the web server).

Include the three way handshake segments to help sync your sequence/ack numbers. Simplify by translating the observed segment sequence numbers from byte counts to a count of packets, beginning with seq # 0 (the first SYN-ACk sent by the web server)

Example: not including three way handshake, the sender’s first 3 segments assuming its initial window is 1 segment and the receiver ACK’s every data segment that arrives. Send Rx ------ seq 1 (data size x bytes) -- ack 2 (data size 0, ack’s seq 1) ----- seq2 (data size x) --- seq3 (data size x) -- ack 3 -- ack4 ….. Solution. For those that used the original link (www.cs.clemson.edu/~jmarty/data.dat ), this was problematic as a redirect was involved… this complicates what you would see. The solution shown here uses a lab machine (netlab). My network diagram was: Netlab.cs.clemson.edu ----- HostOS ---- VM1 ----- VM2 At VM2, issued: wget http://netlab.cs.clemson.edu/data.dat Also at VM2: sudo tcpdump –i eth0 –w mytrace.dmp ‘host netlab.cs.clemson.edu’ To produce the summary shown below: sudo tcpdump –nn –tt –r mytrace.dmp > mytrace.sum Note, also obtained a tcpdump of the transfer from netlab.

Show/list this summary trace (not including the data in hex/asci!!)

http://www.cs.clemson.edu/~jmarty/data.dat

http://netlab.cs.clemson.edu/data.dat

9

The following is summary #1 (call it SUM1) from VM2’s vantage:

1493759382.537701 IP 192.168.2.100.48440 > 130.127.49.7.80: Flags [S], seq 657222341, win 29200,

options [mss 1460,sackOK,TS val 1747656 ecr 0,nop,wscale 7], length 0

1493759382.540678 IP 130.127.49.7.80 > 192.168.2.100.48440: Flags [S.], seq 2694737409, ack

657222342, win 65535, options [mss 1460], length 0

1493759382.540712 IP 192.168.2.100.48440 > 130.127.49.7.80: Flags [.], ack 1, win 29200, length 0

1493759382.540816 IP 192.168.2.100.48440 > 130.127.49.7.80: Flags [P.], seq 1:128, ack 1, win 29200,

length 127: HTTP: GET /data.dat HTTP/1.1


1493759382.552176 IP 130.127.49.7.80 > 192.168.2.100.48440: Flags [P.], seq 1:1461, ack 128, win

65535, length 1460: HTTP: HTTP/1.1 200 OK


1493759382.552540 IP 130.127.49.7.80 > 192.168.2.100.48440: Flags [.], seq 1461:2881, ack 128, win

65535, length 1420: HTTP

















1493759382.557881 IP 130.127.49.7.80 > 192.168.2.100.48440: Flags [F.], seq 21092, ack 128, win 65535,

length 0


length 0


The following is summary #2 (call it SUM2) from netlab’s vantage:

From netlab’s vantage pt:

1493752442.147388 IP 195.88.16.114.42154 > 130.127.48.17.80: Flags [S], seq 4165353571, win 29200,


1493752447.584792 IP 198.21.165.250.51037 > 130.127.49.7.80: Flags [S], seq 1235895083, win 8192,

options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0

1493752447.584807 IP 130.127.49.7.80 > 198.21.165.250.51037: Flags [S.], seq 735377052, ack

1235895084, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0





1493752447.594194 IP 130.127.49.7.80 > 198.21.165.250.51037: Flags [.], seq 1:4381, ack 128, win 46,

length 4380: HTTP: HTTP/1.1 200 OK







10

















1493752447.594283 IP 130.127.49.7.80 > 198.21.165.250.51037: Flags [FP.], seq 20441:21092, ack 128,

win 46, length 651: HTTP







length 0


Solution discussion: We need to talk about two items: TCP sliding windows and tcpdump vantage points. TCP sliding window: Let’s look at two lines from the SUM1 trace –




The first line is the second data segment from the server (netlab). Every tcp segment (this is the tcp header + data but not necessarily in an IP packet yet….) has a seq and ack number. These are in units of bytes. Think of a TCP cx as a stream - the first byte sent is seq number 1. A sender will set the seq number field with the byte number of the first byte of data in the segment in the stream. And to further complicate things, TCP/IP will not start each new Cx at seq number 1. The stack maintains a variable called initial seq number- probably initialized to a random value and then with each new cx its incremented by some amount. In a new Cx, this initial seq number that each side wants to use is sent in the SYN segments. The idea is to have consecutive TCP cxs use different sets of seq numbers. Tcpdump presents the sequence number relative to the initial sequence number. Also, tcpdump sees the amount of data and the sequence number and conveniently tells us the seq number of the last octet of data. So that first segment contains seq numbers 1461 through 2881. Double check: 2881-1460 = 1420 and this is the length shown!! The Ack field is telling us the next seq number the receiver side expects next. Now back to the TCP sliding window….. the actual window used by the sender is :

11

Window = min ( cwnd, receivers advertised window). Again, all these variables are in units of bytes. For this explanation, let’s assume units of segments and that the perspective is from the sender (netlab):

Cwnd: the congestion window. This usually starts at 1 or 2 segments. Each time an Ack arrives, the cwnd is incremented.

o If Ack arrivals suggest that a packet has been dropped, the packet is retransmit and the cwnd is reduced to its starting value (in some cases it is reduced only ½). The idea is to throttle the sender when the network appears congested.

Receivers advertised window : this is a field in the tcp header. It is used to implement flow control. The example is a sender is ‘fast’ and a ‘receiver’ is slow , the receiver could be overwhelmed with data from the network. The receiver can send acks and tweak the window field to tell the sender how much space is left in the socket rx buffer. This should explain why the window update needs to look at the receiver’s Rx advertised window.

Each time an Ack arrives, the sender updates the cwnd, observes the latest rx advertised window from the received ack, and computes the window. It then looks to see if it can send new data. Assuming the send side application has lots of data , TCP is going to send as many packets allowed by the window. For example, if the window is 100,000 bytes and the TCP segment size is 1000 bytes, the sender will try to keep 100 packets in flight at all times. New ack arrivals clock out new data segments.

So when we say the TCP sender side window - unless otherwise specified we are talking about the current window value. If things are going as expected we would expect to see that much data in the pipe. An important concept is the pipe ….. A TCP socket abstracts a flow of data of a pair of application endpoints. A socket is bidirectional but let’s just assume only one side is sending data and the other side is just sending acks. There is a logical pipe between the sender and receiver. The pipe size represents the volume of data that can be contained in the pipe at any given time. The concept of a bandwidth delay product (BDP) actually specifies the pipe size in units of bytes (or packets). There are two variants:

One-way BDP - let’s say the one way latency between the end points is 10ms and the bandwidth over the pipe is 1 Mbps. Assume the bandwidth represents the available bandwidth over the path. In some cases this can correspond to the slowest link speed of all the hops over the path. The BDP is bw*delay = 1Mbps*0.010 = 10,000/8 bytes.

Two-way BDP - this is more useful for TCP. Let’s define the round trip time (RTT) as the amount of time it takes from sending a data segment until when the corresponding ack is received. Let’s say the RTT is 20ms and the available bandwidth is 2Mbps. The pipe size is : 2000000 / (0.020 * 8) bytes.

12

If we know the available bandwidth over a path and the RTT, the ideal TCP window will be the BDP. Unfortunately, it’s difficult to estimate a priori the available bandwidth, so TCP’s slow start algorithm is designed to help get the TCP Cx to an ‘equilibrium point’ where it dynamically estimates the correct window that should be used. The slow start algorithm is very simple.

The send can send up to a Window of data, but then it must wait for an ack arrival to advance the window.

When an ack arrives, the cwnd increases by 1 segment (again, it is in units of bytes so it increases by the tcp segment size).

If a packet is dropped by the network, the receiver is going to ack the sequence number it expects next. If the sender sends packets 100-105 but packet 101 is dropped, the receiver will see segment 100, and then 102-105. The sender will see an ack stream of : 101 101 101 101 101 (the first ack is a ‘new ack’, the other acks are ‘duplicate acks’).

At the sender, it might deduce packet loss when it sees a stream of duplicate acks, however the base slow start algorithm ignores this information. Eventually a timeout occurs (the sender always maintains a timeout if there are packets in flight). When the timeout occurs, the cwnd is reset to its initial value (1 or 2 segments).

Second, we need to orient the trace with the vantage point. For SUM1, we obtain the trace as packets arrive and depart VM2. Arrivals are data packets from netlab, departures are primarily TCP ACKS (except for the initial HTTP GET). Therefore, we should expect an ack immediately after each data segment. The delay would be small as it should include just the time it takes TCP at VM2 to receive the data segment and generate an ack packet. If we look at netlab (SUM2), we see something strange (actually quite explainable) - In the trace, acks arrive at the netlab host and this triggers new data to be sent. Starting with the HTTP GET data that arrives, we see an ack with no data followed by 13 consecutive data segments. Netlab is an older machine and it’s TCP/IP stack is setup so that if TCP is establishing a new Cx over an Ethernet interface, it will init the starting send window to something very large….therefore we see a single burst of all the data all at once !!! Notice that we then see a sequence of acks arrive that acknowledges all data. At the wget side, as it reads data from the socket, TCP will decide when to generate acks.



the header in bytes.

13

o The IP total length field and interpret the data to show the size of the packet in bytes.

o The TCP offset field and interpret the data to show the size of the TCP header in bytes

1493759382.537701 IP 192.168.2.100.48440 > 130.127.49.7.80: Flags [S], seq 657222341, win 29200,


0x0000: 4500 003c c00d 4000 4006 041c c0a8 0264 E..<..@[email protected]

0x0010: 827f 3107 bd38 0050 272c 6ac5 0000 0000 ..1..8.P',j.....

0x0020: a002 7210 76c1 0000 0204 05b4 0402 080a ..r.v...........

0x0030: 001a aac8 0000 0000 0103 0307 ............

1493759382.540678 IP 130.127.49.7.80 > 192.168.2.100.48440: Flags [S.], seq 2694737409, ack


0x0000: 4500 002c cb70 0000 3f06 39c9 827f 3107 E..,.p..?.9...1.

0x0010: c0a8 0264 0050 bd38 a09e 6e01 272c 6ac6 ...d.P.8..n.',j.

0x0020: 6012 ffff c368 0000 0204 05b4 0000 `....h........


0x0000: 4500 0028 c00e 4000 4006 042f c0a8 0264 E..(..@.@../...d

0x0010: 827f 3107 bd38 0050 272c 6ac6 a09e 6e02 ..1..8.P',j...n.

0x0020: 5010 7210 76ad 0000

Solution….let’s look at the first packet (16 octets per line)

4500 003c c00d 4000 4006 041c c0a8 0264

827f 3107 bd38 0050 272c 6ac5 0000 0000

a002 7210 76c1 0000 0204 05b4 0402 080a

001a aac8 0000 0000 0103 0307

Each set of number represents two octets in hex format. The first set is 0x4500. Looking at the IP header field information, the first octet represents the TCPIP version ( either 4 or 6) in the upper nibble and the lower nibble represents the IP header size in units of 4 octets. Upper nibble: 0x4 : makes sense…. TCPIP v4 Lower nibble: 0x5 : 5*4 = 20 octets. Makes sense as we know this is the size of an IP header with NO IP options. The IP packet length field is the 3rd/4th octets. WARNING: the IP field length is a two octet value - an is typed as an unsigned short integer. We need to get the byte ordering correct ! When looking at a network trace,we need to remember that TCP/IP defines the network byte order to be big endian where the most significant bytes are arranged first. Therefore, when we see bytes 0x00 and 0x3c, if we are looking to create an unsigned short, we know to assemble them as 0x003c. 0x03c = converting to decimal : 3c in binary::: 0011 1100 : or in decimal: 60 octets. We know the IP header is 20 octets. So tells us where the tcp header begins (the 21st octet).

bd38 0050 272c 6ac5 0000 0000

a002 7210 76c1 0000 0204 05b4 0402 080a

001a aac8 0000 0000 0103 0307

14

The tcp header format shows the header length field is the upper nibble of the 13’th octet of the tcp header. The 13th octet is 0xa0. In binary: 1100 0000 The upper nibble: 0000 1010 : 10. Interpretting: 10*4 = 40 octets. For the first packet (the SYN from the VM): The IP packet is 60 octets, the IP header is 20, the TCP header is 40. There is no application data contained in the packet. For the second packet: The IP packet is 44 octets, the IP header is 20, the TCP header is 24 octets.

0x0000: 4500 002c cb70 0000 3f06 39c9 827f 3107 E..,.p..?.9...1.

0x0010: c0a8 0264 0050 bd38 a09e 6e01 272c 6ac6 ...d.P.8..n.',j.

0x0020: 6012 ffff c368 0000 0204 05b4 0000 For the third packet: The IP packet is 40 octets, the IP header is 20 , the TCP header is 20.

0x0000: 4500 0028 c00e 4000 4006 042f c0a8 0264 E..(..@.@../...d

0x0010: 827f 3107 bd38 0050 272c 6ac6 a09e 6e02 ..1..8.P',j...n.

0x0020: 5010 7210 76ad 0000

Show the growth of the TCP window of the sending side (the web server). Include the three way handshake segments to help sync your sequence/ack numbers. Simplify by translating the observed segment sequence numbers from byte counts to a count of packets, beginning with seq # 0 (the first SYN-ACk sent by the web server) Solution: I am asking you to estimate the window of the sender based on the trace. Based on SUM1 we might interpret the arrivals of larger size data segments as an increase in the window size. This is a reasonable assumption and you can get full credit if this is your answer. As I had access to the server side, the netlab side results (SUM2) tell the real story. The window is set high enough at the start to send all data – therefore there was no need to grow the window. Q3.3 Repeat Q3.2 Except this time use the VM1 as a router and VM2 as the wget client. Also, use netem at VM1 to add an artificial packet latency of 30ms and an avg loss rate of 5% to all packets forwarded by VM1 to the network that connects with VM2.

15

Solution: Setting a latency of 30ms is meant to help identify data sent each RTT period. With a 5% packet loss rate, you might not see any packets dropped. If you do, you would see duplicate acks and a retransmission. The following is summary #3 (call it SUM3) from VM2’s vantage – with the 30ms latency

1493759241.828754 IP 192.168.2.100.48438 > 130.127.49.7.80: Flags [S], seq 2583161376, win 29200,


1493759241.947696 IP 130.127.49.7.80 > 192.168.2.100.48438: Flags [S.], seq 2676753409, ack







65535, length 1460: HTTP: HTTP/1.1 200 OK















length 0


The following is summary #4 (call it SUM4) from netlab’s vantage – with the 30ms latency

And from netlab’s vantage pt

1493752307.036266 IP 198.21.165.250.51028 > 130.127.49.7.80: Flags [S], seq 641659234, win 8192,

options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0

1493752307.036273 IP 130.127.49.7.80 > 198.21.165.250.51028: Flags [S.], seq 819087082, ack

641659235, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0





1493752307.085756 IP 130.127.49.7.80 > 198.21.165.250.51028: Flags [.], seq 1:4381, ack 128, win 46,

length 4380: HTTP: HTTP/1.1 200 OK



16



























length 0


~ ~

~



the header in bytes. o The IP total length field and interpret the data to show the size of the

packet in bytes. o The TCP offset field and interpret the data to show the size of the TCP

header in bytes

1493759241.828754 IP 192.168.2.100.48438 > 130.127.49.7.80: Flags [S], seq 2583161376, win 29200,


0x0000: 4500 003c cb7f 4000 4006 f8a9 c0a8 0264 E..<..@[email protected]

0x0010: 827f 3107 bd36 0050 99f7 ea20 0000 0000 ..1..6.P........

0x0020: a002 7210 76c1 0000 0204 05b4 0402 080a ..r.v...........

0x0030: 001a 215f 0000 0000 0103 0307 ..!_........

1493759241.947696 IP 130.127.49.7.80 > 192.168.2.100.48438: Flags [S.], seq 2676753409, ack


0x0000: 4500 002c cb59 0000 3f06 39e0 827f 3107 E..,.Y..?.9...1.

0x0010: c0a8 0264 0050 bd36 9f8c 0401 99f7 ea21 ...d.P.6.......!

0x0020: 6012 ffff 3c56 0000 0204 05b4 0000 `...<V........


0x0000: 4500 0028 cb80 4000 4006 f8bc c0a8 0264 E..(..@[email protected]

0x0010: 827f 3107 bd36 0050 99f7 ea21 9f8c 0402 ..1..6.P...!....

0x0020: 5010 7210 76ad 0000 P.r.v...

17

Solution: For the trace shown, the answer is identical to that of Q3.2. This is somewhat expected as I took the tcpdump from VM2 for both Q3.2 and Q3.3. If you obtained the Q3.3 trace from a different machine (i.e., VM1 and then VM2) you might see a difference.

Show the growth of the TCP window of the sending side (the web server). Include the three way handshake segments to help sync your sequence/ack numbers. Simplify by translating the observed segment sequence numbers from byte counts to a count of packets, beginning with seq # 0 (the first SYN-ACk sent by the web server) Solution: Look for gaps in time of at least 30 ms - this will help identify RTT epochs.

1. 1493759241.828754 IP 192.168.2.100.48438 > 130.127.49.7.80: Flags [S], seq 2583161376, win

29200, options [mss 1460,sackOK,TS val 1712479 ecr 0,nop,wscale 7], length 0

2. 1493759241.947696 IP 130.127.49.7.80 > 192.168.2.100.48438: Flags [S.], seq 2676753409, ack


3. 1493759241.947764 IP 192.168.2.100.48438 > 130.127.49.7.80: Flags [.], ack 1, win 29200,

length 0

4. 1493759241.948113 IP 192.168.2.100.48438 > 130.127.49.7.80: Flags [P.], seq 1:128, ack 1, win

29200, length 127: HTTP: GET /data.dat HTTP/1.1

5. 1493759241.980941 IP 130.127.49.7.80 > 192.168.2.100.48438: Flags [.], ack 128, win 65535,

length 0

6. 1493759242.051111 IP 130.127.49.7.80 > 192.168.2.100.48438: Flags [P.], seq 1:1461, ack 128,

win 65535, length 1460: HTTP: HTTP/1.1 200 OK

7. 1493759242.051136 IP 192.168.2.100.48438 > 130.127.49.7.80: Flags [.], ack 1461, win 31240,

length 0

8. 1493759242.051218 IP 130.127.49.7.80 > 192.168.2.100.48438: Flags [.], seq 1461:2881, ack

128, win 65535, length 1420: HTTP

9. 1493759242.051230 IP 192.168.2.100.48438 > 130.127.49.7.80: Flags [.], ack 2881, win 34080,

length 0

10. 1493759242.083264 IP 130.127.49.7.80 > 192.168.2.100.48438: Flags [.], seq 2881:8561, ack

128, win 65535, length 5680: HTTP

11. 1493759242.083297 IP 192.168.2.100.48438 > 130.127.49.7.80: Flags [.], ack 8561, win 45440,

length 0

12. 1493759242.114673 IP 130.127.49.7.80 > 192.168.2.100.48438: Flags [.], seq 8561:15661, ack

128, win 65535, length 7100: HTTP

13. 1493759242.114704 IP 192.168.2.100.48438 > 130.127.49.7.80: Flags [.], ack 15661, win 59640,

length 0

14. 1493759242.145466 IP 130.127.49.7.80 > 192.168.2.100.48438: Flags [FP.], seq 15661:21092,

ack 128, win 65535, length 5431: HTTP

15. 1493759242.145507 IP 192.168.2.100.48438 > 130.127.49.7.80: Flags [.], ack 21093, win 65320,

length 0

16. 1493759242.145841 IP 192.168.2.100.48438 > 130.127.49.7.80: Flags [F.], seq 128, ack 21093,

win 65320, length 0

17. 1493759242.177165 IP 130.127.49.7.80 > 192.168.2.100.48438: Flags [.], ack 129, win 65535,

length 0

I’ve numbered the lines from SUM3 and I make the following observations: The time difference between the first two packets is over 100 ms !! The first window that contains data is between packet #4 and #5. Packet #4

has the VM send the HTTP request, packet #5 is the ack from the netlab side. The time difference is around 30ms.

The window that contains the first data of the data.dat file is packet #6.

18

We see continuous arrivals (each followed by an ack) until packet #10. We observe a 30 ms delay before the next data segment.

We see another gap of 30 ms before the next arrival. When we see large tcp segment arrivals (packet #12 is 7100 bytes), this is a

bit odd given the first three segments negotiated a maximum segment size of 1460 bytes. Large segments are evidence of tcp offload - basically the host is trying to optimize the flow of data by internally concatenating multiple segments into one larger segment. The hardware would then take care of breaking apart the large segment into MSS sized segments.

Over all answer based on SUM3 - We do see an increase in the amount of data that arrives each RTT epoch. All we are looking for in your answer is you identify the RTT epoch. You might see window growth or you might not. When I correlate SUM3 with SUM4 (the netlab vantage perspective), it’s very strange. We see a burst of segments from netlab. These arrive at HostOS and by the time we see them arrive at VM2, the timing is very distorted. This is likely do to any/all of the following: Two NATs in the path (HostOS and VM1), multiple firewalls (HostOS, the VMM, VM1 and VM2, and various strangeness in the networking virtualization code.

Q3.4 Let’s say we use wget to download a very large file that takes hours. Use your answer from Q3.2 to help you answer this question. From another CS Linux host you run a tool like nmap or nping (or you write your own RAW sockets program) that allows you to create and send your own TCP packet. Your goal is to inject a single TCP packet in the stream to cause the wget session to fail. Explain in detail what that single packet looks like. You do not need to specify header fields that do not matter….you do need to specify the values/settings of all fields that are required. You should consider fields in both IP and TCP headers. You do not need to consider arp. Please use values that are based on the TCP cx from your answer to Q3.2.

Solution: let’s say our network is as follows:

Netlab.cs.clemson.edu ----- HostOS ---- VM1 ----- VM2 (wget) | Hacker.cs.clemson.edu-------|

The IP/port of netlab: IPAddr1, port1

The IP/port of the VM2 socket endpoint : IPAddr2, port2

The IP/port the is set/used by NAT (packets forwarded from the private side to the public side through Host OS) : IPAddr3, port3

19

The hacker would have to create an IP packet that contains the following key fields.

IP header:

Src/dst IP: IPAddr1, IPAddr3, and then all other fields in the IP header need to be reasonable to ensure it is not thrown away – checksum valid, frag fields clear, no IP options. It must be delivered to HostOS.

TCP header:

Src/dst port: port1, port 3, Other fields must be reasonable – checksum valid, nothing strange with the urgent fields, …

To cause the TCP session to terminate, the hacker simply needs to set the RST or FIN bits. Other possibilities would be to set the seq number or ack number to something strange like 0’s or all 1’s.

section 1 (25 points) - clemson universityyfeaste/cybersecurity/cpsc424/exa… · private class...

Documents