APS 6.0 Defend Unit 5 Cloud-Based Mitigation - 20180823

Defending Against DDoS
Attacks using Arbor APS
Unit 5: Configuring Cloud Signaling

Objectives
At the conclusion of this unit you will learn to:

• Define Arbor APS cloud signaling
• Describe when to use Arbor APS cloud signaling
• Distinguish between different cloud signaling requests
• Configure Arbor APS to connect to your provider’s cloud-
based services
• Use and monitor your cloud-based mitigation
©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 2

ARBOR NETWORKS CLOUD SIGNALING FOR DDOS PROTECTION
Mitigating Attacks in the Cloud

Issue: Service-disrupting Volumetric DDoS Attacks
DATA
ISP CENTER
SATURATION
IPS
Firewall Load
Balancer
Target
Attack Traffic the APS Applications &
Good Traffic Services
When Enterprise or Data Center operators are under a service-disrupting

DDoS attack
• Best to mitigate application-layer attacks at the customer edge with
volumetric attacks upstream (hybrid DDoS protection)
• Required to handle VOLUMETRIC attacks that exceed the Data Center’s
uplink bandwidth capacity

Mitigation Attempted
• Attack is confirmed by NOC/SOC engineer

– APS reporting provides details of a Volumetric attack towards DNS server
• Mitigation attempted
– Protection Level moved from Low à High
• And attack traffic is dropped by the APS but…
– Bandwidth usage remains high and links are saturated with no change or drop in
traffic volume
– Users continue reporting server slow or down

Engaging ISP to Mitigate DDoS Attack
SCRUBBING
DATA
CENTER
CENTER
IPS
Firewall Load
Balancer
Target
Attack Traffic the APS Applications &
Good Traffic Services
• NOC/SOC engineer reaches out to their ISP to mitigate attack

– Requests ISP to block attack traffic to that Targeted IP or Group
– ISP researches from their perspective to determine traffic characteristics
associated with the attack
– ISP blocks the attack traffic from reaching the data center
– Service reestablished to the server / data center
• While the attack was mitigated, it took several steps and too long of time
to restore service

How APS and Cloud Signaling Help
• Certain high-bandwidth, volumetric attacks, pose a serious threat to

data center availability
– Usually originate from internet bots or large-scale botnets
– Such attacks are too large to mitigate at the data center’s premise
• Preferable to have APS signal to Cloud Signaling Server
– NOC/SOC engineer can manually “Activate” cloud mitigation
– Or set at a predetermined capacity threshold for more automated
protection
• APS signals the attack to the cloud signaling servers directly for a faster reaction
time
• Cloud Signaling reduces time to mitigate DDoS attacks
– Cloud Signaling is the process of requesting and receiving cloud-based
mitigation of volumetric attacks in real time from an upstream service
provider
– Helps to ensure the availability of your data center infrastructure

How Cloud Signaling Works
Required to handle
VOLUMETRIC attacks Subscriber Network Subscriber Network
that exceed the Data

Center’s uplink ArborNetworks SP
Internet Service Provider
bandwidth capacity & TMS-based

DDoS Service
SATURATION
Cloud Signaling Status
1. Service Operating Normally
the APS 2. Attack Begins and Initially

Blocked by the APS
Data Center Network

Firewall / IPS / WAF
3. Attack Grows Exceeding
Bandwidth
?
4. Cloud Mitigation
Public Facing Servers Requested
5. Service Reestablished!

Types of Cloud Mitigations
APS sends a request for the following cloud mitigation types:

• Global
– For all IPv4 prefixes on the network
– Manual or automatic requests supported
• Group
– For specific IPv4 protection groups
– Must be supported by mitigation provider
– Manually request
• Targeted Prefix
– For a targeted prefix(es)
– Must be supported by mitigation provider
– Manual or automatic requests supported
Note: APS does not support cloud signaling for IPv6 traffic

Cloud Signaling Considerations
• APS supports mitigation
Public Local Users

Arbor APS connectivity to only one
upstream provider at a time
– Signals to a single cloud service at
a time
– Supports up to 5 servers for
redundancy
Public Local Users

