Differences

This shows you the differences between two versions of the page.

Link to this comparison view

isc:labs:08 [2024/11/25 04:52]
ebru.resul [[30p] 3. Man in the Middle]
isc:labs:08 [2024/11/27 09:47] (current)
ebru.resul [[30p] 1. Port Scanning]
Line 80: Line 80:
 === [10p] Discover Devices on the Network === === [10p] Discover Devices on the Network ===
  
-//**STEP 1: Scan the network with nmap ping scan**//+//**STEP 1: Scan the network with nmap (using ​ping scan)**//
  
-  * __What It Does:__ Sends ICMP Echo Requests (pings) or TCP/​UDP ​probes ​to detect devices on the network.+  * __What It Does:__ Sends ICMP Echo Requests (pings) or TCP/​UDP ​requests ​to detect devices on the network.
   * __Strengths:​__ Works across subnets and can identify devices beyond the local network.   * __Strengths:​__ Works across subnets and can identify devices beyond the local network.
-  * __Limitations:​__ May miss devices that block ICMP or TCP probes.+  * __Limitations:​__ May miss devices that block ICMP or TCP requests.
  
-<​note>​ **TASK:** Run a ping scan to discover active hosts in your network using nmap (you can use CIDR notation! Remember OpenStack'​s network prefix?​).</​note>  ​+<​note>​ **TASK:** Run a nmap with ping scan to discover active hosts in your network using nmap (you can use CIDR notation! Remember OpenStack'​s network prefix?​). ​Hint: Search on google how to run a "nmap with ping scan option"​</​note>  ​
 <​solution -hidden> <​solution -hidden>
 <​code>​ <​code>​
Line 166: Line 166:
   * __Purpose:​__ Helps test UDP scanning, which is slower and behaves differently than TCP due to the lack of acknowledgments.   * __Purpose:​__ Helps test UDP scanning, which is slower and behaves differently than TCP due to the lack of acknowledgments.
  
-<​note>​ **TASK:** Work in pairs. One person opens an UDP server on their VM using netcat, while the other scans for it. Choose a non-standard port (e.g., 10002). </​note>​+<​note>​ **TASK:** Work in pairs. One person opens an UDP server on their VM using netcat, while the other scans for it. Choose a non-standard port (e.g., 10002). ​Hint: use -k when opening the server to allow multiple connections ​</​note>​
  
 <​solution -hidden> <​solution -hidden>
Line 459: Line 459:
  
 ---- ----
