Description

Part I: Short Answers
1. Jill lives in a large apartment complex and has a Wi-Fi access point that she keeps in her apartment. She likes her neighbors, so she doesn’t put any password on her Wi0Fi and lets any of her neighbors use her Wi-Fi from their nearby apartments if they want to access the Internet. What kinds of security risks is Jill setting herself up for?

2. How many bytes are devoted to header and footer information (with respect to all layers of the IP protocol stack) of an Ethernet frame that contains a TCP packet inside it? What if there was a UDP packet instead?

3. You are the system administrator for a provider that owns a large network (e.g., at least 64,000 IP addresses). Show how you can use SYN cookies to perform a DOS attack on a web server. Show how to defend against this DOS attack.

4. Suppose the transaction ID for DNS queries can take values from 1 to 65,536 and is randomly chosen for each DNS request. If an attacker sends 2048 false replies per request, how many requests should he trigger to compromise the DNS cache of the victim with a probability 99%?

5. In the three-way handshake that initiates a TCP connections, if the SYN request has sequence number 156955003 and the SYN-ACK reply has sequence number 883790339, what are the sequence and acknowledgment numbers for the ACK response?

6. Either party in an established TCP session is allowed to instantly kill their session just by sending a packet that has the reset bit, RST, set to 1. After receiving such a packet, all other packets for this session are discarded and no further packets for this session are acknowledged. Explain how to use this fact in a way that allows a third party to kill an existing TCP connection between two others. This attack is called a TCP reset attack. Include both the case where the third party can sniff packets from the existing TCP connection and the case where he cannot.

7. Describe a firewall rule that can prevent IP spoofing on outgoing packets from its internal network.

a. Based on this observation, and assuming you can sniff all packets sent by the NAT to the outside, can you outline a simple technique that detects the number of unique hosts behind a NAT? Justify your answer.
c. Explain why we say NAT can work as a natural Firewall.

9. Describe the types of rules that would be needed for a rule-based intrusion detection system to detect a smurf attack.

Part II: Lab Report
Q1: Fill the information in the following table I and show a screenshot on how you obtain these information.
User VM Attacker VM DNS Server VM
IP V4 address
Network Mask
DNS Server
Q2: Restart the VMs and fill the information in the following table II.
User VM Attacker VM DNS Server VM
IP V4 address
Network Mask
DNS Server
Q3: Show screenshots of your codes in /etc/bind/named.conf.
Q4: Show a screenshot of your codes in XXXX4222.com.db.
Q5: Show a screenshot of your codes in 192.168.0.db.
Q6: Show two Screenshots that you successfully set up the server and can dig the www.XXXX4222.com by using your User VM. One is from the User VM terminal after running the dig command. The other screenshot should show the packets captured by the Wireshark on the DNSServer.

Q7: Explain what happens and how the Netwox 105 tool works to send a response to a user with the wrong IP address.

Q8: Show the Screenshot of the poisoned DNS cache record in the dump.dp.

Part II Lab: Local DNS Attack 1. Local DNS setup
DNS (Domain Name System) is the Internet’s phone book; it translates hostnames to IP addresses (and vice versa). This translation is through DNS resolution, which happens behind the scene. DNS attacks manipulate this resolution process in various ways, intending to misdirect users to alternative destinations, which are often malicious. The objective of this lab is to understand how such attacks work. Students will first set up and configure a DNS server and then try various DNS attacks on the target within the lab environment.
1.1 Set Up Server, Attacker, and User VMs
• The lab environment is shown in the following Figure. We need three computers
on the same LAN to study the local DNS attack. We will use three virtual
machines (VM) to simplify the lab environment: User VM, Attacker VM, and
DNS Server VM. The VM configuration is based on Ubuntu, the pre-built
operating system we used in the assignment. Make sure to install VirtualBox; go
to https://seedsecuritylabs.org/lab_env.html to download the pre-built VMs, and
follow this document
(https://seedsecuritylabs.org/Labs_16.04/Documents/SEEDVM_VirtualBoxManu
al.pdf ) to run and configure the VM on VirtualBox.
(1) Right-click SeedLab Ubuntu => Clone two Additional VMs, which should be named as YourlastNameDNSServer and YourlastNameAttacker, respectively.

