Your first task is to run two docker instances, understand the basics of networking and inspect packets using
Use two terminals to start two identical images as:
# from terminal 1 $ docker run -it --rm secunive/seclab:lab4 ash # from terminal 2 $ docker run -it --rm secunive/seclab:lab4 ash
You can inspect network interfaces using
ifconfig (run this in terminal 1):
# ifconfig eth0 Link encap:Ethernet HWaddr 02:42:AC:11:00:02 inet addr:172.17.0.2 Bcast:172.17.255.255 Mask:255.255.0.0 ... lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 ...
- there are two interfaces
255.255.0.0, meaning that the interface is connected to a subnetwork in which hosts have address of the form
172.17.*.*. Broadcast address is
255.0.0.0and represents the loopback interface, mapping directly to the local host
Check connectivity: ping
We now use
ping to check network connectivity. We first run ping with the
# ping 172.17.0.2 PING 172.17.0.2 (172.17.0.2): 56 data bytes 64 bytes from 172.17.0.2: seq=0 ttl=64 time=0.095 ms 64 bytes from 172.17.0.2: seq=1 ttl=64 time=0.093 ms 64 bytes from 172.17.0.2: seq=2 ttl=64 time=0.083 ms
ping sends a
ICMP echo request to the destination that answers with a
ICMP echo reply . When the reply is received the roundtrip time is displayed, for diagnostic purposes. In this example the host is pinging itself using the external network interface
eth0 (notice that replies come from address
172.17.0.2 even if we are pinging the local host).
A similar effect is achieved when pinging
localhost (which is an alias for
# ping localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: seq=0 ttl=64 time=0.097 ms 64 bytes from 127.0.0.1: seq=1 ttl=64 time=0.094 ms 64 bytes from 127.0.0.1: seq=2 ttl=64 time=0.094 ms
172.17.0.2 from the second docker instance (that probably has address
172.17.0.3) and vice-versa, to check network connectivity between the two hosts.
tcpdump is a powerful tool for traffic analysis. For example, we can run it on host
172.17.0.2 in order to inspect the ICMP packets sent/received by
# tcpdump -n icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
-nprevents converting addresses to names
icmpspecifies to only inspect ICMP packets
Now if we ping from host
172.17.0.3 we get the following output:
18:16:58.300947 IP 172.17.0.3 > 172.17.0.2: ICMP echo request, id 2560, seq 0, length 64 18:16:58.301009 IP 172.17.0.2 > 172.17.0.3: ICMP echo reply, id 2560, seq 0, length 64 18:16:59.301422 IP 172.17.0.3 > 172.17.0.2: ICMP echo request, id 2560, seq 1, length 64 18:16:59.301509 IP 172.17.0.2 > 172.17.0.3: ICMP echo reply, id 2560, seq 1, length 64 18:17:00.305286 IP 172.17.0.3 > 172.17.0.2: ICMP echo request, id 2560, seq 2, length 64 18:17:00.305316 IP 172.17.0.2 > 172.17.0.3: ICMP echo reply, id 2560, seq 2, length 64
We observe that
- each line is a packet
- packets from
ICMP echo requests
- packets from
ICMP echo replies
- requests and replies have matching
ARP protocol is used to discover the Media Access Control (MAC) address corresponding to a certain IP address. Whenever a host needs to connect to an IP that has not used recently (for which it has a cached MAC address), it broadcasts a ARP request.
Find the correct tcpdump option to sniff ARP packets and ping
172.17.0.3 to observe an ARP request of the form
ARP, Request ....... 172.17.0.10 tell 172.17.0.3 .
The ……. is the password for Task 2!