Wednesday, October 2, 2013

Detecting DDOS attack sources via ip source-track

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

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 only.

Now let’s check to see that traffic is heading for the victim

R1#show ip source-track
Address         SrcIF          Bytes   Pkts     Bytes/s     Pkts/s     Fa0/0             11M  7886       97140         65     Fa0/1            943K  9436         695          2

Let’s hit it after a few seconds again
R1#show ip source-track
Address         SrcIF          Bytes   Pkts     Bytes/s     Pkts/s     Fa0/0             17M    12K     101469         69     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 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        Null      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               100     5.4
Fa0/0         Null      01 00  10     902
0000 /0  0                     0800 /0  0              1400     9.0

From the output shown, there are two source IP addresses sending traffic to the victim, the first source is and the second is

The difference in packet sizes is 100 bytes from and 1400 bytes from You can also see that is sending almost 900 packets per second compared to 4 packets from

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