SL DDOS Detection Mitigation User Course 1.16a R9.5.0.0

REV1.
16
NETSCOUT – Sightline/TMS
Chapters
1. Sightline Introduction
2. DDOS Overview
3. Host Anomaly Detection
4. Profiled Anomaly Detection
5. Interpreting Anomaly Alerts
6. Anomaly Mitigation
7. TMS Mitigation Workflow
8. Volumetric Attacks
9. State Exhausting Attacks
10. Application Layer Attacks
11. Enhancing Mitigations
NETSCOUT University
CONFIDENTIAL & PROPRIETARY
NETSCOUT - Technical Trainings

Terms and Conditions
Presentations, documents or other information

provided during this training are NetScout
Confidential Information and may not be disclosed
to any third party or used for any other purpose
than this training without the express written
permission of NetScout. For more details refer to
the Non-Disclosure Agreement (NDA) executed
between NetScout and the company that sent
trainees to take part in this training.
COPYRIGHT © 2022 NETSCOUT SYSTEMS, INC. | CONFIDENTIAL & PROPRIETARY 1
NETSCOUT University Sightline

CONFIDENTIAL & PROPRIETARY Introduction - 1
Sightline Introduction
Sightline/TMS
COPYRIGHT © 2022 NETSCOUT SYSTEMS, INC. | CONFIDENTIAL & PROPRIETARY

Unit Summary
• Data collection from the network
• Sightline Architecture Overview
• Sightline Traffic Visibility and Analysis

Capturing Network Traffic

Information
Unit 1: Sightline Introduction

Capturing Network Traffic Information

Sightline in a Nutshell
Pervasive Network Advanced Threat Service

Visibility Protection Enablement
Traffic Views Detect + Mitigate Monetize network

• Backbone DDoS Attacks & infrastructure and
• Peering/Transit edge
Cyber Threats technologies
• Cloud/Datacenter
before they impact Revenue generating
• Mobile network
• Customer services services and
competitive
5
differentiation
Sightline is a network-wide infrastructure security platform that measures and monitors traffic. You can
use it to scale your network and customer base. Sightline uses both flow and deep packet inspection
(DPI) technologies and provides macro- and micro-level visibility. This visibility allows you to identify
threats and improve the performance of your network.


Overview
FLOW BGP SNMP

Real time traffic Routing Interface names
information Information and statistics
Flow
BGP
SNMP
NETSCOUT – Arbor Sightline
Traffic and Routing Analysis (TRA)
Sightline uses flow records, SNMP, and BGP data to build network-wide relational models of traffic.
These models create both threshold- and behavioral-based traffic baselines. Sightline uses the learned
and configured traffic baselines to create alerts when the system observes abnormal traffic. Using this
information, you can create the appropriate mitigation to thwart an attack.
Flow Data
Key input to count and provide detail on network traffic
Enables DDoS Detection
BGP Routing Information
Provides reachability and data path information for
reporting
Allows peering analysis
Enables Mitigation capabilities via Blackhole injection,
Diversion of traffic, or Flow Spec
SNMP
Provide context for DDoS and Traffic Analysis
Tracks interface id, name, description and speed
Enables verification of flow derived traffic volumes


Flow Export in a Nutshell
Enabled per-interface
Inbound flow generation (recommended, no mixing)
Visibility requires both directions
Sampled Flow Export to protect the router
Flows
int 1 int 2
A B
Sightline uses flow records, SNMP, and BGP data to build network-wide relational models of traffic.
These models create both threshold- and behavioral-based traffic baselines. Sightline uses the learned
and configured traffic baselines to create alerts when the system observes abnormal traffic. Using this
information, you can create the appropriate mitigation to thwart an attack.


Router Flow Cache In: GigEthernet2/1
Proto: TCP
TOS: 0xB8 (184|EF)
SRC: 10.1.3.2:991
GigEthernet2/1, TCP, TOS=0x0 DST: 10.9.18.3:1053
10.5.5.1:3001 10.3.7.1:443 Start: 12:06:32.103
GigEthernet2/1, TCP, TOS=0x0 Out: TenEthernet0/0 inactivity Inactivity timeout
should be 15 sec
10.1.3.2:991 10.9.18.3:1053 Pkts: 41 or
GigEthernet2/1, ICMP, TOS=0xB8 Bytes: 12,532 active
timeout
10.1.1.1:0 10.3.2.1:0.0 Flags: Syn,Push,Ack Active timeout
GigEthernet2/1, ESP, TOS=0x0
10.2.3.4 10.1.1.1
Last: 12:07:12.916 should be 60 sec
GigEthernet2/1, UDP, TOS=0x0 Prioritize UDP
10.4.4.4:12345 10.1.2.3:53
flow traffic

COPYRIGHT © 2022 NETSCOUT SYSTEMS, INC. | CONFIDENTIAL & PROPRIETARY 8 Traffic and Routing Analysis (TRA)


Super Flow Information
Sightline applies a longest match of source IP & destination IP from the flow with
the prefixes in BGP routing table
11 Fields
‘Classical’ Flow Information
Src IP Dst IP Src Port Dst Port Proto Input Intf Output Intf ToS Flags Bytes pkts
Prefix Next Hop AS path Community Traffic to/from a Managed Objects can
BGP Information also be identified by correlating Flow
and BGP Information
19 Fields
‘Super’ Flow Information
Source Destination Src Dst Proto In Out ToS Flags Bytes pkts
IP Prefix NextHop ASPath Com IP Prefix NextHop ASPath Com Port Port Intf Intf
All other attributes are matched based on the prefix to source/destination IP match. For instance, a flow will match
a prefix and therefore that same flow will match that prefix’s AS Path, next-hops, and communities as well.


BGP Peering
Reachability
Peering Mitigation
and Path
analysis capabilities
Information
• Where is traffic • How can I save • BGP Blackhole

coming from? money? injection
• Where is the traffic • How can I prove • BGP route-based
going to? Services or Customer traffic diversion for
Experiences? TMS
• Which peers are
involved? • BGP Flow Spec traffic
filtering or traffic
• Is it Transit Traffic? diversion for TMS
Flow spec is used to convey Access Control List information via BGP. Actions on the router include both traffic
filtering (or policing) and traffic diversion.

Scalable Architecture

Appliance Types and Roles

Provider A Subscriber
Networks traffic analysis using Flow, BGP and SNMP
Edge
Threat Mitigation System (TMS)

Surgical Attack Mitigation Provider B
Data Storage (DS) TRA TRA Scrubbing

Center
Increase the number of Managed Objects Provider C
ASI Collector (AS) Backbone TMS TMS
Receive ASI DNSFlow messages from ISNG DS
(Leader)
(Leader)
User Interface (UI) AS
UI TRA Customer &
Hosting Edge
Central GUI, takes on Leader or Backup (Backup Leader) TRA
Leader Role
UI
Central Console
Sightline/TMS can be deployed in any network from small, single-site up to any global network (~5,000
routers / 200,000 interfaces)

Sightline Deployment Size: Small est
TRA*
TRA (Leader)
TRA
Use a hybrid TRA/Leader* appliances as a single point of access for managing

Sightline and Managed Services access
Small Deployments are considered everything that is less or equal to 5 Sightline and TMS appliance.
If more appliances are required, then this design will not work as the management duties will be to much for a
hybrid TRA that is the Leader and also has to analyze the received flow information.
Both functionalities must be separated. There is also only one way to access this solution, in case that would fail,
the other Appliance keep to operate but there is no way to monitor or control these till the Leader functionality is
restored.

Sightline Deployment Size: Full-Scale
TRA
TRA
UI
TRA
UI
(Leader)
(Backup Leader)
Dedicated UI appliances for Leader & Backup Leader roles and other UI’s can
serf as Managed Service access or Cloud Signaling endpoints
Highly Scalable solution including Leader Redundancy, with such a design the Deployment can scale up to:
TRA 200x
DS 20x
UI 20x
TMS 100x (Software + Hardware TMS)

Physical versus Virtual Appliance
Sightline SP 7000 Sightline SP 7500 Sightline Virtual
*
• Up to 240.000 fps • Up to 240.000 fps
• 100 data sources (i.e., routers) • 100 data sources (i.e., routers) • Up to 200.000 fps (depends on
host hardware)
• 20.000 monitored interfaces • 20.000 monitored interfaces • Documented performance
• 1GB or 10GB interfaces • 1GB or 10GB interfaces benchmarks
• AC or DC power • AC or DC power
• 2 RU • 2 RU
A deployment can have any mix of

physical and virtual appliances
COPYRIGHT © 2022 NETSCOUT SYSTEMS, INC. | CONFIDENTIAL & PROPRIETARY 15 *only till Release 9.2
You can add virtual TMS (vTMS) instances to your flexible-licensed Sightline/TMS deployment. TMS-VMs
can complement physical TMS models in a hybrid physical/virtual deployment. They can also perform TMS
mitigations in all-virtual Sightline/TMS deployments.
You can configure TMS-VMs in your deployment if the Sightline flexible license includes one or more “flexible-
licensed capacities” for TMS-VMs bandwidth. Licensed capacities for TMS-VMs bandwidth are purchased
separately and can be temporary or permanent. Each capacity that you add increases the pool of available
bandwidth for TMS-VMs.

Scalable Architecture 40 Gbps

Mitigation Capacity
10 Gbps
TMS 2600 TMS 2800 TMS 8100
1 – 10 Gbps @ 10 – 40 Gbps @ 1,5 – 40 Gbps @

~10 Mpps ~30 Mpps ~29 Mpps
1 Gbps 1 Gbps 1 Gbps

10 Gbps 10 Gbps 10 Gbps
2 RU 2 RU 2 RU
Data Center, Access Distributed Scrubbing Centers,

Networks, PE Edge Backbone/Transit Peering Edge

400 Gbps
Mitigation Capacity
60 Gbps TMS HD1000

vDDoS
10 – 60 Gbps @ 20 – 400 Gbps

~28 Mpps up to 198 Mpps
via Backplane 10 Gbps

100 Gbps
1 Slot ASR9K 2 RU
Central Scrubbing Center, Large Backbone/Transit

Peering Edge
Release Notes Sightline 9.1
TMS HD1000 (4x100G + 8x10G) appliance limits
Diverting or inline traffic with 20 Gbps PPMs1:

1 x PPM 20 Gbps 14 Mpps
Diverting or inline traffic with 50 Gbps PPMs1:

Traffic Visibility and Analysis


Sightline Visibility
Provides usable information and data trends

Which applications?
Where is it going to?
Top customer usage?
How much traffic? Which interfaces are most used?
What is the busiest time? What is the IPv6 usage?
Where is it coming from? How much usage per peer?


Predefined Reports
• 350+ predefined reports
• Fast Query-Results
• Granularity up from 5-minute
intervals
• Data Trends up to 3 years


Monitoring defined Resources
Real time traffic correlation Protected assets

to detect anomalies
General Infrastructure
Traffic Rate Thresholds

Services Applications
‘Baselines’ on previous
network pattern Hosts or Application
Servers Infrastructure

Anomaly Detection and Mitigation


Alert Generation
Sightline Alerts
1. Detection Identify Attack Pattern
Real time discovery of anomalous traffic
Determine Impact
– Traffic deviates from acceptable use (Host)
– Traffic exceeding normal levels (Profiled) Enables to choose best
– Traffic exceeding configured threshold mitigation option
2. Classification
Helps to set priorities and classifies automatically:
– Host (Traffic deviates from acceptable use)
– Profiled (Traffic exceeding normal levels)
Severity Levels


Alert Detection and Traffic Diversion
INTERNET
NETSCOUT – TMS
Threat Mitigation System
Attack
Alerting
TMS Mitigation
Flow



Mitigation Capabilities
TMS
Surgical mitigation for
critical resources
X
BGP BLACKHOLE BGP FLOWSPEC

Drop traffic in Drop, rate or mark
the network traffic in the network
Countermeasures enable granular and precise attack mitigation. Choose the countermeasure(s) that are
effective against the attack vector(s) your resource is experiencing. Attacks may be effectively blocked by
a single countermeasure or may require a combination of several of them.
Countermeasures are divided into two categories: Per-packet and Event-driven.

Per-packet countermeasures are run against every packet during an active mitigation (provided the
countermeasure is enabled). After the per-packet countermeasures, then any surviving packets are
forwarded on to the event-driven countermeasures, which are more specialized and only are run if the
packet matches the conditions of the countermeasure.

AIF - ATLAS Intelligence Feed

AIF - ATLAS Intelligence Feed

Feed Elements
ATLAS Intelligence Feed
DDoS TMS DDoS Malware OTT

Reputation Templates Payload IoCs Content
Malware IoCs Identify and report

TMS mitigation DDoS Payload
Block known enable Sightline to OTT traffic by
templates Signatures to
active sources of detect malware Content Provider
providing pre- detect and block
inbound DDoS communication; using Flow and
configured ASERT known DDoS
attack traffic special focus on DNS telemetry
DDoS strategies HTTP attack traffic
botnet C2
AIF for TMS AIF for Sightline
DDoS Intelligence Internet & Threat Intelligence
Countermeasures enable granular and precise attack mitigation. Choose the countermeasure(s) that are
effective against the attack vector(s) your resource is experiencing. Attacks may be effectively blocked by
a single countermeasure or may require a combination of several of them.
Countermeasures are divided into two categories: Per-packet and Event-driven.

Per-packet countermeasures are run against every packet during an active mitigation (provided the
countermeasure is enabled). After the per-packet countermeasures, then any surviving packets are
forwarded on to the event-driven countermeasures, which are more specialized and only are run if the
packet matches the conditions of the countermeasure.

Knowledge Check
Sightline Introduction
Q1: What type of Appliance are supported by Sightline and TMS?
a) Only Virtual Appliances
b) Only Hardware Appliance
c) Any mixture of Hardware and Virtual Appliances
Q2: Which protocol allows Sightline to gain traffic visibility

a) Flow Export
b) SNMP
c) Live packet capturing
Solution: Q1: c Q2: a

Online Lab Access

Lab Exercise
• Online Lab Access: https://portal.ne.netscout.com/

• Environment: Sightline Visibility
• Credentials: Provided by the Instructor Step1
• Time to Complete: 30 minutes
Step2
• Lab Objectives: First Steps
– Introduction to Sightline’s user interface

• My Sightline page
• Help menu
• Commonly used tools/screens

In this Unit, we learned about:

• Data collection from the network
• Sightline Architecture Overview
• Sightline Traffic Visibility and Analysis


DDOS Overview
Sightline/TMS
NETSCOUT University
CONFIDENTIAL & PROPRIETARY DDOS Overview - 1
Unit Summary
• Describe and understand DDOS Threats
• Sightline DOS Alerts and its representation
NETSCOUT University
Impact of DDOS Attacks
Unit 2: DDOS Overview
NETSCOUT University

Who’s Behind it?
Organized Crime
Ransom, blackmail, extortion, etc.
Hacktivists
Politics, ideology, religion, etc.
Gamers
To win, as revenge for losing, etc.
Students
Canceling exams, manipulating registration, etc.
Booter / Stresser Services

Demonstrations of DDoS capability
NETSCOUT University

DDoS Attacks can be complex…
• DDoS attacks are often multi-

vector attacks
• DDoS attacks often change
during the attack

* WISR 2020H2
NETSCOUT University

Easy to perform…
DDoS For Hire services are common and affordable
NETSCOUT University

Business Impact
Operational
Costs
Corporate Revenue
Image Impact
Service Level
Agreement
Penalty
The consequences of being unprepared to mitigate a DDoS attack can be crippling to a business as it
isn't just about possible revenue loss – it's about erosion in trust, brand value and reputation. As DDoS
attacks continue to become both more frequent and complex, it's important that organizations adopt the
right mix of people, processes and technologies to fight these attacks and quickly eliminate downtime. A
critical aspect in getting this right is ensuring resources are in place to both detect and mitigate attacks.
Operational Costs
SLA infractions, Engineering resources, Increased transit cost, Increased network cost, Supply chain
disruption, Clean up costs, Personnel turnover
Revenue Impact
Loss of on-line sales, Inability to process transactions, Customer attrition, Opportunity cost due to loss of
communications
Corporate Image
Reputation loss, Stock value reduction
NETSCOUT University

DDOS Attack Vectors
Which DDoS Attacks types are commonly seen?
Volumetric Attack State Attack Application Attack
Layer 7 - Application Layer 7 - Application Layer 7 - Application

Layer 6 - Presentation Layer 6 - Presentation Layer 6 - Presentation
Layer 5 - Session Layer 5 - Session Layer 5 - Session
Layer 4 - Transport Layer 4 - Transport Layer 4 - Transport
Layer 3 - Network Layer 3 - Network Layer 3 - Network
Layer 2 – Data Link Layer 2 – Data Link Layer 2 – Data Link
Layer 1 – Physical Layer 1 – Physical Layer 1 – Physical
OSI-Model OSI-Model OSI-Model

There was a time when Distributed Denial of Service (DDoS) attacks threatened business operations by
simply “flooding the network pipe” with traffic congestion. By overwhelming the connection to the web
server, these high-bandwidth “volumetric” attacks can take a web property offline. That all changed in
2010, when there was a dramatic shift in DDoS thanks to attackers who developed more sophisticated
and targeted tools. Today, the application-layer is the most popular target for attacks, specifically Web
services. These “application-layer attacks” generally consume less bandwidth and are stealthier in nature
when compared to volumetric attacks, which makes them harder to detect. What’s more, they can have a
catastrophic impact on business availability by threatening critical HTTP, DNS, VoIP or SMTP
applications and services. DDoS attack vectors tend to fall into one of three broad categories:
• Volumetric Attacks
• State Exhaustion Attacks
• Application-layer Attacks
NETSCOUT University

Example: Volumetric Attack – DNS Amplification
Attacker
Resolver
1. Attacker uses source IP of the Victim to spoof

query which is sent to Resolver
Victim
2. Resolver responds to 54-byte query and
elicits a ~4200-byte response to the Victim
NETSCOUT University

Example: State Exhaustion Attack – TCP SYN Flood
The SYN flood attack exploits the TCP three-way handshake that establishes a connection between a
client and a server. During a SYN flood attack, the attacker sends a large number of SYN packets.
However, it does not return the final ACK responses and the handshake is never completed.
The server waits for the ACK responses until it times out. A sufficiently large number of half-open
connections can consume all of the server’s resources and prevent the server from accepting clean
traffic.
Both Spoofed SYN Flood Prevention and TCP SYN Flood Detection (next pages) protect against SYN
flood attacks. However, while Spoofed SYN Flood Prevention can protect against highly distributed
attacks, TCP SYN Flood Detection uses rate thresholds to detect high rate, undistributed SYN flood
attacks.
NETSCOUT University

Example: Application Attack – HTTP SlowLoris / PyLoris
• Single attacker can take down a

web server GET http://www.google.com/ HTTP/1.1
• Exploits design flaws in the HTTP Host: www.google.com
Connection: keep-alive
– Small volumes of HTTP traffic User-Agent: Mozilla/5.0
– Abuses handling of HTTP request X-a: b
headers ssslooowly… X-a: b
– Affected servers will keep these X-a: b
connections open, filling their X-a: b
concurrent connection pool X-a: b
– Eventually denies additional …
connection attempts from clients
Show how easy it is to Download a Slowloris attack tool – Search “Slowloris Github” on Google
The Slowloris attack exhausts connection resources by sending small chunks of HTTP request headers to
the target web server too slowly. By design, the web server must wait for all the header chunks to arrive
or time out the HTTP request. The attack client sends each small HTTP header chunk just before the
server’s HTTP request time out expires.
When many malicious hosts launch simultaneous Slowloris attacks from a botnet, all the available
connections to a target server are opened at once. As a result, the server cannot handle legitimate HTTP
requests.
NETSCOUT University

DDOS Attack Surface
Attack surface is the part of a network or host that is exposed

to the internet and vulnerable to DDoS attacks
☣General Infrastructure (routers, switches, load balancers, etc.)

☣Application specific infrastructure
☣Control Plane / Management Network (if not isolated)
☣Network Links
☣Hosts/Servers
☣IP Protocols (TCP, UDP, ICMP, etc.)
☣Applications (DNS, Web, VoIP, etc.)
Attack surface continues to expand

The DDoS attack surface describes all aspects of network infrastructure, servers, protocols and services
that are vulnerable to DDoS attacks. As new equipment, protocols and services are introduced into
networks, the vulnerable attack surface for DDoS is expanded. This presents a significant challenge for
network operators. Botnet-driven volumetric and application-layer DDoS attacks continue to be the most
significant problems facing operators. This year’s report also reveals attackers are targeting the
infrastructure itself, specifically DNS, VoIP and IPv6.
Network operators are facing a global Internet insurgency driven by the ubiquity of botnets. This has led to
rapidly escalating DDoS attack size, frequency and sophistication. Adding to the challenges facing
operators is the increasing number of attack vectors, including applications and services, not to mention
the proliferation of mobile devices.
NETSCOUT University
DOS Alert Activity
NETSCOUT University
DOS Alert Activity

Searching DOS Alerts
Alerts > DOS

Use the Search bar to search for active or recent alerts
Keyword based Sort by any Wizard based
search heading search
Complete list of Search options is available in the online Help

You can use the Search bar to search for ongoing and recent alerts. When using the Search bar, you can
enter search values with or without keywords. If you do not enter a keyword, then Sightline attempts to
match your search entry to elements visible on the page from which you are searching, including alert ID
(if you entered a positive integer), alert class, alert type, severity level, and resource.
NETSCOUT University
DOS Alert Activity

Searching DOS Alerts - Alert Search Wizard
• Flexible filtering
• Quickly locate multiple
specific criteria's
• Not offering all available
search criteria’s
• Generates a search string
An alternative to using the Search bar is the Search Wizard. After selecting the desired values on the
screen, click Search. The search string according to the criteria given will be automatically filled out on
the alerts screen in the Search bar.
NETSCOUT University
DOS Alert Activity

Searching DOS Alerts – Keyword based search
• Space between search values = AND

• Comma between search values = OR
• Searches without keywords will attempt matches on: Alert ID, Alert
Type, Severity Level, Status and Resource
• Online Help “Acceptable search keywords and values for alerts”
• Examples
➢ ro: for router
➢ prefix: for a CIDR
You can use the Search bar to search for ongoing and recent alerts. When using the Search bar, you can
enter search values with or without keywords. If you do not enter a keyword, then Sightline attempts to
match your search entry to elements visible on the page from which you are searching, including alert ID
(if you entered a positive integer), alert class, alert type, severity level, and resource.
Note: A resource is a service, fingerprint, or managed object.
• You can type AND or insert a space between search values to enter an AND statement.
• You can type OR or insert a comma between search values to enter an OR statement.
• You can use quotation marks (“) to combine words in searches. For example, to search for an
annotation with “This attack is crippling,” you could enter ann:“is crippling”.
Each line represents a different anomaly. Summaries provide a high level view of what triggered the
anomaly, what is affected, start time, and its assigned classification.
NETSCOUT University
DOS Alert Activity

Searching DOS Alerts – Examples
• Search by Type & Managed Object → ac:DOS mo:used.cars.org
• Search by configured Tag (≥ 9.3) → ac:DOS tag:car-dealers

(Tag itself is not shown on the alert page)
• Search by Type & Attacked Prefix → ac:DOS prefix:3.3.3.0/24
NETSCOUT University
DOS Alert Activity

DOS Alert Summaries
x.x.x.198
Anomaly IDs
are unique Graph is visual Severity Resource that Classification
Click on ID depiction of Percentage is affected and Annotations
link for details alert’s activity and Impact
Alternating highlighted sections represent different anomalies. Summaries provide a high level view of
what triggered the anomaly, what is affected, timelines for the anomaly, and its directionality.
ID: A unique identifying number (sequentially assigned by Sightline)
Graph: Visual depiction of a DoS alert’s ongoing activity:
• Host alerts could be either the network boundary, MO boundary, or traffic through a specific router,
depending on where the alert triggered
• Profiled router alert minigraphs show the impact of traffic through a specific router
• Profiled network alert minigraphs could show the impact of traffic at the network boundary or the MO
boundary
Note: DoS alerts may not always have minigraphs
Importance: The severity level of the anomaly (high, medium and low) based on user/system defined
thresholds. The severity percentage is the highest single minute ratio of alert traffic to expected traffic for
any single (router | interface) over the life of the alert (for profiled and misuse anomalies). The impact is
the largest single minute sum of alert traffic traversing the boundary interfaces or router.
NETSCOUT University
DOS Alert Activity

Multiple Host Misuse Types
Multiple Misuse Types for the same targeted IP of a Managed Object

will be aggregated into a single alert
Note: Sightline can potentially generate an alert that has more than 10 different misuse types because of the number
of Misuse Types that are tracked. However, the Alert Traffic graph currently supports only up to 10 different
misuse types. If more than 10 misuse types are triggered, all of the triggered misuse types are listed under Misuse
Types in the alert information that appears above the graph. However, the graph with its colored selectors displays
only the first 10 misuse types that were triggered.
NETSCOUT University
Managed Objects
NETSCOUT University
Managed Objects
Concept
In an enterprise or provider network the volume of

flow information is enormous
• Flow used to calculate baselines, monitor resources, generate alerts and more
• Impossible to keep detailed information on everything
• With Sightline you define the resources you want to protect and monitor
Flow
Leader
TRA
Managed Objects
Flow
TRA
NETSCOUT University
Managed Objects
Definition
• Defines a subset of the network traffic

– 100.218.128.0/17
– AS 123 or community 1001:52
– FCAP expression, e.g., protocol TCP dst port 80
• Can be internal or external to the network
– Internal → Customer, Datacenter, POP, …
– External → Peering AS, Yahoo, Google, …
• Each managed object belongs to a family type
– Family type describes the object’s business relationship
– Reports, alerts, and other features are based on the object family type
NETSCOUT University
Managed Objects
Family Types
• Customer
Specific customer or important resources/services you want to
monitor, report or provide Managed-Services to
• Peer
Upstream or Downstream BGP peers you want to monitor and
report on
• Profile
Typically, resources used as reference points within reports (Content,
Web server, etc.)
• VPN
Used to monitor site-to-site traffic for MPLS/VPN-based customer
NETSCOUT University
Managed Objects Peer

Match: PEER-ASN
Managed Object Example
BGP Peer A BGP Peer B
Profile or
Customer TRA
Match: CIDR Group TRA
Web Servers
DNS Leader
172.16.1.1
TRA
Customer
Match: CIDR Blocks
Customer
Match: PEER-ASN
Customer A Customer B
ASN 65001 Prefix 192.168.0.0/24
NETSCOUT University
Knowledge Check
DOS Overview
Q1: What could be a potential target of a DOS Q3: Who could be behind a DOS Attack?
Attack?
a) Script Kiddies
a) Network
b) Blackmailer
b) Server
c) IT-Experts
c) Users
d) Anyone
d) All of the above
Q2: What are the common OSI Layers used in
DOS Attacks?
a) Data Link
b) Network
c) Transport
d) Application
Solution: Q1: d Q2: b,c,d Q3: d
NETSCOUT University
Lab Exercise


Step2
• Lab Objectives: DDOS Overview

• Search and find alerts
NETSCOUT University

• Describe and understand DDOS Threats
• Sightline DOS Alerts and its representation
NETSCOUT University
NETSCOUT University
Host Anomaly Detection
Sightline/TMS
NETSCOUT University Host Anomaly

