mod_qos

In computer networking, the term quality of service (QoS) describes resource management rather than the quality of a service. Quality of service implements control mechanisms to provide different priority to different users, applications, and data connections. It is used to guarantee a certain level of performance to data resources. The term quality of service is often used in the field of wide area network protocols (e.g. ATM) and telephony (e.g. VoIP), but rarely in conjunction with web applications. mod_qos is a quality of service module for the Apache web server implementing control mechanisms that can provide different levels of priority to different HTTP requests.

But why do you need quality of service for a web application? Well, web servers require threads and processes to serve HTTP requests. Each TCP connection to the web server occupies one of these threads respectively processes. Sometimes a server gets too busy to serve every request due to the lack of free processes or threads. Another parameter requiring control by mod_qos is the available bandwidth: all clients communicate to the server over a network link with limited bandwidth. Overfilling the link results in network congestion and poor performance.

Example situations where web applications require QoS:

• More resources are consumed if request processing by an application takes a long time, e.g. when request processing includes time consuming database queries.
• Oversubscription of link capabilities due to many concurrent clients uploading or downloading data.
• Penetration of the web server by attackers (DoS).

mod_qos may be used to determine which requests should be served and which shouldn't in order to avoid resource oversubscription. The module collects different attributes such as the request URL, HTTP request and response headers, the IP source address, country codes, the HTTP response code, history data (based on user session and source IP address), the number of concurrent requests to the server (total or requests having similar attributes), the number of concurrent TCP connections (total or from a single source IP), and so forth.

The rules you want to configure are defined by the module's directives. Every rule reads attributes from different sources and using its own counters to store their status.

Counteractive measures to enforce the defined rules are: request blocking, dynamic timeout adjustment, request delay, response throttling, and dropping of TCP connections.

The current release of the mod_qos module implements various control mechanisms:

• The maximum number of concurrent requests to a location/resource (URL) or virtual host.
• Limitation of the bandwidth such as the maximum allowed number of requests per second to an URL or the maximum/minimum of downloaded kbytes per second.
• Limits the number of request events per second (special request conditions).
• Limits the number of request events within a defined period of time.
• It can also detect very important persons (VIP) which may access the web server without or with fewer restrictions.
• Generic request line and header filter to deny unauthorized operations.
• Request body data limitation and filtering (requires mod_parp ).
• Limits the number of request events for individual clients (IP).
• Limitations on the TCP connection level, e.g., the maximum number of allowed connections from a single IP source address or dynamic keep-alive control.
• Prefers known IP addresses when server runs out of free TCP connections.
• Serialization of requests.

mod_qos is an open source software licensed under the Apache License. You can download the latest release at SourceForge.net.

More information about mod_qos:

• Build
• Configuration
• Request Level Control
• Status Code and Error Page
• Privileged Users
• Variables
• Conditional Rules
• Events
• Request Level, Generic Filter
• Connection Level Control
• Client Level Control
• Log Messages
• Error Log
• Access Log
• Request Statistics
• Status Viewer
• Web Console
• Utilities
• Sample Use Cases

Build

mod_qos requires OpenSSL, PCRE, threading and shared memory support. mod_qos is designed to be used with Apache's MPM worker binaries but works, with some restrictions, also with other Apache 2.4 multi-processing modules. The module is optimized to be used in a reverse proxy server.

Notes:
  You should choose the worker MPM if you intend to use any connection level control directive.
  If you decide to use HTTP/2 , you should only use the request level control directives as mod_qos works for the hypertext transfer protocol version 1.0 and 1.1 (RFC1945/RFC2616) only.

You can compile the module using apxs . Your httpd binary must support dynamically loaded objects (DSO). Verify this by checking the availability of mod_so: The command httpd -l must list the mod_so.c module. The following command compiles the module and installs mod_qos into the server's modules directory.

cd mod_qos-11.75/apache2 apxs -i -c mod_qos.c -lcrypto -lpcre2-8 cd ../..

If the necessary header files of OpenSSL, PCRE, etc. cannot be found, add the -I option to the apxs command to specify the directory where header files can be found and if any of the required libraries cannot be found (may happen if you use mod_qos without mod_ssl), add the -L option to specify the directory where libraries can be found.
Note: you may customize the code using the following preprocessor directives:

	Name	Description	Default
	QS_MOD_EXT_HOOKS	Enables the optional hooks defined in mod_qos.h	not set
	QSLOG_CLID	Defines the environment variable which shall be used for the "user tracking id" (U) within the format string used by the QSLog directive.	mod_qos_user_id
	QSLOG_EVENT	Defines the environment variable which shall be used for the "event" (Q) within the format string used by the QSLog directive.	Event
	QSLOG_AVERAGE	Defines the environment variable which shall be used for the "average" (a) within the format string used by the QSLog directive.	QS_AllConn
	QS_LOG_REPEAT	Counter used to define how many repetitive messages are summarized.	20
	QS_REQ_RATE_TM	Default for the QS_SrvSampleRate directive.	5
	QS_EXTRA_MATCH_LIMIT	Match limit field used for PCRE data processing.	1500

The support tools may be built (at least on some Linux platforms) using the GNU autotools. Some of these utilities require third-party libraries such as apr, apr-util, PCRE2, libpng, and OpenSSL.

cd mod_qos-11.75/tools ./configure make

Configuration

Configuration is mostly done on a per-server basis (except the generic request filter and a few other directives). Directives within a virtual host are merged with the settings in the global configuration.

The QS_SrvMinDataRate, QS_SrvRequestRate, QS_RequestHeaderFilterRule, QS_ResponseHeaderFilterRule, and all QS_Client* directives may be used outside of virtual host configurations only.

The QS_LogOnly on directive may be used to put mod_qos into a permissive mode where rule violations are logged only but requests/connections are not blocked. This may be used for test purposes.
Should not be activated if you are using any throughput control directive (open loop).

Request Level Control

• QS_LocRequestLimitMatch <regex> <number>
  Defines the number of concurrent requests for the specified request pattern (path and query). The rule with the lowest number of allowed concurrent connections has the highest priority if multiple expressions match the request. By default, no limitations are active.
• QS_LocRequestPerSecLimitMatch <regex> <number>
  Defines the allowed number of requests per second to the URL (path and query) pattern. Requests are limited by adding a delay to each request (linear). The delay calculation is based on an average request rate measurement using a sampling rate of 10 seconds. By default, no limitation is active. This directive should be used in conjunction with QS_LocRequestLimitMatch only (you must use the very same regex pattern with the QS_LocRequestPerSecLimitMatch and QS_LocRequestLimitMatch directive) to avoid too many concurrent requests.
• QS_LocKBytesPerSecLimitMatch <regex> <number>
  Defines the allowed download bandwidth to the location matching the defined URL (path and query) pattern. Responses are slowed down by adding a delay to each response (every 8kbytes). Bandwidth calculation is based on measuring the transferred data. By default, no limitation is active. This directive should be used in conjunction with QS_LocRequestLimitMatch only (you must use the very same regex pattern with the QS_LocKBytesPerSecLimitMatch and QS_LocRequestLimitMatch directive) to avoid too many concurrent requests.
• QS_LocRequestLimit <location> <number>
  Defines the number of concurrent requests for the specified location (applied to the parsed path). By default, no limitations are active for locations. Has lower priority than QS_LocRequestLimitMatch directives.
• QS_LocRequestLimitDefault <number>
  Defines the default limitation for the maximum of concurrent requests per-location for those locations not defined by any QS_LocRequestLimit directive. It could also be used to limit the number of concurrent requests to a virtual host.
• QS_LocRequestPerSecLimit <location> <number>
  Defines the allowed number of requests per second to a location, similar to the QS_LocRequestPerSecLimitMatch directive. The maximum number of requests is limited by adding a delay to each request (linear, each request gets the same delay). By default, no limitation is active. This directive should be used in conjunction with QS_LocRequestLimit only (you must use the same location for both directives) to avoid too many concurrent requests.. Has lower priority than QS_LocRequestPerSecLimitMatch.
• QS_LocKBytesPerSecLimit <location> <number>
  Throttles the download bandwidth to the defined kbytes per second. Works similar as the QS_LocKBytesPerSecLimitMatch directive slowing down HTTP responses by adding a delay to each response. By default, no limitation is active. This directive should be used in conjunction with QS_LocRequestLimit only (you must use the same location for both directives) to avoid too many concurrent requests.. Has lower priority than QS_LocKBytesPerSecLimitMatch.

# maximum number of active TCP connections is limited to 512
MaxClients                    512

