You might have been DoS-ed recently. And you can’t spend more money on special and expensive DoS detection and mitigation systems. Well, you have routers, don’t you? Some routing platforms support features which can be efficiently used to limit the impact of DoS attacks.

Let us take a brief look into one of these features on the Juniper MX gear.

The trick relies on a simple assumption that most of the internet traffic is “green”, so to speak (TCP established sessions mostly), and minority is “red”. Red traffic is important but much less in volume, like TCP SYNs, TCP resets, UDP packets etc. We assume that DoS traffic is “red” in most cases – TCP SYN packets are often used as well as UDP packets with some random ports, port zero, MTU-sized, sometimes with no payload. ICMP is used in DoS attacks as well.

Whatever “green” and “red” traffic is, the principle is the same. First we separate the incoming traffic on the ingress router – “green” traffic is forwarded without interference, but “red” is classified into bins. The bin index is derived from some part of the destination IP address (this works for IPv4 only 😦 ), say from the last 10 bits – this will give us 2^10 = 1024 bins. For example, if 10 less significant bits are used for the bin index, than IP address 192.0.2.66 maps to the bin number 2*256 + 66 = 578. Each bin serves multiple flows which have the same common 10 bits in the destination address. Bin #578 also serves destinations 192.0.10.66, 192.0.18.66, 192.0.26.66 etc.

“Red” traffic in each of the bins is then policed. Committed rate for policers is set high enough not to impact the legitimate traffic, say 10-times the average.

dos-mitigation with prefix-action policing

Why bothering with bins? Can we just police all “red” traffic?

Well, no. If “red” is classified to bins, then, in case that policing takes action, only certain destinations are being affected. Namely, the ones that share common bits that make up the bin index. OK, there will be some “casualties of war” – traffic towards the destinations which share the same bin as the attacked one will be policed and some legitimate “red” packets will be dropped. But, if the number of bins is reasonably high compared with the number of all possible destinations, the probability to drop legitimate traffic can be acceptable.

These will be your tasks:

  • You have to classify “red” traffic.
  • Then measure in real network environment to find out what is normal rate for all the “red” types.
  • Configure classifiers and policers to protect your network.
  • Constantly monitor the operation of the policers. Repeat the process in case of unwanted behaviour, maybe due to bad classification, too aggressive policing etc.

First one is tricky and maybe not to be published publicly. Next one is obvious and an absolute must. You will find netflow tools very useful to accomplish your analysis. And the last one (monitoring) is the hardest, far off the scope of this post. Therefore, I will focus on configuration only, leaving other tasks open.

Let’s see, how this technique can be used with Junos OS (Cisco IOS has a very similar feature called Microflow policing or User-Based Rate Limiting – I might come to that later on).

First we define a prefix-specific action policer and the rate limiter. This one will be for all UDP packets. It will classify the UDP traffic to 1024 bins, each capable of carrying up to 50 Mb/s:

[edit firewall family inet]
prefix-action prefixActionUdp {
    policer FlowPolicerUdp;
    /* without "count" only policers are displayed with a "show firewall prefix-action-stats" command */
    count;
    filter-specific;
    /* 1024 policers */
    subnet-prefix-length 22;
    destination-prefix-length 32;
}
[edit firewall]
policer FlowPolicerUdp {
    if-exceeding {
        bandwidth-limit 50m;
        burst-size-limit 5m;
    }
    then discard;
}

We can now use this prefix-action policer within the firewall filter, for example:

[edit firewall family inet filter ProtectMePlease]
term PoliceUdp {
    from {
        destination-address {
            0.0.0.0/0;
        }
        destination-prefix-list {
            <some exceptions> except;
            <more exceptions> except;
        }
        protocol udp;
    }
    then {
        next term;
        prefix-action prefixActionUdp;
    }
}


You can check the status of each bin with a “show firewall prefix-action-stats” command. The command first displays all the counters (if “count” is configured), then all the policers. You can check for drops within every bin. However, the output might be huge if you run many policers, say 2^14 = 16.384.

Using the “show firewall prefix-action-stats” is non-trivial in some cases. The prefix-specific actions can be term-specific (which is the default) or filter-specific. And the firewall filter can be used in two flavours – interface-specific or not. These variations have impact on prefix-specific action policing and consequently the usage of the corresponding show commands.

To be continued…

Advertisements