DoS/DDoS attack prevention & mitigation setup


LBL DoS/DDoS attack mitigation function is an integrated module optional product LBL Application Delivery Controller and is available for all distributions.

The license LBL DoS/DDoS attack mitigation function then enables the functionality and should not be added modules or libraries installation LBL Application Delivery existing Controller.

Being the suite LBL S.A.A.I. a product destined for mission-critical environments business-critical only staff who made the course and has passed the examination is authorized to certify the installation and maintenance of products in operation. All Certified People are equipped with document issued by TCOGROUP SRL.

LBL DoS/DDoS attack mitigation function

LBL Application Delivery Controller integrates a prevention system Denial of  Service and Distributed Denial of Service  (DoS/DDoS) capable of controlling and catalog real-time dynamics of service request and their evolution. All connections that traverse the layer of balancing are constantly analyzed and catalogd by identifying abnormal events and implementing actions to guarantee continuity of services.

DoS/DDoS congestion resolver©

The system is able to automatically detect coordinated attacks from multiple sources implementing techniques instant congestion which release the service and make it available again. These attacks are difficult to identify being put in place by countless sources. Typically are the result of a virus that once propagated on different vectors are active at the same time paying their attack toward a single goal. In the field of e-commerce the same effects are detected with a marketing campaign well managed. Typically a promotional campaign is promoted through mailing list composed of hundreds of thousands of email addresses. If the campaign was successful and the offer is of interest the site is achieved simultaneously from hundreds of thousands of ‘click’ (observable in the graph to the left and above). The detection of saturation of resources of the backend are activated the defenses through decongenstione. From version 9 it is possible to perform a capping of the requests for individual service further increasing the granularity of intervention.

DoS/DDoS address quarantine©

C:\Users\vale\Google Drive\share\Documents\Products\LBL DoS DDoS Attack mitigation\Images\nafeikaopakadiml.png
C:\Users\vale\Google Drive\share\Documents\Products\LBL DoS DDoS Attack mitigation\Images\kajnbdabfbhblpfc.png
The function DoS/DDoS address quarantine is able to identify sophisticated attempts to exclusive use of the resources by the few subjects. The latter are recognized automatically and excluded by placing the addresses, source of inefficiency, ‘quarantine’ for a predetermined period of time. Normally these attacks come from dynamic addresses and therefore not insertable on public directory of “black lists”. After the time has expired “quarantine” is again made possible on the address placed in quarantine access to services.

VIP iRedCarpet© (Very Important People)

Last evolution, derived from experience in the field of e-commerce, is the feature VIP iRedCarpet©. This feature allows to discriminate, from the point of view of application, the traffic “useful” by traffic “touristy” reacting in a different manner depending on the traffic conditions. The system was designed to give priority to the access of the connections according to the type of service requested, for example privileging the connections that are running of payments or have already performed the authentication to the portal or in the e-commerce, those who have the truck load than those who are browsing in a single consultation. VIP iRedCarpet© collaborates with the functionality DoS/DDoS address quarantine and DoS/DDoS congestion resolver© by increasing the accessibility of services by distinguishing the types of navigation Quality of Service Application (AQoS).

LBL DoS/DDoS attack mitigation function: License Installation

Once you have initiated  LBL Secure Web-Based GUI and logged in to node, select the module designated to host the functionality LBL DoS/DDoS attack mitigation and perform the operations listed below.

If you are not in possession of a license  LBL DoS/DDoS attack mitigation is possible to make a request to TCOGROUP SRL or to an authorized reseller.

Select the module in the shaft of the processes (usually a10_LBLGo) in which you want to install the license LBL DoS/DDoS attack prevention. With the right mouse button select Install license:

Select the appropriate license that will necessarily be called license.xml.

Once you have confirmed your license will be displayed the result of the upload. If successfull go to next step

LBL Application Delivery Controller: Stop

Once installed with success the license you will need to proceed with the restart of the module LBL Application Delivery Controller. To make the restart of the module LBL Application Delivery Controller is sufficient to perform a stop and then a start:

It is possible to see how the situation evolves through LBL Secure Web-Based GUI that highlights the shutdown of the process…

LBL Application Delivery Controller: Start with DoS/DDoS attack mitigation function

Once the module of balancing has stopped you can proceed with the Start module that at startup will acquire the new license enabling the functionality DoS/DDoS attack prevention.

LBL DoS/DDoS function: basic settings