# limits concurrent requests to the locations:
# - /app/a  max. 200 concurrent requests
# - /app/b and /app/c (together) max. 300 concurrent requests
# - /images max. 100 concurrent requests
QS_LocRequestLimit            /app/a                   200
QS_LocRequestLimitMatch       ^(/app/b/|/app/c/).*$    300
QS_LocRequestLimit            /images                  100
# limits download bandwidth to 5Mbit/sec (resp. 640kbytes/sec)
# for downloads from /app/a:
QS_LocKBytesPerSecLimit       /app/a                   640

Status Code and Error Page

• QS_ErrorPage <URL>
  Defines an error page to be returned when a request is denied. The defined URL must be a (S)HTML document accessible by the client. You may enable server-side includes (SSI) in order to present detailed error messages based on the error codes provided by mod_qos.
  Alternatively, a HTTP redirect (302) to a dedicated error page may be defined using an absolute URL defining schema, hostname, and path.
• QS_ErrorResponseCode <code>
  Defines the HTTP response code which is used when a request is denied. Requests denied at connection level usually get a HTTP 500 response code (ignoring the settings of the QS_ErrorResponseCode and QS_ErrorPage directives).
  Default (no custom error code or page defined) codes are:
   400: if a request has no valid URL.
   403: for requests denied by a QS_Deny*, QS_Permit* or QS_RequestHeaderFilter directive.
   413: when limiting the max. body data length by the QS_LimitRequestBody directive.
   500: for requests denied by any other directive.
  

Privileged Users

• Session: VIP identification is stored using a HTTP session cookie. mod_qos starts a new session when detecting a HTTP response header (the header name is defined by the QS_VipHeaderName directive). Alternatively, a new session is started when detecting an authenticated user, see QS_VipUser. The QS_Session* directives are used to set session attributes.
• Request: The QS_VipRequest process environment may be evaluated by mod_qos rules. This variable is set automatically when receiving a valid mod_qos session cookie. The QS_VipRequest variable may also be set by configuration using a QS_SetEnvIf* or SetEnvIf directive. VIP status lasts for the particular request only.
• Client IP address: VIP identification may be stored at the server side on a per-client IP address basis. The QS_VipIPHeaderName, QS_VipHeaderName, QS_VipIPUser, and QS_VipUser directives are used to define when an IP address should be marked as a VIP user.

• QS_VipHeaderName <header name>[=<regex>] [drop]
  Defines an HTTP response header which marks a user as a VIP. mod_qos creates a session for this user by setting a cookie, e.g., after successful user authentication. Tests optionally its value against the provided regular expression. Specify the action 'drop' if you want mod_qos to remove this control header from the HTTP response.
• QS_VipIPHeaderName <header name>[=<regex>] [drop]
  Defines an HTTP response header which marks a client source IP address as a VIP. Tests optionally its value against the provided regular expression. Specify the action 'drop' if you want mod_qos to remove this control header from the HTTP response.
• QS_VipUser
  Creates a VIP session for users which have been authenticated by the Apache server, e.g., by the standard mod_auth* modules. It works similar to the QS_VipHeaderName directive.
• QS_VipIPUser
  Marks a source IP address as a VIP if the user has been authenticated by the Apache server, e.g. by the standard mod_auth* modules. It works similar to the QS_VipIPHeaderName directive.
• QS_SessionTimeout <seconds>
  Defines the session life time for a VIP. It is only used for session based (cookie) VIP identification (not for IP based). Default is 3600 seconds.
• QS_SessionCookieName <name>
  A cookie is used to identify requests coming from a user which has been identified as a VIP. This directive defines a custom cookie name for the mod_qos session cookie. Default is MODQOS.
• QS_SessionCookiePath <path>
  Defines the cookie path. Default is "/".
• QS_SessionKey <string>
  Secret key used for cookie encryption. This key must be defined when using the same session cookie for multiple web servers (load balancing) or the sessions should survive a server restart. By default, a random key is used which changes every server restart.

QS_ErrorPage                  /error-docs/qs_error.html

# restricts max concurrent requests for any location which has no
# individual rule:
QS_LocRequestLimitDefault                              200

# limits access to *.gif files to 100 concurrent requests:
QS_LocRequestLimitMatch       "^.*\.gif$"              100

# limits concurrent requests to the locations /images and /app/a:
QS_LocRequestLimit            /images                  100
QS_LocRequestLimit            /app/a                   300
# limits download bandwidth to 5Mbit/sec:
QS_LocKBytesPerSecLimit       /app/a                   640

# two locations (/app/b and /app/c) representing a single application:
QS_LocRequestLimitMatch       "^(/app/b/|/app/c/).*$"  300


# allows the application to nominate VIP users by sending a
# "mod-qos-vip" HTTP response header:
QS_VipHeaderName              mod-qos-vip
QS_SessionKey                 na&5san-sB.F4_0a=%VBEBahXT1

Variables

mod_setenvif

mod_setenvifplus

• QS_ErrorPage=<URL>
  Defines the error page overriding the setting made by the QS_ErrorPage directive.
• QS_VipRequest=yes
  Disables some restrictions for this request (see privileged Users). Requires the definition of a VIP header using the QS_VipHeaderName directive (this activates VIP verification). However, such an event does not create a VIP session. The user has the VIP status only for a single request.
  The variable is set by mod_qos when receiving a valid VIP session cookie.
• QS_KeepAliveTimeout=<seconds>
  Applies dynamic connection keep-alive settings overriding the Apache KeepAliveTimeout directive settings.
• QS_MaxKeepAliveRequests=<number>
  Applies dynamic connection keep-alive settings overriding the Apache MaxKeepAliveRequests directive settings.
• QS_Timeout=<seconds>
  Alters the I/O timeout (while reading the request body / writing the response) of the current request overriding the Apache TimeOut directive settings.
• QS_Set_DSCP=<value>
  Variable used to set the IP differentiated services code points (DiffServ / RFC 2474). This allows you to classify the network traffic when sending the response data to the client. "value" represents the 6-bit DSCP field as a decimal number (0 to 63).
  Commonly used values:

  DSCP	Class		DSCP	Class
  0	none		8	Class selector 1
  10	Assured forwarding 11		12	Assured forwarding 12
  14	Assured forwarding 13		16	Class selector 2
  18	Assured forwarding 21		20	Assured forwarding 22
  22	Assured forwarding 23		24	Class selector 3
  26	Assured forwarding 31		28	Assured forwarding 32
  30	Assured forwarding 33		32	Class selector 4
  34	Assured forwarding 41		36	Assured forwarding 42
  38	Assured forwarding 43		40	Class selector 5
  44	Voice admit		46	Expedited forwarding
  48	Class selector 6		56	Class selector 7

• QS_Delay=<milliseconds>
  Defines a number of milliseconds to delay the request processing.
• QS_Event
  The variable processed by the QS_ClientEventPerSecLimit directive.
• QS_Block[=<number>]
  Variable processed by the QS_ClientEventBlockCount directive.
  The optional number value defines the penalty points to increase the counter (default is 1).
• QS_Limit[=<number>]
  (Default) variable processed by the QS_ClientEventLimitCount directive.
  The optional number value defines the penalty points to increase the counter (default is 1).
• *_Clear
  The counter of the variable processed by the QS_ClientEventLimitCount directive is reset if you set the same variable suffixed by _Clear, e.g. QS_Limit_Clear.
• *_Decrement
  The counter of the variable processed by the QS_EventLimitCount, QS_CondEventLimitCount, QS_ClientEventLimitCount, QS_CondClientEventLimitCount, and QS_ClientEventBlockCount directives is decremented by the value set in the same variable suffixed by _Decrement, e.g. QS_Limit_Decrement=1 decrements the value of the QS_Limit variable of the corresponding QS_ClientEventLimitCount rule by 1. The variable is evaluated at the end of the request processing.
• QS_Serialize
  Variable processed by the QS_ClientSerialize directive.
• QS_SrvSerialize
  Variable processed by the QS_SrvSerialize directive.
• QS_Cond
  Variable processed by the QS_CondLocRequestLimitMatch, QS_CondEventLimitCount, and QS_CondClientEventLimitCount directives.
• QS_EventRequest
  Variable processed by the QS_ClientEventRequestLimit directive.

• QS_SrvConn
  Number of concurrent connections for this server/virtual host. Value is set when using either the QS_SrvMaxConn, QS_SrvMinDataRate, QS_SrvMaxConnClose, or QS_ClientGeoCountryDB directive.
  Note: value is calulcated when the client establishes the connection and remains the same for all HTTP requests performed on this connection.
• QS_AllConn
  Number of all concurrent connections for this Apache instance. Value is set when using either the QS_SrvMaxConn, QS_SrvMinDataRate, QS_SrvMaxConnClose, or QS_ClientGeoCountryDB directive.
  Note: value is calulcated when the client establishes the connection and remains the same for all HTTP requests performed on this connection.
