WAF, The Intro

I remember the first time I had to work with a WAF solution, I was hesitant of interacting with it because of the large impact it would generate if something was incorrectly modified or configured.

I remember being told to “just” read the Modsecurity Handbook and “check if needed” the Modsecurity Reference Manual (it was v2 at that time) so I could understand what to enable or disable and tune certain rules…

… I wish it was so easy as it sounds, I mean, I had very limited time to read and understand how WAF works, on top of that I had to become proficient at regex, and the different ways a rule can be configured to match a transaction (in WAF a transaction is both, the HTTP request and response), identify at which part of the transation a rule works, and also make sure the rule will not cause abnormal overhead (WAF already causes overhead).

And this was all in production, yeah, I know, it was already scary…

So after reading, building my own lab (multiple times), I gained some confidence at it at least to make sure I was “not going to break” anything, But it was still not enough, additionally, I had to make sure new team members would not suffer the same while also help speed up their learning process, so I created a small presentation that explained how WAF works, since that belongs to the company I made it for, I will create a new enhanced guide that explains it so it is available for anyone who needs it.

So here we go…

Relevant Concepts

• WAF: Web Application Firewall, its a security solution that provides virtual patching to known vulnerabilities to WEB applications and all its related components. Mostly known by the Modsecurity or Modsec project which is part of the OWASP. It uses CRS as its baseline rules
• OWASP: Open Web Application Security Project, its an open international non-profit organization which is mainly focused on web application security, they publish the OWASP Top 10 which is a very important web security standard and contains the most critical security risks to web applications.
• CRS: Core Rule Set, is a set of rules designed to detect mostly generic but also specific web application attacks.
• Virtual Patch: Its a security practice that protects systems and applications from vulnerabilities without modifying the source code, some also call it “external patching” an its a faster way to “patch” a system. Be aware that this does not remove the vulnerability from the system or application, it just adds a security layer to provide protection, and it is ALWAYS recommended to keep the apps and systems properly patched.
• False Positives: I liked this definition from NIST “An instance in which a security tool incorrectly classifies benign content as malicious.”

Why should we use a WAF solution?

Mainly because the probability being target for web attacks grows faster than the capabilities any company has on patching their systems, and it is easier to apply a temporary virtual patch while we work on the final fix instead of leaving our systems wide open.

Why shouldn’t we use a WAF solution?

There is no valid reason, unless your data, clients and applications are not important for your business and you dont care being sued for not carrying data and app protection mechanisms for your business.

Where can WAF be installed?

It can be installed on your own apache or/and nginx servers, we might get in details in future articles.

Or you can pay to WAF providers, feel free to reach out so I can provide you with my recomendations (it’s free). At the end of the day it depends on your budget, your level of technical dexterity, how fast and urged you are, how much traffic your apps handle, etc

WAF Overview

WAF syntax, most specificaly CRS syntax, generally looks like this:

    SecRule REQUEST_COOKIES "@rx attack" "phase:1, log, t:none, deny, id:1"

It is a little strange, isn’t it?, don’t worry, let’s quickly break it down to get some clarity:

Directives

It is essentially an instruction or setting that tells ModSecurity how to behave in specific situations. Think of it as a switch or dial that you can adjust to customize how your web application firewall (WAF) operates. There are different type of them, and they serve for different purposes, some examples are:

• SecDefaultAction: sets default actions for a particular processing phase.
• SecRule: sets a rule to analyze traffic and apply certain actions on it (we will be focusing on this kind of directive)
• SecRuleEngine: sets the rule mode (on, off, detect only)
• SecDebugLogLevel: sets the level of verbosity of the WAF logs.
• SecRuleRemoveById: it’s used to remove a matching rule from being applied, it’s basically a way to bypass or disable a rule.

Variables

It is a container that holds specific information about the HTTP transaction, server environment, or ModSecurity’s internal state. Think of variables as sensors that capture different aspects of web traffic, pretty much the portion of the transaction where we want the rule to focus on. There are different categories of variables available:

• Request Variables: REQUEST_HEADERS, REQUEST_COOKIES, REQUEST_URI, ARGS, ARGS_GET, ARGS_POST
• Response Variables: RESPONSE_HEADERS, RESPONSE_BODY, RESPONSE_STATUS
• Server Variables: SERVER_NAME, SERVER_ADDR, SERVER_PORT
• Special Collections: FILES, ENV, GEO, IP, SESSION

Operators

These are the conditions or tests that are applied to variables to determine if a rule should trigger. They define how ModSecurity should evaluate the data captured by variables. Common operators include:

• @rx: performs a regular expression match
• @pm: performs a pattern match against a list of patterns
• @eq: performs an equals comparison
• @gt: performs a greater than comparison
• @contains: checks if the variable contains a specific string
• @ipMatch: checks if an IP matches a specified range

Actions

These determine what ModSecurity should do when a rule matches. They are the consequences or responses that get triggered. Common actions include:

• deny: blocks the request
• allow: permits the request to proceed
• log: records the transaction
• status: sets the response status code
• msg: sets a message for logging
• id: assigns an identifier to the rule

Phases

These define when during the request/response cycle a rule should be evaluated. The five phases are:

• Phase 1: Request Headers
• Phase 2: Request Body
• Phase 3: Response Headers
• Phase 4: Response Body
• Phase 5: Logging

Transformations

These are functions that modify the data before it’s evaluated by the operator. Common transformations include:

• t:none: disables all transformations, allowing evaluation of raw data
• lowercase: converts string to lowercase
• urlDecode: decodes URL-encoded strings
• base64Decode: decodes base64-encoded strings
• removeWhitespace: removes all whitespace
• htmlEntityDecode: decodes HTML entities
• compress_whitespace: replaces multiple spaces with a single space

Well that’s it for now, in following articles we will get deeper in each of them, creating custom rule, and we will be setting up a WAF server from scratch, as well as other important topics.