Flowmon DDos Defender - Userguide - en

Flowmon DDoS Defender 3.00.
01
User Guide
May 4, 2016
Flowmon DDoS Defender 3.00.01
User Guide, May 4, 2016
Contents
1 Introduction 3
1.1 Universal Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Features and Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 System Description 5
2.1 Attack Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Response to Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Attack Visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 User Interface Description 8

3.1 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 Segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.3 Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.4 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.5 Scrubbing Centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.6 Attack Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.7 Common Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Attack List Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.1 Attack Status Column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.2 Action Status Column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.3 Tools Column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.4 Attack Detail Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4 BGP Injection 32
4.1 Router configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Network scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.1 Scenario 1: Defense Pro in IP Mode (single router) . . . . . . . . . . . . . . . . . . 34
4.2.2 Scenario 2: Defense Pro in IP Mode (two routers) . . . . . . . . . . . . . . . . . . 37
4.2.3 Scenario 3: Defense Pro in transparent mode (single router) . . . . . . . . . . . 39
4.2.4 Scenario 4: Defense Pro in transparent mode (two routers) . . . . . . . . . . . . 42
5 BGP Flowspec Injection 45

5.1 Router configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
www.flowmon.com 2 / 47
1 Introduction
Flowmon DDoS Defender is a solution for detection and mitigation of volumetric attacks - DoS
(Denial of Service) or DDoS (Distributed Denial of Service). Without any configuration changes,
topology changes or any additional investments in the network components, it is possible to detect
the volumetric attacks lead against the IT infrastructure, servers, critical systems or applications in
real time. In collaboration with Scrubbing centres or specialized solutions for DDoS attack elimina-
tion deployed out-of-band, Flowmon DDoS Defender mitigates and blocks such attacks automat-
ically. Deployment is a matter of minutes thanks to the universal architecture and the extensive
integration capabilities with network equipment or DDoS mitigation appliances
1.1 Universal Deployment

Flowmon DDoS Defender can be deployed in heterogeneous environments collecting common
flow statistics from the active network components in various formats and/or processing of highly
accurate flow statistics gained through the Flowmon Probes. Packet sampling necessary to handle
flow export on various devices is no limitation for DDoS Defender and detection accuracy.
Figure 1: Deployment scenarios
Thanks to the robust and versatile architecture, it is possible to deploy standalone DDoS De-
fender as well as in combination with specialized out-of-band solutions for DDoS attack elimina-
tion or together with attack mitigation services provided by Scrubbing centres. The integration with
network components is supported via PBR (Policy Based Routing), BGP (Border Gateway Protocol),
BGP Flowspec or you can possibly use the RTHB (Remotely Triggered Black Hole) mechanism as
a simple method of attack mitigation.
1.2 Features and Benefits

• Real-time DoS and DDoS attack detection
• Significant attack response time acceleration
• Dynamic baselining of traffic volumes and characteristics
• Acquisition and presentation of the attacks’ characteristics
• Notifications via e-mail, syslog, SNMP trap
• Advanced options of immediate reaction
• Support for standard methods of traffic diversion - PBR, BGP, BGP Flowspec, RTBH
• Independent configurations for different customers, services, network segments, etc.
• Plug-in for Flowmon solution, simple installation and quick time-to-value
• Entry level quality of flow data from various sources is sufficient, NetFlow v5/v9, IPFIX, jFlow,
NetStream, sFlow, sampled and non-sampled statistics are supported
2 System Description
Flowmon DDoS Defender solution (DDD module) is delivered as a module for Flowmon solution.
It is deployed together with Flowmon Collector and uses Flowmon Monitoring Center flow database
for attack detections. Thanks to this, the DDD does not require to configure a separate flow source.
The DDD module is focused on detection of volumetric attacks. The detection is based on flow
data collected by Flowmon Monitoring Center. The flow data can be from any source, e.g. router
or probe.
The DDD module can be deployed in three scenarios:
• Standalone - in this scenario, the DDD module is performing passive attack detections and
alerting and is not doing any attack mittigation.
• Out-of-band elimination of DDoS attack - in this scenario, the DDD module is performing
passive attack detections, alerting and can remotely trigger BGP Flowspec rule or a black hole
routing on selected routers for eliminating or rate limiting the attacks.
• Scrubbing Center - in this scenario, the DDD module is able to perform everything from the
above points and moreover, it can be integrated together with a scrubbing center in order
to mitigate attack and return the cleaned traffic back to the network. The scrubbing center
is connected out of the line and in case of attack mitigation, the DDD module can change
routing on selected router(s) in order to divert the traffic via scrubbing center for cleaning. The
cleaned traffic is then returned back into the network using static ARPs together with special
VRF tables or GRE tunnels (if supported by scrubbing center). The DDD module also configure
scrubbing center for cleaning and provide it with important traffic statistics, baselines etc.
necessary for proper traffic mitigation.
2.1 Attack Detection

Attack detection is done for every protected segment defined in the DDD module. The protected
segement is defined by network subnets. For each protected segment, two kinds of methods are
evaluated regularly: Baseline methods (Manual threshold method, Adaptive threshold method)
and Static methods (Incoming/Outgoing packets ratio). For each baseline method, one or more
baselines are built for defined learning period. Each baseline is regularly compared with current
traffic (please see details below) and attack is reported if the current traffic is too high. A minimal
amount of bits per second and packets per second can be defined for enabling an attack detection.
Two main methods are used for attack detection:
• Baseline methods
– Manual threshold - system generates single baseline for peak value of incoming packets
(Ip). User can specify a threshold value (Th) in percents for triggering attack. System com-
pares amount of incoming packets, baseline and specified threashold. Attack is triggered
if Ip > baseline * Th.
– Adaptive threshold - system generates multiple baselines for following traffic: TCP, UDP,
ICMP, TCP Syn packets TCP RST packets, TCP ACK FIN packets and TCP SYN ACK packets.
For each baseline, two thresholds are generated for attack and for suspect traffic. Values
of thresholds are generated automatically according to incoming traffic characteristics.
System compares amount of incoming packets with these thresholds and triggers either
attack or suspect alert in case the traffic exceeds a respective threshold.
• Static methods
– Incoming / Outgoing packet ratio - system compares amount of incoming (Ip) and outgo-
ing (Op) packets and a user-defined threashold (Th) in percents. Attack is triggered if Ip >
Op * Th.
User can specify also an amount of Minimal traffic in packets per second and bits per second.
This limit can be used in two modes:
• Trigger evaluation of detection methods - the above detection methods are evaluated only if
incoming traffic is exceeding both minimal bps and pps.
• Trigger attack - in this mode, the attack is triggered if incoming traffic exceeds both minimal
bps and pps. Also, the above detection methods are evaluated only if incoming traffic is
exceeding both minimal bps and pps.
2.2 Response to Attack

