Download CIT 485: Network Data Collection and more Schemes and Mind Maps Computer Networks in PDF only on Docsity!
CIT 485/585 Network Data Collection
The primary objective of this assignment is to understand how to collect and filter network packet data, as well as how to test packet capturing.
1 STUDENT LEARNING OUTCOMES
- Explain the advantages and disadvantages of network packet collection hardware, including hubs, port mirroring, and network taps.
- Collect network capture data with tcpdump.
- Filter packet captures using Berkeley Packet Filter (BPF) syntax.
- Generate test packets with ping and hping3.
2 INTRODUCTION
Based on readings of the textbook, be sure that you can answer the following questions.
- What is the difference between a hub and a switch?
- How can someone sniff a switched network?
- What is port mirroring?
- What is a network tap? Describe in words and draw a diagram.
3 TCPDUMP
While Wireshark is the most popular graphical network packet sniffer and packet analysis program, tcpdump is the most popular command line network sniffer and packet analysis tool. Analysts often need to collect data on platforms without a graphical interface, and the processing overhead of a graphical interface can cause packets to be lost on fast networks. Because of these factors, Wireshark itself comes with two com- mand line programs (tshark and dumpcap to collect packet data.
To capture packets with tcpdump today, we will use the following options.
- -i eth0 to specify which interface to sniff. Note that this interface will not always be eth0. Multi- interface systems like the Security Onion VM obviously have multiple interfaces to choose between, while recent Linux systems use a different naming system.
- -w file.pcap to specify which file to write captured packets.
- -n to not resolve hostnames, port names, etc. This improves performance, and we can always perform resolution later when viewing the PCAP file in tcpdump or Wireshark.
- -t to not provide timestamps, as we are not collecting data over significant time periods.
- -v is the verbose option to print a packet count, showing how many packets have been captured. Multiple -v options may be specified to provide additional output.
- -s 0 sets the snap length, which is the number of bytes to capture from a packet. The -s 0 options sets snap length to the maximum, which is the default on newer versions of tcpdump, but we will run tcpdump on older systems like Metasploitable and it does not cause any problems to specify the option on newer versions.
We will often specify a Berkeley Packet Filter (BPF) as the last argument to tcpdump to restrict which packets are captured. BPF filters are useful to avoid capturing irrelevant broadcast and multicast data or data from irrelevant protocols or to avoid capturing data destined for other machines when using a hub or mirroring of all ports to capture packets. The tcpdump tutorial in the references provides examples of BPF filters. There is also a link to the BPF documentation in the references.
When capturing packets, tcpdump will run forever. The user must use control-c to exit tcpdump.
On the Metasploitable VM, become root and start capturing ICMP packets. At the same time on the Kali VM, use the command ping -c 3 192.168.1.90 to send exactly 3 ICMP echo requests. Hit control-c after 6 packets are captured to stop the tcpdump command.
root@metasploitable:˜# tcpdump -ntv -s 0 -i eth0 -w ping.pcap icmp tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 6 packets captured 6 packets received by filter 0 packets dropped by kernel
To view high level data about the captured packets, with one line per packet, use tcpdump with the options below.
root@metasploitable:˜# tcpdump -n -r ping.pcap reading from file ping.pcap, link-type EN10MB (Ethernet) 12:49:48.330874 IP 192.168.1.10 > 192.168.1.90: ICMP echo request, id 24663, seq 1, length 64 12:49:48.330903 IP 192.168.1.90 > 192.168.1.10: ICMP echo reply, id 24663, seq 1, length 64 12:49:49.321230 IP 192.168.1.10 > 192.168.1.90: ICMP echo request, id 24663, seq 2, length 64 12:49:49.321250 IP 192.168.1.90 > 192.168.1.10: ICMP echo reply, id 24663, seq 2, length 64 12:49:50.335298 IP 192.168.1.10 > 192.168.1.90: ICMP echo request, id 24663, seq 3, length 64 12:49:50.335319 IP 192.168.1.90 > 192.168.1.10: ICMP echo reply, id 24663, seq 3, length 64
Discuss the following questions in class.
- Is the number of packets captured the number you expected? Why or why not?
- How could you use tcpdump to see the complete packet data?
- What data is included in Linux ICMP echo requests?
- -p 80 to specify the destination port.
- -S to send a TCP SYN packet.
On Metasploitable, start tcpdump with the filter port 80. Write packets to the file port80.pcap.
Use hping3 to check if port 80 is open. In this case, we should see that the response has flags=SA, indicating the SYN and ACK flags are set.
root@kali-nku-2018:˜# hping3 -c 1 -p 80 --syn 192.168.1. HPING 192.168.1.90 (eth0 192.168.1.90): S set, 40 headers + 0 data bytes len=46 ip=192.168.1.90 ttl=64 DF id=0 sport=80 flags=SA seq=0 win=5840 rtt=7. ms
--- 192.168.1.90 hping statistic --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 7.9/7.9/7.9 ms
Use hping3 to check if port 81 is open. In this case, we should see that the response has flags=RA, indicating the RST and ACK flags are set. The Reset (RST) flag in the TCP header indicates an error condition.
oot@kali-nku-2018:˜# hping3 -c 1 -p 81 --syn 192.168.1. HPING 192.168.1.90 (eth0 192.168.1.90): S set, 40 headers + 0 data bytes len=46 ip=192.168.1.90 ttl=64 DF id=0 sport=81 flags=RA seq=0 win=0 rtt=3.7 ms
--- 192.168.1.90 hping statistic --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 3.7/3.7/3.7 ms
Stop tcpdump. Read the port80.pcap file. Verify that the following statements are true.
- Only packets to or from port 80 are present.
- Three packets total are present. The first is a SYN packet to 192.168.1.90 and the second is a SYN- ACK packet from 192.168.1.90.
Why is the third a RST packet? What produces the RST packet?
4.2 UDP PACKETS
It is as easy to create UDP packets as TCP packets with hping3. We just need to add the --udp flag.
On the Metasploitable2 VM, start tcpdump with the filter port 80. Write packets to the file port80.pcap.
On the Kali VM, send a UDP packet to port 80 on the Metasploitable VM.
root@kali-nku-2018:˜# hping3 -c 1 -p 80 --udp 192.168.1. HPING 192.168.1.90 (eth0 192.168.1.90): udp mode set, 28 headers + 0 data bytes ICMP Port Unreachable from ip=192.168.1.90 name=UNKNOWN status=0 port=1938 seq=
--- 192.168.1.90 hping statistic --- 1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 10.0/10.0/10.0 ms
Stop tcpdump. Read the port80.pcap file. Verify that a single UDP packet was received on port 80 and that no other packets were sent or received.
4.3 FLOODING
The hping3 command can be used to launch denial of service attacks by sending packets as fast as possible with the flood option. This option can be used to test the ability of network monitoring infrastructure to keep up with busy networks. It can also be used to test the resilience of networks or servers to denial of service attacks.
On the Metasploitable2 VM, start tcpdump again with the filter port 80. Write packets to the file port80.pcap.
On the Kali VM, flood UDP packets to port 80 on the Metasploitable VM.
root@kali-nku-2018:˜# hping3 --flood --udp -p 80 192.168.1. HPING 192.168.1.90 (eth0 192.168.1.90): udp mode set, 28 headers + 0 data bytes hping in flood mode, no replies will be shown
In the time it takes to switch to the Metasploitable2 VM, tcpdump should be reporting many thousands of packets received. Hit control-c to stop tcpdump. It will produce output something like this, showing that packets were sent so quickly that the kernel could not keep up with sending the packets to tcpdump.
root@metasploitable:˜# tcpdump -ntv -s 0 -i eth0 -w port80.pcap port 80 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 311016 packets captured 370822 packets received by filter 59712 packets dropped by kernel
The dropped packets indicate that tcpdump cannot keep up if packets are sent with full network speed. The VMware virtual network is considerably faster than 1 Gbps Ethernet. If tcpdump cannot keep up, Wireshark certainly could not. The issue could be
- Disk. Typical hard drives can write between 100-200 MB/s, roughly equivalent to 1-2 Gbps network bandwidth. Since Ethernet is full duplex, a 1Gbps Ethernet port can carry up to 2 Gbps of network traffic, 1 Gbps transmitted + 1 Gbps received. Solid state disks (SSDs) are much faster.
- OS. Older operating system kernels and NIC drivers handle network packets using interrupts for each packet. This approach has difficulty keeping up with 1 Gbps or faster networks.
- CPU. Even if the OS is handling interrupts sensisbly, fast networks can still tax a CPUs ability to keep with packets.
Hit control-c on the Kali VM to stop the UDP flood.
