Book Image

Instant Traffic Analysis with Tshark How-to

By : Borja Merino
Book Image

Instant Traffic Analysis with Tshark How-to

By: Borja Merino

Overview of this book

Malware, DoS attacks, SQLi, and data exfiltration are some of the problems that many security officers have to face every day. Having advanced knowledge in communications and protocol analysis is therefore essential to investigate and detect any of these attacks. Tshark is the ideal tool for professionals who wish to meet these needs, or students who want to delve into the world of networking.Instant Traffic Analysis with Tshark How-to is a practical, hands-on guide for network administrators and security officers who want to take advantage of the filtering features provided by Tshark, the command-line version of Wireshark. With this guide you will learn how to get the most out of Tshark from environments lacking GUI, ideal for example in Unix/Linux servers, offering you much flexibility to identify and display network traffic.The book begins by explaining the basic theoretical concepts of Tshark and the process of data collection. Subsequently, you will see several alternatives to capture traffic based on network infrastructure and the goals of the network administrator. The rest of the book will focus on explaining the most interesting parameters of the tool from a totally practical standpoint.You will also learn how to decode protocols and how to get evidence of suspicious network traffic. You will become familiar with the many practical filters of Tshark that identify malware-infected computers and lots of network attacks such as DoS attacks, DHCP/ARP spoof, and DNS flooding. Finally, you will see some tricks to automate certain tasks with Tshark and python scripts.You will learn everything you need to get the most out of Tshark and overcome a wide range of network problems. In addition you will learn a variety of concepts related to networking and network attacks currently exploited.
Table of Contents (7 chapters)

Auditing network attacks (Become an expert)


In this recipe you will learn how to identify well-known network attacks. Some of these attacks can have serious consequences in environments that do not implement appropriate countermeasures. We'll see how, with some skill with Tshark and by applying the correct filters, we can detect most of these attacks.

How to do it...

The examples that follow show how to detect some network attacks (internal and external) using just Tshark from the command line.

ARP spoofing

  1. If you suspect that someone is playing with ARP traffic, it would be advisable to run Tshark in SPAN or HUB mode (see the Capturing traffic (Must know) recipe). Subsequently, a good start would be to look at the rate of ARP reply packets:

    bmerino@Mordor:~$ tshark -i wlan1 -R "arp.opcode == 2" -T fields -e frame.time_delta -e eth.src -e eth.dst 
    

    This would generate the following output:

    Capturing on wlan1  
    0.000036000 00:13:e8:f6:26:ef 08:00:27:21:f9:85
    0.000490000 08:00:27:21:f9:85 00:13:e8:f6:26:ef
    0.564671000 08:00:27:21:f9:85 00:13:e8:f6:26:ef
    bmerino@Mordor:~$ arp -an | grep ef
    ? (192.168.1.131) en 08:00:27:21:f9:85 [ether] en wlan1
    
  2. In this case we see that the ARP reply rate is quite high. Note that the time is in delta format, which indicates the time since the previous packet was captured. Another alternative is to look for duplicate ARP packets, a fairly common symptom in ARP attacks:

    bmerino@Mordor:~$ tshark -i wlan1 -R arp.duplicate-address-detected -o column.format:"Info","%i"
    

    This would generate the following output:

    Capturing on wlan1
    Who has 192.168.1.42?  Tell 192.168.1.131 (duplicate use of 192.168.1.131 detected!)
    
  3. Apart from the preceding filters, take a look at the following example. Since most of the time attackers who do ARP spoof attacks try to fake the MAC of the gateway, we can look for ARP packets that have set the "Sender IP" with the gateway IP (ARP filed), but whose frames have a source MAC different from the gateway. We can use this trick not just for ARP but for other LAN attacks such as DHCP spoofing

DHCP spoofing

  1. In this case, the attacker will try to fake DHCPOFFER or DHCPACK answers to give the user spoofed data. If we know the IP of our DHCP server, we can create a filter that finds DHCPOFFER or DHCPACK answers that come from an IP different than the legitimate server. In the next example a malicious user executes the auxiliary/server/dhcp module (192.168.1.42) from Metasploit to provide false information to any host that uses DHCP. Within this information, each host will receive a fake DNS server (192.168.1.99) also under the attacker's control. In that machine the attacker will have running the auxiliary/server/fakedns module to redirect users to malicious domains.

  2. First, we start running a filter to display DHCPOFFER and DHCPACK responses from an IP different from our server. After getting two DHCPACK packets we confirm that a malicious user has installed a fake DHCP server. Then, we capture some packets in more detail to see the Domain Name Server sent by the server and get, this way, the IP of the fake DNS server.

  3. In a similar way, if we observe many DHCP discovery packets in a short time, it's very likely that someone is trying to do DHCP exhaustion attacks to exhaust the address space of the DHCP server. To check this, we can filter the packets with a source MAC address different from the Client Hardware Address (CHADDR) field inside the DHCP payload.

    bmerino@Mordor:/tmp# tshark -i eth0 -T fields -e frame.time_delta -e eth.src -e bootp.hw.mac_addr -R "bootp.option.dhcp == 1 && (eth.src != bootp.hw.mac_addr)"
    

    This would generate the following output:

    Capturing on eth0
    0.074655000 aa:00:04:00:0a:04 00:16:36:53:e8:c3
    0.632385000 aa:00:04:00:0a:04 00:16:36:53:e8:c3
    0.000138000 aa:00:04:00:0a:04 00:16:36:53:e8:c3
    