In case an attack is reported, the system can react in following ways or their combinations:
• Alert - it can send email, syslog or SNMP trap. Target email is provided in the DDD module,
target syslog and SNMP servers are configured in the Configuration Center.
• Route diversion - it can change routes on specified routers in order to trigger a black hole
routing or traffic diversion to scrubbing center.
• Traffic mitigation - it can configure an out-of-line scrubbing center for attack mitigation. It
includes baseline data configuration, protected segment configuration, mitigation configura-
tion etc. In this mode usually route diversion is performed as well to divert the attack traffic
via scrubbing center.
2.3 Attack Visualization

For detected attack, an operator can use analysis tools in the DDD module for obtaining infor-
mation about attack to know the source and target of the attack, its strength, L4 protocol charac-
teristic etc. Based on this information, the operator can decide if the attack should be mitigated or
not.
3 User Interface Description

Flowmon DDoS Defender solution (DDD module) is controlled by web GUI integrated to the
Flowmon solution. The module GUI can be accessed from the main page of Flowmon solution by
clicking on the DDD module icon.
Figure 2: Icon for access into Flowmon DDoS Defender on Flowmon main page
3.1 Configuration
In this page, the configuration of the DDD module is performed. It comprises of several panels
each configuring different part of system. They are described in the following sections.
3.1.1 Segments
In this panel, the protected segments are configured. Click on the Add new segment... but-
ton to open form for new segment configuration. In the form, provide Segment name and select
Parent profile (defined in Flowmon Monitoring Center) for this segment. Next, select Parent chan-
nels. Two options are available: All will use all parent channels even those added to parent profile
later, Only Selected will use only parent channels selected manually.
In Subnets window, provide list of subnets in the following format:
Subnet list in segment configuration

1.2.3.4/22
2.3.4.5/24
...
3.4.5.6/28
2 a01 : 8 c00 : f f 0 0 : d6 : : / 6 4
In Mitigate option, select the way of selecting traffic for mitigation. Following options are avail-
able:
• Subnets - Subnets configured in Subnets window will be used for mitigation.
• Preferred subnets - Selecting this option will display Preferred subnets window where a dif-
ferent set of subnets can be entered. These preferred subnets will be used for mitigation.
• Autodetected subnets - When a new attack is detected, the system will detect a target subnet
(or host) of this attack and will use it for mitigation. If possible, /32 subnet is used. If the target
area of attacked IP addresses is too wide, a less specific subnet will be used.
In Rule dropdown menu, select one of the defined rules (see below) which will be used for attack
detections. Also special static rule * Always on can be selected. This rule triggers selected action
(except alert - see below) permanently. It can be used for permanent traffic observation/mitigation
by scrubbing center, e.g. for critical servers etc.
In Action set, choose what actions are to be performed upon attack detection. You can select
one of the predefined alerts, one or more predefined routers for traffic diversion and one of the
predefined scrubbing center. Configuration of alerts, routers and scrubbing centers is described
below.
If one or more routers or scrubbing centers are selected above, the action for suspect and/or
attack detection can be configured to be performed automatically or manually by selecting either
Manual or Automatic option.
In Flowspec action dropdown menu a default action can be selected, if at least one Flowspec
router is assigned to this segment.
Maximal bandwidth for this segment can be provided if available, or it can be determined
automatically by the system. However, providing a maximal bandwidth manually improves the
detection. For example, if the segment is connected by 10Gbps uplink, provide this value here. If
the monitored traffic whenever exceeds the provided value, it will be turned into automatic mode
automatically.
Termination timeout defines a maximum time an attack over this segment can be in Non
active state until it is terminated and mitigation of this segment is stopped.
Current segments can be modified by clicking on Edit button and deleted by clicking on Delete
button. The segment can not be deleted if it is currently under attack.
3.1.2 Rules
In this panel, the detection rules are configured. Click on the Add new rule... button to open
form for new rule configuration. In the form, provide Rule name and configure detection methods,
i.e. enable which detection methods are to be used for detection and their parameters.
Option Minimal traffic can work in two modes. In mode Trigger evaluation of methods be-
low you can define a minimal amount of bits per second and packets per second that must be
present in protected segment in order to perform attack detection by baseline or static methods
Figure 3: Segments configuration panel
(see below). So if the traffic is below this limit, no detection will be done. In mode Trigger attack
the behavior is the same as in the previous mode plus it will trigger an attack if the traffic exceeds
both minimal bps and minimal pps.
Below this option you can configure two kinds of detection methods - Baseline methods and
Static methods. For all Baseline methods you can define Common settings, where you can define
a Baseline interval (i.e. baseline learning period) and you can choose whether you want to detect
attack even for baseline equal to zero (option Enable detection for zero baseline). Baseline can
be equal to zero only if no legitimate traffic is incoming to protected segments. This might appear
only in special cases, e.g. in lab environment. Leave this option disabled if you operate under
normal conditions. Option Minimal length of anomaly to trigger attack helps avoid false attacks
in case of short significant data bursts. They might appear in flow data of segment because of active
timeouts longer than 30 seconds - this comes from nature of flow data and cannot be avoided. This
phenomenon appears usually for small data amounts only (< 10Gbps). So if you see from time to
time such peaks in your segment traffic graphs, leave this value on 1:00 minute. Otherwise, you can
decrease it 0:30 seconds to make the detection faster However, if you see the peaks, they will be
usually followed by adequate drops in some of the following time slots.
Manual threshold is a baseline method using one baseline over total traffic and user-defined
threshold for attack trigger.
Adaptive threshold is a baseline method using multiple baselines and adaptive threshold.
Incoming / Outgoing packets is a static method comparing amount of incoming and outgoing
Figure 4: Create segment form
packets.
See section 2.1 for more information.
Current rules can be modified by clicking on Edit button and deleted by clicking on Delete but-
ton. The rule can not be deleted if it is currently assigned to some segment.
3.1.3 Alerts
In this panel, alerts are configured. Click on the Add new alert... button to open form for new
alert configuration. In the form, provide Alert name and select which alerting methods should be
Figure 5: Rules configuration panel
Figure 6: Create rule form
used. You can select Send syslog or Send SNMP trap (server IP addresses are defined in Configu-
ration Center), Send email and Run script option.
Send email
For Send email option, list of recepients must be provided (comma-separeted list of email ad-
dresses). Next, select an email template from drop-down menu (list of templates can be modified -
please see below). This template defines a content of email subject and body. Last think to config-
ure is selecting a trigger for sending email. Following options can be selected:
• Send when attack is detected - send email instantly when new attack is detected
• Send when attack is detected and PDF report is generated - send email when new attack is
detected and attack statistics are collected. An attack report in PDF format with attack details,
graphs and statistics will be attached.
• Send when attack is ended - send email when the attack has ended (manually or automati-
cally). An attack report in PDF format with attack details, graphs and statistics will be attached.
Run script
For Run script option, the script must be uploaded. An example script is provided below. In
Script parameters field, the parameters for the script can be provided. Below this option, a trigger
for running script can be configured. Following options can be selected:
• Run when attack is detected - run scipt instantly when new attack is detected
• Run when attack is detected and attack characteristics are collected - run script when
new attack is detected and attack statistics are collected. Attack statistics are available.
• Run when attack is ended - run script when the attack has ended (manually or automati-
cally). Attack statistics are available.
Following variables are present and set on every type of event.
• SEGMENT - Full human readable name of the segment.
• ATTACKCLASS - Triggered level of the attack (attack, suspect).
• EVENT - Which event was triggered (detected, statistics, ended).
– detected - This event is triggered after given attack is detected.

