LBL Secure Application Availability Infrastructure

Back

La soluzione LBL S.A.A.I. offre una suite di prodotti progettati per aumentare l’alta affidabilità delle infrastrutture e la disponibilità dei servizi applicativi. Piattaforma nata per ambienti di Virtualizzazione on-premise e Cloud. Nel 2012 nasce in California anche TCO Software Group Inc. allo scopo di promuovere il mercato in USA e poter collaborare strettamente con le aziende della Silicon Valley.

  1. La soluzione LBL S.A.A.I.

LBL Secure Application Availability Infrastructure è una soluzione nata per risolvere quelle che oggi sono le problematiche di instradamento e security e gestire i processi di continuità operativa quali Business Continuity, Disaster Recovery.

Cuore della soluzione è LBL Application Delivery Controller uno strumento di bilanciamento del traffico di trasmissione dati a livello 4 OSI e a livello applicativo 7 OSI (HTTP/S-DNS) con caratteristiche di session affinity (aka sticky session e load balancer managed session) in grado di assicurare una elevata scalabilità sui moderni sistemi multiprocessore e sui sistemi con processori multithread. Dal punto di vista architetturale il posizionamento di questo strumento è come Full Reverse Proxy andando ad inserire uno strato per gestire le molteplici applicazioni che compongono i servizi. All’interno della suite di prodotto LBL S.A.A.I., oltre alla componente di bilanciatore intelligente L7 denominata Global Distributed Gateway, sono disponibili ulteriori funzionalità abilitate attraverso un opportuno modello di licensing. Grazie alle funzionalità avanzate di ottimizzazione delle applicazioni e traffic management la piattaforma è in grado di ridistribuire il carico sui cluster e di garantire Business Continuity, Disaster Recovery.

Nei paragrafi successivi sono descritti in maniera sintetica le singole componenti tecnologiche.

Descrizione della soluzione

LBL Secure Application Availability Infrastructure è un insieme di strumenti progettati per aumentare la disponibilità dei servizi applicativi.

Le scelte di progetto sono basate su attenti studi preliminari e da esperienze significative nell’ambito dell’elaborazione concorrente iniziate nel 1986 che hanno permesso l’implementazione di un modello di riferimento sul quale poggia l’intero sistema. LBL Secure Application Availability Infrastructure deriva da una lunga esperienza maturata in numerosi progetti mission-critical che hanno permesso di far acquisire alla soluzione le caratteristiche di semplicità ed affidabilità tipiche di questo settore. LBL Secure Application Availability Infrastructure comprende diversi prodotti e funzionalità rilasciate in distribuzioni commerciali:

Prodotti:

  • LBL Monitor
  • LBL Monitor IP Network Card Redundancy
  • LBL Global Distributed Gateway
  • LBL Application Delivery Controller Standard HA
  • LBL Application Delivery Controller Enterprise HA
  • LBL Application Delivery Controller Platform
  • LBL DNS & Proxy Manager
  • LBL DNS Global Load Balancer & Firewall
  • LBL Commander
  • LBL Commander Work Flow
  • LBL Commander Decision Engine
  • LBL Traffic Monetizer
  • LBL Traffic Monetizer Light
  • LBL GUI Reliability Tools
  • LBL Developer
  • Attack Prophecy (powered by Pluribus ONE)

Funzionalità integrate in LBL Application Delivery Controller:

  • LBL DoS/DDoS Attack mitigation & Vip iRedCarpet
  • LBL Web Application Firewall basato su signature OWASP

LBL Monitor

LBL Monitor è il sistema operativo della suite LBL Secure Application Availability Infrastructure di completa proprietà intellettuale di TCOGROUP. LBL Monitor è stato pensato per sfruttare al massimo le potenzialità di soluzioni ADC & Security con traffico dati passante ottimizzando le piattaforme real-time per enormi volumi di dati TCP/UDP. LBL Monitor è in grado di eseguire tutti i moduli della suite LBL Secure Application Availability Infrastructure in modo modulare, scalabile e integrato.

Attraverso un’interfaccia web è possibile eseguire in sicurezza le operazioni più comuni come lo start/stop di un modulo, eseguire la visualizzazione dei log, verificare le interfacce di rete. LBL Monitor controlla durante il run-time l’evoluzione dell’esecuzione dei moduli filtrando i messaggi e attraverso e-mail o servizi HTTP, notificando quelli più significativi.

LBL Monitor verifica costantemente lo stato dei processi e in caso di problemi è in grado segnalare tempestivamente l’evento anomalo attraverso e-mail, SNMP oppure attraverso una “post HTTP” ad un servizio preventivamente posto in ascolto.

LBL Monitor collabora strettamente con LBL Global Distributed Gateway per la parametrizzazione e personalizzazione dei moduli permettendo una visione globale dei servizi applicativi e delle risorse che possono essere distribuite in locale ed in remoto.

LBL Monitor – Multi-tenancy

LBL S.A.A.I. nasce per essere utilizzato in ambienti virtuali e cloud in modalità multi-tenancy ed in ambienti hybrid-cloud.

Grazie alle funzionalità “Autonomous Delegated Authentication” e full-virtualization è possibile assegnare e segregare a determinati gruppi di utenti le VAPP a loro assegnate garantendo il totale isolamento. La soluzione previene la possibilità di clonazione delle istanze virtuali invalidando le deleghe e rendendo quindi impossibile un uso non autorizzato.

“Autonomous Delegated Authentication” permette di aggregare in insiemi di gruppi di utenti la visibilità e l’operatività delle risorse così da mantenere visioni e operatività globali per alcuni gruppi e parzializzandone l’utilizzo per altri gruppi.

LBL Monitor – Autonomous Delegated Authentication

LBL S.A.A.I. introduce l’autenticazione delegata in tutte le comunicazioni tra le componenti ed i moduli.

L’implementazione è maturata dall’esperienza in datacenter mission-critical per aumentare la sicurezza e diminuire le possibilità di utilizzi non autorizzati di procedure all’interno del/i datacenter. L’odierna possibilità di importazione di un intero sistema operativo clonato all’interno di virtualizzatori compromette drasticamente la sicurezza dando la possibilità di eseguire da remoto procedure altamente pericolose non autorizzate.

A questo proposito tutti gli archivi delle password dei moduli LBL S.A.A.I. sono crittografati ed utilizzabili solo dalla posizione e dal sistema operativo su cui sono stati originati. Eventuali clonazioni del sistema o furto degli archivi di autenticazione rende gli stessi illeggibili e quindi qualsiasi operazione non possibile.

L’implementazione dell’autenticazione degli accessi LBL S.A.A.I. si basa su 4 punti fondamentali:

  1. crittografia dei repository delle autenticazioni
  2. origine della creazione dei file di autenticazione
  3. separazione dell’autenticazione utente e delegata
  4. autonomia rispetto all’infrastruttura da gestire

Il primo (1) punto è importantissimo in quanto gli archivi delle autenticazioni sono crittografati per permetterne la visibilità o leggibilità con i soli strumenti messi a disposizione dalla piattaforma LBL S.A.A.I.

Il secondo (2) punto pone un significativo miglioramento nella sicurezza. Tutti gli archivi risultano illeggibili, anche dagli stessi strumenti LBL S.A.A.I., se vengono copiati in altro luogo o se vengono utilizzati su ambienti virtuali o fisici clonati.

Il terzo punto (3) separa la gestione degli utenti umani dagli utenti delegati o da sistemi LBL S.A.A.I. e permette di definire, dove due gruppi di persone (sistemisti e sicurezza).

Il quarto punto (4) evidenzia come il sistema autoritativo debba essere completamente autonomo dall’infrastruttura che deve gestire. L’autorizzazione delegata all’azione è quindi completamente slegata ad esempio da Directory Server che potrebbero non essere disponibili o raggiungibili al momento dell’esecuzione delle procedure (operazioni da effettuarsi durante avarie o fail-over del datacenter).

LBL Secure Web-Based GUI – Admin Console e Remote Management

LBL Secure Web-Based GUI è l’interfaccia integrata di Remote Management per amministrare tutti i moduli della suite LBL S.A.A.I.

LBL Secure Web-Based GUI è stata sviluppata con le più moderne tecnologie HTML5 responsive ed è possibile utilizzarla da molteplici strumenti come differenti browser, tablet, mobile.

Attraverso l’interfaccia LBLSecure Web-Based GUI di Admin Console e Remote Management è possibile avere accesso a tutte le funzionalità via web.

L’accesso alla piattaforma di management avviene tramite una connessione sicura HTTPS (SSL) con autenticazione da parte dell’operatore anche attraverso la richiesta di certificati digitali.


LBL Monitor – IP Network Card Redundancy

Questo modulo, disponibile su tutte le distribuzioni e utilizzabile con qualsiasi licenza acquisita, permette di ottenere la ridondanza di instradamento utilizzando più interfacce di rete Hardware. È possibile quindi stabilire un numero di interfacce di rete fisiche per uno stesso indirizzo IP che verrà assegnato dinamicamente in base alla disponibilità della rete per quel particolare percorso (path). Per assicurare ai massimi livelli la disponibilità della connettività è quindi possibile impostare nel servizio LBL IPNCR più NIC (Network Interface Card) per uno stesso indirizzo. Il numero di interfacce fisiche di fail-over non ha un limite ed è quindi possibile aggiungere interfacce di fail-over semplicemente duplicando le regole e applicandole alle interfacce.

Il servizio di LBL IP Network Card Redundancy non si limita a fornire alta disponibilità a livello di rete fisica ma può essere utilizzato anche in funzione di logiche applicative. È possibile infatti condizionare l’impostazione dell’indirizzo virtuale in base alla disponibilità di un indirizzo, alla possibilità di connessione ad un indirizzo porta oppure alla disponibilità di un servizio HTTP/S.

È quindi possibile ad esempio condizionare l’impostazione dell’indirizzo alla presenza o all’assenza di un servizio attraverso Health Check. Quest’ultima funzionalità di impostazione condizionata è molto utile nei casi di Disaster Recovery o Business Continuity per poter indicare ai LBL DNS & Proxy Manager un indirizzo alternativo ai siti fino al ripristino del completo controllo di uno dei siti.

LBL Monitor – Logging & Debugging “log-rotation & Message Deduplication”

Il sistema di logging LBL S.A.A.I. può essere impostato per le diverse tipologie di informazioni che si vogliono tracciare. Il log è asincrono con mantenimento della sequenza temporale delle operazioni. La funzione di “log-rotation” permette al sistema di mantenere la storia degli eventi accaduti per 15 giorni prima della loro cancellazione (il numero di giorni è impostabile da parametro). Questa funzionalità è stata introdotta per diminuire i tempi di manutenzione del sistema e non esaurire le risorse di memorizzazione di massa. Il sistema di logging ha integrato un sistema di deduplica dei messaggi in modo da non visualizzare/memorizzare lo stesso messaggio se ripetuto consecutivamente. Il sistema di deduplica in ogni caso esegue la visualizzazione/log del messaggio ogni 20 ripetizioni (numero impostabile da parametro) o al prossimo messaggio diverso da quelli ripetuti.

LBL S.A.A.I. permette ulteriormente di centralizzare in un database relazionale transazionale tutti gli eventi di logging di tutti i moduli e di tutti i nodi LBL S.A.A.I. installati. Il sistema permette di analizzare gli eventi in maniera centralizzata, con strumenti di Business Intelligence e sonde di strumenti di terze parti per la gestione delle criticità. Ogni modulo LBL S.A.A.I. incorpora nativamente questa funzionalità. Come per le statistiche di traffico, nel caso si perdesse la connettività con il repository centralizzato i log vengono mantenuti in cache per un periodo di tempo stabilito fino al ripristino della connettività.

Il sistema di logging a fronte di violazione di regole registra l’evento per analisi o applicazione di trigger.

Struttura dei nomi del file di log:

Di seguito l’elenco delle più importanti possibilità fornite dal sistema di logging & debugging per un’analisi dei dati in transito e delle modificazioni apportate dalle regole di rewiting.

