DDOS

General System Configuration
DDoS Detection and Mitigation Administrator Training
1-1 Arbor Networks SP/TMS



The TMS can be deployed as a mitigation-only solution or as a component of a Arbor Networks SP solution
that provides network monitoring, alerting, traffic engineering reports and mitigation. The following pages
will describe methods of Arbor Networks SP deployment.
Note: virtual TMS solutions are only able to be deployed in traffic diversion mode.

In most deployments, traffic is diverted from the native traffic path to the diversion (off-ramp) traffic path
through a BGP route announcement. This announcement changes the path by advertising the TMS as the BGP
next hop for the mitigated destination. The TMS appliance or SP can originate the route change by
announcing a more specific route to the network. This route-change next hop is the diversion interface of
TMS. This ensures that traffic coming from the attacking source(s) is passed through TMS for mitigation.
TMS can also be deployed in-line. In an inline deployment, the TMS appliance acts as a physical connection
between two end points (bump-in-the-wire). All traffic that traverses the network flows through the appliance.
Application performance statistics are reported most accurately in this mode because the TMS appliance
measures both inbound and outbound traffic directly through the network link.
(Continue on the next page)

Continue:
Though a majority of TMS deployments are done in-cloud utilizing traffic diversion and reinjection,
there are scenarios where deploying TMS in-line makes more sense. The following are advantages of
deploying TMS in the in-line mode:
• This is the simplest deployment method, requiring the least amount of TMS configuration and
integration with the network environment. The in-line deployment requires no networking or
readdressing of the network. Only physical connections in the protected path are required.
• The value of TMS can be maximized as it simultaneously conducts surgical mitigation of attack
traffic while providing application-layer visibility and performance analysis.
• Application performance statistics (i.e., jitter, delay, packet loss, etc.) are reported most accurately
in this mode as TMS measures both inbound and outbound traffic directly through the network
link.
• TMS can be used to generate flow information in an environment where the routers are not
capable of producing flow. For example, if a TMS appliance is deployed in front of a server data
center, the router upstream of the TMS appliance might not be BGP capable, or might be
administered by a different unit or company.
• There may be instances where a customer is not able to be mitigated through the cloud because the
border and customer aggregation edges have collapsed to a single layer. This is true in many
transit networks where, due to IGP/EGP admin distances, the local router will not divert into a
scrubbing center. The in-line mode may serve as a means to dedicate a system to the customer link
where before there was no option.

We distribute diversion traffic between clusters via iBGP Anycast; participating routers then make use of IGP
metrics to send the diverted traffic to the 'closest' instance of the anycast diversion address, and thus to the
'closest' load-leveled TMS cluster.
All that is required is a single iBGP entry for the diversion address to be installed in the RIB, nothing more.

Deploying TMS in multiple locations on a large network (scrubbing centers) provides granular control of
mitigation traffic flows through the single Arbor Networks SP management console. Large network
deployments have the advantage of tracing DoS attacks back to multiple points-of-entry into the network.
Using TMS appliances deployed in close proximity to the peering edge allows for efficient diversion to the
closest appliance for mitigation. The use of large network BGP control techniques (e.g., BGP Anycast
destination prefix announcement) can improve control over the load on the mitigation appliances as an attack
enters the network or increases in volume. In a BGP Diversion deployment, the traffic is routed as described:
1. Arbor Networks SP redirects (diverts) the traffic through the TMS. The redirection is accomplished by
using BGP, which defines an interface on the TMS appliance as the nexthop destination for the incoming
traffic.
2. The TMS inspects the traffic data and performs a mitigation that is based on the configured
countermeasures.
3. The TMS sends the traffic through a GRE tunnel or VLAN to the reinjection router (nexthop router).
4. The reinjection router forwards the traffic to the original destination thus ensuring loop-free routing to the
traffic's destination.
The TMS does not forward return path traffic; an asymmetric route is followed for the return path.
BGP Flowspec diversion enables a broader set of diversion criteria based on source and/or destination IP, port
and protocol. This feature enables traffic diversion into an MPLS backbone and allows reinjection without the
need for GRE tunneling, making DDoS attack mitigation easier for service providers and data center operators.
In a BGP flow specification diversion deployment, the traffic is routed as described:
1. Arbor Networks SP redirects (diverts) the traffic through the TMS using a flowspec redirect announcement
via BGP, which specifies a route target associated with a dirty VRF (Virtual Routing and Forwarding) to
which the attack traffic is forwarded. This dirty VRF, which is on the public side of the TMS, contains a
default route which forwards all attack traffic to the nearest TMS. The redirection is more granular than
with BGP diversion because flow specification allows a variety of traffic characteristics to be considered
when choosing to redirect traffic, including ports and source address
2. The TMS inspects the traffic data and performs a mitigation that is based on the configured
countermeasures.
3. The TMS sends the traffic directly to a nexthop router.
4. The connected nexthop router uses the global routing table to send the traffic to the original destination.
The reinjected traffic always follows the reinjection traffic path to ensure loop-free routing to the traffic's
destination. The reinjection router must be a router which does not have the flowspec announcements in its
routing table to avoid routing loops.


We typically “load balance” local clusters of Threat Management Systems in cleaning centers via CEF-based
load-leveling or its equivalent, per-packet and per-destination load-balancing.






For failover within a TMS, the NICs have relays onboard that create a direct connection between two
different TMS links when bypass is triggered. So, when bypass is triggered by a power outage or some other
event, the inline TMS changes from being a "bump in the wire" to an actual wire. The relays will stay closed
as long as the power is off. Bypass options are available for all TMS appliances.
Note: this deployment mode is only available for physical TMS appliances. No virtual TMS solution (such as
the VSM-40 in a Cisco ASR 9000) can be deployed in anything other than diversion mode.