– statistics - This event is triggered when statistics of given attack traffic are available.
– ended - This event is triggered when given attack has ended (including any timeout set
for given segment).
• SUBNETS_ARRAY - Array of subnetworks defined in given segment.
– Example: (’192.168.3.0/24’ ’192.168.1.0/30’)
• ATTACKID - internal ID of the attack (unique numerical value)
• ATTACKTYPE_ARRAY - An array of triggered methods for given attack.
– Structure of array: detection_method:traffic_type[:suspect].

– Example: (’in_adaptive_baseline_rate:udp:suspect’ ’in_baseline_rate:in’ ’in_out_rate:in_out’)
• IAD_VARIABLES_ARRAY - An array of variable names exported to the script.
Note: Variables of type array have the suffix ’_ARRAY’.
Description of all statistics available in script follows. All variables releated to statistics share
the same prefix STAT_, which is followed by the subject of given statistic. Each statistic is exported
in a form of two arrays. This first one has variable name with the suffix _KEY_ARRAY and holds
ordered list of key values. The second array has name with the suffix _VALUE_ARRAY and holds
ordered list of values. These two arrays are ordered in the same manner so that reading from
the same array index produces a pair of key value and corresponding value. For example, the
STAT_DSTIP statistic will provide pairs of IP address and number of received packets. The statistics
are ordered in descending order and the number of pairs is limited to 10. Statistic are only available
during event ’statistics’ and ’ended’ and are based only on the first few minutes of given attack.
Note: Not all statistics listed bellow will be available at all times, but only statistics configured to be calculated
automatically in the DDoS Defender configuration are provided to user scripts.
All variables releated to statistics share the same prefix STAT_, which is followed by the subject
of given statistic. Each statistic is exported in a form of two arrays. This first one has variable
name with the suffix _KEY_ARRAY and holds ordered list of key values. The second array has name
with the suffix _VALUE_ARRAY and holds ordered list of values. These two arrays are ordered in
the same manner so that reading from the same array index produces a pair of key value and
corresponding value. For example, the STAT_DSTIP statistic will provide pairs of IP address and
number of received packets. The statistics are ordered in descending order and the number of
pairs is limited to 10. Statistic are only available during event ’statistics’ and ’ended’ and are based
only on the first few minutes of given attack.
Note: Not all statistics listed bellow will be available at all times, but only statistics configured to be calculated
automatically in the DDoS Defender configuration are provided to user scripts.
• STAT_DSTIP_ - Destination IP addresses with most incoming packets.
Example
STAT_DSTIP_VALUE_ARRAY=(’7953539’)
• STAT_PROTO_ - Present L4 protocols ordered by transferred packets.
Example
STAT_PROTO_VALUE_ARRAY=(’7953520’ ’18’ ’1’)
• STAT_FLAGS_ - Most common TCP flags.
Example
STAT_FLAGS_VALUE_ARRAY=(’7953521’ ’18’)
• STAT_SRCAS_ - Destination AS ordered by transferred packets.
Example
STAT_SRCAS_VALUE_ARRAY=(’7953539’)
• STAT_SRCIFC_ - FMC Source ordered by incoming packets.
Example
STAT_SRCIFC_VALUE_ARRAY=(’7953539’)
• STAT_SRCCTRY_ - Source Country (ISO 3166-1 Numeric code) ordered by transferred packets.
Example
STAT_SRCCTRY_VALUE_ARRAY=(’7953539’)
• STAT_DSTPORT_ - Destination port/L4 Protocol ordered by transferred packets.
Example
STAT_DSTPORT_VALUE_ARRAY=(’7953520’ ’18’)
• STAT_SRCNET16_ - Source /16 subnet ordered by transferred packets.
Example
STAT_SRCNET16_VALUE_ARRAY=(’7953539’)
• STAT_SRCNET8_ - Source /8 subnet ordered by transferred packets.
Example
STAT_SRCNET8_VALUE_ARRAY=(’7953539’)
An example script follows.
Example script
# --- MANDATORY PART ---

. /usr/local/bin/iad_alert_functions
parse_alert_data # parse alert data and store them to variables
# --- END OF MANDATORY PART ---
echo "\${IAD_VARIABLES_ARRAY[@]}" # print list of valid variables