After you correctly perform the clone function, you should have 3 different VMs in your VirtualBox.
Q1: Fill in the information in the following table I and show a screenshot of how you obtained these information.
User VM Attacker VM DNS Server VM
IP V4 address
Network Mask
DNS Server

(2) Create an NAT Adaptor: File=>Preference=>Network=>Adds New NAT Network
(3) For each VM, we need to modify the Network Adaptor as: “Attached to NAT
Network” and change the “Promiscuous Mode: Allow VMs.”

1.2 Configure Attacker and User VMs
Turn on the User/Attacker VMs and set the Network Connection.
(1) System Settings=>Network=>options=>IPv4 Settings
(2) Choose “Method: Automatic addresses only,” and change the DNS servers as the IP address of the Server VM.
(3) Choose “Wired Connection 1” in the right corner of the Desktop.

Q2: Restart the VMs and fill in the information in the following table II.
User VM Attacker VM DNS Server VM
IP V4 address
Network Mask
DNS Server

1.3 Lab Task 2: Set Up Local DNS Server
(1) Install the BIND 9 DNS Server on your YourlastNameDNSServer VM
$ sudo apt-get install bind9
(2) Configure the BIND 9 Server
BIND 9 gets its configuration from a file called /etc/bind/named.conf. This file is the primary configuration file and usually contains several “include” entries, i.e., the actual configurations are stored in those included files. One of the included files is called
/etc/bind/named.conf.options. This is where we typically set up the configuration options.
Let us first set up an option related to the DNS cache by adding a dump-file entry to the options block:
options { dump-file “/var/cache/bind/dump.db”;
};

The above option specifies where the cache content should be dumped if BIND is asked to dump its cache. If this option is not specified, BIND dumps the cache to a default file called /var/cache/bind/named_dump.db. The two commands shown below are related to the DNS cache. The first command dumps the content of the cache to the file specified above, and the second command clears the cache.
$ sudo rndc dumpdb -cache // Dump the cache to the specified file
$ sudo rndc flush // Flush the DNS cache
(3) Create Zones
Assume that we own a domain, and we will be responsible for providing the definitive answer regarding this domain. We will use our local DNS server as the authoritative nameserver for the domain. In this lab, we will set up an authoritative server for the XXXX4222.com domain, where the XXXX is your Last name. Hopefully, this domain name is not owned by anybody-:).
We need to create two zone entries in the DNS server by adding the following contents to /etc/bind/named.conf. The first zone is for forward lookup (from hostname to IP), and the second zone is for reverse lookup (from IP to hostname).
Type the following codes into the /etc/bind/named.conf file, where the XXXX is your Last name.
zone “XXXX4222.com”{ type master; file “/etc/bind/XXXX4222.com.db”;
};

zone “0.168.192.in-addr.arpa”{ type master; file “/etc/bind/XXXX4222.com.db”;
};
Q3: Show a screenshot of your codes in /etc/bind/named.conf.
(4) Setup the forward lookup zone file
The file name after the file keyword in the above zone definition is called the zone file, and this is where the actual DNS resolution is stored. Readers interested in the syntax of the zone file can refer to RFC 1035 for details.
Create a file named XXXX4222.com.db under the file path as /etc/bind/ directory. The file needs to include the contents as below, whereas the id means the last two digits of your Panther ID.
$TTL 3D
@ IN SOA ns.XXXX4222.com. admin.XXXX4222.com. (
2008111001
8H
2H
4W
1D)

@ IN NS ns.XXXX4222.com.
@ IN MX 10 mail.XXXX4222.com.

www IN A 192.168.0.id mail IN A 192.168.0.id+1 ns IN A 192.168.0.id+2
*.XXXX4222.com. IN A 192.168.0.id+3
The symbol ‘@’ is a special notation representing the origin specified in named.conf (the string after “zone”). Therefore, ‘@’ here stands for XXXX4222.com. This zone file contains 7 resource records (RRs), including an SOA (Start Of Authority) RR, an NS (Name Server) RR, an MX (Mail eXchanger) RR, and 4 A (host Address) RRs.
Q4: Show a screenshot of your codes in XXXX4222.com.db.
(5) Set upetup the reverse lookup zone file.
To support DNS reverse lookup, i.e., from IP address to hostname, we also need to set up the DNS reverse lookup file. In the /etc/bind/ directory, create the following reverse DNS lookup file called 192.168.0.db for the XXXX4222.com domain:
$TTL 3D
@