• QS_IPConn
  Number of IP connections open from the current IP address. Variable is available when using the QS_SrvMaxConnPerIP directive.
  Note: value is calulcated when the client establishes the connection and remains the same for all HTTP requests performed on this connection.
• QS_ClientLowPrio
  The variable is set for connections by clients which have been marked to be processed with low priority, see QS_ClientPrefer. The variable's value is determined when the client opens a new connection and its value represents the status flag of the tracked client attributes (hexadecimal). VIP status is ignored and the variable is always set even the IP has been marked as being VIP.
• QS_IsVipRequest
  Variable is set when detecting a VIP request (either by cookie, IP address status, valid user, etc.). May be used by various event based directives.
• *_Counter
  The counter values of the variables used by the QS_ClientEventLimitCount and QS_EventLimitCount directive are stored within the variable whose name is suffixed by _Counter, e.g. QS_Limit_Counter when limiting QS_Limit events.
• QS_ErrorNotes
  The error code (number only) of a mod_qos log message that has occurred during a request.
• QS_Country
  ISO 3166 country code of client IPv4 address. Only available if the geographical database file has been loaded.
  

# privileged access for curl clients:
BrowserMatch             "curl"                   QS_VipRequest=yes

# allows privileged access to a single resource:
SetEnvIf     Request_URI /app/start.html          QS_VipRequest=yes

# allows privileged access from a specified source address
# or source address range:
SetEnvIf     Remote_Addr 172.18.3.32              QS_VipRequest=yes
SetEnvIf     Remote_Addr 192.168.10.              QS_VipRequest=yes

# set keep-alive timeout for MSIE version 5.x browser to 65 seconds:
BrowserMatch             "(MSIE 5\.)"             QS_KeepAliveTimeout=65

# dynamic error page URL (per host error page):
SetEnvIf     Host        ^([a-zA-Z0-9_\.\-]+)     QS_ErrorPage=/error-docs/$1.html
# external redirect to a sever hosting the error page:
SetEnvIf     Request_URI /app                     QS_ErrorPage=http://your.server.name/error.html

Conditional Rules

• QS_CondLocRequestLimitMatch <regex> <number> <condition>
  Rule works similar to QS_LocRequestLimitMatch but it is only enforced for requests whose QS_Cond variable matches the specified condition (regular expression). Every request matching the defined pattern is counted, but the defined limitation is only enforced for those requests matching the specified condition.
  Only one QS_CondLocRequestLimitMatch rule is evaluated per request.
• QS_CondEventLimitCount <env-variable> <number> <seconds> <pattern>
  Same as QS_EventLimitCount but requests are only blocked if the value of the QS_Cond variable matches the defined pattern (regex).
• QS_CondClientEventLimitCount <number> <seconds> <variable> <pattern>
  Defines the maximum number of the specified environment variable allowed within the defined time. Directive works similar as QS_ClientEventLimitCount but requests are only blocked if the value of the QS_Cond variable matches the defined pattern (regex). Directive is allowed in global server context only.
  

# set the conditional variable to spider if detecting a
# "slurp" or "googlebot" search engine:
BrowserMatch             "slurp"                  QS_Cond=spider
BrowserMatch             "googlebot"              QS_Cond=spider

# limits the number of concurrent requests to two applications
# (/app/b and /app/c) to 300 but does not allow access by a "spider"
# if the number of concurrent requests exceeds the limit of 10:
QS_LocRequestLimitMatch       "^(/app/b/|/app/c/).*$"  300
QS_CondLocRequestLimitMatch   "^(/app/b/|/app/c/).*$"  10   spider

Events

mod_setenvif

mod_setenvifplus

• QS_EventRequestLimit <env-variable>[=<regex>] <number>
  Defines the number of concurrent events. Directive works similar to QS_LocRequestLimit, but counts the requests having the same environment variable (and optionally matching its value, too) rather than those that have the same URL pattern.
  Note: The counter's value is stored in the environment variable QS_EventRequestLimit_<env-variable>_Counter.
• QS_EventPerSecLimit [!]<env-variable> <number>
  Defines how often requests may have the defined environment variable (literal string) set. It measures the occurrences of the defined environment variable on a request per seconds level and tries to limit this occurrence to the defined number. It works similar as QS_LocRequestPerSecLimit, but counts only the requests with the specified variable (or without it if the variable name is prefixed by a "!"). If a request matches multiple events, the rule with the lowest bandwidth is applied. Events are limited by adding a delay to each request causing an event.
• QS_EventKBytesPerSecLimit [!]<env-variable> <number>
  Throttles the download bandwidth of all requests having the defined variable set to the defined kbytes per second. Responses are slowed by adding a delay to each response (every 8kbytes). The delay calculation is based on an average request rate measurement. By default, no limitation is active. This directive should be used in conjunction with QS_EventRequestLimit only (you must use the same variable name for both directives) to avoid too many concurrent requests.
• QS_EventLimitCount <env-variable> <number> <seconds>
  Defines the maximum number of events allowed within the defined time. Requests causing the event are denied when reaching this limitation for the specified time (blocked at request level).
  Notes:
  • The current counter value is propagated to the process environment within the variable <env-variable>_Counter.
  • See also QS_CondEventLimitCount if you want to enforce a rule under certain conditions only.
  • The event counter can be decremented by setting the environment <env-variable>_Decrement.

mod_setenvif

mod_setenvifplus

• QS_SetEnvIf [!]<env-variable1> [!]<env-variable2> [!]<env-variable=value>
  Sets (or unsets) the environment "variable=value" (literal string) if variable1 (literal string) AND variable2 (literal string) are set in the request environment variable list (not case sensitive). This is used to combine multiple variables to a new event type.
  This directive may be used on a per-server or location basis.
• QS_SetEnvIf <env-variable1>=<regex> [!]<env-variable>=<value>
  Sets the environment variable if the environment variable1's value matches the defined regular expression. $1..$9 within the value and are replaced by parenthesized subexpressions of the regular expression.
  This directive may be used on a per-server or location basis.
• QS_SetEnv <env-variable> <value>
  Sets the defined variable with the value where the value string may contain other environment variables surrounded by "${" and "}". The variable is only set if all defined variables within the value have been resolved.
• QS_SetEnvIfQuery <regex> [!]<env-variable>[=<value>]
  Directive works quite similar to the SetEnvIf directive of the Apache module mod_setenvif , but the specified regex is applied against the query string portion of the request line. The directive recognizes the occurrences of $1..$9 within value and replaces them by the sub-expressions of the defined regex pattern.
  This directive may be used on a per-server or location basis.
• QS_SetEnvIfCmp <env-variable1> eq|ne|gt|lt <env-variable2> [!]<env-variable>[=<value>]
  Sets the defined environment variable if the specified env-variables[1|2] are numerical or alphabetically (case insensitive) equal (eq), not equal (ne) greater (gt), or less (lt).
  This directive may be used on a per-location basis only.
• QS_SetEnvIfParp <regex> [!]<env-variable>[=<value>]
  Directive parsing the request payload using the Apache module mod_parp . It matches the request URL query and the HTTP request message body data as well (application/x-www-form-urlencoded, multipart/form-data, and multipart/mixed) and sets the defined process variable (quite similar to the QS_SetEnvIfQuery directive). The directive recognizes the occurrences of $1..$9 within value and replaces them by the sub-expressions of the defined regex pattern. This directive activates mod_parp for every request to the virtual host. You may deactivate mod_parp for selected requests using the SetEnvIf or SetEnvIfPlus directive: unset the variable "parp" to do so. Important: request message body processing requires that the server loads the whole request into its memory (at least twice the length of the message). You should limit the allowed size of the HTTP request message body using the QS_LimitRequestBody directive when using QS_SetEnvIfParp!
• QS_SetEnvIfBody <regex> [!]<env-variable>[=<value>]
  Directive parsing the request body using the Apache module mod_parp . Specify the content types to process using the mod_parp directive PARP_BodyData and ensure that mod_parp is enabled using the SetEnvIf or SetEnvIfPlus directive. You should limit the allowed size of HTTP requests message body using the QS_LimitRequestBody directive when using mod_parp. The directive recognizes the occurrence of $1 within the variable value and replaces it by the sub-expressions of the defined regex pattern. The regular expressions is case insensitive.