Once installed the license LBL DoS/DDoS attack mitigation function it is possible to render it operative immediately through the general parameters of the configuration LBL Application Delivery Controller through the choice D-DOS/DDOS attack in the menu of the ADC Settings.

The parameters below set the basic functionality of the product that are then immediately usable for the production giving the possibility to perform, following a  specific tuning.

The parameter that enables the functionality is DoS/DDoSAttackPrevention which by default is disabled and will therefore have to be set explicitly to “true”. Another important parameter is DoS/DDoSAttackPreventionOnlyClose. This parameter is by default set to true for safety. His approach to “false” must be reasoned, in fact, once set to “false”, if we are in the presence of HTTP/S, the exceeding of the threshold Red Alert will be returned to all users a page of courtesy of overload. In mission-critical environments or business-critical, the page of courtesy can be used by an attacker as a signal to change strategy of attack. For this reason DoS/DDoSAttackPreventionOnlyClose is set by default to “true”. Normally if we are not under stringent conditions mission-critical and business-critical parameter will be set to “false”.

DoS/DDoSAttackPrevention=: default value="false" boolean



If set to true are applied the rules for the prevention of an attack is a DoS /DDoS (Denial of Service). DoS/DDoSAttackPrevention intervenes in different ways depending on the type of attack:

1- multiple requests from the same IP address

2- multiple requests from different  IP indirzzi

In the first case the overcoming of a defined number of simultaneous requests that can be set with the parameter “DoS/DDoSMaxTunnelForClientAddress”, these are erased including any pending requests in internal queues.

In the second case the exceeding of the threshold highWaterDangerLevel all pending requests and/pending in the queues are erased.

In both cases, before the cancellation of pending requests, if connection in HTTP/S is sent a page of courtesy to the client who has made the request.

DoS/DDoSAttackPreventionOnlyClose=: default value="true"



Upon detection of a DoS/DDoS attack the default action is to close the channels that were identified as a threat. For some protocols you can return the indication of temporary inability to reach the service with a page of courtesy. This indication could be used to refine the attack and is therefore disabled by default.

LBL DoS/DDoS function: DoS/DDoS congestion resolver

The functionality DoS/DDoS congestion resolver© is based on the continuous observation of the behavior of the connections and connection requests waiting to be taken in charge by a tunnel. Is a feature unique in its kind and made possible by the engine of forwarding a finite resources at the base of the product LBL Application Delivery Controller.

The reference values to be taken into consideration are respectively the number of tunnel of forwarding and the number of connections waiting to be connected to a resource of the backend. These values in terms of parameters are respectively concurrentSessions maxConcurrentSessions and.

ConcurrentSessions=: default value="50"



It is the number of connections which can be served at the same time initials

MaxConcurrentSessions=: default value="200"



It is the maximum number of connections which can be served at the same time.

Normally in a production deployment of these two values are identical and are fixed on the basis of the calculation capacity and services response of  ‘s backend datacenter es.:





DoS/DDoS congestion resolver© checks every 50 milliseconds the occupation of the tunnel and the number of connection requests in the queue of waiting. If all the tunnels are saturated and the wait queue exceeds the percentage value of employment indicated by highWaterWarningLevel parameter (default 10.0%) compared to the number of tunnel set is immediately notified by message that is undergoing an anomalous peak but still not worrying. The message is written to the log, reported in DB and, if set, notified by e-mail.

Upon reaching or exceeding the parameter highWaterDangerLevel  LBL DoS/DDoS congestion resolver© performs a close with flush all the connections in the tunnels, where provided back to clients any pages of courtesy and then will restore the forwarding of new requests. It is important to note that the close of the channels takes place in a controlled manner the species in the connections of the backend. The flush of the connections is very important because it allows services to backend to properly close the  open file descriptors by application server and free actually resources. In the image on the right is a real example of overshooting the threshold Danger Level and immediate resolution of the event.

The parameters for setting the thresholds are then highWaterWarningLevel highWaterDangerLevel and of which we quote below descriptions available also in the Reference Guide.

HighWaterWarningLevel=:  default value="10.0" UM=%



It is the percentage threshold of connections waiting to be taken in charge by an executor of the pool of forwarding. If this threshold is exceeded the system notifies you with a specific message (yellow-alert) has been exceeded. If the limit is exceeded are instantiated in addition new sessions of forwarding until reaching the “maxConcurrentSessions”.

HighWaterDangerLevel=: default value="70.0" UM=%



