DDoS Secure Portal Configuration

The following parameters should be set on the DDoS Secure appliance soon after
the first power-up. These parameters are used by the appliance algorithm to tune
responses to attacks. The defaults shown will be used if no user-defined values are
supplied.
Click Configure Portals to configure the DDoS Secure appliance Parameters.
Figure 30 displays the DDoS Secure portal configuration page.

Figure: DDoS Secure Portal Configuration Page.

This screen is broken into four parts.

First PartDescribes all the different portals configured on the DDoS Secure
appliance.
Second PartDescribes the Filters in use in a portal.
Third PartDescribes the Filter Aggregations in use in a portal and the final
part describes the protected IPs that are in use in a portal.
Fourth PartDescribes the Protected IPs that are in use in a portal

It is possible to allocate (not necessarily contiguous) blocks of addresses (networks

and or single IP addresses) to what are known as portals, which can, if required, be
managed separately by designated users. This gives the ability for Customers,
Clients or Business Units to be able to manage what DDoS Secure appliance does
for their portal. Any user that has full managerial access can override these portal
configurations. The master portal is known as webscreen.
The master portal defines what the DDoS Secure appliance is to protect, and then
all the other portals have a subset of (but cannot overlap with other portals) this
master portal capability.

DDoS Secure Portal Configuration

The following parameters should be set on the DDoS Secure appliance soon after
the first power-up. These parameters are used by the appliance algorithm to tune
responses to attacks. The defaults shown will be used if no user-defined values are
supplied.
Click Configure Portals to configure the DDoS Secure appliance Parameters. Figure
30 displays the DDoS Secure portal configuration page.
Figure 30: DDoS Secure Portal Configuration Page.

This screen is broken into four parts.

First PartDescribes all the different portals configured on the DDoS Secure
appliance.

Second PartDescribes the Filters in use in a portal.

Third PartDescribes the Filter Aggregations in use in a portal and the final
part
describes the Protected IPs that are in use in a portal.

Fourth PartDescribes the Protected IPs that are in use in a portal

It is possible to allocate (not necessarily contiguous) blocks of addresses (networks

and or single IP addresses) to what are known as portals, which can, if required, be
managed separately by designated users. This gives the ability for Customers,
Clients or Business Units to be able to manage what DDoS Secure appliance does
for their portal. Any user that has full managerial access can override these portal
configurations. The master
portal is known as webscreen.
The master portal defines what the DDoS Secure appliance is to protect, and then
all the
other portals have a subset of (but cannot overlap with other portals) this master
portal
capability.

Table below provides a summary of configure portal details displayed on the DDoS
Secure Portal Configuration page:

Configure Portal Details

FIELD DETAILS

Configure Portals

Expand
When multiple portals are configured, expand the appropriate
portal by clicking on
the + in the Expand column to display the different portal sets of filter / filter
aggregation / protected IP.
Name This is the name of the portal.
Type This portal can be a list of IP addresses, or associated with a particular
VLAN/MPLS definition.
Address(es) It is possible to specify here all the valid protected IP addresses
that your DDoS Secure appliance is protecting for a portal. For the master
portal (webscreen), this defines all the valid addresses that the DDoS Secure
appliance is protecting

any other portal will be a subset of the webscreen portal. Any inbound traffic will
have to match a portal IP address (or be going to a multicast address or a
broadcast address) to be allowed through. Any outbound traffic will have to come
from a valid portal IP address. It is therefore possible to do simple ingress and
egress filtering by specifying a restricted network here. It is valid to specify an
address group that encompasses, for example, the default gateway IP that is on the
Internet side of DDoS Secure appliance.
IP addresses can be specified as

AllAll IP addresses are valid (includes IPv6). all-ipv4All IPv4

addresses.
aaa.bbb.ccc.ddd/maskTo specify a group of IPv4 addresses using a subnet
mask.
aaa.bbb.ccc.ddd/countTo specify a group of IPv4 addresses using a subnet
mask length.
aaa.bbb.ccc.dddTo specify a specific IPv4 address.
aaa.bbb.ccc.ddd-eee.fff.ggg.hhhTo specify a range of IPv4 addresses.
xxxx::xxxx:xxxx/countTo specify a group of IPv6 addresses using a subnet
mask length.
xxxx::xxxx:xxxxTo specify an IPv6 address.
xxxx::xxxx:xxxx-yyyy:yyyy::yyyyTo specify a range of IPv6 addresses. All
addresses can be "," (comma) separated. Thus 11.22.33.44,44.33.22.11
would specify the two protected IPs 11.22.33.44 and 44.33.22.11. There can
be a maximum of 30 different entries.

Note: You may need to define an IP address of 0.0.0.0/32 to allow DHCP requests to
pass through the DDoS Secure appliance.

If the portal has been defined at type VLAN, then a, potentially comma separated,
set of VLAN/MPLS definitions need to be defined. These are prefixed as appropriate
with the following letters.
vVLAN
mMPLS label (Only the outermost VLAN / MPLS label is selected. )
Operation
It is possible for portals to be operating in a different operational mode
than defined for the appliance.
Here, it is possible to select either defending, or logging. If the appliance
operational mode is set to anything other than defending, then the portal mode will
be the same as the operational mode.
Countries
It is possible to specify which countries match, and hence are allowed
to use this portal.
The countries are determined from the ip to country tables provided by MaxMind
(and potentially modified by the geoip command), and so are not guaranteed to be
100% accurate. The 3 letter country ids are required, separated by commas (no
spaces) if multiple countries are to be specified. A full list of these country codes
can be found in, or as observed from the output information of various statistical
outputs. If many countries are to be allowed, the pseudo all can be used, followed
by (!) and the 3 letter country code. Thus all,!GBR means that all traffic, apart from
that coming from GBR is matched. The country match always applies to the Client
Internet address, not a protected IP address.

AS#s It is possible to allow traffic to / from a set of IP addresses or networks on a

permanent basis, based on the Autonomous System (AS) number as used by BGP
routing for the Internet. The AS number information is provided is not 100%
accurate. Specify AS numbers or AS ranges, separated by commas (no spaces) if
multiple AS blocks are required. By default, all AS numbers are allowed. The
maximum AS# that can be specified is 65535.

Speed (bps) This is the minimum guaranteed speed (bandwidth) that the portal has
available for use.
If the value is set to U or 0, then there is no guaranteed minimum speed available.
The sum of all the individual portals cannot exceed that of the master portal.
Burst Speed This is the speed that the portal can use if the bandwidth is not being
used elsewhere. Bandwidth will be rate limited for any speeds over the guaranteed
speed based on Charm