In a SPAN (Switched Port Analyzer) port deployment, the incoming traffic is not diverted from its original
path. Instead, a copy of the traffic is diverted to the TMS appliance for analysis. The TMS appliance inspects
the copied traffic and then sends Arborflow to the leader appliance. No traffic filtering or attack mitigation
occurs in this deployment scenario. However, this type of deployment is useful for analyzing your application
performance. A SPAN port deployment can easily be converted to an inline or off-ramp deployment.


DDoS Detection and Mitigation Administrator Training General System Configuration


First, decide where to place the appliance and which deployment scenario is best for your network. You must
configure your SP leader appliance and any required licenses, and commit the configuration, before you
configure this or any other appliance.
You must use the Command Line Interface (CLI) to install your appliance. See “Using the Command Line
Interface” in the Arbor Networks SP Advanced Configuration Guide for more details.


You can view, configure, and delete Arbor Networks SP and TMS appliances on the Configure Appliances
page (Administration > Appliances). The following provides an overview of what you must know and do
when you configure an appliance.
To start click Add to begin adding a new appliance such as the Arbor Networks TMS.

It is important to set the Appliance type before proceeding with the rest of the TMS configuration because
settings in the Appliance tab and menu tabs change based on the appliance type.
Type a name and description of the appliance or TMS model. You can apply tags to appliance configurations.
This can help you to categorize and to search easily for appliances in your deployment. Type the IP address of
the management interface for the appliance or TMS model. For TMS and FS appliances select the manager
appliance for that appliance you are adding.
Finally, select the model number and enter the license key for the appliance.

SNMP settings are optional (and not available for TMS-CGSEs or TMS-ISAs). The SNMP agent runs only
when the Arbor Networks SP services run. When you stop services or if you do not install the Arbor SP
package, SNMP is not available.
If you select v1/v2c, you must include a community string so you can access SNMP data on this device. Type
up to 32 characters per community string. You can use any characters except the following: quotation marks
(“ and ‘), backslash (\), pipe (|) and Tab.

When configuring a virtual TMS, such as the Cisco VSM blade, the Deployment Type, Capabilities and
Forwarding Mode are hardcoded, as follows (each field will be grayed out and unable to be changed):
Deployment Type: Diversion
Capabilities: Optimize for Mitigation Performance
Forwarding Mode: Patch Panel

The Port for Challenge Packets setting is available in Patch Panel forwarding mode, but not in Layer 3
forwarding mode. In Layer 3 mode, the TMS appliance sends challenge packets based on the configured
routing information.

Enable Full Reporting - Enables all mitigation and reporting capabilities on all interfaces on a TMS appliance
deployed in Inline or Diversion mode. For a TMS appliance deployed in PortSpan mode, this enables all
reporting capabilities on all interfaces but does not enable mitigation.
Optimize for Mitigation Performance - Enables only mitigation on all interfaces on the TMS appliance
Advanced - Allows you to apply custom capabilities to a TMS appliance on the Patch Panel tab.

If Patch Panel is set as the Forwarding Mode, the Patch Panel tab is used to map input port to nexthop address
and output port.
When you select Layer 3 as the Forwarding Mode, one of the following methods is used to forward packets:
Direct  Forwards packets directly to the destination address when this address is in the same subnet as the
TMS appliance.
Standard  Forwards packets to a nexthop using a static route that is configured on the IPv4 Forwarding or
the IPv6 Forwarding tab. It uses the static route that has the longest matching prefix. If none of the static
routes on the IP Forwarding tab match, then it forwards the packet to the default nexthop that is also
configured on the IP Forwarding tab.
GRE  Uses the GRE tunnels that are configured on the GRE tabs to forward packets. The GRE tunnel that
has the longest matching prefix is used.

When Layer 3 forwarding is enabled, the TMS will send and respond to ARPs:
admin@demo:/# service tms show arp

TMS ARP/NDP TABLE
ARP/NDP Entries
-----------
tms2:
192.168.47.1 Configured 00:19:07:a8:9f:c0


Component failures such as CPU, processes, interfaces and power supplies will be noted in the UI for each
TMS appliance. There are group membership failures, where you can require all devices be up and with
bandwidth available before starting a new mitigation. Existing mitigations will also end if a device in the
group fails or becomes unreachable.
Each TMS device can be configured with fault handling for interface failures, nexthop failures, BGP Peer
failures and GRE Tunnel failures.


Existing ongoing mitigations will enter a degraded state if the fault handling determines the TMS or TMS
group should be taken offline. This mitigation will need to be restarted once the failure is addressed or the
offending TMS is removed from the Device Group. These mitigations do not automatically restart once the
fault is corrected.

Keep in mind your design with failures. A single TMS failure in a group can take the entire group offline and
stop all mitigations. This is normally a good thing depending on how the TMS is architected in the network
and what the available capacity is to backhaul traffic to other TMS devices in the network.

Configure the ArborFlow settings from the ArborFlow tab.

Select one of the following to configure flow:
Leave the Export Port box blank to use the default value (5000).
Type the UDP port on which the flow will be sent in the Export Port box.
Type the rate at which you want Arbor Networks SP to sample flows in the Sampling Rate box. If you leave this box
blank, then Arbor Networks SP uses the default setting, which is 10 for TMS 2000-series appliances and 1000 for all
TMS 3000-series and 4000-series appliances.
To assign a BGP router to the appliance for flow matching, select the router from the Source of BGP table for flow
classification list. This feature only functions when a TMS appliance is managed by a CP-5500 appliance.
Clear the Ignore ArborFlow for DoS Detection check box to allow the TMS appliance to serve as an input for DDoS
detection and to generate alerts. Select the Ignore ArborFlow for DoS Detection check box to prohibit TMS appliances
from generating alerts.

