QSFILTER2(1)

πŸ“¦
version 11.74 Β· 2 versions
, in epel 9, ubuntu noble

πŸ’– QSFILTER2(1) β€” the qsfilter2 man page, but make it make sense πŸ’–

okay bestie, sit down, hydrate, because we're about to talk about qsfilter2 from the mod_qos utilities. it's a whole vibe and honestly? kind of iconic. πŸŽ€


✨ NAME ✨

qsfilter2 β€” an utility to generate mod_qos request line rules out from existing access/audit log data. πŸ¦‹


🌸 SYNOPSIS 🌸

qsfilter2 -i <path> [-c <path>] [-d <num>] [-h] [-b <num>] [-p|-s|-m|-o]
[-l <len>] [-n] [-e] [-u 'uni'] [-k <prefix>] [-t] [-f <path>] [-v
0|1|2]

πŸ’… DESCRIPTION πŸ’…

so mod_qos has this request filter that validates each and every request line. it's giving bouncer at the club, but for HTTP. and it supports both models, because it contains multitudes:

  • the negative security model (aka the deny list) β€” that's the QS_Deny* directives. these specify request line patterns that are not allowed to access the server. you use these rules to lock down certain resources that should not be available to users, or to protect the server from malicious patterns. not on my watch energy. πŸ’€
  • the positive security model (aka the allow list) β€” that's the QS_Permit* rules. these directives define the request line patterns that are allowed. anything that doesn't match any of these patterns? not allowed to access the server. periodt.

and qsfilter2? it's an audit log analyzer that generates filter rules β€” perl compatible regular expressions, no less β€” which may be used by mod_qos to deny access for suspect requests (QS_PermitUri rules). it parses your existing audit log files in order to generate request patterns covering all allowed requests. it literally reads the receipts and writes you a whole security model. main character behavior honestly. πŸ‘‘


🌈 OPTIONS 🌈

  • -i <path> β€” the input file containing request URIs. these URIs have to be extracted from the server's access logs, bestie. each line of the input file contains a request URI consisting of a path and and query.

Example:

/aaa/index.do
/aaa/edit?image=1.jpg
/aaa/image/1.jpg
/aaa/view?page=1
/aaa/edit?document=1

these access log data must include current request URIs but also request lines from previous rule generation steps. it must also include request lines which cover manually generated rules. you may use the qos-path and qos-query variables to create an audit log containing all request data (path and query/body data). Example: CustomLog audit_log %{qos-path}n%{qos-query}n. See also http://mod-qos.sourceforge.net#qsfiltersample about the module settings. 🫢

  • -c <path> β€” the mod_qos configuration file defining QS_DenyRequestLine and QS_PermitUri directives. qsfilter2 generates rules from access log data automatically, but manually generated rules (QS_PermitUri) may be provided from this file. Note: each manual rule must be represented by a request URI in the input data (-i) in order to make sure not to be deleted by the rule optimisation algorithm. and QS_Deny* rules from this file are used to filter request lines which should not be used for allow list rule generation.

Example:

# manually defined allow list rule:
QS_PermitUri +view deny
"^[/a-zA-Z0-9]+/view\?(page=[0-9]+)?$"
# filter unwanted request line patterns:
QS_DenyRequestLine +printable deny ".*[\x00-\x19].*"
  • -d <num> β€” depth (sub locations) of the path string which is defined as a literal string. Default is 1. πŸ“
  • -h β€” always use a string representing the handler name in the path even the url does not have a query. See also the -d option.
  • -b <num> β€” replaces url pattern by the regular expression when detecting a base64/hex encoded string. detecting sensibility is defined by a numeric value. you should use values higher than 5 (default) or 0 to disable this function.
  • -p β€” represents query by pcre only (no literal strings).
  • -s β€” uses one single pcre for the whole query string.
  • -m β€” uses one pcre for multiple query values (recommended mode β€” this is the one, bestie πŸ”₯).
  • -o β€” does not care the order of query parameters. live your truth, unordered. ✨
  • -l <len> β€” outsizes the query length by the defined length ({0,size+len}), default is 10.
  • -n β€” disables redundant rules elimination.
  • -e β€” exit on error. no notes, just boundaries. πŸ’…
  • -u 'uni' β€” enables additional decoding methods. use the same settings as you have used for the QS_Decoding directive. (match your outfit to your shoes, okay?)
  • -k <prefix> β€” prefix used to generate rule identifiers (QSF by default).
  • -t β€” calculates the maximal latency per request (worst case) using the generated rules. math girlies rise up. 🧚
  • -f <path> β€” filters the input by the provided path (prefix) only processing matching lines.
  • -v <level> β€” verbose mode (0=silent, 1=rule source, 2=detailed). Default is 1.
⚠️ Don't use rules you haven't checked the request data used to generate it! Level 1 is highly recommended (as long as you don't have created the log data using your own web crawler). like, seriously bestie, please look before you leap. 😭

πŸ‘‘ OUTPUT πŸ‘‘

the output of qsfilter2 is written to stdout. the output contains the generated QS_PermitUri directives but also information about the source which has been used to generate these rules.

it is very important to check the validity of each request line which has been used to calculate the QS_PermitUri rules. each request line which has been used to generate a new rule is shown in the output prefixed by "ADD line <line number>:". these request lines should be stored and reused at any later rule generation (add them to the URI input file). the subsequent line shows the generated rule.

at the end of data processing a list of all generated QS_PermitUri rules is shown. these directives may be used withn the configuration file used by mod_qos.


πŸŽ€ EXAMPLE πŸŽ€

qsfilter2 -i loc.txt -c httpd.conf -m -e
...
# ADD line 1: /aaa/index.do
# 003 ^(/[a-zA-Z0-9\-_]+)+[/]?\.?[a-zA-Z]{0,4}$
# ADD line 3: /aaa/view?page=1
# --- ^[/a-zA-Z0-9]+/view\?(page=[0-9]+)?$
# ADD line 4: /aaa/edit?document=1
# 004 ^[/a-zA-Z]+/edit\?((document)(=[0-9]*)*[&]?)*$
# ADD line 5: /aaa/edit?image=1.jpg
# 005 ^[/a-zA-Z]+/edit\?((image)(=[0-9\.a-zA-Z]*)*[&]?)*$
...
QS_PermitUri +QSF001 deny
"^[/a-zA-Z]+/edit\?((document|image)(=[0-9\.a-zA-Z]*)*[&]?)*$"
QS_PermitUri +QSF002 deny "^[/a-zA-Z0-9]+/view\?(page=[0-9]+)?$"
QS_PermitUri +QSF003 deny "^(/[a-zA-Z0-9\-_]+)+[/]?\.?[a-zA-Z]{0,4}$"

🌟 SEE ALSO 🌟

qsdt(1), qsexec(1), qsgeo(1), qsgrep(1), qshead(1), qslog(1), qslogger(1), qspng(1), qsre(1), qsrespeed(1), qsrotate(1), qssign(1), qstail(1)

(the whole friend group, go say hi πŸ’–)


πŸ’œ AUTHOR πŸ’œ

Pascal Buchbinder, http://mod-qos.sourceforge.net/


and that's the whole thing, bestie β€” brought to you by the mod_qos utilities 11.74, dated May 2023. go forth and generate those rules responsibly. slay. πŸ’…βœ¨

πŸ“¦ where this page comes from