DoS attacks

  1. In recent years attacks known as DNS amplification have increased vertiginously. Such attacks are mainly characterized by two concepts: reflection and amplification. The idea is to send DNS requests to open resolvers using a spoofed IP (reflection). This DNS request is made up of a few bytes but the response generated and sent by the open resolver will be much bigger. Such attacks are in practice very similar to the old SMURF attacks. Let's see the following output:

    bmerino@Mordor:~$ dig ANY ************.es  @156.154.71.1 +edns=0 | grep SIZE
    ;; MSG SIZE  rcvd: 3331
    

    Let's see now this traffic from Tshark:

    bmerino@Mordor:~$  tshark -r dns.pcap -R "ip.addr==156.154.71.1" -T  fields -e frame.number -e ip.src -e ip.dst -e frame.len -e ip.flags.mf
    36 192.168.1.200     156.154.71.1    78 0
    38 156.154.71.1         192.168.1.200  418 1
    39 156.154.71.1         192.168.1.200 1514 1
    40 156.154.71.1         192.168.1.200 1509 0
    
  2. As noted, a single DNS request of 78 bytes to a 156.154.71.1 (open resolver) has produced a response of more than 3300 bytes. Because of its excessive size, this response has been fragmented into three packets and sent to the victim (notice the "More Fragment" bit in the last column). Also note the parameter +edns (extension mechanisms for DNS), thanks to which we will get a UDP response. Otherwise the response would be truncated to TCP due to its excessive size. Since it is not common to find fragmented DNS responses, we can run the following command to quickly identify such attacks:

    bmerino@Mordor:~$  tshark -i eth0 -R "dns &&  ip.fragment" -T  fields -e frame.number -e ip.src -e ip.dst 
    

    This would generate the following output:

    Capturing on eth0
    9 156.154.71.1 192.168.1.200
    
  3. You can also use the ip.flags.mf filter to show the fragments that make up that packet with the "More Fragment" bit activated:

    bmerino@Mordor:~$ tshark -i eth0 -R "ip.flags.mf == 1"
    

    This would generate the following output:

    Capturing on eth0
      1.340579 156.154.71.1 -> 192.168.1.200 IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=30e8)
      1.340812 156.154.71.1 -> 192.168.1.200 IP Fragmented IP protocol (proto=UDP 0x11, off=296, ID=30e8)
    
  4. Or directly by using a capture filter (you can type man pcap filter to see the packet filter syntax from the command line). Note, however, that a filter such as dns && ip.flags.mf == 1 will not work. The main reason is because Wireshark and Tshark reassemble all fragmented IP datagrams into a full IP packet before calling the dissector in the higher layer. Therefore, Tshark will not recognize those packets as DNS until they are received and reassembled. Take a look at the Wireshark documentation to understand this in more detail (http://www.wireshark.org/docs/wsdg_html_chunked/ChDissectReassemble.html).

    bmerino@Mordor:~$  tshark -i eth0 -f 'ip[6] = 32'
    

    This would generate the following output:

    Capturing on eth0
      0.000000 156.154.71.1 -> 192.168.1.200 IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=30ec)
    

How it works...

Suppose that, as on any other day, you open the browser to view your email. But this time, after typing www.gmail.com in the navigation bar, you run into an error as shown in the following screenshot:

What? My browser does not trust Google? If you come across this, you can be sure that someone is doing a man-in-the-middle attack, either playing around with ARP, DNS, or both (see Ettercap + dns_spoof plugin). To check this, we will take a look in our ARP cache to see if someone is trying to fake our gateway (a ZyXEL router). This way if the cached MAC of the IP 192.168.1.1 (our gateway) doesn't match the MAC of the router, we can confirm the attack.