• QS_SetEnvIfStatus <code> <env-variable>[=<value>]
  Sets the defined variable in the request environment if the HTTP response status code matches the defined code. Default value is the status code, but you might override this by any other value. Directive may be used on a per-server or per-location basis.
  A possible use case for this directive is the prevention of repetitive occurrence of unwanted response status codes in conjunction with the QS_ClientEventBlockCount or QS_ClientEventLimitCount directive.
  When using the special variable QS_Block, its value is set to "1" by default. There are also four "special codes" available to set the QS_Block event:
  • QS_SrvMinDataRate may be used to set QS_Block events in order to limit the allowed number of QS_SrvMinDataRate rule violations.
  • QS_SrvMaxConnPerIP may be used to increment the QS_Block event when closing connections due to the reach of the limitation configured by the QS_SrvMaxConnPerIP directive.
  • NullConnection detects connections which are closed even no HTTP request has been received.
    Note: The NullConnection event may happen silently (no log message) expect when using LogLevel "debug". The parameter may be used to defend against SSL DoS attacks. Please pay attention to the fact that unused speculative TCP pre-connections of browsers may unintentionally cause this event as well.
  • BrokenConnection may be used to mark clients aborting the TCP connection before reading the whole HTTP response.
    Note: Connections may also be aborted by mod_qos if client reads the response too slow.
• QS_SetEnvIfResBody <string> [!]<env-variable>
  Adds the defined environment variable (e.g., QS_Block) if the response body contains the defined literal string. Used on a per- location level. Only one directive may be defined per-location (one search string per response). Prefixing the variably by a "!" lets the variable being removed (unset). You may set the QS_SetEnvIfResBodyIgnore environment variable if you want mod_qos to skip (not parsing) a request's response body.
• QS_SetEnvRes <env-variable> <regex> <env-variable2>[=<value>]
  Sets the environment variable (env-variable2) if the regular expression (regex) matches against the value of the environment variable (env-variable). Occurrences of $1..$9 within the value are replaced by parenthesized subexpressions of the regular expression.
• QS_SetReqHeader [!]<header name> <env-variable> [late]
  Sets the defined HTTP request header with the value of the specified environment variable if the variable is available.
  The header is unset (removed from the request) if the header name is prefixed by a "!".
• QS_SetEnvResHeader <header name> [drop]
  Sets the defined HTTP response header (name and value) to the request environment variables. Deletes the specified header if the action 'drop' has been specified.
• QS_SetEnvResHeaderMatch <header name> <regex>
  Sets the defined HTTP response header (name and value) to the request environment variables if the specified regular expression (pcre, not case sensitive) matches the header value.
• QS_UnsetReqHeader <header name>
  The request header of this name is removed.
• QS_UnsetResHeader <header name>
  The response header of this name is removed.
• QS_RedirectIf <variable> <regex> [<code>:]<url>
  Redirects the client to the configured url if the regular expression (case insensitive) matches the value of the the environment variable. Occurrences of $1..$9 within the url are replaced by parenthesized subexpressions of the regular expression. The default status code used by this directive is 302 but you may prefix the url parameter by 307: or 301: to change it to a "307 Temporary Redirect" or "301 Moved Permanently" response. Directive may be used on a per-server or per-location basis.

# marks clients coming from the internal network:
SetEnvIf    Remote_Addr      ^192\.168\.            QS_Intra

# marks clients neither coming from the internal network
# nor are VIP clients as low priority clients:
QS_SetEnvIf !QS_VipRequest   !QS_Intra              QS_LowPrio=1

# limits the request rate for low priority (neither VIP nor internal)
# clients (and no more than 400 concurrent requests for them):
QS_EventPerSecLimit          QS_LowPrio             100
QS_EventRequestLimit         QS_LowPrio             400

# detects the variable "file" within the query portion of the URL:
QS_SetEnvIfQuery             file=([a-zA-Z]*)       QS_LowPrio=$1

# combine variables and propagate them to the application via HTTP header:
SetEnvIf    Content-Length   ([0-9]*)               QS_Length=$1
QS_SetEnv   QS_Type          "length=${QS_Length}; file=${QS_LowPrio}"
QS_SetReqHeader              X-File                 QS_Type

# limit the max. body size since mod_parp loads the whole message into
# the memory servers's:
QS_LimitRequestBody          131072

# body pattern detection, example limits the maximum number of concurrent
# requests posting "id=1234" to ten:
QS_SetEnvIfParp  id=([0-9]*) PARP_PATTERN=$1
QS_EventRequestLimit         PARP_PATTERN=1234      10
# but ignore requests to the location /main/ (any sub-locations):
SetEnvIf    Request_URI      /main/.*               !parp

Request Level, Generic Filter

location

• QS_DenyRequestLine '+'|'-'<id> 'log'|'deny' <pcre>
  Generic request line (method, path, query, and protocol) filter used to deny access for requests matching the defined expression (pcre, case insensitive). The action taken for matching rules is either 'log' (access is granted but the rule match is logged) or 'deny' (access is denied).
• QS_DenyPath '+'|'-'<id> 'log'|'deny' <pcre>
  Generic abs_path (see RFC 2616 section 3.2.2) filter used to deny access for requests matching the defined expression (pcre, case insensitive). The action taken for matching rules is either 'log' (access is granted but the rule match is logged) or 'deny' (access is denied).
• QS_DenyQuery '+'|'-'<id> 'log'|'deny' <pcre>
  Generic query (see RFC 2616 section 3.2.2) filter used to deny access for requests matching the defined expression (pcre, case insensitive). The action taken for matching rules is either 'log' (access is granted but the rule match is logged) or 'deny' (access is denied).
• QS_InvalidUrlEncoding 'log'|'deny'|'off'
  Enforces correct URL decoding in conjunction with the QS_DenyRequestLine, QS_DenyPath, and QS_DenyQuery directives. Default is "off" which means that an incorrect encoding does stop request processing.
• QS_Decoding 'uni'
  Enables additional string decoding functions which are applied before matching QS_Deny* and QS_Permit* directives. Default is URL decoding (%xx, \\xHH, '+').
  Available additional decodings:
  • uni: unicode decoding for MS IIS (%uXXXX and \uXXXX) encoded characters.
• QS_DenyEvent '+'|'-'<id> 'log'|'deny' [!]<env-variable>
  Rule matching requests having the defined process environment variable set (or NOT set if prefixed by a '!'). The action taken for matching rules is either 'log' (access is granted but the rule match is logged) or 'deny' (access is denied).
• QS_PermitUri '+'|'-'<id> 'log'|'deny' <pcre>
  Generic URL (path and query) filter implementing a request pattern allow list. Only requests matching at least one QS_PermitUri pattern are allowed. If a QS_PermitUri pattern has been defined and the request does not match any rule, the request is denied. All rules must define the same action. pcre is case sensitive. You may use the qsfilter2 utility to generate rules based on access log files.
• QS_DenyInheritanceOff
  Disables inheritance of QS_Deny* and QS_Permit* directives (pattern definitions) to a location.
• QS_RequestHeaderFilter 'on'|'off'|'size'
  Filters request headers using validation rules provided by mod_qos. Suspicious headers (not matching the pattern or those which are too long) are normally dropped (removed from the request). Abnormal content-* headers cause request blocking. Only the defined headers are allowed (allow list). Custom rules (additional headers or different pattern/size definitions) may be added using the QS_RequestHeaderFilterRule directive.
  This directive has three different operation modes: 'on' (activated), 'off' (disabled), and 'size' (activated). The operation mode enabled by 'size' does not check the header values against the patterns but limits the maximum length of request header values only (similar to the Apache directive LimitRequestFieldsize but with an individual rule for each header field). This directive may be used on a per-server or per-location level.
  Notes:
  • Header validation is also useful to avoid bypassing of SetEnvIf / SetEnvIfPlus (if configured on a per-location level) directive settings as request headers have higher priority than environment variables for those directives and therefore a header sent a by client can override an environment variable having the same name.
  • You might also configure deny list rules (delete unwanted headers) using the QS_UnsetReqHeader or QS_UnsetResHeader directive.
• QS_RequestHeaderFilterRule <header name> 'drop'|'deny' <pcre> <size>
  Used to add custom request header filter rules, e.g., to override the internal rules (different pcre or size) or to add additional headers which should be allowed. Definitions are made globally (outside VirtualHost). The list of all loaded rules is shown at server startup when using LogLevel "debug". pcre is case sensitive. The size parameter defines the maximum length of a header value. The action 'drop' removes a header not matching the pcre, the action 'deny' rejects a request including such a header not matching the pcre.
• QS_ResponseHeaderFilter 'on'|'silent'|'off'
  Filters response headers using validation rules provided by mod_qos. Suspicious headers (not matching the pattern or those which are too long) are removed from the response. Only the defined headers are allowed. Filter is activated ('on' or 'silent') or deactivated ('off').