CONFIDENTIAL & PROPRIETARY Detection - 1
Unit Summary
• Anomaly Detection & Classification
• Understand Host Detection and its different misuse types available

Anomaly Detection & Classification
Unit 3: Host Anomaly Detection


Infrastructure Security
Sightline functions as a network-wide anomaly

detection system
• Anomaly Definition
An event or condition in the network that is identified as a statistical
abnormality when compared to typical traffic patterns gleaned from
previously collected profiles and baselines or an event and condition that does
not adhere to normal Internet use practices
• Anomaly Causes
DDoS attack, Flash Crowd, topology change, new customer, …


Anomaly Detection Types
HOST PROFILED PROFILED

DETECTION ROUTER NETWORK
Concept Concept Concept
Traffic of a certain Deviations from Deviations from

misuse type directed normal (expected) normal (expected)
towards an individual traffic levels for a traffic levels at the
host through any Managed Object on Managed Object
monitored router a per-router basis boundary
exceeds the
configured threshold


Anomaly Detection Setup
1) Create a Managed Object to identify a resource

• Network address ranges or aggregates
• Customers
• Peers
• Strategic Resources (DNS, VOIP gateways, etc.)
2) Enable anomaly detection methods
ON Host Detection ON Profiled Detection

DEFAULT
DEFAULT
Uses static rate thresholds Calculate baselines to
to identify misuse determine anomalous
OFF OFF
levels of traffic to/from a
Managed Object
Managed objects are administrator-configured

resources that Sightline uses to sort, filter, and store
traffic and flow data.


Alert Generation – Two Step Process
1. Detection
Real time discovery of anomalous traffic
• Traffic that deviates from acceptable use (Host)
• Traffic exceeding normal levels (Profiled Router or Network)
• Traffic exceeding a configured threshold (Threshold Alert, Fingerprint)
2. Classification
Helps to set priorities and classifies automatically
• Host (static misuse thresholds)
• Profiled Router or Profiled Network (historical baselines)
Severity Levels
Once an alert has been detected & classified, its severity can only go up
Alert Severity Never Goes Down

Host Detection
Unit 3: Host Anomaly Detection

Host Detection
Characteristics
Default Alerting
HOST Enabled Traffic on a router for a host that
DETECTION exceeds a Misuse threshold for
Detection a specified amount of time
Static thresholds, measured in
Concept bps and/or pps
Fast Flood
Measure traffic that matches a High alert only
misuse type towards a single Exclusion Trigger: traffic exceeds high alert
host (/32 or /128) • With ≥9.3 you can exclude threshold within the first minute
source or destination IP of detection (disabled by default)
Direction addresses from alert
Towards the victim host detection
• With ≥9.3.5 you can specify
MO either all routers or only
boundary routers to be used
With and without a MO for host alerting

Host Detection
Misuse Signatures PPS Based PPS & BPS Based
• mDNS
• L2TP
• DNS • Chargen Amplification
DNS • ICMP • CLDAP Amplification
• IP Fragment • DNS Amplification
IP Fragment • IP Private • memcached Amplification
… • IPv4 Protocol 0 • MS SQL RS Amplification
• TCP Null • SSDP Amplification
Chargen Amplification • TCP RST • TCP SYN/ACK Amplification
• TCP SYN • SNMP Amplification
• UDP • NTP Amplification
• NetBIOS
• RIPv1
• rpcbind
Additional 5 custom
Misuse Types
Some details about some Misuse Types:

• chargen Amplification: UDP and source port 19
• DNS Amplification: UDP and source port 53
• MS SQL RS Amplification: UDP and source port 1434
• NTP Amplification: UDP with source port 123 and large (invalid) packet sizes
• SNMP Amplification: UDP with source port 161 and/or 162
• SSDP Amplification: UDP with source port 1900
• L2TP: UDP with source port 1701 and packet size 500-65535 bytes
• mDNS: UDP with source port 5353
• NetBIOS: UDP with source port 137 or 138
• RIP v1: UDP and source port 520
• rpcbind: UDP with source port 111

Host Detection
Assigning Detection Settings
Default Host
Detection
Settings
Shared Host
Detection
Settings
Custom Host
Detection
Settings
Shared Host Detection Settings can be found at

COPYRIGHT © 2022 NETSCOUT SYSTEMS, INC. | CONFIDENTIAL & PROPRIETARY 11 Administration > Detection > Shared Host Detection Settings
Host Detection Settings are either inherited by the global system default, overwritten by assigning a shared
detection profile that is commonly used for multiple Managed Object at the same time, or a unique setting is
applied on a per Managed Object base

Host Detection
Detection Example
Scenario:
• There is a DDoS attack
directed toward a single
host in Customer A
TRA
TRA
• The MO for Customer A
Web Servers
Leader
has Host Detection
DNS
enabled
TRA
• All or selected ≥9.3.5 routers
are considered for Host
Detection
Customer A
Customer B

Host Detection
Detection Example (Cont.)
BGP Peer A
1) Attack traffic exceeds
BGP Peer B one or more misuse
type thresholds for
longer than the
configured duration
TRA 2) TRA notifies Leader
TRA
Web Servers
Leader
3) Leader queries all
DNS
TRAs for information
regarding the traffic to
TRA
that host
4) TRAs that see
corresponding traffic
Customer A send info to the
Customer B Leader
Process:
1) Each collector keeps traffic counts per router for each misuse type for each host that has that misuse type
configured.
2) Every minute the collector checks the traffic counts for each host. If the count exceeds the configured trigger rate
from any router it is monitoring and the excessive traffic persists longer than the configured latency, the TRA alerts
the Leader.
3) At this time, refinement is started for this alert. The Leader queries all of the TRAs for information about the
affected host’s traffic.
4) The leader classifies the alert severity and inserts it in the alert database.

Host Detection Leader builds an alert from

Detection Example (Cont.) the details provided by the
TRAs. All routers that saw
BGP Peer A
attack traffic will be listed in
BGP Peer B
the alert details:
TRA
TRA
Web Servers
DNS Leader
TRA
Customer A
Customer B
Once the Leader has been notified of the Anomaly, it collects impact data regarding the anomaly from all of the
Collectors. In the Summary tab of the alert, the traffic seen by each monitored routers is reported and can be
selected individually.

Host Detection
Where Detection Occurs
• For Host Detection
anomalies, misuse traffic is
BGP Peer A BGP Peer B tracked at all monitored
routers* in the network
• Managed Object boundary
does not factor into where
TRA
TRA the traffic is detected
Web Servers
DNS Leader • However, well-defined
boundaries will help fill in
TRA anomaly details in the alerts
and are essential for valid
traffic reports
Customer A
Customer B
Host detection monitors the IPv4 and IPv6 traffic to a host on all monitored routers. As mentioned earlier,
host detection can be configured to monitor the traffic of a customer, peer, or profile managed object or
the traffic of a service. If excessive traffic is detected for multiple misuse types that are enabled, then a
single alert is created instead of separate alerts for each misuse type.

Host Detection
Anomaly Classification
Traffic Volume
High Severity Rate

Middle Line
Trigger Rate
Time
Host Anomalies are detected based on static thresholds

• Trigger Rate – Threshold for Low severity alerts
• Middle Line – 75% of High Sev. Rate, differentiate between Low and Medium severity, not configurable
• High Severity Rate – Threshold for High severity alerts.
Trigger Rate – Rate that must be exceeded in order to generate a Host anomaly
Host Detection Start Latency – Defines how long deviant traffic has to be above the Trigger Rate before an
anomaly is detected
Host Detection End Latency – Determines when an anomaly alert ends after deviant traffic falls below Trigger
Rate
Middle Line – Calculated value @ 75% of the way between Trigger Rate and High Severity Rate
High Severity Rate – Traffic rate that must be exceeded for a Host anomaly to qualify as high severity
Severity Duration – Length of time the traffic has to remain above the High Severity Rate before the alert is
classified as high severity
Fast Flood Detection – If enabled, can trigger a host alert faster than the Severity Duration when anomaly rate is
excessively large initially

Host Detection simplified

representation
Start Latency and Severity Duration
Traffic Volume Severity Duration
Host Detection
Start Latency
High Severity Rate

Middle Line
Trigger Rate
Not relevant
Time
Latency checking prevents traffic spikes from generating alerts

• Host Detection Start Latency – Time the traffic must remain above the Trigger Rate before an
alert is generated
• Severity Duration – Time the traffic must remain above the High Severity Rate before the alert is
escalated to high severity
Host Detection Latency – When a host alert is possible, Sightline waits the amount of time specified in
this field (1 to 20, in minutes) before generating an alert. This defaults to 2 minutes.
Severity Duration – defines how many seconds the traffic level of an alert has to persist above the
severity rate configured for the managed object before the alert is escalated to high severity. This setting
prevents short, transient traffic spikes from creating high severity alerts on the system. The default value
is 300 seconds. You can enable and specify trigger and severity rates for each type of misuse signature.


representation
Severity: Low Alert
Severity Duration
Traffic Volume Host Detection Host Detection
Start Latency End Latency
An anomaly is no
High Severity Rate longer considered
Middle Line active once the
Trigger Rate traffic rate drops
below the Trigger
Low severity Severity stays Alert Rate for the Host
Alert generated as Low Detection End
ends
Latency
Time
1) Traffic exceeds Trigger Rate for longer than Host Detection Start Latency
2) Traffic does not stay above Middle Line for the Severity Duration
3) Traffic does not reach High Severity Rate
An alert has a low severity level if the following conditions are true:
• Traffic stays above the trigger rate for longer than the host detection start latency period.
• Traffic does not stay above the middle line for the severity duration.
• Traffic never goes above the high severity rate.


representation
Severity: Medium Alert
Severity Duration
Traffic Volume Host Detection 3 min 3 min 3 min 3 min
Start Latency
2 min
Settings
High Severity Rate
Host Detection 2 min.
Middle Line Start Latency
>1 min Severity
Trigger Rate 3 min.
Duration
Severity set to Medium
(if > 1 min. & < Severity Duration) Severity of
Low severity Medium
Alert generated
Time
2) Traffic exceeds Middle Line for the Severity Duration
-or-
Traffic exceeds High Severity Rate for 1 min. but less than Severity Duration
Traffic ever goes above the High Severity Rate for one minute but does not stay above High Severity
Rate for the entire Severity Duration (unless the Severity Duration is set for 1 minute)


representation
Severity: High Alert
Severity Duration
Traffic Volume Host Detection 4 min 4 min 4 min
Start Latency
2 min
Settings
High Severity Rate
Host Detection 2 min.
Middle Line Start Latency
>1 min
Trigger Rate Severity
4 min.
Duration
Severity set to Medium Severity set
(if > 1 min. & < Severity Duration) to High
Low severity
Alert generated
Time
2) Traffic exceeds High Severity Rate and stays above for the Severity Duration
An alert has a high severity level if the following conditions are true:
• Traffic stays above the trigger rate for longer than the host detection start latency period.
• Traffic goes above the high severity rate.
• Traffic stays above the high severity rate for the severity duration.

Host Detection
Fast Flood Detection
Quickly alert when a host initially receives very high volume of attack traffic
☞ Fast Flood evaluation occurs every second
☞ Start Latency is ignored when misuse traffic exceeds the High Severity Rate
☞ Alert starts as soon as traffic is sufficient for high severity detection
☞ Can shorten the triggering of auto-mitigation
☞ Start Latency still applies for lower misuse traffic levels
☞ Disabled by default
This feature should be used primarily for
critical resources as it is resource intensive

Host Detection
Fast Flood Detection (Cont.)
Fast Flood triggers a

Host alert when it
detects that the
Alert Latency
traffic seen already
exceeds the traffic
that would trigger an
alert after 60
@ 6 sec
seconds at the High
Severity Rate
Alert Latency

Host Detection
Configuring Fast Flood Detection
When a fast flood host alert is triggered, the alert always has a severity level of high
followed by a symbol and annotation

Host Detection
Alert Directionality
Alert directionality is not used to highlight Attacker or Victim role, incoming or outgoing is
determined as follows:
• Incoming
– Misuse towards a host within a Customer or Profiled Managed Object
– Only Incoming alerts can be auto mitigated by Sightline
• Outgoing
– If the host is part of a Peer Managed
Object, it will be listed as Outgoing
– A Host Alert that is generated under
Global Detection will always be
Outgoing

Knowledge Check
Host Anomaly Detection
Rest of
Determine Alert Direction for these situations: Internet
BGP Peer B
Q1: Attack directed toward a host
BGP Peer A
within Customer A’s Managed Object.
Incoming
a) Incoming
b) Outgoing
TRA
Q2: Attack directed toward a host within a Peer
Managed Object.
Leader
a) Incoming
Outgoing
b) Outgoing
Q3: Attack directed toward a host NOT contained

within a Managed Object (Customer A is not a MO)
a) Incoming Customer A
b) Outgoing
Outgoing
Solution: Q1: Incoming Q2: Outgoing Q3: Outgoing

Lab Exercise


Step2
• Lab Objectives: Host Anomaly Detection

• Analyze Host Router Alerts


• Anomaly Detection & Classification
• Understand Host Detection and its different misuse types available


Profiled Anomaly Detection
Sightline/TMS
NETSCOUT University Profiled Anomaly

Course Agenda
• Understand Profile Detection
• Profile Detection modes available

Profiled Anomaly Detection Types
Unit 4: Profiled Anomaly Detection


Router versus Network
PROFILED PROFILED
ROUTER NETWORK
Concept Concept
Deviations from normal (expected) Deviations from normal (expected)
traffic levels for a MO on a per-router traffic levels at the MO boundary
basis
Direction Direction
Incoming or outgoing (optionally) from Incoming or outgoing (optionally) from
MO perspective MO perspective
MO MO
Required Required
Default Default
Disabled Disabled
Profiled router detection identifies traffic rates on a router that exceed expected levels for a managed
object or service. The traffic rate that Sightline expects for a managed object or service is referred to as
the baseline. A baseline is the learned traffic rate for a managed object or service. When Sightline detects
a profiled router anomaly, it gathers details about the anomalous traffic on the affected routers. When the
traffic significantly exceeds the baseline for a sustained period of time, Sightline triggers an alert.
Profiled network detection identifies excessive rates of network-wide traffic based on baselines that
Sightline has calculated for your network. Sightline generates a profiled network alert if the rate of the
traffic at a managed object or service boundary for one or more hosts exceeds the baseline by the
detection percentage for a sustained period of time.
When Sightline detects a profiled network alert, it gathers details about the alert traffic from across the
entire network. The alert traffic details that Sightline gathers are broader than the alert traffic details for
profiled router detection. It combines all protocols for which attacks have been detected on the same
managed object into one alert. It also provides the source ASN.


Router versus Network (Cont.)
PROFILED PROFILED
ROUTER NETWORK
Detection Detection
Baseline (7 days, 30 min average) Baseline (7 days, 30 min Mean of square)
Alerting Alerting
Counts traffic through a single router per Counts traffic at the MO boundary and
MO; matches the traffic level against matches the traffic levels against a
standard deviation above baselines percentage above baselines
Fast Flood Fast Flood

High alert only if traffic exceeds high Not available
alert threshold within the first minute of
detection (disabled by default)
Profiled detection identifies excessive rates of traffic for a managed object on a router (for Profiled Router
detection) or across the network or managed object boundary (for Profiled Network detection) as compared to
manually configured thresholds or to the traffic rate that Sightline expects. The traffic rate that Sightline expects is
referred to as the baseline. When Sightline detects a profiled anomaly, it gathers details about the anomalous traffic
on the affected routers and interfaces.


Profiled Latency
Profiled Latency
Sensitivity
Threshold Detection sensitivity
Traffic Baseline
Traffic Level
No Alert Profiled Anomaly Alert
Anomaly Status
• Profiled Latency • Anomaly Detection

– Global Setting – Traffic is above the Sensitivity Threshold for
longer than the Profiled Latency
– Allows varying burst tolerance
– Default 5 min
As with Host alerts, Profiled anomalies have a two-step process:

Detection and Classification
Profiled Anomaly detection is performed by the TRAs comparing current traffic to stored
baselines
Detection Terminology
Traffic Baseline – The expected rate of traffic
Sensitivity Threshold – The rate above the baseline that traffic must be before it is
considered anomalous
Profiled Latency – Length of time the traffic must remain above the Sensitivity
Threshold before an anomaly is generated
Severity Threshold – traffic rate that needs to be exceeded for a High severity alert to
be generated


Detection Directionality
Directionality is determined by the managed object
IN OUT
Incoming anomalies are Outgoing anomalies are

created based on traffic created based on traffic
destined for the Managed sourced from the Managed
Object Object, enabled separately
and not widely deployed


Alert Classification
• Determines anomaly type, severity, and size

• Classification is performed by the Leader
– Compares volume of traffic reported by the Collectors to a value calculated
against the total volume of traffic derived from the Traffic and Routing database
• Classification only takes place after an anomaly is detected by a
Collector
– Traffic must be determined to be deviant first

Profiled Router Detection

Profiled Router Detection Router B

TCP UDP
Baselines
• Total Traffic @ Router ICMP Total
– bps & pps, in & out, per interface, per MO Router B
• IP Protocol Traffic @ Router

MO Cust A
– bps & pps, in & out, per MO
• Baseline Values
MO
– Averages of 30 minutes Cust A
• Baseline Validation
– Now  Previous 30 min Router A
TCP
Router A
UDP
– Now  Time of Day (equivalent 30-minute - 24 hours ago)
– Now  Day of Week (equivalent 30-minute - 7 days ago) ICMP Total
– Older information is weighted more to reduce the effect of
recent changes
Profiled Router detection comes in two forms: Bandwidth and Protocol.

Two types of baselines are maintained:
• Protocol detection uses bps and pps baselines per router (for ICMP, TCP, UDP, GRE, AH, ESP, and
"other").
• Bandwidth detection uses bps and pps baselines per interface, not per router.
• The expected rate is our “magic” value based on baseline and sensitivity setting.
Each MO/resource will have a separate expected value per router per protocol and per interface for
bandwidth.


Baseline Example Profiled Router
Detection monitors
MO all routers
Customer A
Router A Router B
Baselines Baselines MO
C
B Customer A
A
Router C Router D
Baselines Baselines
TRA
TRA D
Web Servers
DNS
MO
Customer A TRA
Router E Router F F
Baselines Baselines
E
Customer A
Customer B Sightline Managed Router
COPYRIGHT © 2022 NETSCOUT SYSTEMS, INC. | CONFIDENTIAL & PROPRIETARY 11 Router not managed by Sightline


Sensitivity Settings
Sensitivity 4 Expected
Traffic Baseline
Traffic Level
Detection sensitivity is configurable

per Managed Object


Detection Sensitivity
Detection Sensitivity determines the difference between the

Traffic Baseline and the Sensitivity Threshold
• Lower number → more sensitive
• Higher number → less sensitive
Sensitivity
Threshold
Traffic
Baseline


Detection Sensitivity – Less sensitive
9:00 am 12:00 pm 5:00 pm
Sensitivity Threshold Set to 5
Traffic Baseline


Detection Sensitivity – More sensitive
9:00 am 12:00 pm 5:00 pm
Sensitivity Threshold
Set to 2
Traffic Baseline
It is good practice to
have lower Detection
Sensitivity for Interface
Packet Alerts than for
Bandwidth Alerts


Detection Sensitivity – Ignore Rate
9:00 am 12:00 pm 5:00 pm
Ignore Rate
Traffic Baseline
• Suppress anomalies that are too small to care about, even if statistically
significant
• Anomaly must exceed Ignore Rate before an alert is generated


Profiled Latency
Profiled Profiled simplified
Router Router representation
Traffic Volume Latency
Latency
Alert no
longer active
Severity Threshold
Middle Line
Ignore Rate
Baseline
Time
A profiled alert ends when for the length

of the Profiled Latency period the traffic
level goes below the higher of either
Ignore Rate or Sensitivity Threshold.


Severity: Low Alert Profiled
Severity simplified
Router representation
Traffic Volume Latency Duration
Severity Threshold
Middle Line
Baseline
Low severity
Alert generated
Time
1) Traffic goes above Ignore Rate & Sensitivity Threshold and stays above for longer than Profiled
Router Latency period
2) Traffic may go above the Middle Line, but does not stay there for Severity Duration period
3) Traffic never goes above Severity Threshold
An alert has a low severity level if the following conditions are true:
- Traffic goes above the ignore rate (except with the interface groups match type that does not use ignore rates).
- Traffic goes above a forced alert threshold or the baseline plus the sensitivity threshold and stays there for longer
than the profiled router latency period.
- Traffic does not stay above the middle line for the severity duration.
- Traffic never goes above a severity threshold.


Severity: Medium Alert Profiled
Severity simplified
Router
Duration representation
Traffic Volume Latency
Severity Threshold
Middle Line
Baseline
Low severity Severity set to Medium

Alert generated (if > 1 min. & < Severity Duration)
Time
2) Traffic goes above Middle Line staying there for the Severity Duration period
– or –
2) Traffic goes above the Severity Threshold but does not stay above for the Severity Duration period
An alert has a medium severity level if the following conditions are true:
- Traffic goes above the middle line and stays there for the severity duration or traffic goes above the severity
threshold but does not stay there for the severity duration.


Severity: High Alert
Profiled Severity simplified
Duration Severity set to representation
Traffic Volume Router
Latency High
Severity Threshold
Middle Line
Baseline
Low severity Severity set to

alert generated Medium
Time
2) Traffic crosses Severity Threshold and stays above for the Severity Duration period
An alert has a high severity rate if the following conditions are true:
- Traffic goes above a severity threshold and stays there for the severity duration.


Configuration
Administration > Monitoring > Managed Objects

Profiled Detection must be enabled and configured for each MO you
wish to monitor
Once Profiled Detection is enabled,
you can Edit Profiled Configuration
Fast Flood Detection also available with

Profiled Router detection
Outgoing Detection
enabled/disabled
separately for each MO


Configuration (Cont.)
Severity Classification
• High alert thresholds
• Blank by default
• Superseded by Automatic
Rate Calculation values
Ignore Rates
Enable Automatic
Rate Calculation
(recommended)
Sensitivity Settings
→ Alert Trigger
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 Sightline
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 Sightline 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.


ARC Automatic Rate Calculation
Global Automatic
* Rate Calculation
Settings become
defaults for MO
settings
Page incomplete! *Calculation runs every 8 hours

on 35 minutes past the hour
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 Sightline 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 Sightline to generate an ignore rate,
and then select the corresponding traffic units from the lists.


Recommendations
✓Use Auto Rate Calculation

✓Set Sensitivity settings high (less sensitive) while baselines are being
built in the first week
✓Manually configuring profiles require on-going maintenance
✓Fast Flood Detection can be resource intensive
☞ Should only be enabled for critical resources or those that are under frequent
DDoS attack (especially carpet-bombing style attacks)
✓Get high level infrastructure coverage using network aggregates
☞ Create a Managed Object containing the backbone aggregates and enable
profiled detection
Auto Rate Classification is performed by the Leader using deployment-wide data for each MO
Rates are recomputed every 8 hours on 35 minute past the hour boundaries (00:35 GMT, 08:35 GMT,
and 16:35 GMT)
Two static values are used to calculate the Severity Threshold:
Severity Percentile – The percentage of normal traffic that Sightline uses as a base value to calculate
incoming and outgoing severity rates
For example, 95th percentile means that 95 percent of normal traffic in the past 30 days will be used as
the base value
Designed to find the true maximum by eliminating spikes

Severity Multiplier – The multiplier raises the severity threshold so that the calculated severity rate comes
out above normal peaks
Default value of 1.1 raises severity threshold by 10%

Ignore Percentile is used to calculate the Ignore Rate for profiled detection
Recommended practice is to set this value around the MO’s average data rate during the last 30 days
(40th-50th percentile)

Profiled Network Detection


Overview
• Baseline
– Rates of traffic that cross the managed object boundary or service boundary
• Baseline Types
– Combines all IP protocols into an aggregate for pps or bps
– Aggregates all interfaces that comprise the MO boundary together
– Profiled Country - Alerts when IPv4 traffic from a country exceeds the baseline values
for that country (optional)
• Baseline Values
– ‘Mean of square’ from 30 minutes
– Update at 15 and 45 minutes past the hour


Profiled Network
Baseline Example Detection only monitors
boundary interfaces for
MO
Customer A
the MO
Router A Router B
Baselines Baselines
MO
C
B Customer A
A
Router C
Baselines
TRA
TRA D
Web Servers
DNS
TRA
F
E
Customer A Customer B Sightline Managed Router
COPYRIGHT © 2022 NETSCOUT SYSTEMS, INC. | CONFIDENTIAL & PROPRIETARY 27 Router not managed by Sightline


Configuration
Administration > Detection > DDoS ≤9.2

Administration > Detection > Global Detection Settings ≥9.3
Configure the global start and end latency for Profiled Network anomaly
detection



• Enable profiled detection
• Configure the use of
profiled country detection
• Configure the low alert

trigger rate
• Configure the high severity
rates and duration
• Set the ignore rates in bps
and/or pps
Profiled network detection identifies excessive rates of network-wide IPv4 and IPv6 traffic based on baselines that
Sightline 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, Sightline 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 Sightline triggers the alert.
Incoming/Outgoing Severity Percent: Type the percentage above the baseline that either incoming or outgoing
traffic must be before Sightline triggers a High alert.
Incoming/Outgoing Ignore Rates: Type the traffic rates (in bps and pps) below which you do not want
Sightline to generate alerts.

Knowledge Check
Profiled Anomaly Detection
Q1: Which type of Profile Detection is Q3: What traffic behavior cannot be ‘learned’
supported by Sightline? by Profiled Detection?
a) Network a) Fast increase of traffic
b) Router b) How many PPS was used over time

c) Interface c) Changes in traffic that does not take place every
7 days
d) Application
Q2: What is the default traffic direction
considered for Profiled Detection?
a) Incoming Traffic
b) Outgoing Traffic
c) Both Traffic Directions
Solution: Q1: a,b Q2: a Q3: c

Lab Exercise


Step2
• Lab Objectives: Profiled Anomaly Detection

• Analyze Profiled Alerts


• Understand Profile Detection
• Understanding Profile Detection modes available



Interpreting Anomaly Alerts
Sightline/TMS
NETSCOUT University Interpreting

CONFIDENTIAL & PROPRIETARY Anomaly Alerts - 1
Unit Summary
• DOS Alerts Details
• How to analyse DOS Alerts
• How to get DOS Alert Statistics

Alert Details
Unit 5: Interpreting Anomaly Alerts

Alert Details
Overview
Anomaly Summary - Overview of what the anomaly is, how critical, when it
happened, and what resource is affected…
• Summary Tab
– What are the major components of the anomaly
– What resources, routers, and interfaces, are involved
– Top traffic patterns
• Traffic Details Tab
– Very detailed information on the traffic making up the anomaly (ports, protocols,
source/destination addresses, traffic patterns, etc.)
• Routers Tab
– Router-specific traffic information as well as detailed interface impact

Alert Details
DOS Alert Summary Tab
Unified interface
for IPv4 and IPv6
DoS alerts shows
traffic graph with
selectable content,
top traffic patterns,
view raw flows,
and more…

Alert Details
DOS Alert Summary Tab (Cont.)
Select time period to view alert
View options determined

by alert type
View contribution from

