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.
Open different terminals on client and attacker as explained in the prerequisites.
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.
NOTE: to reproduce the following examples, do a
docker-compose restartin 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).
It is interesting to observe how ARP table is updated through
We first remove the host from the table using option
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
- the first packet is a
Request who-has 10.16.0.150which is broadcast from
10.16.0.10to all hosts on the LAN
- the following answer
Reply 10.16.0.150 is-at 02:42:ac:11:65:50directly comes from the server and contains the mapping of IP
10.16.0.150into the corresponding MAC address
We can check again the table with
arp -vn to see that the mapping has been updated accordingly
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.