Docs
Application Delivery Controller
DoS/DDoS attack mitigation setup

DoS/DDoS attack mitigation setup

Note prima dell'installazione

Oplon DoS/DDoS Attack Mitigation function è un modulo integrato opzionale del prodotto Oplon Application Delivery Controller ed è disponibile per tutte le distribuzioni.

La licenza Oplon DoS/DDoS Attack Mitigation function abilita quindi la funzionalità e non devono essere aggiunti moduli o librerie all'installazione Oplon Application Delivery Controller preesistente.

Essendo la suite Oplon S.A.A.I. un prodotto destinato ad ambienti mission-critical business-critical solo personale che ha effettuato il corso ed ha superato l'esame è autorizzato a certificare l'installazione e manutenzione dei prodotti in esercizio. Tutte le persone certificate sono dotate di documento rilasciato da Oplon NETWORKS SRL.

Oplon DoS/DDoS Attack Mitigation function

Oplon Application Delivery Controller integra un sistema di prevenzione attacchi Denial of Service & Distributed Denial of Service (DoS/DDoS) in grado di controllare e catalogare real-time le dinamiche di richiesta di servizio e la loro evoluzione. Tutte le connessioni che attraversano lo strato di bilanciamento vengono costantemente analizzate e catalogate identificando eventi anomali e attuando delle azioni a garanzia della continuità dei servizi.

DoS/DDoS congestion resolver

Il sistema è in grado di rilevare automaticamente attacchi coordinati provenienti da più fonti attuando tecniche di decongestione istantanea che liberano il servizio e lo rendono nuovamente disponibile. Questi attacchi sono difficilmente identificabili essendo posti in essere da innumerevoli sorgenti. Tipicamente sono il risultato di virus che una volta propagatosi su diversi vettori si attiva contemporaneamente rivolgendo il loro attacco verso un unico obiettivo. In ambito e-commerce gli stessi effetti si rilevano con una campagna marketing ben riuscita. Tipicamente una campagna promozionale viene promossa attraverso mailing list composta da centinaia di migliaia di indirizzi di posta elettronica. Se la campagna ha successo e l'offerta proposta è di interesse il sito viene raggiunto contemporaneamente da centinaia di migliaia di "click" (osservabile nel grafico a sinistra ed in alto). Al rilevamento della saturazione delle risorse di backend vengono attivate le difese attraverso decongenstione. Dalla versione 9 è possibile eseguire un capping delle richieste anche per singolo servizio aumentando ulteriormente la granularità di intervento.

DoS/DDoS address quarantine

La funzione DoS/DDoS address quarantine è in grado di identificare sofisticati tentativi di uso esclusivo delle risorse da parte di pochi soggetti. Questi ultimi vengono automaticamente riconosciuti ed esclusi ponendo gli indirizzi, fonte del disservizio, in "quarantena" per un periodo prefissato di tempo. Normalmente questi attacchi provengono infatti da indirizzi dinamici e quindi non inseribili su directory pubbliche di "liste nere". Scaduto il tempo di "quarantena" viene reso nuovamente possibile, all'indirizzo posto in quarantena, l'accesso ai servizi.

VIP iRedCarpet (Very Important People)

Ultima evoluzione, derivata dalle esperienze in ambito e-commerce, è la funzionalità VIP iRedCarpet. Questa funzionalità permette di discriminare, dal punto di vista applicativo, il traffico "utile" dal traffico "turistico" reagendo in maniera differente in dipendenza delle condizioni di traffico. Il sistema è stato studiato per privilegiare l'accesso delle connessioni in base alla tipologia del servizio richiesto, ad esempio privilegiando le connessioni che stanno eseguendo dei pagamenti oppure hanno già eseguito l'autenticazione al portale o, in ambito e-commerce, coloro che hanno il carrello carico rispetto a coloro che stanno navigando in sola consultazione. VIP iRedCarpet collabora con le funzionalità DoS/DDoS address quarantine e DoS/DDoS congestion resolver aumentando l'accessibilità ai servizi distinguendo le tipologie di navigazione Quality of Service Applicativa (AQoS).

