WebARX Web Application Firewall Engine

WebARX is for both – technical webmasters or web developers and website owners, who don’t have that much technical skill. WebARX web application firewall has a huge amount of opportunities, which for example for CMS users (such as WordPress) removes the need to use multiple security plugins.

In this article, you can read about why is WebARX web application firewall engine one of the most advanced on the market and how you can customize the firewall for it to work the best in your environment.

What Is Web Application Firewall?

A web application firewall (short for WAF) in an application firewall that monitors, filters and blocks traffic that may be harmful to your site.

Web application firewall, and firewall in general consists of multiple components working together to block malicious traffic and prevent false-positive results.

Read more about what is a web application firewall here.

Why do you need a Web Application Firewall?

Hackers are always innovating and finding new ways to get access to your site. It means that having a good security-minded coding technique and implementing security measures already in the coding process may not be enough.

The problem lies in many cases in the used components. Components are for example plugins and themes that are installed on a site. With modern web development practices, heavy usage of third-party components is becoming more and more popular. WordPress has the biggest problem with components.

A very worrisome fact about website hacking statistics: 98% of WordPress vulnerabilities are related to plugins.

Website hacking statistics 2019 – read more here.

Fixing the vulnerable code within the third-party components usually requires the plugin developer to push an update with a fix. For website owners or developers, analyzing the code and fixing it manually is usually not an option.

That’s where virtual patches come very handy.

WebARX sends virtual patches to your websites

Virtual patches are firewall rules that are sent to your site automatically. They usually are made to specifically block and protect a specific plugin or component vulnerability.

Virtual patching is especially good for companies that have multiple websites. If your sites have the same framework/CMS/plugins installed, then central management of virtual patching can save you quite some time and a headache.

Few reasons why virtual patching is great for your sites:

1. It’s scalable as managed web application firewalls can deploy patches to a network of sites at the same time.
2. It reduces the risk while the developer of a plugin/component releases the fix.
3. Less risk for conflicts compared to when the code is manually patched.
4. Provides protection to all sites almost immediately after discovery.
5. Reduces time and money from remediations or from manual code patches.

Read more about what is virtual patching here.

With WebARX you have the freedom to make your own firewall rules

There are a few settings to consider before writing your own match rules. The main difference is whether a rule is for whitelist or not. In case of a whitelist rule, matched elements will skip web application firewall rules from processing request and allow access to the website. In case of a firewall (blacklist) rule, you have the ability to choose from LOG, BLOCK or REDIRECT actions.

• LOG – Logs request and proceeds with access to the website.
• BLOCK – Blocks user from accessing the website.
• REDIRECT – Redirects user to provided URL.

We also provide the ability to match the defined request method. Currently available options are GET, POST and ALL.

Matching Elements

URI

The most simple form of matching. It will seek for a match on request URI, such as /wp-admin. If a match is found, the previously set action will be triggered (LOG, BLOCK or REDIRECT). You can also set it as a whitelist to bypass web application firewall on specific locations.

HTTP Headers

HTTP headers allow the client and the server to pass additional information with the request or the response. You can read more about HTTP Headers here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers

All

Matches on all HTTP headers separated by new line.

Key

Collection of all header keys, for example Content-Type, User-Agent, Accepts, Cookie, Host etc. It can be used to check if the certain header exists or contains in a request or not. The rule is being checked against each key name separately and a match is considered if one of the keys matches provided rule.

Value

Collection of all header values in the request, for example: application/json, user's user agent, cookie etc. It can be used to block requests coming from web bots based on their User-Agent. The rule is being checked against each value separately and a match is considered if one of the values matches provided rule.

Key and value

Collection of headers and values, for example: Content-Type: application/json. It can be used for more precise matching to make sure that both key and value match. The rule is being checked against each element separately and a match is considered if one of the elements matches provided rule.

Body/Parameters

All

Matches on all HTTP parameters or body (depends on the rule request method defined). For example, if you request /?author=somebody&posts=latest – the rule will attempt to match on the whole body (author=somebody&posts=latest)

Keys

Collection of all body/parameter keys, for example, if you request /?author=somebody&posts=latest – author and posts are the keys. The rule is being checked against each key separately and a match is considered if one of the keys matches provided rule.

Values

Collection of all body/parameter values, for example, if you request /?author=somebody&posts=latest – somebody and latest are the keys. The rule is being checked against each value separately and a match is considered if one of the values matches provided rule.

Key and Value

Collection of all body/parameter keys and values, for example, if you request /?author=somebody&posts=latest – author=somebody and posts=latest are two elements on which rule is being checked separately and a match is considered if one of the elements matches provided rule.

IP Address

Match on IP address accepts single IP (127.0.0.1), CIDR notation (127.0.0.1/24), IP range (127.0.0.1-127.0.0.200) and IP with wildcard (127.0.0.*)

What can you do?

With the latest update, you can create your own web application firewall rules to whitelist, block, log and redirect HTTP/S requests. Single firewall rule can match the regular expression on HTTP request headers, body, URI and IP addresses. For testing firewall regex rules, you can test them at regex101.com with PCRE (PHP) flavor.

Example 1: Block Access to Admin Page

Let’s say we have a login page on /wp-admin URI and we want to block a request which tries to access on that page. It can be blocked by a single regex rule: /(wp-admin)/msi.

1. Enable Match by request headers
2. Under URI field put regex rule: (\/wp-admin(\/?))

Example 2: Restrict Admin Page to Known Users

Considering you already created Block /wp-admin rule from the previous example, we want to allow certain IP addresses to access /wp-admin.

1. Enable Match by request headers and IP address
2. Tick Whitelist checkbox
3. Under URI field put regex rule: (\/wp-admin(\/?))
4. Enter the IP address of a user who you want to allow access to the /wp-admin
5. Create a rule and assign it to a module or a single site

Example 3: Block Web Scraping Bot Based on User-Agent

Very often, web scraping bots are collecting information or searching for vulnerable web application components. Some of them can be identified with specific User-Agent (Python-urllib/2.7) which we can use to block them.

1. Enable match by Request Headers
2. Under key and value header put regex:  /(User-Agent:( +?| ?)Python-urllib\/2.7)/i with /i flag which will make rule case-insensitive.

Example 4: Prevent User Enumeration

By default, WordPress leaves ?author= GET parameter accessible and if you enter an ID of some user you will be redirected to /author/. An attacker could automatically probe IDs and collect all users on the WordPress installation.

We could simply prevent that by blocking GET /?author=<> request.

1. Enable match by body/parameter
2. Select match on GET request method
3. In Body Key and Value input enter the following regex: /(author=[0-9]+)/i which will match the author GET parameter if one or more numeric characters are passed.

Creating custom web application firewall modules with a set of rules

Firewall module is basically a group of both firewall and whitelist rules. For creating a web application firewall module, you need to have at least 1 rule. The module can be assigned to one or more websites and all rules from that module will automatically be attached to a website.

Modules can be created at Firewall Rules Management.

Assigning web application firewall module to a single website

If you wish to assign the module to a single website, open that website from the dashboard and under Firewall Rules you can attach single rules or/and modules.

Assigning web application firewall module to multiple websites at once

If you wish to assign a module to more websites at once, consider creating a website group; for example for all your WordPress websites.

Infinite potential

For more technical webmasters, the new web application firewall engine will introduce a huge amount of opportunities, which for CMS users (such as WordPress) it will remove the need to use multiple security plugins.

Want to see if someone is trying to hack your website?

Try WebARX for free