each router separately
The Period dropdown allows for multiple timeframe options with the default being Alert Timeframe.
Each View selected will redraw the graph according to the relevant data (be sure to click the Update
button). For instance, if an alert triggered as a result of traffic that originated and ended within the network
and never crossed the managed object’s boundary or the external boundary, the only graph available will
be for each Router. In the case of an attack from an external source to an internal target, a different graph
will be drawn for Network Boundary versus each affected router in the Router View.
An important point to keep in mind is that the View dropdown list will be determined by the type of
anomaly listed:
- Host alert: Network Boundary, Managed Object Boundary, and Router are selectable
- Profiled Router: Network Boundary, Managed Object Boundary, and Router view are selectable
- Profiled Network: only Network Boundary and Managed Object Boundary are selectable
When Router is selected from the View list, then a Router (Severity) list appears that allows you to select
a router that is associated with the alert traffic. By default, the router with the highest severity percent is
selected in the Router (Severity) list. The routers in the list are also sorted by severity percent.

Alert Details
Graphs and Legends
Graph legend
contains selectors →
click dots to add or
remove graph
elements
Deselected
graph element
shows as an
empty circle
Total traffic is no
longer graphed
Sightline can potentially generate an alert that has over 10 different misuse types due to the amount of
misuse types tracked by Host Detection. However, the Alert Traffic graph that appears here currently
supports up to 10 different misuse types. If more than 10 misuse types are triggered, all of the triggered
misuse types are listed under Misuse Types in the alert information that appears above the graph.
However, the graph itself displays only the first 10 misuse types that were triggered.

Alert Details
Graphs and Legends (Cont.)
If View is Router, Misuse type detection threshold selector becomes

visible when only one misuse type is displayed
SSDP Amplification
Everything but SSDP threshold revealed
Amp. deselected
If the view is Router and only a single misuse type is displayed (whether it triggered the alert or not), a
detection (Threshold) selector for that misuse type will appear.

Alert Details
After selecting the misuse type detection threshold, it will show as a

black line on the graph

Alert Details
Example of an alert showing traffic levels from five misuse types
Note: Sightline can potentially generate an alert that has more than 10 different misuse types because of the number
of Misuse Types that are tracked. However, the Alert Traffic graph currently supports only up to 10 different
misuse types. If more than 10 misuse types are triggered, all of the triggered misuse types are listed under Misuse
Types in the alert information that appears above the graph. However, the graph with its colored selectors displays
only the first 10 misuse types that were triggered.

Alert Details
Top Traffic Pattern
• Found directly below the Alert Traffic graph(s)

• Top Traffic Patterns show traffic contributions by combinations of traffic details
– Shown on both Summary and Traffic Details tabs
This Section
might be
missing
when the
TRA is
under
provisioned
Top traffic pattern breakouts were introduced in Sightline Release 7.0. If the TRA’s, especially virtual TRA
appliance are under powered, aka under provisioned from the DRAM and Cores perspective, then this
Top Traffic Pattern Sectionwill be missing.

Alert Details
Top Traffic Pattern (Cont.)
• Patterns are derived from 5-tuple:

♺ IP Addresses (src/dst)
♺ IP Protocol
♺ TCP/UDP Ports (src/dst)
• Traffic Patterns that exceed 10% of alert are combined → Top Traffic Patterns
• First 10 Top Traffic Patterns are shown in Alert; full list can be downloaded
– Maximum 1-minute traffic over previous 5 minutes
– Only most recent 5 minutes of the alert is evaluated
– No other traffic pattern history is kept
Sightline can display up to 10 top traffic patterns in the Top Traffic Patterns table. You can view all of the traffic
patterns that are associated with an alert by clicking the Download All Patterns which generates a CSV file that
lists the traffic patterns.

Alert Details
Drop Down Menu
Hidden dropdowns appear when hovering near almost any element of a

top traffic pattern
• Add individual detail elements to the Scratchpad for later reference
• Perform Whois lookups on IP addresses / prefixes
Scratchpad is an electronic
pad that helps to centrally
note important information
and identified attack elements

Alert Details
Alert Characterization
• Each element listed contributed at least 25% of the traffic for the alert
• Pulldowns for Scratchpad, etc.

Alert Details
Packet Size Distribution
Packet size distribution bar graph

• Aggregates packet sizes as 150-
length ranges
• Individual packet lengths are not
recorded
The left side of the graph lists groups of packet size ranges of 150 bytes each. Each horizontal bar shows
the number of packets within that 150-byte range. A jumbo frames bar appears at the bottom of the graph
for packets that are larger than 1500 bytes.
The Packet Size Distribution graph can often help you determine if an alert represents an attack. You can
use the graph to identify whether packet sizes are spread out or concentrated. If the packet sizes are
concentrated, you can then use the graph to determine if the areas of concentration are what would be
expected for that type of traffic.
For example, if you receive a UDP flood alert for packets sourced from port 123 (NTP), and the majority
of the packets are large (400 bytes or larger), you are probably looking at a reflection attack because
these NTP packets would normally be much smaller.

Alert Details
Top Interfaces
Up to 5 of the top affected interfaces are tracked

• Top interfaces shown individually on Summary tab
• Top interfaces grouped by router on the Routers tab
The Top Interfaces table displays the interfaces that were most impacted by the traffic of this alert. It can
display up to 5 interfaces. The interfaces are sorted by the Average Observed bps value.
If the name of an item in the Top Interfaces table is truncated, you can hover your mouse over the name
to display the full name. Additionally, each interface has a contextual dropdown. The available options
are:
- Add interface to Alert Scratchpad
- View Summary Report: redirects to Reports → Interfaces → Summary:<interface name>
- View Configuration: redirects to Administration → Monitoring → Interfaces → <interface name>

Alert Details
Annotations
• Only recent annotations are on Summary tab

• Use View All Annotations to view all automatically and manually
added annotations

Alert Details
Raw Flows (Cont.)
View Raw Flows is a link to Explore > Forensics

• Showing the raw data taken from the flow record received
• Query Fingerprint is automatically added, but not constrained to alert traffic

Alert Details
Traffic Details Tab
• 12 details tracked
– Top 5 elements are displayed for
each detail
– If more than 5 elements are
tracked for a detail, View More will
show them in a pop-in window
• Graph shown at top of page is
dependent upon which traffic
detail is selected below
Tracked traffic details include:

• Source and Destination IP Addresses: by default, Sightline aggregates these addresses
• Source and Destination TCP Ports: a port is followed by the service name, and an aggregated port is
followed by the aggregated port name
• Source and Destination UDP Ports: a port is followed by the service name, and an aggregated port is
followed by the aggregated port name
• Source Countries: top 5 source countries for the alert traffic
• Source ASNs: the AS number is followed by the ASN name
• Protocols: top 5 protocols seen within the alert traffic
• TCP Flags: displays the TCP flags that have been set to 1. The letter or letters for the TCP flag are
followed by the name or names of the TCP flag.
• ICMP Types: displays counts and rates for ICMP packets with the specified ICMP type
• Misuse Types: top 5 misuse types for the alert traffic

Alert Details
Aggregated Data
• Up to 100
Aggregation
Aggregation
items may be
recorded in
each category
• Aggregates IP
addresses and
port ranges
into significant
percentages
During each minute of a DoS alert, Sightline collects data on the source and destination IP addresses of
the alert traffic and aggregates them as follows:
• Aggregates the IP addresses until it identifies an IP prefix that represents at least 10% of the alert
traffic.
• Continues to aggregate IP addresses until it identifies an IP prefix that represents at least 10% of the
alert traffic in addition to the traffic of the previously identified prefix.
• Continues this process of aggregation as long as it can identify IP prefixes that represent at least 10%
of the alert traffic in addition to the traffic of previously identified prefixes.
Up to 100 items may be recorded in each traffic detail category.

Alert Details
Aggregated Data (Cont.)
Traffic Details graph shows
any selected detail
• Blue box identifies
graphed detail
• Defaults to Source IP
Address

Alert Details
Routers Tab
Interfaces
grouped by
router, unlike
the Summary
tab
Click [+] to
expand and
see affected
interfaces
• Add interface to Scratchpad
• View Traffic Summary report for interface
• Go to configuration

Alert Details
Annotations Tab
Displays a list of all annotations that have been made for the alert, whether
manually or automatically by the system
• Click Add Annotation to add your own annotations documenting your workflow

Alert Details
Scratchpad
View Scratchpad anytime to see selected details

Analyze Anomalies

Analyze Anomalies
Recommended Practices
If there are a lot of Alerts, check for the following:

☣ MO may have manually configured detection settings
☞ Thresholds for misuse are too low -> raise them
☣ Auto-rates default settings may be too low
☞ Consider a higher percentile for Ignore Rate (~60 or more)
☞ A handful of managed objects make up 90% of all alerts
• May be small resources that have very spiky traffic.
• Turn off profiled alerting or manually increase rates
Unless the network is constantly under attack, aim at getting no more than ~100
DOS alerts and no more than ~10 high alerts per day
When there are overlapped MOs (i.e., multiple MOs that match same flows), you may want to disable
detection on the summary MO in order to reduce the number of alerts generated by a single event.

Analyze Anomalies
Recommended Practices (Cont.)
When trying to identify a malicious attack, look at Host first!

Host anomalies Profiled anomalies
• Are the most commonly used • Show a deviation from normal
attacks against single hosts traffic levels that may or may not
• Trigger when traffic to a particular come as a result of a malicious
host doesn’t appear to comply with attack.
RFC rules • Further analysis required to
• Misuse type most likely signals a determine if anomaly really needs
malicious attack or a network error to be addressed

Analyze Anomalies
Eagle View
Start at 20,000 feet and work your way down

✓ Anomaly summary
☞ Is a given anomaly worth to be investigating?
☞ How severe is it?
☞ What is impacted?
✓ Traffic characterization
☞ Do the traffic patterns look malicious?
☞ How far above the expected is the reported traffic?
✓ Interface/Router traffic details
☞ What are the packet sizes involved?
✓ Is the data consistent with normal Internet traffic patterns?

Analyze Anomalies
Alert Summary
• What is the severity of the anomaly? • When did the anomaly occur?
• What is percentage above the high severity rate? • Did it coincide with any network events?
What resources or
customers are affected?
Severity percent → The highest single-minute ratio of alert traffic to high severity rate for any single
misuse type over the lifetime of the alert. The traffic can be on an individual router, the network boundary,
or the managed object boundary.

Analyze Anomalies
Alert Summary (Cont.)
Mini graph shows a

spike in the traffic levels
Anomaly has High severity
Impact levels are large %

above High Severity Rate Consider the type(s) of misuse
vs the normal traffic the
resource usually receives
Impact → The network bandwidth consumed by the alert traffic. This is measured by the highest single-minute sum
of alert traffic at an individual router, the managed object boundary, or the network boundary.
Note: Impact data and minigraph are not immediately available when the alert becomes active. They
depend on detailed analysis of the traffic and may take several minutes before data is available. If the
duration of the alert is short, there may not be any data for the minigraph at all or it may show up as just a
single vertical line.
There are a few reasons why the sum of the max observed values might not match the displayed impact
value:
• The impact value displayed in the alert summary is the highest traffic for a one minute period across
all boundary interfaces involved in the alert. If some of the affected network elements are not
boundary interfaces, this would cause those interfaces to not have any impact data recorded, and
therefore have no affect on the impact summary calculation.
• The max observed values occurred at different times. For example, say we have an alert where all of
the interfaces are boundary interfaces and are therefore recording impact data. In this alert, we have
interface A which has seen 100 mbps at 10:00 and 20 mbps at 10:01. We also have interface B which
has seen 1 mbps at 10:00 and 30 mbps at 10:01. The impact data in the alert summary would be 101
mbps (for the traffic observed at 10:00, versus the 50 mbps at 10:01), while the max observed would
be 100 mbps for interface A and 30 mbps for interface B.

Analyze Anomalies
Signs of Malicious Traffic
• Several Misuse Types

simulations detected
• Traffic levels reported

for the misuse types
indicate an abnormal
behavior

Analyze Anomalies
Signs of Malicious Traffic (Cont.)
• Destination ports not matching

the service on the affected
host?
• Inspect the Top Traffic Patterns
– Check originating hosts or
specific subnets that
contribute a significant % of
the traffic
– DNS Amplification and port 0
due to fragmented traffic
– Top sourced country (based
on source IP information of the
packets)

Analyze Anomalies
Reports > Customer > IP Header > UDP

Change Period
Select Managed-Object
Check
common
services of
Managed
Object from
Report Data

Analyze Anomalies
Reports > Customer > Countries

Change Period
Select Managed-Object
Check
normal Top
Country
Distribution
with Report
Data

Analyze Anomalies
Examine the Traffic Details

from the router or boundary
with the highest volume of
traffic, looking for:
• Not normal source
distribution
• Non-standard port
distribution
• Unexpected source
countries

Analyze Anomalies
Are they known hosts?

– x.x.18.15/32 contributed 24.8%
– x.x.101.12/32 contributed 22.68%
What kind of traffic is it?

– These ports normal for this resource?
– 100% of traffic had TCP RST flag set?

Analyze Anomalies
☣ A subnet as source with source ports across entire range

☞ This is an indicator of potentially spoofed traffic sources
☣ A small number of IP destinations with varied destination ports
☞ Highly improbable that hosts have services on all those ports
☣ The anomaly ends with a sharp drop off in traffic
☣ Service not offered by this Destination
☞ FQDN and Whois lookup for any hosts involved
☣ Look at bytes/packet and pps for the anomaly
☞ Should see normal packet size distribution for the operated service

Analyze Anomalies
Signs of Normal Usage Spikes
Profiled Anomaly
☞ Low severity with low volume of traffic
☞ Actual traffic is not too far above the baseline
☞ Widespread source IP of common Internet ports
– Subnets of destination IP with standard Windows ports
☞ Alert corresponds with a network event
☞ What is the context?
– In a University network you may see periodic anomalies indicating downloads when a new
Linux Kernel released
– Know your network …

Analyze Anomalies
QUIZ
Alert worth to be
investigated?
List PRO
• DOS Alert triggered
• Target DNS Server
List CONS
• Low Severity
• Traffic Level =
230Kbps @ 450pps
• Traffic graph not
suspicious
• Alert generated
during the night
• Packet sizes not
suspicious

DOS Alert Statistics


Alerts > Summary
Summary of ongoing
Alert activity from last 24 hours and recent alerts with
links to each
Top 5 ongoing or recent alerts


Alerts > Summary (Cont.)
All Alerts and Alert Classes

display the number of alerts in
the system
• Ongoing
– Alerts currently active
• Recent
– Alerts no longer active
• Last 24 Hours
– Newly added alerts in the last 24
hours
A “recent” alert is any alert in the database that is not in “ongoing” status.


Alerts > Activity Report
Shows activity of Host and Profiled alerts over time

Available reports:
• Alerts by Severity (In/Out)
• Alert Misuse Types (In/Out)
• Top 10 Affected Prefixes (In/Out)
• Top 10 Routers Affected (In/Out)
• Top 10 Alerts by Severity Percentage (In/Out)
Standard time period controls
This same report (a Classic DoS report called PDF Activity Report) can be scheduled under
Administration > Reports.

Knowledge Check
Interpreting Anomaly Alerts
Q1: What could be a potential sign of a DOS Q3: Which DOS Alert Types should be
Attack? examined first?
a) High PPS rate a) Profiled Router Alerts
b) Low Bandwidth Utilization b) Profiled Network Alerts
c) High Bandwidth Utilization c) DOS Host Alerts
d) Low PPS rate d) Traffic Threshold Alerts
Q2: Multiple Attack Vectors going to the same
IP Address in a Managed-Object will trigger…
a) … individual Alerts
b) … a single Alert
Solution: Q1: a,c Q2: b Q3: c


• DOS Alerts Details
• How to analyzes DOS Alerts
• How to get DOS Alert Statistics


Anomaly Mitigation
Sightline/TMS
NETSCOUT University Anomaly

CONFIDENTIAL & PROPRIETARY Mitigation - 1
Unit Summary
• Identify different mitigation methods
• Understand how each mitigation method work
• Launch a mitigation from an alert

Mitigation Methods
Unit 6: Anomaly Mitigation

Mitigation Methods
Preparation is the Key
Blackbox Whitebox
No details available All details available

☞ Filter protocols that are ☞ Filter all traffic not
not commonly used
?
☞ Filter traffic for known
reflection/amplification
attack vectors
versus
needed for the protected
resource
☞ Enable selective
WWW
Countermeasures in
conjunction
“Everything permitted “Everything denied

except…” except…”
Distributed Denial of Service (DDoS) attacks are seen in the network as a mix of undesirable traffic from
the attack and desirable traffic from legitimate users and hosts. The undesirable attack traffic may be sent
in large quantities with the intent of overwhelming the victim system or it could be shaped with the intent
of disrupting normal server processing. Some thoughts you may consider prior to developing a mitigation
strategy:
• What do you want to do
• When to use which strategy
• Best strategy for mitigation an attack

Mitigation Methods
Select Strategy
Resource Attack Size Effect of Ease of

affected and Protection Protection
Complexity Launched Usage
Who is affected?
A customer, What is the size Does host or How much
service or the of the attack and service still need configuration or
infrastructure? type(s) used? to be reachable? actions need to
be performed?
Goal is to Stop or Reduce the Impact of the attack

Distributed Denial of Service (DDoS) attacks are seen in the network as a mix of undesirable traffic from
the attack and desirable traffic from legitimate users and hosts. The undesirable attack traffic may be sent
in large quantities with the intent of overwhelming the victim system or it could be shaped with the intent
of disrupting normal server processing. Some thoughts you may consider prior to developing a mitigation
strategy:
• What do you want to do
• When to use which strategy
• Best strategy for mitigation an attack

Mitigation Methods
Comparison
FILTER BLACK FLOW TMS SIGHT-

X
HOLE SPEC LINE
SIGNAL
Use contents Use BGP Use BGP Divert traffic to Request
of alert announcement announcement TMS to protect external
Scratchpad to with new next to instruct critical Mitigation via
define an ACL hop to drop routers to resources Sightline (SL)
to be applied traffic mark, drop or using Signaling from
to a router rate limit traffic configurable your Sightline
that matches a counter- to an upstream
filter measures Sightline
Deployment
Threat Management – Diverts network traffic to a TMS. This mitigation type is useful for attacks on
critical resources that use main service ports. This mitigation type provides detailed mitigation statistics.
Flow Specification (ACLs) – Mitigates using Flow Spec-capable routers. Use this mitigation type to
mitigate an attack that can be cleaned using filtering technology. This mitigation type can redirect, rate-
limit, or perform other operations. You can forward clean traffic to the attacked source.
Blackhole (null-routing using BGP) – Temporarily blackholes network traffic by redirecting it elsewhere in
the network. This mitigation can also divert network traffic at the peering edge of the network without
redirecting it. This mitigation type uses a BGP announcement with a new nexthop to redirect the traffic to
the filter device.
Generate Filter – Mitigates an attack with unique characteristics that can be defined using layer 3-4
access control list (ACL) filters. You can use this mitigation type to mitigate a DDoS attack if the results of
the attack are not critical to your network operations.

Sightline Triggered Blackhole

Mitigation

Sightline Triggered Blackhole Mitigation

Overview
Sightline announces BGP route

to black hole traffic BGP
TRA
• Surgically select the routers from list
• Use BGP Community to influence
where traffic will be blackholed
Peering
Example Edge TMS
1) 65000:910 = Domestic Peering
2) 65000:920 = International Peering
3) 65000:900 = All Peering Routers
Your Network
UI


On the Router
Sightline announces a BGP route with the victim IP address and a next-
hop that points to ’trash’…
B: 4.4.4.4/32 -> 192.168.1.1
S: 192.168.1.1/32 -> discard (equal to Cisco: Interface Null0)
arbor@edge-rio> show route 4.4.4.4/32
inet.0: 130 destinations, 152 routes (130 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
4.4.4.4/32 *[BGP/170] 00:17:38, localpref 100, from 172.16.1.68

AS path: ?, validation-state: unverified
Discard
Detecting which source is an attacker problematic... the chief challenge here is not detecting which
destination is under attack, but detecting which source is an attacker!
Dealing with huge numbers of sources is a study in compromises
• RIB/FIB memory is not limitless
• The goal is to just block attackers
Filtering by source filters all packets with that source – whether or not they are Packets from an attacker –
remember spoofing!


Upstream Signaling
Sightline announces BGP route

to blackhole traffic
BGP TRA
Use BGP Community to allow route to
be sent to upstream carriers to
perform blackhole action
Example: Peering
Edge TMS
• Hurricane Electric
community 6939:666
Your Network
UI


Conclusion
Use Case Advantages Limitations

✓ Preferred for non- ✓ Uses BGP ✓ Affects all traffic
managed ✓ No configuration through selected
customers changes on router routers, regardless
✓ To prevent ✓ Allows frequent of actual intent
collateral damage changes on ✓ Reporting and
✓ For high volume dynamic attacks examination of
attacks ✓ Drops happen in attack traffic may
forwarding path be limited when
send outside of
own network


Alert > Mitigate Alert > Blackhole
From the DoS Alert you can select Blackhole under Mitigate Alert
dropdown
x.x.141.233


Configuration
Unique name*
Destination prefix blackholed*
Announced next-hop*
Choose which router(s) will

get the blackhole injected
Select which BGP

community (if any)
will be used
*automatically filled in when

started from a DOS alert

Sightline Triggered Flow

Specification

Sightline Triggered Flow Specification

Overview
Sightline announces a ‘policy’ via

BGP about how to handle certain
traffic BGP TRA
• Use network elements to police or

drop certain traffic
• Use multi-match criteria to clearly Peering
Edge TMS
identify malicious traffic
Example
1) Traffic-rate to X bps Your Network
2) Traffic-marking set DSCP to CS1
3) Traffic-rate to 0 bps = drop UI


On the Router
Sightline announces a BGP policy with all the configured parameters

arbor@edge-rio> show route table inetflow.0 extensive
inetflow.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

4.4.4.4,*,proto=17,srcport=53,len>=450&<=600/term:1 (1 entry, 1 announced)
TSI:
KRT in dfwd;
Action(s): discard,count
Page 0 idx 0, (group ArborSP type Internal) Type 1 val a3be258 (adv_entry)
Advertised metrics:
Nexthop: Self
Localpref: 100
AS path: [65530] ?
Communities: 65530:100 65530:134 no-export traffic-rate:0:0
Cluster ID: 192.168.252.12
Originator ID: 10.2.25.68
Advertise: 000006f7
Path 4.4.4.4,*,proto=17,srcport=53,len>=450&


Conclusion

✓ Preferred for ✓ Uses BGP ✓ Multiple traffic
managed ✓ No configuration combination would
customers changes on router require multiple
✓ For high volume ✓ Allows frequent BGP FlowSpec
attacks changes advertisements to
✓ Supports Multi-Match be configured and
✓ Supports different propagated
Actions to traffic
✓ Broad vendor
support


Alert > Mitigate Alert > Flow Specification
From the DoS Alert you can select Flow Specification under Mitigate
Alert dropdown
x.x.141.233


Configuration
Name and Description field of the Flow Specification is pre-populated

and can be updated. The Name must be unique within the system
Description


• Select the routers that should
receive the BGP Flow
Specification announcement
Announcement
• Configure VPN Flow
Specification Route Target
and Route Distinguisher (if
required)
• Configure BGP Communities

(if required)


Configure filter elements that

highlight the attack traffic
• Protocol Numbers (numeric)
1 = ICMP, 6 = TCP, 17 = UDP, …
Filter
• Source & Destination Prefix
Became mandatory with ≥9.5.0.0
• TCP Flags (numeric)
1 = FIN 16 = ACK
2 = SYN 64 = ECE
4 = RST 128 = CWR
8 = PSH
When you add or edit a manual flowspec mitigation, by default, Sightline≥9.5.0.0 now requires you to enter a
source prefix and a destination prefix. You specify the prefixes on the Filter tab of the Flow Specification
page. You can use the Sightline leader device’s CLI to disable this requirement.


Select the action that should be performed by the router

Action
Flow Specification rule order is determined by length of matches,

aka rules with more matching fields are executed first


Mitigation > Flow Specification
Once the Flow Specification is configured and saved it must be

manually started to send out the advertisement
Click Start to
announce the
Select the Flow
Flow Specification
Specification(s) and
entry
perform Start, Stop or
Delete for all of them


Detailed Reporting with Sentinel License
• Mitigations table contains information

on each mitigation
• Dropped Traffic graph(s) appear when

there is alert traffic dropped
• Two new Flowspec tabs available in

the alert:
✓ Flowspec Details*
✓ Flowspec Routers*
*Requires a Sentinal License


Sightline TMS Mitigation


Overview
Sightline announces BGP route or

FlowSpec to divert the traffic
BGP
• All traffic through ’poisoned’ routers TRA
towards destination will now be

diverted
Peering
TMS
• Surgical separate valid from malicious Edge
traffic by using a combination of TMS

countermeasures
Your Network
UI


Conclusion

✓ Surgical Mitigation ✓ Uses BGP ✓ Mitigation capacity
✓ Traffic Diversion for − Route based determined by the
Troubleshooting − Flow Specification amount of
purposes hardware or
✓ No configuration software-based
changes on router appliances
✓ Allows frequent
changes
✓ Supports a list of
countermeasures


Attack Processing
Attack Balancing Surgical
Characteristics Traffic Removal Mitigation
TMS uses various

The ideal mitigation: countermeasures
DDoS attacks
drop 100% of the bad traffic to drop or block
consist of
& attack traffic to
undesirable traffic
pass 100% of the good traffic allow the resource
mixed with some
to continue
desirable traffic
operating


Alert > Mitigation Alert > Threat Management
From the DoS Alert you can select Threat Management under Mitigate
Alert dropdown
x.x.141.233
Anyone who is designing a network threat mitigation strategy needs to include flexibility to adapt to widely varied
attack circumstances. No one solution will work for all attacks, so it is important to consider common attack types
in advance to plan how to mitigate them. One should also consider a strategy that identifies initial responses to
unusual attacks and then narrows solutions so that their impact can be minimized efficiently.


Alert > Mitigation Alert > Threat Management (Cont.)
Save and Start Mitigation

Saves the mitigation settings and starts the mitigation (announces BGP route and
takes you to the mitigation dashboard)
Save and View Listing

Saves the mitigation settings and returns you to the list of mitigations but does
not start the mitigation

Sightline Signaling

Sightline Signaling
Overview
Sightline signals to the upstream

provider and ask for help
BGP
• Alert information are TRA
shared with the upstream

cloud service provider
also using Arbor Sightline TMS
Peering
Edge TMS
ISP
• Surgical traffic filtering
closer to the source and UI
protecting own and
Cloud
Signaling Your Network
CS-Provider Connection
upstream service
provider network
UI
CS-Requester

Sightline Signaling
Conclusion

✓ Surgical ✓ Direct Sightline to ✓ Requires a
Mitigation Sightline communication Sentinel license
✓ Alert details ✓ No configuration on Sightline for
shared with changes on routers the Cloud
upstream ✓ Multi-Layered line of Signaling
provider Sightline defense setup provider role
✓ ISPs working ✓ Auto-mitigation
closely together • automatic mitigation launch≥9.4.0.0
• automatic mitigation request
signaling≥9.5.0.0

Sightline Signaling
Alert > Mitigation Alert > Sightline Signaling
From the DoS Alert you can select Sightline Signal under Mitigate Alert
dropdown

Sightline Signaling
Configuration
• From the dropdown

