This shows you the differences between two versions of the page.
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 ==== | ||