<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-5HLVVHN" height="0" width="0" style="display:none;visibility:hidden">

WebShield introduction for server administrators

WebShield-introduction-for-server-administrators

WebShield is a component of the Imunify360 security solution. Its primary purpose is to handle HTTP traffic and prevent HTTP attacks.

As a security solution, WebShield is meant to:

  • Block blacklisted traffic
  • Redirect graylisted traffic to CAPTCHA until the CAPTCHA is passed
  • Act as a proxy service, redirecting remaining traffic to backends

It consists of four services:

  • WebShield itself
  • Shared memory daemon
  • SSL-caching daemon
  • Sentrylogs daemon
    Shared memory is the component of WebShield that makes it easier to deal with certain aspects of Nginx configuration without reloading. It does this by modifying its shared memory.

SSL-caching daemon watches changes to host SSL certificate sets (for known hosting panels only: cPanel, Plesk, DirectAdmin) and updates the WebShield SSL cache when a certificate is added, updated or removed.

Sentrylogs daemon watches WebShield log files to detect errors.

The configuration of WebShield is done by an agent, and direct editing of WebShield configuration files is generally not recommended. This is mainly because after the next reconfiguration all custom changes would be lost. However, there are some items a host administrator may want to set.

Set default SSL certificate explicitly

 

As stated earlier, WebShield maintains its own SSL certificate cache (independent of any panels and web-servers). When a proper SSL request arrives, WebShield gets a destination domain from the request and returns the corresponding certificate from its cache. But what if a request came without Server Name Indication (SNI) set? WebShield does not know which certificate to use. In such situations, web servers usually return the first certificate from the ones they have, and WebShield is no exception here. It would return the first certificate from its cache. If the cache is empty (host has no certificates or because of an error), WebShield will return its default SELF-SIGNED certificate. This is generally not what a host admin wants. Thus, the host administrator is allowed to set a certificate as the default one for WebShield to return.

  1. Place a certificate and a key into the /etc/imunify360-webshield/ssl_certs folder;
  2. If required, in the /etc/imunify360-webshield/ssl.conf file, change the following directives according to your changes:
 

ssl_certificate             ssl_certs/dummy.pem;

ssl_certificate_key         ssl_certs/dummy.pem;

If you want to provide intermediate certificates, they are to be appended to the certificate file.

Additionally, the administrator is allowed to disable searching for the first certificate in the cache before returning the default one for non-SNI (or for non-existent domains) requests. To disable searching, in the /etc/imunify360-webshield/ssl.conf file set lua_enable_ws_sslcache_search directive to 'off'.

These settings require WebShield to be restarted/reloaded.

Manage WebShield SSL cache manually

Due to different reasons, the host administrator may want to add a certificate to WebShield manually (for example, in a no-panel environment, when SSL-caching daemon fails to update the certificate cache, or there are certificates installed in custom places). To manually manage the certificate cache, use the /usr/sbin/im360-ssl-cache utility.

To add certificates to the cache, a user would run the command:

im360-ssl-cache --add /path/to/certs.json

The --add parameter accepts zero or one parameter. If a parameter is given, it is taken as a path to a file in JSON format with a list of certificates and private keys to be added. Otherwise, data is expected to be sent in JSON format to STDIN as in the following example:

cat certs.json | im360-ssl-cache --add

Format of JSON file:

[
{
“key”: “-----BEGIN PRIVATE KEY-----\nM...O\n-----END PRIVATE KEY-----\n”,
“certificate”: “-----BEGIN CERTIFICATE-----\nMI...Y=\n-----END CERTIFICATE-----\n”,
“chain”: “-----BEGIN CERTIFICATE-----\nM...I=\n-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----\nM...U=\n-----END CERTIFICATE-----\n”
},
{
“key”: “...”,
“certificate”: “...”,
“chain”: “...”
}
]

As JSON text is not allowed to have line breaks, all newline symbols must be escaped as in the example above.

To remove certificate(s) from the cache, a user is expected to run the command:

im360-ssl-cache --remove example.org example.com …

The --remove parameter expects one or more space-separated domain names, for which certificates are to be removed from the cache.

When no parameters are passed, the im360-ssl-cache simply lists all domain names of certificates in the cache.

NOTE: Passing certificates data in JSON format is done to put data flow in good order, to avoid excessive checks of data. No certificate checks are made.