menu select the
Mitigation Provider
that should receive
this signaling request
• Add a message on
the signaling request

Sightline Signaling
Status
Requester Side
x.x.141.233
Manually stop the

All mitigation requests in this Alert
Mitigation Request
Provider Side
x.x.141.233
x.x.141.233

Knowledge Check
Anomaly Mitigation
Q1: Mitigation technique that is least Q3: Mitigation that is optimal for most
intrusive? Volumetric DOS Attacks?
a) Blackhole a) Blackhole
b) Flow Specification b) Flow Specification
c) Access-List c) Access-List
d) TMS d) TMS
Q2: Mitigation that could be used for Q4: Mitigation that is best for complex DOS
non-MSSP Customers? Attack?
a) Blackhole a) Blackhole
b) Flow Specification b) Flow Specification
c) Access-List c) Access-List
d) TMS
d) TMS
Solution:
Q1:d – most surgical mitigation approach
Q2:a – most non-paying customers are not protected; the ISP only protects himself against collateral
damage
Q3:b – Mass data cleaning in the network, more surgical filter as a second instance on the TMS. BL is too
aggressive for legitimate services. ACL is no option as it is too slow to respond to changes and to be
deployed, only an option for long term filtering.
Q4:d - TMS

If you are asked for your POD-NUMBER during

Lab Exercise the exercises, use the following syntax:
Your Username: NE182 ➔ POD-NUMBER: 182

• Environment: Sightline

Step2
• Lab Objectives: Anomaly Mitigation

• Creating a BGP Blackhole Mitigation
• Creating a BGP Flow Specification Mitigation
• Creating a TMS Mitigation


• Identify different mitigation methods
• Understand how each mitigation method work
• Launch a mitigation from an alert


TMS Mitigation Workflow
Sightline/TMS
NETSCOUT University TMS Mitigation

CONFIDENTIAL & PROPRIETARY Workflow - 1
Unit Summary
• Start and manage a TMS mitigation
• Work with Sample Packets
• Understand the difference of DROP and BLOCK actions
• Health monitoring for Mitigations

Unit 7: TMS Mitigation Workflow


Process Overview
Detect the Config and

Provisioning start mitigation
attack
• Create MO Monitor the Stop The Generate

mitigation mitigation report
• Associate
mitigation
details
Our Workflow Focus


Detect the Attack
Detection, Classification and Alerting happens simultaneously
After Sightline generates an alert, you can analyze the alert's statistics and perform a mitigation to reduce or stop
the impact of the attack. Sightline sends a variety of alerts for different network behaviors. These alerts are
categorized first by class and then by type. Sightline tries to aggregate the data into statistically significant
groupings, such as subnets and port ranges. Sightline uses one-minute samples to collect the data for alerts. Flow
records that match the alert are gathered from all Sightline collectors every 60 seconds. These flow records are
parsed network-wide for the following information:
• Ingress and egress interfaces
• Protocols
• Source and destination addresses
• Source and destination ports
• TCP flags used, if applicable

Continued:
Sightline determines alert importance by the default thresholds or the thresholds that you set to determine when a
DoS alert has reached low, medium or high level of importance (Severity Level).
The Severity Percent is the percentage by which traffic in a DoS alert exceeded the configured pps or bps threshold
for a managed object.
Impact indicates the bandwidth that an alert consumes in your network. This is measured by the highest single-
minute sum of alert traffic rates at the managed object’s boundary interfaces.
The direction of the alert traffic (incoming or outgoing).
A graph displays the impact of an attack on the defined boundary of a managed object. Because alerts can be
triggered by traffic that did not traverse the defined boundary of a managed object, this graph can display "No
Data" during the life of the alert. In these situations, after the alert is a few minutes old, the Affected Routers tab
may show data because it displays all the traffic that contributes to triggering an alert. This traffic includes traffic
that did not traverse the defined boundary of a managed object.
Note: The severity percent, impact, and affected router max values will not always match. Non-matching values
can usually be attributed to differences between when and where the measurements are taken for each of the values.
Alert classifications allow you to view whether an alert has been addressed and determine what action you should
take on it. Sightline includes alert classifications in anonymous statistics reports. These reports allow you to view
an end-of-year summary of the percentages of different alert classifications.
You can classify alerts on any alert listing page or on the detail page for a specific alert. You can apply the
following classifications to an alert:
• False Positive – The traffic involved in this alert is not malicious or is a symptom of a network problem. When
you classify an alert as False Positive, the alert no longer appears on the Security Status page or All Alerts page.
If you want to view False Positive alerts, you can search for them using the Alert Search Wizard.
• Flash Crowd – an unexpected spike in legitimate traffic.
• Network Failure – a problem with the network infrastructure.
• Possible Attack – might be malicious, but its nature is still under investigation.
• Trivial – no impact on resources (traffic may have triggered an alert because the traffic threshold is set too low).
• Verified Attack – The traffic involved in this alert is malicious. If you mitigate an alert and do not annotate it,
then Sightline automatically classifies the alert as a Verified Attack.
Optionally, Sightline can be configured notify you and particular groups when it triggers an alert.


Detect the Attack
Analyze the details of the alert to determine if a mitigation is necessary

Summary Tab
Traffic Details Tab

Traffic Details Tab
Summary Tab


Mitigating IPv6
Workflow Protection
No difference in the IPv4 More TMS
workflow for IPv4 versus Countermeasures are
compared to IPv6 IPv6 currently available for
mitigations IPv4
This training focuses primarily on IPv4 mitigations


Configuration
Name
• Taken from the DoS Alert
• Must be a unique name; no
duplicate names possible
Mitigation
Template
• Associated with the MO reported in
the DOS Alert
• You can select a different template
to be used (if needed, required to These options will
press Apply button) be covered later
On the Create TMS Mitigation page that appears, configure the settings for the mitigation. When Sightline
performs a mitigation, it applies the settings from the template you select or from the default template. Mitigation
templates are intended 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, Sightline can even be
configured to make an automatic mitigation response. 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).


Managed Object
• MO associated with this
mitigation, used for reports and
MSSP Access (Visible for MSSP
Protection
user accounts)
Allow Scoped User Access

• Allow Managed Services
(scoped) users to view, edit*,
start*, stop*, or delete* a
mitigation if this Managed Object
is assigned to their account
group
*if they have the necessary privileges

Allow Managed Services User Access check box – (mitigations only) select to allow users to edit, start, stop, or
delete a mitigation if this managed object is assigned to their account group.
Flow Specification Filters can be used by supporting routers to divert only specific packets to a TMS mitigation.
These filters can only be applied when flow specification is used to divert traffic (IPv4 mitigations only).


Protection
Protection Prefixes Use Less Specific Diversion Prefixes

• The destination CIDR being mitigated • Many ISPs will not announce prefixes
more specific than /24 (IPv4)
– Must match selected MO
• Select the network mask length
– Up to 1024 prefixes supported • Only the Protection Prefix is mitigated by
the TMS, rest is passed through


Protection
Timeout Flow Specification Filters

• How long (seconds) before mitigation • Create a rule to divert traffic to the TMS
automatically stops
• Support for IPv4 and IPv6
• Default is no timeout
• Constrain mitigation stream to preserve
TMS resources


TMS Appliances
TMS Group Announce Route

• Select which TMS Group will be used • Permission to send a BGP route / BGP
by this mitigation FlowSpec advertisement for diversion
• Must be enabled for traffic to be
automatically diverted to TMS
• Not available for TMS in Inline mode


Save and Start Mitigation

Saves the mitigation settings and starts the mitigation (announces BGP route and
takes you to the mitigation dashboard)
Save and View Listing

Saves the mitigation settings and returns you to the list of mitigations but does
not start the mitigation


Mitigation > Threat Management
Use Wizard based search
Enter search syntax manually
Several search terms possible – useful for finding active and previously started
mitigations
See Help Menu or User Guide for full list of search terms available


Real Time Mitigation Status Page
Displays detailed
statistics about a
mitigation and
allows you to edit
the counter-
measures being
applied
The TMS Mitigation Status page displays detailed statistics about a mitigation and allows you to edit the
countermeasures being applied to a mitigation. The name of the mitigation is appended to the title of the page.
Real-time mitigation status pages do not require the user to wait a period of minutes or look to sample packets to
verify the mitigation is working properly.
• The Summary tab displays information about that TMS mitigation.
• The traffic graph and summary statistics displays dropped and passed traffic and blocked host totals.
• The Countermeasures tab displays countermeasure-based configurations, graphs and statistics.
• View sample packet data with the Sample Packets button to identify which traffic packets are affected by TMS
countermeasures.


Real Time Mitigation Status Page (Cont.) Type of Traffic Units
Type of Traffic
• Per countermeasure (dropped)
• Per TMS Appliance (dropped)
• Total (passed & dropped)
Units
• bits/sec (bps)
Type of Traffic
• packets/sec (pps) Time Period
Time Period
• Summary (total time)
• Last 30 Minute
• Last 5 Minute
• Other (User-Defined period)


Real Time Mitigation Status Page (Cont.)
• Values refresh every ~10 sec

• Configuration changes take 15-20 sec


Real Time Mitigation Status Page (Cont.)
List of available Countermeasures that can be enabled, updated or disabled as

needed for the active mitigation.


Sample Packets
One of the best tools for performing analysis of packets during mitigation
• Run from the Explore > Packets menu or Real Time Mitigation Status Page
• Runs on a single TMS
• Download up to 5000 packets (default)
• Identify effects of the mitigation countermeasures
• Supported filter options
– FCAP Filter
– DNS Regular Expression*
– HTTP Regular Expression*
– SIP Regular Expression*
– Payload Regular Expression
*a countermeasure forcing application decoding must be enabled
The default recording settings for a PCAP file are 5,000 packets or 60 seconds of recording, whichever occurs first.
You can use the CLI to modify the default settings.


Sample Packets (Cont.)
See which Countermeasures are dropping packets
The main sample packets window displays traffic for the given mitigation. These packets are limited to the
mitigation matches only and not all traffic passing through the TMS.


FCAP Filter
• Used to monitor individual
source addresses, ports or
protocols
FCAP Filter: dst port 16840
• Only related packets
displayed


Display filter on Dropped, Passed or ALL Packets (default)


Select a packet to see the full packet decode


Record Packets – Packet Capture

• Default up to 60 seconds or 5000 packets whichever occurs first
• Settings can be changed on a per TMS base
/ services sp mitigation sample_packets max_packets set 1-100000
/ services sp mitigation sample_packets max_seconds set 1-900
Click the record button to

start recording packets
You can cancel the recording, or
have to wait till it has finished You will be prompted to
COPYRIGHT © 2022 NETSCOUT SYSTEMS, INC. | CONFIDENTIAL & PROPRIETARY 25 save or open the file


Sample Packets with Display Filters
Countermeasures with filtered Sample Packets
• TCP SYN Authentication
• TCP Connection Reset
• DNS Malformed
• SIP Malformed
• HTTP Malformed
• All regular expression

countermeasures*

*not supported when ‘Apply to Packet Header‘ is selected
Many countermeasures also provide filtered sample packets buttons pre-filtered to view packets specific to that
countermeasure.


Mitigation Summary Report
A Mitigation Summary Report (PDF) can be downloaded or emailed at

any time


Mitigation dropped Traffic Level in the DOS Alert
x.x.141.233
Once the mitigation

starts, the Alert
Dropped Traffic
graph will reflect
dropped traffic due
to the selected
mitigation actions
Many countermeasures provide blocked hosts lists for download directly from the mitigation pages. This alleviates
the need to run pktengine-client from the shell to gather these stats on hosts that are being blocked.

Block versus Drop

Block versus Drop

TMS Traffic Actions
The following decisions are made while processing the data received by the TMS
Action Reason Meaning
DROP Packet was explicit dropped The packet violated the enabled countermeasure
settings and forwarding was prohibited
Packet was blocked due to All traffic from a malicious host is dropped for a
host on Deny List certain amount of time (60 or 300 sec. intervals)
PASS Packet was explicit passed The packet was allowed, aka explicit approved to
pass the TMS
Packet was forwarded The packet was forwarded by TMS as all
enabled countermeasure checks were
successfully passed

Block versus Drop

Dynamic Host Blocking, aka Deny List
Countermeasures using dynamic host blocking identify source hosts that

violate appropriate behavior
• Offending Host added to Deny List
All traffic from offending Host is blocked (discarded, on a per mitigation base)
☣1 minute (first offense)
☣5 minutes (repeat offenses)
• After blocking time
1) The host is removed from the Deny List
2) Traffic is processed again
3) If the host continues to offend it will be added to the Deny List again
dynamic. Deny List is a host blocking that is dynamically invoked by some countermeasures. When a
countermeasure identifies a pattern of unwanted packet behavior from a particular source host, the host is blocked
for a configured time period. Deny List assumes that additional packets from that host will also be unwanted, so
Deny List drops those packets efficiently without allowing any countermeasure to waste resources checking those
packets. Packets from a host in the Deny List are counted as dropped by the countermeasure that put the source
host on the Deny List.
dynamic. Deny List Hosts are evaluated independently for each mitigation. A host that is blocked by one mitigation
might be able to send traffic through the same TMS device to destinations protected by a different mitigation.
Some countermeasures that have configured maximum rates are not rate-shaping countermeasures but
instead are Deny List countermeasures that use those rates as standards of misbehavior. Some
authenticating countermeasures are also use the dynamic. Deny List countermeasures. These specifics
are covered subsequently in the discussion of each countermeasure.

Block versus Drop

• Represented as Blocked Hosts on the mitigation dashboard

• Blocked hosts can be downloaded
Downloads a list of Downloads top 1000

current blocked hosts as hosts during life of
text file mitigation as text file
The blocked host list that can be downloaded via the UI are updated on a regular base and not
instantaneously, therefore it can take a few seconds before a newly added host will be included

Block versus Drop

Action Countermeasure
DROP Action Countermeasure OPT TCP Connection Reset
Drop a single packet OPT Payload Regular Expression
DROP Invalid Packets
DROP DNS Malformed
DL DROP (Deny List)
DL DNS Rate Limiting
Deny List - adding src OPT IPv4 Address Filter Lists
DL DNS NXDomain Rate Limiting
IP to be dynamically OPT IPv4 Deny/Allow Lists
denied OPT DNS Regular Expression
DROP Packet Header Filtering
DL HTTP Malformed
DROP IP Location Filter Lists
OPT DL Zombie Detection
DL HTTP Rate Limiting
Choice of Drop or OPT AIF and HTTP/URL Regular
OPT UDP Ref./Amp. Protection
Deny List Expression
OPT Per Connection Flood Prot.
DL TLS Negotiation
DROP TCP SYN Authentication
DL SIP Malformed
DROP DNS Authentication
DL SIP Request Limiting
OPT TCP Connection Limiting
DROP IP Location Policing
DROP UDP Session Authentication
DROP Shaping
Countermeasures act primarily using one or more of the following four enforcement types:
• Filter countermeasures including payload countermeasures either drop or pass individual packets or datagrams
based on a match criteria. Traffic acted upon by a filter countermeasure is not evaluated by later
countermeasures.
• Authenticating countermeasures intercept or drop all matching traffic until a validating condition is observed.
Validated source hosts or flows are added to an approved list until they become idle for a given period.
• Rate-shaping countermeasures count matching traffic and compare the matching traffic rate to a
configured value. When the set rate is exceeded, packets are dropped until the average non-dropped
traffic rate returns to the set rate or lower. The system is designed to allow significant traffic bursts
before shaping is triggered.
• Deny List countermeasures identify source hosts that violate situationally appropriate behavior and
add those IP addresses or flows to a dynamic block. All traffic from a source on the dynamic. Deny List
is dropped for a period of one minute. After a source is removed from the dynamic. Deny List, it
remains in the cache until the cache entry is overwritten with a new source. If the same source is
added again while it is in the cache, it is moved to a repeat-offender dynamic. Deny List and blocked
for five minutes.

Countermeasure Processing Order


Processing Types
Per-Packet
Some Countermeasures can take a decision based on seeing a single packet
Event-Driven
Some Countermeasures need to see a sequence of packets to take a decision
The available Countermeasures on the TMS are processed

in a strict order to be predictable and efficient


Per-Packet • Invalid Packets
Invalid Packets Drop Packet
• Deny List
Deny List
IP Address Filter Lists

• IP Address Filter Lists Block src IP
Deny / Allow Lists

• Deny / Allow Lists Drop or Block
Packet Header Filtering

• Packet Filter Header
Block or Rate Limit
IP Location Filter Lists
• IP Location Filter Lists
Zombie Detection • Zombie Detection
UDP R/A Protection • UDP Reflection/Amplification Protection
Per Conn. Flood Protection
or Rate Limit
• Per Connection Flood Limiting
TCP SYN Authentication • TCP SYN Authentication (including HTTP Auth.)
DNS Authentication • DNS Authentication (except for active modes)
Payload Regular Expression • Payload Regular Expression Filtering
Protocol Baselines
• Protocol Baseline Enforcement
IP Location Policing
or Rate Shape • Shaping
Shaping
• IP Location Policing
Pass Event-Driven CMs Drop
Countermeasures are defense mechanisms that you can use to target and remove attack traffic. Countermeasures
act primarily using one or more of the following four enforcement types:
• Pass packets
• Drop packets
• Block source IP address or flow
• Rate limit/shape
Different countermeasures are designed to stop different types of attack traffic. TMS uses the following types of
countermeasures:
• Per Packet (IPv4 and IPv6)
• Event Driven (IPv4 only)
(Continued)

Continued:
The TMS forwards each packet received on a TMS mitigation interface to one or more ongoing
mitigations. Each mitigation processes the packets it receives against all of the countermeasures that are
enabled (set ON) in that mitigation. The countermeasures process packets in the order shown. However,
if a packet was sent from a host that is currently on the TMS dynamic. Deny List, the TMS blocks the
packet. Packets that are blocked by dynamic. Deny List are not processed by countermeasures in any
mitigation.
Per Packet countermeasures are applied to every packet that matches the prefix associated with a mitigation. Per-
packet countermeasures are processed before event-driven countermeasures. The TMS forwards each packet
received on a TMS mitigation interface to one or more ongoing mitigations. Each mitigation processes the
packets it receives against all of the countermeasures that are enabled (set ON) in that mitigation. The
countermeasures process packets in the order shown.
dynamic. Deny List countermeasures (optional on some) identify source hosts that violate situationally
appropriate behavior and add those source IP addresses or flows to the Deny List . Authenticating
countermeasures intercept or drop all matching traffic until a validating condition is observed. Validated
source hosts or flows are added to an approved list until they become idle for a given period. Rate-
shaping countermeasures count matching traffic and compare the matching traffic rate to a configured
value. When the set rate is exceeded, packets are dropped until the average non-dropped traffic rate
returns to the set rate or lower. The system is designed to allow significant traffic bursts before shaping is
triggered.


Event-Driven TCP Flows TCP Connection Reset
Drop Packet
TCP Connection Limiting
Block src IP
DNS Malformed
DNS Queries Drop or Block
DNS Rate Limiting
DNS Regular Expression
DNS Responses
DNS NXDomain Rate Limit
HTTP Malformed
HTTP Request HTTP Rate Limiting
AIF and HTTP/URL Regex
SIP Malformed
SIP Request
SIP Request Limiting
TLS
TLS Negotiation
Event Driven (IPv4 only) – This type of countermeasure is divided into the following groups:
• Application-specific stream-based — TMS identifies the traffic stream with an application ID before it applies
the countermeasure.
• Time-based — Timers detect specific events. For example, the TCP Connection Reset countermeasure drops
traffic when a connection remains idle for too long.
Event driven countermeasures are processed asynchronously based on when the appropriate packets that make up a
given stream are assembled or when the timers for a time-based countermeasure expire. All countermeasures
currently implemented this way are considered event driven. Generally, the per packet process performs
preliminary checks to assist the event driven process, and the event driven process manages most packet drop
decisions and host blocking.

Mitigation Issues

Mitigation Issues
TMS Fate Sharing Options
Mitigation will be stopped in case of failure

• Component Failures (CPU, processes, interface, power supply)
• Group Membership Failures (device group)
• Diversion Failure
– Interface down (reinjection interface down)
– Next-hop unavailable (ARP for next-hop on reinjection interface fails, every 10 sec.)
– GRE tunnel down (GRE tunnel keepalives failing for GRE reinjection tunnel)
– BGP session down (BGP Peer for diversion signaling is down for that TMS)
• TMS Isolation (No communication between TMS and Sightline Leader)
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.

Mitigation Issues
TMS Fate Failure Process
Fault Process
I. TMS detects one or more Fate Sharing relevant issues
II. Sightline leader is notified about issues
III. TMS Group setting may take the complete group offline

Mitigation Issues
TMS Fate Sharing Options
• If a TMS detects an issue, the

TMS or the complete TMS group
will suspend (out-of-service) the
running mitigation
• The event will be logged in the

Annotations section
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.

Mitigation Issues
TMS Fault Considerations
• Mitigation Preconditions can be overridden

• One TMS will take the entire group offline (default)
• A TMS failure should not overwhelm the remaining TMS Appliances in
a group
• Mitigations must be manually restarted once the issue is repaired
− Does not happen automatically
• Power-Supply Failures do not take the TMS offline
− Unless it is the last power supply
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.

Knowledge Check
Q1: Sample Packets will show all packets Q3: The PCAP file generated by Sample
processed by a TMS. Packets > Record will not include packet
payloads.
a) yes
a) yes
b) no
b) no
Q2: Which statement is correct?
Q4: Deny List uses which timings?
a) Pass statements cause the packet to be checked
by the next countermeasure that is enabled a) random selected blocking times
b) Pass statements will allow traffic and does not b) 5 minutes for repeating offenders
perform any other checks
c) always 5 minutes
c) Deny List will only drop individual packets
d) starts with 1-minute intervals
d) Deny List will cause all packets to be dropped
Solution: Q1: b Q2: b,d Q3: b Q4: b,d




Step2
• Lab Objectives: TMS Mitigation Workflow

• Managing TMS Mitigations


• Start and manage a TMS mitigation
• Work with Sample Packets
• Understand the difference of DROP and BLOCK actions
• Health monitoring for Mitigations



Volumetric Attacks
Sightline/TMS
NETSCOUT University Volumetric

CONFIDENTIAL & PROPRIETARY Attacks - 1
Unit Summary
• Identify volumetric Attacks
• Use and configure filters and filter lists
• Use Zombie Detection successfully
• Shape (police) traffic levels

Flooding Attacks
Unit 8: Volumetric Attacks

Flooding Attacks
Overview
Traffic to
one or Spoofed Looks like
or non- Reflection
Description more normal
Attacks
protocols spoofed Traffic
or ports Traffic
Sightline Detection
Host Detection Profiled Detection
Capabilities
TMS Mitigation Zombie Detection UDP Reflection/Amplification Per Connection Flood

Countermeasures Deny/Allow Lists HTTP/DNS Rate Limiting Payload RegEX Filtering
UDP flood Reflection Attacks BlackEnergy

Attacks
Mirai Botnet Variants Memcached
Generic flood attacks are simply large amounts of traffic that are intended to overwhelm the ability of the victim to
function. Flood attacks may be generic traffic in sufficiently large quantities to overwhelm the network
infrastructure or the victim host network interface, or floods may be directed at particular IP protocols and protocol
ports in an attempt to overwhelm a particular network application. Unwanted flood traffic can be difficult to
differentiate from normal traffic except by quantity, since real packets are often used for flood attacks and spoofed
source addresses may create difficulties for identification of a network source for a flood.
Some network floods are not attacks but instead are “flash crowds” (i.e.. unusual numbers of legitimate users).
Flash crowds may still be a threat to a host if their traffic volume is more than the host is able to service.

Flooding Attacks
UDP Floods
Easy to Allows
UDP is Allows
Description spoof Traffic
stateless Traffic
source IP Reflection Amplification
address
Sightline Detection
Capabilities
High rate of packets Collateral Damage Attack Amplification
Attack Pattern
1Mpps @ 60bytes = 480Mbps 1Mpps @ 1250bytes = 10Gbps
Invalid Valid Network TCP

Attack Vector UDP UDP Infrastructure Services
Services Services
UDP is stateless, making it good for floods of traffic

Spoofing source IP addresses is possible
Generation of UDP packets is easy
Packet sizes may range from 60 to 1500 bytes

High volume of small packets can cause forwarding issues for routers, firewalls and
other inline devices
1Mpps @60bytes = 480Mbps (1.000.000 x 60 x 8 = 480.000.000)
1Mpps @1250bytes = 10Gbps (1.000.000 x 1250 x 8 = 10.000.000.000)
DNS is the primary attack target with UDP

DNS Amplification floods can generate a high rate of large UDP packets
Do not generally impact the server (unless DNS) but do impact the infrastructure causing
collateral damage
Can cause jitter and latency, impacting services like VoIP
Some attacks use UDP toward TCP-based services such as the web

Flooding Attacks
Fragmentation Attacks
Targeting Targeting Targeting Bypassing

Description Fragment Security Layer 7 Security
reassembly Appliances Appliances Policies
process
Sightline Detection
Capabilities
TMS Mitigation
Invalid Packets Deny/Allow Lists Zombie Detection
Countermeasures
Teardrop Rose Attack

Attacks
Fragment Overrun Targa Nestea
Fragmentation attacks are floods of unwanted IP packet fragments. They are designed to overwhelm the victim
host’s ability to process incoming traffic by filling the host’s receive buffers with fragments. IP standards call for a
receiving host to store packet fragments until the other fragments of that packet arrive and the packet can be
reassembled. If the other fragments are never sent, the original fragments remain in the victim’s buffers until a
timeout marks them as too old. Too many fragments can prevent a host from having the buffer space needed for
receiving legitimate traffic. Fragments are often malformed as well and can cause other types of collateral damage.
IP fragments are a standard way of handling IP packets that are too large for part of the network infrastructure.
Some fragment floods consist of legitimate traffic passing through a poorly designed or misconfigured network
before reaching the impacted host.

Invalid Packets

Invalid Packets
IPv4 Checks
Invalid packet checks apply to every ✓ Malformed IP Header
mitigation ✓ Incomplete Fragment
✓ Bad IP Checksum
• Always enabled on active mitigations
✓ Duplicate Fragment
• The first check before further processing
✓ Fragment Too Long
• Stops some attacks all by itself ✓ Short Packet
✓ Short TCP Packet
✓ Short UDP Packet
✓ Short ICMP Packet
✓ Bad TCP / UDP Checksum
✓ Invalid TCP Flags
✓ Invalid ACK Number
Invalid Packets is a per packet countermeasure that ensures that all incoming frames are valid IP packets and that
basic IP header requirements are fulfilled. Any frame that does not meet these standards is dropped.
This countermeasure is always enabled for a mitigation and is not configurable in any way. Frames that are dropped
are counted according to the type of packet check violation.

Invalid Packets
IPv6 Checks
✓ Malformed IP Header ✓ Out of Order IPv6 Extension
Invalid packet checks apply Headers
✓ Incomplete Fragment
to every mitigation ✓
✓ Duplicate Fragment Bad Hop-by-Hop Options
• Always enabled on active ✓ Fragment Too Long ✓ Incorrect IPv6 Payload Length
mitigations ✓ Short Packet ✓ Jumbo Option Inconsistent with
• The first check before ✓ Short TCP Packet IPv6 Header
further processing ✓ Short UDP Packet ✓ IPv6 Route Type 0 Headers
✓ Short ICMP Packet
• Stops some attacks all by
✓ Bad TCP / UDP Checksum
itself
✓ Invalid TCP Flags
✓ IPv6 MTU Violation
✓ Duplicate IPv6 Extension
Headers