ReRoute Under The packet rate under which the DDoS Secure appliance will drop
the insertedroute after defined period (default is 5 minutes). This is
only applicable if BGP ReRouting has been enabled which is done via
the CLI.
ReRoute OverThe packet rate over which the DDoS Secure appliance will insert a
route into BGP. This is only applicable if BGP Re-Routing has been
enabled which is done via the CLI.
Rate (pps) This is the minimum guaranteed packet rate that the portal has
available for use.
If the value is set to U or 0, then there is no guaranteed minimum rate available.
The sum of all the individual portals cannot exceed that of the master portal.
Burst Rate

This is the packet rate that the portal can use if the packet rate is not
being used elsewhere.

Packet rates will be rate limited at this value based on Charm. It is usual to keep
this value the same as the Rate (pps) value if the Burst Speed is not more than
double the Speed (bps).
Suggested Rate
The recommended default is normally one quarter of the
theoretically maximum number of small packets that can fit into the
speed of the portal.
With lower bandwidth (bandwidth less than 8Mb/s) the recommended value will be
higher than one quarter of the theoretical maximum, and on higher speed links, this
may be less than one quarter.

ReRoute Under

The rate under which the DDoS Secure appliance will drop the inserted route after

defined period (default is 5 minutes). This is only applicable if BGP Re-Routing has been enabled which is
done via the CLI.
ReRoute Over

The rate over which the DDoS Secure appliance will insert a route into BGP. This

is only applicable if BGP Re-Routing has been enabled which is done via the CLI.
Filters The number of available filters is a limited resource. Here, you can define how
many filters a particular portal is allowed to use. The default value is the number of filters divided by the
number of portals. For the master portal, the number
displayed is the remaining number of filters available for allocation.
Protected IPsThe number of available protected IPs is a limited resource. Here, you can define
how many protected IPs a particular portal is allowed to use. The default value is
the number of protected IPs divided by the number of portals. For the master
portal, the number displayed is the remaining number of protected IPs available for
allocation.
(Addresses) The number of defined IP addresses in the portal.

(Used)

The number of IP addresses in use in the portal.

Existing Portals
This section contains all the configured portals, including the DDoS Secure portal. It is possible to remove a
portal by checking the Remove check box (the portal must not be expanded). It is not possible to delete the
webscreen portal.

Bandwidth and Port Filters

Bandwidth and Port filters are defined for inbound and outbound traffic. Any new traffic that
matches a specific filter will have session state tracking enabled for that traffic. Any
subsequent traffic matching (taking into account direction) a tracked session will also be
allowed based on the filter. Thus for an inbound connection, an inbound filter that allows
http traffic only (port 80/tcp) and an outbound filter that lets through no traffic, is sufficient to
allow a full http connection to take place.
Any traffic associated with a filter will be rate limited (based on Charm) if it exceeds the defined bandwidth
thresholds - which is separately applied to both directions. If multiple protected IPs use the same filter, then

the threshold is an aggregate for all the protected IPs. If the protected IPs each use a different filter with the
same characteristics, then the threshold will be on a per protected IP basis.
Each protected IP must have one inbound filter and one outbound filter configured to control access to and
from the protected IP.
There is a non-configurable filter default, which allows most traffic through with a restriction on valid icmp
types and udp port 80. This is the initial default protected IP filter for both inbound and outbound.
In addition to the non-configurable default filter, there are three predefined configurable
filters. The multicast filter is preset to allow traffic (no tcp and restriction on icmp types)
through and is the default filter for the Global Protected IP Multicast. The broadcast filter is
preset to block all TCP ports, UDP port 7 and all ICMP types, and is the default filter for the

Global Protected IP Broadcast. The intercept filter is initially set to only allow TCP, and this is used in
conjunction with the CLI set wrapper blocked command.
Table below provides a summary of the bandwidth and port filters displayed on the DDoS Secure Portal
Configuration page:

Table 10: Configure Bandwidth and Port Filters Details

FIELD DETAILS
Name This is the name of the filter.

TCP Ports

The default value of all allows through all TCP ports. If only a subset of ports such as 80

and 443 are required, it is suggested that only these are enabled. DDoS Secure appliance
will always drop all packets with port numbers not matching the values entered here. Ports
are specified as either an individual port 80, as a range of ports 80-81, a comma separated
list of ports 80,443, or as a combination 80-81,443. The keyword none is also supported.
Any connection that matches the filter is always allowed, as are any response packets
(including an ICMP diagnostic response) as state is maintained on the connections
session.
Note: FTP (port 21) is a special case - data connections are handled automatically, so
data ports do not need to be defined, only the control port (21), unless FTPS is being used, in which case the
data ports will have to be configured as well as the control port traffic is encrypted which the DDoS Secure
appliance logic cannot interpret.

HTTP Ports

These are the TCP ports that the DDoS Secure appliance will inspect for HTTP traffic.

These ports must also be defined under TCP Ports to be actioned.

UDP Ports

The default value of all allows through all UDP ports. If only a subset of ports such as 53

(DNS) is necessary for the correct operation of the protected IPs, it is suggested that only
these are enabled. DDoS Secure appliance will always drop all packets with port numbers
not matching the values entered here. Ports are specified as either an individual port 53, a
range of ports 53-54, a comma separated list of ports 53,100, or as a combination 5354,100. The keyword none is also supported. Any UDP request that matches the filter is
always allowed the response packets (including an ICMP diagnostic response) as state is
maintained on the connection. However, this state expires after 30 seconds of inactivity, so

if you have a UDP protocol that can be started from either end (such as port 500 for IPSEC
IKE traffic), you will need to specify the UDP port as being valid in both the inbound and
outbound filter of the protected IP definition.

ICMP Types ICMPv4 types necessary (in addition to valid state matching diagnostic responses) for the
correct operation of all protected IPs being defended should be listed here. The appliance
will deny all other ICMP types whether the protected IPs are under attack or not. Types are
specified as either an individual type 8, as a range of types 3-4, as a comma separated list
of types 3,8, or as a combination 3-4,8. The keyword none is also supported. A full list of
types for ICMP is given in ICMP diagnostic responses that match a valid state for an
existing session are always let through. This includes, for example, ping responses to ping
requests. Currently, the highest RFC ICMPv4 defined type is 18, so the keyword all refers
to types 0 through 18. If other ICMP types are required, they will need to be separately
added in (e.g 0-18,21).

ICMPv6 Types

ICMPv6 types necessary (in addition to valid state matching diagnostic responses) for the

