Optimising Traffic Capacity In an Age of Terabit DDoS Attacks

Optimising Traffic Capacity In an Age of Terabit DDoS Attacks [1].

The exponential growth in both hardware and software marvelling engineering crafts has opened new opportunities for both consumer and enterprise industry. On the cross roads of offered services and demand, it is crucial for business to focus in an entirely new way to look for the business risk mitigations. The rise of internet technology and related threats since its inception has was not same as in last few years. Just to quote an example, as per Arbor NETSCOUT [2], there are not less than 55% of global world population on Internet and they have on an average 5.5 devices per person. This is not only an exponential proliferation but an exponential growth in process as we talk.

Screen Shot 2019-03-15 at 10.39.54 am

With this growth, projection and future trend, it is not that surprising to see some of the grave risks to business in terms of DDoS attacks. DDoS attack happens with a variety of reasons and in this article we are not talking the details, however the inference we take from this observation [2] is that business need to invest more in being proactive for such situations.

Screen Shot 2019-03-15 at 10.42.41 am

The classical information security policy which governs on how much to invest on security requirements need to be more pervasive to these reports, so that the overall defence strategy remains in good stead. In general, security investment is always a passive expenditure and a day to day return is never expected. Moreover, in a situation like these reports, where we do not have a quantifiable past data against a company’s infrastructure it is very hard to do a forecast analysis and come up with the best strategy to invest in “what” and “where”.

The smart way of next generation security investment should address “what value investment” we get off the solution/product we deploy as a countermeasure and still not using it for the scoped purpose (standby usage). To my experience, in case of Arbor I see Arbor SP’s very important role in analytics. Even if we deploy Arbor SP platform (as an example) for network attack detection, we can use the tool to understand different network sources, types and patterns which will eventually act as a critical piece of information in capacity planning of various Transit, BLPA, MLPA and PNI exit points.

Of course these consideration require a singularity of management understanding over technical sensitivity to business. Its imperative that, in today’s pace of industrial changes we start thinking not only in terms of one specific domain but to go for a multi-abstract solution which is relevant not only for security but serves a broader purpose of “an intelligence feed” for overall traffic management.

People who come from a traditional 3-tier architecture and the technologies behind perimeter security and embedded end point security understand how the hybrid approach is used in our classical strategy of enterprise security needs. Generally we used to have firewalls, IDS and end point agents detecting anomalies and taking actions. These measures do have some limited intrinsic capabilities to offer first layer of defence, however when we have an attack which is,

  1. Either not detected using classical perimeter security, or
  2. The volume of such attack is beyond the capacity of provisioned infrastructure

We can not bank on them to get a solution. So, when it comes to the broader question of optimising traffic capacity against forecasted trend of global DDoS attack, we need to understand that,

  1. There is no perfect model
  2. There is no direct correlation to DDoS attack size and growth
  3. There is no single DDoS mitigation plan to protect your core network, and
  4. A hybrid approach is best to optimise the budget, security needs and mitigation.

In DDoS world the way a countermeasure works, or more specifically the type of countermeasure chosen is a function of the type of attack. This necessitates the need of a hybrid model. It is very difficult and quite impossible to freeze an industry best perfect model as we know that (from the history) the attack landscape is changing each day. In Industry as of today, for any enterprise  (or any large network) network a DDoS counter measure can be achieved in one of the three ways, or can be combined in case of multi vector attacks.

  1. Remote Scrubbing
  2. ISP Mitigation
  3. On-Premise mitigation

Remote Scrubbing is well suited in a situation where we have DDoS attack targeting a customer’s network with a very high volume, which the network itself is not having a capacity to handle. In these situations, an on demand cloud scrubbing can be initiated with Cloud Scrubbing Service Provider (CSSP) like F5 Silverline or Arbor. This work on the basis of BGP prefix advertisements. The prefix to be scrubbed (the attacked network) is advertised by CSSP and the cleaned traffic is handed over to the customer. This method adds a bit of latency post in post scrubbed traffic, but is tolerated compared to the loss of service. The other method was to do a RTBH where we make the service completely black-holed.

ISP mitigation, is to tell the ISP themselves to do a RTBH. This is well suited in case of a volumetric attack where we know the rogue source. These are the attacks that use massive amount of traffic saturating the bandwidth of the target. Volumetric attacks are easy to generate by employing simple amplification techniques. Example, NTP Amplification, DNS Amplification, UDP Flood, TCP Flood. This is much cheaper than CSSP (even free) as this do not require any service provisioning which is required in case of CSSP. ISPs provide specific BGP community which we can use in advertising the subnet we want to blackhole and ISPs, once they receive the community start doing the blackhole. According to Arbor Networks, 65% of DDoS attacks are volumetric in nature [3]. A organisation can also make use of FlowSpec capabilities to make traffic discard process more specific.

