One of
the nightmares for corporates and service providers are DOS and DDOS attacks. DOS (Denial
of Service) attacks are flooding UDP, TCP, reverse DNS or ICMP to a remote host
to utilize its processor or bandwidth to bring it down or make it unreachable. DDOS (Distributed Denial of
Service) has the same technique but from many different senders (sometimes
hundreds of thousands) either using Net-Bots or random PCs that are infected by a virus or a Trojan, waiting for the
attacker to control them and use them to send traffic to his target victim.
Sometimes DOS
attacks aren't recognized immediately since the attack bandwidth is distributed among multiple links and then aggregated at the core. The problem with DOS attacks is
that you can't just suddenly shutdown your internet links otherwise you just did
what the attacker wanted in the first place which is bring your
server/router/host down. This might be a web server, a database server or a
portal to your customers, of course this is not a good thing
Several
techniques has been developed in order to defend your network against DOS/DDOS,
but for them to be effective, first you need to identify who is attacking your
network and what is he attacking, even though the latter part is easy, the first
one is really the problem, because if it’s a web-server for example, you need
to differentiate the legitimate requests from the non-legitimate requests.
One way of detecting
DOS/DDOS attacks are using cisco’s built in ip source-track command.
Let’s
check the below topology
The
attacker is initiating a DOS attack through ISP1 and there are normal users
sending requests through ISP2
I’ll
simulate those requests by generating
traffic (ICMP messages) from both the attacker and normal users on the
internet. Now let’s imagine that suddenly the server admin is facing a problem
the server and you noticed that internet links towards ISP1 had a sudden rise
in the bandwidth. You can clearly suspect that a DOS or a DDOS attack is being
initiated towards your network.
The key
here is to detect the attack from a transient node that all the internet
traffic is passing through it. In our case here it’s R1, in other cases you
might have 2 redundant internet routers to check the attack from.
Now let’s
configure R1 to monitor transient traffic going to the victim.
R1 (config)#ip source-track 192.168.1.1
Notice that this
command is put on a transient node since the router discretely
enables Netflow on all R1 interfaces and monitors all transient traffic going to
192.168.1.1 only.
Now let’s check to
see that traffic is heading for the victim
R1#show ip source-track 192.168.1.1
Address SrcIF Bytes Pkts
Bytes/s Pkts/s
192.168.1.1 Fa0/0 11M
7886 97140 65
192.168.1.1 Fa0/1 943K 9436
695 2
Let’s hit
it after a few seconds again
R1#show ip source-track 192.168.1.1
Address SrcIF Bytes Pkts
Bytes/s Pkts/s
192.168.1.1 Fa0/0 17M 12K
101469 69
192.168.1.1 Fa0/1 948K 9481
352 0
As shown
above. The difference is huge in traffic between traffic entering to R1 F0/0
interface and F0/1 interface
Now let’s
look at the cache in the Netflow to see the details of traffic of both
interfaces
R1#show ip source-track 192.168.1.1
cache
IP packet size distribution (42060 total
packets):
1-32 64 96
128 160 192
224 256 288
320 352 384
416 448 480
.000 .000 .000 .227 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000
.000
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.000 .000 .000 .000 .772 .000 .000 .000 .000 .000 .000
IP Flow Switching Cache, 278544 bytes
2 active, 4094 inactive, 66 added
1033 ager polls, 0 flow alloc failures
Active flows timeout in 0 minutes
Inactive flows timeout in 15 seconds
IP Sub Flow Cache, 25280 bytes
0 active, 1024 inactive, 0 added, 0 added to flow
0 alloc failures, 0 force free
1 chunk, 1 chunk added
last clearing of statistics never
Protocol Total Flows
Packets Bytes Packets Active(Sec)
Idle(Sec)
-------- Flows /Sec
/Flow /Pkt /Sec
/Flow /Flow
SrcIf SrcIPaddress DstIf
DstIPaddress Pr TOS Flgs
Pkts
Port Msk AS Port Msk AS NextHop B/Pk Active
Fa0/1 40.0.0.1 Null 192.168.1.1 01 00
10 4
SrcIf SrcIPaddress DstIf
DstIPaddress Pr TOS Flgs
Pkts
Port Msk AS Port Msk AS NextHop B/Pk Active
0000 /0
0 0800 /0 0
0.0.0.0 100 5.4
Fa0/0 3.3.3.3 Null 192.168.1.1 01 00
10 902
0000 /0
0 0800 /0 0
0.0.0.0 1400 9.0
From the output shown, there are two source IP addresses sending
traffic to the victim, the first source is 40.0.0.1 and the second is 30.0.0.1
The difference in packet sizes is 100 bytes from 40.0.0.1 and 1400
bytes from 30.0.0.1. You can also see that 30.0.0.1 is sending almost 900
packets per second compared to 4 packets from 40.0.0.1.
Now we can see the devastating effect of the attack on the normal
user experience. The pings from the normal users are starting to timeout since
DOS traffic is eating all the queues with its big packets and huge bandwidth. In
the real world, DDOS attack has reached a phenomenal 300 Gb\s traffic bandwidth,
which for sure can congest the majority of service providers links even the big
ones. You can read more about this specific attack here.
(ping output from normal user)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!..!!..!!!.!.!..!!.!.!!!!!.!!.!.!!!!!...!!...!!!!..!!!.!!.!!.!!.....!!.!!!!..!!!...!.!!!.!!!.!!!!!!.!!.!..!....!!!!..!!.!!!!!!!!!.!...!.!.!!....!!..!!!.!.!!....!!..!!......!!..!.!!.!!!!!!!!.!!.!..!.!....!!.!..!!...!..!.!!!..!!!..!!.!...!.!!!!.!..!.!!!.!.!.!!.!.!.!..!.!!..!!.!...!!!!.!.!!!.!.!.!!.!.!.!..!.!.!!!!.!!..!!!!.!...!!!!!..!....!.!!!!!!.!.!.!!!!!.!!!!!.!..!!!!.!..!!.!..!!!.!!.!.!...
Even though this simple command won’t do you very much
in case of a 300 Gb attack, but for sure it will tell you about the small or
medium ones that happen on weekly basis.
No comments:
Post a Comment