Configure the patch panel settings for SP TMS devices from the Patch Panel tab.
Type the IP interface address in the IP Address box for an input port Select the output port and the interface
name from the Output Port list. You must set the output port to forward traffic. Then, type the IP address of
the nexthop of the traffic in the Nexthop box.

For diversion deployments, an input port is configured with an IPv4 and/or IPv6 Address and mapped to its
Output Port and Nexthop IPv4 and/or IPv6 address.
For inline deployments, both input ports are mapped to each other. An IP Address may be configured but is
not required since the appliance is functioning as a “bump in the wire” not a routing/forwarding device.

If you selected Advanced from the Capabilities list on the Deployment tab, then select from the following
capabilities that you want the individual ports to have:
Mitigate applies intelligent traffic filtering rules to traffic flowing into this port.
Flow generates ArborFlow data from the incoming traffic on this port (in combination with additional
configurations).
DNS gathers DNS usage statistics by inspecting the packets flowing through this port.
Important: Consult your Arbor Networks CE before you configure the Flow or DNS options because these
features require additional configuration.
HTTP gathers HTTP usage statistics (for example, MIME types, HTTP URLs) by inspecting the packets
flowing through this port. It is for port-span TMS interfaces.
VOIP gathers VoIP usage statistics (for example, top callers, recipients, and conversations) by inspecting the
packets flowing through this port. It is for port-span TMS interfaces.

If you configure a diversion deployment, then select this check box to configure the appliance to use the DNS
NXDomain Rate Limiting countermeasure. This check box simplifies enabling DNS NXDomain response
listening on a network port span. When you select this check box, Arbor Networks SP uses this port to listen
to the DNS NXDomain responses.
When you select this check box, the Output Port is disabled and set to none, and the Capabilities check boxes
are disabled. The Capabilities check boxes appear only if you selected Advanced from the Capabilities list on
the Deployment tab.
Note: The NXDomain Listening option is not available for virtual TMS implementations.


"Subinterface" refers to a VLAN on a physical port. Add a subinterface from the Subinterfaces tab.
Type the description of the subinterface in the Description box to help you to identify the subinterface and
type the ID number of the VLAN to which the interface connects in the VLAN ID box. Then, select an
interface (physical or logical) of the Arbor Networks SP TMS device from the Parent list. Finally, click Add
to apply the subinterface settings to the SP TMS device and Save.
When you create multiple subinterfaces on a single physical port, each subinterface appears as a separate
instance in the TMS patch panel. When you configure diversions on one subinterface and reinjections on a
different subinterface, even though they are both on the same physical port, it looks like you are using 2
different interfaces in the patch panel.
You can configure the patch panel to send the reinjection traffic out the same physical port on which it was
received (hair pin). In that case, you will need to prevent a routing loop by some mechanism like VRF on the
adjacent router.

To load-balance traffic across multiple physical ports, you can combine multiple physical ports into one
logical port. In Arbor Networks SP, "logical port" refers to an LACP bundle of multiple physical ports. A
physical port can only be part of one logical port.
You can designate whether a logical port should operate in active or passive LACP mode. When you set a
logical port to operate in active LACP mode, the TMS appliance sends control packets on physical interfaces
and expects to receive packets from an LACP partner device. If the TMS appliance does not receive control
packets, then Arbor Networks SP puts the physical interface out of service. In passive LACP mode, the TMS
appliance only sends control packets if it first receives them from an LACP partner device. Arbor Networks
SP will not put the physical interface out of service due to the absence of received control packets, regardless
of whether the TMS appliance previously received them.

Select one of the following systems from which you want to peer from the Peer from System list:
Arbor Networks SP (to peer from the device configured to manage the router)
TMS (to peer from the SP TMS device)
Select the IP address of the default diversion nexthop from the Default Diversion Nexthop list.
Then click Edit Peering Sessions and the Router Selection Wizard appears. Select a group to filter on from the Group list
(optional). Type a regular expression in the Name Regexp box (optional). Click Filter (optional). To add routers, select
one or more routers from the Available Choices pane, and then click the down arrow (∨). To delete routers, select one
or more routers from the Selected pane, and then click the up arrow (∧). Click Select.
The selected sessions appear in the BGP Peering Sessions box. The sessions in this list are those with which the system
should peer for BGP diversion.




Arbor Networks SP allows you to create GRE tunnels to send mitigation traffic from the TMS device
deployed in diversion mode to the router. You can configure two types of tunnels:
1. static  tunnels traffic through without the option to failover.
2. redundant  GRE keepalives are used on these tunnels and will failover to a secondary destination if the
tunnel to the primary destination fails.
Configure GRE tunnels for re-injecting traffic
Single source address
Must save before you can add tunnels
Each prefix is assigned to a tunnel
Prefixes should not overlap
(Continue on next page)

Continue:
GRE Keepalive
Keepalives enable Arbor Networks SP to alert you to down GRE tunnels, which can hinder the SP
TMS device from forwarding good traffic. Redundant GRE tunnels use keepalives by default. You
can use static tunnels without enabling keepalives. However, because you cannot configure a backup
tunnel for static tunnels, enabling keepalives on static tunnels allows Arbor Networks SP to trigger a
system alert when a tunnel goes down so you can ensure that good traffic is not blackholed (after a
static GRE tunnel goes down, the SP TMS device blackholes all traffic, good and bad). When not
enabled for static tunnels, keepalives are only used on redundant tunnels.
You can monitor your GRE tunnels on the GRE column in the TMS Statistics tab on the Appliance
Status page (System > Status > Appliances Status). You can also click the + icon in the Alerts column
to view the most recent alerts. The Information column will display information about any down
GRE tunnels.
A keepalive packet is a GRE packet encapsulated within another GRE packet. The outer GRE packet
has a source address of the Arbor SP-configured GRE tunnel source and a destination address of the
Arbor SP-configured GRE tunnel destination. The inner GRE packet reverses the source and
destination addresses. The keepalive packet is sent to the GRE end point, which then unencapsulates
the outer GRE header from the packet. The new packet with the former inner GRE header is then
routed back to the TMS mitigation interface. When the TMS appliance receives the returned packet,
the appliance declares the GRE tunnel up.
Static Tunnel Configuration