It is the percentage threshold of connections waiting to be taken in charge by a session of forwarding. If this threshold is exceeded the system notifies you with a specific message (red-alert) has been exceeded. If the limit is exceeded are instantiated in addition new sessions of forwarding until reaching the “maxConcurrentSessions”. With LBL DoS/DDoS attack mitigation function if this limit is reached the system performs the procedures DoS/DDoS Congestion Resolver©

LBL DoS/DDoS function: DoS/DDoS address in quarantine

One of the Attacks DoS/DDoS more frequent takes place thanks to a few or even just one attacker. The use of black-list static on public directory is absolutely not recommended because normally an attack of this type does not occur by static addresses but from dynamic addresses and then lock the address in a permanent manner, would not have obtained the result or worse have precluded from that address a possible contact in the future. Worst thing if the From address is an organization, would be precluded from that organization for ever, the possibility of access to its services.

LBL®DoS/DDoS address in quarantine© checks every 50 milliseconds the number of connections that are going through the layer of routing with the same address. If you exceeded the threshold described in the parameter DoS/DDoSMaxTunnelForClientAddress address is catalogd in a table inside the balancer. All connections from that address will be immediately canceled and for incoming connections policies are implemented notice of courtesy or redirect if set otherwise also those connection requests will be canceled. For that address will be denied access to services for a predetermined time from the parameter DoS/DDoSAddressQuarantineTime, normally set at 30′ (minutes). The expiry of the time will be given again the possibility to request services at the address previously blocked. If recurs the problem the address will again be quarantined.

DoS/DDoSMaxTunnelForClientAddress=: default value="100" mu=requests in the tunnel



Indicates the threshold as the number of requests served simultaneously for single IP address of origin. If this threshold is exceeded all connections established coming from the same IP will be instantly erased. If HTTP/S to all connections on hold in the queue of requests will be answered with the courtesy message (DoS/DDoSCMessage) ridirezionate or on the basis of the parameter (DoS/DDoSRedirect).

DoS/DDoSAddressQuarantineTime=: default value="1800000" UM = milliseconds



In the identification of an attack from a single ip address these is automatically placed in quarantine by preventing access to services. The time of quarantine is determined from this value (30′). Exceeded this time is given again the possibility to the client to access services. If this value is set to 0 or < 0 the quarantine feature is disabled.

LBL DoS/DDoS function: DoS/DDoS courtesy message

If the parameter DoS/DDoSAttackPreventionOnlyClose was set to false service requests HTTP/S “cut” will receive a courtesy message with the indication of retry later for overload of requests. The courtesy message is modifiable by the user. LBL®Application Delivery Controller, if not modified, will have the following html page:

You can also change the name of the page of the overloads of default through the parameter DoS/DDoSCMessage as described below.

DoS/DDoSCMessage=: default value="messageServicesOverload.html"



Indicates the page of courtesy to expose in the case of activation of the DoS/DDoS attack prevention.

If you want to edit the page of courtesy is sufficient to extract from the compressed file (LBL_HOME)/lib/lblApplication Delivery Controller.jar file:

Application Delivery Controller/resources/html/ messageServicesOverload.html and place it in

(LBL_HOME)/lib/Application Delivery Controller/resources/html. Once you have located the file you can also modify it during the runtime. This parameter is taken into consideration if DoS/DDoSAttackPreventionOnlyClose is set to false.

LBL DoS/DDoS function: DoS/DDoS redirect

As an alternative to the courtesy message, if the connection is HTTP/S, it is possible to indicate the client to perform a redirect to another site/service. This feature allows you to perform diversified activities during an attack or to a sudden peak of requests. In fact, happens more and more often that the congestion is not due to real attacks but from marketing campaigns successful with a very high rating for subscription to the campaign. The possibility of diverting requests on another site in order to respond to the request or more simply a redirection to a page that proposes a additional promotion if the customer decides to return in a second moment, may be valid marketing tools that can then offer customers a communication channel and fidelity important.

To set the redirect below the description of the parameter.

DoS/DDoSRedirect=: default value=""



If valued indicates the URI to which redirect the request in the case of activation of the DoS/DDoS attack prevention. e.g.:

If this value is set has priority over the parameter DoS/DDoSCMessage. This parameter is taken into consideration if DoS/DDoSAttackPreventionOnlyClose is set to false.

LBL DoS/DDoS function: VIP iRedcarpet© AQoS (Application Quality of Service)