• QS_ResponseHeaderFilterRule <header name> <pcre> <size>
  Used to add custom response header filter rules, e.g., to override the internal rules (different pcre or size) or to add additional headers which should be allowed. Definitions are made globally (outside VirtualHost). A list of all loaded rules is shown at server startup when using LogLevel "debug". pcre is case sensitive. The size parameter defines the maximum length of a header value.

QS_ErrorPage                     /error-docs/qs_error.html

# add a custom request header rule:
QS_RequestHeaderFilterRule       UA-CPU drop "^[a-zA-Z0-9]+$" 20

# enable header validation:
QS_RequestHeaderFilter           on

<Location />
   # don't allow access to the path /app/admin.jsp:
   QS_DenyPath        +admin     deny "^/app/admin.jsp$"

   # allow printable characters only within the request line:
   QS_DenyRequestLine +printable deny ".*[\x00-\x19].*"
</Location>

Body data filtering requires mod_parp which processes the request's message body of the following HTTP request content types: application/x-www-form-urlencoded, multipart/form-data, and multipart/mixed. The content type application/json may be processed by the built-in JSON parser of mod_qos. The body data is transformed into a request query and may be filtered using the QS_DenyQuery and QS_PermitUri directives.

• QS_DenyQueryBody 'on|'off'
  Enables request body data filtering for the QS_DenyQuery directive.
• QS_PermitUriBody 'on|'off'
  Enables request body data filtering for the QS_PermitUri directive.
• QS_LimitRequestBody <bytes>
  Limits the allowed size of an HTTP request message body. This directive may be placed anywhere in the configuration. Alternatively, the limitation may be set as an environment variable using mod_setenvif (overriding the directive settings).

mod_deflate

# configure the audit log writing the request body data to a file
# (use this log to generate allow list rules using qsfilter2
# when QS_PermitUriBody has been enabled)
# format:
#   %h:
#   The remote host (used to filter by IP address).
#   %>s:
#   The HTTP response status code.
#   %{qos-loc}n
#   The matching Location to generate the rules for.
#   %{qos-path}n%{qos-query}n
#   The request data required by qsfilter2 to generate rules.
CustomLog             logs/qsaudit_log  "%h %>s %{qos-loc}n %{qos-path}n%{qos-query}n"

# enable json parser
PARP_BodyData               application/json

QS_RequestHeaderFilter      on

# limit the max. body size since mod_parp loads the whole message into the
# servers's memory:
SetEnvIfNoCase Content-Type application/x-www-form-urlencoded QS_LimitRequestBody=131072
SetEnvIfNoCase Content-Type multipart/form-data               QS_LimitRequestBody=131072
SetEnvIfNoCase Content-Type multipart/mixed                   QS_LimitRequestBody=131072
SetEnvIfNoCase Content-Type application/json                  QS_LimitRequestBody=65536

# enable mod_deflate input filter for compressed request body data:
SetEnvIfNoCase Content-Encoding (gzip|compress|deflate)       QS_DeflateReqBody

<Location /app>
   # don't allow a certain string pattern within the request query or
   # the request message body data:
   QS_DenyQueryBody              on
   QS_DenyQuery       +s01       deny "(EXEC|SELECT|INSERT|UPDATE|DELETE)"
</Location>

• Register the mod_parp raw parser using the PARP_BodyData directive.
• Enable mod_parp for the content type using the SetEnvIfNoCase directive.
• Use QS_SetEnvIfBody to detect patterns within the HTTP request body.
• The QS_DenyEvent directive denies access for the request.

# sample (using the raw body parser of mod_parp) which denies XML documents
# containing the pattern "<code>delete</code>":
PARP_BodyData               text/xml
SetEnvIfNoCase Content-Type text/xml.*                        parp
SetEnvIfNoCase Content-Type application/xml                   QS_LimitRequestBody=65536
QS_SetEnvIfBody             <code>delete</code>               DENYACTION
<Location /app/web>
   QS_DenyEvent             +BADCODE deny                     DENYACTION
</Location>

Milestones

• QS_MileStone 'log'|'deny' <pattern> [<thinktime>]
  Defines request line patterns a client must access in the defined order as they are defined in the configuration file. The optional 'thinktime' parameter defines the minimal elapse time (in seconds) between two milestones. Milestones are defined on a per-server basis, outside location . Access to milestones is tracked by a dedicated session cookie (QSSCD).
• QS_MileStoneTimeout <seconds>
  Defines the time in seconds within which a client must reach the next milestone. Default are 3600 seconds.

# four milestones:
# 1) client must start with /app/index.html
# 2) and then read some images (e.g. media used within the first page)
# 3) before posting data to /app/register
# 4) afterwards, the user may download zip files
QS_MileStone          deny       "^GET /app/index.html"
QS_MileStone          deny       "^GET /app/images/.*"
QS_MileStone          deny       "^POST /app/register*"
QS_MileStone          deny       "^GET /app/.*\.zip HTTP/..."

Connection Level Control

The module features the following directives to control server access on a per-server (TCP connection) level. These directives must only be used in the global server context and for port based virtual hosts. Virtual hosts neither defining QS_SrvMaxConn, QS_SrvMaxConnClose, nor QS_SrvMaxConnPerIP are using the base server's settings and counters. And do not use these three directives for name based virtual hosts!

• QS_SrvMaxConn <number>
  Defines the maximum allowed number of concurrent TCP connections for this server (virtual host).
• QS_SrvMaxConnClose <number>[%]
  Defines the maximum number of connections for this server (virtual host) supporting HTTP keep-alive. If the number of concurrent connections exceeds this threshold, the TCP connections gets closed after each request. You may specify the number of connections as a percentage of MaxClients if adding the suffix '%' to the specified value.
  Note: It's also possible to control the Keep-Alive settings dynamically using the QS_KeepAliveTimeout and QS_MaxKeepAliveRequests environment variables.
• QS_SrvMaxConnPerIP <number> [<connections>]
  Defines the maximum number of connections per source IP address for this server (virtual host). The "connections" argument defines the number of busy connections of the server (all virtual hosts) to enable this limitation, default is 0 (which means that the limitation is always enabled, even the server is idle).
• QS_SrvMaxConnExcludeIP <address>
  Defines an IP address or address range to be excluded from connection level control restrictions (trusted proxy servers). An address range must end with a "." or ":".
• QS_SrvMaxConnPerIPIgnoreVIP 'on'|'off'
  Tells the QS_SrvMaxConnPerIP directive to ignore (if set to "on") the VIP status of clients. Default is "off", which means that QS_SrvMaxConnPerIP gets disabled for VIPs.
• QS_SrvMinDataRate <bytes per second> [<max bytes per second> [<connections>]]
  Defines the minimum upload/download throughput a client must generate (the bytes sent/received by the client per seconds). This bandwidth is measured while receiving request data (in: request line, header fields, or body), sending response data (out: header fields, body) and during keep-alive (enforce keep-alive). The client connection is closed if the client does not fulfill this required minimal data rate and the IP address of the causing client is marked in order to be handled with low priority (see the QS_ClientPrefer directive). The "max bytes per second" activates dynamic minimum throughput control: The required minimal throughput is increased in parallel to the number of concurrent clients sending/receiving data (starts increasing when reaching the "connections" threshold) as a percentage of the "max bytes per second" which maximum is reached when the number of sending/receiving clients is equal to the MaxClients setting. The "connections" argument is used to specify the number of busy TCP connections a server must have to enable this feature (used to disable the QS_SrvMinDataRate rule enforcement on idle servers).
  This directives must only be used in the global server context.
• QS_SrvRequestRate <bytes per second> [<max bytes per second>]
  Same as QS_SrvMinDataRate but enforcing a minimal upload (reading request) throughput only.
• QS_SrvDataRateOff
  Disables the QS_SrvMinDataRate or QS_SrvRequestRate enforcement for a virtual host.
• QS_SrvMinDataRateOffEvent '+'|'-'<env-variable>
  Disables the QS_SrvMinDataRate or QS_SrvRequestRate enforcement for a connection when the defined process environment variable is set. The '+' prefix is used to add a variable to the configuration while the '-' prefix is used to remove a variable. Directive may be used on a per-server or a per-location basis.
• QS_SrvSampleRate <seconds>
  Defines the sampling rate used to measure the data throughput. Default is 5 seconds or the value you have used for QS_REQ_RATE_TM while compiling the module. Increase this value if you want to compensate bandwidth variations.
  This directives must only be used in the global server context.
  Note: It might also be increased to avoid too many error messages generated by a QS_SrvMinDataRate rule for clients opening unused TCP pre-connections which might happen if Apache's TimeOut directive is set to higher value than this sample rate.
