LSLB | Farms | Update | HTTP Profile

Table of Contents

Global Settings for HTTP Farm Profile
IPDS Rules for HTTP farms
Extras

Global Settings for HTTP Farm Profile #

The HTTP profile manages content-switching at the application layer of the OSI model for both the HTTP and HTTPS protocols. We’ve designed the profile to distribute incoming web traffic across multiple backend resources intelligently by analyzing the content of incoming requests and making routing decisions based on specific parameters such as the URL, cookies, headers, and session information. With this information, we can direct traffic to the appropriate (services) server pools.

In the top right section, we have 2 Indicators. Actions buttons and the Status.
Square box: When clicked, the LSLB farm will stop.
Refresh button: When clicked, the Farm will restart.
Play button: If the farm is off or inactive, it will start when clicked.

Each of the colors described below represents the Status of a given Farm:
Green: Means the farm is UP and all backends are running. It could also mean a redirect is configured.
Red: Means the farm is DOWN or it is unfunctional.
Black: Indicates a CRITICAL damage. Usually occurs when a farm is UP but there is no available backend, or they could be in maintenance mode.
Blue: Shows when there is a PROBLEM. The farm could be running but when at least one backend is down.
Orange: Represents MAINTENANCE. Shows when the farm is running but at least one backend is in maintenance mode.

These color codes are the same all over the graphical user interface. Find a concise explanation about them in the LSLB Farm Section.

In the HTTP(S) farms profile, the HTTP header X-Forwarded-For is filled by default with the client IP address.

Like a reverse proxy, each HTTP(S) farm (or virtual service) manages several services, therefore one HTTP virtual IP and port pair can handle more than one load-balanced web services. Therefore, there is a section called service within the HTTP farm that offers virtual host flexibility and allows the creation of lists of backends for each service.

Each HTTP(S) service uses regular expressions (for virtual host and URL pattern) in PCRE to look for specific patterns in the HTTP headers of the inbound connections. If the pattern matches in both the virtual host and URL pattern field, the backends on that particular service will process those inbound connections.

Basic configuration #

The following are the basic parameters for the HTTP/S farm profile.

Name. This is a name that easily identifies a farm. To change a name of a given farm, you have to stop it first. Ensure that a new name is not in use already.

Virtual IP and Port. These are the virtual IP addresses and port pairs from which the farm will listen for incoming connections. The new IP address and port combination must be unused and available before being configured.

Listener. This field specifies the layer 7 protocol to perform content switching.

HTTP. The virtual service will only receive plain HTTP content.
HTTPS. The virtual service will receive Secure HTTP content, manage SSL handshakes, handle secure cipher configurations, SSL certificates (wildcard or SNI), etc, to perform SSL offloading. This will relieve the real application servers from these heavy tasks.

HTTPS Parameters #

HTTPS Parameters can be found below.

Disable SSLV2, Disable SSLV3, Disable TLSV1, Disable TLSV1.1, Disable TLSV1.2. Each of these toggle buttons enables or disables the associated SSL or TLS version. Disabling any of the protocols is not recommended as its associated ciphers will also be disabled.

Ciphers. This section is where we build lists of ciphers that we use to strengthen an SSL connection. Before a client and server start to exchange information protected by the TLS protocol, they must securely exchange or agree upon an encryption key and a cipher to use when encrypting data.

To configure a cipher for use, select one of the following options.

All. With this command selected, the listening HTTP(S) farm will manage all the available cipher suites. This is the default setting.

High security. This command enables the following ciphers:

kEECDH+ECDSA+AES128:kEECDH+ECDSA+AES256:kEECDH+AES128:kEECDH+AES256:kEDH+AES128:kEDH+AES256:DES-CBC3-SHA:+SHA:!aNULL:!eNULL:!LOW:!kECDH:!DSS:!MD5:!EXP:!PSK:!SRP:!CAMELLIA:!SEED

Enabling this option offers security strong enough to pass with an A+ grade in SSL Labs .

