From 2468c2176ca5da17154315036a923e3b8f0bc23c Mon Sep 17 00:00:00 2001 From: Christopher Faulet Date: Wed, 13 Oct 2021 22:00:39 +0200 Subject: [PATCH] DOC: config: Move 'tcp-response content' at the right place Documentation of 'tcp-response content' was placed before documentation 'tcp-request session'. --- doc/configuration.txt | 188 +++++++++++++++++++++--------------------- 1 file changed, 94 insertions(+), 94 deletions(-) diff --git a/doc/configuration.txt b/doc/configuration.txt index c242698c4..5884507b5 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -12654,6 +12654,100 @@ tcp-request inspect-delay "timeout client". +tcp-request session [{if | unless} ] + Perform an action on a validated session depending on a layer 5 condition + May be used in sections : defaults | frontend | listen | backend + no | yes | yes | no + Arguments : + defines the action to perform if the condition applies. See + below. + + is a standard layer5-only ACL-based condition (see section 7). + + Once a session is validated, (i.e. after all handshakes have been completed), + it is possible to evaluate some conditions to decide whether this session + must be accepted or dropped or have its counters tracked. Those conditions + cannot make use of any data contents because no buffers are allocated yet and + the processing cannot wait at this stage. The main use case it to copy some + early information into variables (since variables are accessible in the + session), or to keep track of some information collected after the handshake, + such as SSL-level elements (SNI, ciphers, client cert's CN) or information + from the PROXY protocol header (e.g. track a source forwarded this way). The + extracted information can thus be copied to a variable or tracked using + "track-sc" rules. Of course it is also possible to decide to accept/reject as + with other rulesets. Most operations performed here could also be performed + in "tcp-request content" rules, except that in HTTP these rules are evaluated + for each new request, and that might not always be acceptable. For example a + rule might increment a counter on each evaluation. It would also be possible + that a country is resolved by geolocation from the source IP address, + assigned to a session-wide variable, then the source address rewritten from + an HTTP header for all requests. If some contents need to be inspected in + order to take the decision, the "tcp-request content" statements must be used + instead. + + The "tcp-request session" rules are evaluated in their exact declaration + order. If no rule matches or if there is no rule, the default action is to + accept the incoming session. There is no specific limit to the number of + rules which may be inserted. + + Several types of actions are supported : + - accept : the request is accepted + - reject : the request is rejected and the connection is closed + - { track-sc0 | track-sc1 | track-sc2 } [table ] + - sc-inc-gpc(,) + - sc-inc-gpc0() + - sc-inc-gpc1() + - sc-set-gpt(,) { | } + - sc-set-gpt0() { | } + - set-mark + - set-dst + - set-dst-port + - set-src + - set-src-port + - set-tos + - set-var() + - set-var-fmt() + - unset-var() + - silent-drop + + These actions have the same meaning as their respective counter-parts in + "tcp-request connection" and "tcp-request content", so please refer to these + sections for a complete description. + + Note that the "if/unless" condition is optional. If no condition is set on + the action, it is simply performed unconditionally. That can be useful for + "track-sc*" actions as well as for changing the default action to a reject. + + Example: track the original source address by default, or the one advertised + in the PROXY protocol header for connection coming from the local + proxies. The first connection-level rule enables receipt of the + PROXY protocol for these ones, the second rule tracks whatever + address we decide to keep after optional decoding. + + tcp-request connection expect-proxy layer4 if { src -f proxies.lst } + tcp-request session track-sc0 src + + Example: accept all sessions from white-listed hosts, reject too fast + sessions without counting them, and track accepted sessions. + This results in session rate being capped from abusive sources. + + tcp-request session accept if { src -f /etc/haproxy/whitelist.lst } + tcp-request session reject if { src_sess_rate gt 10 } + tcp-request session track-sc0 src + + Example: accept all sessions from white-listed hosts, count all other + sessions and reject too fast ones. This results in abusive ones + being blocked as long as they don't slow down. + + tcp-request session accept if { src -f /etc/haproxy/whitelist.lst } + tcp-request session track-sc0 src + tcp-request session reject if { sc0_sess_rate gt 10 } + + See section 7 about ACL usage. + + See also : "tcp-request connection", "tcp-request content", "stick-table" + + tcp-response content [{if | unless} ] Perform an action on a session response depending on a layer 4-7 condition May be used in sections : defaults | frontend | listen | backend @@ -12837,100 +12931,6 @@ tcp-response content [{if | unless} ] See also : "tcp-request content", "tcp-response inspect-delay" -tcp-request session [{if | unless} ] - Perform an action on a validated session depending on a layer 5 condition - May be used in sections : defaults | frontend | listen | backend - no | yes | yes | no - Arguments : - defines the action to perform if the condition applies. See - below. - - is a standard layer5-only ACL-based condition (see section 7). - - Once a session is validated, (i.e. after all handshakes have been completed), - it is possible to evaluate some conditions to decide whether this session - must be accepted or dropped or have its counters tracked. Those conditions - cannot make use of any data contents because no buffers are allocated yet and - the processing cannot wait at this stage. The main use case it to copy some - early information into variables (since variables are accessible in the - session), or to keep track of some information collected after the handshake, - such as SSL-level elements (SNI, ciphers, client cert's CN) or information - from the PROXY protocol header (e.g. track a source forwarded this way). The - extracted information can thus be copied to a variable or tracked using - "track-sc" rules. Of course it is also possible to decide to accept/reject as - with other rulesets. Most operations performed here could also be performed - in "tcp-request content" rules, except that in HTTP these rules are evaluated - for each new request, and that might not always be acceptable. For example a - rule might increment a counter on each evaluation. It would also be possible - that a country is resolved by geolocation from the source IP address, - assigned to a session-wide variable, then the source address rewritten from - an HTTP header for all requests. If some contents need to be inspected in - order to take the decision, the "tcp-request content" statements must be used - instead. - - The "tcp-request session" rules are evaluated in their exact declaration - order. If no rule matches or if there is no rule, the default action is to - accept the incoming session. There is no specific limit to the number of - rules which may be inserted. - - Several types of actions are supported : - - accept : the request is accepted - - reject : the request is rejected and the connection is closed - - { track-sc0 | track-sc1 | track-sc2 } [table
] - - sc-inc-gpc(,) - - sc-inc-gpc0() - - sc-inc-gpc1() - - sc-set-gpt(,) { | } - - sc-set-gpt0() { | } - - set-mark - - set-dst - - set-dst-port - - set-src - - set-src-port - - set-tos - - set-var() - - set-var-fmt() - - unset-var() - - silent-drop - - These actions have the same meaning as their respective counter-parts in - "tcp-request connection" and "tcp-request content", so please refer to these - sections for a complete description. - - Note that the "if/unless" condition is optional. If no condition is set on - the action, it is simply performed unconditionally. That can be useful for - "track-sc*" actions as well as for changing the default action to a reject. - - Example: track the original source address by default, or the one advertised - in the PROXY protocol header for connection coming from the local - proxies. The first connection-level rule enables receipt of the - PROXY protocol for these ones, the second rule tracks whatever - address we decide to keep after optional decoding. - - tcp-request connection expect-proxy layer4 if { src -f proxies.lst } - tcp-request session track-sc0 src - - Example: accept all sessions from white-listed hosts, reject too fast - sessions without counting them, and track accepted sessions. - This results in session rate being capped from abusive sources. - - tcp-request session accept if { src -f /etc/haproxy/whitelist.lst } - tcp-request session reject if { src_sess_rate gt 10 } - tcp-request session track-sc0 src - - Example: accept all sessions from white-listed hosts, count all other - sessions and reject too fast ones. This results in abusive ones - being blocked as long as they don't slow down. - - tcp-request session accept if { src -f /etc/haproxy/whitelist.lst } - tcp-request session track-sc0 src - tcp-request session reject if { sc0_sess_rate gt 10 } - - See section 7 about ACL usage. - - See also : "tcp-request connection", "tcp-request content", "stick-table" - - tcp-response inspect-delay Set the maximum allowed time to wait for a response during content inspection May be used in sections : defaults | frontend | listen | backend