According to the preceding output we can see how the cached MAC corresponds to a Sun xVM VirtualBox. The attacker did not even bother to change the first three bytes of the MAC to emulate a ZyXEL router. If we use arping to send an ARP request to our gateway we can see the real MAC address. Also, if we try to resolve mail.google.com we can confirm that the attacker is also faking DNS responses. As we see, the IP of the machine 192.168.1.131 corresponds to the MAC that is trying to fake the router, so we can be sure that that IP belongs to the attacker:

bmerino@Mordor:~$ ping mail.google.com –t 1
PING mail.google.com (192.168.1.131) 56(84) bytes of data.
bmerino@Mordor:~$ arp -an | grep 131
? (192.168.1.131) en 08:00:27:21:f9:85 [ether] en wlan1

Note that, in this case, we could detect this attack because it was directed to our machine. If the victim was another host, it is likely that we would not even notice this attack. An ARP spoof can be used to attack all hosts within the broadcast domain of the current VLAN or specific hosts. Use the filters described before in the ARP spoofing section in the Auditing network attacks recipe to detect such attacks. Likewise, to understand in greater detail DHCP attacks and their countermeasures, take a look at http://www.securityartwork.es/2013/01/30/defenses-against-dhcp-attacks/?lang=en.

If you experience problems with your network, such as hosts that disconnect, packet loss, duplicate IP, and so on, consider using Tshark to analyze such protocols. Tools such as Loki, dhcpstarv, Yersinia, macof, and a few more, can give you huge headaches in an environment that lacks countermeasures such as Dynamic ARP Inspector (DAI), IP Source Guard, DHCP Snooping, Port Security, and so on. A good approach is to start analyzing protocols of lower layers to upper layers. "Analyze" means to observe the frequency, size, or any other conditions that make us suspicious.

Tshark is equally useful when it comes to quickly identifying DDoS attacks. The following example shows a typical SYN flood against our HTTP server:

bmerino@Mordor:~$ tshark -i eth0 -T fields -e frame.time_delta -e ip.geoip.src_country -e ip.src  -R "tcp.flags.syn==1 && tcp.flags.ack==0 && tcp.dstport==80 && ip.dst==192.168.1.42"

This would generate the following output:

Capturing on eth0
0.036926000     Brazil       177.158.236.156
0.000397000     South Africa     41.21.184.75
0.000145000     China       110.121.38.23
0.000133000     Ireland      212.147.206.156

Although such attacks immediately jump out at you due to the high number of packets with the SYN bit set, the preceding example shows more clearly the operation of such a flood. Thousands of packets are sent from spoofed IPs with the SYN bit. This means that our server has to wait for each connection a given time (until the TCP three-way handshake is complete), during which more packets keep coming. A very large number of packets may end the resources of the server, so it stops responding to more connections. Notice that we have used the GeoIP databases from http://www.maxmind.com. To setup GeoIP with Tshark/Wireshark take a look at http://wiki.wireshark.org/HowToUseGeoIP.

bmerino@Mordor:~$ tshark -v | grep -i geo
Python, with GnuTLS 2.12.14, with Gcrypt 1.5.0, with MIT Kerberos, with GeoIP
bmerino@Mordor:~$ tshark -G defaultprefs | grep use_geo
#ip.use_geoip: TRUE

GeoIP can be very useful not only in such attacks but for any incident related to geolocation. For example, suppose you have configured a GRE tunnel (Generic Route Encapsulation) on your border router. According to the company's policy, only the branches located in Spain can use this VPN. To check for any illegitimate connections we can run Tshark as follows:

bmerino@Mordor:~$ tshark -r greTunnel.pcap -T fields -e ip.geoip.src_country -e ip.src -R "not ip.geoip.src_country contains Spain"
United States *.*.*,*

Note that SYN flood attacks generally require the cooperation of thousands of hosts to succeed. However, the techniques in denial of service attacks have evolved enough in the last years to just need a few hosts to knock down a web service. Take a look at tools such as SlowLoris, Hulk, or THC, which allow you to do a denial of service from the application layer. In these cases we probably need a deeper analysis (HTTP headers, SSL traffic, and so on) to understand the attack technically. Consider using some of the filters seen previously to identify other kind of attacks such as IP fragmentation attacks. This type of attack is used to circumvent countermeasures such as firewalls or IDS by sending many small fragments. Use the ip.fragment and ip.flags.mf filters to observe this kind of packets.

Also take a look at countermeasures such as TCP-Intercept, DNS Inspection, Frag Guard, Flood Guard, Unicast Reverse Path Forwarding, and so on, implemented in some Cisco devices. The deployment of these technologies will be really efficient to mitigate or greatly reduce most of the attacks seen so far.

