Add filter_body plugin for request/response body content filtering #12740
Conversation
This plugin provides streaming body content inspection with configurable pattern matching and actions. It can be used to detect and mitigate CVE exploits and other malicious content patterns. Features: - YAML-based configuration with rule definitions using filter/action schema - Header-based filtering (AND logic between headers, OR within patterns) - Case-insensitive header matching, case-sensitive body patterns - Configurable actions per rule: log, block, add_header (with multiple headers) - Support for both request and response body inspection - Streaming transform with lookback buffer for cross-boundary patterns - Optional max_content_length to skip large bodies - Configurable HTTP methods (request) and status codes (response) - Per-rule metrics counters for monitoring matches - Support for <rule_name> substitution in header values Actions: - log: Log pattern matches via TSError - block: Set 403 Forbidden status and return error response - add_header: Add custom headers to server request or client response Includes: - Comprehensive RST documentation - README.md quick reference - ATSReplayTest autests for request/response filtering scenarios Co-authored-by: Brian Neradt <brian.neradt@gmail.com>
bneradt
left a comment
bneradt
left a comment
There was a problem hiding this comment.
Do we want the README.md since we have the public-facing doc? I suppose the idea of the README is that it would be more dev-centric rather than user focused?
Cast block_avail to size_t before subtracting search_offset to resolve constructor ambiguity between size_t, unsigned, ssize_t, and int overloads. This matches the casting pattern used elsewhere in the same function.
Due to the streaming nature of request body inspection, the response status for blocked requests may be either 403 or 502 depending on timing: - 403 if blocking happens before origin connection - 502 if blocking happens after request headers sent to origin The blocking action is still verified via log message checks. Removing the status expectation prevents test flakiness.
| - Configurable actions per rule: ``log``, ``block``, ``add_header``. | ||
| - Support for both request and response body inspection. | ||
| - Streaming transform with lookback buffer for cross-boundary pattern matching. | ||
| - Optional ``max_content_length`` to skip inspection of large bodies. |
There was a problem hiding this comment.
nit: have the optionals at the end of the list next to eachother
| - Case-insensitive header matching, case-sensitive body patterns. | ||
| - Configurable actions per rule: ``log``, ``block``, ``add_header``. | ||
| - Support for both request and response body inspection. | ||
| - Streaming transform with lookback buffer for cross-boundary pattern matching. |
There was a problem hiding this comment.
This sentence doesn't really make sense to me (maybe I just dont have context) but perhaps a link to a (wiki?) page explaining this could be helpful.
| Features | ||
| -------- | ||
|
|
||
| - YAML-based configuration with flexible rule definitions. |
There was a problem hiding this comment.
nit: bullet points shouldn't have a full stop at the end
| Installation | ||
| ============ | ||
|
|
||
| The ``filter_body`` plugin is an experimental plugin. To build it, either pass |
There was a problem hiding this comment.
You should also mention in the fist sentence of this page that it is experimental
| ============ | ||
|
|
||
| The ``filter_body`` plugin is an experimental plugin. To build it, either pass | ||
| ``-DENABLE_FILTER_BODY=ON`` to ``cmake`` when configuring the build:: |
There was a problem hiding this comment.
Does experiemental plugins need to be turned on for this to work or will this flag turn on just this experimental plugin
| List of HTTP methods to match. If not specified, all methods are matched. | ||
| Only valid for request rules. Example: ``[GET, POST, PUT]``. | ||
|
|
||
| ``status`` (optional) |
There was a problem hiding this comment.
I would reorder this and have subsections of options that are only valid for request rules and ones that are only valid for response rules.
|
|
||
| 1. **Request blocking**: When blocking request bodies, the connection to the | ||
| origin is closed and the client receives a 502 Bad Gateway response. The | ||
| plugin cannot send a custom error response (such as 403 Forbidden) because |
There was a problem hiding this comment.
Could header_rewrite set-status be used to get around this?
| @@ -0,0 +1,137 @@ | |||
| # filter_body Remap Plugin Implementation | |||
There was a problem hiding this comment.
Do you want to keep this?
| Query with `traffic_ctl`: | ||
|
|
||
| ```bash | ||
| traffic_ctl metric get plugin.filter_body.rule.xxe_detection.matches |
There was a problem hiding this comment.
probably keep this as <rule_name> instead od xxe_matches to maintain consistency.
3 participants
This plugin provides streaming body content inspection with configurable pattern matching and actions. It can be used to detect and mitigate CVE exploits and other malicious content patterns.
Features
<rule_name>substitution in header valuesActions
Includes
Co-authored-by: Brian Neradt brian.neradt@gmail.com