Read more about WebShield in the documentation.

WebShield introduction for server administrators

WebShield-introduction-for-server-administrators

WebShield is a component of the Imunify360 security solution. Its primary purpose is to handle HTTP traffic and prevent HTTP attacks.

As a security solution, WebShield is meant to:

  • Block blacklisted traffic
  • Redirect graylisted traffic to CAPTCHA until the CAPTCHA is passed
  • Act as a proxy service, redirecting remaining traffic to backends

It consists of four services:

  • WebShield itself
  • Shared memory daemon
  • SSL-caching daemon
  • Sentrylogs daemon
    Shared memory is the component of WebShield that makes it easier to deal with certain aspects of Nginx configuration without reloading. It does this by modifying its shared memory.

SSL-caching daemon watches changes to host SSL certificate sets (for known hosting panels only: cPanel, Plesk, DirectAdmin) and updates the WebShield SSL cache when a certificate is added, updated or removed.

Sentrylogs daemon watches WebShield log files to detect errors.

The configuration of WebShield is done by an agent, and direct editing of WebShield configuration files is generally not recommended. This is mainly because after the next reconfiguration all custom changes would be lost. However, there are some items a host administrator may want to set.

Set default SSL certificate explicitly

 

As stated earlier, WebShield maintains its own SSL certificate cache (independent of any panels and web-servers). When a proper SSL request arrives, WebShield gets a destination domain from the request and returns the corresponding certificate from its cache. But what if a request came without Server Name Indication (SNI) set? WebShield does not know which certificate to use. In such situations, web servers usually return the first certificate from the ones they have, and WebShield is no exception here. It would return the first certificate from its cache. If the cache is empty (host has no certificates or because of an error), WebShield will return its default SELF-SIGNED certificate. This is generally not what a host admin wants. Thus, the host administrator is allowed to set a certificate as the default one for WebShield to return.

  1. Place a certificate and a key into the /etc/imunify360-webshield/ssl_certs folder;
  2. If required, in the /etc/imunify360-webshield/ssl.conf file, change the following directives according to your changes:
 

ssl_certificate             ssl_certs/dummy.pem;

ssl_certificate_key         ssl_certs/dummy.pem;

If you want to provide intermediate certificates, they are to be appended to the certificate file.

Additionally, the administrator is allowed to disable searching for the first certificate in the cache before returning the default one for non-SNI (or for non-existent domains) requests. To disable searching, in the /etc/imunify360-webshield/ssl.conf file set lua_enable_ws_sslcache_search directive to 'off'.

These settings require WebShield to be restarted/reloaded.

Manage WebShield SSL cache manually

Due to different reasons, the host administrator may want to add a certificate to WebShield manually (for example, in a no-panel environment, when SSL-caching daemon fails to update the certificate cache, or there are certificates installed in custom places). To manually manage the certificate cache, use the /usr/sbin/im360-ssl-cache utility.

To add certificates to the cache, a user would run the command:

im360-ssl-cache --add /path/to/certs.json

The --add parameter accepts zero or one parameter. If a parameter is given, it is taken as a path to a file in JSON format with a list of certificates and private keys to be added. Otherwise, data is expected to be sent in JSON format to STDIN as in the following example:

cat certs.json | im360-ssl-cache --add

Format of JSON file:

[
{
“key”: “-----BEGIN PRIVATE KEY-----\nM...O\n-----END PRIVATE KEY-----\n”,
“certificate”: “-----BEGIN CERTIFICATE-----\nMI...Y=\n-----END CERTIFICATE-----\n”,
“chain”: “-----BEGIN CERTIFICATE-----\nM...I=\n-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----\nM...U=\n-----END CERTIFICATE-----\n”
},
{
“key”: “...”,
“certificate”: “...”,
“chain”: “...”
}
]

As JSON text is not allowed to have line breaks, all newline symbols must be escaped as in the example above.

To remove certificate(s) from the cache, a user is expected to run the command:

im360-ssl-cache --remove example.org example.com …

The --remove parameter expects one or more space-separated domain names, for which certificates are to be removed from the cache.

When no parameters are passed, the im360-ssl-cache simply lists all domain names of certificates in the cache.

NOTE: Passing certificates data in JSON format is done to put data flow in good order, to avoid excessive checks of data. No certificate checks are made.

Read more about WebShield in the documentation.
Subscribe to Imunify security Newsletter