DEBUG debug functionality activation-deactivation
LBL_DEBUG_FLOW flow debugging
LBL_DEBUG_BODY message body debugging
LBL_DEBUG_HTTPV show http version
LBL_DEBUG_ENDPOINT endpoint traking
LBL_DEBUG_SESSION session traking
LBL_DEBUG_MONITOR Monitor
TCO_DEBUG_HEADER header debugging
TCO_DEBUG_IO IO
TCO_DEBUG_RAWIO IO (byte by byte)
TCO_DEBUG_EDITRAWIO edited IO

LBL Global Distributed Gateway

Ambienti complessi e distribuiti richiedono una modalità di gestione e provisioning efficace e sicura. LBL Global Distributed Gateway è il modulo che permette di aggregare e gestire tutte le informazioni ed i parametri dei nodi LBL S.A.A.I. sia locali che distribuiti e di fornire un’immagine globale dei sistemi e del loro stato.

LBL Global Distributed Gateway mantiene la consistenza e l’allineamento di tutti i nodi. Tutte le azioni sono erogate attraverso interfaccia grafica HTML5 (responsive) LBL Secure Web-Based GUI in assoluta sicurezza mantenendo la separazione e segregazione delle risorse in base all’utente ed al gruppo di appartenenza sfruttando le caratteristiche della funzionalità “Autonomous Delegated Authentication”. E’ possibile quindi creare dei raggruppamenti specifici per ogni amministratore restringendo le operazioni che possono essere eseguite.

L’accesso alla piattaforma di management avviene tramite una connessione sicura HTTPS (SSL) con autenticazione da parte dell’operatore anche attraverso la richiesta di certificati digitali.

Tutta la piattaforma implementa nativamente un sistema di versioning che permette il salvataggio automatico della precedente configurazione ogni qualvolta viene fatta una modifica. In questo modo è sempre possibile garantire eventuali azioni di restore/roll-back anche parziali di una configurazione precedente.

È inoltre possibile esportare completamente un intero modulo per eseguire backup totali (export) e restore totali (import).

C:\Users\vale\Google Drive\share\Documents\Products\LBL DoS DDoS Attack mitigation\Images\eljpgkmgaonogfep.png
C:\Users\vale\Google Drive\share\Documents\Products\LBL DoS DDoS Attack mitigation\Images\Screenshot_20171102-160724.png

LBL Global Distributed Gateway – Let’s Encrypt & Centralized certificate management

LBL Global Distributed Gateway L’utilizzo esteso di certificati digitali deve essere supportato da adeguati strumenti che ne permettano una facile gestione. Attraverso l’interfaccia web è possibile creare, aggiornare, importare, esportare e distruggere i certificati digitali coprendone tutto il ciclo di vita.

Let’s Encrypt, ACME Protocol

Il protocollo ACME (Automatic Certificate Management Environment) è un protocollo per automatizzare le interazioni tra le Certification Authorities ed i web server degli utenti, permettendo la generazione e il deploy dei certificati digitali in maniera semplice ed economica. Il protocollo ACME è un protocollo mantenuto da IETF e promosso da Internet Security Research Group che mette a disposizione un servizio di Certification Authority gratuito per la generazione di certificati digitali del tipo Domain Validation. Questo servizio chiamato Let’s Encrypt è generalmente associato al protocollo ACME.

Con LBL ADC con un semplice click è semplice creare e rinnovare certificati Let’s Encrypt direttamente da un browser o uno smartphone.

LBL Application Delivery Controller

LBL Application Delivery Controller è il sistema full-reverse-proxy con caratteristiche di bilanciamento e instradamento del traffico di trasmissione dati a livello 4 OSI e a livello applicativo 7 OSI (HTTP/S) con caratteristiche di session affinity (aka sticky session e load balancer managed session) in grado di assicurare una elevata scalabilità sui moderni sistemi multiprocessore e sui sistemi con processori multithread con caratteristiche di encryption on chip (AES-NI or on-board/on-chip encryption functionality). LBL Application Delivery Controller permette una gestione centralizzata delle politiche di routing fornendo una visione globale dei servizi e con la possibilità di navigare dal singolo end-point per arrivare al nodo di gestione locale o distribuito in servizi cloud. I sistemi sono in grado di gestire centinaia di indirizzi virtuali interni e centinaia di differenti servizi.

LBL Application Delivery Controller Standard HA è destinato ad ambienti in alta affidabilità attraverso un sistema di ‘master/sleeping master/s’ che mantengono i dati di instradamento delle sessioni. Questa versione permette un indice di affidabilità teorico del 99,99%**. Queste funzionalità si realizzano attraverso la gestione di indirizzi virtuali (VIP) che permettono ai nodi di prendere il controllo degli indirizzi (IP-TakeOver) nel caso di guasto del master. Con questa distribuzione è possibile utilizzare due istanze in mutual-failover utilizzando entrambi i nodi contemporaneamente su diversi servizi. (In caso di caduta di uno dei due nodi, il superstite è in grado di gestire tutti i servizi).

LBL Application Delivery Controller Enterprise HA utilizza un sistema avanzato di gestione delle richieste di servizio che permette di gestire più nodi contemporaneamente in maniera simmetrica e paritetica (active-active). Questa soluzione è particolarmente utile in quelle situazioni dove siano necessari dei sistemi di tipo fault-tolerance con affidabilità teorica superiore al 99,999%**. Questa funzionalità, unica nel suo genere, risulta particolarmente valida anche per l’erogazione di servizi e contenuti, anche dislocati geograficamente, aventi come mediatore un DNS round robin o FireWall RoundRobin. Nel contempo questo tipo di “Fail-Over” salvaguarda la continuità di servizio propria dei sistemi “Fault-Tolerance” mantenendo la coerenza di instradamento delle sessioni. Questa distribuzione ha una scalabilità elevatissima e supera i normali limiti di instradamento dei bilanciatori master/sleeping-master. Come migliore soluzione per la gestione dinamica delle associazioni nomi<>indirizzi LBL Application Delivery Controller Enterprise HA può essere affiancato da LBL DNS & Proxy Manager e LBL DNS Global Load Balancer strumenti nati per soddisfare questa esigenza.

LBL Application Delivery Controller Platform si distingue per semplicità d’installazione ed implementazione. Questa versione è stata studiata per lo sviluppo, test e stage.

**Risultato non tipico. La disponibilità dipende da vari fattori, tra cui le architetture hardware, le applicazioni software, processi mission critical e servizi professionali

**Risultato non tipico. La disponibilità dipende da vari fattori, tra cui le architetture hardware, le applicazioni software, processi mission critical e servizi professionali

LBL Application Delivery Controller – Endpoints grouping

Per poter fornire servizi eterogenei in alta affidabilità con una gestione centralizzata LBL Application Delivery Controller mette a disposizione due tipi di aggregazione che permettono la massima flessibilità e partizionamento delle risorse fisico-logiche: End-Points Grouping e Domains Virtualization. L’ End-Points Grouping e il Domains Virtualization sono le caratteristiche che razionalizzano e aggregano in diverse maniere l’associazione tra Punto/i di Richiesta e le Risorse di erogazione dei Servizi.

Con l’End-Points Grouping possiamo assegnare dei nomi simbolici ai listener (Punti di richiesta) e associare ad essi delle risorse di back-end (End-Points) es.:

Aggiungendo all’interno dell’endPointsGrouping ulteriori end-points questi verranno utilizzati solo dai listeners con lo stesso endPointsGrouping. Aggiungendo altri endPointsGrouping con nomi differenti si possono creare isole di servizi separate e utilizzabili solo attraverso i propri listener/s. L’End-Points Grouping è utilizzabile sia su layer 7 sia su layer 4 OSI. A livello 4 OSI questa funzionalità viene utilizzata per aggregare servizi dello stesso tipo es.: ftp, smtp, telnet, ssh etc.


LBL Application Delivery Controller – Domain Virtualization (Grouping)

La funzionalità Domains Virtualization, applicabile solo su layer 7 OSI e protocollo HTTP/S, permette di utilizzare un unico punto di accettazione richieste per diversi raggruppamenti di servizi associati a nomi di dominio differenti. Per fare un esempio possiamo pensare ad un service provider che fornisce servizi a più clienti ognuno con un proprio nome di dominio es.: www.mango_fruit.com, www.papaia_fruit.com, www.ananas_fruit.org. Volendo distribuire servizi differenti a questi nomi di dominio utilizzando lo stesso indirizzo porta TCP/IP di accettazione richieste è possibile parametrizzare nel modo seguente LBL Application Delivery Controller attraverso il VirtualDomain.

LBL Application Delivery Controller – URI Path Grouping

In presenza di traffico layer 7 OSI (HTTP/S) è possibile utilizzare l’URI path per raggruppare ulteriormente i servizi da bilanciare. Per ogni raggruppamento di URI Path, LBL Application Delivery Controller applicherà le regole di bilanciamento in maniera indipendente dagli altri gruppi.

LBL Application Delivery Controller – URI Path matching

In presenza di traffico layer 7 OSI (HTTP/S) è possibile utilizzare in alternativa all’URI path una espressione regolare per catalogare la richiesta e instradarla in end-point specifici. Anche in questo caso è possibile determinare o indurre una specifica sessione applicativa condizionata dal contesto. È altresì possibile assegnare un ordine di matching della regola per poterla eseguire in maniera coordinata tra URI path puntuali e URI path matcher governati da una espressione regolare. Per ogni raggruppamento di URI path matching LBL Application Delivery Controller applicherà le regole di bilanciamento in maniera indipendente dagli altri gruppi.

LBL Application Delivery Controller – Tipi di bilanciamento

Con LBL Application Delivery Controller si possono essere utilizzati i seguenti tipi di bilanciamento.

  1. RoundRobin (default)
  2. Adaptative (aka adapt-active)
  3. FailOver

La politica di bilanciamento può essere associata al Gruppo di risorse (EndPointsGrouping) oppure al dominio (VirtualDomain) fino al URI Path o all’URI Path matching. Diversi gruppi di risorse, diversi domini e differenti URI path URI Path matching all’interno dello stesso dominio possono avere differenti politiche di bilanciamento.

Il bilanciamento RoundRobin assegna le risorse di backend in maniera ciclica in ordine temporale rispetto l’ordine di arrivo della richiesta.

Il bilanciamento Adaptative (adapt-active) assegna le risorse di backend scegliendo, tra quelle disponibili, la meno impegnata. L’impegno della risorsa viene calcolato in base alle connessioni che si trovano nello stato di attesa di una elaborazione dal backend oppure sono in fase di trasferimento dati. Questo comportamento assicura uno straordinario bilanciamento delle richieste senza l’utilizzo di agenti.

Il bilanciamento FailOver è una modalità di bilanciamento riservata a quei servizi che per loro natura non possono essere bilanciati ma hanno bisogno di un sistema di FailOver che ne salvaguardi la continuità di servizio. Questa politica di bilanciamento prevede di avere un pool di risorse di back-end in mutual fail-over. LBL Application Delivery Controller schedula il traffico sul primo nodo di backend in stato di ready partendo dal primo end-point inserito nella lista. All’avaria del nodo attivo LBL Application Delivery Controller cerca di passare al prossimo nodo disponibile. LBL Application Delivery Controller non passa al prossimo libero ma al primo nodo disponibile ripartendo dal primo della lista per permettere i fail-back e ripristinare la situazione iniziale dell’evento di failure.

LBL Application Delivery Controller – Web Socket

LBL Application Delivery Controller implementa la tecnologia Web Socket. WebSocket è una tecnologia web che fornisce canali di comunicazione full-duplex attraverso una singola connessione TCP. WebSocket è presente come raccomandazione W3C e il protocollo WebSocket è stato ratificato dall’IETF come RFC 6455.

WebSocket è disegnato per essere implementato sia lato client che lato server e può essere utilizzato da qualsiasi applicazione client-server. Il protocollo è indipendente dal protocollo che sarà utilizzato. La sua unica correlazione con l’HTTP/S è nel modo in cui fa l’handshake durante una Upgrade request tra client e server. Il protocollo WebSocket permette maggiore interazione tra un client e un server, facilitando la realizzazione di applicazioni che forniscono contenuti e giochi in tempo reale. Questo è reso possibile fornendo un modo standard per il server di mandare contenuti al browser senza dover essere sollecitato dal client e permettendo ai messaggi di andare e venire (full-duplex) tenendo la connessione aperta. Ulteriore vantaggio è che le comunicazioni sono realizzate attraverso le porte TCP utilizzate durante l’handshake SSL senza interruzione dei canali, usufruendo quindi di autenticazioni del protocollo HTTP/S e della possibilità di attraversare i firewall con le stesse policy dell’HTTP/S utilizzate in precedenza.

