FIT3031 - Network Security: Assignment I (2025 S2) Total Marks 100
Due date: September 25th, Thursday, 11:55:00 PM (Melbourne time)
The learning objective of this assignment is for you to gain a first-hand experience on network attacks (i.e., TCP/UDP scanning techniques and DNS attacks) and get a deeper understanding on how to launch these attacks in practice. All tasks in this assignment can be done on the unit’s virtual environment as used in the labs.
For this assignment, you need to submit four files using a two submission links on Moodle:
• Submission link 1: A single video file containing the recording of you carrying out all tasks in both Section 3 and Section 4
• Submission link 2: The final versions of the tcp-scanner.py, udp-scanner.py, remote dns.py scripts from Section 3.
Name your submission files as the format: [Your Name]-[Student ID]-FIT3031-Assignment1, e.g.,
HarryPotter-12345678-FIT3031-Assignment1.mp4.
Moodle allows a maximum submission size of 500 MB. Therefore, the total size of the above three submission files should not exceed 500 MB.
Figure 1: Sample opening slide
• The maximum allowed duration for the recorded video is 20 mins. Therefore, only the first 20:00 mins of your submitted video will be marked. Any exceeding video components will be ignored. Speeding up the video recording (e.g. using a software) is not allowed and such submissions will receive a zero mark.
• If your device does not have a camera (or for whatever reason you can’t use your device), you can borrow a device from Monash Connect or Library. It’s your responsibility to plan ahead for this. Monash Connect or Library not having available devices for loan at a particular point in time is not a valid excuse.
• You can create multiple video parts at different times, and combine and submit a single video at the end. Make sure that the final video is clear and understandable.
• All tasks must be live demonstrated instead of explaining an already completed task. You are not allowed to add voice-over later on. At the beginning of each task, please clearly mention what task is being carried out in the video.
• If any task requires installing new software, you are allowed to do that in advance of recording your video. You do not need to demonstrate software installation in the video.
• In the remote DNS attack, you may need to run the attack for a long time (in the order of a few hours) due to brute forcing. In this case, you can record the parts until the time-consuming step, pause/stop the video recording, and then continue to record once the time-consuming step concludes. You may merge multiple recordings as mentioned befor.
3 Port Scanning Techniques [50 Marks]
A port scan is a common technique used by attackers to discover entry points in a system. The following task focuses on network traffic analysis and security measures related to port scanning techniques. By following the steps, students will analyse network interactions between a client and a server, identify and interpret the type of scan used, and explore countermeasures to enhance security. Additionally, students will gain practical experience by implementing evasive techniques in a scanner script and observing the effects. The goal is to deepen understanding of port scanning concepts and hands-on mitigation strategies.
3.1 Environment Setup
For this question we will be using a new network topology. Run the command below on the GNS3 VM shell to download the project. If you SSH into the VM from your host OS terminal, you can simply copy and paste the command instead of typing it manually.
 |
Alternatively, you can use the link below to download the same project. However, if you are connected to the
Monash Wi-Fi, this method may not work. In that case, please use a mobile hotspot. (single command)
 |
 |
Figure 2: GNS3 Config
Download and copy the server.py file on to the Victim-Server and tcp-scanner.py and udp-scanner.py on to the External-Attacker-1. You will have to create this file in the /home directory to make sure the file not deleted after a reboot. Run Wireshark on the link connecting External-Switch to the Firewall and the link connecting the
Internal-Switch to the Firewall.
Run server.py as below with your student ID.
Note: Victim-Server has multiple IP addresses. Each IP has different levels of traffic restrictions configured. You will be using different IP address for different tasks. Using the wrong IP address for a task will render it invalid and result in zero marks.
IMPORTANT: If you don’t use the correct student ID, your attempt will be deemed invalid and you will receive zero mark for this Section 4.
 |
Running the script with your student ID will always open the same unique set of ports on the server.
3.2 Question 1
Now run tcp-scanner.py as below to scan the entire TCP port range of the Victim-Server and observe the traffic in Wireshark.
 |
Identify and describe the type of TCP scan by analyzing the traffic observed in Wireshark. Explain how the scan operates, and using examples from the traffic flow, demonstrate how the scan distinguishes between a closed port and an open port. (4 marks)
3.3 Question 2
Detecting port scans is a key aspect of network security, as they often indicate malicious intent. A common method is to monitor for a high volume of requests from the same source IP to the same destination IP within a short time. Once identified, rate limiting at control points such as firewalls, IDS/IPS, or load balancers can then be applied to block these scans.
Note: Rate limiting is a network or application control mechanism that restricts the number of requests, connections, or packets a source can send within a specific period of time.
Identify and explain using Wireshark, THREE other traffic patterns you observed that could be used to detect the above-mentioned type of TCP port scan. (3 marks)
3.4 Question 3
Evading port-scanning countermeasures is a common tactic used by attackers to avoid detection. One method of bypassing rate limiting on a source IP is to perform scans at a slower pace, making them more stealthy.
Identify and explain THREE other ways the identified TCP scan could be modified to evade the countermeasures described in the previous question. Clearly indicate which evasion technique corresponds to which countermeasure, with one technique per countermeasure.
Note: While these techniques are illegal and unethical when used without proper authorisation, understanding them is essential for strengthening security defences. (3 marks)
3.5 Question 4
The victim’s organization observed a large number of port scans targeting the server. In response, they implemented a per-source IP rate limit of 100 new connections per second for traffic directed to the server.
The tcp-scanner.py script includes the --conns-per-batch argument, which defines how many parallel workers are executed per second, with each worker scanning one port. Run the command below to test this argument.
 |