• Cloud service operators can
associate multiple Arbor APS
appliances
– 1:1
– N:1
Public Local Users
A • If multiple ISPs must choose
which provider to send Cloud
Signaling requests to
B – Each ISP must have it’s own Arbor APS

Additional Operational Considerations
• APS does not support CS for IPv6 traffic

• If APS running in FIPS mode then CS is not supported
• CIDR blocks that are mapped to the country codes may differ
between APS and your cloud service provider
• APS does not share the following items on the blacklists and
the whitelist:
– IPv6 hosts
– Domains on the inbound blacklist
– Items that are not assigned to All Protection Groups
– If more than 1,000 URLs – APS arbitrarily selects 1,000 URLs from the
blacklist

How APS Communicates with Cloud Signaling Servers
APS sends the following requests to the Cloud Signaling servers:

• Handshake – Determines if group mitigation (protection
groups) is supported
• Heartbeat – Verifies that communication channels are open
• Prefix Update – Sends list of the IPv4 prefixes to CS servers if
group mitigation or group and targeted mitigations supported

About Handshake Requests
• APS initiates a SSL-based handshake with each CS server(s)

– TCP port 443
– When Cloud Signaling is enabled (settings saved)
– Every 12 hours, automatically
• Uses three modes:
– Test Connection
– Normal Connect
– Disconnect
• Negotiates heartbeat parameters
• CS provider never initiates connection to APS

About Heartbeat Requests
• APS exchanges heartbeat messages with the CS servers every minute

– Contains replay checks
– Messages are encrypted and authenticated
• Signals mitigation state and mitigation statistics
– Contains flag to request mitigation / if mitigation is running
– Contains dropped bps and pps of running mitigation(s)
• Asynchronous heartbeats sent to UDP port 7550
– IANA-registered, “cloudsignal” as port name
– Avoids TCP congestion control
– Avoids TCP handshake delays in saturated networks
• Not a request-response protocol
– Each side proceeds independently
– Three heartbeats are sent to each CS server, uses first received
– Allows APS to signal upstream while flooded downstream

Prefix Updates
• The prefix update is initiated in the following instances:

– When the initial handshake determines that the CS provider supports
protection group-level mitigation
– When a protection group is added or deleted, or a protection group’s
prefix list is updated
• If CS provider supports protection group-level or IPv4
protected prefix mitigation:
– APS sends a list of the protected host prefixes to the CS Server
– Contains a list of the protected host prefixes that are associated with
each of your protection groups
• Uses HTTPS
– TCP port 443

CONFIGURING CLOUD SIGNALING
Setting up and Testing Cloud-based Signaling Services

Enabling Cloud Signaling
Important: If you enable Cloud

Signaling, you should configure
an NTP server to avoid clock-
related problems that might
interfere with communications
to the Cloud Signaling servers.
• “Connecton Error” indicated
if “system time is not
synchronized”

Required Cloud Signaling Settings
Enter required CS Server and APS ID information

provided by the CS Provider
• Configure up to 5 CS Servers
o Cloud Signaling will function if at least one
configured Cloud Signaling Server is reachable
• Enter URL if your CS provider has a
management portal
o Used to provide a link on the Tools menu
of the Cloud Signaling widget.

Viewing Cloud Signaling Server Status
Hovering over an alert

icon will display the alert

Using Arbor Cloud?
Select this box if using Arbor Cloud DDoS

Protection Servers
• Provides an option to enable automatic
whitelisting of proxy servers used for the Arbor
Cloud Service DNS-based traffic redirection

Service Provider Management Portal
URL for a Cloud service provider

management portal. This value will be
used to provide a link on the Tools menu
of the Cloud Signaling widget.

Share Inbound Blacklists and Inbound Whitelists
Select to share with the CS Server:

• Hosts on the inbound whitelist
• Hosts, countries, and URLs on the
inbound blacklist
Note: If your CS provider cannot resolve any

of the blacklisted country codes, you will
receive a message on the Summary page
• Will list the country codes that your CS
provider was unable to resolve

About Sharing Inbound Black/Whitelists
• APS sends the lists when it connects to the CS server

• APS resends the blacklists and whitelist to the CS server
when:
– APS connects to a new CS server
– You make changes to the CS configuration
– Changes are made to the either inbound black/whitelists
– APS automatically resends the lists every 12 hours
• Any time APS sends the blacklists and whitelist, the CS server
updates the lists

