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 Part—Describes all the different portals configured on the DDoS Secure appliance. Second Part—Describes the Filters in use in a portal. Third Part—Describes the Filter Aggregations in use in a portal and the final part describes the

protected IPs that are in use in a portal. Fourth Part—Describes 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 Part—Describes all the different portals configured on the DDoS Secure appliance.

Second Part—Describes the Filters in use in a portal.

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

Fourth Part—Describes 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

All—All IP addresses are valid (includes IPv6). all-ipv4—All IPv4 addresses. aaa.bbb.ccc.ddd/mask—To specify a group of IPv4 addresses using a subnet mask. aaa.bbb.ccc.ddd/count—To specify a group of IPv4 addresses using a subnet mask length. aaa.bbb.ccc.ddd—To specify a specific IPv4 address. aaa.bbb.ccc.ddd-eee.fff.ggg.hhh—To specify a range of IPv4 addresses. xxxx::xxxx:xxxx/count—To specify a group of IPv6 addresses using a subnet mask length. xxxx::xxxx:xxxx—To specify an IPv6 address. xxxx::xxxx:xxxx-yyyy:yyyy::yyyy—To 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.

v—VLAN m—MPLS 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 Over The 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 IPs The 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 connection’s 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 53-54,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 Client’s 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 Client’s 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 Client’s 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 The recommended default is normally one quarter of the theoretically maximum number of

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] Select a Filter Name or a Filter Aggregation Name from the pull-down list. It is valid (but

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

The IP address of the IP being protected.

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 current count increases towards the (potentially automatically determined) hard limit.

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 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 Connections

Max Conn Rate

Suggested Conn Rate

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 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 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 FilterThe 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 Can be used to define a name for a protected IP to aid identification when defining

values.

Active Ports

Enabled Ports

Defined Protected IPs

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.

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

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 auto-detected 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

Auto-detected Protected IP

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.

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 third-party 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.ddd—To 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)

Trap Community Name

RO Community Name(s)

System Location

System Contact

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.

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

The syslog priority level at or above which messages are transmitted to the syslog server.

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:-Prefix—Logging Priority

BIOS—Error

CLI—Informational Config—Notice

Count—Informational Debug—Debug

Disk—Error

End—Informational Error—Error

GeoIP—Informational GUI—Informational Inc't—Informational Info—Informational Raid—Error

Start—Informational State—Informational Stats—Informational Warn—Warning

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

FIELD

Server IP address (es)

Port

Refresh Templates (Pkts)

Refresh Templates (Mins)

Flush Long Flows (Mins)

Mail Server

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.

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.

The email address of the required recipient. The address must be acceptable to the 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 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.

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

Send Cluster Monthly Stats

Send Alert

Min Mail Interval (mins)

Proxy Server

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.

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

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.

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

FIELD

Update GeoIP Database(es)

DETAILS

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 MaxMind’s 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

FIELD

Incident Create Threshold

Incident Alert Threshold

DETAILS

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.

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

Incident View 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.

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

FIELD

Incident View Threshold

DETAILS

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

FIELD

Worst Offenders Logging Threshold

General Logging

DETAILS

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.

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

FIELD

Debug Options

Configuration File

DETAILS

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.

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:

Download—Will 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

FIELD

Graphical Summary

Packet Drop / Notification Activity

Worst Incidents

Incidents

DETAILS

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.

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

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 UsageThese 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 month’s

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.

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

CLI—User connected or disconnected from the CLI.

Config—Indicates configuration changes. + is added, - is deleted.

Count—Additional information about a condition that has a start reference. Debug—Debug information.

Disk—Disk Sub-System messages.

End—End of a condition that has a start reference. Error—Indicates some error condition.

GeoIP—Status change in GeoIP updates from www.maxmind.com. GUI—User connected or disconnected from the GUI.

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

Info—Informational information.

Raid—Raid Sub-System messages. Start—Start of a particular condition.

State—DDoS Secure appliance state change (For Example:. reboot initiated). Stats—Daily statistics have been generated.

Warn—Indicates 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 Logfile—It 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 Information—By 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 Information—By 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 Information—By 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 File—By 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. Today to bring 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.

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 Dropped—Packets are actually being dropped (unless in Logging mode). Packets Noted—Packets are actually being noted (as in Logging mode) Occurred—The 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

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.