• QS_SrvMinDataRateIgnoreVIP 'on'|'off'
  Tells the QS_SrvMinDataRate directive to ignore (if set to "on") the VIP status of clients. Default is "off", which means that QS_SrvMinDataRate gets disabled for VIPs.
• QS_SrvSerialize 'on'|'off' [<timeout>]
  Ensures that not more than one request having the QS_SrvSerialize variable set is processed at the same time by serializing them (process one request after each other). Default is "off".
  Note: Maximum wait time for a request is defined by the optional timeout parameter (in seconds). The default is 300 seconds.
• Throttling the download bandwidth: mod_qos does not support bandwidth limitation on a per connection basis but you might use the RATE_LIMIT filter provided by the Apache module mod_ratelimit to implement a bandwidth rate limitation for connections.

# minimum data rate (bytes/sec) when the server
# has 150 or more open TCP connections:
QS_SrvMinDataRate                                 64 256 150

# limits the connections for this virtual host:
QS_SrvMaxConn                                     800

# allows keep-alive support till the server reaches 600 connections:
QS_SrvMaxConnClose                                600

# allows max 50 connections from a single ip address:
QS_SrvMaxConnPerIP                                 50

# disables connection restrictions for certain clients:
QS_SrvMaxConnExcludeIP                    172.18.3.32
QS_SrvMaxConnExcludeIP                    192.168.10.

Client Level Control

Client level control rules are applied per client (IP source address). These directives must only be used in the global server context.

• QS_ClientEntries <number>
  Defines the number of individual clients managed by mod_qos. Default is 50'000 concurrent IP addresses. Each client requires about 150 bytes memory on a 64bit system (depending on how many QS_ClientEventLimitCount events you have configured). Client IP source address store survives graceful server restart. The maximum value is 10'000'000.
• QS_ClientEventRequestLimit <number>
  Defines the allowed number of concurrent requests coming from the same client source IP address having the QS_EventRequest variable set.
  Note: You may use the QS_ClientIpFromHeader directive to override the client's IP address based on the value within the defined HTTP request header (e.g., X-Forwarded-For) instead of taking the IP address of the client which has opened the TCP connection.
• QS_ClientEventPerSecLimit <number>
  Defines how often a client may cause a QS_Event per second. Such events are requests having the QS_Event variable set, e.g., defined by using the SetEnvIf directive. The rule is enforced by adding a delay to requests causing the event (similar to the QS_LocRequestPerSecLimit directive).
• QS_ClientEventBlockCount <number> [<seconds>]
  Defines the maximum number of QS_Block events allowed within the defined time (default is 600 seconds). Client IP is blocked when reaching this counter for the specified time (blocked at connection level: user might not always get a user friendly error response).
  Notes:
  • You may use QS_ClientEventBlockExcludeIP <addr> to exclude an IP address from being processed by this limitation (e.g. for trusted clients connecting via a proxy server). An address range must end with a "." or ":".
  • The counter can be decremented by setting the environment variable QS_Block_Decrement.
• QS_ClientEventLimitCount <number> [<seconds> [<variable>]]
  Defines the maximum number of requests having the defined environment variables (QS_Limit by default) set allowed within the defined time (default is 600 seconds). Requests from client IP's reaching this limitation are denied for the specified time (blocked at request level).
  Notes:
  • The value of the variable defines the penalty points by which the counters are increased. Default (empty or non-numeric value) is 1 (increment per request).
  • You may use the QS_ClientIpFromHeader directive to determine the client's IP address based on the defined HTTP request header (e.g., X-Forwarded-For) instead of taking the IP address of the client which has opened the TCP connection.
  • The current value of this counter is stored within the variable suffixed by _Counter, e.g. QS_Limit_Counter for further processing by other rules.
  • The remaining time (in seconds) is stored within the variabled suffixed by _Remaining, e.g. QS_Limit_Remaining to be used within SSI error pages.
  • The counter can be reset by setting the environment variable which name is suffixed by _Clear, e.g. QS_Limit_Clear.
  • The counter can be decremented by setting the environment variable which name is suffixed by _Decrement, e.g. QS_Limit_Decrement.
  • Adding/removing events (configuration changes) require a server restart (graceful restart is not supported).
  • Only the default rule (QS_Limit) is accessibly by the status viewer (you may use the console to view other variables alternatively).
  • See also QS_CondClientEventLimitCount if you want to enforce a rule under certain conditions only.
• QS_ClientSerialize
  Serializes requests having the QS_Serialize variable set if they are coming from the same IP address.
  Notes:
  • You may use the QS_ClientIpFromHeader directive to override the client's IP address based on the value within the defined HTTP request header (e.g., X-Forwarded-For) instead of taking the IP address of the client which has opened the TCP connection.
  • Maximum wait time for a request is 5 minutes.
• QS_ClientPrefer [<percent>]
  Accepts only VIP and high priority clients when the server has less than 80% (or the defined percentage) of free TCP connections. The server continues dropping more and more clients (also those with few penalty points) the higher the number of connections grows.
  Use the QS_VipHeaderName or QS_VipIPHeaderName directive in order to identify VIP clients.
  The distinction between high and low priority clients is made based on penalty points which are calculated based of these attributes:
  • Data transfer behavior (clients sending data slowly / their transfer rate) (0x01).
  • Accessing "unusual" content types (see QS_ClientTolerance and QS_ClientContentTypes) (0x00 unknown / 0x02 normal / 0x04 unusual).
  • Causing events blocking / limiting them (0x08 block / 0x10 limit).
  • If their connections get closed due to timeouts (0x20).
  HTTP requests causing a client to get marked as "low priority" have the "r;" event within the mod_qos_ev variable set. You may use the status viewer to determine which client addresses are identified as low priority clients. Feature is disabled if directive is not set.
  A low priority flag is cleared after 24h hours. Clients identified by QS_SrvMaxConnExcludeIP are excluded from connection restrictions. Filter is applied on connection level blocking clients even before the server starts reading the HTTP request data.
• QS_ClientTolerance <percent>
  Defines the allowed variation from a "normal" client (average) behavior when enabling the QS_ClientPrefer directive. Default is 20%.
• QS_ClientContentTypes <html> <css/js> <images> <other> <304>
  Defines the distribution of HTTP response content types a client normally receives when accessing the server. Can only be used in conjunction with the QS_ClientPrefer directive. QS_ClientTolerance defines the allowed deviation from these values. mod_qos normally learns the average behavior automatically by default (you can see the learned values within the status viewer or by enabling the QS_Status log messages) but you may specify a static configuration using this directive in order to avoid influences by a high number of abnormal clients. Default is automatic self-learning.
• QS_ClientGeoCountryDB <path>
  Defines the path to the geographical database file. The file is a Comma Separated Value (CSV) format file (example). Each line contains the following fields:
  • Double quoted beginning IPv4 number of the address range, e.g. "1052272128" for 62.184.102.0
  • Double quoted ending IPv4 number of the address range, e.g. "1052272543" for 62.184.103.159.
  • Double quoted ISO 3166 country code, e.g. "FR" for France.
  The QS_Country variable contains the country code for the client's IP address.
  Note: You may use the QS_ClientIpFromHeader directive to override the client's IP address based on the value within the defined HTTP request header (e.g., X-Forwarded-For) instead of taking the IP address of the client which has opened the TCP connection to evaluate this variable.
• QS_ClientGeoCountryPriv <list> <connections> ['excludeUnknown']
  Defines a comma separated list of country codes for origin client IPv4 address which are allowed to access the server even if the number of busy TCP connections reaches the defined number of connections.
  Uses the geographical database loaded by QS_ClientGeoCountryDB.
  Clients whose IP can't be mapped to a country code can be excluded from the limitation by configuring the 'excludeUnknown' argument.
• QS_ClientIpFromHeader <header>
  The QS_ClientIpFromHeader <header> directive can be used to determine the client's IP address based on the defined HTTP request header (e.g., X-Forwarded-For) instead of taking the IP address of the client which has opened the TCP connection. The header must only contain a single IP address.
  It can used for the following directives: QS_ClientEventRequestLimit, QS_ClientEventLimitCount, QS_ClientSerialize, and QS_ClientGeoCountryDB.
  Notes:
  • You might also use a pseudo IP address by creating a hash from the header's value if you prefix the header name by a '#', e.g. #Authorization to use the HTTP basic auth header.
  • The special name #SSL_CLIENT_S_DN creates a pseudo IP from the SSL client certificate's subject and issuer DN.
  • If the remote address information has been overridden by another module such as mod_remoteip , and you want to use this, use the special name #USERAGENT_IP (available with Apache 2.4.19 and newer).