Automate Cloud-based Mitigation Requests
• Select to automate cloud-based mitigation

requests – Global Requests
• Specify a bps and/or pps threshold to indicate
the rate that triggers a global cloud signaling
request
o Rates apply to all of the inbound traffic on your
network
o Mitigation request sent even for protection
groups set to Inactive
• Select interval to specify the amount of time
over which to average the traffic to meet the
thresholds
o Automatic start delay timer is configurable from
5 seconds to 10 minutes
o Automatic stop delay timer is 10 minutes
(requests to end mitigation)

Targeted Destination Settings
Settings to be discussed
later

Configuring Proxy Server for the Handshake
• Select to enable the configuration of proxy

settings
• Add the proxy server IP address or hostname
and specify the port number
• If necessary, enter the user name and the
password required to access the proxy server
• Authentication can be selected if APS is unable
to detect it via the Automatic option
• Click Save to update configuration settings

Cloud Signaling Configured
SUCCESS!
• Connection Status displayed in banner
o “The connection to the Cloud Signaling server
was successful”
• Cloud mitigation widget displays when last
signal received

Cloud Signaling Handshake
• Connection error messages

displayed in banner
• Note: If handshake fails to run
successfully for 36 hours
heartbeats expire

GRE TUNNEL
Defining an Endpoint for Cloud-based Services

GRE Tunneling for Cloud Signaling
• APS can serve as a GRE Tunnel endpoint

– May be requested by the Cloud-based service provider
– APS provides a destination for cleaned traffic that the provider routes back to
the network
• APS does NOT re-inspect the traffic
– Assumes that the traffic received is cleaned

Configure GRE Tunneling for Cloud Signaling
• In order to terminate GRE tunnels, we need to configure a logical IP

interface on a Arbor APS mitigation interface pair.
– GRE tunnel endpoint must be a public IP
• Note: currently there

is no support for:
– IPv6 GRE tunnels
– IPv6 traffic
encapsulated inside
Cloud-based IPv4 tunnels
Signaling Service
GRE tunnel
destination
GRE
GRE EP
tunnel ext0 int0
source
Arbor APS
Pravail APS
GRE Tunnel Termination Notes
• GRE traffic is immediately forwarded to Next Hop:

– NOT inspected by protection groups
– Not available to Packet Capture
– Counted only for interfaces and throughput
• GRE over LACP is not supported
– Specify a GRE tunnel destination that is downstream of APS
• It is recommended to configure at least one post-GRE route of 0.0.0.0/0
• Next-hop for de-encapsulated traffic can be located on any interface pair
• Cannot specify a GRE tunnel destination if vAPS in Layer 3 mode
– Use the IP address of the external interface as the tunnel destination

GRE Tunnel Termination Configuration
• Configure static routing table to route traffic after de-

encapsulation
ext0 int0
Pravail APS

TARGETED CLOUD SIGNALING
Initiating a Targeted Cloud Service Request

Targeted Destination Cloud Signaling
If targeted prefixes is supported by Example

cloud signal provider Configuration
• Check box appears after you
enable Cloud Signaling
• Select check box to request
cloud-based mitigation for any
IPv4 prefixes on which traffic
exceeds one of the specified
thresholds
• Must also enable Top Sources
and Destinations

Automatic Targeted Cloud Signaling
APS starts a targeted cloud

mitigation when:
• Traffic exceeds the Global Cloud
Signal Threshold
• If one or more IPv4 prefixes
1
exceeds a targeted destination
threshold
• For a Targeted Cloud
2
mitigation, APS replaces all
prefixes in the global cloud
mitigation with the targeted IPv4
prefixes

Example 1: Targeted Destination Cloud Signaling
• APS detects a large 80Mbps SYN • Global Cloud Signaling Threshold

flood is not exceeded
– Nearly data center’s link capacity
– Attack continues for 5 minute
interval
– One IPv4 prefix, 100.0.0.20/32 is
receiving 45Mbps of traffic
– Exceeds the 25Mbps targeted
destination threshold
• APS does not automatically
request a cloud-based mitigation