Oplon DoS/DDoS Attack Mitigation function: Installazione licenza

Una volta avviata Oplon Secure Web-Based GUI ed effettuato il login al nodo, scegliere il module designato ad ospitare la funzionalità Oplon DoS/DDoS Attack Mitigation ed eseguire le operazioni di seguito elencate.

Se non siete in possesso di una licenza Oplon DoS/DDoS Attack Mitigation è possibile farne richiesta a Oplon NETWORKS SRL o ad un rivenditore autorizzato.

Selezionare il module nell'albero dei processi (Solitamente A10_LBLGo) nel quale si vuole installare la licenza Oplon DoS/DDoS Attack Prevention. Con il tasto destro del mouse selezionare Install license:

Selezionare la licenza opportuna che dovrà necessariamente chiamarsi license.xml.

Una volta confermata la licenza verrà visualizzato il risultato dell'upload. Se SUCCESSFULL passare al passo successivo

Oplon Application Delivery Controller Stop

Una volta installata con successo la licenza si dovrà procedere con il restart del module Oplon Application Delivery Controller. Per effettuare il restart del module Oplon Application Delivery Controller è sufficiente eseguire uno stop e quindi uno start:

E' possibile vedere l'evolvere della situazione attraverso Oplon Secure Web-Based GUI che evidenzia lo shutdown del processo...

Oplon Application Delivery Controller Start con DoS/DDoS Attack Mitigation function

Una volta che il module di bilanciamento si è arrestato è possibile procedere con lo Start module che all'avvio acquisirà la nuova licenza abilitando la funzionalità DoS/DDoS Attack Prevention.

Oplon DoS/DDoS function basic settings

Una volta installata la licenza Oplon DoS/DDoS Attack Mitigation function è possibile renderla operativa immediatamente attraverso i parametri generali della configurazione Oplon Application Delivery Controller attraverso la scelta D-DOS/DDOS nel menu del ADC Settings.

I parametri di seguito impostano le funzionalità di base del prodotto che sono quindi immediatamente fruibili per la produzione dando la possibilità di eseguire in seguito un tuning specifico.

Il parametro che abilita la funzionalità è DoS/DDoSAttackPrevention che per default è disabilitato e dovrà quindi essere impostato esplicitamente a "true". Un altro parametro importante è *DoS/DDoSAttackPreventionOnlyClose.* Questo parametro è per default impostato a true per sicurezza. La sua impostazione a "false" deve essere ragionata, infatti, una volta impostato a "false", se siamo in presenza di connessioni HTTP/S, al superamento della soglia Red Alert verrà restituita a tutti gli utenti una pagina di cortesia di overload. In ambienti mission-critical o business-critical, la pagina di cortesia può essere utilizzata da un attaccante come un segnale per cambiare strategia di attacco. Per questo motivo DoS/DDoSAttackPreventionOnlyClose è impostato per default a "true". Normalmente se non siamo in condizioni stringenti mission-critical e business-critical il parametro verrà impostato a "false".

DoS/DDoSAttackPrevention=: valore di default="false" boolean

Se impostato a true vengono applicate le regole di prevenzione di un attacco informatico di tipo DoS/DDoS (Denial of Service). DoS/DDoSAttackPrevention interviene in modalità diverse a seconda del tipo di attacco:

  1. Richieste multiple provenienti dallo stesso indirizzo IP

  2. Richieste multiple provenienti da diversi indirzzi IP

Nel primo caso al superamento di un numero definito di richieste contemporanee, impostabile con il parametro "DoS/DDoSMaxTunnelForClientAddress", queste vengono cancellate comprese le eventuali richieste pendenti nelle code interne.

Nel secondo caso al superamento della soglia highWaterDangerLevel tutte le richieste in corso e/pendenti nelle code vengono cancellate.

In entrambi i casi, prima della cancellazione delle richieste pendenti, se connessione in HTTP/S viene spedita una pagina di cortesia al client che ne ha fatto richiesta.

DoS/DDoSAttackPreventionOnlyClose=: valore di default="true"