LBL Application Delivery Controller – Bilanciamento Geografico

LBL Application Delivery Controller è stato studiato fin dall’inizio per un utilizzo diffuso su rete geografica. I Nodi di bilanciamento possono quindi essere posizionati in luoghi geograficamente distanti. L’utilizzo della banda ad uso di LBL Application Delivery Controller è stata limitata al massimo proprio per permetterne un utilizzo in condizioni di limitata capacità di trasmissione.

Il Bilanciamento Geografico è un aspetto che ben si adatta alle attuali possibilità architetturali e permette a due siti geograficamente distanti e active-active di preferire i servizi più vicini al Nodo. Per istruire LBL Application Delivery Controller ad effettuare questa distinzione è semplicissimo. E’ sufficiente indicare nella descrizione del servizio il parametro near.

Con questo parametro, unitamente alle caratteristiche di clustering esteso di LBL Application Delivery Controller, è possibile realizzare gruppi di bilanciatori federati tra loro e dislocati nel territorio. I servizi sono resi comuni ma LBL Application Delivery Controller preferirà in stato di normalità utilizzare quelli più vicini al Nodo.


In mancanza di servizi in prossimità passerà ad utilizzare i servizi situati in altri siti. Questa funzionalità può essere sfruttata anche in altre circostanze dove i servizi non possono essere bilanciati per specifiche architetturali e completa la politica di bilanciamento FailOver automatizzando il ripristino dell’operatività dei servizi una volta che questi siano riattivati.

LBL Application Delivery Controller – IP Reputation and Geo localization

LBL Application Delivery Controller è stato studiato fin dall’inizio per un utilizzo diffuso su rete geografica.

LBL Application Delivery Controller IP Geo Localization è una funzionalità della componente di bilanciamento e instradamento. È composto da due elementi, il downloader delle associazioni indirizzi località (country) e la possibilità di interrogare real-time il database da parte del bilanciatore on-the-fly mentre transitano i dati.

Attraverso il rewriter è possibile impostare dei filtri per permettere o bloccare il passaggio delle richieste provenienti da particolari aree geografiche. Attraverso le potenti regole del rewriter è possibile selettivamente escludere alcuni indirizzi anche se provenienti da aree geografiche interdette.

Il modulo DoS/DDoS utilizza il repository di geolocalizzazione IP per indicare la fonte geografica degli attacchi

C:\Users\vale\Google Drive\share\Documents\Products\LBL DoS DDoS Attack mitigation\Images\kajnbdabfbhblpfc.png

C:\Users\vale\Google Drive\share\Documents\Products\LBL DoS DDoS Attack mitigation\Images\nafeikaopakadiml.png

LBL Application Delivery Controller – Protocolli standard e personalizzati

Con LBL Application Delivery Controller è possibile diversificare i parametri relativi ad un flusso dati fino al singolo raggruppamento di risorse o al protocollo. LBL Application Delivery Controller ha già preimpostati i parametri per i più diffusi protocolli.

E’ altresì possibile modificare o creare un nuovo gruppo di parametri partendo da uno esistente e modificandone solo i valori per differenza.

LBL Application Delivery Controller – HTTP Data Compression

LBL Application Delivery Controller HTTP Data Compression permette di comprimere il traffico dati per ottimizzare l’occupazione della banda.

Con LBL Application Delivery Controller è possibile comprimere selettivamente singoli flussi di dati contestualizzati anche per gruppo/dominio/end-point/mime-type.

La compressione dei dati HTTP si ottiene attraverso regole, già predisposte e personalizzabili, per avere la massima espressività e flessibilità di applicazione.

LBL Application Delivery Controller utilizza una raffinata tecnologia di parallelizzazione di compressione dei dati. La compressione avviene quindi sfruttando al massimo il parallelismo delle moderne CPU multicore e multithread eliminando ogni punto di sincronizzazione dovuti ad hardware aggiuntivo all’esterno della CPU ed eliminando ogni collo di bottiglia.


LBL Application Delivery Controller – Caching & Acceleration

LBL ADC supporta la funzionalità di caching che consente di ottimizzare notevolmente la user experience. A questo proposito tutte le richieste possono utilizzare porzioni di memoria che servono a bufferizzare temporaneamente i contenuti (cache) diminuendo l’utilizzo di banda ed ottimizzando i tempi di accesso e accelerando l’utilizzo dei servizi.

L’impostazione dei valori di caching sono direttamente parametrizzabili attraverso interfaccia con l’assegnazione di aree di memoria dedicate che vengono allocate staticamente in proporzione al dimensionamento dell’ LBL ADC in base ai parametri impostati.

Il dimensionamento della cache è ottimizzato per la massima accelerazione con parametri di fabbrica. L’algoritmo e gli spazi occupati sono disponibili nel manuale Reference Guide.

LBL Application Delivery Controller – Port Rewriting

Il port rewriting è una funzionalità che viene utilizzata nei casi in cui il servizio di back-end cerchi di ridirezionare la comunicazione verso la propria porta e non sulla porta a cui è stato richiesto il servizio. Questo comportamento si può verificare ad esempio con un response code 302 (MOVED TEMPORARY) su alcuni Web Server in specifiche release o implementazioni applicative (es. Microsoft IIS o Apache Web Server).

LBL Application Delivery Controller – X-Forwarded-For (XFF)

LBL Application Delivery Controller può aggiornare e/o inserire nell’HEADER HTTP di request l’entity X-Forwarded-For per eseguire il forwarding degli indirizzi del client. L’entity X-Forwarded-For è caratterizzato da un valore “comma+space separated” ed indica, da sinistra verso destra, gli indirizzi degli strati che hanno attraversato la richiesta (proxy, gateway etc. compliant). L’indirizzo il cui valore è posto più a destra della catena separata da “,” è sicuramente l’indirizzo del client che ha contattato LBL Application Delivery Controller, gli altri indirizzi devono essere utilizzati per finalità statistiche essendo comunque inseriti da altri apparati che sono stati attraversati dal flusso informativo. Di questo argomento si può trovare ampia documentazione in Internet essendo stato adottato dalla pressoché totalità dei servizi di rete a layer 7 HTTP/S.

Inoltre la visibilità del client IP Address nell’ X-Forwarded-For permette a LBL ADC di applicare gli algoritmi di mitigazione DoS/DDoS sulla base dell’ IP address sorgente o come elemento di sessione su più hop applicativi.

LBL Application Delivery Controller – URL Redirection

Un’importante funzionalità è rappresentata dalla possibilità di indicare come end-point un URL di ridirezione. Questa funzionalità, applicabile su layer 7 HTTP/S, centralizza la gestione dell’instradamento in un unico strumento rendendo più semplice la manutenzione dell’impianto.

L’health check del servizio, descritto dal parametro “redirectTo”, può essere attivato indicando “address” e “port”. Questa funzionalità non è attivata in automatico perché il servizio descritto in “redirectTo” potrebbe non essere raggiungibile dal bilanciatore in quanto schermato da un firewall o appartenente ad un’altra rete. Di seguito un esempio di flow di un redirect. E’ anche possibile eseguire il redirect all’interno dello stesso bilanciatore per portare la trasmissione da non criptata a criptata o aggiungere parametri o query string alla nuova richiesta.

LBL Application Delivery Controller – “OutOfOrder” & “OffAgain”

Il sistema durante il funzionamento può rilevare la non disponibilità di uno o più servizi.

Il sistema di sorveglianza servizi interno a LBL Application Delivery Controller provvede a mettere ‘fuori uso’ il servizio e periodicamente verifica la nuova disponibilità ripristinandone la funzionalità. Questa caratteristica di ripristino automatico della risorsa è valida per le politiche di bilanciamento RoundRobin e Adaptative. Per la politica di bilanciamento FailOver è invece (volutamente) necessario un intervento umano per indicare che la risorsa è tornata disponibile. Nel caso di bilanciamento FailOver l’intervento umano è necessario per indicare a LBL Application Delivery Controller che la risorsa è stata ripristinata anche dal punto di vista applicativo.

Eventuali malfunzionamenti saranno notificati attraverso email o http post. Il ripristino del servizio verrà segnalato su logfile.

– SCHEMA DI RISOLUZIONE “Out Of Order” & “Off Again” –

1 – Sistema Ok

2 – Sistema Out Of Order

3 – Sistema Off Again

LBL Application Delivery Controller – Session Affinity and Mirroring

La gestione della sessione può avvenire in diverse modalità a seconda che si stia utilizzando il Layer 4 TCP/UDP in chiaro o SSL/TLS oppure il Layer 7 HTTP o HTTPS. Nel caso si stia utilizzando il layer 4 è possibile gestire la sessione attraverso l’indirizzo TCP del client o di un qualsiasi parametro rappresentativo (Sessione SSL o qualsiasi informazione rappresentativa derivata dallo stream dati).

  • Sessione gestita dall’applicazione (inspection)
  • Sessione generata e gestita da LBL Application Delivery Controller (Load balancer managed session)

Queste due possibilità forniscono la massima flessibilità permettono ad LBL Application Delivery Controller di gestire nella maniera più corretta il flusso informativo.

Nelle versioni LBL ADC Standard HA e LBL ADC Enterprise HA la gestione della sessione prevede la propagazione (mirroring) in maniera trasparente delle informazioni relative alle proprietà delle sessioni (anche per le connessioni SSL/TLS) a tutti i nodi che compongono il cluster (istanze di LBL ADC) per conferire le necessarie caratteristiche di affidabilità e disponibilità di servizio in ambienti mission-critical.

Con LBL ADC è possibile riconfigurare a caldo i servizi mantenendo contemporaneamente tutte le sessioni associate agli altri servizi che continueranno ad operare mantenendo gli instradamenti attivi. E’ inoltre possibile associare, attraverso identificatori, i servizi applicativi alle rispettive risorse che li compongono. In questo modo è possibile correlare l’erogazione di un servizio alle varie componenti applicative.

È Possibile verificare il numero di sessioni e la loro propagazione nei nodi componenti il cluster direttamente da interfaccia grafica su Running Status->Sessions:

È inoltre possibile verificare per IP client il trace dell’attraversamento globale a LBL GDG e le sessioni generate. Anche in questo caso saranno visualizzate tutte le sessioni distribuite sui nodi del cluster dal motore di mirroring.

LBL Application Delivery Controller – Mutual Fail-over

La virtualizzazione di bilanciatori è la tecnologia che permette di avere più istanze di bilanciatori all’interno della stessa istanza LBL Application Delivery Controller o di utilizzare più guest in ambienti che utilizzano hypervisor. Questa tecnologia semplifica la gestione in situazioni complesse dove sono richieste zone diversificate per servizio o qualora sia necessario utilizzare servizi di bilanciamento in mutual fail-over.

È possibile utilizzare più istanze di LBL Application Delivery Controller all’interno dello stesso guest in modo da suddividere i servizi su più nodi che compongono il cluster ed in caso di caduta di uno dei nodi, i superstiti prenderanno in carico gli indirizzi virtuali non più serviti dal nodo in avaria erogando comunque il 100% dei servizi.

È possibile utilizzare questa funzionalità anche in caso di manutenzione programmata permettendo la continuità dell’erogazione dei servizi. A questo scopo è disponibile una funzione del cluster che permette di far migrare gli indirizzi virtuali da un nodo ad un altro in qualsiasi momento.

LBL Application Delivery Controller – Security essential

LBL Application Delivery Controller include caratteristiche di sicurezza avanzata direttamente nel core del sistema di forwarding. In particolare è possibile escludere interi set di indirizzi IP dal forwarding attraverso l’impostazione di IP_GLOBAL_BLACK_LIST IP_GLOBAL_WHITE_LIST oppure attraverso la geo referenziazione. Le liste possono essere popolate anche da sorgenti esterne con strumenti di terze parti.