Select the Enable Keepalives on Static Tunnels check box to allow keepalives on static tunnels
(optional).
Type the number of seconds between keepalive messages on the GRE tunnels in the GRE Keepalive
Interval box.
Type the number of times the system will send keepalive messages (without getting a response)
before it marks the tunnel as down in the GRE Retries box.
Redundant Tunnel Configuration

Type the number of seconds between keepalive messages on the GRE tunnels in the GRE Keepalive
Interval box.
Type the number of times the system will send keepalive messages (without getting a response)
before it marks the tunnel down in the GRE Retries box.
Important: Do not enable keepalives on your router.

Introduced in Arbor Networks TMS 7.0.3 for TMS 4000 Series appliances and TMS-VSMs
only, Blacklist offloading relieves the TMS mitigation processor of the need to process traffic from
blacklisted, repeat-offender hosts. When blacklist offloading is enabled, the TMS 4000 or TMS-VSM
generates flow entries for blacklisted, repeat-offender hosts. It then pushes those flow entries to an
upstream network device, such as a switch. The repeat-offender hosts that send packets at the highest
rate get the highest offloading priority.
After flow entries are offloaded, inbound packets sent from blacklisted, repeat-offender hosts are
dropped at the upstream network device before they enter the TMS mitigation processor. This frees more
TMS resources to mitigate new threats.
(Continued on following page)


About different blacklist offloading methods

TMS 4000s and TMS-VSMs employ different blacklist offloading methods. TMS 4000s use the “hardware
blacklist offloading” method. TMS-VSMs use the “OpenFlow blacklist offloading” method.
TMS 4000s implement hardware blacklist offloading as follows:
• The upstream network device is a hardware switch in the TMS 4000 chassis.
• The hardware switch can drop both IPv4 and IPv6 packets that are sent from blacklisted, repeat-offender
hosts.
• Hardware blacklist offloading is always enabled.
TMS-VSMs implement OpenFlow blacklist offloading as follows:
• The upstream network device is a software-defined OpenFlow switch that is configured in a Cisco ASR
9000 (ASR9K) router. The TMS-VSM is installed in a slot in the ASR9K router’s chassis.
• The OpenFlow network device can drop IPv4 packets only that are sent from blacklisted, repeat-offender
hosts.

A single TMS appliance can have several mitigations running simultaneously, protecting different resources
in the network. The maximum number of ongoing simultaneous mitigations per TMS appliance is controlled
by the Maximum Ongoing Mitigations setting, the configurable range is for each TMS is:
• TMS-4000 10 - 100, blank for default value 100
• TMS-CGSE 10 - 50, blank for default value 50
• TMS-ISA 10 - 50, blank for default value 50





When you select the check box on the Deployment tab, mitigations for the group are stopped in the following
situations:
• when one or more TMS appliances or TMS clusters are put out of service, become unreachable, or fail
• the group’s leader appliance becomes unreachable



If you enable DNS Authentication in UDP Active mode, then the TMS appliance intercepts DNS queries
before they reach an authoritative DNS server and then issues a challenge to the client to verify that those
queries are valid before passing the traffic to the original server.
Configure secondary servers for active DNS authentication from the Active DNS Authentication tab. Type the
prefixes for the DNS query traffic that you want a TMS appliance in this group to intercept, followed by the
IP addresses of the servers to which you want to redirect that traffic for authentication in the Secondary
Servers box.
Note: You can type the IP address of a different authoritative DNS server or of an alias for the same DNS
server.
This configuration is needed if you want Microsoft recursive/caching servers to “seamlessly” authenticate.
Because of “security" (aka non-RFC behavior), Microsoft servers will authenticate but will not resend the
original query at the very end. So the query that got the server authenticated will timeout but, since the IP is
authenticated, any further queries will be passed.


In order for a deployment to use ATLAS Intelligence Feed, a license key must be purchased for the Arbor
Networks SP deployment. The license key is provided through an annual subscription fee, which is based on
the number and capacity of TMS devices deployed. Once provided, the license key enables the Arbor
Networks deployment to pull AIF updates and additions from Arbor.
The license key is based on the serial number of the Leader device, either a Portal Interface (PI) or Collector
Platform (CP). Once purchased, the Arbor Technical Assistance Center (ATAC), will issue a license key.

To install the License Key, login to the Web UI of the Arbor Networks deployment and navigate to
Administration > ATLAS. Once on the ATLAS page, select the ATLAS Intelligence Feed tab.
Enter the License Key in the key dialog box. In the Model dialog enter SP-TMS-AIF. Also, make sure to
enable the automatic connection to the AIF server to receive regular updates. The update interval can also be
specified. If no time is entered, then the Arbor SP Leader will poll the AIF Server every 1 hour. Make sure to
save and commit the configuration.
To receive the latest information and also to check for connectivity, navigate back to the ATLAS Intelligence
Feed configuration page and click the Update Now button.

Use configured IP address of egress interface as source: Select this box to use the IP address of the
interface from which packets leave as the source IP address. (If left unchecked, the default address used is the
IP address of the appliance.)



DDoS Detection and Mitigation Administrator Training Managed Objects


Managed object children allow you to group managed objects hierarchically and create scoped managed
objects. Internet Service Providers (ISPs) can use child managed objects to increase revenue and offer
traffic visibility, detection, and mitigation services to their customers.