correct operation of all protected IPs being defended should be listed here. The appliance
will deny all other ICMP types whether the protected IPs are under attack or not. Types are
specified as either an individual type 8, as a range of types 3-4, as a comma separated list
of types 3,8, or as a combination 3-4,8. The keyword none is also supported. ICMP
diagnostic responses that match a valid state for an existing session are always let
through. This includes, for example, ping responses to ping requests. Currently, ICMPv6
uses 0 through 4, and 128 to 154, so the keyword all refers to types 0 through 4, and 128
through 154 inclusive. If other ICMP types are required, they will need to be separately
added in (e.g 0-4,128-154,156).

IP protocols IP protocols (other than TCP, UDP, ICMPv4 and ICMPv6) necessary for the correct
operation of all protected IPs being defended should be listed here. Examples could be
IPSEC (protocols 50 and or 51) or GRE (protocol 47). The appliance will deny all other IP
protocols whether the protected IPs are under attack or not. Protocols are specified as
either an individual protocol 47, as a range of protocols 50-51, as a comma separated list
of protocols 47,50, or as a combination 47,50-51. The keyword none is also supported.
Any IP request that matches the filter is always allowed the response packets (including an
ICMP diagnostic response) as state is maintained for the session. However, this state
expires after 30 seconds of inactivity, so you will need to specify the IP protocol as being
valid in both the inbound and outbound filter of the protected IP definition.

Countries

It is possible to specify which countries match, and hence are allowed to use this filter. The

countries are determined from the IP to country tables provided and potentially modified by the CLI geoip
command), and so are not guaranteed to be 100% accurate. The 3 letter country ids are required, separated
by commas (no spaces) if multiple countries are to be specified. A full list of these country codes can be
found in, or as observed from the output information of various statistical outputs. If many countries are to be
allowed, the pseudo all can be used, followed by ! and the 3 letter country code. Thus all,GBR means that
all traffic, apart from that coming from GBR is matched. The country match always applies to the Clients
Internet address, not a protected IP address.

Networks

It is possible to specify which networks match, and hence are allowed to use this filter. The

network match always applies to the Clients Internet address, not a protected IP address.
Thus it is possible to specify, say, that only certain IP addresses are able to access port 22
on a protected IP. It should be noted that if port 22 is allowed in another filter match as part

of a Filter Aggregation definition, then port 22 may not be blocked as expected. The
network match always applies to the Clients Internet address, not a protected IP address.

AS#s It is possible to specify which networks matched, based on the Autonomous System (AS)
number as used by BGP routing for the Internet. The AS number information is provided by MaxMind and is
not 100% accurate. Specify AS numbers or AS ranges, separated by commas (no spaces) if multiple AS blocks
are required. By default, all AS numbers are allowed. The maximum AS# that can be specified is 65535.

Speed (bps) This is the minimum guaranteed speed (bandwidth) that the Filter has available for use. If
the value is set to U or 0, then there is no guaranteed minimum speed available. The sum
of all the individual Filters cannot exceed that of the portal unless the portal is unrestricted.

Burst Speed This is the speed that the Filter can use if the bandwidth is not being used elsewhere.
Bandwidth will be rate limited for any speeds over the guaranteed speed based on Charm.

Rate (pps)

This is the minimum guaranteed packet rate that the Filter has available for use. If the

value is set to U or 0, then there is no guaranteed minimum rate available. The sum of all
the individual Filters cannot exceed that of the portal unless the portal is unrestricted.

Burst Rate

This is the packet rate that the Filter can use if the packet rate is not being used elsewhere.

Packet rates will be rate limited at this value based on Charm. It is usual to keep this value
the same as the Rate value if the Burst Speed is not more than double the Speed (bps).

Suggested Rate
of

The recommended default is normally one quarter of the theoretically maximum number

small packets that can fit into the Speed of the Filter. With lower bandwidth (bandwidth
less than 8Mb/s) the recommended value will be higher than one quarter of the theoretical maximum, and on
higher speed links, this may be less than one quarter.

Configure Filter Aggregations

Multiple Filters may be required for a protected IP, each having its own bandwidth and port characteristics.
With Filter Aggregations, you can define a list of (up to seven) filters to search through looking for the first
match on the port and / or protocol, which is then used. It is possible for a Filter Aggregation to refer to
another, previously defined, Filter
Aggregation. Thus it is possible to build a base-line Filter Aggregation and create other special configurations
keyed off the base-line.
If a Filter Aggregation is used, and a particular port is not defined / matched in any of the seven sections, then
any traffic to that port will be dropped.
These Filter Aggregations do not appear on the Statistical Information pages and are an aid to configuring the
Protected IP Filter definitions.
Table below provides a summary of the configuration filter aggregation:

Table 11: Configure Filter Aggregations Details

FIELD DETAILS
Name This is the name of the Filter Aggregation. It is suggested that the Filter Aggregation Name

is easily differentiated from Filter Name for ease of configuration troubleshooting.

Filter [1 2 3 4 5 6 7]
(but

Select a Filter Name or a Filter Aggregation Name from the pull-down list. It is valid

unusual!) to have the -undefined- entry between genuine entries.

Configure Protected IPs

Any auto definitions below are automatically updated in the configuration file every midnight as they provide
a starting value hint to the DDoS Secure algorithms whenever the DDoS Secure engine is restarted. This is
only true for protected IPs that have been
defined, not just detected.

Table below provides a summary of the configuration filter aggregation:

Table : Configure Protected IPs

FIELD
Protected IP

TCP Backlog per port

Suggested TCP Backlog

DETAILS

current count increases towards the (potentially automatically determined)

hard limit.

The IP address of the IP being

protected.
The auto- logic only recalculates for ports or IP addresses that are known to be
Active - i.e. not filtered out by an internal firewall.

The maximum number of

connection attempts, per
port, that a protected IP can
hold in a partially opened
state. This is known as the
hard limit and a value of
1000 per protected IP is
usually acceptable but may
be lowered to around 50 for a
sensitive protected IP. If this
value is prefixed by auto-,
then the DDoS Secure
appliance engine will try to
automatically adjust this
value based on how the
protected IP is responding.
The default is auto-1000. A
value of 0 or U means that
there is no backlog checking.
The DDoS Secure appliance
Charm algorithm will reduce
the likelihood of a user
making a connection as the

The auto- logic may get confused if SYN Cookies are in use by the Protected IP,
as the Protected IP will always quickly respond to the SYN request. If this is the
case, then auto- may not be appropriate, and, depending on the power of the
Protected IP, would typically have a value of 1000 up to 5000.
If the Protected IP hard limit is unknown, and auto- is not appropriate, set this
hard limit value to the value reported under Suggested TCP Backlog for the
appropriate Protected IP, and then review the situation to see if this value
significantly changes. If Syn Floods are being reported, there are very few
connections in the SYN state and the Protected IP is not overloaded, this value
can be increased.
A protected default value of the IP for maximum TCP backlog queue per port
differs depending on its operating system. On Linux systems, for example, this
hard limit can be deter mined by issuing the command: sysctl
net.ipv4.tcp_max_syn_backlog\. On Microsoft Windows servers, this value is
stored in a variable (TcpMaxHalfOpen) in the registry entry:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameter
s].