As a result of this, scanning all 65,535 ports now takes more than 10 minutes to complete.
As a penetration tester, you may not have such a long time window to carry out your attack. How can you improve the scanning technique to complete all 65,535 ports under 60 seconds while still evading the firewall’s rate-limiting countermeasure?
You may add more External-Attacker clients if needed for this scan. However, the attack must be executed from only one client. (For example, you cannot run the same scanning script simultaneously on all five machines.) After the scan, all open ports should be accurately displayed on the console(s).
The restricted IP address for this task is 200.2.4.11. You should perform the scan for this task on that IP. (18 marks, or 5 marks if not executed centrally)
Notes:
3.6 Question 5
To further strengthen security, the organization’s network security team decided to enforce additional firewall controls to stop TCP scans on the server. Identify these restrictions and modify your scan to bypass them. Your modified scan should identify all the open and closed ports on the destination server. You allowed to do any modification to the scan in this task.
The restricted IP address for this task is 200.2.4.12. You should perform the scan for this task on that IP. Demonstration with explanation of the modifications to the scan (5 marks)
3.7 Question 6
Now run udp-scanner.py to scan the first 100 UDP ports and observe the traffic in Wireshark.
 |
Observe the traffic and explain how the scan operates, and using examples from the traffic flow, demonstrate how the scan distinguishes between a closed port and an open port. (2 marks).
3.8 Question 7
Match the result of the scanner with the actual open ports on the server. Is the result correct? Why? Use the observations on Wireshark in your explanation. (2 marks).
Run the udp-scanner.py script with different arguments, without modifying the script itself, to reduce false positives in the scan results. (4 marks).
3.9 Question 8
Run the same scan from the previous question on the IP address below. Do you still observe fewer false positives? If not, explain why. Use Wireshark to support your explanation, citing any evidence you find in the traffic patterns. (5 marks)
 |
3.10 Question 9
Modify the udp-scanner.py script to reduce the false positives of the scan from question 8 and run the scan again to demonstrate.
Briefly explain the techniques used and the modifications to the Python code or/and the arguments given in the
udp-scanner.py script. (4 marks) Notes.
4 DNS Attacks – Using Scapy [50 Marks]
Domain Name System (DNS) is an essential component of the Internet infrastructure. It serves as the phone book for the Internet, so computers can look up for a “telephone number” (i.e. an IP address) from domain names.
Without knowing the IP address, computers will not be able to communicate with one another. Due to its importance, the DNS infrastructure faces frequent attacks. In this section, you will explore the most primary attack on DNS. That is DNS cache poisoning by investigating both Local and Remote DNS cache poisoning attacks.
Due to the large number of computers and networks on the Internet, the domain namespace is organised in a hierarchical tree-like structure. Each node on the tree is called a domain, or sub-domain when referencing to its child node. The following figure depicts a part of the domain hierarchy.
 |
Figure 3: Domain hierarchy
The domain hierarchy tree structure describes how the domain namespace is organised, but that is not exactly how the domain name systems are organised. Domain name systems are organised according to zones. A DNS zone basically groups contiguous domains and sub-domains on the domain tree, and assign the management authority to an entity. Each zone is managed by an authority, while a domain does not indicate any authority information. The following figure depicts an example of the example.com domain.
 |
Figure 4: DNS Zones
Assume that example.com in the above figure is an international company, with branches all over the world, so the company’s domain is further divided into multiple sub-domains, including usa.example.com, uk.example.com, and france.example.com. Inside US, the usa sub-domain is further divided into chicago, boston, and nyc subdomains.
Each DNS zone has at least one authoritative nameserver that publishes information about that zone. The goal of a DNS query is to eventually ask the authoritative DNS server for answers. That is why they are called authoritative because they provide the original and definitive answers to DNS queries, as opposed to obtaining the answers from other DNS servers.
With such arrangement, the root zone for example.com only needs to keep records of who the authority is for each of its subdomains. By doing this, it maintains the independence among the branches in different countries and enable the administrative right of those subdomains, so the branch in each country manages its own DNS information. For
a given DNS query, if your local DNS server does not know the answer, it asks other DNS servers on the Internet for answer via hierarchical authority servers. The following example demonstrates a dig (DNS query) for the domain www.example.net when sending the query directly to one of the root servers (i.e. a.root-servers.net).
Figure 5: DIG to the root server
There are four types of sections in a DNS response: question section, answer section, authority section, and additional section. From the above result, we can see that the root server does not know the answer (because the reply does not include an answer section, but it tells several authoritative nameservers for the net zone (the NS records in the authority section), along with their IP address if possible in the additional section). If you continuously dig the domain www.example.net on one these authoritative nameservers, you will finally end up with the answer section showing the IP address of the machine hosting the website for www.example.net.
When your local DNS server gets information from other DNS servers, it caches the information, so if the same information is needed, it will not waste time to ask again.
4.1 Local DNS Attack targeting Authoritative Nameserver [20 Marks]
4.2 Environment Setup
In this section we will prepare the environment for the DNS attacks in this assessment. Download a new copy of the SecureCorp project using the below link. This is slightly different from the SecureCorp project you had in Week 1. Run the command below on the GNS3 VM shell to download the project. If you SSH into the VM from your host OS terminal, you can simply copy and paste the command instead of typing it manually.
 |