Used when monitoring routers directly connected to the managed object – i.e. customer aggregation
router.
Used when you want to configure a more detailed boundary than the network boundary for the customer
so you can capture backbone traffic from the customer. This could be done on the actual customer
interfaces if they're monitored, on an aggregation router, or even on a POP/regional gateway router that
connects a region to the main network backbone.
Counts all data for the MO and not just the traffic that goes across the network provider boundary.
Traffic is counted across specifically configured boundary interfaces.




Rules Only – When the managed object has boundary rules but no statically configured boundary
interfaces, use this boundary type. The system will not use the global default boundary.
Select one of the locations from the Locality list: default, internal, or external and click Save. Navigate
back to the Edit page and click the Boundary tab. Click Add to open the Add Rule window. Complete the
settings in the Add Rule window.
Note: The rules here mirror the rules configured on the master Auto-Configuration Rules page (Admin
> Monitoring > Auto-Configuration > Rules). You can edit rules in either location. Only rules that
apply to this managed object are listed.
Traffic for MOs defined as Match Type ‘Selected TMS Ports’ is counted in a similar way to “regular”
MOs with ‘Manual, Advanced Boundary Interfaces”’, with the difference that since no IP addresses are
specified, the IN/OUT direction is only determined by the direction of the traffic on the interfaces.
Rules:
Traffic entering a “TMS In” port is counted as IN to the MO;
Traffic entering a “TMS Out” port is counted as OUT from the MO;
if “TMS Auto” is selected, traffic will be counted as “IN” by default.

Continue
To select the TMS in ports, click TMS In Ports and the TMS Ports Selection Wizard opens. Select your
filter criteria and click Filter. Highlight the ports you want to add from the Available Choices box, and
click the down arrow. The ports appear in the Selected box. Click Select and the in ports appear in the
Match Values box.
To select the TMS out ports, click TMS Out Ports. Select your filter criteria and click Filter. Highlight
the ports you want to add from the Available Choices box, and click the down arrow. The ports appear in
the Selected box. Click Select and the out ports appear in the Match Values box.
To select the TMS auto ports, click TMS Auto Ports. Select your filter criteria and click Filter. Highlight
the ports you want to add from the Available Choices box, and click the down arrow. The auto ports
appear in the Selected box. Click Select and the auto ports appear in the Match Values box.

Use simple when MO lives on one side of boundary and flow to/from MO likely to cross boundary only
once. The MO is simple relative to the perspective of the monitored network.
Use advanced when MO match doesn‘t include source or destination IP, lives on both sides of boundary,
or flow to/from MO likely to cross boundary twice. The MO has a complex/advanced relationship to the
monitored network.
Traffic for MOs defined as Match Type “Flow Filter” are required to be configured as “Manual,
Advanced Boundary Interfaces”, but any MO can be configured to use them.
Rule:
Traffic entering Object-facing interfaces and matching the filter is counted as OUT of the MO. Traffic
leaving the interface and matching the filter is counted as IN to the MO.
Traffic entering Backbone-facing interfaces and matching the filter is counted as IN to the MO. Traffic
leaving the interface and matching the filter is counted as OUT the MO.



Managed Object Threshold-based Alerting is enabled globally by default.

You can configure high and low thresholds for either bps or pps. Every minute, SP looks at the in and out
traffic for each managed object and compares it with the thresholds configured for that managed object.
If the in or out traffic is over the configured high threshold, then the system generates a high threshold
alert. If both the in and out traffic is below the configured low threshold, then the system generates a low
threshold alert. SP evaluates each threshold is independently for bps and pps.
There is no system default for generating alerts on a given managed object threshold, so you must
configure each managed object.



DDoS Detection and Mitigation Administrator Training Configuring Detection Settings










The Forced Alert Threshold causes Arbor Networks SP to generate an alert when traffic exceeds it for
the profiled latency period. This threshold is manually configured and is an optional behavior in
Profiled Detection except for Interface Group matched Customer and Profile MOs. There are separate
incoming and outgoing settings which are applied per router for protocol alerts and per interface for
bandwidth alerts. These settings effectively override the Ignore Rate when it’s value is larger than the
Forced Alert Threshold value.
Forced alert thresholds could be used with baselines to ensure that alerts are generated when traffic
rates exceed certain thresholds. With a baseline, the rate of traffic that is required to generate an alert
can increase over time. If you configure forced alert thresholds, then an alert is generated when a
forced alert threshold is exceeded even when an alert would not be generated because of the baseline.
The Forced Alert Threshold settings were added to Profiled Detection in the Arbor Networks SP 5.8
release.









Enabling/disabling Outgoing Detection per Managed Object was added in Arbor Networks SP 5.8.
Prior to that release, Outgoing Detection could only be enabled globally.

Click on MO to Edit  Profiled Router Detection  Set Profiled to Enabled  Click on Edit
Profiled Router Configuration
The Severity Rate Floor value places a minimum on the severity rate determined by auto-rate
calculation. The Ignore Rate Floor value places a minimum on the ignore rate determined by auto-
rate calculation. Auto-rate calculation never provides severity or ignore rates below these values. If
the calculated rate is lower, then Arbor Networks SP uses the rate floor value.
SNMP Link Rate Severity Calculation. If a bandwidth limitation for a managed object is its upstream
link capacity, such as when the links are the direct connections to a customer, and Arbor Networks SP
is monitoring those upstream links, then it could be useful to enable "SNMP Link Rate Severity
Calculation". If it is enabled, an attack that exceeds the capacity of one of those links will be set to
high severity even if the attack does not exceed the fixed or automatic severity rates for the managed
object.

