DoS/DDoS attack mitigation setup
Notes before installation
Oplon DoS/DDoS Attack Mitigation function is an optional integrated product module Oplon Application Delivery Controller It is available for all deployments.
The license Oplon DoS/DDoS Attack Mitigation function therefore enables the feature and no modules or libraries should be added to the installation Oplon Application Delivery Controller.
Being the suite Oplon S.A.A.I. a product intended for business-critical mission-critical environments only staff who have completed the course and passed the exam are authorized to certify the installation and maintenance of the products in operation. All certified persons have a document issued by Oplon NETWORKS SRL.
Oplon DoS/DDoS Attack Mitigation function
Oplon Application Delivery Controller integrates an attack prevention system Denial of Service & Distributed Denial of Service (DoS/DDoS) able to control and catalog real-time the dynamics of service request and their evolution. All connections that cross the balance layer are constantly analyzed and catalogued identifying anomalous events and implementing actions to ensure the continuity of services.
DoS congestion resolver
The system is able to automatically detect coordinated attacks from multiple sources by implementing instant decongestion techniques that free up the service and make it available again. These attacks are difficult to identify as being put in place by countless sources. Typically they are the result of viruses that once propagated over different vectors activates simultaneously by directing their attack towards a single target. In e-commerce, the same effects are achieved with a successful marketing campaign. Typically, a promotional campaign is promoted through a mailing list consisting of hundreds of thousands of email addresses. If the campaign is successful and the proposed offer is of interest the site is reached at the same time by hundreds of thousands of "clicks" (observable in the graph on the left and top). Defenses are activated through decongencenion when backend resource saturation is detected. From version 9, you can also cap requests for a single service, further increasing the granularity of the response.
DoS address quarantine
The DoS/DDoS address quarantine function can identify sophisticated attempts at resource-only use by a few individuals. The latter are automatically recognized and excluded by placing the addresses, the source of the disservice, in "quarantine" for a fixed period of time. Normally these attacks come from dynamic addresses and therefore cannot be placed on public directories of "blacklists". Once the "quarantine" time is over, access to the services is made possible again at the quarantined address.
VIP iRedCarpet (Very Important People)
Latest evolution, derived from e-commerce experiences, is the iRedCarpet VIP feature. This feature allows to discriminate, from an application point of view, the "useful" traffic from "tourist" traffic reacting differently depending on traffic conditions. The system has been designed to prioritize connection access based on the type of service required, for example by prioritizing connections that are making payments or have already authenticated to the portal or, in e-commerce, those who have the loaded cart over those who are browsing in consultation only. VIP iRedCarpet collaborates with DoS/DDoS address quarantine and DoS/DDoS congestion resolver increasing accessibility to services by distinguishing the types of Application Quality of Service (AQoS) navigation.
Oplon DoS/DDoS Attack Mitigation function License Installation
Once started Oplon Secure Web-Based GUI and logged in to the node, choose the module designated to host the feature Oplon DoS/DDoS Attack Mitigation perform the following steps.
If you do not have a license Oplon DoS/DDoS Attack Mitigation you can request it from Oplon NETWORKS SRL or an authorized reseller.
Select the module in the process tree
(Usually A10_LBLGo) in which you want to install the license
Oplon DoS/DDoS Attack Prevention. Right-click install license:
Select the appropriate license that you will need to call license.xml.
Once the license is confirmed, the result of the upload will be displayed. If SUCCESSFULL move to the next step
Oplon Application Delivery Controller Stop
Once the license has been successfully installed, you will need to proceed with the restart of the module Oplon Application Delivery Controller. To restart the module Oplon Application Delivery Controller simply stop and then start:
It is possible to see the situation evolve through Oplon Secure Web-Based GUI highlighting the shutdown of the process...
Oplon Application Delivery Controller Start with DoS/DDoS Attack Mitigation function
Once the balancing module has stopped, you can proceed with the Start module, which will acquire the new license at startup by enabling doS/DDoS Attack Prevention.
Oplon DoS/DDoS function basic settings
Once the license is installed Oplon DoS/DDoS Attack Mitigation function you can make it operational immediately through the general configuration parameters Oplon Application Delivery Controller D-DOS/DDOS in the ADC Settings menu.
The parameters below set the basic product features that are then immediately usable for production, giving you the ability to perform a specific tuning later.
The parameter that enables the feature is DoS/DDoSAttackPrevention it is disabled by default and must be explicitly set to "true". Another important parameter is DoS/DDoSAttackPreventionOnlyClose. This parameter is set to true by default for security. Its setting to "false" must be reasoned, in fact, once set to "false", if we are in the presence of HTTP/S connections, when exceeding the Red Alert threshold will be returned to all users an overloaded courtesy page. In mission-critical or business-critical environments, the courtesy page can be used by an attacker as a signal to change attack strategy. That's why DoS/DDoSAttackPreventionOnlyClose is set to "true" by default. Normally if we are not in strict mission-critical and business-critical conditions the parameter will be set to "false".
DoS/DDoSAttackPrevention: default value "false" Boolean
If set to true, the rules for preventing a cyberattack of type DoS/DDoS (Denial of Service) are applied. DoS/DDoSAttackPrevention takes action in different ways depending on the type of attack:
-
Multiple requests from the same IP address
-
Multiple requests from different IP addresses
In the first case when a defined number of concurrent requests, which can be set with the "DoS/DDoSMaxTunnelForClientAddress" parameter, are cleared, including any pending requests in the internal queues.
In the second case, when the highWaterDangerLevel threshold is exceeded, all in-progress and/or pending requests in the queues are cleared.
In both cases, a courtesy page is sent to the client that requested it before the pending requests are deleted, if the connection in HTTP/S is sent to the client that requested it.
DoS/DDoSAttackPreventionOnlyClose: default value "true"
When a DoS/DDoS attack is detected, the default action is to close channels that have identified themselves as a threat. For some protocols, it is possible to return the temporary impossibility of reaching the service with a courtesy page. However, this indication could be used to refine the attack and is therefore disabled by default.
Oplon DoS/DDoS function DoS/DDoS congestion resolver
The feature DoS congestion resolver is based on continuous observation of connection behavior and connection requests waiting to be taken over by a tunnel. It is a one-of-a-kind feature made possible by the finished resource forwarding engine at the base of the product Oplon Application Delivery Controller.
The benchmarks to be taken into account are the number of forwarding tunnels and the number of connections waiting to be linked to a backend resource. These values, in terms of parameters, are, respectively, concurrentSessions And maxConcurrentSessions.
concurrentSessions: default value "50"
This is the number of connections that can be serviced at the same time
maxConcurrentSessions: default value "200"
This is the maximum number of connections that can be serviced at the same time.
Normally in a production installation these two values are identical and are set based on the computing and response capabilities of the backend services of the datacenter e.g.:
concurrentSessions="2000"
maxConcurrentSessions="2000"
DoS congestion resolver checks the tunnel occupancy and the number of connection requests in the queue every 50 milliseconds. If all tunnels are saturated and the queue wait exceeds the employment percentage value indicated by the highWaterWarningLevel property (default 10.0%) compared to the number of tunnels set up is immediately notified by message that an abnormal but still not worrying peak is taking place. The message is written to the log, reported in the DB and, if set, notified by email.
When the parameter is reached or exceeded highWaterDangerLevel property Oplon DoS/DDoS congestion resolver performs a close with flush of all connections in the tunnels, where expected will report any courtesy pages to the clients and then restore the forwarding of new requests. It is important to note that the close of channels occurs in a controlled manner especially in backend connections. Connection flushing is very important because it allows backend services to properly close descriptor files opened by application servers and actually free up resources. In the image on the right, a real-world example of exceeding the Danger Level threshold and immediately resolving the event.
The parameters for setting the thresholds are then highWaterWarningLevel property And highWaterDangerLevel property below are the descriptions also available in the Reference Guide.
highWaterWarningLevel: default value "10.0" UM-%
This is the threshold percentage of connections waiting to be taken over by a forwarding pool performer. If this threshold is exceeded, the system warns with a specific message (yellow-alert) that the limit has been exceeded. If the limit is exceeded, new forwarding sessions are also instantiated until the "maxConcurrentSessions" is reached.
highWaterDangerLevel: default value "70.0" UM-%
This is the threshold percentage of connections waiting to be taken over by a forwarding session. If this threshold is exceeded, the system warns with a specific message (red-alert) that the limit has been exceeded. If the limit is exceeded, new forwarding sessions are also instantiated until the "maxConcurrentSessions" is reached. With Oplon DoS/DDoS Attack Mitigation function If this limit is reached, the system performs the procedures DoS/DDoS Congestion Resolver
Oplon DoS/DDoS address in quarantine
One of the most frequent DoS/DDoS attacks is by a few or even one attacker. The use of static black-lists on public directories is absolutely not recommended because normally such an attack does not occur from static addresses but from dynamic addresses and therefore blocking the address permanently would mean not having obtained the result or worse having foreclosed from that address a possible contact in the future. Worst of all, if the address of origin is an organization, you would see that organization foreclosed on the possibility of accessing its services forever.
Oplon DoS/DDoS address in quarantine checks every 50 milliseconds how many connections are going through the routing layer with the same address. If the threshold described in the parameter DoS/DDoSMaxTunnelForClientAddress the address is cataloged in a table within the load balancer. All connections from that address will be immediately deleted and for incoming connections, courtesy or redirect warning policies will be implemented if set otherwise those connection requests will also be deleted. That address will be denied access to the services for a predetermined time by the parameter DoS/DDoSAddressQuarantineTime, normally set to 30' (minutes). When the time runs out, you will be given the option to request services again at the previously blocked address. If the problem occurs again, the address will be quarantined again.
DoS/DDoSMaxTunnelForClientAddress: default value "100"UM-requests in the tunnel
Indicates the threshold as the number of requests served at the same time per source IP address. If this threshold is exceeded, all connections established from the same IP will be instantly deleted. If HTTP/S is answered by all connections waiting in the request queue, the courtesy message (DoS/DDoSCMessage) will be answered or redirected by parameter (DoS/DDoSRedirect).
DoS/DDoSAddressQuarantineTime: default value "1800000" UM-milliseconds
When an attack from a single IP address is detected, they are automatically quarantined and prevented from accessing the services. Quarantine time is determined by this value (30'). After this time is given again the ability to access the services. If this value is set to 0 or a set of 0, the quarantine feature is disabled.
Oplon DoS/DDoS function
If the parameter DoS/DDoSAttackPreventionOnlyClose has been set to false HTTP/S service requests "cut" will receive a courtesy message with the indication to retry later for overloads of requests. The courtesy message is editable by the user. Oplon Application Delivery Controller, if not modified, it will show the following html page:
You can also change the default overloaded page name through the DoS/DDoSCMessage as described below.
DoS/DDoSCMessage: default value**"messageServicesOverload.html"**
Indicates the courtesy page to display when activating the DoS/DDoS Attack Prevention.
If you want to change the courtesy page, simply extract the file from the compressed file (LBL_HOME)/lib/lblApplication Delivery Controller.jar:
Application Delivery Controller/resources/html/ messageServicesOverload.html and place it in
(LBL_HOME)/lib/Application Delivery Controller/resources/html. Once the file is positioned, you can also edit it during runtime. This parameter is taken into account if DoS/DDoSAttackPreventionOnlyClose is set to false.
Oplon DoS/DDoS function: DoS/DDoS redirect
As an alternative to the courtesy message, if the connection is HTTP/S, you can instruct the client to redirect to another site/service. This feature allows you to perform diversified tasks during an attack or a sudden spike in requests. In fact, it happens more and more often that congestion is not due to real attacks but from successful marketing campaigns with a very high rating of subscription to the campaign. The ability to divert requests to another site to follow up the request or more simply a redirect to a page that proposes an additional promotion if the customer decides to return later, can be valid marketing tools that can then offer customers an important communication channel and fidelity.
To set the redirect below the description of the parameter.
DoS/DDoSRedirect: default value ""
If valued, indicates the URI to redirect the request to when the DoS/DDoS Attack Prevention is activated. Es.: http://www.caugthinfo.com/ (opens in a new tab)
If this value is set, it has priority over the DoS/DDoSCMessage parameter. This parameter is taken into account if DoS/DDoSAttackPreventionOnlyClose is set to false.
Oplon DoS/DDoS function VIP iRedcarpet AQoS, New (Application Quality of Service)
Oplon VIP iRedCarpet It comes from the experience of DoS/DDoS Attack Mitigation in recent years and is an important evolution of QoS policies oriented to application components AQoS (Application Quality of Service). Oplon VIP iRedCarpet acts in the global context of the features Oplon DoS/DDoS attack prevention But it goes into the merits of individual service requests to determine accessibility privilege at times of particular load. For example, you can distinguish purchase order confirmations from credit card managers and then prefer to switch, you can distinguish users who have already loaded the cart from others who are only performing a verification visit, and then prefer the passage of the former and invite the latter to try again later.
These service access privilege policies can be made through rewriting rules that describe their dynamics. The rules can be structured to selectively limit requests based on the load rise until they keep the services open for the only requests that are absolutely essential and critical.
Normally the first rule to be set is the rule that allows under normal conditions to pass all incoming requests. It is important to note that this rule, being the first, is also the last to be executed if the condition occurs, in fact, with the command EnableAccessOnNormalCondition property followed with LAST (EnableAccessOnNormalCondition; LAST) induces the rewriter Oplon Application Delivery Controller not to apply other rules when the normal condition occurs.
The rule below can be used as a template to identify a level of queue of
requests judged in the standard. The level of queued requests, even at
times of heavy load, normally remains very close to zero (0). THE
INNERVAR HIGH_WATER_LEVEL, made available to the rewriter by the
Oplon DoS/DDoS attack prevention, allows you to read the number of
requests waiting for forwarding during the single request. With the
<numOperatorTag\> feature, you can perform numeric comparisons and then
condition the action to a value. The actions allowed by
<numOperatorTag\> are:
eq=equal
neq=not equal
gt=greater than
geq=greater equal
lt=less than
leq=less equal
Templates already exist with all preset parameters:
Other INNERVARs made available by the rewiter with the feature Oplon DoS/DDoS Attack Mitigation to affect service requests are:
HIGH_WATER_YELLOW_WARNING_REACHED If true has exceeded the Yellow threshold Warning. It therefore indicates a relevant load but not still critical.
HIGH_WATERNumber 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_ACTIVEInstant active tunnels, int format.
TUNNEL_SESSIONS_COMMITTEDInstant tunnel committed, (subset of TUNNEL_SESSIONS_ACTIVE")
ACTUAL_TUNNEL_SESSIONS_SIZEThe actual size of tunnels: (usually equal to "MAX_TUNNEL_SESSIONS_SIZE")
MAX_TUNNEL_SESSIONS_SIZEMaximum number of tunnels set.
If the load level considered "normal" by the first rule were to be exceeded, then the request will be checked in detail to determine the privilege of passage or stop it instantly.
For example, the following two rules indicate that for loads greater than 10 (gt 10) credit card payment confirmations and access from the organization itself, internal and external, are in any case privileged.
rewriteHeaderRule property name property="VIP_EnablePaymentGatewaysOnOverload" flow="REQUEST function" caseSensitive="True"
variables, New10
Var Varname="highWaterLevel property" name property="HIGH_WATER_LEVEL" from="INNERVAR, NEW"
conditions operator="AND"
Cond from="VARIABLE, NEW10" name property="highWaterLevel property" >
numOperatorTaggt 10
Cond from="INNERVAR, NEW" name property="REQUEST_HTTP_URI_PATH"
regexTagPayPalReturn XPayFOLightReturn ReceiveAgos, New100014
rewriteHeaderRule property name property="VIP_EnableAdminSitesOnOverload" flow="REQUEST function" caseSensitive="True"
variables, New10
Var Varname="highWaterLevel property" name property="HIGH_WATER_LEVEL" from="INNERVAR, NEW"
conditions operator="AND"
Cond from="VARIABLE, NEW10" name property="highWaterLevel property"
numOperatorTaggt 10
Cond from="INNERVAR, NEW" name property="REQUEST_HTTP_URI_PATH"
regexTagmyOrganizationExtranetIf the conditions in the previous rules were not met then the next rule would be followed by the next rule, which can be met with an append level of 10% to 39%. In this case for those who had already previously logged in and who received a session from Oplon Application Delivery Controller access to backend services is allowed.
This is obviously just one example, you can condition the privilege to pass on any other indicator such as an application-generated cookie, a path URI, a referer etc.
rewriteHeaderRule property name property="VIP_YellowOverloadEnableReqWithLBLSESSIONID" flow="REQUEST function"
caseSensitive="False"
variables, New10
Var Varname="highWaterLevel property" name property="HIGH_WATER_LEVEL" from="INNERVAR, NEW"/>
conditions operator="AND"
Cond from="VARIABLE, NEW10" name property="highWaterLevel property"
numOperatorTaggeq 10
Cond from="VARIABLE, NEW10" name property="highWaterLevel property"
numOperatorTaglt 40
Cond from="INNERVAR, NEW" name property="REQUEST_HTTP_COOKIES_LIST"
regexTagLBLSESSIONID propertyIf all the above rules are not met and the load level is 40% or higher (geq 40) users who have authenticated in the portal would still freely navigate through the services.
rewriteHeaderRule property name property="VIP_OrangeOverloadEnableReqWithLBLSESSIONIDandUSERID" flow="REQUEST function"
caseSensitive="False"
variables, New10
Var Varname="highWaterLevel property" name property="HIGH_WATER_LEVEL" from="INNERVAR, NEW"
conditions operator="AND"
Cond from="VARIABLE, NEW10" name property="highWaterLevel property"
numOperatorTaggeq 40
Cond from="INNERVAR, NEW" name property="REQUEST_HTTP_COOKIES_LIST"
regexTagUserid
If none of the above rules have been met, with an append level of more than 10% all service requests will be cut (connectionToCut property connectionToCut property="True"), channel close, courtesy page or redirect.
rewriteHeaderRule property name property="VIP_DisableAccessOnOverload" flow="REQUEST function" caseSensitive="True"
variables, New10
Var Varname="highWaterLevel property" name property="HIGH_WATER_LEVEL" from="INNERVAR, NEW"
conditions operator="AND"
Cond from="VARIABLE, NEW10" name property="highWaterLevel property"
numOperatorTaggt 10
connectionToCut property connectionToCut property="True"In the previous pages, we've seen how to describe request filtering rules that are dependent on queuing levels caused by request load. Below we'll look at how to apply rules at the flow level and that is apply the rules described above to service groups. The behavior modifier is noteworthy ; Last That when the condition described in the rule does not run the remaining subsequent rules. In this case applied the ; LAST in each rule, the first one that meets the conditions is executed without continaure in the verification and execution of the remaining.
endpoints
endPointsGrouping property Groupname="es62prod" Enable="True"
virtualDomain, New1001 loadBalancingType property="Adaptive"
cMessage property="MyOrganizationOverloadMessage.html"
rewriteHeaderRules property="VIP_EnableAccessOnNormalCondition; Last
VIP_EnableAdminSitesOnOverload; Last
VIP_EnablePaymentGatewaysOnOverload; Last
VIP_YellowOverloadEnableReqWithLBLSESSIONID; Last
VIP_OrangeOverloadEnableReqWithLBLSESSIONIDandUSERID; Last
VIP_DisableAccessOnOverload"
endp property address="192.168.56.131" Port="8585" uriPath property="/srv01" Enable="True"
endp property address="192.168.56.131" Port="8585" uriPath property="/srv02" Enable="True"
endp property address="192.168.56.131" Port="8585" uriPath property="/srv03" Enable="True"Oplon DoS/DDoS function DoS/DDoS congestion resolver service capping
Release 9 Oplon Application Delivery Controller, Oplon DoS/DDoS Attack Mitigation is enhanced by the ability to set a maximum level of use of backend services. You can set up a maximum number of connections for a single grouping of services. This value is determined by the sum of the maximum number of connections for that service described in the endps that compose it. For example, for endPointsGrouping-> virtualDomain->URIpath the maximum processing capacity of the httpOne -> www.onesite.com (opens in a new tab) -> one service is 20.12.32. For the service group httpOne -> www.onesite.com (opens in a new tab) -> two will be 11-56-67.
This futionivity can be activated through the parameter DoS/DDoSMaxConcurrentConnectionsReaction-"true", otherwise the behavior remains the default, that is, the only log of the event.
endPointsGrouping property Groupname="httpOne"
rewriteHeaderRules property="compressionHEADER; ALWAYS, New10"
rewriteBodyRules property="compressionBODY; ALWAYS, New10"
DoS/DDoSMaxConcurrentConnectionsReaction="True"
Enable="True"
virtualDomain, New1001 virtualDomainName property="www.onesite.com"
DoS/DDoSMaxConcurrentConnectionsReaction="True" Enable="True"
endp property address="192.168.45.131" Port="8585" maxConcurrentConnections property="20" uriPath property="/one"
endp property address="192.168.45.132" Port="8585" maxConcurrentConnections property="12" uriPath property="/one"
endp property address="192.168.45.131" Port="8585" maxConcurrentConnections property="11" uriPath property="/two"
endp property address="192.168.45.132" Port="8585" maxConcurrentConnections property="56" uriPath property="/two"Oplon DoS/DDoS function conclusions
Oplon DoS/DDoS Attack Mitigation it is a value-added feature that over time has been improved until the sophisticated features that can be made available to the market today.
The effect of what is described in these paragraphs, measurable in real time through Oplon Management Console, you can appreciate it from the following images. The images are related to a real situation of the large ecommerce distribution. At three consecutive promotional e-mails, the consumers who immediately responded to the invitation were several tens of thousands (120,000 in the space of about two hours). On first submission Oplon VIP iRedCarpet detected the excessive load event that immediately resolved without "cutting" the ongoing business connections while preserving the operation of the backend services and the database.
Oplon DoS/DDoS Attack Mitigation it is currently the only platform that can dynamically filter service requests in load dependency and the application service required by creating an Application Quality of Service tool unparalleled today on the market.