Completano le caratteristiche di security essential:

  1. Session Cookie (tls)
  2. Set-Cookie app server generation (tls)
  3. HSTS: Redirect from http to https
  4. HSTS: Strict-Transport-Security injection on response
  5. Check body lenght in POST not dependent by content-type / transfer enconding
  6. Client SSL Protocols interceptor and tracing
  7. SSL ciphers suite And Protocols Global / Listeners / Backend abilitations
  8. SSO e client certificate management
  9. XSS mitigation
  10. End Point Maskeration
  11. Virtual patches
  12. IP Addresses White List
  13. IP Addresses Black List
  14. IP Based geo localization White list
  15. IP Based geo localization Black List

Esempio di impostazione range di IP bloccati o temporanemante bloccati


Geolocalization Black list

IP Black list

IP Black list

LBL Application Delivery Controller – SSL Terminator & Offloading

La soluzione LBL Application Delivery Controller attraverso le avanzate funzionalità di tunneling ed encryption end-to-end è in grado garantire un accesso sicuro ai servizi garantendo un unico punto di controllo e sicurezza. La capacità di utilizzare certificati digitali è garantita dal potente sistema di offloading che permette di terminare le connessioni SSL, richiedere ai client strong-autentication, eseguire il forwarding dei certificati verso i servizi, eseguire a diversi livelli di sicurezza le operazioni di re-encryption nel backend.

LBL Application Delivery Controller può essere il terminatore di una connessione HTTPS. L’URL rewriting permette ai servizi HTTP del back-end un ottimo grado di trasparenza delle applicazioni rispetto i protocolli attraversati.

Il sistema LBL Application Delivery Controller offloading accelaration utilizza le nuovissime tecnologie di encryption on chip (AES-NI or on-chip encryption functionality). L’utilizzo di queste tecnologie parallele di encryption permettono di accelerare drasticamente le attività che un tempo venivano delegate da chip ASICs esterni che in ambienti multicore formavano dei colli di bottiglia e introducevano latenze dovute alla dislocazione esterna al calcolatore oltre a presentare problemi di utilizzo in ambienti virtualizzati eterogenei o cloud.

Essendo LBL Application Delivery Controller un full-reverse-proxy è possibile differenziare le caratteristiche SSL/TLS del front-end (connessioni dei client) da quelle del back-end (connessioni verso gli end-point/servizi) sia a livello di protocollo SSL/TLS sia a livello di cipher-suite. Questo permette di mantenere in maniera centralizzata un livello altissimo di protezione e sempre aggiornato diminuendo significativamente gli interventi sulle molteplici piattaforme application-server utilizzate per l’erogazione degli applicativi che possono quindi essere aggiornate in momenti differenti.

Il sistema di encryption e di trattamento dei certificati digitali può avvalersi della tecnologia TLS-SNI (Server Name Indication) in grado di concentrare l’utilizzo di più certificati digitali in un unico indirizzo-porta diminuendo drasticamente il numero di indirizzi IP esposti e portando allo stato logico l’instradamento applicativo. Questa funzionalità permette una drastica semplificazione a livello di networking e di regole firewall.

Il sistema di encryption SSL/TLS garantisce la dinamicità della sessione SSL/TLS per aumentare la sicurezza del protocollo in linea con le ultime specifiche.


LBL Application Delivery Controller fornisce liste sintetiche dei certificati digitali in utilizzo calcolandone l’expiration date ed evidenziandole sull’interfaccia e attraverso e-mail ogni 24 ore quando mancano 60 giorni dalla scadenza.

LBL Application Delivery Controller – SSL Re-encryption

La tecnologia SSL Re-encryption permette di ottenere una trasmissione criptata sia nel front-end dai client che richiedono i servizi a LBL Application Delivery Controller, sia nel back-end permettendo di utilizzare protocolli e cipher-suites SSL/TLS differenti e mantenendo nel contempo un routing efficiente basato sulle informazioni che transitano all’interno di LBL Application Delivery Controller.

Questa tecnologia è molto utile nel caso si trattino volumi elevati di informazioni riservate o sensibili permettendo di avere nell’erogazione del servizio la massima sicurezza disponibile e contemporaneamente tutte le funzionalità di routing applicativo che un moderno ADC deve mettere a disposizione in ambito applicativo.

LBL Application Delivery Controller – SSL Tunneling

Con LBL Application Delivery Controller è possibile eseguire a livello di trasporto il forwarding di dati completamente criptati permettendo l’SSL tunneling o qualsiasi altra forma di encryption in maniera completamente trasparente.

LBL Application Delivery Controller – Strong Authentication & Certificate Forwarding

LBL Application Delivery Controller può gestire l’autenticazione attraverso certificato digitale client. La funzionalità può essere attivata molto semplicemente nella definizione del listener con diversi gradi di sicurezza. Se utilizzata a leyer 7 HTTPS è possibile indicare anche dei particolari URIPath con necessità di strong authentication lasciando la navigazione in SSL senza richiesta del certificato client per gli altri servizi. Una volta verificata l’autenticità del client LBL Application Delivery Controller attuerà le politiche di bilanciamento e routing instaurando una nuova connessione in SSL verso il servizio. Anche a questo livello si possono adottare differenti politiche di encryption, dalla sola instaurazione del tunnel alla certificazione totale della tratta. Se impostato il forwarding dei dati del certificato verso il backend ed essendo LBL Application Delivery Controller in possesso della traccia del certificato pubblico questa potrà essere traferita in due modalità verso il servizio:

  • Estrazione di alcuni dati del certificato e impostazione di altrettanti nuovi entity nell’HEADER http (tipicamente il DN del certificato)
  • Conversione del certificato client in pem format e trasferimento del certificato così trasformato in un entity dell’HEADER HTTP

E’ possibile utilizzare contemporaneamente o esclusivamente il tipo di forwarding. E’ inoltre possibile impostare la profondità della certificate chain in base ai controlli che vengono eseguiti dai servizi di backend.

Il risultato ottenuto è, se necessario, un trasferimento totale delle informazioni con trattamento del certificato in formato X.509.

Esempio:

LBL Application Delivery Controller – Logs and traffic analysis

LBL Application Delivery Controller storicizza su cache permanente in un database relazionale transazionale i dati di traffico e di log. È possibile utilizzare diversi database per la storicizzazione dei dati in dipendenza dei volumi di traffico.

I database supportati per la storicizzazione delle statistiche sono:

  1. Oracle
  2. MS SQLServer
  3. MySQL
  4. Postgres
  5. JavaDB embedded (default)
  6. JavaDB Networked

Superata la soglia di dati gestita dai database sopra elencati è indicato utilizzare il sistema enterprise di storicizzazione e aggregazione dei dati LBL Traffic Monetizer studiato per gestire e aggregare grandi volumi di dati.

LBL Application Delivery Controller – Protocols support IPv4 & IPv6

LBL ADC supporta pienamente e contemporaneamente i protocolli IPv4 e IPv6. Tutte le componenti LBL S.A.A.I., di gestione o di esercizio, possono essere utilizzate attraverso questi protocolli.

In particolare la componente di bilanciamento e instradamento, LBL Application Delivery Controller in tutte le distribuzioni, può utilizzare contemporaneamente sia il protocollo IPv4 sia il protocollo IPv6.

È possibile quindi, per gli stessi servizi, predisporre molteplici listener sia in IPv4 sia in IPv6 ed avere gli stessi o altrettanti servizi di backend sia in IPv4 sia in IPv6.

Sfruttando la capacità di associare dei nomi a degli endpoint (vedere associateName nella reference guide) con LBL Application Delivery Controller possono con facilità essere trattati momenti di transizione abilitando i backend in IPv6.

LBL Application Delivery Controller – DoS/DDoS Attack Mitigation

LBL Application Delivery Controller mette a disposizione una potente funzionalità integrata che permette di prevenire e gestire attacchi di tipo DoS (Denial of Service) e DDoS (Distibuted Denial od Service).

Questa potente funzionalità salvaguarda sia da attacchi provenienti da un unico indirizzo IP sia da attacchi provenienti da indirizzi IP diversificati.

L’algoritmo è stato studiato sia per le funzionalità layer 7 HTTP/S sia a layer 4 TCP/UDP.

La funzionalità è volta a salvaguardare i servizi di backend evitando di esporli a sovraccarichi che potrebbero farli andare in fault propagando il problema sui livelli DB delle applicazioni tipicamente più sensibili. L’algoritmo è quindi basato su soglie di stress applicativo oltre che volumetriche ottenendo il massimo dell’efficacia di protezione.

Con il protocollo HTTP/S è possibile avvisare gli utenti con una pagina di cortesia, un redirect, una connection close o attraverso una richiesta captcha input. Una close con reset (dove permesso dal protocollo di trasporto) per tutti gli altri protocolli.

L’algoritmo è in grado di analizzare l’attacco anche per richieste provenienti da subnets mitigandone gli effetti.

  • Single Address (Captcha input for human user verification)
  • Subnets Addresses 255.255.255.0

255.255.0.0

255.0.0.0

  • Application function prioritization


Il sistema è agent-less ed è basato sulla rilevazione istantanea del degrado dei servizi. In caso di sovraccarico volumetrico il sistema rileva quali richieste causano la maggiore congestione agendo progressivamente fino alla decongestione (SMOOTH MITIGATION). La rilevazione basata su stress applicativo e volumetrica e la conseguente reazione avviene in un tempo massimo di 50 millisecondi.

LBL Application Delivery Controller – DoS DDoS Address Quarantine

LBL Application Delivery Controller permette di confinare temporaneamente attacchi provenienti da singoli IP address, molteplici addess o address afferenti da stesse subnets. L’algoritmo è stato studiato per identificare IP dinamici e porli temporaneamente nella condizione di non nuocere.

Il sistema reagisce sia a layer 4 TCP/UDP sia a layer 7 HTTP/S-DNS. In presenza di HTTP/S l’algoritmo è in grado di rilevare anche attacchi provenienti da sistemi “nascosti” da proxy che ne offuscano l’indirizzo di partenza applicando l’algoritmo anche su elementi dell’HEADER come l’X-Forwarded-For.

C:\Users\vale\Google Drive\share\Documents\Products\LBL DoS DDoS Attack mitigation\Images\nafeikaopakadiml.png

LBL Application Delivery Controller – DoS Captcha confirmation

Al verificarsi di picchi improvvisi di richieste HTTP provenienti dalla stessa sorgente IP, LBL Gloabal Distributed Gateway propone al client una form Captcha input (personalizzabile) per verificare se la richiesta arriva è un operatore umano o se è proveniente da un robot che sta eseguendo uno scan del sito o peggio un tentativo di attacco DoS.

Se l’operatore completa correttamente la richiesta l’indirizzo verrà sbloccato per continuare l’erogazione del servizio. In caso contrario l’indirizzo rimarrà in quarantena.

LBL Application Delivery Controller – 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 address quarantine e DDoS attack mitigation aumentando l’accessibilità ai servizi distinguendo le tipologie di navigazione.

LBL Application Delivery Controller – Firewall XML

Le capacità di instradamento a livello applicativo sono enormemente aumentate dal motore di inspection e rewriting del traffico dati. Il sistema permette di agire agevolmente con regole sia a livello 4 TCP/UDP sia a livello 7 HTTP/S intervenendo sull’instradamento e condizionandolo dinamicamente sia per necessità di session affinity, sia per necessità di continuità dell’erogazione del servizio. Il content rewriting si estende alle componenti L7 sia di header che a livello di body permettendo un totale controllo del traffico dati.

Il sistema permette di utilizzare a più livelli le funzionalità di rewriting, sia attraverso parametrizzazione sia attraverso il linguaggio di programmazione JAVA. Queste due funzionalità sono state studiate per lavorare sia autonomamente sia contemporaneamente. E’ quindi possibile utilizzare delle regole descritte a livello XML e utilizzare delle proprie classi o librerie JAVA e permettere in maniera agevole e controllata di effettuare modifiche fino all’ultimo bit durante il forwarding delle informazioni.

Attraverso XML è possibile effettuare la maggior parte delle attività di rewriting e si arriverà ad utilizzare le estensioni di classi JAVA in casi particolari o in realtà dove serve una integrazione applicativa come ad esempio integrare sistemi di Single Sign On (SSO).

Aspetto questo di fondamentale importanza anche in logica di cooperazione applicativa (es. WSDL) e autenticazione federata (SSO).