Alla rilevazione di un attacco DoS/DDoS l'azione di default è chiudere i canali che si sono identificati come minaccia. Per alcuni protocolli è possibile ritornare l'indicazione della temporanea impossibilità di raggiungere il servizio con una pagina di cortesia. Questa indicazione potrebbe però essere utilizzata per perfezionare l'attacco e quindi è disabilitata per default.

Oplon DoS/DDoS function DoS/DDoS congestion resolver

La funzionalità DoS/DDoS congestion resolver si basa sull'osservazione continua del comportamento delle connessioni e delle richieste di connessione in attesa di essere prese in carico da un tunnel. È una funzionalità unica nel suo genere e resa possibile dal motore di forwarding a risorse finite alla base del prodotto Oplon Application Delivery Controller.

I valori di riferimento da tenere in considerazione sono rispettivamente il numero di tunnel di forwarding ed il numero di connessioni in attesa di essere collegate ad una risorsa di backend. Questi valori, in termini di parametri, sono rispettivamente concurrentSessions e maxConcurrentSessions.

concurrentSessions=: valore di default="50"

E' i numero di connessioni servibili contemporaneamente iniziali

maxConcurrentSessions=: valore di default="200"

E' il numero massimo di connessioni servibili contemporaneamente.

Normalmente in una installazione di produzione questi due valori sono identici e vengono fissati in base alle capacità di calcolo e risposta dei servizi di backend del datacenter es.:

concurrentSessions="2000"

maxConcurrentSessions="2000"

DoS/DDoS congestion resolver verifica ogni 50 millisecondi l'occupazione dei tunnel ed il numero delle richieste di connessione in coda di attesa. Se tutti i tunnels sono saturi e la coda di attesa supera il valore percentuale di occupazione indicato dal parametro highWaterWarningLevel (default 10.0%) rispetto al numero di tunnel impostati viene immediatamente avvisato tramite messaggio che è in atto un picco anomalo ma ancora non preoccupante. Il messaggio viene scritto nel log, riportato nel DB e, se impostata, notificata tramite e-mail.

Al raggiungimento o superamento del parametro highWaterDangerLevel Oplon DoS/DDoS congestion resolver esegue una close con flush di tutte le connessioni nei tunnel, dove previsto riporterà ai client eventuali pagine di cortesia e quindi ripristinerà il forwarding delle nuove richieste. È importante notare che la close dei canali avviene in maniera controllata specie nelle connessioni di backend. Il flush delle connessioni è importantissimo in quanto permette ai servizi di backend di chiudere correttamente i file descriptor aperti dagli application server e di liberare effettivamente le risorse. Nell'immagine a destra un esempio reale di superamento della soglia Danger Level ed immediata risoluzione dell'evento.

I parametri per impostare le soglie sono quindi highWaterWarningLevel e highWaterDangerLevel di cui riportiamo di seguito le descrizioni disponibili anche nella Reference Guide.

highWaterWarningLevel=: valore di default="10.0" UM=%

E' la percentuale soglia di connessioni in attesa di essere prese in carico da un esecutore del pool di forwarding. Se viene superata questa soglia il sistema avvisa con un messaggio specifico (yellow-alert) l'avvenuto superamento del limite. Se il limite viene superato vengono istanziate inoltre nuove sessioni di forwarding fino al raggiungimento del "maxConcurrentSessions".

highWaterDangerLevel=: valore di default="70.0" UM=%

E' la percentuale soglia di connessioni in attesa di essere prese in carico da una sessione di forwarding. Se viene superata questa soglia il sistema avvisa con un messaggio specifico (red-alert) l'avvenuto superamento del limite. Se il limite viene superato vengono istanziate inoltre nuove sessioni di forwarding fino al raggiungimento del "maxConcurrentSessions". Con Oplon DoS/DDoS Attack Mitigation function se viene raggiunto questo limite il sistema esegue le procedure DoS/DDoS Congestion Resolver

Oplon DoS/DDoS function DoS/DDoS address in quarantine

