Differences
This shows you the differences between two versions of the page.
|
isc:labs:08 [2024/11/25 02:21] ebru.resul [[30p] 2. Iptables] |
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 229: | Line 229: | ||
| ==== [30p] 2. Iptables ==== | ==== [30p] 2. Iptables ==== | ||
| - | Here's a [[https://gist.github.com/davydany/0ad377f6de3c70056d2bd0f1549e1017|iptables cheeatsheet]] to help you get started. | + | Here's an [[https://gist.github.com/davydany/0ad377f6de3c70056d2bd0f1549e1017|iptables cheeatsheet]] to help you get started. |
| - | Iptables is a command-line utility that acts as an interface to the netfilter firewall built into the Linux kernel. It allows you to define rules for incoming, outgoing, and forwarded traffic based on IP addresses, protocols, and ports.Think of it as the security checkpoint at a building. Guards check who’s entering, leaving, and passing through, ensuring only authorized people (or data packets) are allowed. With iptables, you establish these security checkpoints for your system's network traffic. | + | Iptables is a command-line utility that acts as an interface to the netfilter firewall built into the Linux kernel. Think of it as the security checkpoint at a building. Guards check who’s entering, leaving, and passing through, ensuring only authorized people (or data packets) are allowed. With iptables, you establish these security checkpoints for your system's network traffic. |
| - | ### **Why Use iptables?** | + | * **Why would you do this?** As a defender, iptables enables you to define network access rules by allowing or blocking traffic to specific ports, protocols, or IP addresses. You can prevent malicious activity, such as unauthorized SSH access or DDoS attacks. |
| - | - **As a Defender:** Iptables allows you to secure your system by defining granular rules to: | + | * **How can an attacker exploit this?** Attackers often aim to bypass firewall rules, exploit misconfigurations, or flood open ports with traffic (e.g., DDoS attacks). Misconfigured or permissive iptables rules can create entry points for attackers to exploit vulnerabilities. |
| - | - Prevent unauthorized access to sensitive services (e.g., SSH, HTTP). | + | |
| - | - Block traffic from malicious sources, such as known bad IPs or entire subnets. | + | |
| - | - Allow only trusted devices or users to access the server. | + | |
| - | - **For Network Policy Management:** | + | |
| - | - Restrict unnecessary traffic, improving performance and security. | + | |
| - | - Enable logging for auditing and monitoring network activity. | + | |
| - | ### **Real-World Importance** | + | **Real-World Importance** |
| - | - **Defending Against Attacks:** Iptables is often used to defend against brute-force SSH attacks by blocking IPs after too many failed login attempts. | + | * __Defending Against Attacks:__ Iptables is often used to defend against brute-force SSH attacks by blocking IPs after too many failed login attempts. |
| - | - **Mitigating DDoS Attacks:** Administrators use iptables to rate-limit connections to web servers, reducing the impact of distributed denial-of-service (DDoS) attacks. | + | * __Mitigating DDoS Attacks:__ Administrators use iptables to rate-limit connections to web servers, reducing the impact of distributed denial-of-service (DDoS) attacks. |
| - | - **Access Control:** By combining whitelists and blacklists, iptables ensures that only authorized users can access specific services or ports. | + | * __Access Control:__ By combining whitelists and blacklists, iptables ensures that only authorized users can access specific services or ports. |
| - | ### **Example in Action:** | + | **Real-World Examples:** A real-world example highlighting the consequences of misconfigured iptables rules is the "IptabLes and IptabLex botnet attacks". In 2014, security experts at Akamai-Prolexic discovered a botnet dubbed "IptabLes and IptabLex" that infected and exploited poorly maintained Linux servers to run large-scale Distributed Denial of Service (DDoS) attacks. |
| - | - Imagine a situation where a server is being spammed with SSH login attempts from a malicious IP. Using iptables, you can block this IP address immediately: | + | |
| - | ```bash | + | |
| - | iptables -A INPUT -s <malicious-IP> -p tcp --dport 22 -j DROP | + | |
| + | **Example in Action:** Imagine a situation where a server is being spammed with SSH login attempts from a malicious IP. Using iptables, you can block this IP address immediately: | ||
| + | iptables -A INPUT -s <malicious-IP> -p tcp --dport 22 -j DROP | ||
| + | === [5p] Best practices === | ||
| - | ---- | + | Here are some best practices when writing firewall rules (read them): |
| + | * Put specific rules at the top of the policy and generic rules at the bottom. The order matters | ||
| + | * The more criteria you specify in the rule, the less chance you will have of locking yourself out. There are plenty of ways in which you can be more specific, such as specifying the input or output interface (-i | -o), the source IP address (-s), the destination IP address (-d), the protocol and ports (''-p <tcp|udp> %%--%%dport|sport <number>''. | ||
| + | * First, place a rule at the very top of the ''INPUT'' chain, which includes the IP address of your workstation (in our case, the ''fep'' will originate your ssh packets to OpenStack), so that you won’t get locked out. A rule for whitelisting your IP address at the top of the policy looks like this. Notice that Insert (-I) was used instead of Append (-A), because we want this rule to be the **first**. <code> iptables -I INPUT -s "<FEP IP address>" -j ACCEPT </code> | ||
| + | * Add whitelist or blacklist rules for the types of traffic you use (or don't want to receive); you will do that for the next subtask! You should use the ''INPUT'' chain for that. | ||
| + | * You should use the connection tracking module(s) to bypass the firewall for already established (usually, outgoing) connections, otherwise replies cannot be received (if you drop them in ''INPUT''). | ||
| - | Iptables is an interface to the Netfilter firewall that is built into the Linux kernel. It provides an administrator with an interface to add, remove, and modify packet rules. | + | **Try to not get locked out of ssh-ing your virtual machine**! Double-check the rule before you add it to a iptables chain (always ask yourself: does it match a broad range of packets / will it filter my SSH traffic from ''fep'')! |
| + | === [10p] Secure Your VM from Unwanted SSH/HTTP Traffic (work in pairs) === | ||
| - | === [5p] Intro: Best practices === | + | //**STEP 1: Access Your Colleague’s VM and Observe Traffic**// |
| - | Here are some best practices when writing firewall rules (read them): | + | * __Purpose:__ Learn how to interact with a remote machine, analyze incoming SSH and HTTP traffic, and apply appropriate filtering rules to manage access. |
| - | * Put specific rules at the top of the policy and generic rules at the bottom. | + | <note>**TASK:** Work in pairs. Follow these steps: |
| - | * The more criteria you specify in the rule, the less chance you will have of locking yourself out. There are plenty of ways in which you can be more specific, such as specifying the input or output interface (''-i | -o''), the source IP address (''-s''), the destination IP address (''-d''), the protocol and ports (''-p <tcp|udp> %%--%%dport|sport <number>''. | + | - Ask your colleague for their VM IP address. |
| - | * First, place a rule at the very top of the ''INPUT'' chain, which includes the IP address of your workstation (in our case, the ''fep'' will originate your ssh packets to OpenStack), so that you won’t get locked out. A rule for whitelisting your IP address at the top of the policy looks like this. Notice that Insert (-I) was used instead of Append (-A), because we want this rule to be the **first**. <code bash> | + | - Use `curl` to connect to their HTTP server and display the server’s response |
| - | iptables -I INPUT -s "<FEP IP address>" -j ACCEPT | + | - Attempt to SSH into their VM using the credentials `hacker:student` |
| + | - If successful, send a broadcast message to your colleague’s system <code>hacker@<colleague-VM>$ wall "Wazzaap?" </code> | ||
| + | </note> | ||
| + | |||
| + | <solution -hidden> | ||
| + | <code> | ||
| + | # Example commands: | ||
| + | curl http://<colleague-VM-IP> | ||
| + | ssh hacker@<colleague-VM-IP> | ||
| + | wall "Wazzaap?" | ||
| </code> | </code> | ||
| - | * Add whitelist or blacklist rules for the types of traffic you use (or don't want to receive); you will do that for the next subtask! You should use the ''INPUT'' chain for that. | + | </solution> |
| - | * You should use the connection tracking module(s) to bypass the firewall for already established (usually, outgoing) connections, otherwise replies cannot be received (if you drop them in ''INPUT''). | + | |
| - | <note warning> | + | //**STEP 2: Monitor Incoming Traffic with tcpdump**// |
| - | **Try to not get locked out of ssh-ing your virtual machine**! Double-check the rule before you add it to a iptables chain (always ask yourself: does it match a broad range of packets / will it filter my SSH traffic from ''fep'')! | + | |
| - | </note> | + | |
| - | === [10p] Task B: Server Firewall === | + | * __Purpose:__ Analyzing network traffic is essential for troubleshooting, identifying unauthorized access, and auditing security. You can identify which machines are connecting to your services and how they interact with your system. |
| - | * For this task: work in pairs! | + | |
| - | * Ask for your colleague's VM IP address. Using ''curl'', read the message from his http server (check man / some examples if you never used it). | + | <note> |
| - | * See if you can ssh into it using the ''hacker:student'' credentials! When successful, send a broadcast message <code> | + | **TASK:** Use the 'tcpdump' tool to observe SSH connections to your machine: |
| - | hacker@<colleague-VM>$ wall "Wazzaap?" | + | - Run the following command to monitor all incoming traffic except packets from the FEP: <code>tcpdump -i eth0 'host not <FEP's IP address>'</code> |
| + | - Watch the output and note the source IPs of the OpenStack VMs connecting to your machine. | ||
| + | - Record the IPs for later use when setting up firewall rules. | ||
| + | </note> | ||
| + | |||
| + | <solution -hidden> | ||
| + | <code> | ||
| + | # Example tcpdump command: | ||
| + | tcpdump -i eth0 'host not <FEP's IP address>' | ||
| </code> | </code> | ||
| - | * Run ''tcpdump'' to see where ssh packets come from (make sure to ignore the ones coming from ''fep''):<code bash> | + | </solution> |
| - | tcpdump -i eth0 'host not <FEP's IP address here>' | + | |
| - | # note the source IP of the other OpenStack VMs connecting to you! | + | |
| - | </code> | + | |
| - | * We want to stop the spam, so blacklist the ''ssh'' (TCP port 22) and ''http'' (TCP port 80) from any other OpenStack VMs addresses (recall the CIDR range?). **Be extra careful not to ban yourself!** | + | |
| - | * You may still wish for your more civilised friends to be able to connect back to you. Whitelist them again by adding a ''ALLOW'' rule before the ones dropping the packets! | + | |
| - | <note tip> | ||
| - | If you want to turn off ''wall'' messages being displayed on your tty, check out ''man mesg'' command! | ||
| - | **But beware when nesting shells!** (e.g., from ''student'' to ''root'' using ''su''). In this case, you must exit them all and issue ''mesg'' on the first one (the tty spawned by ssh!). | + | //**STEP 3: Block Unwanted SSH and HTTP Traffic**// |
| + | |||
| + | * __Purpose:__ Controlling access to services is critical for securing systems against spam, unauthorized users, and brute-force attacks. Blocking unnecessary SSH and HTTP traffic helps prevent abuse and protects sensitive data. | ||
| + | |||
| + | <note> **TASK:** Use `iptables` to block SSH and HTTP connections from unauthorized machines: | ||
| + | - Use the OpenStack CIDR range to block SSH (TCP port 22) and HTTP (TCP port 80) traffic: | ||
| + | - ** Double-check your own IP is not in the blocked range to avoid locking yourself out.** | ||
| </note> | </note> | ||
| <solution -hidden> | <solution -hidden> | ||
| - | <code bash> | + | <code> |
| - | iptables -A INPUT -s 10.9.0.0/16 -p tcp --dport 80 -j DROP | + | # Example iptables rules: |
| + | iptables -A INPUT -s 10.9.0.0/16 -p tcp --dport 22 -j DROP | ||
| iptables -A INPUT -s 10.9.0.0/16 -p tcp --dport 80 -j DROP | iptables -A INPUT -s 10.9.0.0/16 -p tcp --dport 80 -j DROP | ||
| </code> | </code> | ||
| </solution> | </solution> | ||
| - | === [5p] Task C: Workstation Firewall === | ||
| - | * Any security-conscious user should secure his/her workstation. The recommended way is to block all traffic and whitelist only the required connections. | + | //**STEP 4: Allow Trusted Colleagues to Access Your VM**// |
| - | * **Note:** this task is for reference only! But check it out: it is a very good policy if you had it on a laptop that you use with public wifi hotspots (such as the ones offered by coffee shops or hotels), and you would not want anybody to compromise it. The policy would do a good job because it allows very few things in and out. If it doesn’t know what to do with a packet, the packet gets dropped automatically, because you set that up at the very beginning in the policy (''iptables ... -P DROP''): | + | |
| + | * __Purpose:__ While blocking unwanted access is critical, allowing trusted colleagues or team members to connect to your system ensures collaboration and prevents unintentional disruptions in a shared environment. | ||
| + | |||
| + | <note> | ||
| + | **TASK:** Add rules to allow SSH and HTTP traffic from your colleague’s IP: | ||
| + | - Insert the rules **before** the block rules | ||
| + | - Verify the rule placement using: <code>iptables -L -v</code> | ||
| + | </note> | ||
| + | |||
| + | <solution -hidden> | ||
| + | <code> | ||
| + | # Example iptables rules to whitelist a colleague's IP: | ||
| + | iptables -I INPUT 1 -s <colleague-VM-IP> -p tcp --dport 22 -j ACCEPT | ||
| + | iptables -I INPUT 2 -s <colleague-VM-IP> -p tcp --dport 80 -j ACCEPT | ||
| + | </code> | ||
| + | </solution> | ||
| + | |||
| + | |||
| + | <note tip> | ||
| + | If you want to stop `wall` messages from appearing on your terminal, check out the `man mesg` command. | ||
| + | |||
| + | **Reminder:** If you're using nested shells (e.g., switching from `student` to `root` using `su`), ensure you run `mesg` in the original tty spawned by SSH. | ||
| + | </note> | ||
| + | |||
| + | |||
| + | |||
| + | === [5p] Workstation Firewall === | ||
| + | |||
| + | * __Purpose:__ Everyone should take proactive measures to secure their workstation, especially when connecting to public Wi-Fi hotspots such as those found in coffee shops or hotels. By blocking all traffic and only allowing specific connections, you significantly reduce the risk of unauthorized access or compromise. This policy ensures only essential traffic is permitted, while unknown packets are automatically dropped, maintaining robust security. | ||
| + | |||
| + | * **Note:** While this task is for reference, implementing such a policy is highly effective for laptops used in insecure or high-risk environments. It minimizes exposure to threats by defaulting to a "deny-all" approach unless explicitly allowed. | ||
| <spoiler Workstation Firewall Script> | <spoiler Workstation Firewall Script> | ||
| Line 350: | Line 393: | ||
| </spoiler> | </spoiler> | ||
| - | === [10p] Task D: DNS blocking === | + | === [10p] DNS Blocking === |
| - | * Block access to Facebook by using iptables to block all [[https://routley.io/posts/hand-writing-dns-messages#question|DNS queries]] containing "facebook.com". | + | * __Purpose:__ DNS blocking is a practical way to restrict access to unwanted websites or domains, such as blocking social media on a corporate network. By intercepting and dropping DNS queries for specific domains, you can prevent users from accessing restricted content without interfering with the broader network's functionality. |
| - | * **Hint**: The ''string'' iptables module can do packet contents matching (''sudo iptables -m string -help''). But what does a DNS query look like? | + | |
| + | <note>**Task:** Block access to Facebook by dropping all DNS queries containing "facebook.com."</note> | ||
| + | |||
| + | * **Hint:** The `string` iptables module allows packet content matching, including DNS queries. Use the `--hex-string` option to specify binary contents, and choose an appropriate string matching algorithm for efficient filtering. | ||
| * **Note**: you can supply a hex string parameter with the syntax ''|HH HH HH ...|<plaintext>'' (e.g., ''hello|20 57 6F|rld'') to match binary contents of a packet! Also choose a string matching algorithm! | * **Note**: you can supply a hex string parameter with the syntax ''|HH HH HH ...|<plaintext>'' (e.g., ''hello|20 57 6F|rld'') to match binary contents of a packet! Also choose a string matching algorithm! | ||
| Line 362: | Line 408: | ||
| </solution> | </solution> | ||
| - | === [0p] Task E: Port knocking (bonus) === | ||
| - | * Start a netcat TCP server on 31337 and implement a port knocking scheme to open it! | + | === [0p] Task E: Port Knocking (Bonus) === |
| - | * Ask a colleague to scan your port. It should be seen as closed / filtered. | + | |
| - | * Then ask that colleague to knock the correct port sequence and connect to your netcat server. | + | * __Purpose:__ Port knocking is a powerful security technique used to obscure access to sensitive network services. By requiring a specific sequence of connection attempts (knocks) before opening a port, this method prevents unauthorized users from detecting or accessing the service. It’s particularly useful for protecting services on machines that need to remain hidden until needed, such as administrative tools or diagnostic servers. |
| + | |||
| + | <note>**Task:** | ||
| + | - Start a `netcat` TCP server on port `31337`. | ||
| + | - Configure a port knocking scheme so the server remains invisible (closed/filtered) until the correct sequence of port "knocks" is performed. | ||
| + | - Ask a colleague to scan your port. It should appear closed or filtered. | ||
| + | - Provide your colleague with the correct knock sequence and confirm they can access the `netcat` server after performing it. | ||
| + | </note> | ||
| + | |||
| + | * **Why It's Helpful:** | ||
| + | - Protects services from being discovered by malicious scans. | ||
| + | - Adds an extra layer of security for sensitive applications or servers. | ||
| + | - Enables stealthy and controlled access without leaving ports exposed. | ||
| + | |||
| + | * **Hint:** Use the `recent` iptables module to track and validate the knock sequence. | ||
| + | |||
| + | * **Reference:** [Arch Wiki: Port Knocking](https://wiki.archlinux.org/index.php/Port_knocking) | ||
| - | * Check out the ''recent'' iptables module! | ||
| - | * **Reference:** https://wiki.archlinux.org/index.php/Port_knocking | ||
| ==== [30p] 3. Man in the Middle ==== | ==== [30p] 3. Man in the Middle ==== | ||
| - | The ARP protocol is widely used for translating L3 (IP) addresses into L2 (data-link) addresses. | + | The Address Resolution Protocol (ARP) is used to map IP addresses (Layer 3) to MAC addresses (Layer 2) on local networks. However, ARP is inherently vulnerable because it lacks authentication. Attackers can exploit this weakness by forging ARP responses, tricking a victim into associating a legitimate IP (e.g., the router) with the attacker’s MAC address. This allows the attacker to intercept and manipulate network traffic, a classic example of a Man in the Middle (MitM) attack. |
| - | Unfortunately, it suffers from a critical security vulnerability: due to its unauthenticated nature, a destination machine has no way of determining whether a ARP reply is valid, so an attacker can forge ARP packets and tell a victim PC to associate the router's IP address to the attacker's MAC address, such that it will send all traffic through the victim's machine. | + | Think of this as you’re mailing a letter to your bank. A middleman secretly intercepts the letter, opens it, reads all your private information, and replaces it with their own fake letter before sending it to the bank. You never realize your communication was tampered with, but the middleman now has all your sensitive details. This is essentially what a Man-in-the-Middle attack does in a digital network. |
| - | === [20p] Task A: ARP Cache Poisoning === | ||
| - | * We will use two Docker containers to simulate a vulnerable local network (OpenStack filters ARP packets, so you won't be able to do this there). | + | * **Why would you do this as an attacker?** |
| - | <code bash> | + | - To intercept sensitive information like credentials or financial data being transmitted over the network. |
| - | # turn on IP Forwarding -- for the attacker (inherited from host) | + | - To disrupt communications, redirect traffic, or inject malicious content into a victim's browsing session. |
| - | # containers don't have permission for this and we don't want to bother with capabilities | + | - To gather intelligence on a target network or exploit vulnerabilities in intercepted traffic. |
| - | sudo sysctl -w net.ipv4.ip_forward=1 | + | |
| - | # Open a "Victim" terminal (on your VM): | ||
| - | docker run --rm -ti --entrypoint /bin/bash --name victim ubuntu:22.04 | ||
| - | # Open an "Attacker" terminal (also on the same VM): | ||
| - | docker run --rm -ti --entrypoint /bin/bash --name attacker --sysctl net.ipv4.ip_forward=1 ubuntu:22.04 | ||
| - | # we need two terminals for the attacker (for the tcpdump later) | + | **Real-World Example:** |
| - | # so... in a third terminal, spawn a Docker exec shell: | + | The 2015 Superfish Visual Discovery vulnerability in Lenovo laptops exposed millions of users to Man-in-the-Middle attacks by allowing attackers to intercept and decrypt HTTPS traffic, highlighting the dangers of pre-installed software and weak security practices. |
| - | docker exec -ti attacker /bin/bash | + | |
| - | </code> | + | |
| - | * **Victim terminal** (note: we're inside a container): install prerequisites & find out the IP address given by Docker: | + | **Is MitM Still Used?** Yes, Man-in-the-Middle attacks are still used today and remain a serious threat. Their methods, however, have evolved with the advance in technology |
| - | <code bash> | + | |
| - | apt update && apt install -y iproute2 iputils-ping netcat-openbsd | + | |
| - | ip a sh | + | |
| - | </code> | + | |
| - | * **Attacker terminal:** install prerequisites & establish yourself as the Man in the Middle using ARP Spoofing: | + | * Public Wi-Fi Networks: Attackers exploit insecure hotspots to intercept traffic. |
| - | <code bash> | + | * IoT Devices: Poorly secured devices provide new opportunities for interception. |
| - | # install prerequisites for this task | + | * Advanced Techniques: Attacks like SSL/TLS downgrades and HTTPS spoofing target encrypted connections. |
| - | apt update && apt install -y dsniff tcpdump iproute2 iputils-ping | + | |
| - | # start poisoning the host's ARP cache | + | **Mitigation Today:** |
| + | |||
| + | * Strict SSL/TLS protocols and certificate validation. | ||
| + | * Secure DNS implementations like DNSSEC and DNS over HTTPS. | ||
| + | * Use of Virtual Private Networks (VPNs) for secure communication on public networks. | ||
| + | |||
| + | ---- | ||
| + | For the following exercises, we will use Docker containers to simulate a local network vulnerable to ARP spoofing attacks. | ||
| + | |||
| + | === [20p] ARP Cache Poisoning === | ||
| + | |||
| + | //**STEP 1: Set up the environment**// | ||
| + | |||
| + | <note>Create a simulated network with Docker containers to demonstrate how ARP cache poisoning works in a controlled environment.</note> | ||
| + | |||
| + | |||
| + | * 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> | ||
| + | |||
| + | * Open a "Victim" terminal (inside your VM): | ||
| + | <code>docker run --rm -ti --entrypoint /bin/bash --name victim ubuntu:22.04</code> | ||
| + | |||
| + | * 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> | ||
| + | |||
| + | * Open a third terminal for an additional attacker session: | ||
| + | <code>docker exec -ti attacker /bin/bash</code> | ||
| + | |||
| + | //**STEP 2: Configure the victim container**// | ||
| + | |||
| + | <note> Prepare the victim machine to simulate a normal user in the network. | ||
| + | </note> | ||
| + | |||
| + | * Inside the "Victim" terminal | ||
| + | <code>apt update && apt install -y iproute2 iputils-ping netcat-openbsd</code> | ||
| + | |||
| + | * Find the IP address of the victim container | ||
| + | <code>ip a sh</code> | ||
| + | |||
| + | //**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> | ||
| + | |||
| + | * Inside the "Attacker" terminal | ||
| + | <code> | ||
| + | apt update && apt install -y dsniff tcpdump iproute2 iputils-ping</code> | ||
| + | |||
| + | |||
| + | * Start ARP poisoning | ||
| + | <code> | ||
| arpspoof -i <INTERFACE> -t <VICTIM_IP> <GATEWAY_IP> -r | arpspoof -i <INTERFACE> -t <VICTIM_IP> <GATEWAY_IP> -r | ||
| </code> | </code> | ||
| - | === [10p] Task B: Test Implementation === | + | //**STEP 4: Verify the Setup**// |
| - | * **Attacker terminal:** Listen for DNS traffic from the victim: | + | <note> Observe the impact of ARP poisoning and verify the attack's success. |
| - | <code bash> | + | </note> |
| - | tcpdump udp port 53 -nvvX | + | |
| + | * Open a second session on the attacker container | ||
| + | <code> tcpdump -i <INTERFACE> -nvvX | ||
| </code> | </code> | ||
| - | * **Victim terminal:** Open a netcat server and listen for content | + | <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 bash> | + | <code> ip nei sh |
| - | # check ARP table (your gateway's MAC should be the attacker's) | + | |
| - | ip nei sh | + | |
| - | # ping your favorite website | + | |
| - | ping my.secretwebsite.com | + | |
| - | # Unfortunately, IP forwarding inside container doesn't work :( | + | |
| </code> | </code> | ||
| - | The ''tcpdump'' capture on the Attacker terminal should show the intercepted DNS requests ;) | + | === [10p] Test Implementation === |
| + | |||
| + | //**STEP 1: Monitor DNS traffic from the victim**// | ||
| + | |||
| + | <note> Capture DNS traffic intercepted during the MitM attack to demonstrate how attackers can steal sensitive information.</note> | ||
| + | |||
| + | * In the attacker terminal | ||
| + | <code> | ||
| + | tcpdump udp port 53 -nvvX | ||
| + | </code> | ||
| + | |||
| + | |||
| + | //**STEP 2: Simulate victim activity**// | ||
| + | |||
| + | <note> Generate network traffic from the victim to verify interception. Observe DNS traffic in the tcpdump output to confirm interception. </note> | ||
| + | |||
| + | |||
| + | * In the victim terminal, check the ARP table | ||
| + | <code> ip nei sh</code> | ||
| + | |||
| + | * Ping a website to generate traffic | ||
| + | <code> ping my.secretwebsite.com </code> | ||
| + | |||
| + | * 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. | ||
| + | |||
| + | |||
| + | === 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. | ||
| + | |||
| + | * **Mitigation Techniques:** | ||
| + | - Use static ARP tables to bind specific IP-MAC pairs. | ||
| + | - Enable dynamic ARP inspection (DAI) if supported by your network hardware. | ||
| + | - Use encryption protocols (e.g., HTTPS, VPNs) to secure communications even in the presence of MitM attacks. | ||
| + | - Deploy intrusion detection systems (IDS) to monitor for unusual ARP activity. | ||
| ==== [10p] 4. Feedback ==== | ==== [10p] 4. Feedback ==== | ||