# allows not more than 20 events/penalty points per 10 minutes:
QS_ClientEventBlockCount                          20

# don't allow a client to access /app/start.html more than
# 20 times within 10 minutes:
SetEnvIf     Request_URI /app/start.html          QS_Block=1

# don't allow more than 4 "403" status code responses
# (forbidden) for a client within 10 minutes:
QS_SetEnvIfStatus        403                      QS_Block=5

Log Messages

Error Log

mod_qos writes messages to Apache's error log when detecting a rule violation. Each error message is prefixed by an id: mod_qos(<number>). These error codes (number only) are also written to the error notes (Apache's error-notes note as well as the QS_ErrorNotes variable) in order to be processed within error pages using server-side includes (SSI).

mod_qos(00x): initialisation event mod_qos(01x): request level control event mod_qos(08x): request level control event mod_qos(02x): vip session event mod_qos(03x): connection level event mod_qos(04x): generic filter event mod_qos(14x): generic filter event mod_qos(05x): bandwidth limitation event mod_qos(06x): client control event mod_qos(16x): client control event mod_qos(07x): console errors mod_qos(08x): initialisation/resource errors mod_qos(10x): geo errors

Access Log

mod_qos adds event variables to the request record which may be added to access log messages.

• mod_qos_ev
  Status event message of mod_qos. It's a single letter which is used to signalize an event: "D"=denied, "S"=pass due to an available VIP session, "V"=create VIP session (cookie), "v"=marks an IP as VIP, "K"=connection closed (no keep-alive), "T"=dynamic keep-alive, "r"=IP is marked as a slow/bad client, "L"=means a request slowdown, "u"=request without a user tracking cookie, and "s" is used for serialized requests. The letter "A" for connection abort is set if the status code detection BrokenConnection has been configured.
• mod_qos_cr
  The number of concurrent requests to a location matching the QS_LocRequestLimit, QS_LocRequestLimitMatch, QS_LocRequestPerSecLimit, QS_LocRequestPerSecLimitMatch, QS_LocKBytesPerSecLimit, QS_LocKBytesPerSecLimitMatch, QS_CondLocRequestLimitMatch, or QS_EventRequestLimit directive.
• mod_qos_con
  This event shows the number of concurrent connections to this server. Only available if the directive QS_SrvMaxConn is used.
• mod_qos_user_id
  The user id which is available when enabling user tracking.
  User tracking is based on a unique identifier generated by mod_unique_id . This unique identifier is stored as a cookie. The user tracking feature is enabled by setting the QS_UserTrackingCookieName <name> [<path>] [<domain>] ['session'] ['jsredirect'] directive.
  Options of the QS_UserTrackingCookieName directive are:
  • The name argument defining the name of the user tracking cookie.
  • The path specifies a local error document which is shown if a user does not accept the cookie (enforcement).
    You may disable this enforcement for certain clients by setting the DISABLE_UTC_ENFORCEMENT environment variable at server level (outside Location), e.g., to allow crawlers not supporting cookies to access your site.
    This option can be used to ensure whether a client/browser accepts cookies at all which might be a requirement of your application.
  • domain defines optionally the domain attribute for the Set-Cookie header.
  • The session flag indicates that a short lived (per session) cookie shall be created which won't be stored by the browser permanently.
  • When using the additional option 'jsredirect', the client (browser) has to interpret Javascript used within the cookie check page to fetch the cookie and to execute the redirect back to the initially requested page (adding Javascript to the cookie challenge).
    The following SSI variables can be used:
    • QS_UT_QUERY: Query string to call (ajax) the cookie page again to obtain the cookie.
    • QS_UT_NAME: Name of the cookie.
    • QS_UT_INITIAL_URI: Initial page to redirect to.
  Notes:
  • QS_UserTrackingCookieName ignores the QS_LogOnly directive.
  • The cookie is secured by the QS_SessionKey and you should set this directive to have a constant key.
• UNIQUE_ID
  This is a unique request id generated by mod_unique_id. mod_qos uses this id to mark messages written to the error log. So it might be useful to log the UNIQUE_ID environment variable as well, in order to correlate errors to access log messages.
• QS_ConnectionId
  Connection correlation id used to mark all messages belonging to the same TCP connection.

LogFormat "%h %u %t \"%r\" %>s %b %T \"%{content-length}i\" %k \"%{User-Agent}i\" \
           %{mod_qos_cr}e %{mod_qos_ev}e %{mod_qos_con}e %{QS_SrvConn}e %{QS_AllConn}e \
           id=%{UNIQUE_ID}e %{QS_ConnectionId}e %{mod_qos_user_id}e %{QS_Country}e #%P"

Request Statistics

The qslog tool, which is part of the support utilities of mod_qos, may be used to gather request statistics from Apache's access log data. This includes data such as the number of denied requests or new VIP session creations per minute but also total requests per second and other data. Refer to the usage text of the qslog utility and read "Request Statistics Using qslog" for further details.

CustomLog "|/usr/bin/qslog -o logs/qslog.csv -x -f ISBDQkU" \ "%h %>s %b %D %{mod_qos_ev}e %k %{mod_qos_user_id}e"

Instead of using the standard Apache log CustomLog directive, you may use the QSLog directive of mod_qos alternatively. This allows you to configure a single log file for your Apache instance (globally, not per virtual host) and you don't have to specify the format (-f) option.

QSLog "|/usr/bin/qslog -o /var/log/apache/qslog.csv"

Status Viewer

mod_qos features a handler showing the current connection and request status.

<Location /qos> SetHandler qos-viewer </Location>

A machine-readable version of the status information is available when using the request query string auto, e.g., http://your.server.name/qos?auto. The page updates itself automatically every 10 seconds if you add the request query string refresh, e.g., http://your.server.name/qos?refresh.
Note: This view also shows you the error log event counters if you enable event (errors and warnings) counting by configuring QS_EventCount on and are using any client level limitation using QS_Client* directives.

The status information is also provided on the server status page of mod_status (although in a reduced scope).
Note: Compile mod_qos with the preprocessor definition -DQS_NO_STATUS_HOOK to disable its registration to the status page rendered by mod_status.

Use the directive QS_DisableHandler on to disable the qos-viewer and qos-console for a virtual host in order to prevent accidental activation of these functions, including by configuration settings of per-directory files (e.g., .htaccess).

The directive QS_Status 'on'|'off' may be used to enable a status log message (mod_qos(200)) written to the Apache server's ErrorLog. This message contains information about the server's scoreboard. The message is written once every minute.

Web Console

mod_qos implements an Apache handler which acts as a web console for setting attributes via HTTP requests.

<Location /qos/console> SetHandler qos-console </Location>

Access a location where you have enabled the qos-console handler with a web client and use the following request query parameter to modify the status of a client (may only be used if client level control has been enabled).

• address=<IP address>
  Specifies the IP address of the client to modify.
• action='block'|'unblock'|'limit'|'unlimit'|'inclimit'|'setvip'|'unsetvip'|'setlowprio'|'unsetlowprio'|'search'
  Defines the command to be executed, or the attribute to be changed.
  • block: blocks the client for the configured period of time, see also QS_ClientEventBlockCount.
  • unblock: clears the block attribute of the client.
  • limit: denies requests from the client IP for the configured period of time, see also QS_ClientEventLimitCount.
  • unlimit: clears the limit attribute of the client.
  • inclimit: increments the client's limit counter.
  • setvip: sets the client status to VIP.
  • unsetvip: clears the VIP status for a client.
  • setlowprio: sets the client's priority to 'low'.
  • unsetlowprio: clears the 'low' priority attribute of the client.
  • search: verifies the availability of a client IP address.
    Use the asterisk (*) for the address parameter in order to get a list of all available clients (dump).
• event=<name>
  Specifies the event name of the QS_ClientEventLimitCount directive counter which shall be shown or modified (used in conjunction with the limit, unlimit, inclimit, and search action). Default is QS_Limit.

The output (which is plain text) contains the following fields:

• IP address
• VIP status
• low priority status
• QS_ClientEventBlockCount counter (Cr) and remaining time (Td)
• QS_ClientEventLimitCount counter (Cr) and remaining time (Td)

The console may be used to manually update the status of a client (IP) or for automated actions.
Examples:

• To unlock a client which got blocked by mistake.
• To synchronize events within multiple Apache instances.
  An example using qsexec is available within the source code repository.
• Download/upload client status from one Apache instance to another (or to the same instance, e.g., when restarting an instance).

Examples to access the console:

• Sets VIP status for the IP 194.31.217.21:
  http://your.server.name/qos/console?action=setvip&address=194.31.217.21