Custom security. This command lets you customize your own ciphers through the Custom Ciphers field.
Custom ciphers. This command lets you customize specific ciphers to allow or forbid when making an SSL connection. It must be a string in the same format as in OpenSSL ciphers . This command will be displayed if Custom security is set.
SSL Offloading. This option enables the AES ciphers to be offloaded via hardware if the processor allows it. This will allow to optimize the performance of the SSL encryption/decryption task.

Available certificates. These are the available SSL certificates installed on the device. To enable each of them, either select the certificate and click the arrow button or simply drag and drop it from the Available box to the Enabled box. You can also enable/disable multiple certificates or even all of them.

Enabled certificates. In this list, you will manage the certificates that are currently in use by the farm. You may move them to the top or bottom with the double top/down arrows or even disable all of them. Take into account the order of the certificates. In case you configure a wildcard certificate before a host certificate, then the wildcard will be used first.

Advanced settings #

Rewrite Location headers. If enabled, the farm is forced to modify the Location and Content-location headers in response to the clients. If they have the value of the backend itself or the VIP but with a different protocol, the response will be modified to show the virtual host in the request. If the toggle button, enabled and compare backends is enabled, only the backend IP address will be compared. This is essential in redirecting a request to an HTTPS listener on the same server as the HTTP listener. If this field is configured in the service section, then this directive will be ignored for that service.

HTTP verbs accepted. This field indicates the HTTP methods that will be used to validate HTTP client requests. If the client’s request is not allowed, an error will be shown to the client. Each verb has additional lower levels of verbs.

Standard HTTP request. Standard HTTP requests (GET, POST, HEAD).
+ extended HTTP request. extended HTTP requests (PUT, DELETE).
+ options HTTP verb. extended HTTP requests (PUT, DELETE).
+ standard WebDAV verbs. standard WebDAV verbs (LOCK, UNLOCK, PROPFIND, PROPPATCH, SEARCH, MKCOL, MOVE, COPY, OPTIONS, TRACE, MKACTIVITY, CHECKOUT, MERGE, REPORT).
+ MS extensions WebDAV verbs. MS extensions WebDAV verbs (SUBSCRIBE, UNSUBSCRIBE, NOTIFY, BPROPFIND, BPROPPATCH, POLL, BMOVE, BCOPY, BDELETE, CONNECT).
+ MS RPC extensions verbs. MS RPC extensions verbs (RPC_IN_DATA, RPC_OUT_DATA).

Ignore 100 Continue. If checked, the 100 Continue property will be disabled. According to the HTTP 1.1 protocol, when this header is sent, the form data is not sent with the initial request. Instead, this header is sent to the web server backend which answers with 100 (Continue). This means that the server has received request headers and that the client should proceed to send the request body (in the case of a request for which a body needs to be sent; for example, a POST request). If the request body is large, sending it to a server when a request has already been rejected based upon inappropriate headers is inefficient. To have a server check if the request could be accepted based on the request’s headers alone, a client must send Expect: 100-continue as a header in its initial request and check if a 100 Continue status code is received in response before continuing (or receive 417 Expectation Failed and not continue).

Logs. Enable or disable farm traffic logs to debug and analyze what is passing through the load balancer.

Backend connection timeout. This value indicates the time the farm will have to wait for a connection to the backend in seconds. Usually, it will be the socket opening wait time. By default, this value will be set to 20 seconds.

Frequency to check resurrected backends. This is how often the load balancer will wait to check if a backend is reachable and to get out a blacklisted real server if it is up. The farm will be checking the backend periodically once the real server is marked as down, regardless of whether there is a new client connection or not. By default, this value will be set to 10 seconds.

Backend response timeout. This value indicates the time the farm will have to wait for a response from the backends in seconds. By default, this value will be set to 45 seconds.

Client request timeout. This value indicates the time the farm will have to wait for a client’s request. Once this timeout is reached without getting any data from the client, the connection will get terminated. By default, this value will be set to 30 seconds.

HTTP error messages #

Personalized error messages. The farm service will display a custom message on your site when a web code error is detected from the real servers. A personalized HTML page will be shown for error codes 414, 500, 501, and 503.

