Lab 2 - Using tcpdump to Sniff Network Traffic
From SOFTICE
|
Pedagogical Objectives
- Introduce the idea of packet sniffing
- Introduce the tcpdump application
- Analyze network traffic
- Strengthen student's networking knowledge, with an emphasis on OSI Model Layer 2
Developed by:
Synopsis
Packet sniffers are a valuable tool in the network administrator's arsenal. They can be used to view network traffic in a raw form, enabling a deeper understanding of underlying protocols, and proving a valuable troubleshooting too. The tcpdump application, one of the commonly used open source packet sniffers will be discussed and used in this lab.
[Briefing] tcpdump
Frequently in these lab exercises, you will find it necessary to observe physical packets in detail on the virtual networks you create using MLN. While there are several packages that will allow you to do this, a commonly used (and free) one is tcpdump.
tcpdump is also a favorite tool of hackers, as it allows them to observe packet content and addresses, gleaning information it would be difficult to obtain without a packet sniffer.
Like many Unix/Linux utilities that have a seemingly simple purpose, tcpdump has a huge number of options and capabilities, and a man page to match! This lab will start you off in the right direction, and may be added to as we discover tcpdump features you will need to accomplish the required work. Of course, you can always use the man page in Linux to see everything in glorious detail.
Don’t look for tcpdump's man page in your ordinary Linux account. tcpdump can only be run under Linux when you are logged in as root, and for good reason! Allowing non-privileged users to view each others' packets would be a security nightmare. You will have to start up an MLN network and login as root to to one of your virtual hosts to use tcpdump.
This is the “Basic Use” lab for tcpdump. Later labs will discuss the tcpdump application in more detail.
[Network Diagram] Tcpdump
The Tcpdump Network, pictured above, will be used in this lab's exercises.
[Solved] Intercepting ICMP and ARP
Complete the following solved exercises, recording your findings, and the procedures used to obtain them in your log. By doing this, you may be able to obtain partial credit if you are unable to complete any of the exercises.
Note: Before disconnecting from SOFTICE, be sure to shut your virtual hosts down. This procedure is described in Exercise 1-3: Shutdown the Network. This must be done in order to conserve system resources on the SOFTICE cluster.
- MAC (Media Access Control) Address - a 48-bit hardware address that's assigned to, and used to uniquely identify Ethernet network interfaces. MAC addresses are somewhat hierarchical, but not to the same extent as IP address. The first 24-bits in a MAC address identify the Ethernet interface's manufacturer. The remaining 24-bits are used to uniquely identify the specific device.
- TCP/IP (Transmission Control Protocol/Internet Protocol) - the suite of networking protocols that are used on TCP/IP networks, including the Internet
- IP Address - an 32-bit address that's assigned to, and used to uniquely identify a host on a TCP/IP network. IP addresses are organized hierarchically, like phone numbers according to the network's topology
- ARP (Address Resolution Protocol) a TCP/IP protocol that's used to translate IP addresses to hardware addresses, such as MAC addresses. When TCP/IP applications communicate, they have no concept of what type of physical network is being used. ARP provides a layer of abstraction which allows applications to be isolated from such details
- ICMP (Internet Control Message Protocol) - a TCP/IP protocol that's used to send control signals
In this example, we are going to use the tcpdump application to intercept ICMP and ARP traffic.
- Start up the Tcpdump Network:
mln start -p tcpdump
- Console into the observer host and execute the tcpdump command:
tcpdump
- Console into the client client, and use ping to verify connectivity between the client and server hosts:
ping -c 5 10.0.0.1
- Console back into the observer host, and take a look at tcpdump's output. Press Ctrl-C to exit tcpdump, then record this output in your log. tcpdump's output should look similar to the following (line numbers added for clarity):
1. observer:~# tcpdump 2. device eth0 entered promiscuous mode 3. tcpdump: verbose output suppressed, use -v or -vv for full protocol decode 4. listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 5. 03:47:01.136123 arp who-has 10.0.0.1 tell 10.0.0.2 6. 03:47:01.151472 arp reply 10.0.0.1 is-at fe:fd:00:00:5c:a4 7. 03:47:01.136180 IP 10.0.0.2 > 10.0.0.1: icmp 64: echo request seq 1 8. 03:47:01.136303 IP 10.0.0.1 > 10.0.0.2: icmp 64: echo reply seq 1 9. 03:47:02.132174 IP 10.0.0.2 > 10.0.0.1: icmp 64: echo request seq 2 10. 03:47:02.132190 IP 10.0.0.1 > 10.0.0.2: icmp 64: echo reply seq 2 11. 03:47:03.140125 IP 10.0.0.2 > 10.0.0.1: icmp 64: echo request seq 3 12. 03:47:03.140289 IP 10.0.0.1 > 10.0.0.2: icmp 64: echo reply seq 3 13. 03:47:04.148161 IP 10.0.0.2 > 10.0.0.1: icmp 64: echo request seq 4 14. 03:47:04.148334 IP 10.0.0.1 > 10.0.0.2: icmp 64: echo reply seq 4 15. 03:47:05.168356 IP 10.0.0.2 > 10.0.0.1: icmp 64: echo request seq 5 16. 013:47:05.168374 IP 10.0.0.1 > 10.0.0.2: icmp 64: echo reply seq 5 17. 03:47:06.148213 arp who-has 10.0.0.2 tell 10.0.0.1 18. 03:47:06.148289 arp reply 10.0.0.2 is-at fe:fd:00:00:15:4f 19. 14 packets captured 20. 14 packets received by filter 21. 0 packets dropped by kernel 22. device eth0 left promiscuous mode
- The above shows two protocols being intercepted by tcpdump - ICMP and ARP. Let's review some key lines:
2. device eth0 entered promiscuous mode
- Line 2 indicates that eth0, observer's Ethernet interface has entered "promiscuous mode". “Promiscuous mode” enables the card to receive and pass on to the host all packets observed on the network interface – not just those addressed to that host!
Solved 2-1: Intercepting ARP
- When tcpdump receives a PDU (Protocol Data Unit - a unit of information that travels over a network), it displays a line (or multiple lines) on your console. In this simplest form of running tcpdump (with no parameters), the displayed line is very simple. Line 5 is an example. At the left of each ARP line is the time in hours, minutes and decimal seconds:
5. 03:47:01.136123 arp who-has 10.0.0.1 tell 10.0.0.2
- Next, the protocol is identified - ARP in this case:
5. 03:47:01.136123 arp who-has 10.0.0.1 tell 10.0.0.2
- After the protocol is identified, that protocol's activity is described. For line 5, the host with the IP address 10.0.0.2 is requesting the MAC address of 10.0.0.1:
5. 03:47:01.136123 arp who-has 10.0.0.1 tell 10.0.0.2
- Line 6 shows the reply to line 5's query. 10.0.0.1's MAC address is fe:fd:00:00:5c:a4:
6. 03:47:01.151472 arp reply 10.0.0.1 is-at fe:fd:00:00:5c:a4
Solved 2-2: Intercepting IP
- The next PDU received by tcpdump is an IP PDU:
7. 03:47:01.136180 IP 10.0.0.2 > 10.0.0.1: icmp 64: echo request seq 1
- This IP PDU is being sent from 10.0.0.2 to 10.0.0.1:
7. 03:47:01.136180 IP 10.0.0.2 > 10.0.0.1: icmp 64: echo request seq 1
[Exercises]
Complete the following exercises, recording your findings, and the procedures used to obtain them in your log.
Note: Before disconnecting from SOFTICE, be sure to shut your virtual hosts down. This procedure is described in Exercise 1-3: Shutdown the Network. This must be done in order to conserve system resources on the SOFTICE cluster.
Exercise 2-1: Analyzing ARP
1. Use tcpdump to find the MAC addresses of the server, client and observer hosts.
Exercise 2-2: Traffic Sequence
1. Analyze the tcpdump output that you recorded in your log while conducting this lab's solved example. Was ARP or ICMP traffic passed first? What is the reason for this sequence?
Exercise 2-3: ARP Cache
1. Reboot each of your MLN hosts with the reboot command.
2. Start up tcpdump on the observer host.
3. Ping the server host from the client host. What ARP requests, if any take place?
4. Ping the observer host from the client host. What ARP requests, if any take place?
5. Ping the client host from the server host. What ARP requests, if any take place?
6. Describe how and why the ARP requests made in steps 2-5 differ. In what way, if any does the ARP cache play a role?