The value that the DDoS Secure appliance engine believes is a better value to
use.
This value can be incorrectly calculated if the Protected IP is using SYN
Cookies.

Max Open Connections

Suggested Conn Rate

Suggested Connections

Max Conn Rate

reported under Suggested Connections for the appropriate Protected IP, and
then review the situation to see if this value significantly changes. If
Connection Floods are being reported, and the Protected IP (by checking the IP
itself) is not overloaded, this value can be increased.

The maximum number of

open connections (in an
active data transfer state)
that can be handled by the
Protected IP. This is known
as the hard limit and a value
of 1000 per protected IP (but
considerably higher for a
load-balancer) is usually
acceptable but may be
lowered to around 50 for a
sensitive protected IP. If this
value is prefixed by auto-,
then the DDoS Secure
appliance engine will try to
automatically adjust this
value based on how the
protected IP is responding.
The default is auto-1000. A
value of 0 or U means that
there is no connection
checking. The DDoS Secure
appliance Charm algorithm
will reduce the likelihood of a
user making a connection as
the current count increases
towards the
(automatically determined)
hard limit.
If the protected IP hard limit
is unknown, and auto- is not
appropriate, set this hard
limit value to the value

The DDoS Secure appliance engine believes is a better value to use.

The maximum number of new connections per second that can be handled by
the
Protected IP. This is known as the hard limit. This could be a limit imposed by
the
transaction rate of a backend database server. If this value is prefixed by
auto-,
then the DDoS Secure appliance engine will try to automatically adjust this
value
based on how the protected IP is responding. The default is auto-1000. A
value of
0 or U means that there is no connection rate checking. The DDoS Secure
appliance Charm algorithm will reduce the likelihood of a user making a
connection as the current count increases towards the hard limit.
For HTTP connections using HTTP/1.1, the second and subsequent GET /
HEAD / POST requests are also treated as a new connection request for
calculating rates, as well as an additional GET request.
If the protected IP hard limit is unknown, and auto- is not appropriate, set this
hard limit value to the value reported under Suggested Conn Rate for the
appropriate
Protected IP, and then review the situation to see if this value significantly
changes. If Connection Rate Floods, or GET Rate Floods are being reported,
and the
Protected IP is operating within limits, this value can be increased.
The value that the DDoS Secure appliance engine believes is a better value to
use. This value can be incorrectly affected by the protected IP silently dropping
TCP
connections.

Max Active GETs

The maximum number of concurrent HTTP page requests that a protected IP can

process. An example of this is the maximum number of ASP Threads that an IIS
Server can handle. The DDoS Secure appliance code tracks the GET / HEAD /
POST requests, incrementing a counter, and then decrementing this counter when
the HTTP response starts to come back. The default is auto-1000. A value of 0 or
U means that there is no concurrent GET checking.
If the protected IP hard limit is unknown, and auto- is not appropriate, set this hard limit value to the value
reported under Suggested GETs for the appropriate
Protected IP. If GET Floods are being reported, and the Protected IP is operating within limits, this value can
be increased.
Note: Do not set this to 0 or U if you want the DDoS Secure appliance to defend against URL attacks.

Suggested GETs

The value that the DDoS Secure appliance engine believes is a better value to use.

Inbound Filter

The filter will be applied to all sessions initiated to your protected IP (and response

packets). If this is a Filter Aggregation definition, then the first Filter match in the
aggregate list will be used. If there is no Filter match, then the packet will be
dropped.

Outbound Filter

The filter will be applied to all sessions initiated from your protected IP (and

response packets). If this is a Filter Aggregation definition, then the first Filter
match in the aggregate list will be used. If there is no Filter match, then the packet will be dropped.

Send TCP Rejects

If this box is selected, then TCP RST packets will be sent back to the originating

client if the port requested has not been permitted (there has been no Filter match). When under peak loads,
these are rate limited.

Track SOAP If this box is selected, then the HTTP Header data is scanned for SOAP Action
Headers. If one is found, then this Action is tagged onto the URL for URL tracking. There is a performance
overhead with this enabled, so it should only be used on SOAP enabled servers.

No Frags

If this box is selected, then no fragmented IP packets will be accepted.

Note: The DDoS Secure appliance will automatically temporarily enable No Fragmentation on a per protected
IP address basis if it determines that a fragmentation attack is under way.
Operation

It is possible for a Protected IP to be operating in a different operational mode than

defined for the portal or appliance. Here, it is possible to select defending, logging,
or not reported. Not reported means that no packets are dropped and no incidents
are created for this Protected IP. If the appliance or portal operational mode is set
to anything other than defending, then the Protected IP mode will be no better than
logging.
Hostname
values.

Can be used to define a name for a protected IP to aid identification when defining

The hint about the open ports on the protected IP in question. If a Filter or
Filter Aggregation restricts ports, then these ports will not appear in this list.
Also, if the protected IP is filtering out some IP addresses but not others, then
an open port may bounce in and out of Active Ports. These ports get reset
every configuration change, or at midnight.

Active Ports

The actual inbound allowed ports. Entries in red have additional Country /
Network / AS# restrictions.

Enabled Ports

Defined Protected IPs

Table below provides a summary of the defined protected IPs.

Table 1: Defined Protected IPs Details

FIELD DETAILS
Add Protected IP

Allows you to specify a protected IP that has not been previously configured or auto-

detected. You will need to ensure that the Add check box has been selected for a new item to be included.
Note: If the add entry is not available; this is because you have used up the protected IP allocation for this
portal.
Protected IP Defaults