In the example of DHCP attacks we used the -a option to indicate the number of seconds to capture. This is a really interesting option of Tshark since it allows us to specify an autostop condition, thanks to which we will not have to be present to manually stop a capture. We can specify up to three criteria as a stop condition of the form test:value where test is one of duration (seconds), filesize (kilobytes), or files. In a similar way, we can use the –b option if we want to run Tshark in "multiple files" mode. In this mode TShark will write to several capture files. When the first capture file fills up, TShark will switch writing to the next file and so on (take a look at the http://www.wireshark.org/docs/man-pages/tshark.html to get more information about this option). So, if we want to capture traffic and generate files of 1000 KB in length, we would execute something as follows:

bmerino@Mordor:~$ tshark -i eth0 -b filesize:1000 -w A.pcap
Capturing on eth0
2049
bmerino@Mordor:~$ ls A_*
A_00001_20130203154505.pcap  A_00002_20130203154529.pcap

Remember that you can later merge several files into one .pcap file using Mergecap (tool included in the default installation of Wireshark):

bmerino@Mordor:~$ mergecap A_00001_20130203154505.pcap 
A_00002_20130203154529.pcap -w output.pcap –a
bmerino@Mordor:~$ ls -lh output.pcap 
-rw-r--r-- 1 bmerino bmerino 2,0M feb  3 15:51 output.pcap

One advantage of the -b option is the ability to set up a ring buffer. This is a good way to prevent filling the entire hard disk with many pcap files. We do this with the files parameter. So, for example, if we want to rotate a log file every 1000 seconds and maintain a maximum number of 10 files, you would execute:

bmerino@Mordor:~$ tshark -i wlan1 -b duration:1000 -b files:10 -w test.pcap
Capturing on wlan1
3282 ^C
bmerino@Mordor:~$ ls -l test*
test_00001_20130203155318.pcap  test_00002_20130203155418.pcap

Finally, note that Tshark supports different data link types. You can use the –L option to show the types supported by your interface and the –y option to set the one you are interested in. If this option is not set, the default capture link will be used:

bmerino@Mordor:~$ tshark -L -i wlan1
Data link types of interface wlan1 when not in monitor mode   (use option -y to set):
  EN10MB (Ethernet)
  DOCSIS (DOCSIS)

There's more...

The following example shows another case of DDoS attack, this time a more unusual attack that affects the VRRP protocol. Thanks to Tshark we could find out the source of such an attack.

Our network has several Cisco routers configured with Virtual Router Redundancy Protocol (VRRP). This protocol, similar to HSRP, allows you to group a set of routers under a single Virtual IP/MAC so that the group is fully transparent to the client configuration. In this group, just one of the routers (the master virtual router) will be responsible for routing packets to their destination while the rest will monitor the status of the master. In case the master fails, it will be replaced by one backup router which has the highest priority. However, in the last hour the network users complain that they have had troubles connecting to the Internet; oddly, there are several redundant routers.

To investigate this incident, we began monitoring VRRP traffic.

bmerino@Mordor:~$ tshark -i eth0 -R vrrp 

This would generate the following output:

Capturing on eth0  
  0.000049  192.168.1.5 -> 224.0.0.18   VRRP 60 Announcement (v2)
  0.534392  192.168.1.5 -> 224.0.0.18   VRRP 60 Announcement (v2)
  0.534437  192.168.1.5 -> 224.0.0.18   VRRP 60 Announcement (v2)

We noticed that the frequency of these packets was higher than normal. This made us think that someone was trying to make a man-in-the-middle by faking a VRRP router using a higher priority than the master (its current priority was 150); so, we decided to filter out just the priority of those packets:

bmerino@Mordor:~$ tshark -i eth0 -R vrrp -T fields -e vrrp.prio

This would generate the following output:

Capturing on eth0
0

This was even weirder. Someone was forging VRRP packets with a priority of 0. But, why? After checking the VRRP v2 RFC we found the following:

The value of 0 (zero) is reserved for Master router to indicate it is releasing responsibility for the virtual router. The range 1-254 (decimal) is available for VRRP routers backing up the virtual router. The default value is 100 (decimal).

Now it makes sense, someone was doing a denial of service by sending forged packets usurping the VRRP master router but with a priority of 0. This forced the master to release its responsibility and generate new renegotiations with the backups. Let's see this more clearly. The following screenshot corresponds to part of the output generated by the command bmerino@Mordor:~$ tshark -i eth0 -R vrrp -S --------- -V:

To prevent such attacks with VRRP, consider using MD5 authentication and limit multicast traffic only to VRRP routers participating in the negotiation of the virtual router.