Example 2: Targeted Destination Cloud Signaling
• Total traffic increases to • Attack now mitigated in cloud

120Mbps
– Exceeds Global Threshold
• APS now requests a targeted
Cloud Signaling request for prefix
100.0.0.20/32
– Adds the prefix to the list on
the Active Cloud Signaling
Requests page
• The Cloud Signaling server starts
the requested mitigation for
100.0.0.20/32
– APS creates a change log entry

Summary Page View of Targeted Cloud Signaling

Active Cloud Signaling Requests Page
Targeted Duration of Rate Automatic

Host(s) cloud-based which mitigations
mitigation triggered cannot be
mitigation manually
removed

Auto. Targeted Cloud Signaling Workflow
(5 of 5)
• After the attack traffic rate falls below the 25 Mbps threshold,
the mitigation stop
– APS removes the prefix from the Active Cloud Signaling Requests page
and creates a change log entry

MANUAL TARGETED CLOUD SIGNALING
Operator-initiated Cloud Service Requests
42
Active Cloud Signaling

Manual Configuration of Targeted Prefixes
• If you’ve configured destination traffic thresholds, APS also

can add additional IPv4 prefixes
• This manually configured targeted prefix will be added to the
mitigation request when traffic exceeds the defined threshold

Active Cloud Signaling Requests Page
• Lists all prefixes included in a targeted Cloud Signaling Request
• Global
mitigation may
be in process
• Empty list means

that there are no
active requests

Active Cloud Signaling Request Page Operation
Search for IPs in

the list
Click to remove
Add targeted IPs
• Prefixes that APS
• Use commas to separate multiple entries. adds automatically
will not have this
• You can enter one or more prefixes in the
icon and will remain
following forms:
active until the
– IP address, such as 192.0.2.2 automatic mitigation
– Use commas to separate multiple entries ends
– CIDR, such as 192.0.2.0/24
– Host name, such as myserver.mycompany.net

Manual Targeted Prefix Cloud Signaling
• Active Cloud Signaling Requests page displays all prefixes that are
included in a request for targeted Cloud Signaling
Pu ll
Do w
n
Automatic Manual Targeted

Targeted Prefix Prefix

Manual Targeted Cloud Signaling Request
• Results of manually adding a prefix:
Request State Action

No active requests APS sends a targeted prefix
request
Active targeted request APS adds the prefix to the
request
Active global request Global request must be
deactivated before APS can
send a targeted request*
NOTE: Arbor recommends that prefixes be added

to the Active Cloud Signaling Request page prior
to deactivating a global request.

CLOUD SIGNAL WIDGET
Monitoring Your Cloud-based Mitigation Status

Cloud Signaling Widget
• Automatically updates Cloud Signaling status

• Provides manual control of mitigation requests
Your network Cloud Signaling
Server
Status information
and error messages Action button
as appropriate
• Widget appears on both: Link to Configure

• Summary page Cloud Signaling page
• Configure Cloud Signaling Settings page

Tasks to Perform with the Cloud Signaling Widget
The widget allows you to perform the

following tasks:
• Request or stop a global cloud
mitigation
• Request or stop mitigation for a
specific IPv4 PG
– If the cloud signaling provider
supports PG-level mitigation
– Group Cloud Signaling widget
appears on the View Protection
Group Page
• Open the Configure Cloud Signaling
Settings page
• Open your cloud service provider’s
management portal
– If a portal is configured

Information in the Cloud Signaling Widget (1 of 2)
Status Available Tasks

The settings for connecting to Click Please Configure to go to the
the Cloud Signaling Server are Configure Cloud Signaling Settings
not configured. page.
Cloud Signaling is configured Click Enable to enable Cloud

but is not enabled. Signaling.
Cloud Signaling is in a normal Click Activate to initiate Cloud Signaling

state. manually.

Information in the Cloud Signaling Widget (2 of 2)
Status Available Actions

Cloud Signaling requests were To stop the mitigation requests, click
activated and are in progress Deactivate.
but mitigation has not started.
An error has occurred. Below If possible, take appropriate action to

the image, a message describes resolve the error.
the error.
Cloud mitigation is in progress. You can hover your mouse pointer over
the minigraph to view a larger version of
the graph.
To stop the mitigation requests, click
Deactivate.

