ARP - Address Resolution Protocol =================================== .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow **What is ARP?** * ARP stands for Address Resolution Protocol. It’s a network protocol used to map an IP address to a physical MAC address on a local area network (LAN). This is essential for devices to communicate over Ethernet/wifi. .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow **Why is ARP useful?** * Devices communicate using IP addresses, but data is actually sent using MAC addresses at the hardware level. ARP bridges this gap by helping a device find the MAC address that corresponds to a known IP address. Without ARP, devices wouldn’t know how to deliver packets on the local network. .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow **How it works?** * Device wants to send data – It knows the destination IP address but not the MAC address. * Sends ARP request – A broadcast message is sent to all devices on the LAN: “Who has this IP address?” * Receives ARP reply – The device with that IP replies with its MAC address. * Saves the mapping – The sender stores the IP-to-MAC mapping in its ARP cache for future use. .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow **Where is ARP used?** * Local networks (LANs) – To enable communication between devices like computers, printers, and routers. * Home and office networks – Every time a device sends data to another on the same subnet. * Network troubleshooting – Tools like arp -a help diagnose connectivity issues. .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow **Which OSI layer does this protocol belong to?** * It deals with MAC addresses, which are hardware-level identifiers. * It enables the delivery of packets within the same local network segment. * It works below the IP layer, translating IP addresses into MAC addresses for Ethernet communication. .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow Topics in this section, * :ref:`Learnings in this section ` * :ref:`Terminology ` * :ref:`Version Info ` * :ref:`ARP Version&RFC Details ` * :ref:`ARP Basic Setup on Ubuntu using IPv4 ` * :ref:`ARP Basic Setup on Ubuntu using IPv6 ` * :ref:`ARP Protocol Packet Details ` * :ref:`ARP Usecases ` * :ref:`ARP Basic Features ` * :ref:`ARP Feature : IP to MAC Resolution ` * :ref:`ARP Feature : Dynamic Addressing Mapping ` * :ref:`ARP Feature : Broadcast-Based Requests ` * :ref:`ARP Feature : Caching Mechanism ` * :ref:`ARP Feature : Gratuitous ARP ` * :ref:`ARP Feature : Stateless Protocol ` * :ref:`ARP Feature : No Authentication ` * :ref:`ARP Feature : Essential for IPv4 Networks ` * :ref:`Reference links ` .. _ARP_step1: .. tab-set:: .. tab-item:: Learnings in this section * In this section, you are going to learn .. _ARP_step2: .. tab-set:: .. tab-item:: Terminology * Terminology .. _ARP_step3: .. tab-set:: .. tab-item:: Version Info * Version Info .. _ARP_step5: .. tab-set:: .. tab-item:: ARP Version&RFC Details .. csv-table:: :file: ./ARP/arp_rfc_details.csv :widths: 10,10,10,30 :header-rows: 1 .. _ARP_step18: .. tab-set:: .. tab-item:: ARP Basic Setup on Ubuntu using IPv4 **Proxy ARP Test Case** * This test verifies that the router responds to ARP requests on behalf of another host when Proxy ARP is enabled. Succesfull ping from the router confirm Proxy ARP functionality. * Step-1 : Configure router to enable proxy ARP. .. code-block:: shell test:~$sudo sysctl -w net.ipv4.conf.all.proxy_arp=1 net.ipv4.conf.all.proxy_arp = 1 test:~$sudo sysctl -w net.ipv4.conf.wlp2s0.proxy_arp=1 net.ipv4.conf.wlp2s0.proxy_arp = 1 * Step-2: From Host A, Ping Host B. .. code-block:: shell test:~ping 192.168.50.204 PING 192.168.50.204 (192.168.50.204) 56(84) bytes of data. 64 bytes from 192.168.50.204: icmp_seq=1 ttl=64 time=125 ms 64 bytes from 192.168.50.204: icmp_seq=2 ttl=64 time=224 ms 64 bytes from 192.168.50.204: icmp_seq=3 ttl=64 time=320 ms 64 bytes from 192.168.50.204: icmp_seq=4 ttl=64 time=143 ms 64 bytes from 192.168.50.204: icmp_seq=5 ttl=64 time=166 ms * Step-3: See ouput of arp -a command. You should able to target IP mapped with its MAC address. .. code-block:: shell test:~arp -a RT-AX3000-ED38 (192.168.50.1) at c8:7f:54:37:ed:38 [ether] on wlp2s0 realme-12-Pro-5G (192.168.50.204) at 8a:5c:39:7a:20:7b [ether] on wlp2s0 * Step-4: Capture the response on Wireshark. * Expected result: * When Proxy ARP is enabled on the router, it should respond to ARP requests on behalf of another device (Host B). * Ping from Host A to Host B succeeds, and arp -a shows the correct MAC mapping. * Step-5: Wireshark Capture :download:`Download wireshark capture ` **ARP Cache Test Case** * This test checks if the ARP cache is correctly populated after flushing it. When a device is pinged, its MAC address is dynamically learned and added to the ARP table, confirming proper ARP resolution. * Step-1 : Clear ARP table .. code-block:: shell test:~$sudo ip -s -s neigh flush all 192.168.50.1 dev wlp2s0 lladdr c8:7f:54:37:ed:38 ref 1 used 6/6/2probes 1 REACHABLE 192.168.50.6 dev wlp2s0 lladdr 8a:5c:39:7a:20:7b used 3893/3893/3873probes 4 STALE *** Round 1, deleting 2 entries *** *** Flush is complete after 1 round *** * Step-2: Check arp table, only gateway MAC would be seen. .. code-block:: shell test:~$arp -a RT-AX3000-ED38 (192.168.50.1) at c8:7f:54:37:ed:38 [ether] on wlp2s0 * Step-3: Ping another local device. .. code-block:: shell test:~$ping 192.168.50.183 PING 192.168.50.183 (192.168.50.183) 56(84) bytes of data. 64 bytes from 192.168.50.183: icmp_seq=1 ttl=64 time=125 ms 64 bytes from 192.168.50.183: icmp_seq=2 ttl=64 time=224 ms 64 bytes from 192.168.50.183: icmp_seq=3 ttl=64 time=320 ms 64 bytes from 192.168.50.183: icmp_seq=4 ttl=64 time=143 ms 64 bytes from 192.168.50.183: icmp_seq=5 ttl=64 time=166 ms * Step-4: Run arp -a .. code-block:: shell test:~$arp -a shilpa (192.168.50.183) at 0c:9a:3c:9f:17:71 [ether] on wlp2s0 RT-AX3000-ED38 (192.168.50.1) at c8:7f:54:37:ed:38 [ether] on wlp2s0 * Step-5: Capture the response on wireshark. * Expected result: * After flushing the ARP cache, only the default gateway's MAC address should remain. * Pinging a local device should trigger ARP resolution and dynamically populate its MAC in the ARP table. * Step-6: Wireshark Capture :download:`Download wireshark capture ` **Static ARP entries Test Case** * This test verifies that manually added static ARP entries persist in the ARP table even after a reboot or timeout. The entry is marked as PERM, confirming it wont be aged out or replaced. * Step-1: Add Static ARP. .. code-block:: shell test:~$sudo arp -s * Step-2: Reboot or wait timeout period. * Step-3: Chech arp table , entry should remain. .. code-block:: shell test:~$arp -a RT-AX3000-ED38 (192.168.50.1) at c8:7f:54:37:ed:38 [ether] on wlp2s0 realme-12-Pro-5G (192.168.50.6) at 8a:5c:39:7a:20:7b [ether] PERM on wlp2s0 * Step-4: Capture the response on wireshark. * Expected result: * Static ARP entry should persist in the ARP table with a PERM flag, even after reboot or timeout. * No ARP request should be seen in Wireshark for the static IP, confirming the MAC is already known and not resolved dynamically. * Step-5: Wireshark Capture :download:`Download wireshark capture ` **ARP Request Handling Test Case** * This test checks if a device correctly responds to a valid ARP request sent using arping. The target device replies with its MAC address, confirming successful ARP resolution and communication. * Step-1: Use arping to send ARP request to known IP. .. code-block:: shell test:~$sudo arping -c 1 192.168.50.117 ARPING 192.168.50.117 42 bytes from 70:cd:0d:c9:9b:c7 (192.168.50.117): index=0 time=359.440 msec --- 192.168.50.6 statistics --- 1 packets transmitted, 1 packets received, 0% unanswered (0 extra) rtt min/avg/max/std-dev = 359.440/359.440/359.440/0.000 ms * Step-2: Capture the response on wireshark. * Expected result: * The target device should reply to the ARP request with its MAC address, confirming it is reachable. * Wireshark capture should show an ARP request from the source and a matching ARP reply from the target. * Step-3: Wireshark Capture :download:`Download wireshark capture ` **ARP Reply Handling Test Case** * Step-1: Use arpspoof to send unsolicited ARP reply * This test checks if a device accepts unsolicited ARP replies (sending fake ARP reply without a request) using arpspoof. The target updates its ARP table with the attacker's MAC, confirming the reply was accepted. .. code-block:: shell test1:~$sudo arpspoof -i wlp2s0 -t 192.168.50.122 192.168.50.113 * Step-2: Ping your IP on target machine. .. code-block:: shell test2:~$ping 192.168.50.113 * Step-3: Check arp table. .. code-block:: shell test2:~$arp -a * Step-4: Capture the response on wireshark. * Expected result: * The target device should update its ARP table with the attacker's MAC address upon receiving the unsolicited ARP reply. * Wireshark capture should show an unsolicited ARP reply from the attacker and no corresponding ARP request from the target. * Step-5: Wireshark Capture :download:`Download wireshark capture ` **ARP Timeout/Aging Test Case** * This test Verifies that the ARP entries expire after a timeout period if unsed. After pinging a device and waiting, the ARP entry transitions to STALE and eventually disappers, confirming proper aging behaviour. * Step-1: Clear ARP table .. code-block:: shell test:~$sudo ip -s -s neigh flush all * Step-2: Ping a device to populated ARP cache. .. code-block:: shell test:~$ping 192.168.50.6 PING 192.168.50.6 (192.168.50.6) 56(84) bytes of data. 64 bytes from 192.168.50.6: icmp_seq=1 ttl=64 time=125 ms 64 bytes from 192.168.50.6: icmp_seq=2 ttl=64 time=224 ms 64 bytes from 192.168.50.6: icmp_seq=3 ttl=64 time=320 ms 64 bytes from 192.168.50.6: icmp_seq=4 ttl=64 time=143 ms 64 bytes from 192.168.50.6: icmp_seq=5 ttl=64 time=166 ms * Step-3: Wait ARP timeout period (1-2mins) * Step-4: Run ip neigh command, shows STALE for ping IP, represents that will disappear if we dont use) .. code-block:: shell test:~$ip neigh 192.168.50.1 dev wlp2s0 lladdr c8:7f:54:37:ed:38 REACHABLE 192.168.50.6 dev wlp2s0 lladdr 8a:5c:39:7a:20:7b STALE * Step-5: Capture the response on wireshark. * Expected result: * After pinging, the ARP entry should transition from REACHABLE to STALE and eventually be removed if unused, confirming proper aging. * Step-6: Wireshark Capture :download:`Download wireshark capture ` **ARP Table Overflow Test Case** * This test simulates ARP cache overflow by adding 100 fake static entries to the ARP table. The system accepts and retains these entries as PERM, confirming its ability to handle a large ARP table without errors. * Step-1: Use a script or tool to ARP many fake enries. .. code-block:: shell test:~$for i in {1..100}; do sudo ip neigh add 192.168.0.$i lladdr 02:00:00:00:00:$((i % 100)) dev wlp2s0 2>/dev/null done * Step-2: Monitor ARP table. Many ARP entries (including real and fake ) should succesfully added and shows as PERM. .. code-block:: shell test:~$arp -a * Step-3: Capture the response on wireshark. * Expected result: * The ARP table should accept and retain all 100 static (PERM) entries without dropping or overwriting existing ones. * Wireshark should show no ARP traffic for these static entries, confirming they were not dynamically resolved. * Step-4: Wireshark Capture :download:`Download wireshark capture ` **ARP Rate Limiting Test Case** * This test checks if the system limits excessive ARP traffic by sending 50 rapid ARP requests. A significant portion of requests are dropped, confirming that ARP rate limiting is active and effective. * Step-1: Send 50 ARP rquests using arping. .. code-block:: shell test:~$sudo arping -c 50 192.168.50.6 ARPING 192.168.50.6 Timeout 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=0 time=214.414 msec 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=1 time=144.378 msec Timeout Timeout 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=2 time=204.545 msec Timeout Timeout Timeout Timeout Timeout Timeout Timeout 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=3 time=501.430 msec Timeout Timeout Timeout 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=4 time=491.688 msec Timeout Timeout Timeout 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=5 time=368.760 msec Timeout Timeout Timeout 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=6 time=252.911 msec Timeout Timeout 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=7 time=158.205 msec Timeout Timeout Timeout 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=8 time=309.092 msec 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=9 time=127.322 msec Timeout 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=10 time=174.753 msec 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=11 time=199.963 msec 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=12 time=132.498 msec Timeout Timeout 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=13 time=187.470 msec Timeout Timeout Timeout 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=14 time=170.034 msec Timeout Timeout Timeout 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=15 time=470.797 msec Timeout --- 192.168.50.6 statistics --- 50 packets transmitted, 16 packets received, 68% unanswered (0 extra) rtt min/avg/max/std-dev = 127.322/256.766/501.430/126.860 ms * Step-2: Capture response on wireshark. * Expected result: * The system should drop or ignore a large number of rapid ARP requests, resulting in partial replies (e.g., 16/50), confirming rate limiting. * Wireshark capture should show that only a subset of ARP requests receive replies, with increasing delays or silent drops for excessive traffic. * Step-3: Wireshark Capture :download:`Download wireshark capture ` **ARP Retry Behaviour Test Case** * This test verfies that the system retries ARP requests when pinging a nonexistent IP. Multiple ARP requests (typically 3-5) are sent before the system marks the host unreachable, confirming standard retry behaviour. * Step-1: Ping a Non-Existent IP on local Subnet. .. code-block:: shell test:~$ping -c 5 192.168.50.200 PING 192.168.50.200 (192.168.50.200) 56(84) bytes of data. From 192.168.50.110 icmp_seq=1 Destination Host Unreachable From 192.168.50.110 icmp_seq=2 Destination Host Unreachable From 192.168.50.110 icmp_seq=3 Destination Host Unreachable From 192.168.50.110 icmp_seq=4 Destination Host Unreachable From 192.168.50.110 icmp_seq=5 Destination Host Unreachable --- 192.168.50.200 ping statistics --- 5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4081ms pipe 4 * Step-2: Use Wireshark to count ARP retries. * Expected result: * The system should send multiple ARP requests (typically 3 to 5) before declaring the host unreachable, confirming standard retry behavior. * Wireshark capture should show repeated ARP requests with no replies, followed by ICMP “Destination Host Unreachable” messages. * Step-3: Wireshark Capture :download:`Download wireshark capture ` **ARP Filtering Test Case** * This test verifies that ARP replies are blocked using nftables on a specific interface, preventing the system from responding to ARP requests. As a result, ping attempts from another device fail due to unresolved IP-to-MAC mapping. * Step-1: Create the arpfillter table. .. code-block:: shell test1:~$sudo nft add table netdev arpfilter * Step-2: Attach the ARP filtering rule to incoming traffic on the network interface. Hooks into the ingress of interface. .. code-block:: shell test1:~$sudo nft add chain netdev arpfilter input { type filter hook ingress device wlp2s0 priority 0 \;} * Step-3: Attach the ARP filtering rule to drop all ARP traffic arriving on that interface. .. code-block:: shell test1:~$sudo nft add rule netdev arpfilter input ether type arp drop * Step-4: Send ARP request to that interface. .. code-block:: shell test2:~$ping 192.168.50.113 * Step-5: Capture the response on wireshark. * Expected result: * All ARP packets arriving on the filtered interface should be dropped, preventing ARP replies and IP-to-MAC resolution. * Ping attempts from other devices should fail due to unresolved MAC addresses, and Wireshark should show ARP requests without replies on that interface. * Step-6: Wireshark Capture :download:`Download wireshark capture ` **ARP on Bridged Interfaces Test Case** * This test verifies that ARP requests and replies should pass through the virtual bridge, allowing to resolve each other's MAC addresses. * Step-1: Create a bridge interface. (veth pairs- virtual ethernet cables) .. code-block:: shell test1:~$sudo ip link add veth1 type veth peer name veth1-br test1:~$sudo ip link add veth1 type veth peer name veth2-br * Step-2: Create bridge and attach interfaces. .. code-block:: shell test1:~$sudo ip link add name br0 type bridge test1:~$sudo ip link set br0 up test1:~$sudo ip link set veth1-br master br0 test1:~$sudo ip link set veth2-br master br0 test1:~$sudo ip link set veth1-br up test1:~$sudo ip link set veth2-br up * Step-3: Create network namespaces .. code-block:: shell test1:~$sudo ip netns add ns1 test1:~$sudo ip netns add ns2 * Step-4: Move veth1 and veth2 into namespaces .. code-block:: shell test1:~$sudo ip link set veth1 netns ns1 test1:~$sudo ip link set veth2 netns ns2 * Step-5: Assign IP address. .. code-block:: shell test1:~$sudo ip netns exec ns1 ip addr 192.168.1.10/24 dev veth1 test1:~$sudo ip netns exec ns1 ip link set veth1 up test1:~$sudo ip netns exec ns1 ip link set lo up test1:~$sudo ip netns exec ns2 ip addr 192.168.1.20/24 dev veth2 test1:~$sudo ip netns exec ns2 ip link set veth2 up test1:~$sudo ip netns exec ns2 ip link set lo up * Step-6: Test ARP behaviour by pinging between connected devices. .. code-block:: shell test1:~$ping -c 2 192.168.1.20 PING 192.168.1.20 (192.168.1.20) 56(84) bytes of data. 64 bytes from 192.168.1.20: icmp_seq=1 ttl=64 time=413 ms 64 bytes from 192.168.1.20: icmp_seq=2 ttl=64 time=314 ms --- 192.168.1.20 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1000ms rtt min/avg/max/mdev = 314.165/363.574/412.984/49.409 ms * Step-7: Capture the response on wireshark. * Expected result: * ARP requests and replies should successfully traverse the virtual bridge, enabling MAC address resolution between namespaces. * Wireshark should capture proper ARP exchanges between the bridged interfaces, confirming seamless L2 communication through the bridge. * Step-8: Wireshark Capture :download:`Download wireshark capture ` **Duplicate IP detection Test Case** * To verify how the network handles a situation where two devices are assigned the same IP address, which should trigger an IP conflict and prevent proper communication. * Step-1: Assign Same IP to two devices. Here I have used 2 Laptops and mobile. * Step-2: Check your laptop's IP address .. code-block:: shell test1:~$ifconfig br0: flags=4099 mtu 1500 ether 62:47:a9:f6:2b:ca txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 2 overruns 0 carrier 0 collisions 0 enp1s0: flags=4099 mtu 1500 ether b4:a9:fc:7b:e4:ee txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 1000 (Local Loopback) RX packets 102152 bytes 9652412 (9.6 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 102152 bytes 9652412 (9.6 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 virbr0: flags=4099 mtu 1500 inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255 ether 52:54:00:1a:ed:e4 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 344 overruns 0 carrier 0 collisions 0 wlp2s0: flags=4163 mtu 1500 inet 192.168.50.110 netmask 255.255.255.0 broadcast 192.168.50.255 inet6 fe80::48f0:513:7352:fd4a prefixlen 64 scopeid 0x20 ether e8:6f:38:71:f1:e3 txqueuelen 1000 (Ethernet) RX packets 5317022 bytes 7116415323 (7.1 GB) RX errors 0 dropped 19116 overruns 0 frame 0 TX packets 919187 bytes 146487549 (146.4 MB) TX errors 0 dropped 707 overruns 0 carrier 0 collisions 0 * Step-3: Assign the same IP address to your mobile device manually (192.168.50.110) (via Wi-Fi settings -> Static IP). * Step-4: Reconnect both devices to the same network (Wi-Fi or LAN) * Step-5: From a third device (Laptop 3), try to ping the duplicate IP. .. code-block:: shell test3:~$ping 192.168.50.110 * Step-6: Open Wireshark on any device and capture traffic to observe ARP conflict or duplicate IP detection packets. * Expected result: * An IP conflict should occur, resulting in unstable communication — ARP replies may alternate between devices or trigger conflict messages. * Wireshark should show multiple ARP replies for the same IP from different MAC addresses, indicating a duplicate IP on the network. * Step-7: Wireshark Capture :download:`Download wireshark capture ` **One-Way ARP spoofing to Client/poisoning detection Test Case** * To test if a client device can be tricked into associating the gateway's IP with the attacker's MAC address, effectively rerouting traffic through the attacker. * Step-1: Connect three devices (Attacker-L1, Client-L2, Gateway-L3) to the same network. * Step-2: Disable firewalls on L1 and L2. * Step-3: On L1(attacker), run. .. code-block:: shell test1:~$sudo arpspoof -i -t * Step-4: On L2(client), ping the gateway (Triggering network activity). .. code-block:: shell test2:~$ping * Step-5: On L2, check the ARP table. .. code-block:: shell test2:~$arp -a * Step-6: Use wireshark to capture unsolicited ARP replies from attacker. * Expected result: * L2's(Client) ARP table shows the attacker's MAC for the gatewa's IP. * Wireshark shows repeated ARP replies from Attacker claiming to be Gateway. * Step-7: Wireshark Capture :download:`Download wireshark capture ` **One-Way ARP spoofing to Gateway/poisoning detection Test Case** * To test if the gateway device can be tricked into associating the client's IP with the attacker's MAC address, effectively rerouting traffic through the attacker. * Step-1: Connect three devices (Attacker-L1, Client-L2, Gateway-L3) to the same network. * Step-2: Disable firewalls on L1 and L3. * Step-3: On L1(attacker), run. .. code-block:: shell test1:~$sudo arpspoof -i -t * Step-4: On L3(gateway), ping the client (Triggering network activity). .. code-block:: shell test3:~$ping * Step-5: On L3, check the ARP table. .. code-block:: shell test3:~$arp -a * Step-6: Use wireshark to capture unsolicited ARP replies from attacker. * Expected result: * L3's(Gateway) ARP table shows the attacker's MAC for the Client's IP. * Wireshark shows repeated ARP replies from Attacker claiming to be Client. * Step-7: Wireshark Capture :download:`Download wireshark capture ` **ARP Ping Test Case** * To verify that ARP resolution only when needed-i.e., the first ping triggers ARP requests, but subsequent pings use the cached MAC address without sending new ARP packets. * Step-1: Ping the target device from your system .. code-block:: shell test1:~$ping 192.168.50.122 * Step-2: Check the arp table to confirm the MAC address is cached. .. code-block:: shell test1:~$arp -a * Step-3: Ping the target device from your system again. .. code-block:: shell test1:~$ping 192.168.50.122 * Step-4: Capture traffic using wireshark during both pings. * Expected result: * During the first ping, Wireshark should show ARP request and reply packets, as your system resolves the MAC address of the target. * The ARP table should now contain the target's IP and MAC. * During the second ping, Wireshark should show only ICMP (ping) packets, with no ARP traffic, since the MAC is already cached. * Step-5: Wireshark Capture :download:`Download wireshark capture ` **ARP Static Assign MAC and Ping Test Case** * To verify that when a static ARP entry is manually added, the system uses if for communication without sending ARP requests. * Step-1: Add a static ARP entry for the target IP and MAC .. code-block:: shell test1:~$sudo arp -s * Step-2: Verify the ARP table to confirm the entry is present and marked as PERM (permanent) .. code-block:: shell test1:~$arp -a * Step-3: Ping the target IP. .. code-block:: shell test1:~$ping * Step-4: Capture traffic using wireshark during the ping. * Expected Result: * The ARP table shows the static entry with correct MAC address. * No ARP packets are seen in wireshark during the ping. * Only ICMP request and reply packets are visible, confirming that the system used the static ARP entry directly. * Step-5: Wireshark Capture :download:`Download wireshark capture ` **Persistent ARP Cache Poisoning (Static ARP Entry Bypass) Test Case** * This test whether continuous ARP spoofing can bypass or overwrite a manually added static ARP entry on a victim device, depending on the operating system's ARP cache behaviour. * Step-1: Enable IP forwarding on the attacker's device to allow packet routing. .. code-block:: shell test1:~$sudo sysctl -w net.ipv4.ip_forward=1 * Step-2: On the client device, add a static ARP entry for the gateway. .. code-block:: shell test2:~$sudo arp -s * Step-3: Verify the static ARP entry .. code-block:: shell test2:~$arp -a * Step-4: Start continuous ARP spoofing from the attacker, targeting both the client and the gateway. Run this two commands on different terminals. .. code-block:: shell test1:~$sudo arpspoof -i -t test1:~$sudo arpspoof -i -t * Step-5: On the client, ping the gateway. .. code-block:: shell test2:~$ping * Step-6: Capture traffic using wireshark on any device to observe spoofed ARP replies. * Expected result: * Wireshark shows repeated unsolicited ARP replies from the attacker, mapping both the gateway and client IPs to the attacker's MAC. * On the client side, the static ARP entry may not be overwritten(depending on OS behaviour), but spoofed packets are still visible. * Some systems may show duplicate entries or ignore spoofed replies due to the static entry. * Step-7: Wireshark Capture :download:`Download wireshark capture ` **ARP poisoning on Non-Existent IP Address Test Case** * This test how a client device reacts when an attacker sends spoofed ARP replies from an IP address that dosen't exist on the network. * Step-1: Choose a non-existent IP address.(e.g., one not currently used in the subnet) * Step-2: On the client , clear the arp cache. .. code-block:: shell test2:~$sudo ip -s -s neigh flush all * Step-3: On the attacker, start spoofing ARP replies for the non-existent IP. .. code-block:: shell test1:~$sudo arpspoof -i -t * Step-4: On the Client, check the ARP table. .. code-block:: shell test2:~$arp -a * Step-5: Ping the non-existent IP from the client. .. code-block:: shell test2:~$ping * Step-6: Capture traffic using wireshark on attacker or client. * Expected result: * The non-existent IP appears in the client's ARP table, mapped to the attacker's MAC address. * Wireshark shows spoofed ARP replies from the attacker for the non-existent IP. * when the client pings the non-existent IP, the ICMP request is redirected to the attacker, who cannot route it, resuting in Destination Host Unrechable. * This confirms taht the attacker can poison the ARP cache even for unused IPs. * Step-7: Wireshark Capture. :download:`Download wireshark capture ` **ARP "Healing" and Restoration Test Case** * To demonstrate how ARP spoofing can be reversed - either manually by sending correct ARP replies or automatically when spoofing stops-allowing devices to restore accurate IP-to-MAC mappings. * Step-1: Enable IP forwarding on the attacker to allow traffic routing .. code-block:: shell test1:~$ sudo sysctl -w net.ipv4.ip_forward=1 * Step-2: Start ARP spoofing from the attacker to poison both the client and the gateway. .. code-block:: shell test1:~$sudo arpspoof -i -t test1:~$sudo arpspoof -i -t * Step-3: On the client, ping the gateway. .. code-block:: shell test2:~$ping * Step-4: Check the ARP tables on both client and gateway .. code-block:: shell test2:~$arp -a test3:~$arp -a * Step-5: Stop spoofing on the attcker by pressing Ctrl+C in both spoofing terminals. * Step-6: Recheck ARP tables on client and gateway to observe if correct MAC addresses are restored. * Step-7: Use wireshark to capture traffic during and after spoofing. * Expected result: * While Spoofing is active, ARP tables on both client and gateway show the attacker's MAC for each other's IP. * When spoofing is stopped, the attacker sends "healing" ARP replies with the correct MAC addresses. * ARP tables on both the devices are restored to correct mappings. * Wireshark shows a burst of ARP replies with valid MACs after spoofing stops. * Step-8: Wireshark Capture. :download:`Download wireshark capture ` **Gratuitous ARP Test Case** * This test verify that a device sends a Gratuitous ARP when it is assigned a new IP address or reconnects to the network-helping other devices update their ARP tables with the correct MAC-IP mapping. * Step-1: Assign a new IP address to the device or reconnect it to the network. .. code-block:: shell test1:~$sudo ifconfig up * Step-2: Optionally bring the interface down and up again to simulate reconnection. .. code-block:: shell test1:~$sudo ip link set down test1:~$sudo ip link set up * Step-3: Send a Gratuitous ARP manually .. code-block:: shell test1:~$sudo arping -A -I * Step-4: capture traffic using wireshark on another device or the same device. * Expected result: * Wireshark should show an ARP request where the source and target IP are the same- this is a Gratuitous ARP. * Step-5: Wireshark Capture. :download:`Download wireshark capture ` .. _ARP_step19: .. tab-set:: .. tab-item:: ARP Basic Setup on Ubuntu using IPv6 * Setup .. _ARP_step6: .. tab-set:: .. tab-item:: ARP Protocol Packet Details **ARP Request Packet** .. csv-table:: :file: ./ARP/arp-packet1_details.csv :widths: 10,20,30,10 :header-rows: 1 **ARP Reply Packet** .. csv-table:: :file: ./ARP/arp-packet2_details.csv :widths: 10,20,30,10 :header-rows: 1 .. _ARP_step7: .. tab-set:: .. tab-item:: ARP Usecases .. csv-table:: :file: ./ARP/arp_usecases.csv :widths: 10,20,30 :header-rows: 1 .. _ARP_step8: .. tab-set:: .. tab-item:: ARP Basic Features .. csv-table:: :file: ./ARP/arp_features.csv :widths: 10,10,30 :header-rows: 1 .. _ARP_step9: .. tab-set:: .. tab-item:: ARP Feature : IP to MAC Resolution **IP to MAC Resolution - Testcases** .. csv-table:: :file: ./ARP/arp_feature1_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _ARP_step10: .. tab-set:: .. tab-item:: ARP Feature : Dynamic Addressing Mapping **Dynamic Addressing Mapping - Testcases** .. csv-table:: :file: ./ARP/arp_feature2_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _ARP_step11: .. tab-set:: .. tab-item:: ARP Feature : Broadcast-Based Requests **Broadcast-Based Requests - Testcases** .. csv-table:: :file: ./ARP/arp_feature3_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _ARP_step12: .. tab-set:: .. tab-item:: ARP Feature : Caching Mechanism **Caching Mechanism - Testcases** .. csv-table:: :file: ./ARP/arp_feature4_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _ARP_step13: .. tab-set:: .. tab-item:: ARP Feature : Gratuitous ARP **Gratuitous ARP - Testcases** .. csv-table:: :file: ./ARP/arp_feature5_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _ARP_step14: .. tab-set:: .. tab-item:: ARP Feature : Stateless Protocol **Stateless Protocol - Testcases** .. csv-table:: :file: ./ARP/arp_feature6_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _ARP_step15: .. tab-set:: .. tab-item:: ARP Feature : No Authentication **No Authentication - Testcases** .. csv-table:: :file: ./ARP/arp_feature7_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _ARP_step16: .. tab-set:: .. tab-item:: ARP Feature : Essential for IPv4 Networks **Essential for IPv4 Networks - Testcases** .. csv-table:: :file: ./ARP/arp_feature8_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _ARP_step17: .. tab-set:: .. tab-item:: Reference links * Reference links