A percentile basically says that for the specified percentage of the time, the data points are below the
resulting value. So if we calculate a 50th percentile, 50% of the time the data points are below that
resulting value and 50% of the time they are above that value. A 50th percentile is the same as a
"median." A 95th percentile says that 95% of the time data points are below that value and 5% of the
time they are above that value. 95 is a magic number used in networking because you have to plan
for the most-of-the-time case. If networks were planned for mean or average use, they could be
unusable (saturated) half the time.
The Severity Multiplier is used to calculate the high severity rate. Type the number you want to
multiply with the severity threshold to calculate the new high severity rate. For example, if the 95th
percentile value comes out to 100 Mbps, then a severity multiplier of 1.1 will create a high severity
rate of 110 Mbps.

Changing the Severity Percentile, Severity Multiplier, and Ignore Percentile settings will change how
the system calculates the values for Ignore Rate and Severity Threshold. ARC takes up to the last 30
days of traffic samples, then for the severity threshold, it takes the severity percentile value and
multiplies it by the severity multiplier which then becomes the Severity threshold. This is done for
bps, pps in both incoming and outgoing directions.
Ignore rate does not use the Severity Multiplier, just the configured Ignore Percentile.
Severity Rate Floor settings are the lowest values for which you want Arbor Networks SP to generate
a severity rate, and then select the corresponding traffic units from the lists.
Ignore Rate Floor settings are the lowest values for which you want Arbor Networks SP to generate
an ignore rate, and then select the corresponding traffic units from the lists.




Profiled network detection identifies excessive rates of network-wide IPv4 and IPv6 traffic based on
baselines that Arbor Networks SP has calculated for your network. The alerts are triggered at the
configured managed object boundary (whether the global boundary or local interface).
Enable Profile Country Detection: If enabled, Arbor Networks SP generates alerts when the traffic
from a country exceeds the baseline values for that country.
Incoming/Outgoing Detection Percent: Type the percentage above the baseline that either incoming
or outgoing traffic must be before Arbor Networks SP triggers the alert.
Incoming/Outgoing Severity Percent: Type the percentage above the baseline that either incoming
or outgoing traffic must be before Arbor Networks SP triggers a High alert.
Incoming/Outgoing Ignore Rates: Type the traffic rates (in bps and pps) below which you do not
want Arbor Networks SP to generate alerts.


When there are MO’s with child managed objects, you may want to disable detection on the parent
MO in order to reduce the number of alerts generated by a single event.






















DDoS Detection and Mitigation Administrator Training Mitigation Settings



The IPv6 Mitigation feature was added in the Arbor Networks SP 5.6 release.





Filter Types
IPv4 Black/White – An FCAP filter based on ports, protocols, IPv4 addresses, etc.
IPv6 Black/White – An IPv6 FCAP filter based on ports, protocols, IPv6 addresses, etc.
DNS – A list of DNS regular expressions.
IP Location – A list of countries, as defined by their IP addresses.
IPv4 Address – A list of IPv4 addresses and CIDR blocks.
IPv6 Address – A list of IPv6 addresses and CIDR blocks.
URL – A list of URL regular expressions.
Arbor Networks SP validates IPv4 Black/White, IPv4 Address, IPv6 Address, URL, and DNS filters when
you configure and save them. If Arbor Networks SP cannot validate a filter, the Filter List Validation Errors
window appears.


This table includes the Filter List mitigation limits for each series of appliances.

IP Location filter lists are assembled from one or more geographic country objects that are loaded in Arbor
Networks SP software for use in TMS mitigations. Each IP Location country object is internally defined as a
large list of IP addresses that is not visible or configurable in Arbor Networks SP. Each IP Location filter list
is configured in Arbor Networks SP as a selection of any number of IP Location countries. Default IP
Location filter lists for several continental regions are installed by the software. Any number of overlapping
IP Location filter lists are allowed. IP Location filter lists do not have any intrinsic drop or pass action.

Any number of IP Location filter lists may be selected for a mitigation, and a single selector determines for
that mitigation whether traffic will be dropped if the source address matches any selected IP Location filter
lists, or will be dropped if it does not match any selected IP Location list.
IP Location filter lists are used in mitigations to filter only IP source addresses and do not affect destination
addresses.

IP Location Filter Lists have two primary use cases.

If the legitimate client user base for a protected prefix is entirely within a known geographic area, a IP
Location filter list can be used to define that area for mitigations. Any mitigation for that prefix can then use
that IP Location filter list to drop all traffic outside of that area. Additional mitigation countermeasures can
then be used against attackers from within the legitimate user area without the need to apply those
countermeasures to all attackers worldwide.
Alternatively, if attacks are repeatedly launched from a particular geographic region that is unfriendly to the
Arbor Networks customer, an IP Location filter list can be used to define that unfriendly area. Any mitigation
then can use that IP Location filter list to drop all traffic from sources within that area, and any additional
countermeasures will then be applied only to stray attackers outside of that area.



Mitigation templates are preset groups of countermeasures and countermeasure settings that can be used to
pre-populate the settings of a TMS mitigation.
Mitigation templates are intended to be used as a tool to quickly set the countermeasure settings of a TMS
mitigation, allowing a mitigation to be started with minimal time and effort. With mitigation templates
configured, Arbor Networks SP can even be configured to perform an automatic mitigation response.
A TMS mitigation template named “Default” always exists in the system configuration. Its settings are used
as default mitigation settings by any mitigation that is not set to use a different template. Networks that have
one generic template for initial attack response often choose to make it the Default template.

There are many strategies for building mitigation templates which will vary depending on customer needs.
Some ideas for mitigation templates are as follows:
Generic Template – A generic template enables some or all of the most common countermeasures. The
purpose of a generic template is to allow operators to quickly configure mitigations to block likely attacks as
soon as possible, before knowing anything about the attack, thereby reducing the impact of an attack as soon
as possible and easing pressure on operations staff until they can more carefully analyze the attack.
When more is known about an attack, the mitigation can be modified or replaced to adjust the
countermeasures and other settings. Most Arbor Networks TMS implementations include at least one generic
template to be used as a typical first response.