Filter Lists

Filter Lists
Overview
Filter Lists can reduce the processing load on the TMS
o Limiting the amount of traffic that needs to go through all countermeasures
o If a packet matches, no further processing will be done
Sightline can automatically import Filter Lists from external sources

o Filter Lists are configured globally
o Filter Lists can be pre-assigned via template or added on the fly
o Multiple filters can be selected simultaneously
Filter lists are often compared to ACLs

o Drop Statement – Traffic is explicitly dropped
o Pass Statement – Traffic is explicitly whitelisted, no further inspection

Filter Lists
Use Cases
Pass lists (Allow Lists)
o Known partner networks
o Approved remote workers
o Known secure clients
Block lists (Deny Lists)

o Security group infected subscriber lists
o Third-party tool bot and infected host lists
o Networks or countries without legitimate use case
All are cases where a known list is used repeatedly in many mitigations

Filter Lists
Types
Deny/Allow List Uses FCAP expressions to identify traffic
IP Address List Uses CIDR blocks to allow or deny
≥9.3.x NEW
≥9.3.x ASERT provided list of IP addresses from known
AIF List attack reflectors
Regular expressions that search for DNS queries

DNS List and responses
HTTP/URL List Regular expressions that search HTTP queries
Uses GeoIP data to identify traffic from specific

IP Location countries

Filter Lists
IP Address Filter
User-defined list(s) of IP addresses/CIDR blocks

• Towards the top of the processing order, immediately after the Blocked Host list
• IP address sources that are known in advance can be processed immediately
– Sources known to be desirable can be forwarded (PASS list)
– Sources that are untrusted can be blocked (DROP list)
– No further processing is performed on packets matching the selected list/lists
• Reminder: filter list processing is efficient
– Skillful use of filter lists can make better use of mitigation countermeasure processing
capacity
IP Address filter lists are user-chosen lists of IP addresses that are configured in Arbor Sightline for use in TMS
mitigations. IP Address filter lists are a per-packet countermeasure. They are evaluated as the first configurable
countermeasure so that IP address sources that are known in advance to be undesirable can be dropped
immediately, and sources that are known in advance to be desirable can be forwarded immediately. No further
countermeasure evaluation is done on any traffic matching selected IP address filter lists, and filter list processing is
efficient, so skillful use of filter lists can make better use of mitigation countermeasure processing capacity for only
those sources that are suspect or unknown.
IP address filters can be a mix of CIDR blocks and single IP addresses. An IP address filter may include up to
50,000 address elements on TMS 1200 or 2500 hardware and up to 150,000 address elements on TMS 3000 or
4000 hardware. The large permitted size of a filter list allows large lists of individual IP addresses to be uploaded
from external host oriented tools for detecting compromised hosts. Such lists are an expected use example for IP
address drop filter lists. An expected use example for IP address pass filter lists is to approve remote branch office
address blocks and lists of recent VPN user addresses.

Filter Lists
Deny/Allow Filter List
IPv4 Deny/Allow Lists includes three similar FCAP based filter

mechanisms
• Inline Filters
– Ad hoc filter that is configured specifically for this mitigation
• Deny/Allow Filter Lists
– Selected from global Filter-Lists configured in Sightline
– Usually externally managed filters, uploaded into Sightline
• Deny List Fingerprints
– May be derived from AIF threat policies automatically downloaded
– May be derived from previously configured fingerprints in Sightline

Filter Lists
Deny/Allow Filter List – Example
Inline Filter list can be populated by copying FCAP from alert

Scratchpad

Filter Lists
Deny/Allow Filter List – Example (Cont.)
FCAPs can also be created with the FCAP Wizard

Filter Lists
Deny/Allow Filter List – Use Cases
FCAP format to explicitly DROP or PASS traffic

• Use case: known sources to PASS
– Partner networks, megaproxy, NOC/SOC pass src net 102.12.33.0/24
• Use case: known sources to DROP
– Repeat offenders, spoofed sources drop src host 171.16.49.133/32
• Use case: not required ports and protocols
– Filter what is not needed drop proto udp and dst port 80
drop dst port 80 (only SSL/443)
• Other use cases:
– Pass Google crawler traffic
– Pass web-analytic sites (netcraft, etc.)
– Users that contact support during a mitigation
Example, if the mitigation protects a server group that obtains content from other sources, the connections to those
other sources should be added to a Deny/Allow Filter List filter in a “pass” rule, because they are already known to
be legitimate and they should be exempt from mitigation countermeasures.
Alternatively, if bandwidth is being consumed by legitimate-appearing traffic of a type that is unused by the
protected hosts, such as DNS directed at web servers, those traffic characteristics could be added to a Deny/Allow
Filter List filter in a “drop” rule.
Deny/Allow List filter “drop” rules are also commonly used to consistently drop particular types of traffic from
hosts or networks that have been identified as chronic offenders rather than allowing TMS to continually reevaluate
whether to allow that traffic.

Filter Lists
FCAP Examples
Web Server (HTTP and HTTPS)

drop not (proto icmp or proto tcp)
drop proto tcp and not ((src port 1024..65535 and dst port 80) or (src port 1024..65535 and
dst port 443))
drop proto icmp and not ((icmptype 3 and icmpcode 4) or (icmptype 11 and icmpcode 1))
Authoritative DNS Server

drop not (proto icmp or proto udp or proto tcp)
drop proto tcp and not ((src port 53 or src port 1024..65535) and dst port 53)
drop proto udp and not ((src port 53 or src port 1024..65535) and dst port 53)

Filter Lists
FCAP Examples (Cont.)
Recursive DNS Servers

drop not (proto icmp or proto udp or proto tcp)
drop proto tcp and not ((src port 1024..65535 and dst port 53) or (src port 53 and dst port
1024..65535))
drop proto udp and not ((src port 1024..65535 and dst port 53) or (src port 53 and dst port
1024..65535))
SMTP MTA
drop not (proto icmp or proto tcp)
drop proto tcp and not ((src port 1024..65535 and dst port 25) or (src port 25 and dst port
1024..65535))

Filter Lists
Default IPv4 Deny/Allow Filter List
Filter list is pre-configured

• Targets invalid traffic which should be dropped for all mitigations
• Default can be changed
drop proto 0
drop proto icmp
drop net 127.0.0.0/8
drop net 10.0.0.0/8
drop net 172.16.0.0/12
drop net 192.168.0.0/16
drop net 224.0.0.0/4
drop net 240.0.0.0/4
The Default Deny/Allow filter lists is a special case of Deny/Allow Filter List. The Default Deny/Allow Filter
List is pre-configured by the system software. The FCAP expression that defines the Default Deny/Allow
Filter List can be modified and saved to fit local network needs, but the Default Deny/Allow Filter List can
never be deleted. It is therefore always available to all mitigations, but it is not active for a mitigation
unless it is selected.
The pre-configured FCAP statement for the Default Deny/Allow Filter List drops traffic to well-known
private address spaces, to multicast addresses, and ICMP, along with some illegal traffic combinations.
The administrator needs to adjust those rules if legitimate traffic to or from private IP addresses or
multicast might be mitigated by a TMS device.
(Continued)

Continue
Alternatively, if bandwidth is being consumed by legitimate-appearing traffic of a type that is unused by the
protected hosts, such as DNS directed at web servers, those traffic characteristics could be added to the
Deny/Allow Filter List filter in a “drop” rule. Deny/Allow Filter List filter “drop” rules are also commonly used to
consistently drop traffic from hosts or networks that have been identified as chronic offenders rather than allowing
TMS to continually re-evaluate whether to allow that traffic.
The Fingerprints selector is used for the same reasons, except that the filter rules have been previously defined as
fingerprint objects. Fingerprints are usually defined for known threat traffic, such as protocols and ports used by
particular worms and viruses. The Fingerprints selector allows the definition of any fingerprint to be added to the
Deny/Allow Filter List as a “drop” rule.
Note: Fingerprints can be resource intensive

Filter Lists
Assigning Deny/Allow List
One or more Deny/Allow filter list can be selected when configuring a

mitigation

Filter Lists
Assigning Deny/Allow List (Cont.)
Inline Filters
• Freeform FCAP filter
• Configured before or during
Mitigation Drag and
drop to
IPv4 Deny/Allow Filter List reorder
• From mitigation template used or each filter
selected during mitigation list
Deny List Fingerprint

• From mitigation template used or
selected during mitigation
The filter list processing order can be adjusted by dragging and dropping each individual list. Remember
that each list will be processed in top-down order. For example, consider the above image. The Deny /
Allow Filter List called “Default IPv4 Deny / Allow ” will be processed before “My Favorite Martians”, and
so on. This is an important point to consider, especially if some of your filter lists have larger CIDR blocks
or pass statements in them, which may unintentionally pass or block traffic if those lists are put higher in
the processing order.

Filter Lists
IP Location Filter
• IP Location filter lists are selected IP Location country codes

– Allows you to leverage existing IP Location data
• IP Location country codes use large lists of associated IP
address prefixes to match traffic
– IP Location country lists are a special extension of IP address filter lists
• IP Location filter lists are globally configured or uploaded
• Mitigations can use any IP Location filter list to match traffic
– Drop or pass is a mitigation countermeasure setting
– Rate Shaping is not supported
IP Location filter lists are assembled from one or more geographic country objects that are loaded in Arbor
Sightline 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 Sightline. Each IP Location filter list is configured in
Arbor Sightline 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.

Filter Lists
Assigning IP Location Filter
IP Location lists can be selected within the mitigation configuration or

the Mitigation Dashboard

UDP Reflection and Amplification


Overview
While like the Deny/Allow Lists in

behavior, it comes later in the
packet processing order
• Useful if you need to pass some
legitimate traffic (using pass lists)
before applying this countermeasure
• It provides detailed individual drop
statistics
• Can be automated through the Alert
Misuse Types detected


Configuration
• Built to handle most common

UDP DDoS attack vectors Enable these options to
automatically select filters
• Can be configured to either drop that match the Misuse types
in the alert
or block offending external hosts
• Uses predefined FCAP filters


Additional Match Criteria
Expand any of the filters to add additional FCAP match criteria
Especially handy
for DNS and other
traffic that can be
legitimate outside
traffic and you
don’t want to drop
ALL of it
Click the Test Filter to open the Sample Packets screen


Zombie Detection

Zombie Detection
Overview
Zombie Detection is a generally useful countermeasure against flood,

TCP SYN, and protocol attacks
• Source addresses (hosts) that exceed pps or bps threshold are blocked
☞ Utilize the learned dataset or know your service!
☞ Top Talkers External in pps will help with values
☞ Most web-based services have a low client but high server packet rate
• Easy way to drop traffic for spoofed floods, such as UDP, that use a limited
number of source addresses
Zombie Detection is a per-packet countermeasure that identifies and blocks hosts that are sending excessive
amounts of traffic to the protected hosts or networks.
Zombie detection monitors overall bit rates and packet rates for traffic from each source host. Once every minute,
the zombie countermeasure checks the bit rate and traffic rate for traffic from each source host during the previous
minute. If either the BPS or PPS zombie threshold has been exceeded by that host, the host is added to the Deny
List. Zombie detection continues to monitor the bit rates and packet rates of hosts on the Deny List and to evaluate
those counters every minute. If traffic from the Deny List host drops below the zombie thresholds for one minute,
the host is removed from the Deny List . One minute data is used by zombie detection to reduce the possibility that
short term high traffic spikes lasting seconds do not trigger zombie blocking. If a host is put to the Deny List for
consecutive 1-minute periods, its period increases to 5 minutes.
(Continued on next page)

Continue
The original design goal of zombie detection was to block traffic from bot-infected “zombie” hosts that send traffic
flood attack packets at a constant rate with no regard to return traffic. These include more specific attacks such as
TCP SYN floods and protocol flood attacks. However, zombie detection is useful for controlling the rate at which
any host may send traffic, including to prevent connection table and request table exhaustion attacks, and also to
prevent some user-initiated actions such as bulk content downloads and peer-to-peer file hosting.
When zombie detection is enabled, zombie thresholds should be set at rates higher than any legitimate host would
be expected to send on a sustained basis. These may vary depending on the services offered by protected hosts. In
most cases, the protected hosts are content servers and the source hosts are clients that should be sending only
requests and acknowledgements, so the expected traffic rates will be quite low.
Zombie thresholds often need to be set higher than defaults when source hosts are expected to upload large amounts
of content to the protected hosts.

Zombie Detection
Flexible Zombie
• Flexible Zombie requires FCAP filters to monitor specific traffic for

abusive amounts
– Allows handling very specific attacks
– Applied early in the processing order
• Up to 5 Flexible Zombies can be defined per mitigation in addition to
global All Hosts Zombie
– Works with or without All Hosts Zombie
– No Learned Dataset support for Flexible Zombies
The Zombie Detection countermeasure includes a set of 5 configurable “Flexible Filters” in addition to the existing
All Hosts threshold configuration. The conventional All Hosts countermeasure checks traffic rates from all sources
regardless of traffic type. The Flexible Filters allows the application of filters to the incoming traffic in order to
narrow the scope of the search for hosts sending abusive amounts of traffic. For example, a Flexible Filter can be
configured to check specific traffic rates from just certain IP subnets, or check traffic rates for certain types of
packets (TCP SYN+ACK packets, for example), and Deny List offenders from this subset based on customized
threshold rates.
Up to 5 Flexible Filters can be defined per IPv4 or IPv6 mitigation. Also, the conventional thresholds
applied to all sources are still available for the configuration of the traditional All Hosts operation (where
all traffic is evaluated).
Flexible Filters (Flexible 1 through Flexible 5) combine a matching criteria specified by FCAP statements with
specific thresholds in bps and pps that - once exceeded - will result in the source address being added to the Deny
List.

Zombie Detection
Flexible Zombie (Cont.)
• Traffic scoping allows a more precise evaluation and detection of

malicious traffic
• Effective mitigation without the need for more complex
countermeasures
Regular Zombie Flexible Zombie
(Abusive host undetected) (Attack vector identified)
Total Traffic Attack Vector Ex: proto icmp
Rate Traffic Rate
“All Hosts” Threshold
“Flexible 1” Threshold
Malicious Legitimate Malicious Legitimate

Host “Chatty” Host Host “Chatty” Host

Zombie Detection
Flexible Zombie (Cont.)
All Host
1 Gbps
Flex 1
& protocol esp
200 Mbps
10 Kpps
Flex 2
1 kpps protocol tcp
Flex 3
protocol tcp and fragments
250 pps
Flex 4 protocol icmp

100 pps
Host is added to the Deny List when

exceeding any configured pps or bps threshold

Zombie Detection
Configuration
Global
‘All Hosts’ Thresholds
Flexible Filter n:
FCAP Filter + Thresholds
Offending hosts will

be placed on the
Deny List
The Zombie Detection countermeasure uses configured bps and/or pps threshold values to identify and block hosts
(“zombies”) that send excessive amounts of IPv4 or IPv6 traffic to protected hosts or networks. This packet-based
countermeasure can protect against common attacks including flood, TCP SYN, and protocol attacks.
Configure the Zombie Detection countermeasure when creating or editing a mitigation or mitigation template or
from the TMS Mitigation Status page.
To enable the Zombie Detection countermeasure specify a bps or pps value for All Hosts Zombie Type and Save.
Or for Flexible Zombies specify a bps and/or pps rate and a filter (SYN flag, packet size, etc.) to identify a traffic
flow then Save. Only packets matching the filter are counted to determine if a host should be blocked. If the rate is
exceeded per source address, then the host is added to the Deny List.

Zombie Detection
Monitoring
Each Zombie can be

visualized and configured
• All Hosts: shows the
thresholds for the global Use slider
to adjust
Zombie operation values
• Flexible 1 → 5: shows a
single Flexible Zombie
configuration and its
statistics
Graphs show levels of traffic

passed and dropped

Proxy List Threshold Exemption


Overview
Rate Based countermeasure thresholds need to be increased for some

sources that transmit at high rates
• Typical sources
– Host aggregators (e.g., Proxies or NAT Gateways)
– High-traffic, special-use hosts (e.g., mail servers, network management tools)
• Solution
– Single rate multiplier + proxy list per mitigation not per countermeasure
• Affected countermeasures
– Zombie Detection, DNS Rate Limiting, HTTP Rate Limiting and SIP Rate Limiting
Network administrators can augment threshold limits of affected countermeasures for cases where traffic
is sourced from known proxies, NAT routers, or high-traffic, special-use hosts such as mail servers or
network management tools. Up to 50 IPv4 or IPv6 CIDR prefixes may be added to a proxy list for each
mitigation or mitigation template.
A single scale multiplier is used for all affected countermeasures and for all proxy list sources. The scale
multiplier can multiply thresholds by as much as 1000, although multiples in the range of 5 to 25 are more
typical. Proxy list sources that violate the scaled threshold for a countermeasure are blocked in the
normal manner for that countermeasure.


Configuration
Multiplies the countermeasure threshold rates by specified Scaling

Factor for the listed Proxy Source CIDRs
• Changes apply to all affected countermeasures
Gear button → advanced

configuration for proxies
Proxy list threshold exceptions can be set in a running mitigation by clicking the “settings gear” icon in the
upper right corner of the status pane of any affected countermeasure. The settings icon leads to a single
settings pane per mitigation, and any proxy list settings changes will be applied to all affected
countermeasures

Per Connection Flood Protection


Overview
• Mitigates traffic on any

connection that exceeds the
After some
configured maximum time, slider
and graphs
become
available and
• Much like Zombie Detection or show traffic
levels
Shaping, except on a per-
connection basis (5-tuple)
instead of per-source address
basis
The Per Connection Flood Protection countermeasure monitors IPv4 traffic on a per-connection basis (5-tuple)
rather than on a per-source basis. When the IPv4 traffic of any connection exceeds the maximum configured rates
for bps or pps, then the countermeasure can block all of the traffic of that connection or limit the rate of the traffic
of that connection.


Configuration
Limit the amount of traffic that can be send through a single connection
(5-tuple)
Specify the ports
Block source IP or rate

limit the session
max permitted throughput

per connection
5-tuple = src IP + dst IP + Protocol + src Port + dst Port



Options
• Rate limit protection on a connection 5-tuple:

– source/destination IP addresses
– protocol
– source/destination ports
• Enabled for all, multiple, or specific TCP and UDP ports
– At least 1 TCP or UDP port must be specified
• Can block or rate limit offending connection
• Intended where Zombie Detection by source host is impractical (NAT,
Proxies, …)
You can use the Per Connection Flood Protection countermeasure when adding the source host to the Deny List of
the offending traffic is not a good option. For example, if the attacker is behind a NAT, you can use this
countermeasure to block or rate limit the traffic of an attacker’s connection without adding the host to the Deny List
for legitimate users who are also behind the same NAT.


Overview
Mitigate traffic from either specified or unspecified countries

• Limit traffic rate or block traffic
• Useful when other countermeasures are ineffective
• Rate suggestion possible per configured Managed Object
• May block some legitimate traffic due to:

– Geographic inaccuracy and flux
– IP space can span broad geographic expanses
– Normal users present in unexpected geographic region due to travel or
migration
Rate suggestion possible per configured

Managed Object
• Must be enabled ahead of time (takes several days!)
• Can establish pre-attack level country base rates
Some risk can be reduced by using rate limits instead of a drop action for countries that need some
blocking but are expected to contain legitimate users

IP Location Policing Rate Suggestion
• Supported only for IPv4-based Managed Objects

• Select the Generate IP Location Policing Rate Suggestions check box to collect
per-county rate statistics
Must be selected well

in advance of mitigation
• Rate suggestions used in the IP Location Policing countermeasure


Mitigation Template
Select the Load All Countries and Rates on Mitigation Start check box
in the mitigation template
Can also be
controlled from
the Mitigation
Status page

Adding a Country
Select the Enable IP Location Policing check box to enable this countermeasure. The Load All
Countries button (TMS Mitigation Status page only) adds all of the countries’ traffic for which Arbor
Sightline has data. The Load Rates button loads the generated rates for all countries whose configured
actions are “rate shape”. To load rates, the Generate IP Location Policing Rate Suggestions setting must
be selected on the Mitigation tab for the protected managed object.
The Add Country button is used to specify a country whose traffic should be policed. After selecting a
country, use the dropdown menu to select action, default is “allow all” traffic, there are no further
parameters for “allow all” and “drop all”.

Updating a Country
Edit a
Country
Delete a
Country
Rate shaping can utilize per country rates that are learned by Sightline from flow data, or by manually
configured rates. Boxes appear to manually set enforcement rates when “rate shape” is selected.
Note: It makes sense that IP Location Filter block/pass occurs before zombie but the IP Location Policing
Rate Limiting should likely occur after zombie. The idea is to drop all traffic from an individual high rate
zombie before the zombie’s traffic can potentially impact good traffic from the country. As it is, a single
potential zombie could take up most of a countries rate-limit. Depending on the settings, if rate-limiting
first, zombies may not be identified.

Traffic Shaping

Traffic Shaping
Overview
Limit attack traffic to a level that allows protected hosts to function

• Should be used when all other countermeasures are not removing enough
– Up to 10 virtual queues to shape traffic individually
– Typical for Flash crowd control
– Slow down attack while analyzing for more specific countermeasures settings
– Does not differentiate between legitimate and unwanted traffic
• Shaping is done before traffic is sent to the application decoders
– Packets dropped by Shaping can negatively affect event-driven countermeasures
Shaping is used to limit attack traffic to a level that allows protected hosts to function and allows some legitimate
traffic to reach those hosts. Shaping is generally not appropriate as a first response, because it restricts legitimate
traffic and unwanted traffic equally. Shaping is appropriate when other countermeasures have failed, or when other
countermeasures have only partially succeeded and traffic levels remain high enough to be a continued threat.
Note: Shaping is enforced before traffic is sent to any TMS application decoders, so packets dropped by shaping
can impair the effectiveness of application-specific event-driven countermeasures. Enable shaping only after
deciding that event-driven countermeasures are not adequate mitigation for the attack.

Traffic Shaping
Configuration
Using the FCAP Filter, you can scope the shaping to specific traffic
• If Flow Capture Filter

Expression not specified,
scope is all traffic passed by
per-packet countermeasures
• All traffic above the

configured levels (bps/pps)
will be dropped/policed
Select to configure
additional Shaping
Queue
Shaping is a per-packet countermeasure that limits the forwarding rate for traffic matching a filter. It
inspects the packet to determine if the packet matches the PCRE-format filter, or it matches all packets if
no filter is defined. If the packet matches, the current packet forwarding rate data is compared to the
Maximum Levels bps/pps settings. If this packet would cause the forwarding rate to exceed either
maximum, the packet is dropped. Otherwise, the packet is forwarded, and the forwarding rate data is
updated to include the packet just forwarded.
Each of the TMS systems that are part of the mitigation group will rate limit at the same Maximum Levels
settings. For example, if the rate limit is 100 mbps and there are 3 TMS systems in the mitigation, each would rate
limit at 100 mbps so the victim may see as much as 300 mbps. This feature is a more useful when deployed in a
data center with a primary / redundant entry point because only one TMS is likely to see all the traffic for the
victim. It is less useful in a peering or scrubbing center deployment since you cannot predict how much traffic for
the victim will be going through each TMS.

Traffic Shaping
• Up to 10 queues can be
configured
• Each use a FCAP Filter
Expression and
maximum Traffic Levels
settings in bps and pps
Arbor TMS has the ability in the UI to create up to 10 separate Shaping queues each with unique FCAP
filter specification. This allows for shaping countermeasure that has multiple traffic shaping filters with different
purposes and maximum level settings

Traffic Shaping
Monitoring
Shaping status graphs of

dropped traffic are color-
coded by enabled shaping
queue
During mitigation, the Shaping status depicts color-coded (by shaping queue) graphs of dropped traffic.

Knowledge Check
Volumetric Attacks
Q1: Why is it recommended to use Filter Q3: Which IP protocols are often used for
Lists? volumetric attacks?
a) easy to configure a) GRE
b) very effective in the packet processing path of the b) UDP
TMS
c) TCP
c) Filter Lists are one of the first checks applied to
traffic passing the TMS d) ESP
d) all above Q4: Why is it not recommended to mitigate an

attack only by traffic policing/shaping?
Q2: What is the difference between
Deny/Allow and IP Based Filter Lists? a) It is hard to find the right values to configure
a) Deny/Allow Filters allow a multi-match statement b) The configuration is too complex to manage
b) IP Based Filters allow a multi-match statement c) It does not differentiate between valid and attack
traffic
Solution: Q1: d Q2: a Q3: a,b,c,d Q4: c




Step2
• Lab Objectives: Volumetric Attacks

• Mitigate a Volumetric Attack


• Identify volumetric Attacks
• Use and configure filters and filter lists
• Use Zombie Detection successfully
• Shape (police) traffic levels


State Exhaustion Attacks
Sightline/TMS
NETSCOUT University State Exhaustion

Unit Summary
• Identify Stack targeting attacks
• Use TCP SYN Authentication with its different modes
• Limit the amount of Connections
• Terminate TCP sessions that are IDLE or are invalid
• TLS Session Attacks

Stack Attacks
Unit 9: State-Exhaustion Attacks

Stack Flood Attack

Overview
Spoofed Usually Unable to

Allocating respond to
Description or non- flood of TCP legitimate
spoofed small Resources connections
Traffic packets
Sightline Detection
Host Detection
Capabilities
TMS Mitigation Deny/Allow Lists TCP SYN Authentication Zombie Detection

Countermeasures Per Connection Flood Connection Limiting
Attacks TCP SYN TCP FIN TCP RST TCP SYN/ACK Amplification
TCP Stack Flood Attacks are designed to overwhelm a particular part of a host’s TCP connection state machine to
interfere with normal legitimate TCP connections to that host. TCP Stack Floods may prevent new connections,
close or inhibit existing connections, or to crash operating systems that have flawed TCP implementations.
TCP Stack attacks are generally floods at large packet rates that attempt to overwhelm the host. Spoofed source
addresses and attacks from large groups of compromised hosts are common.
Arbor Sightline Detection

Host Detection: TCP SYN, TCP RST, TCP ACK, TCP
SYN/ACK Amplification, Total Traffic detection

Connection Attack
Overview
Allocating all
Keeping Keeping idle Resources to
Description ½ open TCP connections block legitimate
Connections open connections
Sightline Detection Limited by Sampled Flow Export

Capabilities
TMS Mitigation Deny/Allow Lists TCP SYN Authentication TCP Connection Reset
Countermeasures TCP Connection Limiting HTTP Authentication
Attacks TCP Idle Attacks
Connection attacks maintain a large number of half-open or fully open idle TCP connections. Resource exhaustion
in the TCP stack or application connection tables prevents the victim host from allowing new TCP connections to
be opened to the victim.

Connection Attack
Example: TCP Half-Open Connections
A
B
C
Y
A?
B?
C?
Y?
Since each TCP connection is distinct, data about each connection must be maintained separately. TCP uses a
special data structure called a transmission control block (TCB) for this purpose. The TCB contains all the
important information about the connection, such as the two socket numbers that identify it and pointers to buffers
where incoming and outgoing data are held. Each device maintains its own TCB for the connection.

TCP SYN Authentication


Overview
• Prevents SYN attacks from spoofed source IP addresses and packet-