If a protected IP is detected (assuming Auto Detect Protected IPs is enabled, but

has not been defined, then the new protected IP will be configured with the definition for protected IP defaults
acting as a template. Changes to the Protected IP Defaults will also change the configuration of Auto-detected
Protected IPs.
Note: If the auto-detected protected IP is part of a defined portal, then the autodetected protected IP will take on the characteristics of the portal Indeterminate
protected IP.

Global Protected IPs

It is possible to define default settings for five virtual protected IPs, distinct from

those defined under Protected IP Defaults.

portal Defense defines what the portal is capable of handling, and typically would be used if the portal were a
load balancer with various Virtual IP addresses, but has its own set of limitations.
Intercept default settings are used for traffic that has been intercepted to an internal
DDoS Secure appliance server to generate suitable denial response pages. These
interceptions are configured using the CLI set wrapper blocked command.
Multicast default settings are used for those backend devices responding to multicast addresses.
Broadcast default settings are used for those backend devices responding to broadcast addresses.
Indeterminate default settings are used for those protected IPs that are unknown,
have not yet been validated, or were discovered after the internal protected IP table
is full.

Defined Protected IPs

Contains all the defined Protected IPs. Checking the Remove check box and
then clicking on Update will remove Protected IPs from the defined list.
Contains all Protected IPs detected by the appliance, apart from those reported
above. Checking the Include check box and then clicking on Update will move
this Protected IP into the Defined Protected IPs section, where the specific
protected IP configuration can be changed from the Protected IP Defaults.

Auto-detected Protected IP

It is possible to purge out all the Auto-detected Protected IPs by clicking on

Delete
All.
It is possible to include all Auto-detected Protected IPs by clicking on Include
All. Inactive auto-detected Protected IPs will be automatically deleted after 5
days.
Note: Auto-detected protected IPs are allocated to the appropriate portals.

Configuring Date and Time

This section helps you configure date and time on your DDoS Secure appliance. Click Configure Date and Time
to configure Date and Time.
The screen on Figure 31 displays the options to configure date and time.

Figure 31: Data and Time Page

Date and Time must be set to the standard time for your environment as it is used in the
creation of log entries. Time is stored internally as UTC and displayed biased from UTC by the Time Zone
definition. It is advised that when installing or configuring a DDoS Secure appliance unit for the first time that
the system time configuration is set immediately after the Management Interface has been configured.
If your environment uses NTP to synchronize time, then a (comma delimited) list of server
IPs can be specified here. If NTP servers are specified, it is assumed that the
Management Interface IP address and default gateway definitions are sufficient to access
the specified NTP server(s). These NTP servers will keep the internal clock synced with
UTC time.
If NTP servers are defined, then the Date and Time fields are ignored when Update is
clicked. Changing the Time Zone changes how the date and time is represented when
displayed or when recorded in log files. It does not affect the duration of incidents or
recordings.

If NTP servers are not defined, then the internal clock will be set based on the Time Zone
and the Date and Time fields unless if this is a VMware instance, where time will be synced
up with the host server. Thus changing just the Time Zone may cause the (internal) UTC
clock to move forward or backwards by several hours to compensate for the time zone
change. It is important when adjusting the time configuration to always set the correct
timezone and time information, this helps prevents large leaps in the system clock
backwards or forwards. Large changes in the system clock can cause erroneous reports of
DDoS Secure appliance subsystems stalling or failing and for the duration of events to be
incorrect. The configuration of a valid NTP server can prove very useful as it prevents such
confusing error reports and ensures an accurate system clock is established and
maintained from power on.

NOTE: NTP Servers are not configurable when DDoS Secure appliance is running as an Application on a thirdparty hardware platform.
The NTP State describes how ntp is working, as defined by the ntpq -n -p linux command.
* in column 1 is the peer being used.

in column 1 is a peer that is not being used at present.

+ in column 1 is a peer that is a potential candidate.
After defining, or updating a set of NTP servers, NTP will take a few minutes
to choose a suitable, stable NTP peer, and so all column 1s will be blank.
Clock 127.127.1.0 is the local system clock.

Configuring Logging
You can specify where you want the appliance logging redirected to for off the box analysis, as well as control
the detail of the logging.
Click Configuring Logging to configure remote logging.
Portals
IP addresses can be specified asaaa.bbb.ccc.dddTo specify a specific IP address and can be separated by
commas where ever supported.
By expanding the appropriate portal, it is possible to configure the information for that portal by clicking on
the + in the Expand column.
Note: For any portal other than DDoS Secure appliance, only the Mail Server is configurable.
The screen on Figure 32 displays Secure Logging portal Option.

DDoS Secure Portal Options

SNMP
Appliance can be configured to send SNMP traps to a SNMP management tool such as HP
Openview. If this manager (or any other SNMP reader) wants to read MIB defined data via
SNMP, then the correct access control must be configured, see under [Network Access].
The DDoS Secure appliance MIB is contained on your DDoS Secure appliance Manual CD
and is called /SNMP_MIB/ DDoS Secure appliance.mib. The SNMP agent is set up for
Read-Only Access. The screen on Figure 33 displays Secure Logging SNMP Options.

DDoS Secure SNMP Options

Table below provides a summary of the information displayed on the DDoS Secure SNMP
options:

DDoS Secure SNMP Details

FIELD
Trap Receiver IP
Address(es)

System Location

System Contact
Trap Community Name

RO Community Name(s)

Syslog Server

DETAILS
The IP address for the SNMP trap destination has to be a specific IP address, and
cannot contain a network mask. Multiple IP addresses are valid, separated by a
comma. Traps are v2c.

This is the community name to be used whenever a SNMP trap is sent.

Only applications using the defined community name(s) can read the DDoS Secure
appliance MIB data. Multiple Community names are supported, , (comma)
separated.

Define here where your DDoS Secure appliance is located. This is kept unique
across an Active/Standby DDoS Secure appliance pair.

Define here the email address of whoever is responsible for the operation of your
DDoS Secure appliance.

The appliance can be configured to send a copy of the messages that it records in
the
DDoS Secure appliance logs to a syslog server. The remote syslog server may
require
reconfiguration before it will accept DDoS Secure appliance syslog messages. The
syslog
server will receive the messages at the specified Facility and Priority.The screen on
Figure
34 displays syslog server options.

DDoS Secure Syslog Server Options

Table below provides a summary of the information displayed on the DDoS Secure SNMP
options:

DDoS Secure Syslog Server Option Details

FIELD

Server IP address(es)

Facility

Priority

DETAILS
The IP address for the
syslog server has to be a
specific IP address and
cannot
contain a network mask.
Multiple IP addresses are
valid, separated by a
command.

Note: Version 4.0.3-0 and earlier, this was the priority encoded in messages sent
to the syslog server.
Note: The following message prefixes have the associated syslog priority levels:PrefixLogging Priority
BIOSError
CLIInformational ConfigNotice
CountInformational DebugDebug
DiskError

The syslog facility type to

EndInformational ErrorError
transmit in the messages to
GeoIPInformational
the syslog server.
GUIInformational
Inc'tInformational
InfoInformational
The syslog priority level at
RaidError
or above which messages
are transmitted to the
StartInformational StateInformational StatsInformational WarnWarning
syslog server.

Webtrends Server
The appliance can be configured to send messages to a Webtrends server in WELF
syslog format. The remote Webtrends server may require reconfiguration before it will
accept DDoS Secure WELF messages. The Webtrends server will receive the messages at the specified
Facility and Priority. The screen on Figure 35 displays Secure Logging webtrends server Options.

DDoS Secure Secure Logging Webtrends Server

Table 16 provides a summary of the information displayed on the DDoS Secure logging webtrends options:

DDoS Secure Logging Webtrends Details

FIELD DETAILS
Server IP address

The IP address for the Webtrends server has to be a specific IP address and cannot

contain a network mask. Multiple IP addresses are valid, separated by a comma.

Facility

The syslog facility type to transmit in the messages to the Webtrends server.

Priority

The syslog priority level to transmit in the messages to the Webtrends server.

Netflow Server
The appliance can be configured to send messages to one or more Netflow Collectors in
version 9 (RFC 3954) format. The Netflow Collector may require reconfiguration before it will accept Netflow
v9 messages from the DDoS Secure appliance. There is no aggregation of Netflow messages.
The screen on Figure 36 displays Secure Logging netflow server Options.

DDoS Secure Secure Logging Netflow Server

Table below provides a summary of the information displayed on the DDoS Secure netflow server options:

DDoS Secure Netflow Server Details

Mail Server
FIELD
Server IP address (es)

Port

Refresh Templates (Pkts)

Refresh Templates (Mins)

Flush Long Flows (Mins)

DETAILS
The IP address for the
Netflow Collector has to be a
specific IP address and
cannot contain a network
mask. Multiple IP addresses
are valid, separated by a
comma, as well as multicast
IP addresses.

This is the port that the

NetFlow Collector is listening
on.

When the specified number of NetFlow packets has been transmitted, then the
Templates defining the format of the NetFlow packets are re-transmitted.
When the specified number of minutes has passed since the Templates were
last transmitted, then the Templates defining the format of the NetFlow
packets are re-transmitted.

When the specified number of minutes has passed since NetFlow information
has been transmitted for a particular flow, then a NetFlow record is generated.
This allows Collectors to maintain Flow information about flows that have
active from some time, instead of waiting for the flow to timeout.
Note: When a long flow is flushed, this also resets the active/packet/byte
counters displayed in the stateful session information pages, such as TCP Info.
Session aggregation is not supported, so enabling this can generate a lot of
traffic.

If required, email can be sent every midnight with a copy of the daily statistics, or email can be sent to alert
on activity. Click Send Test Mail button to validate that email can be sent to and received by the Mail server.
The screen on Figure 37 displays Secure Logging mail server Options.

Figure 37: DDoS Secure Secure Logging Mail Server

Table below provides a summary of the information displayed on the DDoS Secure logging mail server options:

Table 18: DDoS Secure Mail Server Details

FIELD
Server IP address

From

To

DDoS Secure appliance Server

Send Daily Stats

Send Cluster Daily Stats

DETAILS
The IP address for the Mail
server has to be a specific IP
address, and cannot be a DNS
resolvable name. Multiple IP
addresses are not valid.

specified mail server and multiple recipients can be specified, (comma)

separated.

It is possible that you may be accessing the DDoS Secure appliance via an IP
address that is different to the DDoS Secure applicable management IP
address. Here, you can define the different IP address, or the DNS resolvable

The email address of whoever

is notionally sending the mail.
This address is used in the
header of the email but the
SMTP envelope of the email
uses the null sender <> as
failure or delivery delay
notification are not supported.

name to the alternative IP address for embedding into any URIs in the emails.

If selected, email will be sent every midnight with a summary of the daily
activity of your DDoS Secure applicable. This report contains the same
information as found on the Display Stats page. On Sunday mornings a
Weekly
summary is also sent. On the 1st of a month, a Monthly summary is also
sent.

The email address of the

required recipient. The address
must be acceptable to the
If selected, email will be sent every midnight with a summary of the daily
activity of all the DDoS Secure appliances sharing State information. This
report contains the same information as found on the Display Stats page.

Send Cluster Weekly Stats

If selected, email will be sent at midnight on Sunday mornings a Weekly

summary is sent. This report contains the same information as found on the
Display Stats page.

If selected, email will be sent at midnight on the 1st of a month a Monthly

summary is also sent. This report contains the same information as found on
the Display Stats page.
Send Cluster Monthly Stats
If selected, email will be sent summarizing the current incident activity (for
those incidents over the alert threshold. An alert email is sent from the DDoS

Send Alert

Secure appliance when the minimum mail interval separation time has
passed and there is at least one incident change yet to be reported.

Emails generated by incident activity are rate limited to sending no more

than one email per every min mail interval. Delayed alerts are collected and
sent together in a single email.

Min Mail Interval (mins)

Proxy Server

This may be needed to allow the DDoS Secure appliance to be able to access the internet to be able to
download the GeoIP updates using the management interface.
The screen on Figure 38 displays Logging proxy server Options.

DDoS Secure Logging Proxy Server

Table below provides a summary of the information displayed on the DDoS Secure proxy server options:

DDoS Secure Proxy Server Details

FIELD DETAILS
Server IP

The IP address for the Proxy server has to be a specific IP address, and cannot

be a DNS resolvable name. Multiple IP addresses are not valid. none indicates
no Proxy Server.

Server Port This defines the port to use on the Proxy Server.

Proxy User

This defines the user to authenticate the Proxy Server (can be blank).

Proxy Password

This defines the password to authenticate the Proxy Server (can be blank).

GeoIP Database(s)
The screen on Figure 39 displays GeoIP database Options.

Figure : DDoS Secure GeoIP Server

Table below provides a summary of the information displayed on the DDoS Secure portal
options:

Table : GeoIP Database Details

DETAILS
FIELD
Update GeoIP Database(es)

The database used to map IP addresses to Country is the GeoLite free version
provided by MaxMind (http://www.maxmind.com) under their license
agreement. There is also a free version that maps IP addresses to Cities, as
well as IP
addresses to AS number. If you want to use these free databases, subject to
MaxMinds license agreements, then your DDoS Secure appliance will need
access to the internet - either directly using DNS resolution, or via a proxy
server. By clicking on Update GeoLite Databases, the Country, City and AS
databases are installed and selected for updates on a daily basis.

Incident Create Threshold

The screen on Figure 40 displays incident create threshold options.

Figure 40: DDoS Secure Secure Incident Create Threshold

Table below provides a summary of the information displayed on the incident create threshold options:

Table : Incident Create Threshold Details

DETAILS
FIELD
Incident Create Threshold

It is possible to control whether incidents are created, and to specify the

packet rate at or above which they are created. If an incident has not been
created, then it is not possible to alert on, report on, or view information about
this incident.
Incidents are broken down into sixteen main categories, with each category
containing a set of specific incident].
Each main category can be enabled or disabled for incident tracking. If
enabled for tracking, when the errant packet rate for the main category is
equaled, or
exceeded, an Incident will be created if not already active.
When an Incident has not equaled or exceeded the errant packet rate for a
period of time (default of five minutes), the Incident will be closed.
Whenever an Incident goes over the Incident Alert Threshold for a period of
time (the default is 60 seconds) an entry is written out into the log file. If the
entry is logged, when the incident is closed, this will also be logged.
Any logging here will also be duplicated out to the syslog server (if configured
above) about the specific incident.
If there is a defined Webtrends server (configured above), then information is
sent out about an incident when the Incident closes.
By checking Auto Adjust, the threshold values will get adjusted once a day if
there is a high Incident rate to try to keep the Incident rate per category to be
between 10 and 100 per day.

Incident Alert Threshold

The screen on Figure 41 displays incident alert threshold options.

Figure : DDoS Secure Incident Alert Threshold

Table 22 provides a summary of the information displayed on the incident view threshold
options:

Table : Incident Alert Threshold Details

Incident Alert Threshold

Each main category can be enabled or disabled for alert tracking. If

enabled for tracking, when the errant packet rate within an incident has
equaled, or exceeded the Incident Alert Threshold for more than a period
of time (default is 60
seconds), an alert will be generated, as well as a log entry created. When
the incident is closed, a corresponding end of incident alert will be
generated.
If Incidents are not being created for this main category type, then the
Incident Alert will also implicitly be disabled.
If email is configured for sending Alerts then emails will be sent at the
appropriate
time.
If a SNMP Trap Server is configured then SNMP traps will be sent out for an
incident as appropriate alerts are triggered.

Incident View Threshold

The screen on Figure 42 displays incident view threshold options.

Figure : DDoS Secure Incident View Threshold

Table below provides a summary of the information displayed on the incident view threshold options:

Table 23: Incident View Threshold Details

DETAILS
FIELD
Incident View Threshold

The Incident View Threshold dictates when the Right Hand Pane Defense
Indicators turn from gray to red and from red to gray.
If Incidents are not being created for this main category type, then the
Incident View must also be disabled.
If an option is disabled, then the Defense Status for this option in the right
hand pane has the link reference removed.
The Right Hand Pane Defense Indicators will be red whenever the current
packet rate is at or above the specified view threshold rate.

Incident Peak Values

The screen on Figure 43 displays incident peak value options.

Figure : DDoS Secure Incident Peak Values

Table below provides a summary of the information displayed on the incident peak values
options:

Table : Incident Peak Value Details

FIELD DETAILS
Incident Peak Values

The Incident Peak Values indicate the peak values tracked since the values were

last reset. From this, it is possible to determine what would be the appropriate values to set in the Incident
Alert or Incident View fields.

Worst Offenders Logging Threshold

The screen on Figure 44 displays worst offender logging threshold options.

Figure : Worst Offenders Logging Threshold

Table below provides a summary of the information displayed on the worst offender logging threshold options:

Table : Worst Offender Logging Threshold Details

DETAILS
FIELD
Worst Offenders Logging
Threshold

An IP address will be a valid candidate for entering into the Worst Offenders
Table if tracking is enabled and errant packets are being generated by that IP
address.
Once an IP address has entered the Worst Offenders Table, and the IP
Addresses errant packet rate is at or above the threshold for this appropriate
category, an entry will be written into the log file. When the IP address is
removed from the Worst Offenders Table, then this event will also be written
into the log file.
If an IP address errant packet rate is at or above the Auto Black-List threshold
(type 1 or type 2), and Auto Black-Listing is then the IP address will be moved
out of the Worst Offenders Table and into the Auto Black-Listed IP Table.

General Logging

The screen on Figure 45 displays general logging options.

Figure 45: General Logging

Table below provides a summary of the information displayed on the general logging
options:

Table 26: General Logging Threshold Details

FIELD DETAILS
General Logging

It is possible to configure whether Worst Offender activity and Auto Black

Listed activity are logged to the general log file. This information is always
logged to the Worst Offender log files. Enabling this (the default) causes
entries to be written out to the general log file. On busy DDos Secure
appliance, this can generate a large amount of log entries. In addition,
Incident detail information can also be logged to the general log file.

Debug Options
The screen on Figure 46 displays debug options.

Figure : Debug Options

Table below provides a summary of the information displayed on the general logging
options:

Table 27: Debug Option Details

DETAILS
FIELD
Debug Options

Enabling any of these options can cause very large amounts of data to be
written out into log files. These options should only be used when
troubleshooting at the request of a appliance engineer.

Configuration File

Through the Configuration File Window, it is possible to view, save and restore configurations.
Click Configuration File to bring up the Configuration File management page in the Center Pane, or for guest
accounts a partial copy of the configuration file will be displayed, see the View option below.
Click one of the following:

DownloadWill prompt you for a location to save the (encrypted) configuration file on
your PC.

Browse Will enable you to locate a previously saved (encrypted) configuration file.
Then this file can then be uploaded and installed as the running configuration by
clicking Upload. Normally, when a configuration is uploaded, interface definitions are

ignored as the configuration may be from a different DDoS Secure appliance. It is

possible to override this by checking Use Interface Definitions.

View Will bring up a copy of the current configuration in the Center Pane. However
only administrator accounts will see the whole configuration file. Operator accounts will
only see a partial copy of the configuration file with user account information removed.
Guest accounts will find that they only have the partial copy of the configuration file
displayed, as they do not have access to all configuration file management options.
Figure 47 and Figure 48 display the configuration option and the snippet of the
configuration file as seen by an administrator account.

Figure : Configuration File Options

Figure : Configuration File Page

The configuration section contains a listing of Command Line Interface (CLI) commands
that would, when displayed for an administrator, completely recreate the device current
settings. The CLI section would be missing the user information when viewed by a guest or operator account.
NOTE: A portal user will only see their portal configuration.
Statistics Reports
Display of statistics reports allows you to review the current defensive statistics of the appliance.
Click Statistics Reports to display current defensive statistics. Figure 49 displays the Log Files page.

Figure: Statistics Report Page

These statistics report the activity of the DDoS Secure appliance over the last 24 hours. Any defense line that
comprises of only zero entries is not reported. portal users will only see data relevant to their portal.
The statistics are broken down into nine sections, and output can cover a day, week or
month depending on the options selected. Some of the sections may not be presented, as they are not
appropriate to the selected options.
Table below provides a summary of the information displayed on the DDoS Secure statistic report page:

Table 28: DDoS Secure Statics Report Details

DETAILS
FIELD
Graphical Summary

Packet Drop / Notification

Activity

This section summarizes the Traffic Throughput, the Traffic dropped (Internet
Noise, Black Listed and Attack) and the Traffic Dropped (Attack only).

This section summarizes the packet drop activity and reasons why the packets
were
dropped, as well as situations that occurred and there was no packet drop
activity.
This section reports any worst incidents tracked over the month, week and day.

Worst Incidents
This section reports any incidents that were active for the selected date.
Incidents

Portals

These statistics reflect the traffic rates and the counters used for the portal. Any line

containing all zeros in the counters section is not reported.

Table Usage These statistics reflect the usage of different tables with the DDoS Secure appliance
software.
Over time, the History, URLs and Worst Offenders Tables will become 100% full, which is normal. When the
table is full, the least recently used entry is discarded.

Resource Usage

These statistics reflect how the appliance is being utilized.

Memory usage is always likely to be high as the underlying OS uses spare memory for disk caching.
It is possible to look back over the last week and month, previous week and months
worth of Statistics by clicking on the appropriate button, or for a specific by selecting the date and clicking on
Date. Up to 60 days worth of information is held, but is dependent on available disk space.
A copy of this statistical report can be emailed every midnight if required.

General Logs
This allows you to review the log files of the appliance to see what has happened in the
past.
Click General Logs to display log files. Figure 50 displays the DDoS Secure General Logging page.

Figure 50: DDoS Secure General Logs Page

The log file starts with a date and time entry, followed by a log entry type prefix. The next
entry is appliance, Indeterminate, Multicast, Broadcast, an IP address, a MAC address, or
Incident report identification. The final part of the entry describes why this entry was
logged.
If a Protected IP is unknown, or has not yet been validated, then the entry will be logged against
Indeterminate.

BIOSIndicates an entry from the BIOS System Event Log (SEL).

CLIUser connected or disconnected from the CLI.

ConfigIndicates configuration changes. + is added, - is deleted.

CountAdditional information about a condition that has a start reference.

information.

DebugDebug

DiskDisk Sub-System messages.

EndEnd of a condition that has a start reference.

GeoIPStatus change in GeoIP updates from www.maxmind.com.

GUIUser connected or disconnected from the GUI.

Inc'tIndicates information about a specific incident. Clicking on this will take you
straight to the Incident information.

InfoInformational information.

RaidRaid Sub-System messages.

StartStart of a particular condition.

ErrorIndicates some error condition.

StateDDoS Secure appliance state change (For Example:. reboot initiated).

have been generated.

StatsDaily statistics

WarnIndicates some warning condition.

For Worst Offender, the Start: entry is only recorded when the IP address has exceeded the average error rate
as defined under Configure Logging. The End: entry is recorded when the IP Address is replaced by a new
Worst Offender. In addition, the Count: entry records the different defense types and counts for that specific
IP address.
By default, only the first 1Mb of information is displayed with the latest entry at the top. If
there is more information, it is possible to display all the information by clicking on Full List
at the end of the output. This may take some time to download - especially over slower
links.
The display log page has the following options:

Download LogfileIt is possible to download the complete file in compressed format to

your local by clicking on Download Logfile, found at the bottom of the log file.

Download HelpDesk InformationBy clicking on Download HelpDesk Information

(found at the bottom of the log file output), a copy of information suitable for DDoS
Secure appliance Support will get downloaded to your local PC for onward forwarding
to DDoS Secure appliance Support. This includes the full set of the DDoS Secure
appliance log files.

Create Dell DSET InformationBy clicking on Create Dell DSET Information (if

available, found at the bottom of the log file output), a copy of information suitable for DDoS Secure appliance
Support will get built ready for downloading to your local PC for onward forwarding to DDoS Secure appliance
Support.

NOTE: This may take some time - do not leave the page while this is being processed.
This should not be run on a busy DDoS Secure appliance.

Download Dell DSET InformationBy clicking on Download Dell DSET Information

(if available, found at the bottom of the log file output), a copy of information suitable for
DDoS Secure appliance Support will get downloaded to your local PC for onward
forwarding to DDoS Secure appliance Support.

Download Core FileBy clicking on Download Core File (if available, found at the

bottom of the log file output), a copy of and core files will get downloaded to your local PC for onward
forwarding to DDoS Secure appliance Support.
Incident Logs
Display incident page allows you to review the active Incidents tracked by the appliance.
Click Incident Logs to display active Incident information. For an Incident Defense Type to be displayed here
(the default), it has to be enabled in Incident Create Threshold,
configured in Section [Configuring Logging].
Figure 51 displays the tracked incident List page.
Figure 51: Incident Logs

NOTE: Entries that are red font in either the incident log, or the active
incidents are incidents that have been over the alert threshold for at least 1
minute.
Incidents can be filtered by Protected IP or Portal by selecting from the pull down list.
up a log of incidents that has taken place today.
Date to bring up a log of incidents that have taken place within the specified date
range. Only the last 60 days worth of incidents are kept on disk.

Today to bring

CSV Display to bring up a comma-separated detail of incidents that have taken place
within the specified date range. You can look up a specific incident by entering the
incident number, which is in the format yyyymmdd/nnnnnn .

Date and Time hyperlink to drill down to the specific detail of an incident.

Display Incident Details

By hovering the mouse over an IP address, it is possible to roughly determine where the IP address is.
There are three types of Incident activity - recorded on the 7th line of output.
Packets DroppedPackets are actually being dropped (unless in Logging mode).
Packets are actually being noted (as in Logging mode)
OccurredThe situation has been noted this number of times.
Figure 52 displays the specific display incident List page.
Figure : Specific Display Incidence Page

Worst Offenders Log File

Packets Noted

Click Worst Offender Log to display Worst Offenders. Figure 53 and Figure 54 displays the Worst offenders
page.

Figure: Worst Offenders Log Page Snippet 1

If an IP address (or Address/NetMask) is entered and the Find IP is clicked, the GUI
will output all entries that it can find in the logs or Incident information.
If a time is defined with a tolerance either side and Find Time is clicked, the all
information referring to the time window is output.

Figure: Worst Offenders Log Page Snippet 2

Click Download Logfile (found at the bottom of the log file output), for a copy of the
log file
that can be used for post processing on the Worst Offender information. Other
download
options are:

Download CSV Logfile.

Download Black-Listed IPs CSV Logfile.

Download Previous Month CSV Logfile.

Download Previous Month Black-Listed IPs CSV Logfile.