Alternatively, you can use the link below to download the same project. However, if you are connected to the
Monash Wi-Fi, this method may not work. In that case, please use a mobile hotspot. (single command)
 |
Now add an Internal-Server node (Ubuntu-24.04-plus-essentials) to the Corporate LAN and configure it with a static IP.
For this attack both the DNS server and the Internal-Attacker have to be in the same subnet. So first move the DNS server to the Corp LAN and assign a suitable IP configurations (ex: 10.10.10.53).
Figure 6: Topology for Local DNS attack
 |
Figure 7: Static IP config for DNS
Start the DNS server using the below command.
 |
We recalled that a DNS response contains question section, answer section, authority section, and additional section. If we only target the answer section, the attack only affects one hostname (as we did in our Week06 lab “DNS Spoofing Attacks”). Real DNS attacks usually target the authority section by providing a fake NS record for the target domain in the authority section. If the fake NS record is cached, when a victim’s local DNS server tries to find any IP address in the target domain, it will send a request to the malicious nameserver specified in the fake NS record. Such an attack can affect all the hostnames in the target domain. In this task, you will explore how to target the authoritative server of example.net and replace it with ns1.attacker.com and ns2.attacker.com.
4.3 Question 10
 |
Figure 8: Successful DNS spoofing attack
4.4 Remote DNS Attack targeting Authoritative Server [30 Marks]
4.5 Environment Setup
For this task, the attacker (Internal-Attacker) and DNS server need to be in different LANs. We need to move DNS
server back to the Server LAN and revert the IP configurations to the original setting to match the Server subnet.
 |
Figure 9: Topology for Remote DNS attack
The previous local DNS attacks assume that the attacker and the DNS victim server are on the same LAN so that the attacker can observe the DNS query message and reply with a forged DNS packet. When the attacker and the DNS server are not on the same LAN, the attack becomes harder since the attacker cannot perform ARP poisoning attack and see the DNS query. When the DNS victim server cannot resolve a DNS query, it forwards the DNS query packet to the forwarder DNS server (Google DNS server in our current setup). The DNS query is sent via a UDP packet where the UDP’s source port is a 16-bit random number. In addition, the 16-bit transaction ID in the DNS header is also self-created by the DNS victim server. Hence, if the remote attacker wants to forge the DNS response, the forged packet must contain the correct values of these two numbers; otherwise, the reply will not be accepted.
Without being able to sniff the query packet, the remote attacker can only guess these two numbers. The chance is one out of 232 for each guess. If an attacker can send out 1000 spoofed responses, it may take several days to try up 232 time. In contrast, it only takes few seconds to receive the correct packet response from the forwarder Google DNS. Consequently, that real reply will be cached by the local DNS victim server. To make another try, the attacker has to wait for the server to send out another DNS query when its cache times out. Hence, this attacking chance makes the remote DNS attack unrealistic.
The remote DNS attack had become an open problem until Dan Kaminsky came up with a simple trick in 2008. The attack is depicted in the following figure.
 |
Figure 10: Kaminsky Attack
We choose a domain test.com as our targeted domain name in this task. When a client queries the DNS server for www.test.com, the attacker (Internal-Attacker) wants to cause the DNS server to use their DNS server (ns.attacker.com). The following steps with reference to above figure describe the outline of the attack.
xyz123 is a random name.
Even if the response failed, the attacker would go back to Step 1, and try another non-existing random name until the attacker succeeds.
To simplify and shorten the attack’s simulation time in this task, we suggest you follow the below steps before doing the task.
• DNS: 10.10.5.53
• Internal-Attacker: 10.10.10.X
• Internal-Client: 10.10.10.X
 |
Then, you should configure the forwarder 8.8.8.8, enable recursion and fix the query source port of the DNS server (i.e. 33333). With this constraint, the attacker now only needs to guess the transactionID of the DNS packet when performing remote DNS attacks. You can review the following figure for the correct configuration of DNS server.
 |
Figure 11: DNS server config file
We provide you the remote dns.py script template on Moodle that helps to perform the Kaminsky attack.
 |
 |
 |
 |
 |
Figure 12: Attacker’s screen shows poisioning was successful
6 Acknowledgement
Parts of this assignment and instructions are based on the SEED project (Developing Instructional Laboratory for Computer Security Education) https://seedsecuritylabs.org.