alert_data_print # print all valid variables and their values
Email templates
In this section, email templates can be modified. New template can be added by clicking on
Add new template ... button. Current template can be modified or deleted by clicking on Edit or
Delete button respectively. Default template can not be deleted. Adding new or modifying current
template will open Edit Email Template form. In this form, Template name must by provided.
Next Language must be selected. This option controls the language in which the email content will
be sent. Email subject and Email body fields define the content of subject and body of the alert
email. They can contain following predefined macros.
• %SEGMENT - name of segment in which the event was triggered
• %EVENT - event type (e.g. Detected, Attack details available, Ended, Ended by user ...)
• %TIME - date and time of event
• %DEVICE - name of device
• %LINK - URL link to attacks page
• %MITIGATION_TYPE - mitigation configuration (e.g. Manual Mitigation is set up ...)
• %MITIGATION_STATUS - current mitigation status (e.g. Mitigation is not running ...)
• %SUBNETS - list of subnets defined for segment
• %METHODS - list of triggered detection methods
Figure 7: Email template configuration panel
Current alerts can be modified by clicking on Edit button and deleted by clicking on Delete
button. The alert can not be deleted if it is currently assigned to some segment.
Figure 8: Alerts configuration panel
Figure 9: Create rule form
3.1.4 Routers
In this panel, routers are configured. Click on the Add new router... button to open form for
new router configuration. In the form, provide Router name and its IP address. The Method
option is used for selecting the approach used for routing configuration.
First option is ACL configuration. In this case, the DDD module logs directly to command line
interface of the router and configures access list (Cisco) or prefix list (Juniper and Alcatel). For
this option, you must select Vendor of the router from the provided list. For Cisco, standard IOS
is supported only. Next, Access list or Prefix list name must be provided. In case of Cisco and
Alcatel router, separate Access/Prefix lists must be provided for IPv4 and IPv6 subnets. At least one
of them must be provided. If Access list for IPv4 is provided only, then segment cannot contain IPv6
subnets, otherwise they won’t be redirected! For command line interface access, select protocol
in Connect with drop down menu and provide Login and Password. For this scenario, a static
routemap must be configured on router in order to divert all traffic passing through the provided
access/prefix list. The access/prefix list is configured automatically by the DDD module, which is
adding/removing subnets of protected segments upon mitigation start/stop request.
Here you can find a list of commands used for ACL configuration for specific vendor.
Cisco Add IPv4 Rule

conf t
ip access− l i s t extended < a c l −name>
<subnet−id > permit ip any <subnet > <mask>
no deny ip any any
2147483647 deny ip any any
end
logout
Cisco Add IPv6 Rule

conf t
ipv6 access− l i s t < acl6−name>
permit ipv6 any <subnet >/ <mask> sequence <subnet−id >
no deny ipv6 any any
deny ipv6 any any sequence 2147483647
end
logout
Cisco Remove IPv4 Rule

conf t
ip access− l i s t extended < a c l −name>
no permit ip any <subnet > <mask>
end
logout
Cisco Remove IPv6 Rule

conf t
ipv6 access− l i s t < acl6−name>
no permit ipv6 any <subnet >/ <nmask>
end
logout
Juniper Add IPv4/IPv6 Rule

configure p r i v a t e
set p o l i c y −options p r e f i x − l i s t < a c l −name> <subnet >/ <mask>
commit
exit
exit
Juniper Remove IPv4/IPv6 Rule

configure p r i v a t e
d e l e t e p o l i c y −options p r e f i x − l i s t < a c l −name> <subnet >/ <mask>
commit
exit
exit
Alcatel Lucent Add IPv4 Rule

configure f i l t e r match− l i s t ip−p r e f i x − l i s t < a c l −name> create
p r e f i x <subnet >/ <mask>
exit
logout
Alcatel Lucent Add IPv6 Rule

configure f i l t e r match− l i s t ipv6−p r e f i x − l i s t < acl6−name> create
p r e f i x <subnet >/ <nmask>
exit
logout
Alcatel Lucent Remove IPv4 Rule

configure f i l t e r match− l i s t ip−p r e f i x − l i s t < a c l −name>
no p r e f i x <subnet >/ <mask>
exit
logout
Alcatel Lucent Remove IPv6 Rule

configure f i l t e r match− l i s t ipv6−p r e f i x − l i s t < acl6−name>
no p r e f i x <subnet >/ <mask>
exit
logout
Next option is BGP. In this case, the DDD module performs injection of routes by BGP protocol
to routers selected in BGP neighbor option. Select the BGP injector device in the BGP injector
drop down menu. The BGP injector can be DDoS Defender itself or DefensePro Scrubbing center.
If the BGP injection is done by DDoS Defender, the BGP mode (iBGP, eBGP, Flowspec) must be
selected. Next field allows user to provide (Extended) BGP Community, which is optional. Many
formats of Community or Extended Community is supported - please click on info icon on the right
side of this field to see the supported formats. For iBGP mode, AS number must be provided
together with Next HOP address for IPv4 and/or IPv6. For eBGP and Flowspec mode, both router
and DDoS Defender autonomous systems must be provided. Next HOP cannot be defined in eBGP
mode and must be configured directly on router.
If the DefensePro scrubbing center is configured to be used as BGP injector, it is configured by

DDD module directly by connecting to DefensePro command line interface, so connection protocol
in Connect with drop down menu must be provided as well as Login and Password. The Test
button can be used for testing that the connection to router is working properly and whether the
router is correctly configured.
Figure 10: Routers configuration panel
3.1.5 Scrubbing Centers
In this panel, scrubbing centers are configured. Click on the Scrubbing center icon next to its
name to forward to Scrubbing Center GUI. Click on the Add new Scrubbing Center... button to
open form for new scrubbing center configuration. In the form, provide Scrubbing center name
and its IP address, Login and password. In OSCI option, select supported scrubbing center.
DefensePro/Vision Scrubbing center Radware DefensePro controlled via management con-
Figure 11: Create router form
Figure 12: Scrubbing Centers configuration panel
sole APSolute Vision is supported and can be configured by DDD. For configuration, a template file
is generated by DDD and then applied via Vision to all selected DefensePro boxes. The template
content depends on Vision settings available via Edit default settings button in Scrubbing Centers
panel, where default configuration can be set. Via Settings button in Edit segment form, either the
default settings can be selected, or specific configuration for this particular segment can be set.
DDD detects also a maximum bandwidth of each segment over non-attack traffic. It can be set
manually, if necessary in the same configuration form.
Figure 13: Create scrubbing center form
3.1.6 Attack Statistics
In this panel, advanced attack statistics can be enabled for automatic precomputing. Without
precomputing, in attack details (see section 3.2.3) the advanced statistics can be computed upon
user request. The computation may take longer time. To speed it up, important statistics can
be selected here and these statistics will be precomputed upon attack detection, so they can be
accessed quickly. On the other hand, it increases the collector utilization, so please choose wisely,
which statistics to precompute.
3.1.7 Common Settings
In this panel, a unique identifier of DDoS Defender instace can be defined. This identifier is used
to differentiate rules configured on Scrubbing center by multiple DDD instances. This value can be
changed only if no mitigation is in progress.
Figure 14: Configure Vision template for DefensePro
Figure 15: Select attack statistics for precomputing
Figure 16: Unique identifier configuration
3.2 Attack List Page