Continue
Resource-based templates – Resource-based templates are mitigation templates that are set
according to the characteristics of a particular resource to be protected. For example, a web
server would likely have HTTP Authentication and Zombie filtering, but would not have a need
for DNS or SIP countermeasures. A resource-based template typically uses the Black / White
List to block all traffic that is not accepted by the resource, and also enables countermeasures that
are relevant for. Resource based templates are typically used in conjunction with auto-
mitigations. The mitigation template is associated with a Arbor Networks SP managed object so
that a mitigation using those template settings is automatically activated whenever Arbor
Networks SP detects high-impact anomalous traffic toward the resources defined by that
managed object.
An example resource-based template for a DNS server group might use the Black / White List to
permit SSH and SNMP traffic to and from operations center networks and to block all other
traffic except for TCP port 53 and UDP port 53, and to enable DNS Authentication (and, starting
in TMS 5.1, other DNS-related countermeasures).
Attack-based templates – Attack-based templates are mitigation templates that are set according
to the characteristics of a particular type of attack. The purpose of attack-based templates is to
allow security-knowledgeable administrators to create a collection of pre-defined defenses for
various attack types. Operators are then able to choose mitigation settings from the template
collection based on the suspected attack. Settings guesswork by operators is thus minimized and
response time is decreased.
Some attack-based templates may be quite simple, yet still be useful. An example template for
TCP SYN attacks might enable only the TCP SYN Authentication and Zombie Detection
countermeasures, and perhaps add a Black / White List rule to drop packets that have SYN set
along with any of FIN, URG, or PSH.

Another example of a Mitigation Template would be those tailored towards dealing with specific types of
attacks.
In this case, for dealing with TCP flooding based attacks, it might make sense to specifically configure our
Mitigation Template with the "Zombie detection" and the "TCP SYN Authentication" countermeasures
enabled.
This would enable a user to quickly enable this particular Mitigation Template if a corresponding attack were
observed.

The SP system includes several system-defined mitigation templates:

• Default IPv4
• Default IPv6
• Auto-Mitigation IPv4 - Uses this template as the default for managed object IPv4 auto- mitigations.
• Auto-Mitigation IPv6 - Uses this template as the default for managed object IPv6 auto- mitigations.
• DNS Flood Protection – Provides example countermeasures to support deployments for DNS
infrastructure protection for DNS authentication, malformed DNS filtering, and flood and zombie
protection.
• VoIP Gateway Protection - Provides example countermeasures focused on VoIP Gateway Flood Protection.

Mitigation templates allow you to set common configurations for multiple mitigations. These mitigation
templates serve as examples for how you might configure a mitigation for a particular attack. You can use
existing mitigation templates or create your own templates for attacks against specific infrastructure (for
example, VoIP and DNS servers) or against particular customer types (for example, video hosting).
When a managed object produces an anomalous alert, either you can manually configure a mitigation or
Arbor Networks SP can automatically configure a mitigation to protect your network against the attack. When
Arbor Networks SP performs a mitigation, it applies the settings from the template you select or from the
default template.

By default, the mitigation template that is applied to all Managed Objects is the system-defined ”’Default
IPv4/IPv6’ template, which contains countermeasure settings for the most common types of DDoS attacks.
This might not be the most appropriate template given the asset under protection, therefore it might make
sense to make additional templates based on your needs.
Mitigation Templates can be managed by navigating to the Administration > Mitigation > Templates
hierarchy within the WebUI. All existing Mitigation Templates will be listed here and they can be edited or
deleted. New Mitigation Templates can be created by selecting the "Add Template" button.

When configuring a Mitigation Template, you will notice that the configuration looks identical to the
configuration of an actual mitigation. This is because the template settings will ultimately populated into a
live mitigation and determine which countermeasures are activated within that mitigation.
Select Enable CDN Proxy Support to prevent the blacklisting of a content delivery network (CDN) proxy.
This setting is a global setting that applies to all countermeasures in a mitigation that can blacklist a source IP
address (more on this later).

When defining a Mitigation Template, the operator has the ability to lock or unlock particular settings such
that changes to a mitigation can be allowed or disallowed. For example, if a mitigation were activated as a
result of a mitigation template and the 'TCP Connection Reset' countermeasure was locked, an operator would
be unable to disable or change the settings for this particular countermeasure.




Once a Mitigation Template has been created, it needs to be associated with a particular Managed Object.
In order to do this, you need to navigate to Administration > Monitoring > Managed Objects, select a
Managed Object and access the Mitigation tab. In the section on Templates, we can assign a template to be
used for either a User Initiated mitigation or an Auto-Mitigation.
User Initiated Mitigations are those that are initiated as a result of an operator selecting the mitigate button on
an observed alert. This will take the operator to a Mitigation screen with countermeasures and thresholds pre-
defined based on that which is specified in the Mitigation Template.
Auto-mitigations allows Arbor Networks SP to automatically initiate a TMS mitigation when designated
customer managed objects are attacked. This allows an environment to fully automate the response
mechanism for dealing with attacks.



You can enable auto-mitigation for customer managed objects. Auto-mitigation allows Arbor Networks SP to
initiate a TMS mitigation automatically when a customer managed object is attacked.
This feature is disabled by default.
You must globally configure auto-mitigation on the Configure Global TMS Mitigation Settings page
(Administration > Mitigation > Global Settings) before you can configure auto-mitigation for specific
customer managed objects.

You can configure auto-mitigation for a specific customer managed object on the Mitigation tab of the Add
Customer Managed Object page or the Edit Customer Managed Object page. When you enable auto-
mitigation on a customer managed object, you can also specify constraint prefixes for it. Constraint prefixes
limit the IP address space that Arbor Networks SP auto-mitigates.