414: Request-URI Too Long. This is the error message by the HTTP/S profile if the URI reaches the maximum number of characters allowed. If you receive this error, shorten the length of the URL.
500: Internal Server Error. This is the error message by the HTTP/S profile if the backend encounters an unexpected command
501: Not Implemented. This is the error message by the HTTP/S profile if the request verb isn’t managed or known by the proxy or backend.
503: Service Unavailable. This is the error message by the HTTP/S profile if the proxy doesn’t find an available backend for the request. This might happen when all backends or servers are down, or because the regular expression in the request doesn’t match with any configured service.
WAF 403: Forbidden. This is the error message by the HTTP/S profile if the WAF is enabled and the WAF engine rejects the request.

Headers #

In this section, we can add, modify or delete request and response headers globally, applying actions to all the configured services. If a header is configured in the service section, that configuration will be discarded.

The actions to use in this section include:

Create rule. A global header rule will be created.
Delete. A global header rule will be deleted.

This section allows us to add, modify or create Header requests and responses as shown in the image below.

Type.

Request: remove header. Header pattern that will be removed from the client HTTP requests.
Request: modify header. Modify the header from the client HTTP requests.
Request: add header. The header that will be added to the client HTTP requests.
Response: remove header. Header pattern that will be removed from the Backend HTTP response.
Response: modify header. Modify the header from the Backend HTTP response.
Response: add header. The header that will be added to the Backend HTTP response.

Services Settings #

The services within an LSLB farm with an HTTP profile provide content-switching capabilities for web virtual services to deliver multiple web services and applications through the same virtual IP and PORT. This helps to unify web applications through a single domain, manage virtual hosts, manage URLs, configure redirects, configure persistence and backends per service. Each service within an LSLB farm has various properties, health checks, persistence, Header management, and a backend list. Regular expressions may be used to match conditions that will specify the service to be used per request.

Each service match condition will be checked by the HTTP farm profile core in priority mode (that can be altered if needed). If no service is matched then the farm core will return an error (HTTP error 503). For this reason, specific multiple-service definitions are allowed. If URL and Host’s fields are not defined, all requests will match. The HTTP service conditions will be determined by a virtual host and/or a URL pattern.

First, creating and adding at least one backend server to a service is a necessity. Once the new service is applied, the HTTP services will be evaluated from top to bottom in the list order. The first service to match in Host and/or URL field will process the request. Those service conditions are determined by URL or Host patterns.

The service conditions to be matched are:

Virtual Host. This feature allows you to define a condition based on the domain name using the same virtual IP and port within an HTTP farm. If you want to remove this condition, you can leave the field empty. Regular expressions in PCRE format are supported in this field.

URL pattern. The purpose of this field is to identify a web service based on the URL path that the client is requesting. The URL will be evaluated against a designated pattern, ensuring its syntax is correct. If you wish to disregard this condition, you can leave the field empty. Regular expressions in PCRE format are supported in this field, allowing for advanced pattern matching.

The Virtual Host and URL pattern values are regular expressions. If left empty, any value will match. Both fields must match or it’ll skip to the next service. It is recommended to use at least one, serving as the default if there is no match detected at the bottom.

Rewrite Location headers. If enabled, the service is forced to modify the Location and Content-location headers in response to the clients. If they have the value of the backend itself or the VIP (but with a different protocol) the response will be modified to show the virtual host in the request. If the toggle button enabled and compare backends is enabled, then only the backend IP address is compared. This is essential when redirecting requests to an HTTPS listener on the same server as the HTTP listener. When enable and compare backends is selected, a flag called Enable path for Rewrite location Headers will be available. Enable this flag if you are working with Rewrite URLs. This value will force you to check the URL responses and will change the response to the original if a rule is configured in Rewrite URLs. If this field is enabled, it will override the same directive in the global section.

Redirect #

If the service has the redirect option enabled, backend servers may not be used as all the requests will be sent to the specified URL.

Redirect Type. There are two redirect types: Default and Append. With the Default type, the URL is taken as an absolute host and path to redirect to. With the Append type, the original request path will be appended to the host and the path you specified.

