Set Up WAF KEMP in ServerStadium Part 2

INTRODUCTION

Hello! Still discussing about WAF KEMP; now let’s continue to add setup some WAF rules on the SubVS of virtual services.

Kemp Web Application Firewall (WAF) services are natively integrated into the Kemp LoadMaster. This enables secure deployment of web applications, preventing Layer 7 attacks while maintaining core load balancing services and ensuring superior application delivery and security. WAF functionality directly augments the LoadMaster’s existing security features to create a layered defense for web applications – enabling safe, compliant, and productive use of published services.

WAF KEMP DEFAULT RULES

KEMP WAF has default rules that update daily.

This setting can be found at Web Application Firewall > Access Settings.

WAF KEMP CUSTOM RULES

You can also write and upload your own custom rules if required.

With the WAF-enabled LoadMaster, you can choose whether to use Kemp-provided rules, custom rules which can be uploaded, or a combination of both.

The writing in WAF KEMP has a similar syntax to ModSec writing rules.

The ModSecurity Reference Manual should be consulted in any cases where questions arise relating to the syntax of commands: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual

After writing some custom rules, you can upload them to KEMP through the following menu.

Web Application Firewall > Custom Rules > Browse > Add Ruleset

WAF KEMP DEMO

I’ve added some rules that block access from my device IP. The rules syntax is as the following:

SecRule REMOTE_ADDR "@ipMatch 125.164.9.70" \
id:99999,phase:1,t:none,log,deny,ctl:ruleEngine=off

If the rule is applied to the SubVs, my device will get an Access denied message from accessing the website.

Now go to Virtual Services > your 443 or 80 Virtual IP Address > your SubVSs > Modify

To enable the WAF rules, check the Enabled box on the WAF panel.

To apply the BLOCK-IP.conf WAF custom rule, just scroll down the rules on the Manage Rules column, check the BLOCK-IP rules, and apply them to the SubVs.

Here is the result before and after the rules, applied to the SubVs.

Before applying the rule

After applying the rule

You can also inspect the WAF Event log to see if the rule is read by the system.

2022-04-09T19:28:51+00:00 lb100 wafd: [client 125.164.9.70] ModSecurity: Access denied with code 403 (phase 1). IPmatch: “125.164.9.70” matched at REMOTE_ADDR. [file “/tmp/waf/6/BLOCK-IP.conf”] [line “2”] [id “99999”] [hostname “6.5 (subahmadcloud)”] [uri “/”] [unique_id “dce9c392-cd01-490f-adaf-755c64e3242a”] 2022-04-09T19:28:52+00:00 lb100 wafd: [client 125.164.9.70] ModSecurity: Access denied with code 403 (phase 1). IPmatch: “125.164.9.70” matched at REMOTE_ADDR. [file “/tmp/waf/6/BLOCK-IP.conf”] [line “2”] [id “99999”] [hostname “6.5 (subahmadcloud)”] [uri “/”] [unique_id “c19d2e9e-c2c5-4c35-a6fc-c63235f5eb35”] 2022-04-09T19:35:28+00:00 lb100 wafd: [client 125.164.9.70] ModSecurity: Access denied with code 403 (phase 1). IPmatch: “125.164.9.70” matched at REMOTE_ADDR. [file “/tmp/waf/6/BLOCK-IP.conf”] [line “2”] [id “99999”] [hostname “6.5 (subahmadcloud)”] [uri “/”] [unique_id “87c30379-753d-4632-8e86-48256ce6dc44”] 2022-04-09T19:35:29+00:00 lb100 wafd: [client 125.164.9.70] ModSecurity: Access denied with code 403 (phase 1). IPmatch: “125.164.9.70” matched at REMOTE_ADDR. [file “/tmp/waf/6/BLOCK-IP.conf”] [line “2”] [id “99999”] [hostname “6.5 (subahmadcloud)”] [uri “/”] [unique_id “a507ea93-eec2-41d1-9532-4978db0f06c7”]

CONCLUSION

Though it is a long work process, it is still worth starting with. If you miss part 1, please read it here.