Anche a layer 4 TCP/UDP è possibile intervenire direttamente sull’instradamento riducendo i tempi di down-time di componenti come ad esempio il Database o sistemi di remote desktop, indirizzando interattivamente le richieste sui punti di erogazione disponibili.

LBL Application Delivery Controller – FULL REVERSE PROXY

Dal punto di vista architetturale e funzionale LBL ADC è un Full Reverse Proxy andando ad inserire uno strato di Application Delivery Control per gestire le molteplici applicazioni che compongono un servizio ed offrire un motore di analisi full-L7 del traffico dati. Con la soluzione LBL ADC agendo come Full Reverse Proxy, tutte le connessioni che attraversano lo strato di bilanciamento vengono terminate e costantemente analizzate e catalogate identificando eventi anomalie e attuando delle azioni a garanzia della continuità di erogazione. Il sistema, in tutte le sue componenti, è stato progettato per essere utilizzato in ambienti mission-critical e business-critical con specifiche stringenti di criticità e confidenzialità.

LBL Application Delivery Controller – HTTP Content Rewriting

LBL Application Delivery Controller implementa nativamente le funzionalità di full reverse-proxy. Con LBL Application Delivery Controller è possibile ispezionare, variare o indurre un cambiamento di comportamento sia a livello di HTTP Header sia a livello di HTTP Body (full content-rewriting). Il sistema permette di utilizzare a più livelli le funzionalità di rewriting, sia attraverso parametrizzazione sia attraverso il linguaggio di programmazione. Queste due funzionalità sono state studiate per lavorare sia autonomamente sia contemporaneamente. E’ quindi possibile utilizzare delle regole descritte a livello di interfaccia grafica e utilizzare dei propri programmi, come estensione di classi messe a disposizione dalla libreria LBL Application Delivery Controller, e permettere in maniera agevole e controllata di effettuare modifiche, comprese modalità binaria, durante il forwarding delle informazioni. Le funzionalità descrittive a livello di interfaccia grafica e le estensioni delle parti programmatiche possono collaborare contemporaneamente in modo da unire la praticità dei parametri alla logica di un vero programma.

Attraverso l’interfaccia grafica ed i template è possibile effettuare la maggior parte delle attività di rewriting e si arriverà ad utilizzare le estensioni di classi solo in casi particolari o in realtà dove serve una integrazione applicativa come ad esempio integrare sistemi di Single Sign On (SSO).

Il sistema di parametrizzazione è molto semplice e utilizzabile interamente guidato da interfaccia grafica HTML 5 per descrivere le azioni da intraprendere a livello di HEADER HTTP o a livello di BODY HTTP.


Di seguito un esempio di template di rewriting che permette di verificare se la richiesta arriva in chiaro e nel caso esegue un URL redirection della stessa richiesta in SSL mantenendo tutti i parametri della richiesta originale.

Attraverso l’interfaccia è possibile controllare qualsiasi valore sia dell’HEADER sia del BODY e attraverso l’utilizzo di un semplice meccanismo di VARIABILI costruite on-the-fly è possibile ricomporre da zero qualsiasi situazione partendo dai dati provenienti dallo streaming.

Già in questa sequenza di template di rewriting è possibile apprezzare le potenzialità dello strumento senza intervenire con strumenti di programmazione. A livello di programmazione è comunque possibile utilizzare in forma di “metodo” tutte le possibilità offerte dall’interfaccia ed è inoltre possibile utilizzare le variabili dichiarate mettendo a disposizione un vero linguaggio tutte le possibilità logiche che questo offre.

Le variabili possono trarre il loro valore da diverse sorgenti. I dati più frequenti possono essere caricati attraverso delle INNERVARIABLE già pronte all’utilizzo. Per evitare overhead di sostituzione di stringhe e permette di crescere nel tempo con il numero di valori preparati e pronti all’uso le INNERVARIABLE devono essere caricate in una VARIABLE. Questa funzionalità è stata pensata da progetto per non avere limiti futuri nell’implementazione di valori precostituiti e facili da utilizzare (una totale trattazione si può trovare nel manuale “Content Rewriting How To” e nel manuale “Reference Guide”).

Il rewriting del BODY da un punto di vista di utilizzo è molto simile al funzionamento del rewriting dell’HEADER. Da un punto di vista tecnologico il suo trattamento è molto più articolato perché deve prevedere di modificare il protocollo on-the-fly senza l’utilizzo di cache, per evitare memorizzazione di dati sensibili, ed andando ad agire nei contenuti e variandone quindi le dimensioni. LBL Application Delivery Controller utilizza quanto di meglio mette a disposizione la tecnologia per permettere di modificare a piacimento ed in maniera consistente i dati che attraversano lo strato di bilanciamento. In maniera consistente perché la frammentazione viene dettata dalla tipologia del dato che viene trasferito (mime-type) e quindi entrando nel merito applicativo in maniera automatica.

Di seguito un’immagine di parametrizzazione che inserisce nel body una porzione di codice javascript a supporto di implementazione di statistiche google analytics.

In conclusione le caratteristiche di rewriting coniugano la semplicità della parametrizzazione e la profondità d’intervento mettendo a disposizione uno strumento facile da utilizzare direttamente da WEB.

LBL Application Delivery Controller – L4 TCP/UDP binary Content Rewriting

LBL Application Delivery Controller permette di gestire completamente il ciclo di content-rewriting a layer 4 (TCP/UDP). Il sistema è stato studiato per poter identificare porzioni di protocollo e poter agire in modalità full-binary. Un esempio lo possiamo trovare nel template di content rewriting LBLTCPCIFS (nell’immagine di seguito) che modifica on-the-fly il bit vcnumber (little endian) del protocollo SMB1.0 che permette di bilanciare il protocollo.

LBL Application Delivery Controller – SSO Integration

Centralizzare le politiche di accesso semplifica le procedure di sicurezza e di autorizzazione di accesso ai dati e alle applicazioni. L’implementazione in ambienti complessi, dove Single Sign On e Access Control Management troverebbero una naturale collocazione, spesso causano problemi di complessità nella distribuzione e mantenimento nel tempo dei plugin di enforcement bloccando l’intera evoluzione dell’infrastruttura. La posizione strategica della componente LBL Application Delivery Controller permette di verificare le rispondenze autoritative derivate dal modulo di “Richiesta di servizio” e “Punto di erogazione”.

Con LBL Application Delivery Controller è possibile integrare un unico punto di controllo accessi di tutte le applicazioni web e gestire quindi notevoli quantità di servizi senza appesantire successivamente le attività di esercizio e aggiornamento naturale delle applicazioni. Attraverso il sistema LBL Developer (descritto in precedenza) è possibile sviluppare rapidamente le interfacce verso i sistemi IM (Identity Management) e ACM (Access Management). La possibilità di eseguire attraverso LBL Developer lo sviluppo ed il debug dei codici prodotti conferisce stabilità e consistenza riducendo drasticamente i costi di implementazione ed i tempi di produzione. Con questo sistema è possibile integrare velocemente tecnologie di Identity Management e Single Sign On riducendo i layer (eliminazione dei plug-in di enforcement) semplificando drasticamente le architetture e riducendo i tempi di manutenzione.

LBL Application Delivery Controller – Protocol correction

In alcune circostanze, specie in presenza di layer di ‘URL Rewriting’ è necessario correggere i contenuti dell’HEADER HTTP.

LBL Application Delivery Controller implementa la correzione di protocollo per l’identificazione del mime type nel caso questi non sia conforme alle specifiche HTTP1.0 e HTTP1.1. Questa funzionalità consente ai sistemi di rewriting di interpretare correttamente il tipo di contenuto e quindi effettuare le opportune azioni di riscrittura.

Questa funzionalità è attivabile solo se necessaria, normalmente LBL Application Delivery Controller non effettua alcuna modifica dei valori trasportati con il protocollo HTTP essendo conforme alle specifiche W3C di ‘Gateway trasparente’. In HTTPS i valori possono essere modificati secondo le regole di URL rewriting per i soli dati relativi all’HEADER.

LBL Application Delivery Controller – Dynamic Address Listen & Network Adapter Translation

I sistemi di listening e monitoring gestiscono la possibilità di variare dinamicamente l’indirizzo o la scheda di rete su cui si accettano le connessioni.

Questa funzionalità facilita la riconfigurazione dei sistemi senza che LBL Application Delivery Controller debba essere riparametrizzato o riavviato mantenendo quindi i dati di sessione.

– Dynamyc Address Listen (DAL)-

A1– Scheda di rete eth0 indirizzo 129.172.59.10

A2– Set scheda di rete eth0 con nuovo indirizzo 192.168.83.22

– Network Adapter Translation (NAT)-

B1– Scheda di rete eth0 con indirizzo di rete 129.172.59.10

B2– Set eth0 down

B3– Set scheda di rete eri0 con indirizzo di rete 129.172.59.10

Questo capitolo riassume i comportamenti di LBL Application Delivery Controller se durante il run-time vengono modificati o spostati di interfaccia gli indirizzi IP sui quali i listener stanno insistendo per fornire i servizi di bilanciamento. Queste politiche vengono anche utilizzate dalle versioni Standard ed Enterprise per fornire le funzionalità di fail-over e garantire quindi continuità di servizio. “listenType” è il parametro che determina le politiche di utilizzo dei listeners e può assumere quindi i seguenti valori.

ListenType = STATIC (default)

DAL (Dynamic Address Listen)

NAT (Network Adapter Translation)

  1. STATIC: Associazione rigida indirizzo/interfaccia di rete. Questa associazione, già presente nella versione 1.1, fornisce una associazione fissa tra il listener e l’indirizzo IP. Nel caso si dovessero verificare modifiche di indirizzo o malfunzionamenti della interfaccia di rete LBL Application Delivery Controller cessa di erogare il servizio per quell’indirizzo di rete. Questa modalità è il DEFAULT se non indicato esplicitamente.
  2. NAT Network Adapter Translation: Permette ad LBL Application Delivery Controller di adattare i listeners sullo stesso indirizzo anche se durante il run-time questo indirizzo è stato spostato da una interfaccia ad un’altra.
  3. DAL Dynamic Address Listen: La funzionalità DAL permette ad LBL Application Delivery Controller di specificare una interfaccia di rete, fisica o logica, e la posizione di uno degli indirizzi IP associati. Al modificarsi dell’indirizzo IP LBL Application Delivery Controller rileverà la variazione ed effettuerà un nuovo bind con il nuovo indirizzo chiudendo il precedente. Questa funzionalità è particolarmente utile in quei casi ove l’indirizzo di rete viene riassegnato dinamicamente, DHCP, oppure per creare temporaneamente dei “bridge” su reti ADSL offrendo un unico punto d’ingresso ai servizi del back-end.

LBL Application Delivery Controller Network Federation & Automatic Role Assumption (Hot-Plug Nodes)

Questa caratteristica, nelle versioni Standard ed Enterprise, permette a LBL Application Delivery Controller di autoconfigurarsi nel ruolo di Master o Sleeper o, nella distribuzione LBL Application Delivery Controller Enterprise Edition, di aggregarsi in maniera spontanea alla community di nodi già in funzione. Proprio questa funzionalità permette a LBL Application Delivery Controller Enterprise Edition di aggiungere nodi on-the-fly aumentando la capacità di throughput senza limiti teorici e senza discontinuità di servizio.

Una installazione tipica di LBL Application Delivery Controller Standard Edition in un ambiente mission-critical potrebbe assumere la seguente configurazione. L’esempio riportato evidenzia anche la possibilità di LBL Application Delivery Controller di poter utilizzare più sleeper per aumentare la disponibilità attraverso ridondanza multipla. Anche in questo caso l’aggiunta di un ulteriore Nodo, per manutenzione o upgrade, si può effettuare a caldo on-the-fly senza interrompere i servizi.

In caso di failure di uno dei nodi il sistema di LBL Application Delivery Controller Automatic Role Assumption ripristina la condizione di migliore funzionamento.

LBL Application Delivery Controller – UDP protocol

LBL Application Delivery Controller è dotato di uno strumento per eseguire il bilanciamento dei pacchetti UDP. Il servizio è altamente parallelizzato prevede anche il modulo di rewriting per poter intervenire sia sui contenuti sia sull’instradamento dei pacchetti.