In this page, the list of attacks is provided. Attacks are sorted by their status. Starting attacks
first, followed by Active, Not Active, Ended attacks with mitgation start/stop failed and finally
Ended attacks. Attack status is displayed in the first column. In the next 3 columns following
information is provided: start time, end time and target segment name.
Figure 17: Attack List page
3.2.1 Attack Status Column
In Attack status column, the name of status together with coloured square icon is used to sig-
nal the current status of the attack together with additional information. The coloured sqare can
contain following flags giving the additional information:
• ? - question mark flag is used for suspect attack - the system detected something suspicious
which not need to be an attack.
• ! - exclamation mark flag is used in case some error occured (e.g. mitigation start failure). You
can click on it and acknowledge the error resulting in removing the ! flag.
• F - F flag is used for attacks marked as false positives by user. The attack can be marked/un-
marked as false positive in the attack details form (see below).
Figure 18: Attack flags
3.2.2 Action Status Column
In Action status column, the following actions may appear. You can hover your mouse over
clock icon to see time of an action.
• Detected - an attack was detected. Hover your mouse over info icon to see type of attack. This
action might appear multiple times for single attack in case another threshold was exceeded
or in case this attack was not active for some time.
• Not Active - this attack was not active from this moment
• Ended - this attack was ended. It might has been ended automatically after Termination
timeout, or manualy by clicking on Disable button. In case of manual ending, "M" icon is
displayed.
• Not Confirmed - this attack was detected by DDoS Defender and mitigation on Scrubbing
center was started. However, Scrubbing center did not detect this attack at all so it turned
into Not Active status and then into Ended status after Termination timeout.
• Mitigation Start - Mitigation was started successfully. You can click on this action to display
action log. It might has been started automatically or manually. Appropriate icon "A" or "M" is
displayed accordingly.
• Mitigation Stop - Mitigation was stopped successfully. You can click on this action to display
action log. It might has been stopped automatically or manually. Appropriate icon "A" or "M"
is displayed accordingly.
• Always On Mitigation Start - Always On Mitigation was started. You can click on this action
to display action log.
• Always On Mitigation Stop - Always On Mitigation was stopped. You can click on this action
to display action log.
• Mitigation Start Failed - Mitigation start was not successful. You can click on this action
to display action log. In action log, you can click on Retry or Revert button. You can use
Retry button in case the error was fixed, or Revert button for removing configuration that was
applied before failure. Retry button is available only for non-Ended attacks.
• Mitigation Stop Failed - Mitigation stop was not successful. You can click on this action to
display action log. In action log, you can click on Retry or Revert button. You can use Retry
button to try again to stop the mitigation, or Revert button for re-applying everything what
was removed so far and starting mitigation again. Revert button is available only for non-
Ended attacks.
• Mitigation Start (reverted) - Mitigation Start Failed action will turn into this action in case of
successful Revert action.
• Mitigation Stop (reverted) - Mitigation Stop Failed action will turn into this action in case of
successful Revert action.
3.2.3 Tools Column
In the last column Tools, control buttons are available. The list of available buttons follows:
• Detail - display details of detected attack (see below), including basic information, active traf-
fic graph with highlighted attack, traffic statistics table with baseline values and attack traffic
values and list of advanced attack statistics computed from primary flow data.
• Analyze - forward to Flowmon Monitoring Center to analyze attack traffic
• PDF report - generate PDF report for this attack
• Mitigate - this button starts mitigation action.
• Stop mitigation - this button stops mitigation action.
• Disable - this button disables the attack and turns it into Ended status.
• Delete - this button deletes an attack.
The above buttons are available for attack under the following conditions:
Button Attack status Always on rule Router or ScrubC Automatic/Manual Mitigation in Notes
assigned trigger progress
Detail always available
Analyze always available
PDF report always available
Mitigate Active, Not active no yes Manual No Available for Automatic mode and
Always on rule in case of mitiga-
tion start failure
Stop mitigation Active, Not active no yes Both Yes
Disable Active, Not active no don’t care Both No
Delete Ended don’t care don’t care Both No
Table 1: Availability of buttons in specific states
3.2.4 Attack Detail Page
Attack detail page comprises of three tabs: Overview, Action status and Details.
In Overview tab, the basic info about the attack is present: Start time, End time, Attack status,
Attack target (segment name) and Detection method. Below this info a graph of attack traffic with
thresholds is displayed. Content of the graph can be switched below, where you can choose one
of the detection methods: Adaptive threshold, Manual threshold, Incoming/Outgoing ratio and
Minimal traffic. Detection methods which resulted into triggering this attack are highlighted with
exclamation mark icon next to them.
Clicking on Adaptive threshold method will reveal a sub-menu of traffic subsets which are being
used for baselines computation and attack monitoring. Traffic subsets which triggered the attack
are highlighted with exclamation mark icon next to them.
In the graph, the current attack is highlighted with dark red color. Another attacks are high-
lighted with light red color. In the graph legend below, the particular graph lines or columns can be
hidden/displayed by clicking on checkboxes.
In the bottom of the form, a set of buttons is available. In this set you can find same buttons
Figure 19: Attack detail form
as in the Tools column together with a Mark/Unmark false positive button. False positive attack
is considered as a legitimate traffic, thus it influeces the protected segment baselines. If you mark
the attack as a false positive, from the baseline perspective it is the same situation as if the attack
was deleted.
In Action status tab, the history of all actions is displayed including timestamps. Details about
each action can be shown by hovering mouse over info icon, action log can be displayed by clickin
on action itself (not available for all actions).
In Details tab, the detailed analyzis of attack data can be done. There are multiple statistics
available generated from primary flow data stored by Flowmon Monitoring Center. By clicking on
statistic the data are displayed. If the data are requested for the first time, they must be computed.
This operation may take longer time. To speed this up, you configure important statistics to be
precomputed automatically upon attack detection. This configuration is available in Configuration
page.
4 BGP Injection
This chapter specifies a feature of the DDD module for route advertising by BGP injection (route
injection) in order to redirect traffic via Scrubbing Center (SC). In case of an attack detection a user is
alerted and he/she can analyze the attack details and possibly trigger the DDD module to configure
the network and/or SC for attack mitigation. The mitigation can be triggered also automatically
just upon the attack detection with no user interaction. The DDD module can be integrated with
Defense Pro boxes (connected out of band as SCs) via Vision server and configure them for the
purpose of attack mitigation. REST API is used for DDD – Vision communication.
In order to redirect attack traffic via SC using BGP, the DDD was extended with a Linux BGP
router performing route advertising by BGP routing protocol to any router supporting BGP. This
approach is well suited for large scale networks. In smaller networks, malicious traffic can be redi-
rected using ACLs. List of advertised routes (LAR) is generated by the DDD module and it contains
subnets to be redirected.
The list of such subnets is created based on user requests:
• User request for mitigation start for specific attack - user will define a list of subnets to be
redirected. These subnets will be added to LAR. The subnets provided by user must comply
the longest prefix match in order to replace current routes on the router.
• User request for mitigation stop for specific attack - the system will check whether subnets in
this attack are unique. If the same subnet is not found in any other attack currently mitigated,
it is removed from LAR.
To perform traffic redirection by BGP injection for a protected segment, following configuration
must be provided:
• DDoS Defender AS. Use the same AS number as for the router AS to run Linux BGP router in
iBGP mode or different AS for eBGP mode.
• At least one BGP capable router must be assigned to the protected segment.
• The BGP capable router will be configured in the DDD module with following items:
– Router name
– IP address
– Community numbers list