Redirect URL. This parameter controls where the client will be redirected after a request is answered. The client request is answered automatically by redirecting to a new URL. If you configure a redirect value, DON’T configure backends in this service. If the Virtual Host and the URL pattern match, the appliance will send an HTTP Location Header response to the client in order to be redirected to the configured URL.

Redirect Code. Several redirect HTTP codes could be used: 301 (Moved Permanently), 302 (Moved Temporarily), or 307 (Temporary Redirect).

Persistence #

Persistence. This parameter defines how the HTTP service is going to manage the client session and which HTTP connection has to be controlled to maintain safe client sessions. When a type of persistence session is selected, its Time To Live TTL(seconds) will be shown.

No persistence. The farm service won’t control the client sessions. The HTTP or HTTPS requests will be delivered to real servers.
IP: Client address. The client IP address will be used to keep the client sessions open through the real servers.
BASIC: Basic authentication. The HTTP basic authentication header will be used to control the client sessions. For example, when a web page requests a basic authentication from the client, an HTTP header will contain a string like the following:
```
		HTTP/1.1 401 Authorization Required
		Server: HTTPd/1.0
		Date: Sat, 27 Nov 2011 10:18:15 GMT
		WWW-Authenticate: Basic realm="Secure Area"
		Content-Type: text/HTML
		Content-Length: 31
```
Then the client answer with the header:
```
                GET /private/index.html HTTP/1.1
		Host: localhost
		Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
```
This basic authentication string is used as an ID for the session to identify the client session.
PARM: A URI parameter. Another way to identify a client session is through a URI parameter separated from a semicolon character that is used as a user session identifier. In the example http://www.example.com/private.php;EFD4Y7 the parameter will be used as the session identifier.
URL: A request parameter. When the session ID is sent through a GET parameter with the URL, this parameter indicates that the name associated with the client session ID will be possible. For example, a client request like http://www.example.com/index.php?sid=3a5ebc944f41daa6f849f730f1 should be configured with the parameter Persistence Session Identifier (sid value in this example) and the persistence session time to life (TTL)
COOKIE: . You’ will be able to select an HTTP cookie variable to read from the HTTP Headers and use it to maintain client sessions for a given time. The configured cookie name in the persistence session identifier field is created by a programmer and embedded into a webpage to identify the client session, for example:
```
                GET /spec.html HTTP/1.1
                Host: www.example.org
                Cookie: sessionidexample=75HRSd4356SDBfrte
```
Additionally, Persistence session Time To Life(TTL) should be configured. This value manages the time that the load balancer saves when the client and the backend go without any activity.
HEADER: a request header. An HTTP header custom field could be used to identify the client session. The persistence session Time To Life and persistence session identifier is required to be configured. For example:
```
               GET /index.html HTTP/1.1
               Host: www.example.org
               X-sess: 75HRSd4356SDBfrte
```

Cookie #

Cookie insert. If defined, the load balancer will create a cookie in each response with the appropriate key of the backend. Even if the session table is flushed or sessions are disabled, the proper backend will be chosen. This feature avoids changing the real server code to create a session cookie.

The Cookie Name A name of a cookie that will be created and added to the client request / backend response. The Cookie Path is the URI or relative path where the new cookie will be created. For the whole domain, the character needs to be set. Cookie Domain is the domain where the cookie is going to be created. Finally, Cookie TTL is the number of seconds the cookie will be kept in memory between the client and backend. This field must be greater than 0. And this time is related to the time without any activity. After reading the indicated seconds without any activity the persistence session will be deleted.

Farmguardian #

HTTP farms provide a basic and native backend health check but the Farmguardian configuration is recommended for smarter heuristics backend health checks to ensure that the application is healthy.

Some built-in or customized advanced health checks can be assigned to this service from the already created farmguardian checks.

For further Farmguardian information go to the Monitoring >> Farmguardian section.

Notice that after selecting the farmguardian, it will be automatically applied to the farm.

HTTPS Backends. This checkbox indicates to the farm that the backend servers defined in the current service are using the HTTPS protocol so the data will be encrypted before being sent.

Backends #

Regarding the Backends, the HTTP farm profile allows the configuration of the following properties: All the backends must be IPv4 or IPv6, and with the same IP version as the Farm VIP.