E’ possibile intervenire nel flusso dati rimodulando durante il runtime gli endpoint di instradamento anche in dipendenza dei pacchetti dati ricevuti.

Anche con il protocollo UDP è possibile realizzare il bilanciamento con la gestione della sessione.

LBL Application Delivery Controller – Business Continuity & Disaster Recovery

Una delle caratteristiche peculiari di LBL Application Delivery Controller è la possibilità di utilizzo in architetture che prevedono un sito di Business Continuity o Disaster Recovery. La modularità che contraddistingue l’architettura permette infatti di sfruttare a seconda delle necessità, topologia della rete e dalla disponibilità di banda una soluzione completa per automatizzare processi e rendere altamente disponibile l’erogazione dei servizi.

Nell’esempio di seguito sfruttando la possibilità di attribuzione gerarchica del Master, è possibile attivare in qualsiasi momento il sito di Disaster Recovery in campus reindirizzando le richieste in maniera automatica o manuale verso i propri servizi. Lo switch manuale o automatico è determinato dal valore gerarchico (Weight) dell’istanza LBL Application Delivery Controller.

Nell’immagine e nei parametri di seguito si possono osservare le caratteristiche che permettono di effettuare questa operazione in maniera semplice quanto efficace:

Ogni istanza LBL Application Delivery Controller può essere parametrizzata per:

  1. Group = E’ il nome del gruppo di appartenenza al cluster. Con nomi diversi possono esserci più gruppi di cluster indipendenti che condividono la stessa rete
  2. SubGroup = E’ il sottogruppo di propagazione delle informazioni di instradamento delle sessioni verso il backend
  3. Weight = Peso che determina la gerarchia di attribuzione dello stato di Master dei nodi attivi
  4. Start = Il tipo di start all’avvio del sistema. Automatic significa che il bilanciatore si avvia automaticamente allo start del sistema, Manual significa che serve un’operazione comandata da un operatore per rendere operativo il nodo di bilanciamento
  5. Status = E’ lo stato del nodo in un momento specifico

Si noti che nel Sito principale sono stati attivati in maniera automatica entrambi i nodi di bilanciamento ed essendo il nodo 101 quello con “Peso” maggiore questi si è attribuito in automatico anche il controllo degli indirizzi virtuali che servono ad instradare le richieste applicative verso il proprio back-end.

Il nodo posto sul sito di DR detiene il Peso più alto della gerarchia di attribuzione degli indirizzi virtuali ma, essendo in stato di “stopped” (inattivo), non viene considerato nel pool di bilanciamento. Inoltre anche eventuali restart dei sistemi di DR non altererebbero questa situazione essendo stato impostato ad un avvio manuale e quindi comandato esplicitamente da un operatore. Questa è una situazione ideale per un sito di DR. Infatti lo “switch” dei servizi dal sito principale ad un sito secondario è normalmente una decisione puntuale ed umana, determinata o da eventi eccezionali oppure da simulazioni schedulate per determinare l’efficacia dell’impianto in caso di eventi eccezionali.

Dal punto di vista prettamente di switch delle richieste di servizio dal Sito principale al sito di DR è sufficiente collegarsi al Sito di DR attraverso la connessione sicura della LBL WebConsole di LBL Application Delivery Controller e attivare il nodo di bilanciamento con l’apposito pulsante di Start: Avendo il nodo in DR un “Peso” più elevato tra i nodi attivi, gli indirizzi virtuali verranno migrati verso il nodo di DR dirottando quindi tutte le richieste di servizio verso i relativi servizi applicativi di back-end.

Per ripristinare le richieste sul sito principale sarà sufficiente eseguire, tramite LBL WebConsole, lo stop del processo di bilanciamento nel nodo di DR.

Ritornando il nodo di DR in stato di Stopped, il nodo con peso maggiore nel Sito principale si riattribuirà il controllo degli indirizzi virtuali facendo quindi transitare le richieste di connessione attraverso i propri servizi di back-end.

Altre architetture di Disaster Recovery sono possibili. A titolo di esempio di seguito un’immagine con architettura di mutual Disaster Recovery. In questo caso due siti indipendenti e attivi forniscono servizi di mutual Disaster Recovery. La duttilità fornita dallo strato di virtualizzazione permette a LBL Application Delivery Controller di adattarsi in diversi scenari con Semplicità implementativa.

LBL Application Delivery Controller – Service mapping

Con LBL Application Delivery Controller è possibile associare, attraverso identificatori, i servizi applicativi alle rispettive risorse che li compongono. In questo modo è possibile correlare l’erogazione di un servizio alle varie componenti applicative che lo compongono. In alcune occasioni infatti, pur essendo operativi i servizi posti in bilanciamento, potrebbero indirettamente essere indisponibili per failure/manutenzione delle risorse ad essi associati. Si pensi ad esempio ad alcune applicazioni web che afferiscono ad un DataBase, ad un directory server e ad un file system condiviso. Pur essendo i servizi web attivi il DataBase, il direcotory server o il file system condiviso potrebbe essere fuori servizio e quindi anche i servizi web ad essi associati saranno, al loro volta, fuori servizio pur rispondendo correttamente alla connessione.


Questa funzionalità è molto interessante perché permette di catalogare contestualmente i servizi tecnologici con i servizi di business e identificare velocemente le correlazioni. È possibile quindi intervenire a livello di TAG per porre fuori servizio in maniera coordinata interi set applicativi o semplici end-point per manutenzione programmata o routing alternativi in caso di fail-over senza che gli altri servizi siano coinvolti.

LBL Application Delivery Controller – Courtesy message

In caso di attività programmate ai servizi di backend, ad esempio per aggiornamento software delle applicazioni, è a volte necessario interrompere l’erogazione dei servizi o parte di essi. Attraverso la funzionalità di interazione è possibile bloccare temporaneamente le richieste con le modalità descritte nel capitolo specifico “Integrazione con sistemi di monitoring di terze parti: External event Communication”. Di default LBL Application Delivery Controller si comporta in due modi a seconda che si tratti di comunicazione Layer 4 o comunicazione Layer 7 HTTP/S.

Nel caso di comunicazione layer 4 LBL Application Delivery Controller non può fare altro di accettare la connessione, verificare che nessun servizio richiesto sia attivo e nel caso chiudere la comunicazione appena intrapresa.


Nel caso invece la comunicazione sia a layer 7 HTTP/S LBL Application Delivery Controller ritorna una pagina HTML con l’indicazione generica di indisponibilità di servizi.


E’ possibile modificare il file HTML e proporre all’operatore un messaggio che contenga le indicazioni della mancata erogazione del servizio in modo da limitare il più possibile il ricorso all’help desk e dare una puntuale informazione all’operatore. L’operazione di modifica è effettuabile direttamente da interfaccia HTML 5.

LBL Application Delivery Controller – Scalabilità della Soluzione e Capacity on Demand

L’hardware best performance industry oggi a disposizione ha una potenza di calcolo importante e anche il rapporto costi/performance è assolutamente a favore del best performance industry. Le CPU moderne forniscono set di istruzioni privilegiate on chip e consentono di fare encryption on chip in parallelo sui core ed in ambiente virtualizzato con performance più alte di ASICs dedicate comunque non utilizzabili in ambienti virtualizzati.

La soluzione LBL Application Delivery Controller è una soluzione software che può essere installata su server e sui più comuni ambienti di virtualizzazione quali VMware, Hyper-V, KVM, Oracle VB,… E’ in grado di creare multiple istanze software isolate tra di loro a cui sono assegnate proprie risorse hardware.

A differenza delle tradizionali appliance, che vanno periodicamente sostituite per disporre di migliori prestazioni e nuove funzionalità, LBL Application Delivery Controller può evolvere nel tempo in funzione dell’hardware impiegato ed è in grado di sfruttare le migliori tecnologie che il mercato mette a disposizione.

LBL Application Delivery Controller è nato nell’era della virtualizzazione, di cui sfrutta al meglio le caratteristiche e la flessibilità, e può quindi essere utilizzato:

  • su infrastrutture fisiche o virtuali già disponibili
  • come componente essenziale di piattaforme di Unified Computing (Cisco UCS, HDS UCP)
  • in ambito cloud (AWS, MS Azure,…)
  • in ambienti di iperconvergenza

LBL Application Delivery Controller utilizza una raffinata tecnologia di core parallelization raggiungendo performance elevatissime e consentendo una scalabilità dei sistemi:

  • Può essere installato su macchine multiprocessore (X64 o RISC)
  • Può utilizzare RAM con scalabilità impensabili fino a pochi anni or sono
  • Può sfruttare connessioni di rete Ethernet (su rame o su fibra ottica) o InifiniBand e quindi garantire throughtput elevatissimi
  • In contesti di cloud LBL Application Delivery Controller consente di gestire perfettamente le risorse di networking (DNS dinamici) e ben si adatta ai modelli di business (capacity on demand, pay per use)

L’innovativo sistema di rilevamento dei carichi applicativi permette di associare alle politiche di bilanciamento azioni infrastrutturali di gestione delle risorse. LBL Application Delivery Controller è nato nell’era della virtualizzazione e permette di eseguire specifiche azioni al variare della quantità delle richieste di servizio. Al verificarsi di particolari picchi di richieste è possibile aumentare dinamicamente (Capacity on Demand) le risorse comandando lo start di ulteriori servizi applicativi permettendo di superare il momento critico. Al verificarsi del picco è quindi possibile eseguire sull’infrastruttura lo start di macchine virtuali per far fronte alle richieste e al diminuire delle richieste è possibile liberare risorse spegnendo le istanze virtuali non più necessarie e tornare allo stato iniziale.

Questo garantisce grande flessibilità nella integrazione di soluzioni fisiche e virtuali. La possibilità di suddividere in più istanze virtuali specializzate consente di ottenere livelli di sicurezza e segregazione elevatissimi. Ogni Guest può accedere alle risorse hardware assegnate ed è completamente separato dagli altri.

In caso di necessità temporanee/emergenze, inoltre, la soluzione LBL Application Delivery Controller consente di distribuire le licenze/istanze su più nodi senza interruzione nella erogazione dei servizi fino al rientro della fase di emergenza e quindi al ritorno allo stato di normalità di esercizio.

Hot-Exporting of Load Balancing Processes Instances LBL consente la creazione della copia compressa di una intera istanza di bilanciamento e instradamento a scopo di:

  • backup;
  • spostamento su altri nodi;

creazione di template da utilizzare in contesti simili a quello di partenza.

Hot-Importing of Load Balancing Processes Instances in Different Physical/Logical Node LBL consente di importare intere istanze di bilanciamento e instradamento create in precedenza.

Questa funzione è estremamente utile in caso di:

  • spostamenti di risorse da un nodo ad un altro;
  • creazione di nuove istanze a partire da template preesistenti.

LBL Application Delivery Controller – WAF signature OWASP

LBL Application Delivery Controller integra la componente di Web Application Firewall basata su signature ed in grado di proteggere le applicazioni web e contrastare le minacce OWASP.

Il sistema è stato realizzato considerando le capacità di calcolo delle risorse assegnate alla macchina creando una classifica degli attacchi diminuendo al massimo il degrado delle prestazioni e quindi la user-experience assicurando nel contempo la massima efficacia di sicurezza.

In caso di violazione o detect di una regola, questa viene loggata nel sistema di logging e in una apposita tabella delle violazioni rilevate.

La parametrizzazione è semplicissima essendo il componente integrato nella piattaforma.

Attack prophecy

LBL Application Delivery Controller integra la componente di Web Application Firewall basato su analisi comportamentale (Machine Learning) e denominata Attack Prophecy*. Una soluzione di nuova generazione per la rilevazione delle minacce verso i servizi web e l’attuazione dei corrispondenti meccanismi di difesa e protezione che sfrutta le ultime tecnologie nel campo dell’apprendimento automatico e dell’analisi comportamentale (Pattern Recognition & Machine Learning), per identificare, oltre ad attacchi esistenti, nuove minacce in maniera efficiente e scalabile.

L’algoritmo di Attack Prophecy (Machine Learning) permette la rilevazione/intercettazione di attacchi informatici anche particolarmente sofisticati e specifici per i servizi web attaccati anche con grossi volumi di traffico.