– Router AS
If internal BPG (iBGP) mode is used for routes injection, it is possible to set specific next-hop
IP address of all injected routes in the DDD module’s gui. But routes injected using eBGP contain
next-hop IP address of the machine running the DDD module. Specifically, it is the IP address of
the interface from which the routing updates are sent. Appropriate next-hop IP address to redirect
traffic via SC must be set on the router. This is caused by the fact that eBGP can use only directly
connected networks as a next-hop IP address. Configuration examples are provided in following
sections.
4.1 Router configuration

Route advertising by BGP injection requires adding a BGP capable router to the DDD module.
You can add a new router in the configuration section of the DDD module in the routers table.
Clicking the Add new router... button will display a new form, where you must provide all neces-
sary parameters for the BGP injection process. First you must enter a Router name and IP address
of the router. Then choose the BGP redirection method and as a BGP injector choose the DDoS
Defender. Next you can provide a list of community numbers which are separated by a semicolon.
You can use these to filter routing updates on the router to stop them from reaching the VRF table.
Also you have to select a BGP mode - iBGP or eBGP. The rest of the configuration depends on the
selected mode:
• iBGP
– AS: Autonomous system of both BGP capable router and the DDD module.
– Next-hop IP: Next-hop IP address for injected routes used for redirecting traffic through
SC.
• eBGP
– Router AS: Autonomous system of the BGP capable router.

– DDoS Defender AS: Autonomous system of the machine running the DDD module.
You can also test the BGP connection between the DDD module and BGP router by clicking the
Test button. This will show you state of the connection and possible errors if there are any. This is
very useful for debugging configuration or connection errors.
Figure 20: Create BGP router form
If you have at least one BGP capable router added, you can assign this router to a protected
segment. After an attack is detected on this segment and you choose to start the mitigation and all
subnets from this segment will be injected to the BGP router’s routing table.
4.2 Network scenarios

In this section we will discuss several connection scenarios and the necessary configuration that
must be done on routers in order to provide traffic redirection for the DDD module. Configuration
examples will be also provided. These scenarios use Radware Defense Pro scrubbing centers to
clean malicious traffic.
4.2.1 Scenario 1: Defense Pro in IP Mode (single router)
In this scenario, the Defense Pro (DP) is connected in IP mode (DP ports have IP addresses) with
two interfaces on a router. Redirected traffic first goes through the source interface (Gi0/0) of the
router. Then it is cleaned by DP and finally it arrives back at the router on the destination interface
(Gi0/1).
Figure 21: Topology of scenario 1
Steps:
1. Router is configured as a BGP neighbor for the DDD module and in case of attack mitigation,
the DDD module advertises user-defined routes.
2. All routes advertised by the DDD module must be set with a next-hop IP address to redirect
traffic via DP. Next-hop IP is a loopback interface of the Defense Pro scrubbing center. This
can be done using a route-map (eBGP) or directly in the gui of the DDD module (iBGP).
3. The next step is creating a virtual routing table (VRF) to ensure that cleaned traffic is not routed
using injected routes and it is correctly re-injected to the network. This table will contain all
routes from the global routing table except those injected by the DDD module.
4. Set redistribution of all routes from the global routing table into the BGP process on the
router. Routes from this BGP process will then be leaked to the VRF table.
5. Leak redistributed routes from the BGP process to the VRF table, but filter all routes injected
by the DDD module. This can be done using a community list inside a route-map. This com-
munity list will deny specific community numbers which are set in the DDD module. Commu-
nity list requires decimal number which is a combination of the DDD module’s AS number and
community number. This number can be calculated using following example: 25511 = AS, 444
= community
25511dec = 63A7hex , 444dec = 1BChex − > 63A701BChex = 1671889340dec (1)
6. Use route-map with a community list to filter routes injected from the DDD between global
and VRF routing table.
7. Assign the VRF table to the destination interface (Gi0/1) of the router. This will remove IP
address of the interface and it must be set again.
8. Configure Defense Pro to use GRE tunnel to re-inject the cleaned traffic back into the network
via destination interface (Gi0/1) of the router.
Cisco configuration example:
Router Gi0/0:
IP = 1.100.1.1/30
Router Gi0/1:
IP = 1.100.2.1/30
Defense Pro Lo0:

IP = 1.100.3.1/30
# Set bgp neighbor and next-hop IP address

router bgp 25512
neighbor 192.168.1.1 remote-as 25511
# eBGP specific settings !!!
neighbor 192.168.1.1 route-map BGP_SET_NEXT_HOP in
# Route-map specifying the next-hop IP address

route-map BGP_SET_NEXT_HOP permit 10
set ip next-hop 1.100.3.1
# Create community list to match community numbers specified in the DDD module
# AS = 25511, community = 444

ip community-list 100 deny 1671889340
ip community-list 100 permit .*
# Create route-map and apply the community list

route-map FILTER_DDD permit 10
match community 100
# Create VRF routing table

ip vrf DDOS
rd 100:10
route-target import 100:10
import ipv4 unicast map FILTER_DDD
# Redistribute routes from global routing table to the BGP process.

# If you use other routing protocols such as OSPF, you have set the redistribution too.
router bgp 25512
address-family ipv4
redistribute static
redistribute connected
......
# Set VRF table on the destination interface

inter Gi0/1
ip vrf forwarding DDOS
4.2.2 Scenario 2: Defense Pro in IP Mode (two routers)
In this scenario, the Defense Pro (DP) is connected in IP mode (DP ports have IP addresses)
between two different routers (source and destination router). Redirected traffic first goes through
interface Gi0/0 of the source router. Then it is cleaned by DP and finally it is sent to the interface
Gi0/1 of the destination router using GRE tunnel.
Steps:
1. Source router is configured as a BGP neighbor for the DDD module and in case of attack
mitigation, the DDD module advertises user-defined routes.
traffic via DP. Next-hop IP is a loopback interface of the Defense Pro scrubbing center (Lo0).
This can be done using a route-map (eBGP) or directly in the gui of the DDD module (iBGP).
3. Configure Defense Pro to use GRE tunnel to re-inject the cleaned traffic back into the network
via interface Gi0/1 of the destination router.
Source router Gi0/0:

IP = 1.100.1.1/30
Destination router Gi0/1:

IP = 1.100.2.1/30
Defense Pro Lo0:

IP = 1.100.3.1/30

router bgp 25512

4.2.3 Scenario 3: Defense Pro in transparent mode (single router)
In this scenario, the Defense Pro (DP) is connected in transparent mode (DP ports behave like
a wire). Redirected traffic first goes through source interface (Gi0/0) of the router. Then it is cleaned
by DP and finally it arrives back at the router on the destination interface (Gi0/1).
Steps:
1. Router is configured as a BGP neighbor for the DDD module and in case of attack mitigation,
the DDD module advertises user-defined routes.
traffic via DP. Next-hop IP must be any non-existing IP in the same network subnet as the
source interface (Gi0/0) of the router. This can be done using a route-map (eBGP) or directly
in the gui of the DDD module (iBGP).
3. Create a static ARP which will map the MAC address of the destination interface (Gi0/1) of the
router to the next-hop IP. Another static ARP for the opposite direction is neccessary. This will
ensure that the cleaned traffic is re-injected back into the network.
4. The next step is creating a virtual routing table (VRF) to ensure that cleaned traffic is not routed
using injected routes, but it is re-injected to the network. This table will contain all routes from
the global routing table except those injected by the DDD module.
5. Set redistribution of all routes from the global routing table into the BGP process on the
router. Routes from this BGP process will then be leaked to the VRF table.
6. Leak redistributed routes from the BGP process to the VRF table, but filter all routes injected
by the DDD module. This can be done using a community list inside a route-map. This com-
munity list will deny specific community numbers which are set in the DDD module. Commu-
nity list requires decimal number which is a combination of the DDD module’s AS number and
community number. This number can be calculated using following example: 25511 = AS, 444
= community
25511dec = 63A7hex , 444dec = 1BChex − > 63A701BChex = 1671889340dec (2)
7. Use route-map with a community list to filter routes injected from the DDD between global
and VRF routing table.
8. Assign the VRF table to the destination interface (Gi0/1) of the router. This will remove IP
address of the interface and it must be set again.
Router Gi0/0:
IP = 1.100.1.1/30
MAC = 0000.0000.0301
Router Gi0/1:
IP = 1.100.2.1/30
MAC = 0000.0000.0401

router bgp 25512

# Set static ARPs

arp 1.100.1.2 0000.0000.0401 ARPA
arp 1.100.2.2 0000.0000.0301 ARPA
# Create community list to match community numbers specified in the DDD module
# AS = 25511, community = 444
ip community-list 100 deny 1671889340
ip community-list 100 permit .*
# Create route-map and apply the community list

route-map FILTER_DDD permit 10
match community 100
# Create VRF routing table

ip vrf DDOS
rd 100:10
route-target import 100:10
import ipv4 unicast map FILTER_DDD
# Redistribute routes from global routing table to the BGP process.

# If you use other routing protocols such as OSPF, you have set the redistribution too.
router bgp 25512
address-family ipv4
redistribute static
redistribute connected
......
# Set VRF table on the destination interface

inter Gi0/1
ip vrf forwarding DDOS
4.2.4 Scenario 4: Defense Pro in transparent mode (two routers)
In this scenario, the Defense Pro (DP) is connected in transparent mode (DP ports behave like
a wire) between two different routers (source and destination router). Redirected traffic first goes
through interface Gi0/0 of the source router. Then it is cleaned by DP and finally it arrives on the
interface Gi0/1 of the destination router.
Steps:
1. Source router is configured as a BGP neighbor for the DDD module and in case of attack
mitigation, the DDD module advertises user-defined routes.
traffic via DP. Next-hop IP must be any non-existing IP in the same network subnet as the
interface Gi0/0 of the source router. This can be done using a route-map (eBGP) or directly in
the gui of the DDD module (iBGP).
3. Create a static ARP on the source router which will map the MAC address of the interface
(Gi0/1) of the destination router to the next-hop IP. Another static ARP for the opposite direc-
tion is neccessary. This will ensure that the cleaned traffic is re-injected back into the network.
Source router Gi0/0:

IP = 1.100.1.1/30
MAC = 0000.0000.0301
Destination router Gi0/1:

IP = 1.100.2.1/30
MAC = 0000.0000.0401

router bgp 25512

# Set static ARPs

arp 1.100.1.2 0000.0000.0401 ARPA
arp 1.100.2.2 0000.0000.0301 ARPA
5 BGP Flowspec Injection

