February 26, 2019 by Agnes Talalaev
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.
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.
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.
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:
Read more about what is virtual patching here.
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.
We also provide the ability to match the defined request method. Currently available options are
The most simple form of matching. It will seek for a match on request URI, such
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
Matches on all HTTP headers separated by new line.
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.
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.
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 (
Collection of all body/parameter keys, for example, if you request
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.
Collection of all body/parameter values, for example, if you request
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
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.*)
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.
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:
Considering you already created
Block /wp-admin rule from the previous example, we want to allow certain IP addresses to access
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.
/(User-Agent:( +?| ?)Python-urllib\/2.7)/iwith /i flag which will make rule case-insensitive.
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.
Body Key and Valueinput enter the following regex:
/(author=[0-9]+)/iwhich will match the author GET parameter if one or more numeric characters are passed.
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.
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.
If you wish to assign a module to more websites at once, consider creating a website group; for example for all your WordPress websites.
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.
Protect your websites from malicious traffic - set-up in under 3 minutes.
WebARX is compatible with the following platforms: