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