This chapter specifies a feature of the DDD module for attack characteristics advertising us-
ing a Flow Specification rules (Flowspec) of a Border Gateway Protocol Network Layer Reachability
Information (BGP NLRI) in order to mitigate or ratelimit the attack on the router with Flowspec
capability (please see RFC 5575 for more information). In case of an attack detection a user is
alerted and he/she can analyze the attack details and possibly trigger the DDD module to provide
a Flowspec rule to a router. The mitigation can be triggered also automatically just upon the attack
detection with no user interaction.
To perform Flowspec injection, the BGP communication between DDD and Flowspec router
must be configured and working according to the section 4.
The Flowspec rules for injection are created based on attack statistics from the first 30s of attack.
The rules can be created for following items:
• destination network
• source network
• destination port
• source port
• L4 protocol
When starting manual mitigation, user can revise and modify the Flowspec rules prepared by
DDD before they are sent to the router. He/she can also modify the Flowspec action for each of the
rules. The action can be one of the following:
• accept
• discard
• rate-limit
• redirect
• redirect-next-hop
• copy
• mark
5.1 Router configuration

In order to make the Flowspec injection work properly, the router must be able to support this
standard and the flowspec must be enabled. We also recommend to turn of flowspec validation.
Below, you can find an example of enabling the Flowspec on Cisco ASR router.
route-policy PASS
pass
end-policy
router bgp 100

bgp router-id 81.19.34.68
address-family ipv4 flowspec
!
neighbor 192.168.20.2
remote-as 300
!
address-family ipv4 flowspec
route-policy PASS in
route-policy PASS out
validation disable
!
!
Contacts
Flowmon Networks a.s.

U Vodarny 2965/2
Brno 61600
Web: www.flowmon.com
Email:[email protected]
Tel.: +420 511 205 251
Feedback
We would be pleased if you tell us your comments to this text (typing errors, incomplete or unclear
information). Please, contact us via email [email protected].
Copyright
Except as stated herein, none of the document may be copied, reproduced, distributed, republished, downloaded, dis-
played, posted, or transmitted in any form or by any means including, but not limited to, electronic, mechanical, pho-
tocopying, recording, or otherwise, without the prior written consent of Flowmon Networks. Any unauthorized use of
this specification may violate copyright laws, trademark laws, the laws of privacy and publicity, and communications
regulations and statutes.
Flowmon Networks, the company logo, and other designated brands included herein are trademarks of Flowmon Net-
works a.s. All other trademarks are the property of their respective owners.
This product uses NfSen and NFDUMP software Copyright (c) 2004, SWITCH - Teleinformatikdienste fuer Lehre und
Forschung.
This product uses compress library zlib Copyright (C) 1995-1998 Jean-loup Gailly and Mark Adler.
This product uses library libpcap Copyright (c) 1993, 1994, 1995, 1996, 1997, 1998 The Regents of the University of California
and Copyright (c) 1999 - 2003 NetGroup, Politecnico di Torino (Italy).
This product includes sFlow(TM), freely available from http://www.inmon.com/.
Copyright (c) 2007 - 2016 Flowmon Networks a.s. All rights reserved.

Flowmon DDos Defender - Userguide - en

Uploaded by

Copyright:

Available Formats

Flowmon DDos Defender - Userguide - en

Uploaded by

Document Information

Original Title

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

Flowmon DDos Defender - Userguide - en

Uploaded by

Copyright:

Available Formats

Flowmon DDoS Defender 3.00.

3 User Interface Description 8

5 BGP Flowspec Injection 45

1.1 Universal Deployment

Figure 1: Deployment scenarios

1.2 Features and Benefits

• Signiﬁcant attack response time acceleration

• Dynamic baselining of traﬃc volumes and characteristics

• Acquisition and presentation of the attacks’ characteristics

• Notiﬁcations via e-mail, syslog, SNMP trap

• Advanced options of immediate reaction

• Independent conﬁgurations for different customers, services, network segments, etc.

• Plug-in for Flowmon solution, simple installation and quick time-to-value

The DDD module can be deployed in three scenarios:

2.1 Attack Detection

Two main methods are used for attack detection:

2.2 Response to Attack

2.3 Attack Visualization

3 User Interface Description

In Subnets window, provide list of subnets in the following format:

Subnet list in segment conﬁguration

• Subnets - Subnets conﬁgured in Subnets window will be used for mitigation.

Figure 3: Segments conﬁguration panel

Figure 4: Create segment form

See section 2.1 for more information.

Figure 5: Rules conﬁguration panel

Figure 6: Create rule form

Following variables are present and set on every type of event.

• SEGMENT - Full human readable name of the segment.

• ATTACKCLASS - Triggered level of the attack (attack, suspect).

• EVENT - Which event was triggered (detected, statistics, ended).

– detected - This event is triggered after given attack is detected.

• SUBNETS_ARRAY - Array of subnetworks deﬁned in given segment.

– Example: (’192.168.3.0/24’ ’192.168.1.0/30’)

• ATTACKID - internal ID of the attack (unique numerical value)

• ATTACKTYPE_ARRAY - An array of triggered methods for given attack.

– Structure of array: detection_method:traﬃc_type[:suspect].

• IAD_VARIABLES_ARRAY - An array of variable names exported to the script.

Note: Variables of type array have the suﬃx ’_ARRAY’.

• STAT_DSTIP_ - Destination IP addresses with most incoming packets.

• STAT_PROTO_ - Present L4 protocols ordered by transferred packets.

• STAT_FLAGS_ - Most common TCP ﬂags.

• STAT_SRCAS_ - Destination AS ordered by transferred packets.

• STAT_SRCIFC_ - FMC Source ordered by incoming packets.

• STAT_DSTPORT_ - Destination port/L4 Protocol ordered by transferred packets.

• STAT_SRCNET16_ - Source /16 subnet ordered by transferred packets.

• STAT_SRCNET8_ - Source /8 subnet ordered by transferred packets.

An example script follows.

# --- MANDATORY PART ---

echo "\${IAD_VARIABLES_ARRAY[@]}" # print list of valid variables

• %SEGMENT - name of segment in which the event was triggered

• %TIME - date and time of event

• %DEVICE - name of device

• %LINK - URL link to attacks page

• %MITIGATION_TYPE - mitigation conﬁguration (e.g. Manual Mitigation is set up ...)

• %MITIGATION_STATUS - current mitigation status (e.g. Mitigation is not running ...)

• %SUBNETS - list of subnets deﬁned for segment

• %METHODS - list of triggered detection methods

Figure 7: Email template conﬁguration panel