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.
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:
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:
This would generate the following output:
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.
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:
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:
Remember that you can later merge several files into one .pcap
file using Mergecap (tool included in the default installation of Wireshark):
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:
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:
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.
This would generate the following output:
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:
This would generate the following output:
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.