Contents
Global Settings for HTTP Farm Profile
This profile manages content switching at the HTTP layer 7 application delivery for both HTTP and HTTPS protocols.
The Farm Status is shown by mean the color bullets as follow:
- Green: Means UP. Farm is running and all backends are UP or the redirect is configured.
- Red: Means DOWN. Farm is stopped.
- Yellow: Means RESTART NEEDED. There are recent changes that need a farm restart to be applied.
- Black: Means CRITICAL. The farm is UP but there is not backend available or they are in maintenance mode
- Blue: Means PROBLEM. Farm is running but at least one backend is down.
- Orange: Means MAINTENANCE. Farm is running but at least one backend is in maintenance mode.
Those color codes are the same all over the graphical user interface. You could see them better explained in the LSLB Farms Section
In the HTTP(S) farms profile, the HTTP header X-Forwarded-For is filled by default with the client IP address.
Every HTTP(S) farm (or virtual service) is able to manage several web services like a reverse proxy, therefore one HTTP virtual IP and port pair can handle more than one load-balanced web service. For that reason, there is a section called service under an HTTP farm in order to offer virtual host flexibility and allow to create a list of backends for each service.
Each HTTP(S) service uses a combination of regular expressions (for virtual host and URL pattern) in PCRE in order to manage all the incoming connection whose HTTP header matches both.
Basic configuration
Basic parameters for HTTP/S farms profile are the following:
Name. It’s the identification field and a descriptive name for the farm service. It won’t be possible to change the farm name unless the farm is stopped in the first place. Ensure that the new farm name isn’t already in use.
Virtual IP and Port. These are the virtual IP address and port pair from which the farm will be listening for incoming connections. The new IP address and port combination must be unused and available prior to being configured.
Listener. This field specifies the protocol to be managed at layer 7 for content switching.
- HTTP. The virtual service will only understand plain HTTP content.
- HTTPS. The virtual service will understand Secure HTTP content, it’ll manage SSL handshake, handle secure ciphers configurations, SSL certificates (wildcard or SNI), etc, in order to perform SSL offload and relief the real application servers from these heavy tasks.
HTTPS Parameters
HTTPS Parameters can be found below.
The Disable SSLV2, Disable SSLV3, Disable TLSV1, Disable TLSV1.1, Disable TLSV1.2 selectable buttons if selected, avoid using those given protocols. By default TLSv1.3 can’t be disabled. Thus, once a protocol is disabled, its ciphers will also be disabled.
Ciphers. This field is used to build a list of ciphers accepted by SSL connections in order to harden that connection. Before a client and server can begin to exchange information protected by TLS, they must securely exchange or agree upon an encryption key and a cipher to use when encrypting data. Further information about security can be found on external resources such as Wikipedia.
In order to configure which cyphers will be used, please select one of the following options.
- All. This item indicates that all ciphers are allowed to be managed by the HTTPS listener. This is the default setting.
- High security. This option 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
Which they’ll be enough to pass through an A+ in SSL Labs .
- Custom security. This option allows setting your own allowed ciphers through the Custom ciphers field.
- Custom ciphers. This allows you to customize which ciphers will be allowed or forbidden to be used by the SSL connection. It must be a string in the same format as in OpenSSL ciphers . This option will be displayed if Custom security is set.
- SSL Offloading. This version includes SSL Offloading capabilities which increase performance on AES CPUs compatible. If your hardware implements these capabilities this option will be shown. Otherwise, it will not.
Available certificates. These are the available SSL certificates installed in the device. To enable one of them you could either select the certificate and press the arrow button or you could 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 can see, manage and order the certificates that are currently in use by the farm. You can move to the top or bottom with the double top/down arrows or even disable all of them but one with the left double arrows.
Advanced configuration
Rewrite Location headers. If enabled, the farm is forced to modify the Location and Content-location headers in responses 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 option enabled and compare backends is selected then only the backend IP address is compared, this could be useful to redirect a request to an HTTPS listener on the same server as the HTTP listener.
HTTP verbs accepted. This field indicates the HTTP operations that will be permitted in the HTTP client requests. If a not allowed verb is requested an error will be shown to the client. Each verb level includes its verbs and additionally lower levels verbs.
- Standard HTTP request. Standard HTTP requests (GET, POST, HEAD).
- + extended HTTP request. 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 how long the farm is going to wait for a connection to the backend in seconds. Usually, it will be the socket opening time wait. By default, this value will be set to 20 seconds.
Backend response timeout. This value indicates how long the farm is going to wait for a response from the backends in seconds. By default, this value will be set to 45 seconds.
Frequency to check resurrected backends. This value in seconds is how long the load balancer will wait to check if a backend is reachable again and to get out a blacklisted real server if is alive. 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.
Client request timeout. This value indicates how long the farm is going to wait for a client request in seconds. Once this timeout is reached without getting any data from the client, the connection will be closed. By default, this value will be set to 30 seconds.
Personalized error messages. Through the personalized error messages, the farm service is able to answer a custom message of 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.
Add Request Headers. List of headers that will be added to the client HTTP requests.
Remove Request Headers. List of header patterns that will be removed from the client HTTP requests.
Add Response Headers. List of headers that will be added to the Backend HTTP response.
Remove Response Headers. List of header patterns that will be removed from the Backend HTTP response.
Services Settings
The services within an LSLB farm with HTTP profile provides content switching capabilities for web virtual services to deliver multiple web services and applications through the same virtual IP and PORT, which helps to unify web applications through one single domain, manage virtual hosts, manage URLs, configure redirects, configure persistence and backends per service. Every service within an LSLB farm has different properties, health checks, and backend list. Regular expressions can be used as match conditions that can specify which service should be used per request.
Every service match condition will be checked by the HTTP farm profile core in priority mode (that can be altered if needed) and if none service is matched then the farm core will return an error. For this reason, specific multiple service definitions are allowed. If no URL is defined then every request will match. The HTTP service conditions will be determined by a virtual host and/or an URL pattern.
First, it’s required to create at least one service in order to add backends.
After the creation, you will be asked to Restart the farm in order to apply the new service.
Once the new service is applied, the HTTP services are evaluated top to bottom in the list order, the first service to match both conditions will process the request. Those services conditions could be determined by URL patterns, specific headers or redirection and allow to identify several web services in through the same farm.
The service conditions to be matched are two:
Virtual Host. This field specifies the condition determined by the domain name through the same virtual IP and port defined by an HTTP farm. In order to discard this condition just leave it empty. This field supports regular expressions in PCRE format.
Url pattern. This field allows determining a web service regarding the URL the client is requesting through a specific URL pattern which will be syntactically checked. In order to discard this condition just leave it empty. This field supports regular expressions in PCRE format.
The Virtual Host and URL pattern values are regular expressions, if they are left empty any value will match. Both fields must match or it’ll skip to the next service. It’s recommended to include one service as the default one if there is no match detected at the bottom.
HTTPS Backends. This checkbox indicates to the farm that the backends servers defined in the current service are using the HTTPS protocol so the data will be encrypted before to be sent.
Strict Transport Security
HTTP Strict Transport Security, or HSTS, is a web security policy to prevent threats during web traffic communication or cookies disclosure. Web browsers need to support this option.
By default, in HTTPS farms is enabled in all services.
STS Header. Checkbox to enable or disable this option.
Timeout. Expiration timeout of this header.
Redirect
If the service has the redirect option enabled, then backend servers cannot be used as all the requests will be sent to the specified URL.
Redirect URL. This field behaves as a special backend, as the client request is answered automatically by a redirect to a new URL. If you configure a redirect value then DON’T configure backends in this service. If Virtual Host and URL pattern match then ZEVENET sends an HTTP Location Header response to the client in order to be redirected to the configured URL.
Redirect Type. There are two options: Default or Append. With the Default option, the URL is taken as an absolute host and path to redirect to. With the Append option, the original request path will be appended to the host and path you specified.
Redirect Code. There are several redirect HTTP codes that 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 field has to be controlled to maintain safe client sessions. When a type of persistence session is selected a persistence session TTL will be shown.
- No persistence. The farm service won’t control the client sessions and the HTTP or HTTPS requests will be delivered to real servers.
- IP: Client address. The client IP address will be used to keep open the client sessions 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 to 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.
- URL: A request parameter. When the session ID is sent through a GET parameter with the URL will be possible to use this option indicating the parameter name associated with the client session ID. For example, a client request like http://www.example.com/index.php?sid=3a5ebc944f41daa6f849f730f1 should be configured the parameter Persistence Session Identifier:
- 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.
- COOKIE: a certain cookie. Also, you’ll be able to select an HTTP cookie variable to maintain the client session through the COOKIE option. A cookie has to be created by the real app programmer into the webpage to identify the client session, for example:
GET /spec.html HTTP/1.1 Host: www.example.org Cookie: sessionidexample=75HRSd4356SDBfrte - HEADER: a certain request header. An HTTP header custom field could be used to identify the client session. For example:
GET /index.html HTTP/1.1 Host: www.example.org X-sess: 75HRSd4356SDBfrte
Persistence Session Time To Live. This value indicates the max time of life for an inactive client session (max session age) in seconds.
Persistence Session Identifier. This field is the URL parameter, cookie or header field name that will be analyzed by the farm service and will manage the client session.
Cookie
Cookie insert. If defined, the HTTP farms will inject a cookie in each response with the appropriate key of the backend, so that 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 It’s the name of the cookie that will be created and added to the client request. 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.
After the service configuration, it’ll be required to update the changes through the green button Submit.
Farmguardian
HTTP farms provide a basic and native backend health check but the Farmguardian configuration is recommended for smarter heuristics backends health checks in order to ensure the real state of the application health.
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.
Backends
Regarding the Backends section, the HTTP farm profile allows you to configure the following real servers properties:
All the backends must be IPv4 or IPv6, with the same IP version as the Farm VIP.
ID. It’s the index that references the backend in the farm configuration.
ALIAS. Backend alias, if any alias was selected.
IP. The IP address of the given backend, if you have selected any alias, this field will be not editable, you should change the alias field. If you have selected ‘Custom IP’ in the alias field, it will be editable for the desired IP.
PORT. It’s the port value for the current real server.
PRIORITY. It’s the priority value for the current real server, lower values are more priority. the initial value of priority is 1 and when a backend fails, +1 is added to this initial value, if the priority amount is minor or equal than the priority value for the backend then this backend will be used. When a backend is alive again -1 is reduced of the initial priority value.
TIMEOUT. It’s the specific timeout value for a backend to respond. This value overrides the global Backend connection timeout farm parameter for the current backend.
WEIGHT. It’s the weight value for the current real server. More weight value indicates more connections delivered to the current backend. By default, a weight value of 1 will be set. The values range available are from 1 to 9.
ACTION. The available actions per backend are:
For already created backends:
- Enable Maintenance. This action is available just if the backend was previously enabled. To put a certain real server in maintenance mode means that no new connections will be redirected to it. There are two different methods to enable 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. This action is available if the backend is maintenance. Enable new connections to the real server again after the enabled maintenance.
- Delete. Delete the given real server of the virtual service. The alias won’t be deleted if there is any.
Add backend form:
You will be able to configure the same parameters as described before but the id, once the configuration of the fields is finished, click on the Save button in order to create the backend.
Through the Actions menu button the following actions are available for one or more selected backends:
- Add Backend. This option opens the backend creation form.
- The actions mentioned above: Enable maintenance (Drain and cut mode), Disable maintenance and Delete
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 and a chain icon which redirects to its IPDS section. Under the Available table it can be seen all the available rules of the same kind, that can be applied to the farm. Under the enabled table, it can be seen each rule of the same type applied to the farm, there is also a status ball for each rule which tells if the rule is stopped in red or running in green.
Each rule can be accessed clicking on the edit icon which will allow you to change rules parameters or even start/stop the rule. It is not possible to create a new rule under this farm view, you should do it through the IPDS section.
You can add one rule, clicking on the desired rule and then on the right single arrow, or more than one, keeping shift key pressed and selecting the rules that you want to add, then you will need to click on the right single arrow. You can also add all available blacklists by clicking on the right double arrow.
To delete one or more rule, 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 ZEVENET.