Uno degli attacchi DoS/DDoS più frequenti avviene ad opera di pochi o addirittura un solo attacker. L'utilizzo di black-list statiche su directory pubblici è assolutamente sconsigliato in quanto normalmente un attacco di questo tipo non avviene da indirizzi statici ma da indirizzi dinamici e quindi bloccare l'indirizzo in maniera permanente significherebbe non aver ottenuto il risultato o peggio aver precluso da quell'indirizzo un possibile contatto in futuro. Cosa peggiore se l'indirizzo di provenienza è un'organizzazione, si vedrebbe preclusa da quell'organizzazione, per sempre, la possibilità di accedere ai propri servizi.

Oplon DoS/DDoS address in quarantine verifica ogni 50 millisecondi il numero di connessioni che stanno attraversando lo strato di instradamento con lo stesso indirizzo. Se viene superata la soglia descritta nel parametro DoS/DDoSMaxTunnelForClientAddress l'indirizzo viene catalogato in una tabella all'interno del bilanciatore. Tutte le connessioni provenienti da quell'indirizzo verranno immediatamente cancellate e per le connessioni in arrivo verranno attuate le politiche di avviso di cortesia o redirect se impostate altrimenti anche quelle richieste di connessione verranno cancellate. Per quell'indirizzo verrà negato l'accesso ai servizi per un tempo predeterminato dal parametro DoS/DDoSAddressQuarantineTime, normalmente impostato a 30' (minuti). Allo scadere del tempo verrà data nuovamente la possibilità di richiedere servizi all'indirizzo precedentemente bloccato. Se dovesse ripresentarsi il problema l'indirizzo verrà nuovamente messo in quarantena.

DoS/DDoSMaxTunnelForClientAddress=: valore di default="100" UM=richieste nel tunnel

Indica la soglia come numero di richieste servite contemporaneamente per singolo indirizzo IP di provenienza. Se questa soglia viene superata tutte le connessioni instaurate provenienti dallo stesso IP verranno istantaneamente cancellate. Se HTTP/S a tutte le connessioni in attesa nella coda di richieste verrà invece risposto con il messaggio di cortesia (DoS/DDoSCMessage) oppure ridirezionate in base al parametro (DoS/DDoSRedirect).

DoS/DDoSAddressQuarantineTime=: valore di default="1800000" UM=milliseconds

