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.
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.
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.:¬†http://www.caugthinfo.com/
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:
Lt= less than
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
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" Variables Var varName=highWaterLevel"" name="HIGH_water_LEVEL" from=INNERVAR"" Conditions operator="and" Cond from="VARIABLE" name=highWaterLevel"" > NumOperatorTag=gt 10 Cond from=INNERVAR"" name="REQUEST_HTTP_URI_PATH" RegexTagPayPalReturn=|XPayFOLightReturn|ReceiveAgos
RewriteHeaderRule name="VIP_EnableAdminSitesOnOverload" flow="REQUEST" caseSensitive= "true" Variables Var varName=highWaterLevel"" name="HIGH_water_LEVEL" from=INNERVAR"" Conditions operator="and" Cond from="VARIABLE" name=highWaterLevel"" NumOperatorTag=gt 10 Cond from=INNERVAR"" name="REQUEST_HTTP_URI_PATH" RegexTagmyOrganizationExtranet=|myOrganizationIntranet
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" Variables 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" RegexTag=LBLSESSIONID
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" Variables 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" RegexTag=USERID
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" Variables 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.
Endpoints EndPointsGrouping groupName="es62prod" enable= "true" VirtualDomain loadBalancingType=Adaptative"" CMessage=MyOrganizationOverloadMessage".html" RewriteHeaderRules="VIP_EnableAccessOnNormalCondition;LAST VIP_EnableAdminSitesOnOverload;LAST VIP_EnablePaymentGatewaysOnOverload;LAST VIP_YellowOverloadEnableReqWithLBLSESSIONID;LAST VIP_OrangeOverloadEnableReqWithLBLSESSIONIDandUSERID;LAST VIP_DisableAccessOnOverload" Endp address=192.168.56.131"" port="8585" uriPath="/srv01" enable= "true" Endp address=192.168.56.131"" port="8585" uriPath="/srv02" enable= "true" Endp address=192.168.56.131"" 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->Www.onesite.com->/one is 20+12=32. For the group of services httpOne->Www.onesite.com->/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"" RewriteHeaderRules=compressionHEADER";ALWAYS" RewriteBodyRules=compressionBODY";ALWAYS" DoS/DDoSMaxConcurrentConnectionsReaction= "true" Enable= "true" VirtualDomain virtualDomainName=www.onesite.com"" DoS/DDoSMaxConcurrentConnectionsReaction= "true" enable= "true" Endp address=192.168.45.131"" port="8585" maxConcurrentConnections="20" uriPath="/one" Endp address=192.168.45.132"" port="8585" maxConcurrentConnections="12" uriPath="/one" Endp address=192.168.45.131"" port="8585" maxConcurrentConnections="11" uriPath="/two" Endp address=192.168.45.132"" 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.