• Clears the QS_Limit counter for the IP 194.31.217.21:
  http://your.server.name/qos/console?action=unlimit&address=194.31.217.21&event=QS_Limit

The status viewer may be used as well to verify the status of the client. Example:
http://your.server.name/qos?action=search&address=194.31.217.21

Utilities

mod_qos provides optional tools for log data processing and analysis:

• qsdt
  Simple tool to measure the elapse time between related log messages.
• qsexec
  Command execution triggered by patterns within log files.
• qsfilter2
  Rule generator. Creates QS_Permit* directives and rule patterns from audit log files.
• qsgeo
  Adds the country code for the client IP address within a log file.
• qsgrep
  Searches a file for a pattern and prints the data in a new format.
• qslog
  A real time TransferLog/CustomLog data analyzer. It reads the per request log data from stdin and generates statistic records every minute.
• qslogger
  Shell command interface to the syslog(3) system log module.
• qspng
  Creates graphics (png images) from the output of qslog.
• qsre
  Regular expression (pcre) pattern match test tool.
• qsrespeed
  Compares the expected processing time per regular expression.
• qsrotate
  Log rotation tool similar to Apache's rotatelogs.
• qssign
  A log data integrity check tool. It reads log data from stdin (pipe) and writes the signed data to stdout adding a sequence number and signature to ever log line.
  qssign.rb is a Logstash filter plugin which may be used to verify the signatures of log messages in real time.
• qstail
  Shows the end of a log file beginning at a defined pattern.

Sample Use Cases

Slow Application

In case of a very slow application (e.g., at location /ccc), requests wait until a timeout occurs. Due to many waiting requests, there are no free TCP connections left and the web sever is not able to process other requests to applications still working fine, e.g., to /aaa, /bbb /dd1, and /dd2. mod_qos limits the number of concurrent requests to an application in order to assure the availability of other resources.

Example:

# maximum number of active TCP connections is limited to 256 (limited # by the available memory, adjust the settings according to the # used hardware): MaxClients 256 # limits the maximum of concurrent requests per application to 100: QS_LocRequestLimit /aaa 100 QS_LocRequestLimit /bbb 100 QS_LocRequestLimit /ccc 100 QS_LocRequestLimitMatch "^(/dd1/|/dd2/).*$" 100

The qslog tool may be used to analyze your log files in order to identify "slow" resources by using the -pu, -puc, or -c option.

HTTP Keep-Alive

The keep-alive extension of HTTP 1.1 allows persistent TCP connections for multiple requests/responses. This accelerates access to the web server due to less and optimized network traffic. The disadvantage of these persistent connections is that server resources are blocked even when no data is exchanged between client and server. mod_qos allows a server to support keep-alive as long as sufficient connections are available, but stops the keep-alive support when it reaches a defined connection threshold.

Example:

# maximum number of active TCP connections is limited to 256 (limited # by the available memory, adjust the settings according to the # used hardware): MaxClients 256 # disables keep-alive when 70% of the TCP connections are occupied: QS_SrvMaxConnClose 70%

Client Opens Many Concurrent Connections

A single client may open many TCP connections simultaneously in order to download different content from the web server. So the client gets many connections while other users may not be able to access the server because no free connections remain for them. mod_qos can limit the number of concurrent connections for a single IP source address.

Example:

# maximum number of active TCP connections is limited to 896 # (limited by the available memory, adjust the settings according to the # used hardware): MaxClients 896 # don't allow a single client to open more than 50 TCP connections if # the server has not more than 196 free connections: QS_SrvMaxConnPerIP 50 700

Many Requests to a Single URL

If you have to limit the number of requests to an URL, mod_qos can help with that, too. You may limit the number of requests per second to an URL. mod_qos will then calculate the necessary delay time to be added to each requests accessing this resource in order to achieve the defined limitation.

Example:

# does not allow more than 150 requests/sec: QS_LocRequestPerSecLimit /download/mod_qos.so.gz 150 # but do not allow more than 600 concurrent requests: QS_LocRequestLimit /download/mod_qos.so.gz 600

Alternatively, if you need to reduce the number of processed requests per time to a very low value, you might add a (predefined or dynamically calculated) delay to each request and process only one of them at the same time. However, this will delay every request to the defined URI, even the server is idle.

Example:

# does not allow more than 4 requests/sec by adding a wait time of 250ms # to each request and process only one request at once: SetEnvIf Request_URI ^/download/mod_qos.so.gz QS_SrvSerialize=1 SetEnvIf Request_URI ^/download/mod_qos.so.gz QS_Delay=250 QS_SrvSerialize on # but do not allow more than 600 concurrent requests: QS_EventRequestLimit QS_SrvSerialize 600

mod_qos can also restrict the access to an URL by limiting the number of requests from a single IP address (LimitDownloadCounter is the counter to use while the LimitDownloadNow pattern is used to limit access to this specific resource only still allowing the IP address to access other resources).

Example:

# does not allow more than 4 downloads of mod_qos.so.gz per minute from a single IP address: SetEnvIf Request_URI ^/download/mod_qos.so.gz LimitDownloadCounter SetEnvIf Request_URI ^/download/mod_qos.so.gz QS_Cond=LimitDownloadNow QS_CondClientEventLimitCount 4 60 LimitDownloadCounter LimitDownloadNow

Bandwidth Restriction

It's sometimes necessary to restrict the bandwidth consumed by clients downloading certain type of data in order to avoid that the entire bandwidth of your Internet connection is exploited by less important data traffic, e.g. if your web server hosts large files to be downloaded.
mod_qos allows you to defined the bandwidth which may be used when accessing a defined URL or when the server returns a certain content-type.

Example:

# limits the download bandwidth when accessing ISO images to 1 megabyte/sec # and does not allow more then 300 clients to download such file type in # parallel: QS_LocKBytesPerSecLimitMatch \.iso 1024 QS_LocRequestLimitMatch \.iso 300

Brute Force

Sometimes, you want to limit how often a resource may be accessed within a certain amount of time, e.g., to defend against brute-force respectively dictionary attacks or an account lockout DoS (someone systematically locks user accounts by too many invalid sign-in attempts). mod_qos allows you to limit this either server wide (any request accessing the resource) by using the QS_EventLimitCount directive, or on a per client IP basis using the QS_ClientEventLimitCount directive.

Example:

# allows a single IP address to access the URI /wp-login.php not more # than 10 times within an hour: SetEnvIf Request_URI ^/wp-login.php LimitLogin QS_ClientEventLimitCount 10 3600 LimitLogin

Note: Multiple users may share an IP addresses which might cause false positives. You might avoid this by decrementing the counter on successful user authentication / login, e.g. by setting the variable LimitLogin_Decrement=1.

A brute force attack might also be performed by many distributed clients (thousands of clients, but every client performs a few requests only). To add protection to your server, you might configure an overall limitation for critical resources allowing only known clients (VIPs) to access your server without any restrictions. The QS_CondEventLimitCount directive might be used to achieve this.

Too Many Client Connections

mod_qos may prefer "known" client IP addresses in the case that too many clients access the server. "Known" clients are those which have once been identified by the application by setting the corresponding HTTP response header. Such identification may happen at successful user login. Connections from clients which are not known to mod_qos (never marked by the corresponding response header) are denied if the server runs on low TCP connection resources (20% or fewer free connections in this example). mod_qos may also prefer those clients which communicate with the server instantaneously and fast, and denies access to slow clients sending data irregularly, in case the server has not enough resources.

You may also set limitations defining how many resources may be requested by a single IP address source, e.g., using the QS_SrvMaxConnPerIP directive and you can disable HTTP keep-alive dynamically.

For more information about how mod_qos can help you in such situations, see the article "Denial of Service Defense".

Example:

# maximum number of active TCP connections is limited to 896 (limited # by the available memory, adjust the settings according to the used # hardware): MaxClients 896 # idle timeout: Timeout 5 # keep alive (for up to 85% of all connections): KeepAlive on MaxKeepAliveRequests 40 KeepAliveTimeout 2 QS_SrvMaxConnClose 85% # name of the HTTP response header which marks preferred clients (this # may be used to let the application decide which clients are "good" and # have higher privileges, e.g. authenticated users. # you may also use the QS_VipIPUser directive when using an Apache # authentication module such as mod_auth_basic or mod_auth_oid ): QS_VipIPHeaderName mod-qos-login # enables the known client prefer mode (server allows new TCP connections # from known/good clients only if there are more than 716 open TCP connections): QS_ClientPrefer 80% # don't allow more than 30 TCP connections per client source address being # processed if the server has 500 or more open connections: QS_SrvMaxConnPerIP 30 500