All'individuazione di un attacco proveniente da un singolo indirizzo ip questi viene automaticamente posto in quarantena impedendo l'accesso ai servizi. Il tempo di quarantena è determinato da questo valore (30'). Superato questo tempo è data nuovamente la possibilità al client di accedere ai servizi. Se questo valore è impostato a 0 o

< di 0 la funzionalità di quarantena viene disabilitata.

Oplon DoS/DDoS function DoS/DDoS courtesy message

Se il parametro DoS/DDoSAttackPreventionOnlyClose è stato impostato a false le richieste di servizio HTTP/S "tagliate" riceveranno un messaggio di cortesia con l'indicazione di ritentare più tardi per overload di richieste. Il messaggio di cortesia è modificabile dall'utilizzatore. Oplon Application Delivery Controller, se non modificato, riporterà la seguente pagina html:

E' possibile modificare anche il nome della pagina di overload di default attraverso il parametro DoS/DDoSCMessage come descritto di seguito.

DoS/DDoSCMessage=: valore di default="messageServicesOverload.html"

Indica la pagina di cortesia da esporre in caso di attivazione del DoS/DDoS Attack Prevention.

Se si vuole modificare la pagina di cortesia è sufficiente estrarre dal file compresso (LBL_HOME)/lib/lblApplication Delivery Controller.jar il file:

Application Delivery Controller/resources/html/ messageServicesOverload.html e posizionarlo in

(LBL_HOME)/lib/Application Delivery Controller/resources/html. Una volta posizionato il file è possibile modificarlo anche durante il runtime. Questo parametro viene preso in considerazione se DoS/DDoSAttackPreventionOnlyClose è impostato a false.

Oplon DoS/DDoS function DoS/DDoS redirect

In alternativa al messaggio di cortesia, se la connessione è HTTP/S, è possibile indicare al client di eseguire un redirect verso un altro sito/servizio. Questa funzionalità permette di eseguire attività diversificate durante un attacco o ad un improvviso picco di richieste. Capita infatti sempre più spesso che la congestione non sia dovuta a veri attacchi ma da campagne marketing ben riuscite con un altissimo rating di sottoscrizione alla campagna. La possibilità di dirottare le richieste su un altro sito per dar seguito alla richiesta o più semplicemente una ridirezione ad una pagina che proponga una promozione aggiuntiva se il cliente decidesse di ritornare in un secondo momento, possono essere validi strumenti per il marketing che può quindi offrire ai clienti un canale di comunicazione e fidelity importante.

Per impostare il redirect di seguito la descrizione del parametro.

DoS/DDoSRedirect=: valore di default= ""

Se valorizzato indica l'URI a cui ridirigere la richiesta in caso di attivazione del DoS/DDoS Attack Prevention. es.: http://www.caugthinfo.com/ (opens in a new tab)

Se questo valore viene impostato ha priorità rispetto al parametro DoS/DDoSCMessage. Questo parametro viene preso in considerazione se DoS/DDoSAttackPreventionOnlyClose è impostato a false.

Oplon DoS/DDoS function VIP iRedcarpet AQoS (Application Quality of Service)

Oplon VIP iRedCarpet nasce dall'esperienza fatta in questi anni nelle tematiche DoS/DDoS Attack Mitigation ed è una importante evoluzione delle politiche QoS orientate alle componenti applicative AQoS (Application Quality of Service). Oplon VIP iRedCarpet agisce nel contesto globale delle funzionalità Oplon DoS/DDoS attack prevention ma entra nel merito delle singole richieste di servizio per determinare il privilegio di accessibilità in momenti di particolare carico. È possibile ad esempio distinguere le conferme degli ordini di acquisto provenienti dai gestori di carte di credito e quindi privilegiarne il passaggio, è possibile distinguere gli utenti che hanno già caricato il carrello da altri che stanno solamente effettuando una visita di verifica e quindi privilegiare il passaggio dei primi e invitare i secondi a ritentare più tardi.

Queste politiche di privilegio di accesso ai servizi è possibile effettuarle attraverso regole di rewriting che ne descrivono le dinamiche. Le regole possono essere strutturate per limitare selettivamente le richieste in base all'innalzarsi del carico fino ad arrivare a mantenere aperti i servizi per le sole richieste assolutamente indispensabili e critiche.

Normalmente la prima regola da impostare è la regola che permette in condizioni normali di far passare tutte le richieste in arrivo. È importante notare che questa regola, essendo la prima, è anche l'ultima ad essere eseguita se si verifica la condizione, infatti, con il comando EnableAccessOnNormalCondition seguito con LAST (EnableAccessOnNormalCondition;LAST) induce il rewriter Oplon Application Delivery Controller a non applicare altre regole al verificarsi della condizione di normalità.

La regola di seguito può essere utilizzata come template per identificare un livello di accodamento delle richieste giudicato nella norma. Il livello delle richieste in coda, anche in momenti di forte carico, rimane normalmente molto vicino allo zero (0). La INNERVAR HIGH_WATER_LEVEL, messa a disposizione del rewriter dalla funzionalità Oplon DoS/DDoS attack prevention, permette di leggere il numero delle richieste in attesa di forwarding durante la singola richiesta. Con la funzionalità <numOperatorTag> è possibile eseguire confronti numerici e quindi condizionare l'azione ad un valore. Le azioni permesse da <numOperatorTag> sono:

eq=equal

neq=not equal

gt=greater than

geq=greater equal

lt=less than

leq=less equal

Esistono già i template disponibili con tutti i parametri preimpostati:

Altre INNERVAR messe a disposizione dal rewiter con la funzionalità Oplon DoS/DDoS Attack Mitigation per condizionare le richieste di servizio sono:

HIGH_WATER_YELLOW_WARNING_REACHED = se true è stata superata la soglia Yellow Warning. Indica quindi un carico rilevante ma non ancora critico.

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")

MAX_TUNNEL_SESSIONS_SIZE= Maximum number of tunnels set.

Se il livello di carico considerato "normale" dalla prima regola dovesse essere superato si passerà quindi a verificare la richiesta nel suo dettaglio per determinare il privilegio di passaggio oppure fermarla istantaneamente.

Le due regole di seguito indicano ad esempio che per carichi superiori al 10 (gt 10) le conferme di pagamento delle carte di credito e gli accessi provenienti dall'organizzazione stessa, interni ed esterni, vengono in ogni caso privilegiati.

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"
                  regexTagmyOrganizationExtranet

Se le condizioni alle regole precedenti non dovessero essere soddisfatte allora si procederebbe con la regola successiva che può essere soddisfatta con un livello di accodamento dal 10% al 39%. In questo caso per coloro che si erano già connessi precedentemente e che hanno ricevuto una sessione da Oplon Application Delivery Controller viene permesso l'accesso ai servizi di backend.

Questo ovviamente è solo un esempio, è possibile condizionare il privilegio al passaggio su qualsiasi altro indicatore come un cookie generato dall'applicazione, un URI path, un 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 property

Se tutte le regole precedenti non dovessero essere soddisfatte ed il livello di carico dovesse essere uguale o superiore al 40% (geq 40) gli utenti che hanno eseguito un'autenticazione nel portale continuerebbero comunque liberamente a navigare attraverso i servizi.

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

Nel caso nessuna delle regole precedenti sia stata soddisfatta, con un livello di accodamento superiore al 10% tutte le richieste di servizio verranno invece tagliate (connectionToCut connectionToCut="true"), close dei canali, pagina di cortesia o 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"

Nelle pagine precedenti abbiamo visto come descrivere le regole di filtro delle richieste in dipendenza dei livelli di accodamento causati dal carico di richieste. Di seguito vedremo come applicare le regole a livello di flussi e cioè applicare le regole sopra descritte ai gruppi di servizi. È da notare il modificatore di comportamento ;LAST che al verificarsi della condizione descritta nella regola non esegue le regole successive rimanenti. In questo caso applicato il ;LAST in ogni regola, la prima che soddisfa le condizioni viene eseguita senza continaure nella verifica ed esecuzione delle rimanenti.

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

Dalla release 9 Oplon Application Delivery Controller, Oplon DoS/DDoS Attack Mitigation si arricchisce della possibilità di impostare un livello massimo di utilizzo dei servizi di backend. È possibile infatti impostare per singolo raggruppamento di servizi un numero massimo di connessioni. Questo valore è determinato dalla somma del numero massimo di connessioni per quel servizio descritto negli endp che lo compongono. Ad esempio per endPointsGrouping -> virtualDomain -> URIpath la capacità massima di elaborazione del servizio httpOne -> www.onesite.com (opens in a new tab) -> one è 20+12=32. Per il gruppo di servizi httpOne -> www.onesite.com (opens in a new tab) -> two sarà 11+56=67.

Questa fuzionalità è attivabile attraverso il parametro DoS/DDoSMaxConcurrentConnectionsReaction="true", altrimenti il comportamento rimane il default e cioè il solo log dell'evento.

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 conclusioni

Oplon DoS/DDoS Attack Mitigation è una funzionalità a valore aggiunto che nel tempo è stata migliorata fino al raggiungimento delle sofisticate caratteristiche che oggi possono essere messe a disposizione del mercato.

L'effetto di quanto descritto in questi paragrafi, misurabile in tempo reale attraverso Oplon Management Console, è possibile apprezzarlo dalle seguenti immagini. Le immagini sono relative ad una situazione reale della grande distribuzione e-commerce. A tre invii consecutivi di e-mail promozionali i consumatori che hanno risposto immediatamente all'invito sono stati diverse decine di migliaia (120.000 nell'arco di due ore circa). Al primo invio Oplon VIP iRedCarpet ha rilevato l'evento di carico eccessivo che ha immediatamente risolto senza "tagliare" le connessioni di business in corso preservando il funzionamento dei servizi di backend e della base dati.

Oplon DoS/DDoS Attack Mitigation è ad oggi l'unica piattaforma che riesce a filtrare dinamicamente le richieste di servizio in dipendenza dei carichi e dal servizio applicativo richiesto realizzando uno strumento di Quality of Service Applicativa senza eguali oggi sul mercato.

EC2 SetupACME SSL (Let's Encrypt)