Manually Requesting Cloud-based Mitigation
Activate button on widget starts a Deactivate button on widget stops a

manual mitigation manual mitigation

Mitigation Requested versus Mitigation Activated Status
Cloud signaled mitigation is Cloud signaled mitigation is

requested but not yet started running
Activation sync may take several minutes

Manually Deactivating Cloud-based Mitigation
• When you deactivate an active mitigation request, only the current request
is affected
– If you deactivate Cloud Signaling for a protection group, and its traffic
immediately exceeds the threshold again, APS re-activates Cloud Signaling for
that protection group
• When mitigation is requested manually, you must stop it manually
• When a mitigation is requested automatically, it stops automatically unless
you stop it manually first

Automatically Requesting Cloud-based Mitigation
• Configured Global Threshold

was exceeded
• APS initiates cloud

mitigation request to Cloud
Signaling provider network
Cloud mitigation because of traffic

above automatic threshold

Automatic Triggers – Cloud Provider Activated
• An event occurred in the Cloud

Provider network
– Cloud Signaling Server triggered
a mitigation
• Information about mitigation is
important to the APS
– Traffic statistics calculated into
total traffic seen for Automatic
Cloud Signaling trigger
Mitigation started on SP without

Cloud Signaling

Cloud Mitigation Blocked Traffic Graphs
• Widget mini-graph shows

amount of traffic blocked by
cloud mitigation
• Click on mini-graph for larger
graph in pop-in
– Reports traffic bps blocked to the
APS
– Includes bps blocked by Cloud
Mitigation in traffic total for
Automatic Cloud Signaling
Click on mini-graph Activation and Deactivation
decisions

Summary
In this unit you have learned about:

• How Arbor APS uses cloud signaling to request cloud-based
mitigations.
• When best to use cloud signaling for certain types of
volumetric DDoS attacks.
• The differences between the use of handshake, heartbeat,
and prefix update cloud signaling requests.
• Configuring your Arbor APS for cloud-based mitigation
services.
• Viewing the status and controling your cloud-based
mitigation.

Lab Exercises
• Configuring Cloud Signaling

– Lab 4
• Lab Review

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY

APS 6.0 Defend Unit 5 Cloud-Based Mitigation - 20180823

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

APS 6.0 Defend Unit 5 Cloud-Based Mitigation - 20180823

Загружено:

Авторское право:

Доступные форматы

Defending Against DDoS

Attacks using Arbor APS

Unit 5: Configuring Cloud Signaling

At the conclusion of this unit you will learn to:

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 2

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 3

When Enterprise or Data Center operators are under a service-disrupting

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 4

• Attack is confirmed by NOC/SOC engineer

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 5

• NOC/SOC engineer reaches out to their ISP to mitigate attack

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 6

• Certain high-bandwidth, volumetric attacks, pose a serious threat to

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 7

that exceed the Data

bandwidth capacity & TMS-based

the APS 2. Attack Begins and Initially

Data Center Network

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 8

APS sends a request for the following cloud mitigation types:

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 9

• APS supports mitigation

Public Local Users

Public Local Users

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 10

• APS does not support CS for IPv6 traffic

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 11

APS sends the following requests to the Cloud Signaling servers:

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 12

• APS initiates a SSL-based handshake with each CS server(s)

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 13

• APS exchanges heartbeat messages with the CS servers every minute

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 14

• The prefix update is initiated in the following instances:

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 15

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 16

Important: If you enable Cloud

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 17

Enter required CS Server and APS ID information

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 18

Hovering over an alert

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 19

Select this box if using Arbor Cloud DDoS

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 20

URL for a Cloud service provider

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 21

Select to share with the CS Server:

Note: If your CS provider cannot resolve any

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 22

• APS sends the lists when it connects to the CS server

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 23

• Select to automate cloud-based mitigation

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 24

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 25

• Select to enable the configuration of proxy

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 26

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 27

• Connection error messages

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 28

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 29

• APS can serve as a GRE Tunnel endpoint

©2018 ARBOR® CONFIDENTIAL & PROPRIETARY 30

• In order to terminate GRE tunnels, we need to configure a logical IP