La soluzione LBL Application Delivery Controller grazie ad Attack Prophecy non ha quindi obbligatoriamente la necessità di reperire firme (signature) e costanti aggiornamenti dall’esterno ma è in grado di costruire uno strato di protezione su misura per i servizi monitorati, in maniera totalmente autonoma.

Il paradigma “Anomaly-based“, su cui è basato l’algoritmo Attack Prophecy, permette quindi, attraverso l’analisi del profilo di traffico, di rilevare diverse categorie di attacco, da quelle legate a vulnerabilità intrinseche dei servizi a quelle più generali e diffuse quali OWASP top 10 e aspetto fondamentale essendo in grado di rilevare minacce zero-day.

*Attack prophecy is powerd by PluribusONE

LBL Application Delivery Controller – Network Freezing

La funzionalità di Network Freezing nasce dalla necessità di trovare un punto di sincronizzazione su “processi” asincroni. In alcune circostanze infatti è necessario generare un istante T0 per avere un “momento” in cui tutte le applicazioni siano consistenti tra loro. Questa funzionalità può trovare una ideale collocazione in architetture a BUS software dove le applicazioni si scambiano “transazioni” asincrone.

In queste situazioni le applicazioni instradano le loro “transazioni” attraverso il BUS software per essere poi recapitate, attraverso delle regole esterne all’applicazione stessa, verso altre applicazioni. Questa architettura è applicata per diverse ragioni in moltissime circostanze sia locali che geografiche. Se geografiche le ragioni sono derivate dalla logistica come la disponibilità di throughput, la disponibilità della rete, l’interfacciamento con altre applicazioni. Se locali invece le ragioni sono molto spesso legate all’interfacciamento con altre applicazioni e alla necessità di scalare per motivi di performance. In quest’ultimo particolare scenario, peraltro molto diffuso, non essendo le transazioni in two-phase-commit non si riesce a trovare un momento consistente per effettuare ad esempio un full-backup rendendo molto difficile, se non addirittura impossibile, la ricostruzione totale degli archivi in caso di necessità (roll-back).

Con questa funzionalità LBL Application Delivery Controller riesce a mettere a disposizione uno strumento per “bloccare il tempo” in un determinato “istante” permettendo di eseguire in maniera consistente tutte le operazioni necessarie.

LBL Application Delivery Controller – DB traffic & log trace

La generazione delle statistiche, ad opera del processo nucleo LBL Application Delivery Controller, trova persistenza all’interno di un Database Relazionale. Tutte le statistiche visualizzate sulla LBL WebConsole sono ricavate dal Database e sono solo una sintesi delle statistiche che si possono ricavare dai dati contenuti nel Database.

Da un punto di vista architetturale i layer che realizzano la storicizzazione delle statistiche sono:

  1. Generazione e caching in memoria (1° livello)
  2. Caching su memoria persistente (2° livello)
  3. Caching Transazionale su servzio Web (LBL StatisticsBrokerWebCache 3° livello))
  4. Popolamento Transazionale su Database Relazionale

Questi layer sono stati realizzati per permettere la massima scalabilità e un bassissimo impatto con il servizio core di bilanciamento anche in presenza di altissimi volumi di traffico.

La Transazionalità inoltre permette di poter storicizzare i dati per servizio senza perdere informazioni. Cosa necessaria nel caso queste informazioni servano a processi di fatturazione in base al traffico generato.

Anche con questa nuova implementazione LBL Application Delivery Controller resta semplice da installare e non aggiunge nuove impostazioni nella sua installazione di base. Nel caso si volessero centralizzare le statistiche del traffico generato, si possono separare su altri nodi i servizi di LBL StatisticsBrokerWebCache e Database e quindi visualizzare attraverso la LBL WebConsole o con script SQL le statistiche di più nodi LBL Application Delivery Controller.

Le statistiche visualizzabili attraverso la LBL WebConsole e immediatamente disponibili dopo l’installazione sono state scelte per verificare istantaneamente lo stato delle connessioni e il traffico generato. Per il traffico HTTP/S sono state rese disponibili 2 statistiche relative alla giornata lavorativa con un raggruppamento significativo di informazioni per verificare in maniera puntuale il traffico ed il response time per singoli servizi.

È inoltre disponibile la tabella Syslog_event che memorizza tutti gli eventi di log registrati in tutti i processi.

Le statistiche ottenibili direttamente da LBL WebConsole sono:

  1. Sessions Activity
  2. HTTP-S traffic today
  3. HTTP-S traffic avg
  4. L4 TCP traffic
  5. L4 Datagram traffic
  6. Pool queue activity
  7. Pool queue committed
  8. Connection HighWater
  9. Syslog event

Di particolare interesse è il log del traffico HTTP/S nel dettaglio fornito dalla suddivisione del response time in tempi parziali (split response time). Infatti, per poter analizzare eventuali inefficienze il response time viene suddiviso in:

RESPONSE_TIME bigint E’ il response time del servizio richiesto Valore espresso in nanosecondi.
LAP_TIME_A bigint Tempo compreso tra la fine della lettura dell’HEADER del client e l’inizio della connessione verso l’endpoint Valore espresso in nanosecondi.
LAP_TIME_B bigint Tempo di connessione all’endpoint Valore espresso in nanosecondi.
LAP_TIME_C bigint Tempo tra la connessione avvenuta all’endpoint e l’inizio della lettura dell’HEADER di risposta. Se il client invia il body è il tempo di trasmissione del body dal client all’endpoint. Valore espresso in nanosecondi.
LAP_TIME_D bigint Tempo di lettura dell’Header dell’endpoint. Valore espresso in nanosecondi.
LAP_TIME_E bigint Tempo tra la fine della lettura dell’Header e la fine dei dati in risposta Valore espresso in nanosecondi.

LBL ADC Embedded reports

LBL ADC mette a disposizione una serie di reports direttamente dalla console HTML5 che permettono di effettuare con semplicità le più importanti verifiche sul traffico dati con possibilità di drill-down per selezioni successive. L’utilizzo è semplicissimo e permette un immediato riscontro delle attività con una profondità temporale impostabile dall’utente.



LBL DNS & Proxy Manager