With an IPv6 CIDR block-based customer managed object, the Profiled Auto-Mitigations options appear
when you click Enable Auto-Mitigation on the managed object's Mitigation tab. With an IPv4-based
customer managed object, the Profiled Auto-Mitigations options appear when you click Alert Triggered on
the managed object's Mitigation tab.
The Profiled Auto-Mitigations options allow you to disable auto-mitigation for alerts that are triggered by a
profiled router attack or a profiled network attack while you enable auto-mitigation for DoS alerts that are
triggered by a host attack. For example, you can enable both host detection and profiled network detection for
a managed object, but only enable auto-mitigation for DoS alerts that are triggered by a host attack.
They also allow you to use the global auto-mitigation setting for alerts triggered by a profiled router attack or
a profiled network attack. You configure this global setting on the Configure Global TMS Mitigation Settings
page (Administration > Mitigation > Global Settings).
Note: Arbor Networks recommends that you do not enable auto-mitigation for DoS alerts that are triggered
by a profiled router or a profiled network detection.



Note: If you have manually edited the auto-mitigation i.e. changed and saved the mitigation config in any
way while it is running, then the auto-mitigation will no longer end automatically and you will have to end it
manually.
SP stops auto-mitigations when the alerts end and will not restart an auto-mitigation after it stops. You can
manually restart a mitigation by changing settings on the mitigation pages (Mitigation menu).
If you edit, stop, or start an auto-mitigation, it clears the auto-mitigation flag and the auto-mitigation converts
to a user-generated mitigation.
You can create a TMS mitigation even when it overlaps and matches the same alert_id as an auto-mitigation.





Arbor Networks SP counts all running learning mitigations toward your licensed mitigation limit. If you are
approaching your limit, while running one or more learning mitigations, and then try to start a regular
mitigation, Arbor Networks SP stops the learning mitigation to allow the regular mitigation to start.

The learned dataset contains “normal busy” settings for the following countermeasures:
• Zombie Detection (bps, pps)
• TCP Connection Reset (seconds)
• HTTP Rate Limiting (requests per second, Objects per second)
• DNS Rate Limiting (queries per second)
• DNS NXDomain Rate Limiting (failed queries per second)
• SIP Request Limiting (messages per second)







Corporate Headquarters
76 Blanchard Road
Burlington, Massachusetts 01803
Toll Free +1 855 773 9200
T +1 781 362 4300
F +1 781 365 1749
Europe Headquarters
T +44 207 127 8147
Asia Pacific Headquarters Revised: 26 FEB 2017

T +65 68096226
www.arbornetworks.com Information presented in this document is subject to change without

notice. The contents of this publication may not be reproduced (in any
Copyright © 1999-2016 part or as a whole) without the permission of the publisher. Peakflow X
Arbor Networks, Inc. is a trademark of Arbor Networks. All other trademarks are the property
All rights reserved. of their respective owners.

DDOS

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DDOS

Uploaded by

Copyright:

Available Formats

General System Configuration

DDoS Detection and Mitigation Administrator Training

1-1 Arbor Networks SP/TMS

1-2 Arbor Networks SP/TMS

1-3 Arbor Networks SP/TMS

1-4 Arbor Networks SP/TMS

(Continue on the next page)

1-5 Arbor Networks SP/TMS

1-6 Arbor Networks SP/TMS

1-7 Arbor Networks SP/TMS

1-10 Arbor Networks SP/TMS

1-11 Arbor Networks SP/TMS

1-12 Arbor Networks SP/TMS

1-13 Arbor Networks SP/TMS

1-14 Arbor Networks SP/TMS

1-15 Arbor Networks SP/TMS

1-16 Arbor Networks SP/TMS

1-17 Arbor Networks SP/TMS

1-18 Arbor Networks SP/TMS

1-19 Arbor Networks SP/TMS

1-20 Arbor Networks SP/TMS

1-21 Arbor Networks SP/TMS

1-22 Arbor Networks SP/TMS

1-23 Arbor Networks SP/TMS

1-24 Arbor Networks SP/TMS

1-25 Arbor Networks SP/TMS

1-26 Arbor Networks SP/TMS

1-27 Arbor Networks SP/TMS

1-28 Arbor Networks SP/TMS

1-29 Arbor Networks SP/TMS

1-30 Arbor Networks SP/TMS

1-31 Arbor Networks SP/TMS

1-32 Arbor Networks SP/TMS

admin@demo:/# service tms show arp

1-33 Arbor Networks SP/TMS

1-34 Arbor Networks SP/TMS

1-35 Arbor Networks SP/TMS

1-36 Arbor Networks SP/TMS

1-37 Arbor Networks SP/TMS

1-38 Arbor Networks SP/TMS

Configure the ArborFlow settings from the ArborFlow tab.

1-39 Arbor Networks SP/TMS

1-40 Arbor Networks SP/TMS

1-41 Arbor Networks SP/TMS

1-42 Arbor Networks SP/TMS

1-43 Arbor Networks SP/TMS

1-44 Arbor Networks SP/TMS

1-45 Arbor Networks SP/TMS

1-46 Arbor Networks SP/TMS

1-47 Arbor Networks SP/TMS

1-48 Arbor Networks SP/TMS

1-49 Arbor Networks SP/TMS

1-50 Arbor Networks SP/TMS

(Continue on next page)

1-51 Arbor Networks SP/TMS

Static Tunnel Configuration

Redundant Tunnel Configuration

Important: Do not enable keepalives on your router.

1-52 Arbor Networks SP/TMS

(Continued on following page)

1-53 Arbor Networks SP/TMS

1-54 Arbor Networks SP/TMS

About different blacklist offloading methods

1-55 Arbor Networks SP/TMS