Task 1: Address Resolution Protocol

Network switches and hubs

A network switch is a device that connects computers on a network. Differently from network hubs, which simply broadcast packets to all connected computers, it performs a more accurate delivery: packets are forwarded to the correct destination only.

On LANs implemented through network hubs, any computer is able to intercept any packet. Modern LANs are based on network switches, and interception is not directly possible. However, as we will see, networks switches do not provide security against interception.

Exercise

Open different terminals on client and attacker as explained in the prerequisites.

Run tcpdump -n -i eth0 icmp on the attacker host in order to sniff any icmp (ping) packet going through attacker’s eth0 interface, and then from the client:

ping server with ping -c1 server : you will see no output from tcpdump
ping attacker with ping -c1 attacker : you will get the ping request and response in tcpdump:
```
attacker # tcpdump -n -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:06:18.421201 IP 10.16.0.10 > 10.16.0.20: ICMP echo request, id 18176, seq 0, length 64
11:06:18.421336 IP 10.16.0.20 > 10.16.0.10: ICMP echo reply, id 18176, seq 0, length 64
```
Explanation: Docker network is implemented as a virtualised network switch and interception is not possible directly. When the client pings the server packets only flows through the client and the server and the attacker cannot intercept them. See also the screenshot showing how server (top) and attacker (bottom) only intercept pings directed to them.

Note: simple network switches learn the mapping between MAC addresses and network links (ports) dynamically, whenever they receive packets from links. If they do not know the mapping they behave as hubs, broadcasting the packet to every connected host. In the example above you could sometimes notice a single ICMP request which is broadcast to both server and attacker reflecting this behaviour.

The following picture from practicalnetworking.net explains this behaviour:

Address Resolution Protocol (ARP)

Address Resolution Protocol (ARP) maps IP addresses into ethernet MAC addresses and is a fundamental component of packet routing in LANs. As discussed above, switches use MAC addresses to correctly route packets on network links.

ARP Table

NOTE: to reproduce the following examples, do a docker-compose restart in order to reset hosts

The ARP table keeps track of the mappings between IPs and MACs. It is possible to inspect arp table as follows:

client # arp -vn
client #

Explanation: the table is initially empty, since the client has never communicated with any other host on the LAN.

In fact, ARP table is updated when needed. To observe this, try to ping the server and inspect again the table:

client # ping -c1 server
PING server (10.16.0.150): 56 data bytes
64 bytes from 10.16.0.150: seq=0 ttl=64 time=0.302 ms

--- server ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.302/0.302/0.302 ms

client # arp -vn
? (10.16.0.150) at 02:42:ac:11:65:50 [ether]  on eth0
client #

Explanation: the server host (IP 10.16.0.150 ) has been added in the table with its MAC address 02:42:ac:11:65:50 (check network configuration in prerequisites).

Inspecting ARP

It is interesting to observe how ARP table is updated through tcpdump .

We first remove the host from the table using option -d :

client # arp -d 10.16.0.150

client # arp -vn
client #

Explanation: the mapping is removed, meaning that any further request to the server will require an update of the ARP table. (NOTE: in some implementations you will still see the line in the table with <incomplete> in place of the MAC address)

On a different terminal on host client we run tcpdump . When we start ping -c1 server from the first terminal we observe the following output from tcpdump:

client # tcpdump  -n -i eth0 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:42:28.971090 ARP, Request who-has 10.16.0.150 tell 10.16.0.10, length 28
10:42:28.971151 ARP, Reply 10.16.0.150 is-at 02:42:ac:11:65:50, length 28

Explanation:

the first packet is a Request who-has 10.16.0.150 which is broadcast from 10.16.0.10 to all hosts on the LAN
the following answer Reply 10.16.0.150 is-at 02:42:ac:11:65:50 directly comes from the server and contains the mapping of IP 10.16.0.150 into the corresponding MAC address

We can check again the table with arp -vn to see that the mapping has been updated accordingly

Exercise

Restart hosts by issuing docker-compose restart and re-open one client and one server terminals. Ping the client from the server. The only entry in the server ARP table (use option -vn ) is the password for Task 2.