LBL DNS & Proxy Manager è il nuovissimo ed innovativo prodotto che consente di impostare dinamicamente le associazioni nome<>indirizzi sul DNS verificando costantemente la raggiungibilità e operatività dei servizi applicativi. LBL DNS & Proxy Manager permette di mantenere costantemente aggiornati in maniera autonoma più nodi DNS per avere sempre a disposizione la più attuale immagine della topologia dello stato della rete e dei servizi ad essa associati. LBL DNS & Proxy Manager rende possibile la realizzazione di infrastrutture di alta affidabilità, Business Continuity e Disaster Recovery in maniera semplice quanto efficace. LBL DNS & Proxy Manager è anche il giusto complemento a LBL Application Delivery Controller Enterprise HA potendo gestire diversi indirizzi DNS in RoundRobin in maniera dinamica presentando ai client l’effettiva disponibilità di instradamento. LBL DNS & Proxy Manager è rilasciato con il proprio DNS o per cooperare con i DNS preesistenti nell’infrastruttura BIND (https://www.isc.org/) e MS DNS.

LBL DNS Global Load Balancer & Firewall

LBL DNS Global Load Balancer è il sistema di bilanciamento, instradamento e filtraggio (DNS firewall) del traffico DNS/DNSSEC a layer 7 OSI UDP/IP TCP/IP. Il sistema permette di instradare le richieste in base ai contenuti ed in base ad eventi contingenti che possono essere rilevati sia manualmente sia automaticamente. Il sistema è stato studiato per architetture di business-continuty e disaster-recovery ed è in grado di modificare dinamicamente le risposte dei DNS in base alla disponibilità dei servizi.

LBL DNS Global Load Balancer, analizzando a livello semantico le richieste e le risposte, può instradare le richieste su differenti DNS Server in base ai contenuti e modificare le risposte in base alla provenienza o in base ad eventi contingenti come ad esempio l’indisponibilità di un servizio.

Il sistema è basato su un sistema “DICHIARATIVO” e un sistema ad “EVENTI”. Per questo motivo LBL DNS Global Load Balancer è in grado di predisporre le risposte provenienti dai DNS per essere reattive in caso di procedure di business-continuity o disaster-recovery diminuendo i tempi di fail-over in caso di necessità.

Le funzionalità DNS Firewall permettono di filtrare richieste e risposte instradando le richieste e risposte malevole o indesiderate verso dei “black-hole” che non rallentano la fruizione dei contenuti. E’ possibile condizionare richieste e risposte attraverso liste di siti indesiderati o liste di siti che possono essere utilizzati. Questa ultima funzionalità permette di attribuire a particolari dipartimenti sensibili delle “white-list” di siti consultabili e rendere più difficile l’attivazione di virus malware ed evitare fenomeni di data Exfiltration.

Tutto il traffico gestito da LBL DNS Global Load Balancer può essere finemente tracciato per analisi comportamentali e determinazione di anomalie individuando le sorgenti delle anomalie.


Con LBL DNS Global Load Balancer è possibile diminuire le attività di tracing indesiderate da parte di terzi intercettando le attività di sistemi analitici di profilazione comportamentale bloccando centralmente banner pubblicitari (adsblock) pop-up malware.

Le funzionalità LBL DoS/DDoS attack mitigation possono essere attivate per proteggere efficacemente i DNS server bilanciati da LBL DNS Global Load Balancer intervenendo quando i sistemi cominciano a presentare problemi di sofferenza.

LBL DNS Global Load Balancer è efficacemente utilizzato in infrastrutture cloud ibride potendo essere installato in cloud e mantenendo i DNS autoritativi nei datacenter dell’organizzazione introducendo una affidabilità altissima ed indipendente dalla zolla tettonica in cui sono presenti i datacenter.

LBL Traffic Monetizer

Il governo e controllo di un sistema informativo complesso nasce dalla necessità di garantire nel tempo uno standard qualitativo elevato con tempi e costi misurabili. Un datacenter ha come obiettivo l’erogazione di servizi informativi ed attuativi, oggi chiamati anche servizi self-service, rivolti ad un grande pubblico e che devono soddisfare alcuni requisiti come Sicurezza ed Affidabilità.

LBL Traffic Monetizer consente il monitoring di come le applicazioni stanno performando, implementando un tracing profondo dei parametri richiesti per una puntuale analisi e fornendo un reporting avanzato.

Grazie alle avanzate funzionalità di traffic management e analisi in tempo reale del traffico dati consente di ottimizzare le performance delle applicazioni.

LBL Traffic Monetizer dispone di un raffinatissimo motore di popolamento e aggregazione di dati analitici e transazionali per enormi volumi di dati a supporto di piattaforme enterprise di Business Intelligence, contabilizzazione e/o fatturazione.

LBL Traffic Monetizer utilizza un database relazionale per storicizzare le statistiche di traffico. Il database ed il suo gestore possono essere eventualmente installati separatamente dal servizio di bilanciamento per poter consolidare le statistiche di traffico provenienti da diversi nodi. Gli stessi dati analitici provenienti dai sistemi di bilanciamento possono essere aggregati ed analizzati in maniera differente e contemporaneamente per soddisfare le esigenze di verifica applicativa, di networking, di utilizzo delle applicazioni e ottemperanza degli SLA nell’analisi delle intrusioni e phishing.

LBL Traffic Monetizer è in grado di rilevare dati temporali su risposte sia di sistema che applicative analizzando tutte le fasi del traffico, dall’acquisizione della richiesta alla fase di connessione al servizio fino alla rilevazione dell’ultima informazione spedita dal servizio ai client, misurando i tempi di risposta dei singoli servizi con split sui layer infrastrutturali ed individuando tutti gli elementi della catena sia infrastrutturali che applicativi.

L’analisi del ciclo di vita del dato permette di isolare tempestivamente anomalie infrastrutturali a più livelli evidenziando le zone di intervento per il miglioramento della fruibilità dei servizi. Attraverso l’interfaccia grafica è possibile verificare per ogni modulo il profilo corrente, lo stato e visualizzare i logfile. E’ possibile inoltre avviare o fermare il modulo e notificare via email l’evento (watchdog). Questo permette di rilevare eventuali anomalie, anche applicative, per una immediata azione correttiva.

L’analisi dei dati evidenza non solo le performance assolute delle applicazioni ma permette anche di scindere le varie fasi dell’evoluzione del servizio in più elementi, come ad esempio il tempo di connessione, di prima risposta ed in generale dei tempi parziali di attraversamento delle informazioni, permettendo una diagnosi precisa del problema. La raffinatezza dei dati raccolti con granularità al nanosecondo (miliardesimo di secondo), permette di eseguire approfonditi test sul traffico rilevando anche i tempi intermedi di percorrenza dell’informazione attraverso i layer architetturali.

Di seguito un esempio di analisi del traffico dati che evidenzia in grafico i valori di attraversamento delle informazioni. Nel riquadro “Traffico normale” è possibile apprezzare un aumento dei dati di traffico ma una regolarità nei tempi di risposta dell’infrastruttura.

Traffico normale

Nel riquadro di seguito si nota un aumento del traffico e dei tempi di riposta a seguito di problemi nei servizi di backend identificati dalle colonne rosse che indicano una criticità nel raggiungere il servizio (aumento dei tempi di connect verso il servizio).

Traffico anomalo

L’analisi dei tempi di attraversamento della richiesta e della risposta (Response-Time) sezionati in tempi parziali (Lap-Time) permette una analisi precisa per l’identificazione di colli di bottiglia e pone le basi per la loro soluzione.

L’architettura permette la scrittura, il consolidamento e l’aggregazione in tempo reale di diversi milioni di record all’ora fornendo ai sistemi di analisi e reporting delle viste e set di dati immediatamente fruibili. LBL Traffic Monetizer viene fornito di template di consolidamento in formato sorgente da cui è possibile personalizzare e adattare ulteriori interpretazioni dei dati di traffico garantendo flessibilità di utilizzo e crescita nel tempo.

LBL Traffic Monetizer è integrabile su diverse piattaforme di Business Intelligence e sistemi di monitoraggio.

LBL Traffic Monetizer Light – Analisys & Reports

LBL Traffic Monetizer Light è il sistema di analisi e reporting dei dati di traffico e logging inferiore a 3 milioni di hits al giorno (24 ore). Il sistema viene fornito direttamente su una Virtual Appliance ed è possibile utilizzarlo direttamente con un breve setup ridirezionando tutti i dati di traffico e log dai sistemi della suite LBL S.A.A.I. verso la il broker LBL Traffic Monetizer Light.

Per facilitare il deploy, la Virtual Appliance LBL Traffic Monetizer Light contiene preinstallato e configurato un Database e un sistema di reportistica con Business Intelligence comunque sostituibili con altre piattaforme nel caso l’utente finale voglia utilizzare diversi DB o Business Intelligence.

Con LBL Traffic Monetizer Light vengono distribuite delle query di esempio in forma sorgente che possono essere personalizzate a piacere per poter estrapolare dalla base dati informazioni o viste differenziate in relazione alle richieste del business e fornire nuovi reports.

LBL Traffic Monetizer Light ha pre-installato e configurato il conosciutissimo e apprezzato TIBCO jasperreport server. Al suo interno sono forniti innumerevoli report in forma sorgente che possono essere personalizzati a piacimento essendo lo strumento molto noto e semplice da usare.

LBL Commander

LBL Commander introduce un nuovo concetto di alta affidabilità in ambito applicativo andando a ricoprire il ruolo di coordinatore delle attività in un datacenter mission-critical. LBL Commander è composto da due moduli principali: LBL Commander Work Flow, l’esecutore dei flussi di lavoro, e LBL Commander Decision Engine, motore decisionale in grado di innescare flussi di lavoro. I due moduli sono stati progettati per lavorare in cooperazione tra loro oppure, nel caso non siano richieste delle operazioni automatiche, il solo componente LBL Commander Work Flow. LBL Commander Decision Engine è stato progettato per cooperare con LBL Application Delivery Controller.

LBL Commander – Work Flow

La flessibilità di utilizzo di questo componente deriva dalla capacità di descrivere semplicemente dei e quindi poterli gestire attraverso un’interfaccia grafica fruibile da un qualsiasi browser.

La possibilità di descrivere i processi, provarli, collaudarli e documentarli è fondamentale nelle attività mission-critical dove alcune procedure vengono utilizzate solo in casi di effettiva necessità ed in momenti che non possono essere scelti a priori. In questi casi è fondamentale avere dei punti di riferimento precisi con il minor numero possibile di azioni da effettuarsi in un contesto che permetta di verificarne costantemente lo stato di avanzamento.

Questo risultato si può ottenere con diverse tecniche che normalmente si riassumono in un manuale con un insieme di procedure, spessissimo “script”, che devono essere utilizzati in sequenze prestabilite. Un grosso limite di queste tecniche è dato dall’aggiornamento delle procedure e dalla non omogeneità dell’operatività. Altro grosso limite è rappresentato dal fatto che spesso questi script assumono dimensioni e complessità molto elevate dovendo incorporare sia la logica sia l’azione diventando spesso poco mantenibili.


La soluzione che proponiamo è una strutturazione delle attività in un Work Flow che descriva in maniera molto semplice le azioni da intraprendere e dove la logica della sequenza in cui vengono eseguite le operazioni sia esterna agli script/programmi. Altra importante caratteristica è la possibilità di ripercorrere in maniera semplice i vari step del Work Flow in modo da verificarne a priori e in maniera inequivocabile gli effetti una volta avviato.

Come overview abbiamo pensato che proprio la visione delle interfacce Uomo-Macchina sia la migliore dimostrazione dell’efficacia dello strumento. Tutte le azioni che vengono intraprese attraverso l’interfaccia sono in realtà dei comandi remoti a una istanza (RWC Remote Workflow Command) LBL Commander Work Flow Server che in maniera sicura (SSL) e autenticata svolge le operazioni. Il tutto in maniera completamente trasparente all’operatore che deve ovviamente controllare queste delicate operazioni.

Da una qualsiasi postazione è possibile collegarsi alla console LBL Monitor su cui è in esecuzione LBL Commander Work Flow oppure è possibile anche utilizzare delle postazioni LBL Monitor opportunamente impostate con i riferimenti ai server LBL Commander Work Flow.

La tracciabilità delle operazioni è assicurata a livello di infrastruttura software di base permettendo di eseguire il log delle singole azioni e scelte effettuate dall’operatore.

Tutte le operazioni sia di setup, scrittura di script, debug e di gestione sono attuabili attraverso interfaccia HTML 5.

LBL Commander – Decision Engine

LBL Commander Decision Engine è il modulo pensante della soluzione LBL Commander. Questo ambiente è stato pensato per lavorare in architetture Stretch Cluster a livello geografico. Il motore decisionale è un progetto completamente nuovo per poter aderire alle nuove esigenze e poter sfruttare al massimo le nuove risorse tecnologiche che oggi abbiamo a disposizione come ad esempio la disponibilità di connettività.

LBL Commander introduce in effetti nuovi concetti, tra tutti la separazione netta tra Work Flow (cosa si deve fare) e Decisione (quando deve essere fatto).

Queste tecnologie da sole hanno dato origine a nuovi paradigmi come il Remote Workflow Command (RWF) e determinano una programmazione modulare nel software di scripting separando la logica dalla funzionalità permettendo di creare librerie tematiche di script modulari, riutilizzabili e autodocumentabili.

L’architettura di LBL Commander Decision Engine è un’architettura molto flessibile che può essere articolata in diverse maniere e rendere possibili diversi scenari.


Una istanza LBL Commander Decision Engine può governare più sistemi di LBL Commander Work Flow con ambiti applicativi diversificati. Questa funzionalità permette di tenere sotto controllo interi datacenter con pochissimi punti di verifica diminuendo la complessità e aumentando nel contempo l’affidabilità.

LBL Commander – Decision Engine Split Brain Killers

Questo servizio gestisce in ambienti cluster distribuiti e paritetici (stretch cluster), eventuali possibilità di Split Brain e quindi di corruzione logica delle basi dati. LBL Commander Decision Engine – Split Brain Killer ha pochissimi parametri ed è quindi utilizzabile con grande semplicità. Semplicità necessaria in questi casi. Sfruttando le caratteristiche di LBL Application Delivery Controller e le interazioni con gli instradamenti è possibile con pochissimi parametri costruire le regole necessarie per verificare lo stato del cluster e quindi inibire la possibilità di Split Brain.

LBL Commander – Work Flow Remote Batch

Questo modulo è stato studiato appositamente per permettere di eseguire batch remoti, tipicamente di HealthCheck risorse, in modalità sicura. Il modulo si compone di un listener HTTP che può interpretare dei file di profilo XML per il lancio di comandi (script)/eseguibili in assoluta sicurezza.

Il Listener HTTP mette a disposizione una applicazione in grado di lanciare dei batch contenuti nel server stesso e quindi senza possibilità di modifica dall’esterno. Questo sistema fa sì che non possano essere lanciati arbitrariamente dei batch o eseguibili nella macchina bersaglio.

LBL GUI Reliability Tools –

Il test applicativo ricopre oggi un ruolo importante nel determinare l’affidabilità del software dalle fasi di pre-produzione e successivamente durante l’erogazione dei servizi.

LBL GUI Reliability Tools sono strumenti di automazione che permettono di registrare le attività di un operatore e quindi ripeterle all’infinito rilevando le anomalie che si dovessero riscontrare durante l’utilizzo.

Il sistema è formato da due elementi, un Recorder ed un Player. Il sistema di recording è composto da uno strumento visuale che registra le azioni dell’operatore e permette di intervenire, già durante la registrazione, per identificare i punti critici di confronto come ad esempio valori di riferimento o difformità di risposta dai valori attesi.




Con il Recorder è possibile provare interattivamente la registrazione, partendo da qualsiasi posizione o eseguendo la singola azione valutandone immediatamente gli effetti.

Dopo aver registrato le azioni dell’operatore, è possibile salvare ed importare le tracce su diversi Player per poterle eseguire e verificarne i risultati.


Molteplici Player sono gestiti centralmente attraverso l’interfaccia Web.

Anche le attività delle singole postazioni di test possono essere verificate centralmente attraverso l’interfaccia WEB che ripete quanto accade in ogni singolo desktop.

LBL Developer – strumenti di programmazione

Uno dei punti fondamentali di una suite è la sua programmabilità e la reperibilità di Know-How disponibile sul mercato. LBL S.A.A.I. mette a disposizione un sistema integrato di sviluppo con IDE di mercato per poter facilmente non solo programmare ma anche testare efficacemente le regole che devono poi essere distribuite in produzione.

LBL Developer è una Virtual Appliance che permette di sviluppare, testare e quindi mettere in produzione le regole sviluppate con il supporto di template e sample già disponibili in forma sorgente e pronti per essere personalizzati.

L’IDE preinstallata è Netbeans ma possono essere installate e configurate in brevissimo tempo, gli IDE che il cliente finale meglio conosce. Le regole sviluppate possono essere quindi provate step-by-step fino al loro completo funzionamento prima di essere messe in produzione. Il sistema permette inoltre di utilizzare sistemi di programmazione collaborativa (versioning) e di introdurre sistemi di qualità e sicurezza di quanto sviluppato.

Cloud IaaS OpenStack SDN

I servizi IaaS (Infrastructure as a Service) vengono oggi utilizzati dai maggiori provider Cloud per permettere la creazione di infrastrutture in base alle esigenze del singolo utente.

Come abbiamo visto la soluzione LBL S.A.A.I offre una suite di prodotti progettati per aumentare la sicurezza e l’alta affidabilità delle infrastrutture garantendo la disponibilità dei servizi applicativi. Piattaforma nata per ambienti di Virtualizzazione (NFV) e Cloud, LBL S.A.A.I. è disponibile per gli ambienti Cloud più diffusi quali Azure o Amazon (già integrato con logiche di ELASTIC-IP multi-region).

La natura delle componenti LBL S.A.A.I. permette di integrarsi in maniera spontanea in infrastrutture di servizi on demand. A questo proposito, il sistema viene fornito sia in distribuzioni come Virtual Appliance che come puro software e quindi installabile da sistemi automatizzati che partendo da template di configurazione creano l’infrastruttura desiderata.

Sei interessato alle nostre soluzioni?