Virtual Host
The ADC Virtual Host page includes the following sections. Click on the link to go to the corresponding section to learn more:
To go to the documentation for the previous section of the manual, see Deny and Error Handling . To go to the documentation for next subsection in the ADC section, see Load Balancing .
To access the Virtual Host page in the WAF management interface:
- On the left panel, under Services, click Websites.
- On the Websites page, click the website you want to manage.
- Under ADC, click Virtual Host.
To save configuration changes or edits you make to any features and options, you must click Save on the lower-right of the section or page where you are making changes. Click apply changes on the upper-left corner of the page, and then click OK. Your changes will not be stored if you do not properly save your changes.
The virtual host is the website proxy that is accepts requests for the web servers serving the website for which the ADC is proxying requests.
Alert Logic Managed Web Application Firewall (WAF) is designed to easily fit into complex data centers without sacrificing the inherent protection advantages of the reverse proxy deployment mode. This is achieved through the deployment options reverse proxy and routing proxy. Both deployment options offer the full set of WAF features including inspection, rewriting, blocking of outgoing server responses, accelerating, caching and compression.
The two deployment options can be used in combination on the same appliance as the deployment option applies to single websites. The same appliance can serve websites deployed in routing proxy and reverse proxy mode at the same time.
Reverse proxy
In reverse proxy, the appliance terminates all traffic destined to the website it protects. For HTTP(S), traffic requests are validated and forwarded to the backend web server on behalf of the client.
A number of IP addresses are assigned to the appliance. The number of IP addresses required depends on the number of SSL websites, and the type of SSL certificates used. As a general rule, one unique IP address is required for each certificate deployed on the appliance.
To direct traffic through the reverse proxy, either NAT rules or DNS must be altered to point to the appliance. If it is required that traffic to other (non-http) services reach the web server from the Internet, then you must create separate NAT rules for the ports serving those services that bypass the appliance.
Reverse proxy completely shields the web server infrastructure and allows for inspection of both client requests and server responses. This also rewrites and inserts cryptographic tokens that allow protection against session hijacking, cross-site request forgery, and similar attacks.
Reverse proxy is easy to implement, but a number of extra IP addresses are required. For more complex data centers, reverse proxy is not recommended because of the number of changes that are required for the network firewall NAT rules.
Routing proxy
Routing proxy deployment has all the advantages of reverse proxy both in terms of protection, acceleration, caching and compression. All features available for reverse proxy are also available in routing proxy deployment.
The major difference is that routing proxy deployment does not require more than one IP address for each of the WAF appliances network interfaces and the only change necessary on the network firewall (or router) is to configure it to route traffic to the protected web servers through WAF. Web traffic to the protected servers are picked up and validated while traffic to other protocols like SSH, SMTP and FTP are routed through to the backend web servers.
The ability to route traffic to other services also means that only the HTTP services on the backend web servers are protected by the appliance. Sine the IP addresses and network firewall policy rules leave a small footprint, this deployment option is the best one for complex data centers.
Virtual web server
Web server
Read only |
Protocol and fully qualified domain name (FQDN) for the website the proxy is configured for. |
Website status
Drop-down list |
Controls if WAF serves the website by the node.
|
Proxy name
Input field |
The name of the website proxy when listed in overview tables and reports.
|
Deployment
Drop-down list |
The proxy deployment mode.
For a description of the deployment options, refer to Deployment. |
Listen IP
Select combo |
The IP address to which the virtual host is bound. Click to change the IP address configuration.
|
HTTP listen port
Input field |
The port number the virtual HTTP host is listening to.
|
HTTPS listen port
Input field |
The port number the virtual HTTPS host is listening to.
|
Vhost test
Button |
Click HEAD Request to test the VHOST. |
SSL certificate
In the SSL certificate section, the current SSL certificate in use is displayed. To upload a new certificate, click the
.When you create an SSL website, WAF gives this website a temporary SSL certificate. You are able to substitute the temporary certificate with a signed certificate. These actions are only intended for SSL enabled website proxies, and the SSL section is only shown for SSL enabled website proxies.
Exporting certificate from web server
When you create a website proxy for an existing HTTPS web server, you need to export the SSL certificate from the web server, and import the certificate toWAF. WAF supports the imports of the following formats:
- PKCS12 (or PFX): The standard format that Microsoft IIS servers use. It stores public key, private key, and the key chain in one single encrypted file.
- PEM: Commonly used in *nix based web servers like Apache and Nginx. When ordering certificates, this format is often referred to as “Apache format.”
- Intermediate: A subordinate certificate where the chain begins at the trusted root, through the intermediate and ending with the SSL certificate issued to you.
The links below open procedures that refer to third party products and guidelines, and may change at the vendors discretion.
The following options show you how to export an SSL certificate from the most common servers. To export a certificate from the web server, refer to the vendors guidelines.
Export an SSL certificate from a Microsoft IIS server
When you export an SSL certificate from a Microsoft IIS server, the certificate is usually obtained in PKCS12 (.pfx) format. The instructions for exporting from IIS 7 below includes the SSL certificate chain.
Microsoft guidelines can be found on the links below:
Add the certificate
To add a certificate:
- Open the Windows Start menu.
- In the Search box, type MMC and then click OK.
- Click the File tab, and then select Add/Remove Snap-in.
- Click on Certificates, and then click Add.
- Select Computer Account, and then click Next.
- Select Local Computer, and click Finish.
- Click OK to close the Add/Remove snap-in window.
- In the center pane, double-click Certificates (Local Computer) in the center window.
Export the certificate
To export the certificate:
- Double-click on the Personal folder, and then click Certificates.
- Right-click the certificate you want would like to backup, and then select ALL TASKS and then Export.
- Follow the Certificate Export Wizard to backup your certificate to a .pfx file.
- Select Yes, export the private key.
- Select Include all certificates in certificate path if possible.
Do not select the delete Private Key option.
- Type a password you can remember, and then save the file.
- Click Finish. You see the following message, "The export was successful."
- Click OK.
Export an SSL certificate from an Apache server
For apache-based web and application servers with default PEM encoding, the SSL certificate can be copied directly from the file system and imported as is when the default PEM encoding is used.
Obtain the SSL-certificate file from the web servers file system. By default, the file is PEM-encoded.
The exact location may vary, but the Apache config file (httpd.conf) shows the exact location as in the example below:
<VirtualHost 192.168.0.1:443>
DocumentRoot /var/www/html2
ServerName www.yourdomain.com
SSLEngine on
SSLCertificateFile /path/to/your_domain_name.crt SSLCertificateKeyFile
>/path/to/your_private.key
SSLCertificateChainFile /path/to/CA_chain.crt
</VirtualHost>
Where:
SSLCertificateFile is the server public key.
SSLCertificateKeyFile is the server private key.
SSLCertificateChainFile is the certificate chain.
Keep the contents of the files open. You will need it for the PEM (Apache) certificate upload section.
When you create an SSL website, WAF assigns the website a temporary SSL certificate. You are able to substitute the temporary certificate with a signed certificate.
Depending on the format of the certificate, select the appropriate action in the bullet list.
Importing the PKCS12 format
To import a certificate in PKCS12 format:
- Select Import SSL certificate (PKCS12 format).
- Click Choose File to browse your system for the file location.
- In Passphrase input, type the passphrase.
- Leave Validate certificate chain selected.
- Click Save settings in the lower right corner of the page.
- Click apply settings at the top of the page to apply the certificate to the run-time configuration.
Importing the PEM format
To import a certificate in PEM format:
- Select Import SSL certificate (PEM format).
- Open the .PEM file(s) in a text-editor. When obtained from the web server, the following extension convention is usually used:
*.crt – public keys, both server and CA chain
*.key – the private key
- Copy the public certificate section of the certificate into the SSL public key/certificate field.
The public certificate is the section of the certificate file between (and including) the certificate start and end tags.
-----BEGIN CERTIFICATE-----
Certificate characters
-----END CERTIFICATE--
- Copy the (SSL) private key section of the certificate into the SSL private key field.
The (SSL) private key is the section of the certificate file between (and including) the private key start and end tags.
-----BEGIN RSA PRIVATE KEY-----
Private key characters
-----END RSA PRIVATE KEY-----
- In the Passphrase, field type the passphrase for the private key (if the original private key was encrypted).
- Leave Validate certificate chain selected.
When selected, WAF validates that the certificate chain is complete and ordered correctly. Do not clear this option unless the certificate import is generates certificate chain errors that you must adjust manually after import.
- Click Save Settings in the lower right corner of the page.
- Click Apply Settings at the top of the page to apply the certificate to the run-time configuration.
- (Optional) In SSL authority certificate(s) chain, if a certificate authority chain is provided with your certificate, enter the entire list of certificates (more than one certificate may be provided).
- Click Save settings. The imported certificate is displayed in the certificate table along with the certificate chain (if any). Verify that the certificate is imported correctly.
- Click the Apply settings.
Importing the intermediate certificate
To import an intermediate certificate:
- Select Edit Certificate Chain.
- Open the intermediate certificate in a text-editor. When obtained from the web server, the following extension convention is usually used:
The public key/certificate is the section of the certificate file between (and including) the certificate start and end tags.
<-----BEGIN CERTIFICATE--->
Certificate characters
<-----END CERTIFICATE--->
- Click Save settings in the lower right corner of the page.
- Click apply settings at the top of the page to apply the certificate to the run-time configuration.
SSL settings
Minimum SSL protocol version.
To configure WAF to handle requests for host aliases to the main configured domain name (e.g. www.mydomain.com), add a list of aliases in this section.
If the web system that answers requests to www.mydomain.com
also serves requests to mydomain.com
, www.mydomain.net
and mydomain.net
and uses the same content as www.mydomain.com
, then WAF handles and validates the alias domain names as aliases to
the main virtual host when added to this section.
Virtual host aliases
Input area |
A list of host names.
|
When WAF is deployed as a proxy, requests for virtual host aliases are filtered and forwarded without modification to the host header.
Wildcards
You can use the wildcard character *
to match the server name part of the domain name (e.g. www). If for instance, the domain names www. domain.net
, www2.domain.net
, www3.domain.net
and webserver.domain.net
all point to the same server the wildcard expression *.domain.net
is used to match all HTTP requests pointing to domain.net. This is provided that the DNS records of the respective
hosts all point to WAF.
Default proxy
When enabled, the proxy is used as the default host for requests of the IP address to which the proxy is configured to listen. The default proxy responds to all requests for virtual hosts that are not configured as primary host name, or as a virtual host for other proxies listening to the same IP address. This allows you to configure a single proxy that serves requests for several host names that the same backend web server serves without adding all the virtual host names in WAF.
Client READ header timeout
Input field |
Max time to wait for the client request header.
|
Client READ body timeout
Input field |
Max time to wait for the client request body.
|
Client SEND timeout
input field |
Max time to wait for a client send to complete.
|
HTTP request and connection throttling
HTTP request throttling
HTTP request throttling status
Info |
Displays the global HTTP throttling status. Click configure to be redirected to the HTTP request throttling section where you can change your settings. |
Maximum burst rate
Input field |
The amount of requests the client is allowed to exceed the allowed request rate. For instance, if the maximum burst rate is set to 20 per second and the request rate is limited to five request, then the client can issue 20 requests for one second. Then must wait four seconds until the rate is balanced. When a client loads an html page, it typically results in a lot of sub-requests for graphic elements, style sheets, javascript, etc. Setting a reasonable burst rate allows for fast page loads when the request rate is limited.
|
Throttling action
Drop-down list |
How to handle exceeding limits of the client.
|
Throttling zone
Drop-down list |
Client request rate is tracked across website proxies using four global databases, throttling zones. To account for different usage patterns throttling limits are defined separately for each global throttling zone. |
HTTP connection throttling
HTTP connection throttling status
Info |
Displays the global HTTP connection throttling status. Click configure to be redirected to the HTTP connection limiting section where you can change your settings. |
HTTP connection throttling zone
Drop-down list |
Client request rate is tracked across website proxies using four global databases, throttling zones. To account for different usage patterns throttling limits are defined separately for each global throttling zone. |
HTTP requests often pass through one or more proxy servers before reaching the endpoint web server. Examples include web gateways in the client network, content delivery networks (CDN), caching servers, SSL accelerators, layer 7 load balancers and web application firewalls. Each time the request passes through a proxy server, the source IP of the request changes to the IP address of the proxy server. This meanst he source IP from the network connection (socket) cannot be the IP address of the original request. To account for this, the standard is that proxy servers insert the client source IP in a request header named X-Forwarded-For. This is the default behavior of Alert Logic Managed Web Application Firewall (WAF).
Another option is to configure WAF as a Transparent Proxy, which reinserts the client source IP before it forwards the request to the backend web environment.
Play tricks at the network level to inject the client IP as the source of the request to the backend server. This requires modification of default gateway at the backend server to make the response go back through WAF.
Transparent Proxy |
You must enable and configure transparent proxy. |
You can apply transparent proxy configuration to both routing proxy and reverse proxy deployment modes. When enabled, WAF inserts the client source IP in the request to the backend web server to preserve it. In practice, the transparent proxy spoofs the client source IP which is why this feature is sometimes also called client impersonation.
While transparent proxy preserves the client source IP in the HTTP requests the backend web server receives, it has a few drawbacks of performance and availability risk. Because the original client IP is inserted as the source IP of the connection that is made to the backend, every request to not reuse connections from other client IPs requires a new connection. This negatively impacts the performance. WAF deployed as either reverse or routing is easy to bypass if both nodes in a cluster fails, because only a change a NAT rule or a static route is required. This is further complicated when it is proxying transparently because the backend web servers are configured to use the WAF cluster as a gateway. This means that each backend web server must be reconfigured to restore availability in the unlikely event that both WAF nodes in a cluster fails.
The original client source IP needs WAF configured as the default gateway for the web server response to come back through WAF. This also means that it is complicated and error prone to implement use transparent proxy in high performance deployments where WAF is deployed in combination with a load balancer.
To minimize the availability impact on the web properties the configuration of transparent proxy must performed in the following order:
- If WAF is deployed as a cluster, create a cluster interface with an VIP that the backend web servers can reach in System> Clustering.
- Enable IP Forwarding in Services > Network > Network routing.
- Edit the segmentation table to make sure that routing does not violate network segmentation settings in Services > Network > Network routing. By default, routing cannot traverse network interfaces.
- Configure backend web servers to use WAF as default gateway.
Proxy protocol
Alert Logic allows you to enable proxy protocol, which is designed to safely transport connection information without losing any information. Enabling proxy protocol allows WAF to work with multiple layers of NAT or TCP proxy protocols, does not require infrastructure changes, has no impact on NAT firewalls, and is scalable.
Enable proxy protocol
Check box |
Safely transport connection information without losing any information |
Enabling proxy protocol on the WAF is not necessary unless you are configuring both communicating endpoints. If you have configured the other communicating endpoint to proxy protocol, you can enable proxy protocol in the WAF.
You must configure proxy protocol on both endpoints of the connection. If one endpoint connection is not configured to use proxy protocol, the websites stop communicating, and WAF does not function properly.
Since the X-headers are part of the client request WAF receives, and the client can manipulate it, they cannot be trusted. The information that the proxy insert can only be trusted if the client does not control that information. This is if the proxy that receives the request from the client, for instance a load balancer in front of WAF, follows the standard of appending the source IP it receives the request from to the X-Forwarded-For header. In addition, it must overwrite values in X-Forwarded-Proto and X-Forwarded-Port headers with protocol and port information to be trusted. Such a proxies, defined by one or more IPs, are referred to as Trusted Proxies.
When WAF receives a request from a trusted proxy, IP based blocking extracts and uses the IP address of the client source IP from the X-Forwarded-For header in place of the actual request (socket) IP for both HTTP Throttling. For the IP based blocking controls, the X-Forwarded-For IP transparently replaces the socket IP and the network blocking controls works without other modification to the policy.
Use trusted proxy - extract client source IP from X-Forwarded-For header
Check box |
Enable Trusted Proxy functionality. When enabled, if a request is received from a proxy from the list of trusted proxies:
Default: |
Reset X-Forwarded-For header to last untrusted source in list
Check box |
Following the proposed standard, the X-Forwarded-For header may contain a comma separated list of IP addresses. Depending on the configuration options in the endpoint web server and application, it may be logged with a comma separated list, which you may not want. For WAF to always forward the X-Forwarded-For a single IP address, enable this option. Default: |
Forward X-Forwarded-For and X-Forwarded-Proto headers from trusted proxy unaltered
Check box |
Leave X-Headers untouched from trusted proxy. If WAF is deployed behind another reverse proxy, by default, WAF inserts the source IP from that proxy in the X-Forwarded-For header sent to the backend web server. If the X-Forwarded-For header is already present, the source IP is appended to the header. While this behavior conforms to standards, you may not always want it. You can configure trusted proxies to forwarded the X-Forwarded-For header as it is received from the trusted proxy without modifying it. Default: |
Trusted CIDR ranges
Input field |
List of Trusted CIDR ranges from which X-Forwarded-For header is forwarded unmodified to the backend web server.
|
The standard for forwarding client source IP from layer 7 proxies. Header is always inserted.
X-Forwarded-For |
The X-Forwarded header is always inserted. |
The X-Forwarded-For (XFF) HTTP header field is a standard to identify the originating IP address of a client connecting to a web server through an HTTP proxy or load balancer. This is an HTTP request header the developers of Squid caching proxy server introduced. An effort has been started at IETF for standardizing the Forwarded HTTP header.
When the request passes through multiple proxy servers, each server adds the respective source IP to the X-Forwarded-For header. The X-Forwarded-For header then contains a list of IP addresses the request has passed through. The leftmost IP address is the original client IP. The rightmost IP address is the last proxy in the chain, and the source IP of the request is the address of the last proxy.
This allows the endpoint web server to extract and log the original client IP address from the XFF header for applications that need this data. The endpoint web server no longer needs to extract data for the IP address of the last proxy in the chain from which the request received.
WAF is a proxy-based device that terminates requests from clients and makes requests to the backend web server on behalf of the client. To make the original source IP available to the backend web application, WAF forwards the source IP address to the backend server in the X- Forwarded-For header.
In addition to the X-Forwarded-For header Layer 7, proxies often insert X-headers with information about which protocol and port from the request they received. The following headers are:
- X-Forwarded-Proto: Contains the protocol the request was received on - HTTP or HTTPS
- X-Forwarded-Port: Contains the port the request was received on
Contrary to the X-Forwarded-For header, these headers are not lists. This means that WAF overwrites their information if it receives the request from a proxy that already inserted them.
If requests through WAF passes through further layer 7 proxies on their way to the backend servers, you must copy the value of those headers into reserved custom headers like X-WSM-Forwarded-Proto. WAF does this to keep the value of these headers as received intact. You can insert request heads to copy the value of those headers in Health Checking section in Load Balancing.
Redirects
Redirects tells the client to get the requested resource elsewhere. The Redirect feature instructs clients to make a new request with a different URL. It often redirects HTTP requests for resources requiring encryption to corresponding pages on an SSL encrypted connection - HTTPS.
When redirecting, WAF sends an HTTP 301 - Permanently Moved
response code.
Match types
WAF allows for either prefix
, regex
or vhost regex
based matching of client requests.
Prefix
If prefix match is selected, the requested URL is matched left to right beginning with a slash (/secret
).
Regex
If Regex match is selected, the requested URL is matched using a regular expression. You can match asp files in a specific directory and instruct the client to request a php file in another directory on another server using HTTPS instead of HTTP.
Do not select Regex match type unless you really need it. Prefix is cheaper CPU wise.
Vhost regex
The vhost regex type allows for matching on elements in the virtual host name. The vhost regex redirects to a different virtual host optionally with some of the matched elements in the target URL- like redirecting foo.alertlogic.com to http://www.alertlogic.com/foo or foo.alertlogic.net to http://www.alertlogic.com/net/foo.
The syntax is dependent on the match type selected.
Enable external redirects
Check box |
When selected, WAF redirects client requests based on redirect rules configured. |
Proto
Drop-down list |
For website proxies serving both HTTP and HTTPS, select the protocol to match. If for instance, you only want to serve a specific page using the HTTPS protocol match the corresponding HTTP page and redirect to HTTPS on the same site. |
Match type
Drop-down list |
See above. |
Match
Input field |
The client request to match. If prefix match is selected, the requested URL is matched left to right beginning with a slash (
|
Redirect externally to
Input field |
The new URL path to which the client is redirected. If prefix match is selected, the new URL path corresponds to the prefix matched. If /secret is entered in the match field (above) then the part of the request following the prefix (/secret) is sent to the new URL path.
|
Enable external redirects
Check box |
When select, WAF redirects client requests based on redirect rules configured. |
Proto
Drop-down list |
For website proxies serving both HTTP and HTTPS, select the protocol to match. If for instance you only want to serve a specific page using the HTTPS protocol match, the corresponding HTTP page redirects to HTTPS on the same site. |
Match type
Drop-down list |
See above. |
Match
Input field |
The client request to match. If Regex match is selected, the requested URL is matched using a regular expression. The supplied regular expression is matched against the requested URL-path. If it matches, the server substitutes any parenthesized matches into the redirect URL path sent in the redirect response to the client.
|
Redirect externally to
Input field |
The new URL path to which the client is redirected. If Regex match is selected, the parenthesized matches in $1, $2, etc. is substituted into the new URL path allowing fine grained and complex redirect rules.
|
Enable external redirects
Check box |
When selected, WAF redirects client requests based on redirect rules configured. |
Proto
Drop-down list |
For website proxies serving both HTTP and HTTPS, select the protocol to match. If for instance, you only want to serve a specific page using the HTTPS protocol, match the corresponding HTTP page and redirect to HTTPS on the same site. |
Match type
Drop-down list |
See above. |
Match
Input field |
The vhost part of client request to match. If vhost regex match is selected, the vhost part of the client request is matched using a regular expression. If it matches, the server substitutes any parenthesized matches into the redirect URL path sent in the redirect response to the client.
|
Redirect externally to
Input field |
The new URL path to which the client is redirected. If the match expression contains parentheses, the parenthesized matches are placed in the variables $c1, $c2, $c9. These variables are used in the redirected URL to allow for fine grained and flexible redirects.
|
The examples from the table above are summarized below. Substitute ssl.somename.tld
with the correct address.
- On an HTTP proxy, redirect all requests to the corresponding location on an HTTPS proxy
-
Match type: prefix
Match: /
Redirect externally to: https://ssl.somename.tld/
- On an HTTP proxy, redirect all requests for resources in
/secret
to/moresecret
on an HTTPS proxy -
Match type: prefix
Match:
/secret
Redirect externally to: https://ssl.somename.tld/moresecret
- On an HTTP proxy, redirect all requests for
.jsp
to a.php
script with the same name and location on an HTTPS proxy -
Match type: regex
Match:
(.+)\.jsp
Redirect externally to: https://ssl.somename.tld$1.php
- Virtual host redirect - redirect requests to somehost.somename.cc to www.somename.tld/cc/somehost/
-
Match type: vhost regex
Match:
(\w+)\.somename\.(\w){1,5}
Redirect externally to: http://www.somename.tld/$c2/$c1
Options
This option allows underscore characters to show up in request headers. |
Traffic statistics
Allows traffic statistics to be logged in the Traffic statistics section. |
Save settings |
Click to save settings. |