On-Premise mitigation (referred as OTP i.e. On-Premise Threat Protection) is to add TMS (Threat Management System) appliance in the network itself and doing an in-house scrubbing. In practice, OTP functions exactly the same way as CSSP works. In fact, if you look into the cloud console of any CSSP like F5 Silverline or Arbor, you will see the same console you get for OTP. So, if you have same vendor for both CSSP and OTP, you will have more singular experience. Deploying OTP require a careful examination of existing network, the sections which are vulnerable and routing decisions to make in diverting and re-injecting the attack (dirty) and legitimate (clean) traffic. There are various method to achieve this objective and it depends on the type of network and security objective scope on how to deploy it. As an example following is the complete Arbor stack for all three options.

Screen Shot 2019-03-15 at 11.14.01 am

It is important to note that as we discussed earlier about the standby usage of the solution, in case of OTP, we do have analytical capabilities in doing on demand packet captures using TMS appliances in understanding the traffic details (if required).

So, although it is always good to have all the solution in place if budget allows, an enterprise may chose one of them or all. There are other considerations as well like which vendor to chose and how to operationalise DDoS mitigation practice in enterprise as a business as usual process, which are as crucial as the solution itself. In all the cases, it is very crucial that we take in consideration what is happening globally in the internet cloud and how the future of security defence in evolving in making a network immune to risks.

References:  

[1] This article is an outcome of the webinar session by JP Blaho, Product Marketing on Brightalk.

[2] http://public2.brighttalk.com/resource/core/221711/capacity-managementwebinar21219_483572.pdf