generators
– Verifies the client before passing TCP connection requests
– Non-spoofed, stateful SYN ACK attacks are still possible
• TCP 3-way handshake is expensive to setup and maintain
• Number of TCP connections has a finite limit (server, firewall or load-
balancer)
• Once a connection is started, the corresponding device must maintain
its state
• Not adding host to Deny List
TCP SYN Authentication is a per-packet countermeasure that intercepts all TCP connections inbound to
the protected hosts. The TMS acts as a proxy for the protected hosts to verify that the source host is
behaving properly to maintain TCP connection state. If the source host is verified, then the source host is
approved and is allowed to connect to the protected hosts. If the source host does not behave as
expected, it is assumed to be malicious and is not allowed through.
A host that fails TCP SYN Authentication is not blocked: Any subsequent TCP connection attempt may be used to
authenticate.


Configuration
Ignore Source / Destination Ports

• Define source or destination ports to ignore for
TCP SYN Authentication, such as:
– Ignore port 25 for SMTP MTA
– Ignore port 443 for HTTPS
TCP SYN Authentication Idle Timeout

• Length of time for zero packets from the client Applies to HTTP
Services (TCP/80,
before client must re-authenticate TCP/8080)
Ignore Source/Destination Ports: Some applications do handle a connection reset in a transparent manner (e.g.,
HTTPS or mail servers). In this case, it may be preferred to bypass this countermeasure through the use of an
exclude port that exempts clients from being challenged when attempting to open TCP sessions on the excluded
destination port.
TCP SYN Authentication Idle Timeout: A host that is authenticated by TCP SYN Authentication remains
approved until it has not sent a TCP packet for a period longer than this value. The default is 60 seconds.


Connection Reset Validation
Client TMS Server

SYN Port 80 Port 80
Port n SYN/ACK
ACK Client Authenticated
Connection established
RST
Connection terminated
Port n+x SYN

SYN/ACK
If the first received packet of a TCP connection is not a SYN packet, then the TCP SYN Authentication module
assumes that it has intercepted a connection already in progress. It notes TCP sequence numbers and drops that
packet. Packets from the source host will continue to be dropped until the TMS detects a retransmission of the data
in the dropped packet. The retransmission packet is forwarded to the destination, and the source host is approved to
continue sending TCP packets directly to the protected destinations.
TCP SYN Authentication is intended to protect against TCP SYN flood attacks, but it is also expected to protect
against any TCP flag attack, such as ACK floods or illegal TCP flag combinations. TCP SYN Authentication
blocks traffic from any host that has not connected using a proper TCP stateful handshake, so it should block all
attacks that send stateless TCP packets. TCP SYN Authentication performs well for both flood attacks and trickle
attacks.


Default Behavior
In addition to TCP SYN packets, any other type of TCP packet is

automatically dropped
• Source host is authenticated if it resends the dropped packet (retransmit)

– Host added to authentication list (default 60 seconds)
– Host categorized with “retransmit-auth” marker
• Any TCP packet received from authenticated host (whether by the TCP SYN-ACK
challenge or the ‘retransmit-auth’ method) is passed


Caveats
Some services or TCP stacks may not

handle the TCP RST and restart well
• SSL/HTTPS: Browsers show Connection Reset
errors
• SSH: Exits session, requires manual re-run
• SSL/IMAPS/POP3S: Client get Connection
Reset errors, some may or may not re-try
• SMTP: If multiple MX records, MTAs will get reset and immediately try the next MX
record host
– Round-robin might ensure that the MTA will never get back to an authenticated MX
record


Out-of-Sequence Authentication
Intended to reset TCP connections via

a seamlessly transparent method
• Avoid Transaction errors and retries for SSL or
non-HTTP TCP protocols
1. TMS imitates a pre-existing half-open

connection
2. TCP client should perform a reset of the half-
open session and retry
• Recommended method for most cases
If Enable Out-of-sequence Authentication is selected, a completely different authenticating behavior is used. If

the received packet has the SYN flag, TMS intercepts the SYN and sends back an ACK packet with incorrect
sequence numbers, thereby imitating a half-open TCP connection at the destination host. If the source host responds
with RST packet to close the half-open connection and then resends the SYN packet using the same TCP sequence
number, then the source host is verified to be listening for proper connection state and can properly reset stale
connections. The new SYN packet is forwarded to the destination to complete the intended connection, and the
source host is marked as approved to set up TCP connections directly with the protected servers. Subsequent TCP
packets are forwarded directly to the destination hosts.
The advantage of Out-of-sequence Authentication over the original TCP SYN connection reset method is that Out-
of-sequence Authentication does not abnormally reset the attempted client connection. The imaginary half-
connection that is reset is not the connection attempted by the client. Most client stacks regard the connection
completion as normal and do not inform the application of any error, so the user is unaware of any impact from the
authentication.


Out-of-Sequence Validation
Client TMS Server

SYN Port 80
Port 80
Test 1
Port n
ACK Incorrect Sequence
RST Client Authenticated
RFC 793 ELSE*
SYN
Test 2
Port n Port 80
SYN/ACK Incorrect Acknowledge number
RST Client Authenticated
ELSE*
SYN Port 80
Port n
SYN/ACK
Test 3
ACK Client Authenticated

RST
*Only if the previous test didn‘t authenticate the client
Packet Exchange:
1. 11:40:15.984405 IP 192.168.4.1.35792 > 192.168.4.225.https: Flags [S], seq 4205432417, ... Client sends first
SYN to establish connection with server.
2. 11:40:15.984695 IP 144.0.4.225.https > 192.168.4.1.35792: Flags [.], ACK 253118415, ... TMS replies back to
the client with an ACK with the out-of-sequence ACK#. The ACK# number is artificially generated and
according to the RFC invalid and worthy of a Reset.
3. 11:40:15.984717 IP 192.168.4.1.35792 > 192.168.4.225.https: Flags [R], seq 253118415, ... Client sends a RST
packet back to that invalid ACK above.
4. 11:40:18.983908 IP 192.168.4.1.35792 > 192.168.4.225.https: Flags [S], seq 4205432417, ... Client then sends a
second SYN packet to the server. Note that the SEQ# here matches the first packet sent by the client. This is an
identical SYN packet to the first packet sent.
5-6. When the TMS sees this second identical SYN packet, the client is added to the allow list and this packet is
forwarded to the server.
7. 11:40:18.984189 IP 192.168.4.225.https > 192.168.4.1.35792: Flags [S.], seq 4261116235, ACK 4205432418, ...
The server, now finally having seen a SYN packet responds with a valid SYN-ACK packet and the hand shake
completes.


Options
Enable Outbound Out-of-sequence Authentication

• Prevents connections come from the protected
host(s) being dropped.
• Has to be enabled with Spoofed Flood Protection
Enable Spoofed Flood Protection

• Mitigation of inbound spoofed ACK and SYN/ACK
floods
• When enabled, existing “retransmit” authenticated
connections are revoked and will need to re-
authenticate


Spoofed Flood Protection
Blocks SYN-ACK response in outbound TCP connections unless Outgoing Out-Of-

Sequence option is enabled
• Spoofed Flood Protection prevents retransmit-auth
• Drops all existing TCP connections
• All source hosts must authenticate via SYN or Out-of-Sequence method
• Idle TCP connections are dropped after authentication idle timeout
– Suitable for most content services (webservers, email servers, ...)
– Not compatible with interactive protocols (SSH, FTP, …)
– Not suitable for websites maintaining login sessions (idle TCP connections)


Spoofed Flood Protection Validation
Challenge:
1. Intercepts initial SYN-ACK packet from source host
2. Responds with ACK packet that has invalid sequence number
3. Proper host behavior is to send RST
4. TMS notes RST and authenticates source host
5. Client should resend initial SYN to restart TCP handshake


Automation
Automate TCP SYN Authentication based on Host

Detection
• Enables TCP SYN Authentication when DOS
Host alert has TCP SYN misuse type detected
Automate Spoofed Flood Protection based on

Host Detection
• Enables Spoofed Flood Protection and
Outbound OoS Authentication when DOS
Host alert has TCP SYN/ACK Amplification or
TCP ACK misuse misuse type detected



Configuration
Limit the number of simultaneous open TCP connections from a single

source host
…
…
The TCP Connection Limiting countermeasure limits the number of concurrent TCP connections that can
originate from a single host. This countermeasure prevents attacks that overwhelm the victim's
connection resources with an excessive number of TCP connections. The TCP Connection Limiting
countermeasure mitigates IPv4 attack traffic.
For example, some botnets open hundreds of active or inactive TCP connections. A sufficiently large
number of connections can consume all of the resources of a server and prevent the server from
accepting legitimate traffic.
You can configure the TCP Connection Limiting countermeasure when you create or edit a mitigation or
mitigation template and when you edit a mitigation on the TMS Mitigation Status page.


Advanced Settings
Choose whether to ignore connections that are idle longer than a

setting
• Default is to ignore any idle longer than 60 seconds
• Eliminates false blocking due to broken implementations or bad connectivity
• Some secure banking uses idle connections
The TCP Connection Limiting countermeasure monitors the TCP requests from a source host and checks for a SYN
followed by an ACK for the same 4-tuple (src/dst IP and src/dst port combination). This countermeasure does not
require replies from the server to function because it is designed to work in an asymmetric environment.
When the number of concurrent connections from a single host exceeds the connection limit configured in this
countermeasure, then one of the following happens depending on how this countermeasure is configured:
• The host is added to the Deny List.
• The host's connections that exceed the connection limit are dropped and the connections are reset.
• The host's idle connections are ignored and not counted to keep the host within the connection limit.

TCP Connection Reset


Overview
• Handles TCP connections after SYN Authentication

• Keeps hosts from eating up server connection table
– Setup a connection and leave it up with no valid data – low packet rates with
many connections
– Setup the connection, send some data and then abandon the connection
without sending an RST


Overview (Cont.)
• Modes
a) Monitor new TCP connections and ensure source host sends at least required
payload data within initial timeout
b) Ensure source host sends a TCP packet more frequently than the idle timeout
• Connection found idle > timeout is closed by sending TCP reset to the protected
host and not to the attacker
• Ports
➢ 80 (HTTP)
➢ 443 (HTTPS)
➢ 25 (SMTP)
TCP Connection Reset has two different enforcement criteria.

• When a TCP connection is first detected, the source host must send at least as much payload data as specified by
Initial Connection Required Data in a time period shorter than the Initial Timeout.
• The source host must merely send a TCP packet more frequently than the standard Idle Timeout.
Any TCP connection found to have been idle for a period longer than the appropriate timeout is closed by sending a
TCP Reset to the destination host. TCP Resets are not sent to the source host, so that attackers have no feedback
that their connections have been blocked.
Arbor Sightline applies the TCP Connection Reset countermeasure to the following ports:
• 80—HTTP traffic (Web traffic)
• 443—HTTPS traffic (Web traffic)
• 25—SMTP traffic (mail)
You cannot manually configure ports for this countermeasure.


Configuration – Initial Timeout
Initial Timeout Required Data

• Drop new TCP connection if the Initial
Required Data is not received in the
specified period
Consecutive Idles Before Adding Host to

Deny List
• Allows client to fail multiple
connections before getting added to
the Deny List
The TCP Connection Initial Timeout and Initial Timeout Required Data, which allow a shorter timeout
period and minimum payload data required for an initial connection, are designed to cause faster
connection resets when malicious software opens TCP connections but does not send any additional
packets. It is also useful for more sophisticated attack software that sends empty TCP packets for the
sake of avoiding idle timeouts.
The number of Consecutive Idles Before Adding Host to Deny List should never be set to one,
because that would block legitimate users who allow a connection to expire while distracted with other
tasks. The setting may need to be adjusted higher for applications that have multiple TCP control
connections that might be idle simultaneously due to a single lack of user action.
Source hosts are added to the deny Listing for 5 minutes if the number of consecutive resets for TCP
connections that they originate reaches the Consecutive Idles setting. TMS restarts the consecutive
resets counter for a host at zero anytime it receives a packet on any existing TCP connection from that
host.


Configuration – Connection Timeout
TCP Connection Idle Timeout

• Drop TCP connections from hosts that
have not sent packets for specified
period (IDLE)
Track Connection After Initial State

• If you want the ‘Idle’ timeout to apply
after the host passes the initial required
data check


Slow Attack
Countermeasures for
more Sophisticated
HTTP
HTTP Attacks
Services
Arbor TRA Arbor TMS
• Problem: Attacks on HTTP more prevalent, more

sophisticated
• Solution: Countermeasure for Slowloris and other slow
request attacks. Stricter malformed header checks defeat
HTTP
LOIC and similar attacks
• Value: Service Availability


Slow Attack (Cont.) HTTP REQUEST
GET /default.html HTTP/1.1
Application Slow Request Attack Host: www.peace.com
Prevention User-Agent: Mozilla/5.0
• Configured under TCP Connection Connection: keep-alive
Reset X-a: b
X-a: b
• Detects and resets connections with X-a: b
low sustained bandwidth X-a: b
– Idle connection no longer required X-a: b
for reset …
• Intended to prevent attacks such as
HTTP Slowloris / PyLoris


Configuration – Slow Attacks
The following configuration options

are available:
200*
60*
60*
*default values



Overview
Compare packet headers (L3/L4) with a manually defined filter expression

• Applied on a per packet basis (payload that spans multiple segments will not match)
• Matching packet is dropped
• Supports IP, TCP, UDP and ICMP filter keywords
• Supported operators:


IP Filter Keywords ip.dsfield.ecn
ip.dsfield.dscp Explicit Congestion
Notification
ip.flags.rb
ip.dsfield Flag: Reserved Bit
Differentiated
Services Field ip.flags ip.flags.df
Flag: Don’t’ Fragment
ip.version* ip.hdr_len* ip.len*
ip.ttl ip.proto
ip.src
ip.addr
ip.dst
IPv4
*Sightline ≥9.5.0.0
The syntax in the Packet Header Filtering countermeasure for the ip.flags field has changed with Sigthline
9.5.0.0 and onwards. The new syntax matches the syntax that Wireshark uses. Although the ip.flags field
is a 3-bit field, Wireshark treats it as a full byte. The Packet Header Filtering countermeasure previously
treated ip.flags as a 3-bit field, but now also treats it as a full byte.
Any mitigations or mitigation templates using the ip.flags filter should be changed to use the new syntax.
The following table shows the change in syntax for the Bit to match action:
Don't Fragment (DF)

• Previous syntax
• Ip.flags & 2
• ip.flags == 2
• New syntax
• ip.flags & 0x40
• ip.flags == 0x40
Reserved (RB)
• Previous syntax
• ip.flags & 4
• ip.flags == 4
• New syntax
• ip.flags & 0x80
• ip.flags == 0x80


Layer-4 Filters Keywords
tcp.srcport tcp.port tcp.dstport
TCP
tcp.flags.ack|push|syn|
tcp.window_size_value
reset|fin|cwr|ecn|ns|urg
tcp.checksum
tcp.options.sack_perm tcp.options.mss_val tcp.option_kind*
UDP
udp.srcport udp.port udp.dstport
udp.length udp.checksum
ICMP icmp.type icmp.code icmp.checksum

*Sightline ≥9.5.0.0

Packet Header Filtering Expression

Selectively Filter Malicious Traffic tcp.window_size_value > 10000
and tcp.options.sack_perm &&
tcp.options.mss_val ge 1450 and
not tcp.dstport & 1
Specification
Filter packets if the TCP window size
value is greater than 10.000 and TCP
selective acknowledgement is enabled,
and TCP MSS value is greater than or
equal to 1450 bytes and the TCP
destination port number is not uneven.

TLS Attack Prevention


Overview
SSL-
Based
Services
SP TRA SP TMS
HTTP
• Problem: Attacks on TLS based services are growing
• Solution: Suite of detection and countermeasures to stop attacks specifically
targeting HTTPS, POP3S, SMTPS servers
• Value: Service availability → prevents malformed or malicious TLS signaling and
negotiation from reaching the server


Attack Operation
Scope of Mitigation
TLS 1.2


Threads
Mitigates attacks that target TLS negotiation

• Malformed TLS Attacks
– Garbage packets send that force crypto-work on the server
– Invalid SSL Handshake send or improper use of protocol options
• SSL Resource Exhaustion Attacks
– Large number of cipher options or TLS extensions
– Slow negotiation – slowloris-style lack of progress
– Renegotiations – immediate or repeated
• TCP connection exhaustion on TLS ports
– Often coupled with above attacks (TLS Renegotiation, etc.)
– Examples: THC DDoS (https://github.com/vanhauser-thc)


Configuration
Protects secured application

services from attacks that
target TLS signaling protocols
• Not recommended to change
Advanced Settings
• Any host that exceeds the
thresholds is added to the Deny
List
– Interval is always 5 minutes (not
configurable)
The SSL Negotiation countermeasure is designed to protect secured services from attacks that target the
SSL and TLS signaling protocols. Advanced Settings default values are reasonable for most situations
and rarely need adjustment:
Maximum cipher suites – The maximum number of cipher suites for which a client is allowed to indicate
support. While the default value of 100 significantly exceeds the norm, it is small enough to reduce the
amount of time a server spends searching the list of ciphers to look for a common supported option.
Maximum client extensions – the maximum number of extensions that a client is allowed to include.
The default value is 10 to reduce the impact of malicious clients on the server.
Maximum open uncompleted connections – The maximum number of times that a client can open a
connection and close it without completing the SSL handshake and sending encrypted data. The default
value of 25 allows valid clients to open multiple parallel connections and only use a few of them, while still
blocking attacks.
Maximum seconds before application data – The maximum number of seconds that a client is allowed
between opening a connection, completing the SSL handshake, and sending the first bytes of encrypted
application data. The default value is 30 seconds.


TLS Support
TLS (Version 1.0, 1.1,1.2 and 1.3)
Protected ports
• 443 HTTP over TLS (HTTPS)
• 465 SMTP over TLS (legacy SMTPS reassigned by IANA as URL Rendezvous Directory for SSM)
• 563 NNTP over TLS (NNTPS)
• 587 SMTP mail submission (may be TLS)
• 636 LDAP over TLS (LDAPS)
• 989 FTP over TLS (FTPS)
• 992 TELNET over TLS
• 993 IMAP4 over TLS (IMAP4S)
• 994 IRC over TLS
• 995 POP3 over TLS (POP3S)
• 5061 SIP over TLS
SSLv3 Official Support was removed in Sightline 9.2

TLS 1.3 Support was added in Sightline 9.2


Mitigation Status
Usual TMS statistics

• Traffic dropped by bps/pps
• Hosts blocked
– Rate per second
– Average at once
• Download blocked hosts List
– Current
– Top

Knowledge Check
State Attacks
Q1: What is the most common reason for half Q3: Why is there a risk when allowing too
open TCP connections? many idle connections towards a server?
a) TCP protocol errors a) There will be too much traffic to the server
b) Unsupported encryption b) An intermediate firewall could suffer from problems
with its state-table size.
c) Spoofed traffic
c) All server resources could be used, and new
d) Temporary routing issues connections could no longer be accepted
Q2: Using TCP SYN Authentication, who d) Troubleshooting the server will be too complicated
sends the challenging packets to the host?
a) TMS
b) Server
c) Router
Solution: Q1: c Q2: a Q3: b,c




Step2
• Lab Objectives: State Exhaustion Attacks

• Mitigating State and Stack Attacks


• Identify Stack targeting attacks
• Use TCP SYN Authentication with its different modes
• Limit the amount of Connections
• Terminate TCP sessions that are IDLE or are invalid
• TLS Session Attacks



Application Layer Attacks
Sightline/TMS
NETSCOUT University Application Layer

Unit Summary
• Block generic Application Layer attacks
• Perform more specific blocking on HTTP attacks
• Perform more specific blocking on DNS attacks
• Blocking of SIP based attacks

Application Attacks
Unit 10: Application Layer Attacks

Application Attacks
Overview
Internet Resource Stealthy on

Description facing intensive low traffic
services operations rates
Sightline Detection
Not possible via Flow Export
Capabilities
HTTP Malformed HTTP Rate Limiting HTTP/URL RegEx
TMS Mitigation SIP Malformed SIP Request Limiting DNS Malformed DNS RegEx
Countermeasures
Payload RegEx DNS Authentication DNS Rate Limiting
Attacks HTTP GET floods SIP Invite floods DNS Pseudo-random Label
Application attacks are designed to overwhelm components of specific applications. They are conceptually similar
to generic flood attacks except that they are targeted at a particular software component rather than entire hosts.
Application attacks are usually seen against common server applications such as HTTP servers, DNS resolvers, and
SIP gateways.
Depending on the actual application weakness being attacked, the rate of attack packets needed for a successful
attack may be very low. Because of this, application attacks can be very stealthy and attackers frequently obscure
them by mixing attack traffic with a much larger amount of other traffic using the same protocol, port, and server
host.

Application Attacks
Overview (Cont.)
Application attacks attempt to cause disruption to the service with

expensive or well-crafted requests
• DNS
– Dictionary attack → query a NXDOMAIN causing high back-end operations
• Web
– Expensive setup → TLS encryption
– Database query → get long listing instead of just a few at a time
– Large download → flood the interface return path
– Flash traffic → Coupons posted to Twitter!
Harder to defend as you must know what is malicious

Payload Regular Expression


Overview
Regular Expression (RegEx) countermeasures look for expression match

against packet data
• Block content-identifiable attack vectors → drop packets where a string in the data
matches or not-matches the pattern
• Actions can be drop or add to Deny List
Payload RegEx HTTP RegEx DNS RegEx

Filter within the payload Filter within HTTP Header Filter within DNS Header
and optionally within the
Layer 4 header Import URL Filter Lists to Import DNS Filter Lists to
scale scale
Payload Regular Expression (Regex) filtering is a per-packet countermeasure that compares a regular expression
filter to TCP or UDP packet payloads. It is designed for attacks that contain a unique data pattern. Many application
layer DDoS attacks can be identified by their payloads, as can many packet repetition attacks in conjunction with
matching packet headers.
When a packet containing TCP or UDP is received, it is first compared to specified TCP/UDP port lists. If the port
matches, the packet payload is compared to the PCRE-format regular expression. Packets that don’t match the port
lists or that are protocols other than TCP or UDP will be passed to the next enabled countermeasure. Filtering may
be set to drop packets/Deny List sources that match and pass packets that do not match, or pass packets that match
and drop packets/Deny List sources that do not match.
Since this countermeasure is implemented per-packet, a regular expression cannot match payload data that is split
into multiple IP packets, even though the payload of those packets might form a single application datagram. Also,
if an IP packet is received as multiple fragments, only the first fragment will have a TCP or UDP header that can
match the port list, so only the first fragment will be compared to the regular expression.


Use sample traffic to generate
Configuration Specify TCP or UDP port(s)
RegEX ≥9.3
Choose source or destination
Enter a regular expression in a Displays Sample

PCRE format to search Packets using
regex filter
(not supported
when ‘Apply
When checked, RegEx is applied to
Regular Expression
start of packet header to Packet Header’ is
selected)
Select behavior and were to apply

RegEx
The Payload Regular Expression (in PCRE format and single-line mode) match is only applied to packets from
the specified ports. Note that payload regular expressions are case-sensitive by default. To perform case-insensitive
matching, preface the expression with “(?i)
When the Apply Regular Expression to Payload Header box is selected, the regular expression is
applied to the layer 3/4 packet header in addition to the packet payload. This allows operators to block
attacks based on specific patterns in the packet header.
If the Action to Apply to Offending Hosts is set to Deny List (default), then offending source hosts are
dynamically blocked and all traffic from them is dropped. If set to Drop Traffic, then only the offending
traffic from these hosts is dropped.
If Apply Action to is set to Matched Traffic, then the traffic that matches the payload regular expression is either
dropped or the host is blocked. If set to Unmatched traffic, then the traffic that does not match the payload regular
expression is either dropped or blocked.


Use Cases
• Drop packets from attacker that utilize a common payload

– Payload includes DE AD BE EF
• Drop packets for a traffic based on data inside the payload
– DNS TXT queries: \x00\x10\x00\x01$
– DNS MX queries: \x00\x0f\x00\x01$
• Drop packets poorly crafted and always include the same Timestamp
– Timestamp Unix Epoch (Jan 1, 1970)
\x16\x03\x00\x00\x37\x01\x00\x00\x33\x03\x00\x01\x01\x01\x01


Workflow – Identify possible match
Obtain the payload data

from Sample Packets
Window
Type: TXT
Class: IN
00 10 00 01


Workflow – Test possible match
Regular Expression filters can use hex format for matching, enter \x
between every byte
Example 72 73 65 74 → \x72\x73\x65\x74
➢ Use anchors for start ^ and end $

➢ Use offset ^.{n} to start n bytes
into the payload (following TCP or UDP
header)


Workflow – Configure Filter
Input the hex formatted string with

\x operator in front of every byte
(no spaces)
Type: TXT
+
Class: IN
→
\x00\x10\x00\x01


Workflow – Filter Validation
View dropped traffic with Sample Packets and verify that no good traffic
is dropped.


UI RegEx Generation ≥9.3
• Sightline generates a table of traffic pattern from the traffic seen by

the selected TMS for this mitigation
• Select traffic pattern you want the countermeasure to mitigate
• Configuration values are automatically generated from the selection
Select a single TMS



UI RegEx Generation ≥9.3 (Cont.)
Overview of Detected Pattern
Number of Fields matching % of traffic matching Blank fields mean ANY = * value
Replace selected
with existing RegEx
Copy RegEx to clipboard

Add selected to
15
existing RegEx


UI RegEx Generation ≥9.3 (Cont.)
Configuration auto generated

from selection
• TCP, UDP Ports or IP Protocol

• Port Direction
• Regular Expression
• Apply to Packet Header (if needed)
You need to click Save to activate

the new RegEx configuration
Multiple selections are
OR’d together by ‘|‘

≥9.3
UDP Session Authentication

UDP Session Authentication ≥9.3

Overview
Drops traffic for UDP sessions that do not complete a

retransmission check
• Mainly intended for Gaming environments
• Application must use initialization packet for each new session that is reliable
identifiable by a RegEx
• Valid Client retransmit lost initialization packet
• In-Progress Session Acceptance Period learns existing session and are
considered authenticated
▪ Period starts on enabling countermeasure
▪ Period starts on change of Destination Port
▪ Period starts on change of In-Progress Session Acceptance Period value setting

UDP Session Authentication ≥9.3

Configuration
List of ports matched
RegEx identification of client

session initialization packet
Inflight start-up period to

avoid disrupting sessions on Apply RegEx from
countermeasure start Packet Header
Retransmit window for
dropped initialization packet to
successfully authenticate
Session Idle Timer for

triggering re-authentication

UDP Session Authentication ≥9.3 Data

Packet
Initialization
Examples Packet
Idle Session Timer
Authenticating Existing Sessions (during Inflight startup period) Initial Packet
Retransmission Timer
✓ !
Idle Timer is ignored during Inflight
startup period
✓
✓ ! Idle Timer requires Session
re-authentication
✓
✘
In-Progress Session Acceptance Period
t
Authenticating new Sessions (at any time)
Retransmit expected
✘
Session
Authenticated ✘ Retransmit Window closed
✓ ✘
un-authenticated Session
✓ ✘
t t
successful failed

HTTP Malformed

HTTP Malformed
Overview
Block attacks that send invalid or blank HTTP request to a server to