IN

SOA
2008111
8H
2H
4W
1D) ns.XXXX4222.com. admin.XXXX4222.com. ( 001
@
IN NS ns.XXXX4222.com.
id IN PTR www.XXXX4222.com.
id+1 IN PTR mail.XXXX4222.com.
id+2
IN PTR ns.XXXX4222.com.
Q5: Show a screenshot of your codes in 192.168.0.db.
(6) Restart the Bind server
After you successfully finish the steps above, you need to start your server by using the following:
$ sudo service bind9 restart

1.4 Test Local DNS Server

(1) Start the Wireshark on your DNS server to capture the DNS message from the user or attacker.
(2) Go to the terminal of the user/attacker.
$ dig www.XXXX4222.com
The correct return should be as the figure below if my last name is Dan and the last two digits of my Panther ID are 68.

Q6: Show two Screenshots that you successfully set up the server and can dig the www.XXXX4222.com by using your User VM. One is from the User VM terminal after running the dig command. The other screenshot should show the packets captured by the Wireshark on the DNSServer.

2. Local DNS cache Poisoning Attack
The main objective of DNS attacks on a user is to redirect the user to another machine B when the user tries to get to machine A using A’s hostname. For example, when the user attempts to access online banking, if the adversaries can redirect the user to a malicious website that looks very much like the main website of bank, the user might be fooled and give away the password of their online banking account. When a user types the name of a website (a hostname, such as www.example.net) in a web browser, the user’s computer will issue a DNS request to the DNS server to resolve the IP address of the hostname.

When a DNS server, say Apollo, receives a query, if the host name is not within the Apollo’s domain, it will ask other DNS servers to get the hostname resolved. Note that in our lab setup, the domain of our DNS server is XXXX4222.com; therefore, for the DNS queries of other domains (e.g., example.net), the DNS server Apollo will ask other DNS servers. However, before Apollo asks other DNS servers, it first looks for the answer from its own cache; if the answer is there, the DNS server Apollo will reply with the information from its cache. If the answer is not in the cache, the DNS server will try to get the answer from other DNS servers. When Apollo gets the answer, it will store the answer in the cache, so next time, there is no need to ask other DNS servers.
Therefore, if attackers can spoof the response from other DNS servers, Apollo will keep the spoofed response in its cache for a certain period. Next time, when a user’s machine wants to resolve the same hostname, Apollo will use the spoofed response in the cache to reply. This way, attackers only need to spoof once, and the impact will last until the cached information expires. This attack is called DNS cache poisoning.

In this task, we will poison the cache of the local DNS by using the netwox 105 tool. Netwox tool 105 provides a utility to conduct DNS sniffing and responding. We can make up any arbitrary DNS answer in the reply packets. The manual of the tool is described in the following:

(1) Running the Server
$ sudo service bind9 restart
(2) Delete the data in the cache $sudo rndc flush
(3) Save the cache dump.db as empty, the dump file is in the directory of
/var/cache/bind
$sudo rndc dumpdb -cache

On the Attacker’s VM
(4) In the Attacker VM, announce a nonexistent web www.YourFullName.com with a nonexistent Authoritative Name Server ns.YourFullName.com. The IP address of the website is 10.20.30.first-two-digits-of-PantherID and the IP address of your ANS is 10.first-two-digits-of-PantherID.20.last-two-digits-ofPantherID. The codes are similar to the following figure.

On the User VM
(5) Using the user to dig or nslookup the www.YourFullName.com.
Q7: Explain what happens and how the Netwox 105 tool works to send a response to a user with the wrong IP address.

(6) Check the dump.db file in the DNS server whether this www.YourfullName.com has been recorded. You can tell whether the DNS server is poisoned or not by observing the DNS traffic using Wireshark. You should also dump the local DNS server’s cache to check whether the spoofed reply is cached or not. To dump and view the DNS server’s cache, issue the following command:
$ sudo rndc flush
$ sudo rndc dumpdb -cache

Q8: Show the Screenshot of the poisoned DNS cache record in the dump.dp.