LBL VIP iRedCarpet© is born from the experience made in these years in themes DoS/DDoS attack mitigation and is an important policy developments QoS oriented to the applicative components AQoS (Application Quality of Service). LBL VIP iRedCarpet© acts in the context of overall functionality LBL DoS/DDoS attack prevention© but enters the merits of each individual service requests to determine the privilege of accessibility in moments of particular load. For example it is possible to distinguish the confirmation of purchase orders from credit card operators and then privilegiarne passage, it is possible to distinguish between users who have already loaded the truck by others who are only by carrying out a verification visit and thus favor the passage of the first and invite the seconds to try again later.

These policies of privilege of Access to Services you can make through rules of rewriting it that describe the dynamics. Rules can be structured to selectively limit requests on the basis of the rising of the load until you get to keep open the services for the Sun requests absolutely indispensable and criticism.

Normally the first rule to set is the rule that allows in normal conditions of passing all incoming requests. It is important to note that this rule, being the first, is also the last to be performed if the condition occurs, in fact, with the command  EnableAccessOnNormalCondition followed with LAST (EnableAccessOnNormalCondition;LAST) induces the rewriter LBL®Application Delivery Controller not to apply other rules to the occurrence of a condition of normality.

The rule below can be used as a template to identify a level of requesting queuing judged in accordance. The level of requests in the queue, even in moments of strong load, normally remains very close to zero (0). The INNERVAR HIGH_water_level, put at the disposal of the Rewriter by functionality LBL®DoS/DDoS attack prevention, allows you to read the number of requests pending forwarding during the single request. With the functionality <numOperatorTag> you can perform numerical comparisons and then condition the action to a value. The actions permitted by <numOperatorTag> are:


Neq=not equal

Gt=greater than

Geq=greater equal

Lt= less than

Leq=less equal

There are already templates  available with all the preset parameters:

RewriteHeaderRule name="VIP_EnableAccessOnNormalCondition"

   flow="REQUEST" caseSensitive= "true" variables Var

varName=highWaterLevel"" name="HIGH_water_LEVEL" from=INNERVAR"" conditions

operator="and" cond

from="VARIABLE"  name=highWaterLevel"" numOperatorTag=

leq 10


Other INNERVAR made available by rewiter with functionality LBL®DoS/DDoS attack mitigation to condition the service requests are:

HIGH_water_YELLOW_warning_REACHED = if true was exceeded the threshold Yellow

Warning. Thus indicates a considerable load but not

Still critical.

HIGH_WATER= number of connection requests in the queue in long format.

HIGH_water_level= % of connection requests in the queue compared to the number of tunnels    Contemporary settings, this is a float value.

TUNNEL_SESSIONS_ACTIVE= Instant active tunnels, int format.

TUNNEL_SESSIONS_COMMITTED= Instant tunnel committed, (subset of    TUNNEL_SESSIONS_ACTIVE”)