exhaust resources or to exploit vulnerabilities
• HTTP headers checked for compliance to RFC 2616 Section 2.2 “Basic Rules”
• Protection levels medium/high add progressively stricter checks
• Violating messages are dropped and source host is added to the Deny List
Malformed HTTP filtering is intended to block attacks that send invalid or blank HTTP requests to a server to
exhaust resources or to exploit vulnerabilities by validating that HTTP messages are in a proper format.
The countermeasure inspects the HTTP headers and verifies that they conform to RFC2616 Section 2.2 "Basic
Rules", with the exception that the countermeasure allows exceptions to constraints on the space (" ") character. It
also looks for any parsing error in the entire stream. If either of these tests fails, message is dropped and the source
host is blocked.
Arbor 5.7 allows stricter HTTP Malformed checks; these block certain attacks such as LOIC which are
valid HTTP but using non-standard syntax or header values. These checks can be enabled by using the
level setting for HTTP Malformed Filtering. Raising the level to Medium or High adds progressively stricter
checks that block additional attacks.

HTTP Malformed
Protection Levels
HTTP header field rules by level

Low • HTTP 1.1 requests must have Host:
• HTTP 1.1 requests must have Host:

Medium • All requests must have User-Agent:
• All HTTP 1.1 requests must have Host:

High • All requests must have User-Agent:
• All requests must have Connection:
When Low setting is selected, the countermeasure filters traffic that does not conform to RFC 2616
standards. A higher setting blocks traffic that conforms to RFC standards for valid request headers but
has other abnormal HTTP behavior. As you increase the enforcement level, more malicious HTTP traffic
is dropped, but the likelihood of dropping legitimate traffic also increases. For more information also see
knowledge base article number 1275.

HTTP Authentication

HTTP Authentication
Overview
Extension of TCP SYN Authentication where a new HTTP connection of

a source host undergoes additional checks for proper HTTP behavior
TCP SYN Authentication countermeasure supports three optional extensions:

1) Enable Application Reset
2) HTTP Authentication
3) Require JavaScript for HTTP Authentication
The HTTP extensions are mutually exclusive

• HTTP Authentication takes priority over Application Reset (if both selected)
• JavaScript for HTTP Authentication takes priority (if other two selected)
The HTTP authentication options are application countermeasures that are configured as extensions to TCP SYN
Authentication. Packets are passed directly from TCP SYN Authentication to the HTTP application decoder for
TCP connections that are to be HTTP authenticated. HTTP authentication options should thus be treated as a per-
packet countermeasure when considering countermeasure processing order, even though they are technically event-
driven.
When any of the HTTP authentication methods are selected, a new TCP connection to the TCP ports specified for
HTTP is established with the TMS, but the the connection is not reset as in normal TCP SYN Authentication.
Rather, the source host then undergoes additional checks for proper HTTP stateful behavior. These HTTP
authentication options also avoid a browser error that would otherwise appear because of TCP SYN Authentication,
removing a possible source of user complaint.

HTTP Authentication
Configuration
Modes
➢ Application Reset
➢ HTTP Authentication
➢ HTTP Authentication with
JavaScript
HTTP Ports
• Used by all HTTP authentication
options
• Defines TCP ports being used
by HTTP (default 80, 8080)
The HTTP Authentication Ports box is shared between all HTTP authentication methods even though they
can't be used at the same time. HTTP authentication methods only see TCP traffic sent to these ports.

HTTP Authentication
Client TMS Server
Application Reset SYN Port 80
Port n Port 80
SYN/ACK
ACK
• Avoid sending a TCP Connection established
GET / HTTP/1.1 302 „Moved

RST from the TMS, Temporarily“
HTTP/1.1 302 Location: /
get the client to tear FIN/ACK
Client Authenticated
down the TCP ACK

connection instead…
Port n+x SYN
SYN/ACK
ACK
GET / HTTP/1.1
If Enable Application Reset is selected, HTTP Authentication is not enabled, and the TCP connection is to an
HTTP TCP port, the TMS SYN Authentication module does not cause the connection to be reset. It instead waits
for an HTTP request to a URI and responds to that request with a HTTP temporary redirect to the same URI
location. This causes any popular web browser to close the intercepted TCP connection normally and retry the
request on a new TCP connection, doing so seamlessly without the disruption of an unexpected connection reset.
Since the source hosts is now authenticated, the new TCP connection is forwarded to its intended destination.

HTTP Authentication
Client TMS Server
HTTP Authentication Port n
SYN Port 80 Port 80
SYN/ACK
ACK
• Add additional security by GET / HTTP/1.1 302 „Moved

Temporarily“
using the HTTP protocol to HTTP/1.1 302 Location: /KmfPM/
validate the client and test FIN/ACK
ACK
its protocol awareness… Connection terminated
SYN
Port n+x
SYN/ACK
ACK
GET /KmfPM/ HTTP/1.1

302 „Moved
Temporarily“
FIN/ACK
Client Authenticated
ACK
Port n+y SYN

SYN/ACK
ACK
GET / HTTP/1.1
If Enable HTTP Authentication is selected and the TCP connection is to an HTTP TCP port, the TMS SYN
Authentication module does not does not cause the connection to be reset. Instead, it waits for the source host to
send an HTTP GET or HEAD request. The TMS responds with an HTTP Redirect to a modified URI. If the source
host is a real HTTP client, it should open a new connection to the new URI. The TMS also intercepts this
connection but recognizes that the source host properly followed the redirect. The TMS responds with another
HTTP Redirect to the original URI and approves the host to open future HTTP connections directly with the
destination servers.
A host that passes TCP SYN Authentication but fails HTTP Authentication is still approved to open TCP
connections to TCP ports not listed for HTTP. Hosts that fail HTTP Authentication are not blocked.
HTTP Authentication is useful protection against attacks that try to open a correct stateful TCP connection but then
blindly request only a single web page URL, and also for attacks that open a stateful connection but then leave the
connection idle. HTTP Authentication is often preferable to TCP Connection Reset because the malicious TCP
connections never reach the server hosts.

HTTP Authentication
TMS
HTTP Authentication + JavaScript Client SYN
Port 80
Server
Port 80
SYN/ACK
Port n ACK
• Add additional security GET / HTTP/1.1
by using the HTTP Constructing:

/MlWVR HTTP/1.1 200 OK (text/html)
protocol to validate the FIN/ACK
ACK
client and test its Connection terminated
protocol awareness and SYN

Port n+x SYN/ACK
JavaScript support… ACK
GET /MlWVR/ HTTP/1.1

302 „Moved
Temporarily“
FIN/ACK Client Authenticated
ACK
Port n+y SYN

SYN/ACK
ACK
GET / HTTP/1.1
Selecting Require JavaScript for HTTP Authentication uses a JavaScript-based authentication challenge which
is designed to add a layer of complexity for the client being authenticated by employing mechanisms that:
- Stop curl and similar tools that can respond to 302 redirect status codes.
- Slight obfuscation that prevents the redirection URI from being parsed trivially out of the response HTTP packet.
- Dynamic JavaScript challenge to make guessing and probing by botnet components more difficult.
- Use elements not normally found in JavaScript tools, e.g., Browser object model components such as window.
With the JavaScript authentication challenge enabled, HTTP authentication is performed by returning an HTTP
response with a 200 status code and HTTP payload containing an HTML document with multiple JavaScript
sections. When executed, the JavaScript sets the client browser's location to the redirection URL obtained by
executing the JavaScript.

HTTP Authentication
Caveats
• Only works with HTTP traffic (not HTTPS)

• Default ports (80 and 8080) can be changed per mitigation or global
/ service tms registry main set mitigation tcp_syn default_http_ports = 80,8080
• All sessions must be persistent to a single TMS

– TMS group → no per-packet load-balancing
– 302 redirect can not come from one TMS with the response handled by another
TMS
There is a registry setting to make TMS send redirect messages (http://<TMSofframpIP>/cookie). That will make
sure that the sessions are persistent on a single TMS.

HTTP Limiting

HTTP Limiting
Overview Request Limiting
HTTP Request Limiting adds clients to Deny List that exceed a given
rate of HTTP requests
• Rate tracked based on source IP address
• This includes all objects they are requesting
• The value of 120 allows each client to
place up to 120 requests per second, else
the sender is blocked
Example
/user/login?type=mobile
/index.html SUM ≤
120/sec.
/images/front.jpg
HTTP Request Limiting restricts the rate of HTTP requests that any client host is allowed to send. The
countermeasure is intended to prevent a host from overwhelming the resources of a web server either by
sending HTTP requests at too high a rate.
Since web servers can send a large amount of data due to a single request, a web server can be heavily
loaded by a relatively small number of HTTP requests. Thus rate limits should not be raised by large
amounts without careful consideration of the reasons and consequences. The default limits are usually
acceptable for typical users. Exceptions may need to be made for content mirror servers by adding those
servers to a “pass” rule in the Deny / Allow List filter.

HTTP Limiting
Overview Object Limiting
HTTP Object Limiting add clients to the Deny List that exceed a given
rate of HTTP requests for a single object
• Rate tracked based on source IP address
• The value of 15 allows each client to

request the same object (URI) no more
than 15 times per second, else the sender
is blocked
Example /user/login?type=api SUM ≤ 15/sec.
/index.html SUM ≤ 15/sec.
/images/front.jpg SUM ≤ 15/sec.
HTTP Object Limiting restricts the rate of HTTP requests for a specific object that any client host is
allowed to send. The countermeasure is intended to prevent a host from overwhelming the resources of a
web server either by requesting the same object at too high a rate.

HTTP Regular Expression


Overview
AIF and HTTP Regular Expressions

provide a mechanism to block specific
HTTP requests that impact a server or
service
Common HTTP Header fields

o User-Agent: (usually typos here)
o Referer: (find out original site that sent clients here)
o Host: (domain name of the site for virtual sites)
o Request Method:
o Request URI: (full URI path)
o Request Version:
Match throughout the HTTP Header:

http://en.wikipedia.org/wiki/List_of_HTTP_header_fields
The AIF and HTTP/URL Regular Expression countermeasure

allows you to configure a mitigation to use the regular
expressions downloaded by the AIF feed to drop traffic
associated with malware families. It also allows you to use HTTP
header regular expressions and/or URL filter lists to match traffic
in a mitigation.


Configuration
Without using AIF –

ATLAS Intelligence
Feed
If the HTTP Regular Expressions and/or URL Filter Lists are used without the AIF feed regular
expressions, these regular expression and/or filter lists block HTTP requests that match or do not match
these regular expressions and/or filter lists.


Configuration
If AIF Malware Family

Blocking is enabled,
then Header Regular
Expressions and URL
Filter Lists can only
block matching traffic.
If the AIF Malware Family Blocking is enabled with the HTTP Regular Expressions or URL Filter
Lists, then the regular expressions and filter lists can only block matching traffic and not block unmatched
traffic since AIF regex matches attack traffic.


Configuration
The Enable AIF Malware Family Blocking setting includes an information icon. When you click this icon,
a window displays the malware families for which the AIF feed has downloaded regular expressions. For
each malware family, the AIF feed downloads one or more regular expressions. The regular expressions
for malware families in the Low list are conservative. The regular expressions for malware families in the
Medium list are “moderate” unless the malware family inherits the regular expression used in the Low list.
The regular expressions used in the High list are “aggressive” unless the malware family inherits the
regular expression from the Low or Medium list.
In the Malware families window, you can view a list of all of the malware families or a list of malware
families for each AIF enforcement level. You can also search for specific malware families.


Use Cases
• Drop traffic to a particular site hosted on a server

Host: www.attacked.com
• Drop traffic to the attacked URI and move the service:
/scripts/database/attacked.asp moved to /scripts/database/attacked-1.asp
• Drop traffic from external sites that moved their DNS to your site!
http://en.wikipedia.org/wiki/Blue_Frog
• Drop traffic from Referred sites:
Referer: twitter.com
• Drop invalid HTTP headers:
Cache Control: No-Restore


Mitigation Status
Graph can be total or subset

for each enforcement AIF level
Each AIF signature is vetted against terabytes worth of traffic by ASERT. A signature that falls into the
Low category has a neglible chance of matching valid traffic. Medium signatures have at most a 0.01%
chance, while High signatures have at most a 0.1% chance of matching valid traffic.


Sample Packets

filter type also available in
Sample Packets to filter
your view
• Matching throughout
the HTTP Header
• Great way to look at
GET or POST, User-
Agent, Referer or URI
HTTP Regular Expression matching will only work if the mitigation has one of the HTTP countermeasures is
enabled or if the TMS patch panel has the HTTP option checked.


Sample Packets (Cont.) Match: Mozilla


PCRE Anchors
^ match start of line
$ match end of line
HTTP\/1\.1 = match anywhere on a line

HTTP\/1\.1$ = match only when at the end of a line


Workflow
1. Examine
Sample
Attack
Packets
GET /database/attacked\.asp
2. Create
Regex
Filter
3. Monitor
Result

DNS Malformed

DNS Malformed
Overview
Block attacks that send invalid or blank DNS messages to a server to

• Validates DNS Messages
1) Packets sent to port 53 are checked to make sure there is a payload
2) DNS decoder verifies a DNS message has been received
− The message is checked for compliance to pertinent RFCs
− If the validation fails, the message is dropped
• Source hosts are not blocked, the packet is only dropped
• DNS Z Flag is no longer validated with Release ≥9.3
Malformed DNS Filtering validates that DNS messages are in a proper format and is intended to block attacks that
send invalid or blank DNS messages to a server to exhaust resources or to exploit vulnerabilities.
Malformed DNS Filtering is implemented as two modules. A per-packet pre-filtering module inspects every packet
received. If the packet was sent to destination port 53, the packet is checked to make sure a payload exists that
could be part of a valid DNS message. If the payload is missing, the packet is dropped. The source host is not
blocked.
The Malformed DNS message validation module is event-driven and is signaled to run whenever the TMS DNS
decoder verifies that a valid DNS message has been received. The module inspects the DNS message and verifies
that the message conforms to a large number of format rules as defined in RFCs 1035, 1996, 2136, 2929 and others,
and that only appropriate IANA-assigned numeric field values are present. If message validation fails, the message
is dropped. The source host is not blocked.
Sightline Release 9.3 no longer validated the DNS Z Flag, its meaning and usage was changed a few times and
causes confusions and sporadically overblocking by this countermeasure, which is now no longer happening.

DNS Authentication

DNS Authentication
Reflection and Amplification Attack
Attacker
Resolver
1. Attacker uses source IP of the Victim to spoof

query which is sent to Resolver
Victim
2. Resolver responds to 54-byte query and
elicits a ~4200-byte response to the Victim

DNS Authentication
Dictionary Attack
DNS Cache DB Server
DB Server overwhelmed with

lookups
Attacker requests entries that
do not exist in the DNS Cache: NXDomain: abcd.somedomain.com
Query: abcd.somedomain.com NXDomain: efgh.somedomain.com
Query: efgh.somedomain.com NXDomain: ijkl.somedomain.com
Query: ijkl.somedomain.com ...
…

DNS Authentication
Overview
Passive → Caching/Recursive Servers & Authoritative Servers

Active UDP → Authoritative Servers
Active TCP → Caching/Recursive Servers & Authoritative Servers
Each protection mode is preferred for certain attack type and has
disadvantages that must be considered
• Only one protection mode per mitigation
• DNS Authentication does not Deny List failing hosts
The Domain Name System distributes the responsibility of assigning domain names and mapping those names to IP
addresses by designating authoritative servers to be responsible for their particular domains, and in turn can assign
other authoritative servers for their sub-domains. This mechanism has made the DNS distributed and fault tolerant
and has helped avoid the need for a single central register to be continually consulted and updated.
Non-authoritative servers do not contain copies of any domains. Instead they have a cache file that is constructed
from all the DNS lookups they have performed in the past for which they have gotten an authoritative response and
for which the response has not "timed-out."
When a non-authoritative server queries an authoritative server and receives an authoritative answer, it passes that
answer along to the requester as an authoritative answer. Thus, non-authoritative servers can answer authoritatively
for a given DNS request. However, if another request comes for a different name in the same domain, they can't
answer without asking an authoritative server for that domain.
Most often, a non-authoritative server answers with a previous lookup from its lookup cache. Any answer retrieved
from the cache of any server is deemed non-authoritative because it did not come from an authoritative server.
For Passive and Active TCP protection modes, DNS Authentication Timeout is number of seconds after
which DNS request is considered to have failed authentication

DNS Authentication
Configuration Overview
DNS Malformed
DNS Rate Limiting
DNS Authentication
DNS NXDomain
Rate Limiting

DNS Authentication
Passive Mode
Drops the first DNS request (UDP/53) from a client

• If client retransmits DNS request within DNS Authentication Timeout
period, source address is allowed
• Retry and subsequent requests are passed to destination
Only works well for randomly spoofed address attacks where

each packet is a unique source IP
DNS Authentication Passive Mode intercepts a DNS request on port 53 and drops the request. If the
source host retries the same request within a time period shorter than the DNS Authentication Timeout,
then the source host is approved. The retry and all future DNS requests are forwarded to the destination
hosts. DNS Authentication Passive mode is intended to protect against DNS request attacks that request
information for randomized names or use spoofed source addresses. It is not effective against attacks
that reuse source addresses or are launched from real IP host addresses, such as most botnet attacks.

DNS Authentication
Active UDP Mode
Useful for protecting Internet-facing DNS servers that only respond to

queries for which they have authoritative answers
• Protects the Authoritative Servers for the zone
• Only recursive/caching DNS servers can authenticate
1) Traffic from unauthenticated clients is dropped
2) DNS Client (recursive servers) are re-directed using a NS record response (TMS)
3) DNS Client follows challenge and is authenticated for 60 seconds
We use a NS record to redirect the server to the "authoritative server" (our cookie). The key is that unlike a normal
DNS server, the TMS does NOT give the A record for the server in the redirect (e.g. we give the name but not the
phone number). So the recurser is forced to do a look up the name (our cookie), thus authenticating itself. All
queries for top level domains or root will be passed by default.
DNS Authentication UDP Active Mode is intended to protect authoritative DNS servers against any scripted DNS
attacks that do not follow DNS NS redirects. It is effective for attacks both from botnets using real IP hosts and
from spoofed attacks, including those that reuse spoofed source addresses. UDP Active Mode will block legitimate
DNS queries when a protected server is not authoritative for the domain name in the intercepted query. UDP Active
Mode is thus useful for protecting Internet-facing DNS servers that only respond to queries for which they have
authoritative answers. UDP Active Mode should not used to protect DNS servers that provide recursive redirects to
client hosts. For example, UDP Active Mode should not be used to authenticate end-host subscribers to protect the
primary DNS servers for those subscribers, unless those DNS servers provide full DNS proxy.
Active UDP protection mode has an idle timeout (default 60 seconds) for authenticated clients. Any
authenticated client that expires due to an extended idle time will have to re-authenticate when they
become active again.

DNS Authentication
Active UDP Mode (Cont.)
DNS Authentication Active UDP Mode intercepts a DNS request on UDP port 53 and returns a spoofed
DNS response to the client. The spoofed response contains an NS record for the requested domain
redirecting the request to a fake nameserver domain name that includes a cookie hash as part of its
name, and does not include an address “glue” record for the fake nameserver. A properly implemented
DNS client will respond with a DNS query for the address of the fake nameserver. The TMS detects the
cookie hash in the DNS query and approves the client source address as authenticated, and spoofs a
new response that gives the destination address of the original intercepted query as the address of the
fake nameserver. Most clients will then retry the original DNS request to the original nameserver IP
address, except that internally the client is using that IP address from the fake nameserver record. If it
does, then the extra NS record is harmless.

DNS Authentication
Client TMS DNS Server
Some DNS proxy servers acting as DNS clients will cache DNS response records in a way that prevents
them from making a query to an IP address when a successful answer from that address already exists in
the cache. This prevents the client from repeating the same query after authentication approval using the
fake nameserver record because it already has the spoofed NS record cached as a response to the same
query to the same IP destination address. Arbor TMS can accept a list of secondary DNS server
mappings that specify a DNS server IP address to be used in the A-record response to the fake
nameserver address query instead of the destination IP address from the original query. Secondary
servers are normally included as part of a TMS Group configuration so that they do not need to be
configured in individual mitigations, but they may be configured directly in a mitigation if that mitigation
does not use a configured TMS Group.

DNS Authentication
Client TMS DNS Server

DNS Authentication
Active TCP Mode
Uses the “Truncate” feature of the DNS protocol as a form of DNS

redirection during authentication
• Client usually handles DNS Truncate in IP stack
• Seamless transition is invisible to client applications
• Effective regardless of whether the protected server is authoritative or not

for the queried domain name
– Must be able to handle DNS queries over TCP
DNS Authentication Active TCP Mode is intended to protect modern DNS servers against scripted DNS
attacks. It is effective for attacks both from botnets using real IP hosts and from spoofed attacks, including
those that reuse spoofed source addresses. It is effective regardless of whether the protected server is
authoritative or not for the queried domain name. It does not work for a protected DNS server that does
not accept DNS requests over TCP from arbitrary clients, or when the server is behind a firewall that
filters or blocks DNS over TCP from arbitrary clients. All modern DNS servers are capable of serving DNS
over TCP, but sometimes restrict TCP service to only selected hosts for security reasons, such as
allowing TCP only for zone transfers between authoritative servers.
Effective for attacks both from botnets using real IP hosts and from spoofed attacks, including those that
reuse spoofed source addresses

DNS Authentication
Active TCP Mode
TCP DNS query intercepted between client and DNS Server when
client is authenticated the TCP DNS query is forwarded
1. First DNS query (UDP/53) from client intercepted and spoofed reply from TMS
with Truncate bit set returned
– Indicates the response can not fit in the small UDP packet
– Typical client behavior is to switch to TCP for large response
2. Second DNS query (TCP/53) from client to server passed by TMS
– TCP SYN Authentication is disabled for port TCP/53
– Valid clients will resend the query over TCP/53
– TCP/53 should not be blocked by the Firewall
DNS Authentication TCP Active Mode intercepts a DNS request on UDP port 53 and returns a spoofed DNS
response to the client that has the DNS Truncate bit set and no response record data. The TMS also opens a rate-
limited path TCP port 53 traffic between the client and server IP addresses for a short time. A properly
implemented DNS client will respond to the spoofed response by retrying the original DNS query using TCP port
53. The TMS detects a TCP DNS request using the same source and destination IP addresses that it previously
intercepted in UDP and approves the client source address as authenticated. The TCP DNS request is forwarded
toward its destination. Most protected DNS servers will accept the TCP connection and will respond normally to
the DNS request.

DNS Authentication
Recommendation
• NETSCOUT currently suggests TCP Active Mode as the default

protection for DNS Servers
– Where protected servers must respond to TCP DNS requests from arbitrary
clients
• Active UDP mode may be a choice
– If servers do not support TCP DNS requests from arbitrary clients, and the
servers are authoritative for all legitimate desirable DNS Requests
• Passive Mode is generally recommended only when:
– A high-traffic DNS attack is using random IP source addresses
– Neither Active mode can be used due to DNS server configuration constraints

DNS Rate Limiting Options

DNS Rate Limiting – Query Limit

Overview
Protects against attacks from legitimate hosts
DNS Rate Limiting tracks queries per second by authenticated source address
• If all DNS queries exceed DNS

Query Rate Limit, the source is
blocked
• If unique DNS queries exceed DNS

Query Object Limiting, the source is
dropped or blocked
The DNS (Query) Rate Limiting countermeasure is intended to prevent hosts from overwhelming the
resources of a DNS nameserver by sending too many DNS query request messages. The DNS Query
Rate Limit should be set to a value that is a reasonable maximum value for user clients of the
nameserver infrastructure. DNS queries exceeding this rate is are dropped and the source is blocked. The
default limit is almost always acceptable for typical users. Higher limits are usually required only when
Arbor TMS is deployed internal to a network instead of near the peering edge, such as at a data center
border, so that it monitors DNS queries from servers with high outgoing connection rates such as email
servers. Qualifying servers may greatly exceed the query rate setting and may need to be protected by
adding those servers to a “pass” rule in the Deny / Allow List filter.

DNS Rate Limiting – NXDOMAIN Limit

Overview
Limits the rate at which clients may send DNS queries for non-existent
domains (NXDomain responses)
• Queries per second are based on source/destination pair

• Failed queries exceeding DNS NXDomain Rate Limit → the source is blocked
DNS NXDomain Rate Limiting is intended to monitor hosts that attempt excessive numbers of DNS
queries for non-existent domains, and to prevent those sources from overwhelming the resources of a
DNS nameserver. Typically legitimate DNS queries have a high success ratio; a high rate of queries for
non-existent domains is a more likely indicator of an attacker than simply a high rate of queries, and the
allowed rate for failed queries can be lower without impacting legitimate users.
The DNS NXDomain Rate Limit should be set to a value that is a reasonable maximum value for user
clients of the nameserver infrastructure. The default limit is almost always acceptable for typical users,
but a lower limit is also acceptable. Typically, with the default setting, the NXDOMAIN rate
countermeasure is used primarily to obtain lists of blocked hosts so that they may be investigated as
possible attackers. Higher NXDOMAIN rate limits are not usually required, since even servers with high
transaction rates do not usually have high DNS failed-query rates unless poorly configured. Important
servers may be protected anyway by adding those servers to a “pass” rule in the Deny / Allow List filter.

DNS Rate Limiting – NXDOMAIN Limit

TMS Design
TMS must see DNS NXDOMAIN response from the server
• Inline mode with symmetric traffic flow

Attack
TMS
DNS Server
• Offramp mode combined with a SPAN port returning the DNS server response
Attack
TMS SPAN
port
DNS Server
Since this countermeasure’s operation depends on monitoring NXDOMAIN responses from the servers,
they have to travel through the same TMS mitigation ports in the opposite direction of the corresponding
queries.
It is possible for an offramp deployment to configure a mitigation interface to accept SPAN response
traffic from the DNS servers for the purpose of supporting DNS NXDOMAIN Rate Limiting acting on DNS
queries forwarded through other TMS ports. A third mitigation port would be connected to a switch SPAN
port mirroring the response traffic from the DNS server.
The UI for the Patch Panel has a DNS NXDomain Listening box next to each port configuration, which is
enabled to be able to use this countermeasure.



Overview
DNS domain filtering is designed to block attacks that contain unique

DNS domain name information
• Countermeasure is composed of two filtering types:
– DNS Regex Expression
– DNS Filter Lists
• Processing of DNS Filter Lists is more efficient than DNS Regular Expressions,
but filtering is more flexible with DNS Regular Expressions
• DNS requests are typically decoded using string-based, instead of hex-based,
matches
This DNS-specific countermeasure is composed of Regular Expression Filtering and Filter Lists. DNS
domain filtering of both types is designed to block attacks that contain unique DNS domain name
information. Common uses are to block known suspect domain names that are statically configured in
attack tools, or to limit DNS requests to only those domain names that have answers on the protected
servers. The latter case is often used against attacks with randomized domain queries.
DNS Regular Expression Filtering compares a regular expression to each domain queried in a DNS query
request. DNS Filter Lists compare lists of regular expressions to each domain queried in a DNS query
request. Only five regular expressions may be manually entered for a mitigation, but filter lists may
contain thousands of entries. Processing of DNS Filter Lists is more efficient than DNS Regular
Expressions, but filtering is more flexible using DNS Regular Expressions.


Configuration
Drop matched traffic
or unmatched traffic
Choose record type from

