Monday, March 11, 2013

How to identify a DoS flood

 
In this post, we will talk about  DoS flooding and how to recognize that your being flooded. 

An associate of mine, recently came under a small udp flood, and needed analysis to help determine that he was indeed under a small under 250megs flood. Since many years ago and  in a former past life, I ‘ve been a crafter of tcp/udp/icmp floods, so I offered my experience on how to detect these floods.

With most flooding tools, they have one flaw that’ easily picked upon. No matter how much they try to randomize their src_address, the src_ports are almost never  randomized.

Even with icmp_floods, we have some tell-tale signs of the flooding that can't  be hidden.

In my example, I will use a very common tool  ( hping ) and will show you how you can quickly identify that your being flooded.

In ALL DoS and DDoS flooding attacks, the goal is for the attacker(s) to exhaust server/network resources. This could be via bandwidth consumption, or server tcp tcb exhaustation.  Attack at Layer3/4 are typically used by most attackers, and it’s common to  spoof the sources , or if conducting a some type of reflection, we spoof some other innocent bystander address(es).

In all of these attacks, the  SRC_PORT are rarely  random and will increase in a sequence range that’s consecutive and increasing by minimum of 1. This is the flaw that allows for one to identify that a flood is happening.

In my  example, we will use tshark and the –T –e options for fields

Here’s in this case  the attacker  conducted a udp flood  towards a dns server at 192.0.2.1 ;   hping –fast -2 –rand-source ­–p 53  192.0.2.1

In the above we sent a UDP flood targeting  192.0.2.1, &  with a dest_port == 53. So if one was to monitor traffic destination to  192.0.2.1 , we will find the  src_port are increasing consecutively, but with various random sources.

( output truncated )



 tshark -r file-udp.pcap  udp -T fields -e udp.srcport  -e ip.src

Running as user "root" and group "root". This could be dangerous.

1301    9.35.49.162

1302    45.181.159.172

1303    136.26.121.252

1304    57.13.211.54

1305    201.127.52.18

1306    54.77.144.164

1307    140.145.233.186

1308    252.150.97.164

1309    212.101.20.22

1310    186.80.49.107

1311    64.48.137.160


Now let’s look at the same  style attack, but now with a tcp syn_flood. Here’s the attacker tcp flood  a web server at 192.0.2.1,  and the cmd execution, using hping the flood would be executed as such ;  hping –fast -2 –rand-source ­–p 80 192.0.2.1

And now using tshark  and fields, we would find consecutive increasing src_ports again;

( output truncated )



tshark -r file_tcp.pcap  tcp -T fields -e tcp.srcport -e ip.src

Running as user "root" and group "root". This could be dangerous.

1595    205.167.39.167

1596    12.236.13.105

1597    253.137.231.137

1598    188.34.147.67

1599    169.51.152.239

1600    21.152.7.4

1601    133.152.135.163

1602    144.36.170.54

1603    216.99.236.9

1604    61.105.135.209

1605    202.99.240.95

1606    115.13.215.41

1607    116.162.32.81

1608    116.161.142.239

1609    54.216.81.81

1610    187.133.220.9

1611    65.39.33.3

1612    1.169.67.81

1613    128.7.34.34

1614    99.0.23.126

1615    224.162.208.116

1616    250.40.105.123

1617    227.174.7.94

1618    224.39.169.65

1619    171.99.21.2

1620    242.141.67.142

1621    141.83.22.10

1622    249.159.239.140

NOTE:
You notice how in both cases, the attack has random src_address,  but the port number where not? This is the flaw in ALL L4 floods where the sources_ports are not randomized. 

So using tshark/wireshark along with  cisco flow top talkers and/or your firewall sessions monitor, can provide insight on a potential tcp/udp flood.


Now let’s look at icmp, their’s no port # , but we have other clues that a flood is happening. Look here at this output;

[kfelix@attack01:~]> tcpdump -r file.pcap -n icmp

reading from file file.pcap, link-type EN10MB (Ethernet)

05:29:01.204184 IP 193.118.93.172 > 192.0.2.1: ICMP echo request, id 60417, seq 0, length 8

05:29:02.207244 IP 213.178.131.23 > 192.0.2.1: ICMP echo request, id 60417, seq 256, length 8

05:29:03.217264 IP 227.210.11.229 > 192.0.2.1: ICMP echo request, id 60417, seq 512, length 8

05:29:04.227294 IP 105.132.157.53 > 192.0.2.1: ICMP echo request, id 60417, seq 768, length 8

05:29:05.237301 IP 99.54.225.72 > 192.0.2.1: ICMP echo request, id 60417, seq 1024, length 8

05:29:06.247296 IP 36.118.223.171 > 192.0.2.1: ICMP echo request, id 60417, seq 1280, length 8

05:29:07.257303 IP 198.223.148.121 > 192.0.2.1: ICMP echo request, id 60417, seq 1536, length 8

05:29:08.267313 IP 253.35.224.74 > 192.0.2.1: ICMP echo request, id 60417, seq 1792, length 8

05:29:09.277343 IP 201.82.75.35 > 192.0.2.1: ICMP echo request, id 60417, seq 2048, length 8



or  by using  tshark we get the following;

[kfelix@attack01:~]> tshark -r file.pcap -V icmp -T fields -e icmp.ident -e ip.src

Running as user "root" and group "root". This could be dangerous.

0xec01 193.118.93.172

0xec01 213.178.131.23

0xec01 227.210.11.229

0xec01 105.132.157.53

0xec01 99.54.225.72

0xec01 36.118.223.171

0xec01 198.223.148.121

0xec01 253.35.224.74

0xec01 201.82.75.35


I hope this post has been helpful for identifying  flood attacks, &  in either realtime or for post forensics

Ken Felix
Freelance Network/Security Engineer
kfelix  a-t hyperfeed d-o-t com

No comments:

Post a Comment