The solution LBL S.A.A.I. Offers a suite of products designed to increase the high reliability of the infrastructures and the availability of application services. Platform born for virtualization environments on-premise and cloud. In 2012 was born in California also TCO Software Group Inc. in order to promote the market in the USA and to work closely with companies in Silicon Valley.
LBL Secure Application Availability Infrastructure is a solution born to solve those who today are the issues of routing and security and manage the processes of operational continuity such as Business Continuity and Disaster Recovery.
The heart of the solution is LBL Application Delivery Controller a tool for balancing of traffic of data transmission to level 4 OSI and application tier 7 OSI (HTTP/S-DNS) with characteristics of session affinity (aka sticky session and load balancer managed session) capable of ensuring a high scalability on modern multiprocessor systems and on systems with multi-threaded processors. From the point of view of Architectural positioning of this tool is as Full Reverse Proxy going to insert a layer to manage the many applications that make up the services. Inside the product suites LBL S.A.A.I., in addition to the component of intelligent balancer L7 called the Global Distributed Gateway, there are additional features that are enabled through an appropriate model of licensing. Thanks to the advanced features of application optimization and traffic management platform is able to redistribute the load on the cluster and to ensure Business Continuity and Disaster Recovery.
In the following paragraphs are described in a synthetic manner the individual technological components.
LBL Secure Application Availability Infrastructure is a set of tools designed to increase the availability of application services.
The design choices are based on careful preliminary studies and by significant experiences in the context of the drafting competitor began in 1986 that have allowed the implementation of a reference model on which rests the entire system. LBL Secure Application Availability Infrastructure comes from a long experience in numerous projects in mission critical that have allowed to acquire the solution the characteristics of simplicity and reliability which are typical of this sector. LBL Secure Application Availability Infrastructure includes various products and feature released in commercial distributions:
- LBL Warningr
- LBL Warningr IP Network Card Redundancy
- LBL Global Distributed Gateway
- LBL Application Delivery Standard Controller has
- LBL Application Delivery Controller Enterprise has
- 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)
Integrated functionality in LBL Application Delivery Controller:
- LBL DoS/DDoS attack mitigation & Vip iRedCarpet
- LBL Web Application Firewall based on signature OWASP
LBL Monitor is the operating system of the suite LBL Secure Application Availability Infrastructure of complete intellectual property of TCOGROUP. LBL Monitor has been designed to exploit to the maximum the potential of ADC Solutions & Security with data traffic passing by optimizing platforms real-time for huge volumes of data TCP/UDP. LBL Monitor is able to perform all the modules of the suite LBL Secure Application Availability Infrastructure so modular, scalable and integrated.
Through a web interface it is possible to safely run the most common operations like the start/stop of a module, perform the view logs, check network interfaces. LBL Monitor checks during the run-time the evolution of the execution of the modules by filtering messages and through e-mail or HTTP services, notifying the most significant ones.
LBL Monitor constantly checks the status of jobs and in the event of a fault is able immediately report the anomalous event through e-mail, SNMP or through a “HTTP post” to a service placed beforehand in listening.
LBL Monitor closely collaborates with LBL Global Distributed Gateway for parameterization and customizing forms allowing a global vision of application services and resources which may be distributed locally and remotely.
LBL S.A.A.I. was born to be used in virtual environments and cloud in multi-tenancy and in environments hybrid-cloud.
Thanks to features “Autonomous Delegated authentication” and full-virtualization you can assign and segregate to certain groups of users vapps assigned to them by ensuring the total isolation. The solution prevents the possibility of cloning of virtual instances invalidating the delegations and thus making impossible a unauthorized use.
“Autonomous Delegated authentication” allows you to aggregate into sets of groups of users the visibility and effectiveness of resources so as to maintain the visions and global operations for some groups and by dividing the use for other groups.
LBL S.A.A.I. introduces delegated authentication in all communications between the components and modules.
The implementation is gained from experience in mission-critical data center to increase security and decrease the possibility of unauthorized use of procedures within the/the datacenter. Today’s possibilities of importing an entire operating system cloned within virtualizers drastically compromises the security giving the possibility to perform remotely procedures highly dangerous not authorised.
In this regard all the archives of the password of the modules LBL S.A.A.I. Are encrypted and can only be used from the position and the operating system on which they were originated. Any cloning of the system or the theft of the archives of authentication makes them unreadable and therefore any operation not possible.
The implementation of the authenticating access LBL S.A.A.I. is based on 4 fundamental points:
- Encryption of the repository of authentications
- Origin of the creation of the authentication file
- Separation of user authentication and delegated
- Autonomy in relation to the infrastructure to manage
The first (1) point is very important because the archives of the authentications are encrypted to allow the visibility and readability with just the tools made available by the platform LBL S.A.A.I.
The second (2) point poses a significant improvement in safety. All archives are unreadable, even by the same tools LBL S.A.A.I., if they are copied in another place or if they are used on virtual environments physical or cloned.
The third point (3) separates the management of human users by users delegates or by systems LBL S.A.A.I. and allows to define, where two groups of people (engineers and safety).
The fourth point (4) shows how the authoritative system should be completely independent from the infrastructure that must manage. The delegated permission to the action is therefore completely detached for example from directory servers that may not be available or accessible at the moment of execution of procedures (operations to be carried out during failures or fail-over of the datacenter).
LBL Secure Web-Based GUI is the integrated interface for remote management to administer all modules of the suite LBL S.A.A.I.
LBL Secure Web-Based GUI has been developed with the most modern technologies HTML5 responsive and can be used by multiple instruments as different browsers, tablet, mobile.
Through the interface LBL Secure Web-Based GUI Admin Console and Remote Management it is possible to have access to all functionality via the web.
Access to the platform management takes place via a secure connection HTTPS (SSL) with authentication on the part of the operator even through the demand for digital certificates.
This module, available on all distributions and usable with any acquired license, allows to obtain the redundancy of routing using multiple network interfaces Hardware. It is therefore possible to establish a number of physical network interfaces for the same IP address that will be assigned dynamically based on the availability of the network for that particular path (path). To ensure the highest levels of availability of connectivity you can then set the service LBL IPNCR more Network Interface Card (NIC) for one and the same address. The number of physical interfaces fail-over does not have a limit and it is then possible to add interfaces fail-over simply by duplicating the rules and applying them to the interfaces.
The service of LBL IP Network Card Redundancy is not limited to provide high availability at the level of the physical network but can also be used as a function of application logic. In fact it is possible to influence the setting of the virtual address on the basis of the availability of an address to the possibility of connection to a port address or to the availability of an HTTP service/S.
It is therefore possible for example to influence the setting of the address to the presence or absence of a service through Health Check. The latter setup functionality conditioning is very useful in cases of Disaster Recovery or Business Continuity To be able to indicate to the LBL DNS & Proxy Manager an alternate address to sites up to the restoration of full control of one of the sites.
The system of logging LBL S.A.A.I. can be set for the different types of information that you want to trace. The log is asynchronous with maintenance of the temporal sequence of operations. The function of “log-rotation” allows the system to maintain the history of the events which have occurred for 15 days before their cancellation (the number of days is settable from parameter). This feature has been introduced to reduce system maintenance times and does not consume resources mass storage. The system of logging has an integrated deduplication of messages in such a way as to not display/store the same message if repeated consecutively. The system of deduplication in each case performs the display/log message every 20 repetitions (settable number from parameter) or at the next message different from those repeated.
LBL S.A.A.I. allows to further centralize in a relational database transactional all events of logging of all modules and all nodes LBL S.A.A.I. installed. The system allows you to analyze the events in a centralized manner, with Business Intelligence tools and probes of third-party tools for the management of criticality. Each module LBL S.A.A.I. natively incorporates this functionality. As for the traffic statistics, in case you lose connectivity with the centralized repository logs are kept in cache for a set period of time up to the restoration of connectivity.
The system of logging in the face of the violation of rules records the event for analysis or application triggers.
The structure of the names of the log file:
Below the list of the most important opportunities provided by the system of logging & debugging for an analysis of the data in transit and of the amendments made by the rules of rewiting.
|DEBUG||Debug functionality activation-deactivation|
|LBL_DEBUG_BODY||Message body debugging|
|LBL_DEBUG_HTTPV||Show http version|
|TCO_DEBUG_RAWIO||I (byte by byte)|
Complex environments and distributed require a mode of management and provisioning effective and safe. LBL Global Distributed Gateway is the module that you can use to aggregate and manage all the information and parameters of the nodes LBL S.A.A.I. both local and distributed and to provide a global picture of the systems and their state.
LBL Global Distributed Gateway preserves the consistency and alignment of all nodes. All actions are delivered through graphical interface HTML5 (responsive) LBL Secure Web-Based GUI in absolute safety maintaining separation and segregation of resources based on user and group membership of exploiting the characteristics of the functionality “Autonomous Delegated Authentication”. It is therefore possible to create specific groupings for each administrator by narrowing the operations that can be performed.
Access to the platform management takes place via a secure connection HTTPS (SSL) with authentication on the part of the operator even through the demand for digital certificates.
The entire platform natively implements a versioning system that allows automatic saving of the previous configuration whenever you made a change. In this way it is always possible to guarantee any action to restore/roll-back of even partial to a previous configuration.
You can also export completely a whole module to perform total backup (export) and restore total (import).
LBL Global Distributed Gateway Extensive use of digital certificates must be supported by appropriate tools that allow for easy management. Through the Web interface, you can create, update, import, export, and destroy digital certificates by covering the entire life cycle.
Let’s Encrypt, ACME Protocol
The ACME (Automatic Certificate Management Environment) is a protocol to automate the interactions between the Certification authorities and Web servers of users, allowing the generation and deployment of digital certificates in a simple and Economic. The ACME protocol is a protocol maintained by the IETF and promoted by the Internet Security Research Group that provides a free Certification Authority service to generate digital certificates of the Domain Validation type. This service called Let’s Encrypt is usually associated with the ACME protocol.
With the LBL ADC with a simple click, it’s easy to create and renew Let’s Encrypt certificates directly from a browser or a smartphone.
LBL Application Delivery Controller is the system full-reverse-proxy with characteristics of balancing and routing traffic of data transmission to level 4 OSI and application tier 7 OSI (HTTP/S) with characteristics of session affinity (aka sticky session and load balancer managed session) capable of ensuring a high scalability on modern multiprocessor systems and on systems with multi-threaded processors with characteristics of encryption on chip (AES-NI go on-board/on-chip encryption functionality). LBL Application Delivery Controller enables centralized management of policies for routing by providing a global vision of the services and with the ability to navigate from single end-point to arrive at the management node local or distributed in cloud services. systems are able to handle hundreds of virtual addresses interiors and hundreds of different services.
LBL Application Delivery Controller Has Standard is designed for environments in high reliability through a system of ‘master/sleeping master/s’ which maintain the routing data sessions. This version allows a reliability index theorist of 99.99%**. These features are achieved through the management of virtual addresses (VIP) which allow the nodes to take control of addresses (IP-TakeOver) in case of failure of the master. With this distribution it is possible to use two instances in mutual-failover using both nodes simultaneously on different services. (In case of a fall of one of the two nodes, the survivor is able to manage all services).
LBL Application Delivery Controller Enterprise has uses an advanced system of managing service requests that allows you to manage multiple nodes simultaneously in a symmetrical manner and assembly (active-active). This solution is particularly useful in those situations where they are needed for systems of the type fault-tolerance with theoretical reliability higher than 99.999%**. This feature is unique in its kind, is particularly valid also for the delivery of services and content, even geographically dispersed, having as Ombudsman a DNS round robin or RoundRobin FireWall. At the same time this type of “Fail-Over” ensures the continuity of service your systems “Fault-Tolerance” while maintaining consistency of routing the sessions. This distribution has a very high scalability and exceeds the normal limits of routing of the balancers master/sleeping-master. As the best solution for the dynamic management of associations names<>addresses LBL Application Delivery Controller Enterprise has can be flanked by LBL DNS & Proxy Manager and LBL DNS Global Load Balancer tools born to satisfy this need.
LBL Application Delivery Controller Platform stands out for ease of installation and implementation. This version is designed for development, test and stage.
**Result is not typical. The availability depends on various factors including hardware architectures, software applications, mission critical processes and professional services
**Result is not typical. The availability depends on various factors including hardware architectures, software applications, mission critical processes and professional services
In order to be able to provide heterogeneous services in high reliability with a centralized management LBL Application Delivery Controller provides two types of aggregation that allow maximum flexibility and resource partitioning physico-logic: End-Points Grouping and Domains Virtualization. The End-Points Grouping and the Domains Virtualization are the features that streamline and aggregate in different ways the association between Point/the request and the resources for delivering the services.
With theEnd-Points Grouping we can assign symbolic names to the listener (request points) and associate them the resources of back-end (End-Points) es.:
Adding to the inside of the endPointsGrouping further end-points these will only be used by listeners with the same endPointsGrouping. Adding other endPointsGrouping with different names you can create islands of separate services and usable only through their own listener/s. The End-Points Grouping is usable both on layer 7 both on layer 4 OSI. At level 4 OSI this functionality is used to aggregate services of the same type es.: ftp, smtp, telnet, ssh, etc.
The functionality Domains Virtualization, applicable only on layer 7 OSI and HTTP/S, allows you to use a single point of accepting requests for various groupings of services associated with different domain names. To make an example we can think to a service provider that provides services to more customers each with its own domain name e.g. www.mango_fruit.com, www.papaia_fruit.com, www.ananas_fruit.org. Wishing to distribute different services to these domain names using the same address TCP/IP port of acceptance requests can be parameterized in the following way LBL Application Delivery Controller through the VirtualDomain.
In the presence of traffic layer 7 OSI (HTTP/S) it is possible to use the URI path to further group services to balance. For each grouping of URI Path, LBL Application Delivery Controller will apply the balancing rules in an independent manner from the other groups.
In the presence of traffic layer 7 OSI (HTTP/S) you can use as an alternative to the URI path a regular expression to categorize the request and route it in end-point specific. Also in this case it is possible to determine or induce a specific application session conditioned by the context. It is also possible to assign an order of matching of the rule to run it in a coordinated manner between URI path punctual and URI path matcher governed by a regular expression. For each grouping of URI path matching LBL Application Delivery Controller will apply the balancing rules in an independent manner from the other groups.
With LBL Application Delivery Controller can be used the following types of balance.
- RoundRobin (default)
- Adaptative (aka adapt-active)
The policy of balance can be associated with the resource group (EndPointsGrouping) or to the domain (VirtualDomain) until URI path or to the URI path matching. Different groups of resources, different domains and different URI path URI Path matching within the same domain can have different policies for balancing.
The balancing RoundRobin allocates the resources of backend in a cyclical manner in the temporal order with respect to the order of arrival of the request.
The adaptative balance (adapt-active) allocates the resources of the backend choosing among those available, the less committed. The commitment of the resource is calculated on the basis of the connections that are located in a wait state for a processing from the backend or are in the process of data transfer. This behavior ensures an extraordinary balance of requests without the use of agents.
The balancing FailOver is a balancing mode reserved for those services which by their nature cannot be balanced but need a system of FailOver which safeguards the continuity of service. This policy of balance is expected to have a pool of resources of back-end in mutual fail-over. LBL Application Delivery Controller schedule traffic on the first node of the backend in state of ready starting from the first end-point inserted in the list. The failure of the active node LBL Application Delivery Controller tries to go to the next available node. LBL Application Delivery Controller does not pass to the next free but at the first node available spreading from the first on the list to allow the fail-back and restore the initial situation in the event of failure.
LBL Application Delivery Controller implements Web technology Socket. WebSocket is a web technology that provides channels of full-duplex communication through a single TCP connection. WebSocket is present as a W3C recommendation and the WebSocket Protocol was ratified by the IETF as RFC 6455.
WebSocket is designed to be implemented both the client side that the server side and can be used from any client-server application. The protocol is independent from the protocol that will be used. Its unique correlation with the HTTP/S is in the way in which makes the handshake during an upgrade request between client and server. The WebSocket protocol allows greater interaction between a client and a server, facilitating the creation of applications that provide content and games in real time. This is made possible by providing a standard way for the server to send content to the browser without having to be requested by the client and allowing to messages to come and go (full-duplex) taking the open connection. A further advantage is that the communications are made through TCP ports used during the SSL handshake without interruption of the channels, therefore taking advantage of authentications of HTTP/S and the possibility of traversing the firewall with the same policy of the HTTP/S previously used.
LBL Application Delivery Controller was designed from the outset for widespread use on the geographical network. The Nodes of balancing can then be positioned in places that are geographically distant. The use of the band to use of LBL Application Delivery Controller has been limited to maximum precisely to allow use in conditions of limited transmission capacity.
The geographic balance is an aspect that is well suited to the current architectural possibilities and allows two sites geographically distant and active-active to prefer the services closer to the node. For instructing LBL Application Delivery controllers to make this distinction is easy. It is sufficient to indicate in the service description parameter near.
With this parameter, together with the characteristics of the extended clustering of LBL Application Delivery Controller, it is possible to provide groups of federated balancers between them and located in the territory. The services are rendered common but LBL Application Delivery Controller wont in the state of normal use those closest to the node.
In the absence of services in the vicinity will change to use the services located in other sites. This functionality can also be exploited in other circumstances where services cannot be balanced for architectural specifications and complete the policy of balancing FailOver by automating the restoration of services once they are reactivated.
LBL Application Delivery Controller was designed from the outset for widespread use on the geographical network.
LBL Application Delivery Controller IP Geo Localization is a feature of the component of balancing and routing. It is composed of two elements, the downloader associations addresses location (country), and the ability to query the real-time database by the balancer on-the-fly while passing the data.
Through the rewriter you can set filters to allow or block the passage of requests from particular geographical areas. Through the powerful rules of the Rewriter is possible to selectively exclude some addresses even if coming from geographical areas which are forbidden.
The module DoS/DDoS Uses the repository of geolocation IP to indicate the geographical source of the attacks
With LBL Application Delivery Controller it is possible to diversify the parameters relating to a data flow up to a single grouping of resources or to the protocol. LBL Application Delivery Controller has already preset parameters for the most popular protocols.
It is also possible to modify or create a new group of parameters starting from an existing one and modifying only the values for the difference.
LBL Application Delivery Controller HTTP date compression allows to compress the data traffic to optimize the occupation of the band.
With LBL Application Delivery Controller it is possible to selectively compress individual data streams contextualized also for group/domain/end-point/mime-type.
Data compression HTTP is obtained through rules, already prepared and customizable, in order to have the maximum expressiveness and flexibility of application.
LBL Application Delivery Controller uses a refined technology parallelization of data compression. The compression occurs then exploiting to the full the parallelism of modern CPU multicore multithreaded and eliminating any synchronization point due to additional hardware outside the CPU and eliminating any bottleneck.
LBL ADC supports the functionality of caching that enables you to dramatically streamline the user experience. In this regard all requests can use memory portions that are used to temporarily buffer content (cache) by decreasing the use of the band and by optimizing the access times and accelerating the use of the services.
Setting the values of caching are directly can be parameterized via interface with the allocation of areas of dedicated memory that are statically allocated in proportion to the sizing of the LBL ADC on the basis of the parameters set.
The dimensioning of the cache is optimized for maximum acceleration with factory parameters. The algorithm and the occupied spaces are available in the Reference Guide.
The port rewriting is a feature that is used in cases where the service back-end try to redirect the communication toward its port and not on the port to which service was requested. This behavior may occur for example with a response code 302 (MOVED TEMPORARY) on some Web Server in specific release or implementations of application (e.g. Microsoft IIS or Apache Web Server).
LBL Application Delivery Controller can update and/or insert in the HTTP header of the request the entity X-Forwarded-For to perform the forwarding of the addresses of the client. The entity X-Forwarded-For is characterized by a value “subparagraph+space separated” and indicates, from left to right, the addresses of the layers that have crossed the request (proxy, gateway etc. compliant). The address whose value is situated furthest to the right of the chain separated by “,” is certainly the address of the client that has contacted LBL Application Delivery Controller, other addresses must be used for statistical purposes in any case being entered by other apparatuses that have been crossed by the flow of information. In this topic you can find ample documentation on the Internet since it was adopted by almost all network services at layer 7 HTTP/S.
Also the visibility of the client IP address in the X-Forwarded-For allows LBL ADC to apply the algorithms of mitigation DoS/DDoS attack on the basis of the IP address source or as an element of the session on multiple application hop.
An important feature is represented by the possibility of indicating how end-point a URL redirection. This functionality, applicable on layer 7 HTTP/S, centralizes the management of routing in a single instrument making easier the maintenance of the plant.
The health check service, described by the parameter “redirectTo”, can be activated by specifying “address” and “port”. This functionality is not activated in automatic because the service described in “redirectTo” may not be reachable from the balancer because shielded by a firewall or belonging to another network. Here is an example of a flow of a redirect. It is also possible to perform the redirect inside the same balancer to bring the transmission from unencrypted to encrypted or add parameters or query string to the new request.
The system during operation can detect the unavailability of one or more services.
The system of monitoring internal services to LBL Application Delivery Controller provides to put ‘out’ service and periodically verifies the new availability, restoring the functionality. This characteristic of automatic recovery of the resource is valid for the policies of balancing RoundRobin and adaptative. For the policy of balancing FailOver is instead (intentionally) need a human intervention to indicate that the resource is session available. In the event of a FailOver balancing human intervention is necessary to indicate a LBL Application Delivery Controller that the resource has been restored also from the point of view of application.
Any malfunctions will be notified through email or http post. The restoration of the service will be reported on the logfile.
– Resolution Scheme “Out of Order” & “Off Again” –
1 – system ok
2 – System Out of Order
3 – System Off Again
Session management can be done in different ways depending on whether you are using the Layer 4 TCP/UDP in clear or SSL/TLS or Layer 7 HTTP or HTTPS. In case you are using the layer 4 it is possible to manage the session through the TCP address of the client or of any parameter representative (SSL session or any representative information derived from data stream).
- Session handled by Application (inspection)
- Session generated and managed by LBL Application Delivery Controller (Load Balancers managed session)
These two options provide maximum flexibility allow LBL Application Delivery Controller to manage in the most correct manner the information flow.
In versions LBL Standard ADC HAS AND LBL ADC Enterprise has session management provides the propagation (Mirroring) in a transparent manner of information relating to the properties of the sessions (even for the SSL/TLS connections) to all nodes that make up the cluster (instances of LBL ADC) to impart the necessary characteristics of reliability and availability of service in mission-critical environments.
With LBL ADC you can reconfigure a warm services while maintaining all sessions associated with the other services that will continue to operate while maintaining the active routes. It is also possible to associate, through identifiers, application services to the respective resources that compose them. In this way it is possible to correlate the provision of a service to the various components of the application.
You can check the number of sessions and their propagation in the nodes forming the cluster directly from the graphical user interface on the Running Status->Sessions:
You can also check for client IP the trace of the global crossing to LBL GDG and sessions generated. Also in this case will be displayed all distributed sessions on the nodes of the cluster from the engine of mirroring.
Virtualization of balancers is the technology that allows you to have multiple instances of the balancers within the same instance LBL Application Delivery Controller or use more guest in environments that use hypervisor. This technology simplifies management in complex situations where are required diversified areas for service or if it is necessary to use balancing services in mutual fail-over.
You can use multiple instances of LBL Application Delivery Controller within the same guest so as to divide the services on multiple nodes that make up the cluster and in case of a fall of one of the nodes, the survivors will load the virtual addresses no longer served by the node failure in delivering however the 100% of the services.
You can use this feature even in the case of programmed maintenance allowing the continuity of service delivery. For this purpose there is a function of the cluster that allows you to migrate the virtual addresses from one node to another at any time.
LBL Application Delivery Controller includes features of advanced security directly in the core of the system of forwarding. In particular it is possible to exclude entire sets of IP addresses from the forwarding through the setting of IP_global_BLACK_LIST IP_global_White_LIST or through the Geo Referencing. Lists can be populated also by external sources with third-party tools.
Complete the characteristics of security essentials:
- Session cookies (TLS)
- The Set-Cookie app server generation (TLS)
- HSTS: Redirect from http to https
- HSTS: Strict-Transport-Security injection on response
- Check body length in post not dependent by content-type / transfer encoding
- SSL Client Protocols interceptor and tracing
- SSL ciphers suite and Protocols Global / Listeners / abilitations Backend
- SSO and client certificate management
- XSS mitigation
- End Point Maskeration
- Virtual patches
- IP Addresses White List
- IP Addresses Black List
- IP based geo localization White list
- IP based geo localization Black List
Example of setting range of IP locked or temporanemante blocked
Geolocalization Black list
IP Black list
IP Black list
The solution LBL Application Delivery Controller through the advanced functionality for tunneling and encryption end-to-end is able to ensure a secure access to services providing a single point of control and security. The ability to use digital certificates is guaranteed by the powerful system of offloading that allows you to terminate the SSL connections, require that clients strong-autentication, perform the forwarding of certificates toward services, perform at several levels of security operations for re-encryption in the backend.
LBL Application Delivery Controller can be the terminator of an HTTPS connection. The URL rewriting enables the HTTP services of back-end an excellent degree of transparency of applications than the protocols crossed.
The system LBL Application Delivery Controller accelaration offloading uses the newest technologies of encryption on chip (AES-NI go on-chip encryption functionality). The use of these technologies parallel encryption allow you to dramatically accelerate the activities that were once delegated by chip ASICs outdoors multicore environments formed bottlenecks and introduced latencies due to relocation outside the computer in addition to present problems of use in virtualized environments heterogeneous cloud or.
Being LBL Application Delivery Controller a full-reverse-proxy it is possible to differentiate the characteristics SSL/TLS front-end (client connections) from those of back-end (connections toward the end-point/services) both at the level of the SSL/TLS protocol both at the level of the cipher-suite. This allows you to keep in a centralized manner a very high level of protection and always updated significantly decreasing the interventions on multiple platforms application-server used for the delivery of application programs that can then be updated at different times.
The system of encryption and the treatment of digital certificates can use technology TLS-SNI (Server Name Indication) capable of concentrating the use of multiple digital certificates in a single address-door drastically reducing the number of IP addresses exposed and bringing to the logic state routing application. This feature allows a drastic simplification at the level of networking and firewall rules.
The system of encryption SSL/TLS ensures the dynamism of the session SSL/TLS to increase the security of the protocol in line with the latest specs.
LBL Application Delivery Controller provides synthetic lists of digital certificates in use by calculating the expiration dates and highlighting them on the interface and through e-mail every 24 hours when missing 60 days after expiry.
The SSL technology King- encryption allows to obtain a encrypted transmission in both the front-end by clients who require services to LBL Application Delivery Controller, both in the back-end allowing the use of protocols and cipher-suites SSL/TLS different and while maintaining efficient routing based on information that transit within LBL Application Delivery Controller.
This technology is very useful in case you indent high volumes of confidential or sensitive information allowing to have in the delivery of the service is the strongest security available and at the same time all the functionality of routing application that a modern ADC must make available in the scope of its application.
With LBL Application Delivery Controller it is possible to perform at the transport level the forwarding of data fully encrypted enabling SSL tunneling or any other form of encryption in a manner completely transparent.
LBL Application Delivery Controller can manage authentication through digital certificate client. The feature can be activated very simply in the definition of the listener with different degrees of security. If used to leyer 7 HTTPS is also possible to indicate particular URIPath with need for strong authentication leaving the navigation in SSL without the request of the client certificate for other services. Once you have verified the authenticity of client LBL Application Delivery Controller will implement the policies of balancing and routing by establishing a new connection to SSL toward service. Even at this level we can adopt different policies of encryption, only by the establishment of the tunnel to the total certification of trafficking. If you set the forwarding of the data of the certificate to the backend and being LBL application delivery controllers in possession of the trace of the public certificate this can be transferred in two ways toward service:
- Extraction of some data of the certificate and setting up as many new entity in the http header (typically the DN of the certificate)
- Conversion of Client Certificate in PEM format and transfer of the certificate so transformed into an entity of the HTTP header
It is possible to simultaneously use or only the type of forwarding. It is also possible to set the depth of the certificate chain on the basis of the checks that are performed by the services of the backend.
The result obtained is, if necessary, the total transfer of information with treatment of the certificate in the X.509 format.
LBL Application Delivery Controller storicizza on persistent cache in a relational database transactional data traffic and log. It is possible to use several databases to the data historization in dependence of the volumes of traffic.
The supported databases for the storicizzazione statistics are:
- MS SQLServer
- Our JavaDB embedded (default)
- Our JavaDB Networked
Exceeded the threshold of managed data from databases listed above is indicated using the system enterprise of storicizzazione and aggregation of data LBL Traffic Monetizer designed to manage and aggregate large volumes of data.
LBL ADC fully supports and simultaneously both IPv4 and IPv6. All components LBL S.A.A.I., management or exercise, can be used by these protocols.
In particular the component of balancing and routing, LBL application delivery controllers in all distributions, can simultaneously use both IPv4 and IPv6.
It is thus possible for the same services, providing multiple listeners in both IPv4 and IPv6 and have the same or as many services of the backend in both IPv4 and IPv6.
By exploiting the ability to associate names to endpoints (see associateName in reference guide) with LBL Application Delivery Controller can easily be treated moments of transition by enabling the backend in IPv6.
LBL Application Delivery Controller provides a powerful integrated functionality that allows you to prevent and manage Denial of Service) and DDoS (Distibuted denial or service).
This powerful feature protects both from attacks from a single IP address both from attacks from IP addresses diversified.
The algorithm has been studied both for features layer 7 HTTP/S both Layer 4 TCP/UDP.
The functionality is to safeguard the services of backend avoiding to expose them to overloads that could make them go in fault by propagating the problem on levels DB applications typically more sensitive. The algorithm is therefore based on thresholds of application stress as well as volumetric obtaining the maximum effectiveness of protection.
With the HTTP/S it is possible to alert users with a page of courtesy, a redirect, a close connection or through a request input captcha. A close with reset (where permitted by the Transport Protocol) for all other protocols.
The algorithm is able to analyze the attack also for requests from subnets mitigandone effects.
- Single Address (Captcha input for human user verification)
- Subnets Addresses 255.255.255.0
- Application prioritization function
The system is agent-less and is based on the survey snapshot of the degradation of services. In the case of volumetric overload the system detects such as requests will cause greater congestion by acting progressively until the congestion (SMOOTH MITIGATION). The detection based on stress application and volumetric and the consequent reaction takes place in a maximum time of 50 milliseconds.
LBL Application Delivery Controller enables you to temporarily confine attacks from individual IP address, multiple addess or address afferent to the same subnets. The algorithm is designed to identify dynamic IP and place them temporarily in the condition not to harm.
The system reacts to both Layer 4 TCP/UDP both layer 7 HTTP/S-DNS. In the presence of HTTP/S the algorithm is also capable of detecting attacks from systems “hidden” by proxy that obscure the starting address by applying the algorithm also on elements of the header as the X-Forwarded-For.
The occurrence of sudden spikes of HTTP requests coming from the same source IP, LBL Gloabal Distributed Gateway offers the client a Captcha form input (customizable) to verify if the request arrives is a human operator or if it is coming from a robot that is performing a scan of the site or worse an attempt of DoS attack.
If the operator completes the request correctly the address will be unlocked to continue the provision of the service. Otherwise the address will remain in the quarantine.
Last evolution, derived from experience in the field of e-commerce, is the feature VIP iRedCarpet. This feature allows to discriminate, from the point of view of application, the traffic “useful” by traffic “touristy” reacting in a different manner depending on the traffic conditions. The system was designed to give priority to the access of the connections according to the type of service requested, for example privileging the connections that are running of payments or have already performed the authentication to the portal or in the e-commerce, those who have the truck load than those who are browsing in a single consultation. VIP iRedCarpet collaborates with the functionality DoS address quarantine and DDoS attack mitigation by increasing the accessibility of services by distinguishing the types of navigation.
The routing capacity at the application layer are enormously increased from engine inspection and rewriting of data traffic. The system allows to act easily with rules is level 4 TCP/UDP is level 7 HTTP/S by intervening on the routing and dynamically conditioned both for the need of session affinity, both for the need of continuity of service delivery. The content rewriting extends to the components L7 both header and at the level of the body allowing a total control of the traffic data.
The system allows to use at multiple levels the functionality of rewriting, both through parameterization is through the Java programming language. These two features were designed to work either independently or simultaneously. It is therefore possible to use the rules described at the level XML and use their own classes or Java libraries and allow an easy and controlled to make changes up to the last bit during the forwarding of information.
Through XML it is possible to perform most of the tasks of rewriting and you will arrive to use the extensions of Java classes in special cases or in reality where serves a application integration as for example to integrate systems for Single Sign On (SSO).
This aspect is of fundamental importance in logic of applicative cooperation (e.g. WSDL) and federated authentication (SSO).
Also at Layer 4 TCP/UDP it is possible to intervene directly on the route by reducing the times of down-time components such as for example the database or systems of remote desktop, directing interactively requests on the dispensing points available.
From the point of view of architectural and functional LBL ADC is a Full Reverse Proxy going to insert a layer of Application Delivery Control to manage the many applications that make up a service and offer a parse engine full-L7 Traffic Data. With the solution LBL ADC acting as Full Reverse Proxy, all connections that traverse the layer of balancing are terminated and constantly analyzed and catalogd by identifying events faults and implementing actions to guarantee the continuity of supply. The system in all its components, is designed to be used in mission-critical and business-critical applications with stringent specifications of criticality and confidentiality.
LBL Application Delivery Controller natively implements the functionality of full reverse-proxy. With LBL Application Delivery Controller it is possible to inspect, vary or induce a change of behavior both at the level of the HTTP header is level of HTTP Body (full content-rewriting). The system allows to use at multiple levels the functionality of rewriting, both through parameterization is through the programming language. These two features were designed to work either independently or simultaneously. Thus it is possible to use the rules described at the level of the graphical interface and use of their programs, as an extension of classes available from the library LBL Application Delivery Controller, and allow an easy and controlled to make changes, including binary mode, during the forwarding of information. The feature-level descriptive graphic interface and the extensions of the programmatic parts can collaborate simultaneously so as to combine the convenience of parameters to the logic of a real program.
Through the graphical interface and templates you can perform most of the tasks of rewriting and you will arrive to use the extensions of classes only in special cases or in reality where serves a application integration as for example to integrate systems for Single Sign On (SSO).
The system of parameterization is very simple and entirely usable guided by graphic interface HTML 5 to describe the actions to be taken at the level of the HTTP header or at the level of the BODY HTTP.
Below an example of template of rewriting that allows to check if the request arrives in clear and in the case performs a URL redirection of the same request SSL in keeping all the parameters of the original request.
Through the interface you can check any value of both the header of both the body and through the use of a simple mechanism of variables built on-the-fly You can redial from zero any situation starting from the data coming from the stream.
Already in this sequence template of rewriting it is possible to appreciate the potential of the instrument without intervening with programming tools. At the level of programming is still possible to use in the form of “method” all the possibilities offered by the interface and you can also use variables declared by providing a true language all logical possibilities that this offers.
The variables can take their value from different sources. The data more frequently can be loaded through INNERVARIABLE already ready to use. To avoid overhead of string substitution and allows to grow over time with the number of values prepared and ready to use the INNERVARIABLE must be loaded into a variable. This functionality has been designed from project to have no limits future implementation of preconceived values and easy to use (a total description can be found in the manual “Content Rewriting How To” and in the manual “Reference Guide”).
The rewriting of the body from the point of view of use is very similar to the operation of the rewriting of the header. From a technological point of view its treatment is much more articulated because it must provide to amend the Protocol on-the-fly without the use of the cache, to avoid storing sensitive data, and going to act in the contents and thus varying the dimensions. LBL Application Delivery Controller uses the best offers the technology to allow you to change at will and in a consistent manner the data that traverse the layer of balance. In a consistent manner because the fragmentation is dictated by the type of data that is transferred (mime type) and then moving on to application in an automatic manner.
In conclusion the characteristics of rewriting combine the simplicity of parameterization and the depth of intervention by providing an easy to use tool directly from the web.
LBL Application Delivery Controller enables you to fully manage the cycle of content-rewriting at layer 4 (TCP/UDP). The system has been studied in order to identify portions of the Protocol and to be able to act in full mode-binary. An example we can find in the template content rewriting LBLTCPCIFS (in the image below) that change on-the-fly the bit vcnumber (little endian) of Protocol SMB1.0 that allows to balance the protocol.
Centralize Access Policies simplifies security procedures and authorisation of access to applications and data. The implementation in complex environments, where Single Sign On and Access Control Management would be a natural place, often cause problems of complexity in the distribution and maintenance in the time of plugins to enforcement by blocking the entire evolution of the infrastructure. The strategic position of the component LBL Application Delivery Controller enables you to check the its correspondences authorities derived from the form of “Service Request” and “dispensing point”.
With LBL Application Delivery Controller it is possible to integrate a single point of access control of all web applications and manage then considerable amount of services without burdening subsequently the operating activities and natural update applications. Through the system LBL Developer (described above) you can quickly develop interfaces to IM systems (Identity Management) and ACM (Access Management). The ability to run through LBL Developer the development and debugging of the codes produced confers stability and consistency by drastically reducing deployment costs and production times. With this system it is possible to rapidly integrate technologies of Identity Management and Single Sign On reducing layer (elimination of the plug-in enforcement) drastically simplifying the architectures and reducing maintenance downtime.
In some circumstances, especially in the presence of the layer of ‘URL rewriting is necessary to correct the contents of the HTTP header.
LBL Application Delivery Controller implements the correction of the Protocol for the identification of the mime type in case these does not conform to the specifications HTTP1.0 and HTTP1.1. This functionality allows systems to rewriting of correctly interpreting the content type and then perform the appropriate action of rewriting.
This feature can be activated only if necessary, normally LBL Application Delivery Controller does not perform any modification of the values which are transported with the HTTP protocol being conforms to W3C specifications of ‘Gateway transparent’. In HTTPS values can be modified according to the rules of URL rewriting for only data relating to the header.
The systems of listening and monitoring manage the possibility of dynamically varying the address or the network adapter on which you accept the connections.
This feature facilitates the reconfiguration of the systems without that LBL Application Delivery Controller should be riparametrizzato or restarted thus keeping the session data.
– Dynamyc Address Listen (FROM)-
A1– network card eth0 address 184.108.40.206
A2– Set eth0 network card with new address 192.168.83.22
– Network Adapter Translation (NAT)-
B1– eth0 network card with network address 220.127.116.11
B2– Set eth0 down
B3– Set network card ERI0 with network address 18.104.22.168
This chapter summarizes the behavior of LBL Application Delivery Controller if during the run-time are modified or moved to interface the IP addresses on which the listener are insisting to provide balancing services. These policies are also used by the standard versions and Enterprise to provide the fail-over capability and therefore guaranteeing continuity of service. “ListenType” is the parameter that determines the usage policies of listeners and can therefore take the following values.
ListenType = STATIC (default)
From (Dynamic Address Listen)
NAT (Network Adapter Translation)
- STATIC: rigid association address/network interface. This association, already present in version 1.1, provides a fixed association between the listener and the IP address. In the case should occur changes of address or malfunctions of the network interface LBL Application Delivery Controller ceases to deliver the service for that network address. This mode is the default if not explicitly stated.
- NAT Network Adapter Translation: Allows to LBL Application Delivery Controller to adapt the listeners on the same address even if during the run-time this address has been moved from an interface to another.
- From the Dynamic Address Listen: The functionality by allowing LBL Application Delivery Controller to specify a network interface, either physical or logical, and the position of one of the associated IP addresses. To change the IP address LBL Application Delivery Controller will detect the change and make a new bind with the new address by closing the previous. This feature is particularly useful in those cases where the network address is dynamically reallocated, DHCP, or to create temporarily of “bridge” on ADSL networks by providing a single point of entry to the services of the back end.
LBL Application Delivery Controller Network Federation & Automatic Role Assumption Hot-Plug (nodes)
This characteristic, in Standard and Enterprise, allows LBL Application Delivery Controller to configure itself in the role of Master or sleeper or, in distribution LBL Application Delivery Controller Enterprise Edition, to aggregate in a spontaneous manner to the community of nodes already running. This functionality allows LBL Application Delivery Controller Enterprise Edition to add nodes on-the-fly by increasing the throughput capability without the theoretical limits and without interruption of service.
A typical installation of LBL Application Delivery Controller Standard Edition in a mission-critical environment could take the following configuration. The example also shows the possibility of LBL Application Delivery Controller to be able to use more sleeper to increase availability through multiple redundancy. Also in this case the addition of a further node, for maintenance or upgrade, you can perform a warm on-the-fly without disrupting services.
In the event of failure of one of the nodes of the system of LBL Application Delivery Controller Automatic Role Assumption Restores the condition of better functioning.
LBL Application Delivery Controller is equipped with a tool to perform the balancing of the UDP packets. The service is highly parallelized also provides the form of rewriting to be able to work both on the content on both the routing of the packets.
It is possible to intervene in the data stream reformulating during the runtime endpoints also routing in dependence of the data packets received.
Even with the UDP protocol it is possible to realize the balance with the session management.
One of the peculiar characteristics of LBL Application Delivery Controller is the possibility of use in architectures that provide a site of Business Continuity or Disaster Recovery. The modularity that distinguishes the architecture allows in fact to exploit according to necessity, the topology of the network and the bandwidth availability a complete solution to automate processes and make highly available service delivery.
In the example below by exploiting the possibility of awarding hierarchical outline of the Master, you can activate at any time the Disaster Recovery site in campus redirecting Web requests in an automatic or manual manner toward their services. The switch manual or automatic is determined by the hierarchical value (weight) of the instance LBL Application Delivery Controller.
In the image and in the parameters below you can observe the features that allow you to perform this operation in a manner as simple as effective:
Each instance LBL Application Delivery Controller can be parameterized for:
- Group = is the name of the group to which they belong to the cluster. With different names can there be multiple groups of independent cluster that share the same network
- SubGroup = is the subgroup of propagation of routing information sessions toward the backend
- Weight = Weight that determines the hierarchy of attribution of the state of the Master of the active nodes
- Start = type of start at system startup. Automatic means that the balancer starts automatically at the start of the system, manual means that serves an operation controlled by an operator to make operational the node of balancing
- Status = and the status of the node at a specific point in time
It should be noted that in the main site were activated in an automatic manner both nodes of balancing and being the node 101 that with “weight” greater than these is given in automatic control of virtual addresses that are used to route requests application toward its own back-end.
The node located on the DR site holds the weight up to the top of the hierarchy of allocation of virtual addresses but, being in a state of “stopped” (inactive), is not considered in the pool of balance. Also any restart systems of DR do not alter this situation having been set to manual startup and then explicitly controlled by an operator. This is an ideal situation for a DR site. In fact the “switch” of services from the main site to a secondary site is normally a timely decision and human, or determined by exceptional events or from simulations scheduled to determine the effectiveness of the system in case of exceptional events.
From the standpoint of switches of service requests from the main site to the DR site is sufficient to connect to the DR site through the secure connection of LBL WebConsole of LBL Application Delivery Controller and activate the node to balance with the appropriate button to start: Having the node in DR a “weight” higher between active nodes, the virtual addresses will be migrated toward the node DR diverting then all service requests toward the relative application services backend
To restore the requests on the main site will be sufficient to perform, through LBL WebConsole, stop the balancing process in node of DR.
Returning the node of DR in a state of stopped, the node with greater weight in the main site you riattribuirà control of virtual addresses making then pass connection requests through its services back-end.
Other architectures of Disaster Recovery are possible. By way of example below an image with architecture of mutual Disaster Recovery. In this case two independent sites active and provide services of mutual Disaster Recovery. The flexibility provided by the virtualization layer allows LBL Application Delivery Controller to adapt in different scenarios with simplicity of implementation.
With LBL Application Delivery Controller it is possible to associate, through identifiers, application services to the respective resources that compose them. In this way it is possible to correlate the provision of a service to the various application components that compose it. On some occasions, while being operational services placed in balancing, could indirectly be unavailable for failure/maintenance of the resources associated with them. Consider for example some web applications that relate to a DataBase to a directory server and to a shared file system. Although the web services active the DataBase, the direcotory server or shared file system could be out of service and therefore also the web services associated with them will be in their turn out of service while responding correctly to the connection.
This functionality is very interesting because it allows us to classify contextually technological services with business services and quickly identify correlations. It is therefore possible to intervene at the level of the TAG to put out of service in a coordinated manner the entire set of application or simple end-point for planned maintenance or alternative routing in case of fail-over without the other services are involved.
In the case of planned activities to the services of the backend, for example for application software update, it is sometimes necessary to interrupt the delivery of services or part of them. Through the functionality of interaction is possible to temporarily lock requests with the modalities described in the specific chapter “integration with systems of monitoring of third parties: External event Communication”. By default LBL Application Delivery Controller behaves in two ways depending on whether the communication Layer 4 or the communication Layer 7 HTTP/S.
In the case of communication layer 4 LBL Application Delivery Controller can not do anything to accept the connection, check that no service required is active and in the case close communication just undertaken.
In the case instead the communication both layer 7 HTTP/S LBL Application Delivery Controller returns an HTML page with the generic indication of unavailability of services.
It is possible to edit the HTML file and propose to the operator a message that contains the indications of non-delivery of service so as to limit as far as possible recourse to the help desk and give a timely information to the operator. The modification operation can be carried out directly by the HTML interface 5.
The hardware best performance industry available today has a calculation power important and even the cost/performance is absolutely in favor of the best performance industry. The modern CPU provide set of privileged instructions on chip and allow you to do encryption on chip in parallel on core and in virtualized environment with performance higher dedicated ASICs which cannot be used in virtualized environments.
The solution LBL Application Delivery Controller is a software solution that can be installed on the server and on the most common virtualization environments such as VMware, Hyper-V, KVM, Oracle VB,… It is able to create multiple instances isolated software between them to which they are assigned their hardware resources.
Unlike traditional appliance, which must be replaced periodically in order to provide better performance and new features, LBL Application Delivery Controller can evolve over time as a function of the hardware used and is able to exploit the best technologies that the market offers.
LBL Application Delivery Controller is born in the era of virtualization, which exploits the features and flexibility, and can therefore be used:
- On physical infrastructure or virtual already available
- As an essential component of platforms of Unified Computing (Cisco UCS, HDS UCP)
- In the cloud (AWS, MS Azure,…)
- In hyperconvergence environments
LBL Application Delivery Controller uses a refined technology of core parallelization reaching high performance and allowing a systems scalability:
- Can be installed on multiprocessor machines (X64 or RISC)
- Can use RAM with scalability unthinkable until a few years ago
- Can Exploit Ethernet network connections (on copper or optical fiber) or InifiniBand and thus ensure the highest throughput
- In contexts of cloud LBL Application Delivery Controller enables you to manage perfectly the networking resources (Dynamic DNS) and is well suited to business models (capacity on demand, pay per use)
The innovative system for the detection of application workloads allows to associate to the policies of balancing infrastructure actions of management of resources. LBL Application Delivery Controller is born in the era of virtualization and allows you to perform specific actions to vary the amount of service requests. The occurrence of particular peak demands it is possible to dynamically increase (Capacity On Demand) resources by controlling the start of further application services allowing to overcome the critical moment. The occurrence of the peak is therefore possible to perform on the infrastructure the start of virtual machines to cope with the demand and the decrease of the requests you can free up resources by turning off virtual instances that are no longer required and return to the initial state.
This ensures great flexibility in the integration of solutions for physical and virtual. The ability to split into multiple virtual instances specialized allows to obtain levels of safety and the highest segregation. Each guest can access the hardware resources allocated and is completely separate from the others.
In the case of temporary need/emergencies, the solution also LBL Application Delivery Controller allows you to distribute licenses/instances on multiple nodes without interruption in the delivery of services until the return of the emergency phase and then to return to normal operation.
|Hot-Exporting of Load Balancing Processes Instances||LBL enables the creation of compressed copy an entire instance of balancing and routing for the purpose of:
Creating template to use in contexts similar to that of departure.
|Hot-Importing of Load Balancing processes instances in different physical/Logical Node||LBL allows you to import whole instances of balancing and routing created previously.
This feature is extremely useful in the case of:
LBL Application Delivery Controller integrates the component of Web Application Firewall based on signature and able to protect Web applications and counter threats OWASP.
The system has been made considering the calculation capacity of the resources allocated to the machine by creating a ranking of attacks by decreasing the maximum performance degradation and therefore the user-experience while ensuring the maximum effectiveness of safety.
In the event of a breach or detect a rule, this loggata is in the logging system and into a suitable table of infringements detected.
The parameterization is very simple being the component integrated in the platform.
LBL Application Delivery Controller integrates the component of Web Application Firewall based on behavioral analysis (Machine Learning) and called Attack Prophecy*. A next-generation solution for the detection of threats to Web services and the implementation of the corresponding mechanisms of defense and protection that takes advantage of the latest technologies in the field of automatic learning and behavioral analysis (Pattern Recognition & Machine Learning), to identify, in addition to existing attacks, new threats in an efficient manner and scalable.
The algorithm of Attack Prophecy (Machine Learning) allows the detection/interception of cyber attacks also particularly sophisticated and specific to web services also attacked with large volumes of traffic.
The solution LBL Application Delivery Controller thanks to Attack Prophecy has not therefore necessarily need to find signatures (signature) and constant updates from the outside but is able to construct a protective layer on measure for the services being monitored, in a totally autonomous manner.
The Paradigm “anomaly-based“, on which is based the algorithm Attack Prophecy, therefore allows, through the analysis of the profile of traffic, to detect different categories of attack from those linked to the intrinsic vulnerability of services to those more general and widespread such as OWASP Top 10 and fundamental aspect being capable of detecting zero-day threats.
*Attack prophecy is powerd by PluribusONE
The Network capabilities Freezing was born from the need to find a point of synchronization on “Jobs” asynchronous. In some circumstances it is in fact necessary to generate an instant T0 to have a “moment” in which all applications are mutually consistent. This functionality can find an ideal location in bus architectures software where applications exchange “transactions” asynchronous.
In these situations the applications route their “transactions” through the BUS software to then be delivered through the rules outside the application itself, toward other applications. This architecture is applied for various reasons in many circumstances both local and geographical. If geographical reasons are derived from logistics as the availability of throughput and availability of the network, interfacing with other applications. If instead the local reasons are very often linked to the interfacing with other applications and to the need to scale for performance reasons. In the latter particular scenario, which moreover is very widespread, not being transactions in two-phase commit-you cannot find a moment consisting to make for example a full backup-making it very difficult, if not impossible, the total reconstruction of the archives in the event of need (roll-back).
With this functionality LBL Application Delivery Controller manages to make available a tool to “lock time” in a given “instant” allowing to perform in a consistent manner all the necessary operations.
The generation of statistics, the work of the process core LBL Application Delivery Controller, located persistence within a Relational Database. All the statistics displayed on LBL WebConsole are obtained from the database and are only a synthesis of the statistics that can be obtained from the data contained in the database.
From the point of view of architectural layers that form the historicizing statistics are:
- Generation and caching in memory (1° level)
- Caching on persistent memory (2° level)
- Transactional Caching on Web Service (LBLStatisticsBrokerWebCache 3° level)
- Transactional populating on Relational Database
These layers were made to allow maximum scalability and a very low impact with the core service of balancing even in the presence of extremely high volumes of traffic.
The transactionality furthermore allows to historicize the data for service without losing information. What is necessary in the case these information serve billing processes based on the traffic generated.
Even with this new implementation LBL Application Delivery Controller remains simple to install and do not add new settings in its basic installation. In case you wish to centralize the statistics of the traffic generated, you can separate on other nodes the services of LBLStatisticsBrokerWebCache and database and then display through the LBL WebConsole or with SQL script statistics more nodes LBL Application Delivery Controller.
The statistics can be viewed through the LBL WebConsole and immediately available after installation have been chosen to check immediately the status of the connections and traffic generated. For HTTP traffic/S were made available 2 statistics relating to working day with a significant grouping of information to verify in a timely manner the traffic and the response time for individual services.
Also available is the Syslog table_event that stores all the events recorded logs in all processes.
The statistics directly obtainable from LBL WebConsole are:
- Sessions Activity
- HTTP-S traffic today
- HTTP-S traffic avg
- L4 TCP traffic
- L4 Datagram traffic
- Pool queue activity
- Pool queue committed
- Connection HighWater
- Syslog event
Of particular interest is the log HTTP traffic/S in the detail provided by the subdivision of the response time in partial times (split response time). In fact, in order to be able to analyze any inefficiencies the response time is divided into:
|RESPONSE_TIME||Bigint||It is the response time of the requested service value expressed in nanoseconds.|
|LAP_ TIME_A||Bigint||The time between the end of the reading of the header of the client and the beginning of the connection toward the endpoint value expressed in nanoseconds.|
|LAP_TIME_B||Bigint||The time of connection to the endpoint value expressed in nanoseconds.|
|LAP_TIME_C||Bigint||The time between the connection occurred at the endpoint and the beginning of the reading of the header of the response. If the client sends the body is the time of transmission of the body from the client to the endpoint. Value expressed in nanoseconds.|
|LAP_TIME_D||Bigint||Read time of the header of the endpoint. Value expressed in nanoseconds.|
|LAP_TIME_E||Bigint||The time between the end of the reading of the header and the end of the data in response value expressed in nanoseconds.|
LBL ADC provides a series of reports directly from the HTML5 console that allow you to easily perform the most important data traffic checks with the possibility of drilldown for later selections. The use is simple and allows an immediate response of the activities with a temporal depth settable by the user.
LBL DNS & Proxy Manager is the brand new and innovative product that allows you to dynamically set associations name<>addresses on the DNS constantly checking the reachability and operability of application services. LBL DNS & Proxy Manager enables you to maintain constantly updated in an autonomous way more nodes DNS to always have the most current image of the topology of the network status and associated services. LBL DNS & Proxy Manager makes possible the realization of infrastructures of high reliability, Business Continuity and Disaster Recovery in a simple and effective way. LBL DNS & Proxy Manager is also the right complement to LBL Application Delivery Controller Enterprise has being able to handle different DNS addresses in RoundRobin dynamically Presenting to clients the actual availability of routing. LBL DNS & Proxy Manager is issued with your DNS or to cooperate with the existing DNS infrastructure BIND (https://www.isc.org/) and MS DNS.
LBL DNS Global Load Balancer is the balancing system, routing and filtering DNS (firewall) for DNS traffic/DNSSEC at layer 7 OSI UDP/IP TCP/IP. The system allows you to route requests on the basis of the contents and on the basis of events quotas which can be detected either manually or automatically. The system is designed for architectures of business-continuty and disaster-recovery and is able to dynamically modify the responses of the DNS on the basis of the availability of the services.
LBL DNS Global Load Balancer, analyzing a semantic level requests and responses, can route requests on different DNS server on the basis of the contents and change the answers based on origin or on the basis of events quotas such as for instance the unavailability of a service.
The system is based on a system of “declarative” and a system for “events”. For this reason LBL DNS Global Load Balancer is able to arrange the responses from the DNS to be reactive in the case of procedures for business-continuity or disaster-recovery by reducing the length of fail-over in case of need.
The DNS functionality Firewall allow you to filter requests and responses by routing the requests and responses malicious or unwanted toward the “black-hole” that does not slow down the enjoyment of contents. It is possible to condition requests and responses through lists of unwanted sites or lists of sites that can be used. This last feature allows to assign a particular sensitive departments of “white-list” of sites to be consulted and to render more difficult the activation of viruses malware and avoid phenomena of Exfiltration date.
All traffic managed by LBL DNS Global Load Balancer can be finely trace for behavioral analysis and determination of faults by identifying the sources of faults.
With LBL DNS Global Load Balancer is possible to decrease the activity of unwanted tracing from a third party by intercepting the activities of analytical systems of behavioral profiling centrally by blocking banner ads (adsblock) pop-up malware.
The features LBL DoS/DDoS attack mitigation can be activated in order to effectively protect the DNS server balanced by LBL DNS Global Load Balancer intervening when the systems begin to present problems of suffering.
LBL DNS Global Load Balancer is effectively used in hybrid cloud infrastructures can be installed in the cloud and maintaining the autoritativi DNS in the datacenter of the organization by introducing a very high reliability and independent from the tectonic sod in which there are present the datacenter.
The government and control of an informative system complex was born from the need to ensure in time a high quality standard with times and costs measurable. A datacenter has as objective the provision of information services and implementing, today also called self-service, addressed to a large audience and that must meet certain requirements such as security and reliability.
LBL Traffic Monetizer allows the monitoring of how applications are performing, implementing a tracing deep parameters required for a punctual analysis and providing an advanced reporting.
Thanks to the advanced functionality of traffic management and real-time analysis of the traffic data allows you to optimize performance of applications.
LBL Traffic Monetizer has a refined engine of populating and aggregation of analytical data and transactional enormous volumes of data to support enterprise platform for Business Intelligence, accounting and/or billing.
LBL Traffic Monetizer uses a relational database to historicize traffic statistics. The database and its handler may possibly be installed separately from the balancing service in order to be able to consolidate traffic statistics from different nodes. The same analytical data coming from the balancing systems can be aggregated and analyzed in a different manner and at the same time to meet the verification requirements of application, networking, using applications and compliance with SLAs in the intrusion analysis and phishing.
LBL Traffic Monetizer is able to detect temporal data on answers both system and application by analyzing all the phases of the traffic, by the acquisition of the request to the connection step at the service up to the detection of the latest information sent from the service to clients, by measuring the response times of the individual services with split on infrastructure layer and identifying all the elements of the chain and infrastructural applications.
The life cycle analysis of the data allows to isolate promptly infrastructure faults at multiple levels to highlight areas of intervention for the improvement of the usability of the services. Through the graphical interface it is possible to check for each module the current profile, status and view the logfile. It is also possible to start or stop the module and notify via email the event (watchdog). This allows to detect any faults, even application, for an immediate corrective action.
Data analysis highlights not only the absolute performance of applications but also allows to separate the various stages of the evolution of the service in more elements, such as for example the connection time, first response and in general of partial times of crossing of information, allowing an accurate diagnosis of the problem. The refinement of the data collected with granularity to nanosecond (billionth of a second), allows to perform extensive testing on traffic noting also the intermediate times of travel of the information through the architectural layer.
Below an example of traffic analysis data that shows in graphic the values of crossing of information. In the box “Normal Traffic” you can appreciate an increase of traffic data but a regularity in the response times of the infrastructure.
In the box below we note an increase in traffic and response times as a result of problems in the services of the backend identified by the red columns that indicate a criticality in reaching the service (increase in the times of connect toward service).
The analysis of the crossing times of the request and the response (Response-Time) sectioned in partial times (Lap-Time) allows a precise analysis for identifying bottlenecks and lays the foundations for their solution.
The architecture enables the writing, consolidation and aggregation in real time of several millions of records per hour by providing to the systems of analysis and reporting of views and data sets immediately accessible. LBL Monetizer Traffic is provided with templates of consolidation in the source format from which you can customize and adapt more interpretations of the traffic data with the flexibility of use and growth over time.
LBL Traffic Monetizer is integrable on different platforms of Business Intelligence and monitoring systems.
LBL Traffic Monetizer Light is the system of reporting and analysis of traffic data and logging of less than 3 million hits per day (24 hours). The system is supplied directly on a Virtual Appliance and you can use it directly with a short setup redirecting all traffic data and log from the systems of the suite LBL S.A.A.I. toward the broker LBL Traffic Monetizer Light.
To facilitate the deployment, the Virtual Appliance LBL Traffic Monetizer Light contains pre-installed and configured a database and a reporting system with Business Intelligence substitutable with other platforms in the case the end user wants to use several DB or Business Intelligence.
With LBL Traffic Monetizer Light are distributed queries for example in source code form that can be customized at pleasure to be able to extrapolate from the data base information or differentiated views in relation to the demands of the business and provide new reports.
LBL Traffic Monetizer Light has pre-installed and configured the well-known and appreciated TIBCO Jasperreport server. Within it are provided countless reports in source form that can be customized at will as the tool is very well known and easy to use..
LBL Commander introduces a new concept of high reliability in application going to play the role of coordinator of activities in a mission-critical data center. LBL Commander is composed of two main modules: LBL Commander Work Flow, the executor of workflows, and LBL Commander Decision Engine, decision engine capable of triggering workflows. The two modules have been designed to work in cooperation with each other or, in the case are not required of automatic operations, the only component LBL Commander Work Flow. LBL Commander Decision Engine was designed to cooperate with LBL Application Delivery Controller.
The flexibility of use of this component derives from the ability to describe simply and therefore they can be managed through a graphical interface is accessible from any web browser.
The possibility to describe processes, try, test them and documented is crucial in mission-critical tasks where some procedures are used only in cases of real need and in moments that can not be chosen beforehand. In these cases it is essential to have precise benchmarks with the smallest possible number of actions to be carried out in a context that allows to continuously ensure the state of progress.
This result can be obtained with different techniques that normally are summed up in a manual with a set of procedures, often “script”, which must be used in predetermined sequences. A major drawback of these techniques is given by the updating of procedures and by the non-homogeneity of the operation. Another major limit is represented by the fact that often these scripts take size and complexity is very high since it must incorporate both the logic is the action often becoming little mantenibili.
The solution we propose is a structuring of activities in a Work Flow that describes in a very simple manner the actions to be undertaken and where the logic of the sequence in which they are performed the operations both external scripts/programs. Another important characteristic is the possibility to retrace in a simple manner the various steps of the work flow so as to verify a priori and unequivocally the effects once started.
As overview we thought that precisely the vision of Human-Computer Interface is the best proof of the effectiveness of the instrument. All the actions that are undertaken through the interface are in reality of remote commands to an instance (RWC Remote Workflow Command) LBL Commander Work Flow Server that safely (SSL) authenticated and performs the operations. All in a manner completely transparent to the operator who must of course check these delicate operations.
From anywhere you can connect to the console LBL Monitor running LBL Commander Work Flow or you can also use of the stations LBL Monitor suitably set with references to server LBL Commander Work Flow.
The traceability of operations is ensured at the infrastructure level basic software allowing to perform the log of individual actions and choices made by the operator.
All the operations of both setup, writing scripts, debug and management are feasible through HTML interface 5.
LBL Commander Decision Engine is a form of thinking solution LBL Commander. This environment has been designed to work in architectures Stretch Cluster at the geographical level. The decision engine is a completely new project in order to be able to adhere to the new needs and be able to take full advantage of the new technological resources that today we have at our disposal such as the availability of connectivity.
LBL Commander introduces in effect new concepts, between all the clear separation between Work Flow (what should you do) and Decision (when must be done).
These technologies alone have given rise to new paradigms such as Remote Workflow Command (RWF) and determine a modular programming software for scripting by separating the logic from the features allowing you to create thematic libraries of modular script, reusable and autodocumentabili.
The architecture of LBL Commander Decision Engine is a very flexible architecture that can be articulated in different manners and make several scenarios.
An instance LBL Commander Decision Engine can govern multiple systems of LBL Commander Work Flow with application fields diversified. This feature allows to keep under control the entire datacenter with very few points of verification by reducing complexity and increasing at the same time the reliability.
This service manages in clustered environments distributed and joint committees (stretch cluster), any possibility of Split brain and then of corruption logic of data bases. LBL Commander Decision Engine – Split Brain Killer has very few parameters and is therefore usable with great simplicity. Simplicity required in these cases. By exploiting the characteristics of LBL Application Delivery Controller and the interactions with the routes it is possible with very few parameters to construct the rules necessary to verify the status of the cluster and therefore inhibit the possibility of Split brain.
This module is designed to allow you to perform remote batch, typically HealthCheck resources in safe mode. The module is composed of an HTTP listener that can interpret the file XML profile for the launch of commands (script)/executable in absolute safety.
The HTTP listener provides an application capable of launching of batch contained in the server itself and therefore without the possibility of changing from the outside. This system ensures that it cannot be arbitrarily thrown of batch or executables in the target machine.
The application test covers today an important role in determining the reliability of the software by the steps of pre-production and subsequently during the delivery of the services.
LBL GUI Reliability Tools are automation tools that allow you to record the activity of an operator and then repeated ad infinitum by detecting faults that they find during the use.
The system is formed by two elements, a recorder and a Player. The system of recording is composed of a visual tool that records the actions of the operator and allows to interpose, already during the recording, to identify the critical points of comparison such as reference values or differences in response from the expected values.
With the Recorder you can interactively try recording, starting from any position or by performing the single action immediately evaluating the effects.
After you have registered operator actions, you can save and import the tracks on different player to be able to perform and verify the results.
Multiple Player are managed centrally through the Web interface.
Also the activities of the individual stations of testing may be verified centrally through the web interface that repeats what happens in every single desktop.
One of the fundamental points of a suite is its programmability and the availability of know-how available on the market. LBL S.A.A.I. provides an integrated development with IDE of the market to be able to easily not only program but also test effectively rules that must then be deployed into production.
LBL Developer is a Virtual Appliance that allows you to develop, test and then put into production rules developed with the support of the template and sample already available in source code form and ready to be customized.
The IDE is preinstalled Netbeans but can be installed and configured in a very short time, the IDE that the final customer knows better. The rules developed can be then try step-by-step until their complete operation before being put into production. The system also makes it possible to use systems of collaborative programming (versioning) and to introduce systems of quality and safety of products developed.
Services (IaaS Infrastructure as a Service) are today used by more cloud provider to allow the creation of infrastructure on the basis of the needs of the individual user.
As we have seen the solution LBL S.A.A.I offers a suite of products that are designed to increase security and high reliability of the infrastructure by ensuring the availability of application services. Platform born for virtualization environments (NFV) and Cloud, LBL S.A.A.I. is available for Cloud environments more popular such as Azure or Amazon (already integrated with the logic of the elastic-IP multi-region).
The nature of the components LBL S.A.A.I. allows to integrate in a spontaneous manner in infrastructure services on demand. In this regard, the system is provided in both distributions as Virtual Appliance that as pure software and so it can be installed by automated systems that starting from the template configuration creates the desired infrastructure.