-For the following exercises, we will use Docker containers to simulate a local network vulnerable to ARP spoofing attacks. (OpenStack filters ARP packets, so you won't be able to do this there).+For the following exercises, we will use Docker containers to simulate a local network vulnerable to ARP spoofing attacks.
  
 === [20p] ARP Cache Poisoning === === [20p] ARP Cache Poisoning ===
Line 468: Line 468:
  
  
-  * Enable IP forwarding on the host system ​to allow traffic ​relay+  * Ensure ​the host system ​forwards packets between devices. This is crucial for traffic ​to flow through the attacker container.
 <​code>​sudo sysctl -w net.ipv4.ip_forward=1</​code>​ <​code>​sudo sysctl -w net.ipv4.ip_forward=1</​code>​
  
Line 474: Line 474:
 <​code>​docker run --rm -ti --entrypoint /bin/bash --name victim ubuntu:​22.04</​code>​ <​code>​docker run --rm -ti --entrypoint /bin/bash --name victim ubuntu:​22.04</​code>​
  
-  * Open an "​Attacker"​ terminal ​(on the same VM):+  * Open an "​Attacker"​ terminal ​with IP forwarding enabled:
 <​code>​docker run --rm -ti --entrypoint /bin/bash --name attacker --sysctl net.ipv4.ip_forward=1 ubuntu:​22.04</​code>​ <​code>​docker run --rm -ti --entrypoint /bin/bash --name attacker --sysctl net.ipv4.ip_forward=1 ubuntu:​22.04</​code>​
  
Line 493: Line 493:
 //**STEP 3: Launch the ARP spoofing attack**// //**STEP 3: Launch the ARP spoofing attack**//
  
-  ​<​note>​Perform ARP cache poisoning from the attacker container to impersonate the gateway (router) for the victim.</​note>​+<​note>​ Perform ARP cache poisoning from the attacker container to impersonate the gateway (router) for the victim.</​note>​
  
   * Inside the "​Attacker"​ terminal   * Inside the "​Attacker"​ terminal
Line 505: Line 505:
 </​code>​ </​code>​
  
-//**STEP 4: Monitor ​the network traffic**//+//**STEP 4: Verify ​the Setup**//
  
-<​note>​Observe the impact of ARP poisoning and verify the attack'​s success.</​note>​+<​note> ​ Observe the impact of ARP poisoning and verify the attack'​s success. 
 +</​note>​
  
   * Open a second session on the attacker container   * Open a second session on the attacker container
-<​code>​ +<​code>​ tcpdump -i <​INTERFACE>​ -nvvX
-tcpdump -i <​INTERFACE>​ -nvvX+
 </​code>​ </​code>​
  
 <​note>​ Check the victim’s ARP table to confirm the gateway MAC address has been replaced with the attacker’s MAC. The victim’s traffic should now flow through the attacker. </​note>​ <​note>​ Check the victim’s ARP table to confirm the gateway MAC address has been replaced with the attacker’s MAC. The victim’s traffic should now flow through the attacker. </​note>​
 +<​code>​ ip nei sh
 +</​code>​
  
-=== [10p] Task B: Test Implementation ===+=== [10p] Test Implementation ===
  
 //**STEP 1: Monitor DNS traffic from the victim**// //**STEP 1: Monitor DNS traffic from the victim**//
  
-  * __Purpose:​__ ​Capture DNS traffic intercepted during the MitM attack to demonstrate how attackers can steal sensitive information.+<​note> ​Capture DNS traffic intercepted during the MitM attack to demonstrate how attackers can steal sensitive information.</​note>​
  
-<code bash> +  * In the attacker terminal 
-In the attacker terminal+<​code>​
 tcpdump udp port 53 -nvvX tcpdump udp port 53 -nvvX
 </​code>​ </​code>​
 +
  
 //**STEP 2: Simulate victim activity**//​ //**STEP 2: Simulate victim activity**//​
  
-  * __Purpose:​__ ​Generate network traffic from the victim to verify interception.+<​note> ​Generate network traffic from the victim to verify interception. ​Observe DNS traffic in the tcpdump output to confirm interception. </​note>​
  
-<code bash> 
-# In the victim terminal, check the ARP table 
-ip nei sh 
  
-# Ping a website to generate traffic +  * In the victim terminal, check the ARP table 
-ping my.secretwebsite.com+<​code>​ ip nei sh</​code>​
  
-# Unfortunately,​ IP forwarding inside containers doesn'​t work in this simulation,​ +  * Ping a website to generate ​traffic 
-# but the tcpdump on the attacker should still show intercepted ARP or DNS traffic. +<​code>​ ping my.secretwebsite.com ​</​code>​
-</​code>​+
  
-<​note> ​**TASK:** Observe DNS traffic ​in the tcpdump ​output to confirm interception</​note>​+  ​Unfortunately,​ IP forwarding inside containers doesn'​t work in this simulation, but the tcpdump ​on the attacker should still show intercepted ARP or DNS traffic.
  
-=== [10p] Mitigation and Defense === 
  
-//**STEP 1: Understand ​Mitigation ​Techniques**//​+=== Mitigation ​and Defense ===
  
   * __Why Mitigation is Necessary:​__ ARP spoofing is a common attack on local networks, especially public Wi-Fi. Implementing defenses can prevent unauthorized access and secure sensitive data.   * __Why Mitigation is Necessary:​__ ARP spoofing is a common attack on local networks, especially public Wi-Fi. Implementing defenses can prevent unauthorized access and secure sensitive data.
Line 556: Line 554:
     - Deploy intrusion detection systems (IDS) to monitor for unusual ARP activity.     - Deploy intrusion detection systems (IDS) to monitor for unusual ARP activity.
  
-<​note>​ **TASK:** Research how static ARP tables or DAI can be implemented on your network. If possible, try configuring them on your host or a VM. </​note>​ 
- 
-//**STEP 2: Apply Lessons Learned**// 
- 
-  * __Purpose:​__ Consolidate knowledge by applying techniques to protect against ARP spoofing in your own environments. 
  
-<​note>​ **TASK:** Document steps to configure defenses, monitor ARP activity, and secure communications. </​note>​ 
 ==== [10p] 4. Feedback ==== ==== [10p] 4. Feedback ====
  
isc/labs/08.1732503152.txt.gz · Last modified: 2024/11/25 04:52 by ebru.resul
CC Attribution-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0