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.
The examples that follow show how to detect some network attacks (internal and external) using just Tshark from the command line.
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
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!)
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
In this case, the attacker will try to fake
DHCPOFFER
orDHCPACK
answers to give the user spoofed data. If we know the IP of our DHCP server, we can create a filter that findsDHCPOFFER
orDHCPACK
answers that come from an IP different than the legitimate server. In the next example a malicious user executes theauxiliary/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 theauxiliary/server/fakedns
module to redirect users to malicious domains.First, we start running a filter to display
DHCPOFFER
andDHCPACK
responses from an IP different from our server. After getting twoDHCPACK
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.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
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
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
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)
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 asdns && 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)
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)
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.