ACTIONS. Use the following actions to manage the backends:
For already created backends:

Enable Maintenance. Use this action if the backend was previously disabled. Placing a real server in maintenance mode means that no new connections will be redirected to it. There are two methods for enabling the maintenance mode:
- Drain Mode. Keeps established connections and persistence if enabled, but will not admit new connections.
- Cut Mode. Drops all active connections against the backend
Disable Maintenance. Use this action when the backend is in maintenance mode. Enable new connections to the real server again after disabling maintenance mode.
Delete. Remove configurations of a selected virtual service. The alias won’t be deleted if there is any.

ALIAS. Backend alias, if any alias was selected.
IP. The IP address of a given backend.
PORT. The port number of the current real server.
TIMEOUT. The time a backend takes to respond. This value overrides the parameter of the global Backend connection timeout but it is limited to this selected farm.
WEIGHT. The weight value for the current real server. More weight indicates more connections delivered to the current backend. By default, a weight value of 1 will be set. The values range available is from 1 to 9.
STATUS. The possible values are:

Up. The farm is running and the backend is ready to receive connections.
Down. The farm is running and the service has detected that the backend is not working
Maintenance. Backend is marked as not ready for receiving connections by the administrator, this option is useful for backend’s maintenance tasks
Undefined. The backend status has been not checked.

PRIORITY. The priority value for the current real server. Lower values have more priority. The default service priority value is 1. When a backend fails, the service priority is increased by 1. When the backend is alive again, the service priority value is decreased by 1. Active backends contain priority values less than or equal to the service priority.
CONNECTION LIMIT. The maximum number of concurrent connections that the backend will handle. If this value is reached, new connections to the backend will be blocked and the client will receive an HTTP 503 error.

Add backend form:

Through the Actions menu button, the following actions are available for one or more selected backends:
Add Backend. This command opens the backend creation form.
The actions mentioned above: Enable maintenance (Drain and Cut mode), Disable maintenance and Delete.

Rewrite URLs #

It checks a pattern to get strings from URLs and replace them. Several configurations can be added. All of them will be sequentially applied to the incoming URL unless the last flag is set that will finish the rewrite URL phase and the other Rewrite URLs patterns will not be evaluated.

In this section, the URL request is analyzed by the HTTP proxy engine, if the URL request matches the Pattern then the URL request is sent to the client with the Replace regular expression configured. When the response is received by the load balancer from the backend the change to the real URL will be done just in case the Rewrite Location Header is activated for the service with the value Enable path for Rewrite location Headers.

For example, if Pattern is configured with the value /media/(.+)$ and Replace with value /svc1/$1, the client request https://vhost.domain.com/media/console will be sent to the backend with the value https://vhost.domain.com/svc1/console

IPDS Rules for HTTP farms #

This section let you enable IPDS rules. The list shows different types of protection and a select box to enable them. For further information please go to the IPDS >> Blacklists rules, IPDS >> DoS rules, IPDS >> RBL rules or IPDS >> WAF rules specific documentation.

For each of the four types of IPDS rules, Blacklist, DoS, WAF, and RBL, there are two tables, Available and enabled. There is also a chain icon. Under the Available table, you will see that all the available rules are of the same kind, and can be applied to a given farm. Regarding the enabled table, you will see that the rules applied to the selected farm are of the same type. There is also a status symbol for each rule which tells if the rule is stopped (red color) color or if it is running (green color).

Each rule can be accessed by clicking on the edit icon which will allow you to change rule parameters or even start/stop the rule. You will not be able to create a new rule inside this farm view. Change it through the IPDS section.

Add a rule by clicking on the desired rule followed by clicking on the right single arrow. Or, you can select more than one by simultaneously keying the shift key and selecting the rules that you want to add. You will then click the right single arrow. You can also add all the available blacklists by clicking on the right double arrow.

To delete one or more rules, select them and click on the left arrow or click on the double arrow to remove all.

Extras #

Check out our video to know how easy is to configure an HTTPS redirection with RELIANOID.

Updated on 25 April, 2024