[3] [https://www.arbornetworks.com/images/documents/WISR2016_EN_Web.pdf]

[4] Image: https://www.pinterest.com.au/pin/836895543232227709/

 

BGP Flowspec Configuration for Juniper MX

Reference to the last article for more reference is here. In this example we assume that the Arbor SP Collector Appliance is 10.100.200.10 and the specific Juniper device is 10.1.2.3 with a configured community 1234:5678 for RTBH purposes.

Step1: Create a FlowSpec policy allowing Arbor SP Collector IP Address

set policy-options policy-statement ARBOR_FS_POLICY from neighbor 10.100.200.10
set policy-options policy-statement ARBOR_FS_POLICY then accept

Step2: Create a FlowSpec policy allowing specific community advertisement for RTBH

set policy-options community ARBOR_ALLOWED_COMMUNITY members target:1234:5678
set policy-options policy-statement ARBOR_IMPORT_POLICY term BGP from community ARBOR_ALLOWED_COMMUNITY

Step3: Configure the routes you want to send to Arbor SP for analytics purposes.

set policy-options policy-statement ROUTES-TO-ARBOR term DIRECT from protocol direct
set policy-options policy-statement ROUTES-TO-ARBOR term DIRECT then accept
set policy-options policy-statement ROUTES-TO-ARBOR term OSPF from protocol ospf
set policy-options policy-statement ROUTES-TO-ARBOR term OSPF then accept
set policy-options policy-statement ROUTES-TO-ARBOR term BGP from protocol bgp
set policy-options policy-statement ROUTES-TO-ARBOR term BGP then accept

Step4: Configure the bgp neighbor group

set routing-instances Internet protocols bgp group ARBOR-BGP type internal
set routing-instances Internet protocols bgp group ARBOR-BGP local-address 10.1.2.3
set routing-instances Internet protocols bgp group ARBOR-BGP import ARBOR_IMPORT_POLICY
set routing-instances Internet protocols bgp group ARBOR-BGP family inet unicast
set routing-instances Internet protocols bgp group ARBOR-BGP family inet flow no-validate ARBOR_FS_POLICY
set routing-instances Internet protocols bgp group ARBOR-BGP export ROUTES-TO-ARBOR

Step5: Configure BGP Neighbor.

set routing-instances Internet protocols bgp group ARBOR-BGP neighbor 10.100.200.10 description Arbor_BGP
set routing-instances Internet protocols bgp group ARBOR-BGP neighbor 10.100.200.10 family inet unicast
set routing-instances Internet protocols bgp group ARBOR-BGP neighbor 10.100.200.10 family inet flow

Verification:

show route table Internet.inetflow.0 detail

show firewall filter __flowspec_Internet_inet__ detail logical-system all
show route receive-protocol bgp 10.100.200.10 table Internet

 

 

 

BGP Flowspec Configuration for ASRs

Recently i worked on BGP Flowspec based attack mitigation using Arbor SP. This post will delineate the key findings and configuration experience to help others in doing a similar deployment.

Arbor SP [1] is the Visibility and Attack Detection Engine, which runs on a hypervisor layer such as Cisco UCS. The job of Arbor SP is to collect NetFlow, SNMP and BGP data from the various core/ edge routers in the network and analyse the statistics. Traffic patterns are observed and compared against historical data and known attack signatures within Arbor SP’s profiling database, it is worth mentioning at this point that subscription to Arbor’s analytics service is required in order to maintain an up to date database of threat signatures, similar to any AV/AMP service.

When Arbor SP detects an unusual pattern of traffic it will raise alerts to the specified operators or can be configured to automatically intervene to mitigate the threat utilising BGP FlowSpec, in which case it will send ACL updates to the specific routers, and /or redirect illegitimate traffic to the Arbor TMS blade on the ASR9k in order to be scrubbed.

Flowspec mitigation is for the targeted attack. This type of attack is not bandwidth sensitive in general, but specific to some port, protocol or IP Address. The attacks in the scope of flowspec mitigation are:

  1. Protocol Attacks
  2. Application Attacks

Protocol attacks are the attacks that render a target in-accessible by exploiting a weakness in the Layer 3 and Layer 4 protocol stack. Example SYN Flood, Ping of Death.

Application attacks are the attacks hat exploit a weakness in the Layer 7 protocol stack. The most sophisticated of attacks and most challenging to identify/mitigate. Example, HTTP Flood, Attack on DNS Services.

Generally in any enterprise network, Arbor SP is placed in a security zone where it has SNMP, Flow (netflow/jflow) and BGP connectivity in place. This could be either in DMZ, Intranet or in a secure Management zone. It entirely depends on the specific architectural decision specific to an environment.

For BPConsidering we have the SP deployed and connectivity in place, if we want to add an ASR as a flowspec client we need to do followings.

Step1: Enable the flowspec feature on ASR.

flowspec
local-install interface-all
address-family ipv4
local-install interface-all
!
vrf Internet
address-family ipv4
local-install interface-all

Step2: Enable the flowspec address-family in BGP.

router bgp 12345

address-family ipv4 flowspec
!
address-family vpnv4 flowspec

Step3: Enable the same flowspec address-family in specific VRF where we are going to have BGP Neighborship with SP.

vrf Internet

 address-family ipv4 flowspec

Step4: Enable the same flowspec address-family in specific BGP VRF where we are going to have BGP Neighborship with SP.

router bgp 12345
vrf Internet

 address-family ipv4 flowspec

This will make the vrf Internet to have the capability to add an Arbor SP Collector as a BGP Neighbor.

Step5: Create the neighbor group for Arbor Collector.

neighbor-group ARBOR-BGP
remote-as 12345
update-source Bundle-EtherXY.123
address-family ipv4 unicast
route-policy IMPORT-FROM-ARBOR in
route-reflector-client
route-policy ALLOW-ALL out
soft-reconfiguration inbound always
!
address-family ipv4 flowspec
!

It is good if we can have the BGP Neighbors prefixes exchange controlled using route-policies as in above configuration. Please note that the route-policy in is used when we configure RTBH or any decision which we want to take based on a community value. Flowspec rule will never make use of in route-policy.

router bgp 12345
vrf Internet

neighbor 1.2.3.4

 use neighbor-group ARBOR-BGP

Now, if we have proper SP configuration at Arbor side, we should see the BGP getting up using following command.

show bgp vrf Internet summary

To check if the BGP neighborship for flowspec capability is up or not, we can issue following command.

show bgp vrf Internet ipv4 flowspec summary

Once we have the flowspec neighborship established, we can then make use of flowspec capabilities. At this stage we can create a flowspec advertisement on Arbor SP and issue following command on ASR to check if the ASR is receiving the flowspec advertisement or not.

show flowspec vrf all afi-all internal

This command will list the rule FlowSpec rule, its source and destination IP Addresses and the Match and action criteria it performs.

In the next post i will explain the command sets for Juniper.

References:

[1] https://gblogs.cisco.com/uki/mitigating-ddos-with-arbor-on-the-cisco-asr9k/