Virtual Host Security
Table of Contents
Enable reCAPTCHA | Site Key | Secret Key | reCAPTCHA Type | Max Tries | Concurrent Request Limit
Realm Name | User DB Location | User DB Max Cache Size | User DB Cache Timeout (secs) | Group DB Location | Group DB Max Cache Size | Group DB Cache Timeout (secs)
reCaptcha Protection⇑
Description
reCaptcha Protection is a service provided as a way to mitigate heavy server load. reCaptcha Protection will activate after one of the below situations is hit. Once active, all requests by NON TRUSTED(as configured) clients will be redirected to a reCAPTCHA validation page. After validation, the client will be redirected to their desired page.
The following situations will activate reCaptcha Protection:
1. The server or vhost concurrent requests count passes the configured connection limit.
2. Anti-DDoS is enabled and a client is hitting a url in a suspicious manner. The client will redirect to reCAPTCHA first instead of getting denied when triggered.
3. WP Brute Force protection is enabled and action is set to 'Captcha or Drop’. When a brute force attack is detected, the client will redirect to reCAPTCHA first. After max tries is reached, the connection will be dropped, as per the ‘drop’ option.
4. A new rewrite rule environment is provided to activate reCAPTCHA via RewriteRules. 'verifycaptcha' can be set to redirect clients to reCAPTCHA. A special value ': deny' can be set to deny the client if it failed too many times. For example, [E=verifycaptcha] will always redirect to reCAPTCHA until verified. [E=verifycaptcha: deny] will redirect to reCAPTCHA until Max Tries is hit, after which the client will be denied.
Enable reCAPTCHA⇑
Description
Enable the reCaptcha Protection feature at the current level. This setting must be set to Yes at the Server level before the reCaptcha Protection feature can be used.
Default values:
Server-level: Yes
VH-Level: Inherit Server level setting
Syntax
Select from radio box
Site Key⇑
Description
The site key is the public key provided by Google via its reCAPTCHA service. A default Site Key will be used if not set.
Secret Key⇑
Description
The secret key is the private key provided by Google via its reCAPTCHA service. A default Secret Key will be used if not set.
reCAPTCHA Type⇑
Description
Specify the reCAPTCHA type to use with the key pairs. If a key pair has not been provided and this setting is set to Not Set, a default key pair of type Invisible will be used.
Checkbox will display a checkbox reCAPTCHA for the visitor to validate.
Invisible will attempt to validate the reCAPTCHA automatically and if successful, will redirect to the desired page.
Default value is Invisible.
Syntax
Select from drop down list
Max Tries⇑
Description
Max Tries specifies the maximum number of reCAPTCHA attempts permitted before denying the visitor.
Default value is 3.
Syntax
Integer number
Concurrent Request Limit⇑
Description
The number of concurrent requests needed to activate reCAPTCHA. reCAPTCHA will be used until concurrent requests drop below this number.
Default value is 15000.
Syntax
Integer number
Access Control⇑
Description
Specifies what sub networks and/or IP addresses can access the server. At the server level, this setting will affect all virtual hosts. You can also set up access control unique to each virtual host at the virtual host level. Virtual host level settings will NOT override server level settings.
Blocking/Allowing an IP is determined by the combination of the allowed list and the denied list. If you want to block only certain IPs or sub-networks, put * or ALL in the Allowed List and list the blocked IPs or sub-networks in the Denied List. If you want to allow only certain IPs or sub-networks, put * or ALL in the Denied List and list the allowed IPs or sub-networks in the Allowed List. The setting of the smallest scope that fits for an IP will be used to determine access.
Server Level: Trusted IPs or sub-networks must be specified in the Allowed List by adding a trailing "T". Trusted IPs or sub-networks are not affected by connection/throttling limits. Only server level access control can set up trusted IPs/sub-networks.
Tips
Use this at the server level for general restrictions that apply to all virtual hosts.
Allowed List⇑
Description
Specifies the list of IPs or sub-networks allowed. * or ALL are accepted.
Syntax
Comma delimited list of IP addresses or sub-networks. A trailing "T" can be used to indicate a trusted IP or sub-network, such as 192.168.1.*T.
Example
IPv6 addresses: ::1 or [::1]
IPv6 subnets: 3ffe:302:11:2:20f:1fff:fe29:717c/64 or [3ffe:302:11:2:20f:1fff:fe29:717c]/64
Tips
Trusted IPs or sub-networks set at the server level access control will be excluded from connection/throttling limits.
Denied List⇑
Description
Specifies the list of IPs or sub-networks disallowed.
Syntax
Comma delimited list of IP addresses or sub-networks. * or ALL are accepted.
Example
IPv6 addresses: ::1 or [::1]
IPv6 subnets: 3ffe:302:11:2:20f:1fff:fe29:717c/64 or [3ffe:302:11:2:20f:1fff:fe29:717c]/64
Authorization Realms⇑
Description
Lists all authorization realms for this virtual host. Authorization realms are used to block unauthorized users from accessing protected web pages. A realm is a user directory containing usernames and passwords with optional group classifications. Authorization is performed at context level. Since different contexts can share the same realm (user database), so realms are defined separately from the contexts that use them. You can refer to a realm by these names in context configuration.
Realm Name⇑
Description
Specifies a unique name for the authorization realm.
User DB Location⇑
Description
Specifies the location of the user database. For DB type Password File, it is the path to the flat file containing user/password definitions. You can edit this file through the WebAdmin console by clicking on the filename.
Each line of the user file contains a username followed by a colon, followed by a crypt() encrypted password, optionally followed by a colon and group names that user belongs to. Group names are delimitated by commas. If group information is specified in the user database, then the group database will not be checked.
Example:
john:HZ.U8kgjnMOHo:admin,userFor DB type LDAP, it is the LDAP URL to query for the user information. For each valid user, the authentication data stored in the LDAP server should contain at least the user id and user password. One and only one record should be returned in the LDAP search request based on the this URL and username received in the HTTP Authentication header. "$k" must be specified in the filter part of the URL and it will be replaced with the username. The user password attribute must be returned in the query result. The attribute name of the user password is specified by Password Attribute. Group information can be optionally specified by the Member-of Attribute.
Example: At minimum, a user can be defined in LDAP with object classes: uidObject, simpleSecurityObject and organizationalRole. The following URL could be used:
ldap://localhost/ou=UserDB,dc=example,dc=com???(&(objectClass=*)(uid=$k))Syntax
Path to user DB file or LDAP URL (RFC 2255).
Tips
It is recommended to store user password files outside of the document tree. If a user password file has to be placed inside document tree, simply name it with a leading ".ht" like .htuser to prevent it being served as a static file. LiteSpeed Web Server does not serve files prefixed with ".ht".
See Also
User DB Max Cache Size⇑
Description
Specifies the maximum cache size of the user database. Recently accessed user authentication data will be cached in memory to provide maximum performance.
Syntax
Integer number
Tips
As a larger cache will consume more memory, a higher value may or may not provide better performance. Set it to an appropriate size according to your user database size and site usage.
User DB Cache Timeout (secs)⇑
Description
Specifies how often the backend user database will be checked for changes. Every entry in the cache has a timestamp. When cached data is older than the specified timeout, the backend database will be checked for changes. If there is no change, the timestamp will be reset to the current time, otherwise the new data will be loaded. Sevrer reload and graceful restart will clear the cache immediately.
Syntax
Integer number
Tips
If the backend database does not change very often, set a longer timeout for better performance.
Group DB Location⇑
Description
Specifies the location of the group database.
Group information can be set either in the user database or in this standalone group DB. For user authentication, the user DB will be checked first. If the user DB also contains group information, then the group DB will not be checked.
For the DB type Password File, the group DB location should be the path to the flat file containing group definitions. You can edit this file through the WebAdmin console by clicking on the filename.
Each line of a group file should contain a groupname followed by a colon, followed by space delimited group of usernames. Example:
testgroup: user1 user2 user3For the DB type LDAP, the group DB location should be the LDAP URL to query for group information. For each valid group, one and only one record should be returned in the LDAP search request based on this URL and the group name specified in Require (Authorized Users/Groups). "$k" must be specified in the filter part of the URL and it will be replaced with the group name. The name of the attribute that specifies members in this group is specified by the Group Member Attribute.
Example: If objectClass posixGroup is being used to store group information. The following URL could be used:
ldap://localhost/ou=GroupDB,dc=example,dc=com???(&(objectClass=*)(cn=$k))Syntax
Filename which can be an absolute path or a relative path to $SERVER_ROOT, $VH_ROOT.
Tips
It is recommended to store a group file outside the document tree. If it has to be placed inside document tree, simply name it with a leading ".ht" like .htgroup, to prevent the file being served as a static file. LiteSpeed Web Server does not serve files prefixed with ".ht".
See Also
User DB Location, Context Require (Authorized Users/Groups), Group Member Attribute
Group DB Max Cache Size⇑
Description
Specifies the maximum cache size of the group database.
Syntax
Integer number
Tips
As a larger cache will consume more memory, a higher value may or may not provide better performance. Set it to an appropriate size according to your user database size and site usage.
See Also
Group DB Cache Timeout (secs)⇑
Description
Specifies how often the backend group database will be checked for changes. For more detail please refer to User DB Cache Timeout (secs).
Syntax
Integer number