ACTUAL_tunnel_SESSIONS_SIZE= The actual size of tunnels: (usually equal to


MAX_tunnel_SESSIONS_SIZE= Maximum number of tunnels set.

If the level of load considered “normal” from the first rule should be exceeded will then verify the request in detail to determine the privilege of passage or stop it instantly.

The two rules below indicate for example that for loads above 10 (gt 10) The payment confirmation of credit cards and logins from the organization itself, internal and external, are in any case privileged.

RewriteHeaderRule name="VIP_EnablePaymentGatewaysOnOverload" flow="REQUEST" caseSensitive= "true"


   Var varName=highWaterLevel"" name="HIGH_water_LEVEL" from=INNERVAR""

   Conditions operator="and"

   Cond from="VARIABLE"  name=highWaterLevel"" >

   NumOperatorTag=gt 10




RewriteHeaderRule name="VIP_EnableAdminSitesOnOverload" flow="REQUEST" caseSensitive= "true"


     Var varName=highWaterLevel"" name="HIGH_water_LEVEL" from=INNERVAR""

   Conditions operator="and"

   Cond from="VARIABLE"  name=highWaterLevel""

   NumOperatorTag=gt 10




If the conditions in the preceding rules should not be met then you would proceed with the next rule that can be satisfied with a level of queuing from 10% to 39%. In this case for those who were already connected previously and which have received a session from LBL®Application Delivery Controller is allowed access to the services of the backend.

This is obviously just an example, it is possible to condition the privilege to step on any other flag as a cookie is generated by the application, a URI path, a referer etc.

RewriteHeaderRule name="VIP_YellowOverloadEnableReqWithLBLSESSIONID" flow="REQUEST"

   CaseSensitive= "false"


   Var varName=highWaterLevel"" name="HIGH_water_LEVEL" from=INNERVAR""/>

   Conditions operator="and"

   Cond from="VARIABLE"  name=highWaterLevel""

   NumOperatorTag=geq 10

   Cond from="VARIABLE"  name=highWaterLevel""

   NumOperatorTag=lt 40

   Cond from=INNERVAR""  name="REQUEST_HTTP_COOKIES_List"



If all the above rules should not be met and the level of the load should be equal to or higher than 40% (geq 40) users who have performed an authentication in the portal nonetheless freely to navigate through the services.

RewriteHeaderRule name="VIP_OrangeOverloadEnableReqWithLBLSESSIONIDandUSERID" flow="REQUEST"

   CaseSensitive= "false"


   Var varName=highWaterLevel"" name="HIGH_water_LEVEL" from=INNERVAR""

   Conditions operator="and"

   Cond from="VARIABLE"  name=highWaterLevel""

   NumOperatorTag=geq 40

   Cond from=INNERVAR""  name="REQUEST_HTTP_COOKIES_List"



In case none of the preceding rules has been fulfilled, with a level of upper queuing to 10% all service requests will instead be cut (connectionToCut connectionToCut= “true”), close the channels, page of courtesy or redirect.

RewriteHeaderRule name="VIP_DisableAccessOnOverload" flow="REQUEST" caseSensitive= "true"


   Var varName=highWaterLevel"" name="HIGH_water_LEVEL" from=INNERVAR""

   Conditions operator="and"

   Cond from="VARIABLE"  name=highWaterLevel""

   NumOperatorTag=gt 10

   ConnectionToCut connectionToCut= "true"


Earlier we saw how to describe the rules to filter the requests in dependence of the levels of queuing caused by the load of requests. Later on we will see how to apply the rules at the level of flows and i.e. apply the rules described above to groups of services. It is to be noted the behavior modifier ;last that the occurrence of the condition described in Rule does not perform the successive rules remaining. In this case applied the ;LAST in each rule, the first that meets the conditions is performed without continaure in verification and enforcement of remaining.


   EndPointsGrouping groupName="es62prod" enable= "true"

   VirtualDomain loadBalancingType=Adaptative""








Endp address="" port="8585" uriPath="/srv01" enable= "true"

Endp address="" port="8585" uriPath="/srv02" enable= "true"

Endp address="" port="8585" uriPath="/srv03" enable= "true"


LBL DoS/DDoS function: DoS/DDoS congestion resolver service capping

From Release 9 LBL Application Delivery Controller, LBL DoS/DDoS attack mitigation is enriched by the possibility to set a maximum level of use of the services of the backend. It is in fact possible to set for single grouping of services a maximum number of connections. This value is determined by the sum of the maximum number of connections for that service described in endp that compose it. For example endPointsGrouping-> virtualDomain->URIpath the maximum capacity for the processing of service httpOne->>/one is 20+12=32. For the group of services httpOne->>/two will be 11+56=67.

This functionality can be activated through the parameter DoS/DDoSMaxConcurrentConnectionsReaction=”true”, otherwise the behavior remains the default and that is the only event logs.

EndPointsGrouping groupName=httpOne""



   DoS/DDoSMaxConcurrentConnectionsReaction= "true"

   Enable= "true"


      DoS/DDoSMaxConcurrentConnectionsReaction= "true" enable= "true"

Endp address="" port="8585" maxConcurrentConnections="20" uriPath="/one"

Endp address="" port="8585" maxConcurrentConnections="12" uriPath="/one"

Endp address="" port="8585" maxConcurrentConnections="11" uriPath="/two"

Endp address="" port="8585" maxConcurrentConnections="56" uriPath="/two"


LBL DoS/DDoS function: Conclusions

LBL DoS/DDoS attack mitigation is a value-added features and functionality that over time has been improved up to the achievement of the sophisticated features that today can be made available to the market.

The effect of what is described in these paragraphs, measurable in real time through LBL Management Console, you can appreciate the following images. The images are related to a real situation of great distribution e-commerce. Three consecutive send promotional e-mail consumers who responded immediately to the invitation were several tens of thousands (120,000 within about two hours). The first sending LBL iRedCarpet VIP has detected the event of excessive load that has immediately solved without “cut” the connections of business in progress while preserving the functioning of services of the backend and of the data base.

LBL DoS/DDoS attack mitigation is up to now the only platform that manages to dynamically filter the service requests in dependence of the loads and the application service required by providing a tool for Quality of Service Application without equal on the market today.

Are you interested in our solutions?