dropdown (default = all)
Up to 5 regular expressions
OR → either may match

AND → all must match
DNS Regular Expressions are entered manually for each mitigation or mitigation template. Up to five
domain regex statements can be specified. The countermeasure compares a PCRE-format regular
expression to each domain queried in a DNS request and, if multiple regular expressions are set, the user
can set whether any (OR Expressions) regular expression may cause an action or if all (AND
Expressions) regular expressions must match to trigger an action. The countermeasure may be set to
drop requests when a regular expression match is found and pass requests that have no match, or pass
requests when a match is found and drop requests that have no match. Counters show the rate of
matches for each regular expression in a running mitigation.
DNS Filter Lists are user-chosen lists of regular expressions that are compared to each queried DNS
domain. DNS filter lists are intended for previously known location information that defines either
legitimate or unacceptable requests for protected servers. DNS filter lists are configured in Arbor Sightline
and are only selected for a particular mitigation. Multiple DNS filter lists may be selected. A match of a
domain to any regular expression in any selected filter list will mark a DNS request as a filter list match.
No counters exist for filter list matches.
The mitigation user may select whether an action should be taken based on a match for either DNS
Regular Expression or a DNS Filter List, or only upon a match by both.


Match regular expressions

to inbound requests,
inbound responses, or both
Source host can be

blocked instead of a single
packet drop
• Deny List → Doesn’t allow
them to shift queries to
other domain names on
the same server
The Apply DNS Regular Expression to selection allows the countermeasure to match inbound requests, inbound
replies, or both. The default selection is to only match inbound requests with Queries Seen and Query Rate statistics
shown on the Mitigation Status page. When Inbound Replies is selected, Replies Seen and Reply Rate statistics
appear on the Mitigation Status page. When Both is selected, Queries and Replies Seen and Query and Reply Rate
statistics appear.
The Deny List on Blocked option will place the a host’s address on the temporarily blocked host list (dynamically
blocked) when this countermeasure blocks their DNS requests.


• Match multiple regular

expressions
• Choose DNS resource

record types to match,
such as A records or
TXT records
Click to add a new

regular expression
When you click in the Resource Record Types box, selecting a DNS resource record (RR) type from the
dropdown adds the selection to the list. You can add multiple RR types to the list. Each entry in the list is an RR
type name and its numeric value.
Your selection can include numeric values for RR types that are not on the list by typing the numeric
value and then pressing enter or click the highlighted value. For a list of DNS resource record types along
with their values and meanings, see section 3.2.2 of RFC 1035 on the IETF.org Web site
(https://www.ietf.org/rfc/rfc1035.txt)
In a DNS query from a DNS client to a DNS name server, the RD flag bit can be set or unset. If the RD
flag bit is set, and the DNS name server cannot resolve the query, it forwards the query to successive
upstream name servers until it receives a response that contains a fully resolved domain name. The RD
flag bit value is copied into every response to the query.
You can match on the value of the Recursion Desired flag bit in a DNS message:
Ignore (default)—RD flag bit is ignored when matching.
Set—Match if RD flag bit is set (1).
Unset—Match if RD flag bit is unset (0)


Use Case
• Drop all DNS queries for a certain domain

.+\.blockthisdomain\.com
• Pass all queries for certain domains or FQDNs public resolvable

www\.arbor\.net
mail\.arbor\.net
+ drop unmatched traffic
Note: Escape the ‘.’ as a string literal → ‘\.’


Sample Packets
Use of FQDN for matching

google.com
DNS Regular Expressions (RegEx): Customers can now configure a Arbor TMS countermeasure to look for
specific values in the header of DNS request packets. The DNS regular expressions are regular expressions that
Arbor TMS applies separately to each line of DNS requests that enter the mitigation. Other details of this feature
are below:
• If requests or any line of the header either match or do not match (depending on the settings) the expressions,
Arbor TMS dynamically drops the offending traffic coming from the source host.
• The DNS RegEx countermeasure supports up to five expressions evaluated simultaneously per mitigation.
• The countermeasure is a packet-by-packet analysis.
• Optionally it can place the source on a Deny List.


Use full packet decode

SIP Malformed

SIP Malformed
Overview
Block attacks that send invalid or blank SIP messages to a server to

• Basic SIP message types must conform to RFC 3261 Section 8.1
RFC 3261 • INVITE
• ACK
• Message types not defined in RFC 3261 will • OPTIONS
be ignored and transparently passed • BYE
• CANCEL
• UDP Keepalives are considered valid SIP • MESSAGE
packets≥9.3.5
SIP Malformed filtering is intended to block attacks that send invalid or blank SIP messages to a server to
exhaust resources or to exploit vulnerabilities by validating that SIP messages are in a proper format.
Basic SIP message types (INVITE, ACK, OPTIONS, BYE, CANCEL, and MESSAGE) must conform to
RFC 3261 section 8.1.

SIP Malformed
Caveats
Validates SIP Messages are in the proper format in two steps:

1) All packets sent to port 5060 are checked to make sure there is a
payload
– Packets without payload are dropped (except Keepalives)
2) SIP decoder verifies a SIP message has been received
− The message is checked for compliance to RFC 3261 section 8.1
– Source hosts are blocked when their SIP messages are dropped
SIP Malformed filtering is implemented as two modules. A per-packet pre-filtering module inspects every
packet received. If the packet is UDP and has a SIP destination port (usually 5060), the packet is checked
to make sure a payload exists that could be part of a valid SIP message. If the payload is missing, the
packet is dropped and the source host is blocked for one minute.
The SIP Malformed message validation module is event-driven and is signaled to run whenever the TMS
SIP decoder verifies that a valid SIP message has been received. The module inspects the message and
verifies that required headers exist, and then verifies that all headers specified in RFC 3261 section 8.1
are properly formatted and have reasonable values. If either verification check fails, the message is
dropped and the source host is blocked for one minute.



Overview
Blocks source clients that attempt to

send a high rate of SIP messages to a
SIP server or gateway
• Standard token-bucket to track the number
of messages per client
• If the SIP message rate is above the Limit,
the message is dropped, and the source
host is added to the Deny List
SIP Request Limiting is intended to prevent hosts from overwhelming the resources of a SIP server or
gateway by sending too many SIP request messages. The countermeasure is signaled to run whenever
the TMS SIP decoder verifies that a valid SIP message has been received. The countermeasure inspects
the message and updates stored rate data for SIP messages that have been sent from the source host to
the destination host. The rate data is then checked to see that the message rate is below a maximum
allowed rate or within a burst tolerance. If the SIP message rate is too high, the message is dropped and
the source host is blocked for one minute.
The SIP Source Limit should be set to a value that is a reasonable maximum value for user clients of the
local SIP infrastructure. Communications between SIP servers may greatly exceed the Source Rate
setting and may need to be protected by adding those servers to a “pass” rule in the Deny / Allow List
filter.


Sample Packets
Use of SIP Regular Expression for matching

• Allows for matching in the SIP data
• Match on phone numbers, INVITEs, anything inside of the SIP headers

Knowledge Check
Application Layer Attacks
Q1: HTTP Authentication belongs to which Q3: Which statement is true?
other counter measure?
a) DNS is only used as an attack target
a) TCP Connection Reset
b) DNS is used to reflect traffic for a DOS attack
b) TCP SYN Authentication
c) DNS is irrelevant for DOS Attacks
c) HTTP Malformed
d) DNS uses port 35
d) HTTP Rate Limiting
Q4: What is the correct a regular expression
Q2: Which TCP ports normally send plain text to match www.netscout.com?
HTTP traffic?
a) www.netscout.com
a) 80
b) www\.netscout\.com
b) 8080
c) www*netscout*com
c) 443
d) www/.netscout/.com
d) 3443
Solution: Q1: b Q2: a,b Q3: b Q4: b




Step2
• Lab Objectives:
• Mitigating Application Layer Issues


• Block generic Application Layer attacks
• Perform more specific blocking on HTTP attacks
• Perform more specific blocking on DNS attacks
• Blocking of SIP and TLS based attacks



Enhancing Mitigations
Sightline/TMS
NETSCOUT University Enhancing

CONFIDENTIAL & PROPRIETARY Mitigations - 1
Unit Summary
• Understand the use of Scoping Countermeasures
• CDN Support
• Cloud Signaling
• Mitigation Templates Concepts
• Auto-Mitigation
• Learning Mitigation

Scoping Countermeasure
Unit 11: Enhancing Mitigations

Overview
www.ABC.net
GET /admin.php www.ABC.net
GET /admin.php www.rock.org
Will this stop the attack? www.news.com

HTTP Regex: GET \/admin\.php
Yes, but….
Solution?
HTTP Regex: GET \/admin\.php
+ TMS
Scope: Host: www\.rock\.org a.b.c.d
Focus DNS or HTTP countermeasures to be applied more specifically to:

• Specific virtual servers or NAT/load-shared servers share an IP address with other servers
• A portion of domains handled by the same servers
• Many related domains on many servers with many IP addresses
• Domains with server IP addresses that are variable or unknown
• Domains being used by attacks on servers that don’t serve for that domain
• Make best use of TMS countermeasure capacity

Overview (Cont.)
Scoping allows you focus which traffic should be evaluated by the DNS
or HTTP countermeasures
• DNS or HTTP each separately supports:
– Up to 5 specific domain regular expressions
– Selector for whether countermeasures act on:
• Traffic matched
• Traffic not matched
• Supported to be preconfigured through mitigation templates
Focus DNS or HTTP countermeasures to be applied more specifically to:

• Specific virtual servers or NAT/load-shared servers share an IP address with other servers
• A portion of domains handled by the same servers
• Many related domains on many servers with many IP addresses
• Domains with server IP addresses that are variable or unknown
• Domains being used by attacks on servers that don’t serve for that domain
• Make best use of TMS countermeasure capacity

Overview

CDN Proxy

CDN Proxy
Overview
Hosting Data Center

TMS
Legit Users
Backend DBs Origin Server
Attackers
CDN Proxy Server
• Problem → Source IP of attack appears to be the CDN proxy server

– Countermeasures that add source hosts to the Deny List will block all users of that proxy
• Solution → Recognize when traffic is from a proxy server and adjust countermeasures to
block traffic based on flow rather than source IP
– Legitimate users get through; attackers are blocked
Arbor Sightline countermeasures that use the Deny List add an attacker’s IP address. When traffic is
routed through a CDN proxy, the source IP address of that traffic is the IP address of the last CDN proxy
device. That source IP address is shared by all of the users whose traffic passes through that device.
Therefore, the countermeasure settings that blocks an attacker’s IP address might discard all traffic from
the CDN proxy.
When you enable CDN Proxy Support, you can prevent the adding to the Deny List of a CDN proxy. Arbor
Sightline then uses the countermeasures of the mitigation to block just the malicious traffic through a CDN
proxy.

CDN Proxy
Overview (Cont.)
When CDN Proxy Support is enabled

• TMS looks for the following fields in the HTTP Header
➢ X-Forwarded-for
➢ True-Client-IP
• If detected and the packet or flow is violating one of the enabled counter-
measures, it will only drop the packet or flow
• Source IP of the packet will never be added to the Deny List
Arbor TMS can automatically detect proxies of some Content Delivery Networks (CDNs) by certain HTTP
header patterns such as “True-Client-IP”. Arbor TMS can automatically detect some firewall and web-
caching proxies by certain other HTTP header patterns such as “X-Forwarded-For.” When CDN Proxy
Support is enabled, a TMS will recognize CDN and firewall proxy servers and will not block those source
IP addresses. Countermeasures that identify attack traffic will instead either drop packets individually or
block traffic flows. A blocked flow is identified by source IP address combined with layer 4 IP protocol and
TCP/UDP source and destination ports. Legitimate users of the same proxy are thus not blocked and
should be able to continue to use the protected servers.
When a traffic flow is blocked, TMS will send a TCP reset to the proxy so that the proxy is informed that
the flow is no longer valid. Additionally, source IP addresses of detected proxies are exempted from
certain host-specific rate-based countermeasures.

CDN Proxy
Modified Countermeasures
Check modified to ‘drop’: Checks exempted:

• HTTP Malformed • DNS NXDomain Rate Limiting
• SIP Malformed • DNS Rate Limiting
• SSL Negotiation • HTTP Rate Limiting
• DNS Regular Expression • SIP Request Limiting
• HTTP Regular Expressions • TCP Connection Limiting
• Zombie Detection
The following countermeasures modify block behavior for detected proxy hosts:
• HTTP Malformed
• SIP Malformed
• SSL Negotiation
• DNS Regular Expression
• UDP DNS flows are dropped but not blocked.
• TCP DNS flows are blocked regardless of whether the block on Blocked setting is
selected.
• HTTP Regular Expressions (including AIF filters)
• Flows are blocked regardless of whether the block on Blocked setting is selected.
Source IP addresses of detected proxies are exempted from the following rate-based
countermeasures:
• DNS Rate Limiting / DNS NXDomain Rate Limiting
• HTTP Rate Limiting
• SIP Request Limiting
• TCP Connection Limiting

CDN Proxy
Configuration
Prevents blocking of a CDN (HTTP) proxy
• Select during mitigation

creation
• Option in mitigation
template
When creating a new mitigation, if not selected, you can Enable CDN Proxy Support to prevent the
blocking of a CDN proxy. This setting is a global setting that applies to all countermeasures in a mitigation
that can block a source IP address.
Recall that Arbor Sightline countermeasures can block an attacker’s IP address. When traffic is routed
through a CDN proxy, the source IP address of that traffic is the IP address of the last CDN proxy device.
That source IP address is shared by all of the users whose traffic passes through that device. Therefore,
the countermeasure settings that block an attacker’s IP address might block all traffic from the CDN
proxy.
When you enable CDN Proxy Support, you can prevent the blocking of a CDN proxy. Arbor Sightline then
uses the countermeasures of the mitigation to block just the malicious traffic from a CDN proxy.

Cloud Signaling

Cloud Signaling
Overview
Defense at the customer edge
DATA
ISP 1 CENTER
ISP
ISP 2
SATURATION
Firewall IPS
Load
Balancer
Target
AED Applications
ISP ‘n’ Attack Traffic & Services
Good Traffic

Cloud Signaling Sightline ≥9.4.0.0 supports

Cloud Signalling for
Overview (Cont.) IPv6 Traffic
Multi-Layer Defense (Sightline + AED) Cloud-based

DDoS Protection
SCRUBBING CENTER
ISP 1
DATA
Cloud CENTER
Signaling
ISP 2 ISP Firewall IPS

Load
Balancer
Target
ISP ‘n’
AED
On-premise
Applications
& Services
DDoS Protection

Cloud Signaling
Overview (Cont.)
UDP Heartbeat from AED still work →
AED includes Cloud Mitigation Request
a) Handshake (TCP 443) Sightline
– AED establishes connection with each

configured Sightline server
AED MGT
– Negotiates heartbeat parameters EXT INT
– Cloud Signaling Version determine

available capabilities
b) Heartbeat (UDP 7550) !
In-band communication design
– Asynchronous UDP every minute
– AED sends Heartbeat to each Sightline server
• Includes if cloud mitigation is needed or not
– Each configured Sightline sends Heartbeat to AED
• Includes mitigation state & statistics

Cloud Signaling
Configuration
Enable Cloud Signaling
Automatically respond on
Cloud Signaling
Cloud Signaling requests
Define Signaling Endpoint

on Sightline (Leader/UI’s)
Permit AED source IP for Signaling

Cloud Signaling
Cloud Signaling
Configure
per AED Automatically
signaling use all
credentials signaled Filter
List in
Mitigations
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 Sightline 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.

Cloud Signaling
Filter Lists
APS/AED filter lists automatically used in Cloud Signaling mitigations

• Whenever mitigation is created from Cloud Signaling alert page
• Applies to both auto-mitigations and manual mitigations
• Automatically removed when Cloud Signaling alert ends
– Allows Cloud Signaling auto-mitigation reuse with different APS
TMS Filter List Name TMS Countermeasure Usage

APS-<APS name>-<MO name>-drop-ip_address IPv4 Address Drop Filter List
APS-<APS name>-<MO name>-drop-ip_location IP Location Filter List
APS-<APS name>-<MO name>-drop-url URL Filter List in AIF and HTTP/URL Regular Expression
APS-<APS name>-<MO name>-pass-ip_address IPv4 Address Pass Filter List
AED filter lists updates

• Sent by AED to SP over normal Cloud Signaling messages
• AED sends an update when a deny list or allow list changes on AED
• AED sends a refresh of all four lists every 12 hours
AED filter lists on SP become empty when disabled on AED
• AED sends updates for all four lists with no filters
• Filter lists are not deleted but have no effect
AED can update filter lists on SP while Use Filter Lists in Mitigations is disabled in SP settings
• SP setting applies only to automatic use in mitigations

Cloud Signaling
Filter Lists (Cont.)
APS/AED filter lists cannot be deleted through the Sightline UI
Use CLI command to delete an APS filter list

/ services sp mitigation filters delete filtername

Mitigation Templates Concepts


Overview
Mitigation templates combine TMS

Group
global mitigation configuration
parameters with a pre-set Diversion BGP
Signalling
Prefix
group of IPv4 or IPv6
countermeasures that can be Template
used to thwart an attack.
Counter- Timeout
Mitigation templates are measures length
globally configured and can be

Filter
used by multiple Managed Lists
Objects
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 Sightline 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.


Defaults
Name Description
Sightline uses this as the default template for managed object IPv4 auto-
Auto-Mitigation IPv4
mitigations
Sightline uses this as the default template for managed object IPv6 auto-
Auto-Mitigation IPv6
mitigations
Sightline uses this as the default template for user-initiated IPv4mitigations. It
Default IPv4 includes optimum countermeasure settings for the most common types of
DDoS attacks
Sightline uses this as the default template for user-initiated IPv6mitigations as
Default IPv6 it includes optimum countermeasure settings for the most common types of
DDoS attacks
Provides countermeasures to support deployments for DNS infrastructure
DNS Flood Protection protection including DNS authentication, malformed DNS filtering, flood
protection, and zombie protection
VoIP Gateway Provides countermeasures to support VoIP gateway flood protection; use
Protection this template to protect against malformed VoIP traffic and floods
Sightline 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.


Example: Resource Based - Web Server Farm
• Enter Deny/Allow Lists to drop everything not web related

– Drop all ICMP, UDP* and other protocols
– Drop all traffic from private and IANA reserved space
– Drop all fragments
– Drop all TCP traffic other than those ports served by the servers
• Enable countermeasures that protect web servers
– Zombie Detection
– TCP SYN Authentication (including HTTP Authentication)
– TCP Connection Reset
– Application Slow Request Attack Prevention
* Study the protected resource before dropping
– HTTP Malformed all UDP to make sure this will not affect critical
functions such as DNS or network monitoring
– HTTP Rate Limiting
The resource-based template above is designed to protect a web server farm. We will enable the countermeasures
that we would typically employ for protecting web assets, namely Zombie Detection, TCP SYN Authentication,
TCP (Idle) Connection Reset, HTTP Rate Limiting, HTTP Malformed,.
In addition to enabling these particular countermeasures, it is also considered best practice to drop anything which
is not web related. Ultimately this will reduce the amount of work that the TMS has to perform by strictly limiting
the inspected protocols to those we explicitly want to allow to our protected assets. For example, the only allowed
protocols we would need to support in our environment would be TCP/80 (HTTP) and TCP/443 (HTTPS). Based
on the analysis of the environment it might be determined that ICMP and UDP protocols can be safely dropped
without adversely impacting anything in the environment.
In addition, it would make sense to drop all private and IANA reserved space (Bogons) as the traffic entering the
TMS will be coming from the Internet and it is highly unlikely that we would ever expect to see traffic entering our
environment sourced from these address spaces. It might make sense to possibly drop all fragments, especially if
PATH MTU discovery is allowed through to our end host and clients are expected to properly adjust their MSS
sizes accordingly. Certainly it would make sense to drop all bad combinations of TCP flags, for example, a packet
flagged with both the SYN and the FIN flags simultaneously. Or along similar lines, any TCP packets with no flags
at all.

Auto Mitigation

Auto Mitigation
Overview
Auto-Mitigation allows for a mitigation to be started automatically

without human intervention
• Managed Object Type: Customer
• Configuration Option: per Managed Object
• Trigger:
Alert Triggered Traffic Triggered

• Host Detection (only)
(not commonly used)
• Profiled Detection (only)
• Both

Auto Mitigation
Profiled Alerts
Auto-mitigation can be disabled for Profiled Router and Profiled

Network DoS alerts
• Setting is both global and per managed object
• Choose to perform auto-mitigation for host alerts and use profiled detection for
alerting only
– Host alerts often reflect legitimate attacks
– Profiled detection is much more likely to alert on traffic that may or may not be
an attack

Auto Mitigation
Alert Triggered
When enabled, a mitigation is initiated when the following is true:

1 Alert level is High
2 The alert is a Host alert (optionally: Profiled Router or Network)
3 The alert direction is Incoming
4 The alert has no existing mitigations
5 No other mitigation exists that is diverting the exact same prefix
Attacked destination falls within the constraint prefixes defined

6
within the Managed Object (if configured)
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.
Sightline 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.

Learning Mitigation

Learning Mitigation
Overview
Aid for setting rate-based countermeasure settings

• Gain usable threshold values
– Learn typical traffic rates for a set of rate-based countermeasures
– Learning mitigations is a real mitigation that passes all* traffic
• Can prevent another mitigation due to protection prefix overlap
• Results, aka learned dataset is a snapshot of the traffic rates that

were seen during that period
– Generated once, but can be used many times
– Used for countermeasure threshold settings in mitigation template or running
mitigation
COPYRIGHT © 2022 NETSCOUT SYSTEMS, INC. | CONFIDENTIAL & PROPRIETARY 29 *except Invalid Packets
Learned datasets are link to the MO in which they were created (learning mitigation run) but can be copied to other
managed objects.

Learning Mitigation
Configuration
Learning Mitigations count against the limit of running mitigations

allowed per TMS
Click the name of the learning mitigation to view results
Sightline 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, Sightline stops the
learning mitigation to allow the regular mitigation to start.

Learning Mitigation
Results
Learned dataset shows a

snapshot of seen traffic rates
for several different rate-
based countermeasures
• HTTP Rate Limiting
• DNS Rate Limiting
• DNS NXDomain Rate Limiting
• SIP Request Limiting
The learning 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)

Learning Mitigation
Running Mitigation
While running a mitigation, the

learned dataset (the gray-
shaded curve) will provide
context to aid in selecting
appropriate countermeasure
settings
Overlay previously
generated learned
dataset with the
current traffic

Knowledge Check
Enhancing Mitigations
Q1: What is the concept of Cloud Signaling? Q3: Which Alert Severity Level can be auto-
mitigated?
a) Building a multi-layer defense architecture
a) low
b) To replace Cloud-Protection services
b) medium
c) To switch between Cloud and on-Premise
protection c) high
Q2: What are valid design concepts for Q4: A learning mitigation requires traffic to be
Mitigation Templates? diverted.
a) Generic a) true
b) Resource based b) false
c) Attack based
d) Cost of Protection Service based
Solution: Q1: a Q2: a,b,c Q3: c Q4: a


• Understand the use of Scoping Countermeasures
• CDN Support
• Cloud Signaling
• Mitigation Templates
• Auto-Mitigation
• Learning Mitigation



NETSCOUT University
CONFIDENTIAL & PROPRIETARY
Corporate Headquarters This course material is based on
310 Little Road
Westford, MA 01886, USA
Arbor Sightline Release 9.5.0.0
Toll Free +1 888 357 7667
T +1 978 614 4000
Revised: 21st of March 2022
F +1 978 614 4004
www.netscout.com
Information presented in this document is subject to change without notice.
The contents of this publication may not be reproduced (in any part or as a
whole) without the permission of the publisher. Sightline is a trademark of
Copyright © 2022
NETSCOUT Inc. All other trademarks are the property of their respective
NETSCOUT, Inc.
All rights reserved.
owners.

SL DDOS Detection Mitigation User Course 1.16a R9.5.0.0

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

SL DDOS Detection Mitigation User Course 1.16a R9.5.0.0

Uploaded by

Copyright:

Available Formats

REV1.

3. Host Anomaly Detection

4. Profiled Anomaly Detection

5. Interpreting Anomaly Alerts

7. TMS Mitigation Workflow

9. State Exhausting Attacks

10. Application Layer Attacks

11. Enhancing Mitigations

NETSCOUT - Technical Trainings

Presentations, documents or other information

COPYRIGHT © 2022 NETSCOUT SYSTEMS, INC. | CONFIDENTIAL & PROPRIETARY 1

NETSCOUT University Sightline

COPYRIGHT © 2022 NETSCOUT SYSTEMS, INC. | CONFIDENTIAL & PROPRIETARY

NETSCOUT University Sightline

• Sightline Architecture Overview

• Sightline Traffic Visibility and Analysis

COPYRIGHT © 2022 NETSCOUT SYSTEMS, INC. | CONFIDENTIAL & PROPRIETARY 3

NETSCOUT University Sightline

Capturing Network Traffic

Unit 1: Sightline Introduction

COPYRIGHT © 2022 NETSCOUT SYSTEMS, INC. | CONFIDENTIAL & PROPRIETARY 4

NETSCOUT University Sightline

Capturing Network Traffic Information

Pervasive Network Advanced Threat Service

Traffic Views Detect + Mitigate Monetize network

NETSCOUT University Sightline

Capturing Network Traffic Information

FLOW BGP SNMP

COPYRIGHT © 2022 NETSCOUT SYSTEMS, INC. | CONFIDENTIAL & PROPRIETARY 6

NETSCOUT University Sightline

Capturing Network Traffic Information

NETSCOUT University Sightline

Capturing Network Traffic Information

NETSCOUT – Arbor Sightline

NETSCOUT University Sightline

Capturing Network Traffic Information

COPYRIGHT © 2022 NETSCOUT SYSTEMS, INC. | CONFIDENTIAL & PROPRIETARY 9

NETSCOUT University Sightline

Capturing Network Traffic Information

• Where is traffic • How can I save • BGP Blackhole

COPYRIGHT © 2022 NETSCOUT SYSTEMS, INC. | CONFIDENTIAL & PROPRIETARY 10

NETSCOUT University Sightline

Unit 1: Sightline Introduction

COPYRIGHT © 2022 NETSCOUT SYSTEMS, INC. | CONFIDENTIAL & PROPRIETARY 11

NETSCOUT University Sightline

Traffic and Routing Analysis (TRA)

Threat Mitigation System (TMS)

Data Storage (DS) TRA TRA Scrubbing

ASI Collector (AS) Backbone TMS TMS

Receive ASI DNSFlow messages from ISNG DS

COPYRIGHT © 2022 NETSCOUT SYSTEMS, INC. | CONFIDENTIAL & PROPRIETARY 12

NETSCOUT University Sightline

Use a hybrid TRA/Leader* appliances as a single point of access for managing

NETSCOUT University Sightline

NETSCOUT University Sightline

Sightline SP 7000 Sightline SP 7500 Sightline Virtual

A deployment can have any mix of

NETSCOUT University Sightline

Scalable Architecture 40 Gbps

1 – 10 Gbps @ 10 – 40 Gbps @ 1,5 – 40 Gbps @

1 Gbps 1 Gbps 1 Gbps

Data Center, Access Distributed Scrubbing Centers,

NETSCOUT University Sightline

60 Gbps TMS HD1000