Deny rules

Overview

Goal	The protected backend has some text fields in HTML forms where user input could lead to false-positives. Because of that, the Microgateway configuration must be extended with deny rule exceptions.
Notes	The purpose of the test strings in this exercise is to trigger a deny rule. Therefore, the request is blocked and you can practise how to configure deny rule exceptions. In real life, ensure that there is no vulnerability in the backend application where you configure deny rule exceptions.

Preparation

Deploy the Kubernetes exercise
1.
Run the following commands:

copy

cd deny-rules/exercise/

copy

kubectl apply -k .

The exercise has been deployed successfully.

The exercise does not contain any licenses. Therefore, Airlock Microgateway runs as Community Edition

For more details see Features and support.

To run the exercise as Premium Edition, copy a valid license to .templates/microgateway/secret/microgateway.lic and execute kubectl apply -k . to re-deploy the Microgateway.

Test strings

The table below lists test strings to trigger deny rules in a particular deny rule group:

Deny rule Group	Test string
SQL Injection in Parameter Value	copy ' or 1=1--
Cross-Site Scripting (XSS) in Parameter Value	copy <script>alert('xss')</script>

Instruction part 1 - Adapt the configuration to prevent false-positives on the Contact page

1.
Connect to the website:

●
Open the URL in your browser: https://<MINIKUBE_IP>/

2.
Use the test strings to trigger false-positives in the following HTML fields:

●
Search, in the top right corner
●
After clicking on No Comments in the fields:

●
Comment
●
Name

●
The HTML form to leave a comment also contains the fields Email and Website. Since the format of an email address or an URL is very clear, it is nearly impossible to have a false-positive there. Therefore, we recommend not to configure a deny rule exception, to achieve best security.

3.
Watch the logs of the Microgateway pod.

details...

Check the logs of the Microgateway configbuilder.

copy

kubectl logs -l app=microgateway -c configbuilder -f

Follow the logs of the Microgateway runtime container.

copy

kubectl logs -l app=microgateway -c microgateway -f

Follow the logs of the Microgateway runtime container and filter for interesting log messages. Mainly these are the log messages with the log_id WR-SG-SUMMARY and WR-SG-BLOCK. Under some circumstances, WR-SG-REJECT or WR-SG-BACK is also very interesting.

copy

kubectl logs -l app=microgateway -c microgateway -f | grep -iE "WR-SG-(SUMMARY|BLOCK|REJECT|BACK)"

details...

The following should be noticed:
●
The requests are not blocked because the Microgateway is configured for log_only mode.

deny_rule_groups[].log_only: true

●
The log key "th_mode":"NOTIFY" in the log message WR-SG-BLOCK confirms the log_only mode.
●
The log message WR-SG-BLOCKDET-* is logged because the Microgateway is configured with integration mode.

operational_mode: integration

Request Summary log messages are always a good source of information and could be helpful to compose a deny rule exception. The table below shows how to combine the log information with the corresponding DSL setting to compose a deny rule exception.

Request summary log messages are always a good source of information and could be helpful to compose a deny rule exception. The table below shows how to combine the log information with the corresponding DSL setting to compose a deny rule exception.

Log message id	Log key	DSL key	Example log message	Example DSL config
WR-SG-SUMMARY	entry_path	exceptions[].path.pattern	"entry_path":"/"	exceptions: - path: pattern: ^/$
WR-SG-BLOCKDET-*	rule_group_key	rule_group_keys[]	"rule_group_key":"SQLI_PARAM_VALUE"	- rule_group_keys: - SQLI_PARAM_VALUE
WR-SG-BLOCKDET-*	message	exceptions[].parameter_name.pattern	"message":"Blocked parameter: \"s=..."	exceptions: - parameter_name: pattern: ^(?:s)$

4.
Edit Microgateway's configuration file.

Edit the file config/config.yaml and configure the following settings:

For the mapping wordpress:
●
deny_rule_groups[].rule_group_keys[]
●
deny_rule_groups[].exceptions[]

Use the (Microgateway) DSL reference to accomplish this task.

details...

The modified part of the config.yaml looks as follow:

copy

    mappings: 
      - name: wordpress 
        entry_path: 
          value: / 
        ... 
        deny_rule_groups: 
          - log_only: true 
          # Exceptions for the comment form 
          - rule_group_keys: 
              - SQLI_PARAM_VALUE 
              - XSS_PARAM_VALUE
              - HTML_PARAM_VALUE  
              - UNIXCMD_PARAM_VALUE 
            exceptions: 
              - path: 
                  pattern: ^/wp-comments-post.php$ 
                parameter_name: 
                  pattern: ^(?:comment|author)$ 
          # Exceptions for the search field 
          - rule_group_keys: 
              - SQLI_PARAM_VALUE 
              - XSS_PARAM_VALUE 
              - HTML_PARAM_VALUE 
              - UNIXCMD_PARAM_VALUE 
            exceptions: 
              - path: 
                  pattern: ^/$ 
                parameter_name: 
                  pattern: ^(?:s)$

5.
Apply the new configuration.

After modifying the configuration file, apply the new configuration by running the following command:

copy

kubectl apply -k .

6.
Deploy the Microgateway with the new configuration.

details...

copy

kubectl rollout restart deployment/microgateway

A running Microgateway does not automatically reload the new configmap. The existing Microgatway pod must be killed. This way a new pod is deployed with the adapted configuration.

7.
Check the status of the Microgateway pod.

details...

List the Microgateway pods:

copy

kubectl get pod

copy

kubectl get pod -l app=microgateway

Show Microgateway pod details:

copy

kubectl describe pod -l app=microgateway

Once the pod is ready to process requests, the output of the kubectl describe command shows that the pod is ready.

...
   Conditions: 
  Type              Status 
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True
...

8.
Connect to the website:

●
Open the URL in your browser: https://<MINIKUBE_IP>/

The web application should be reachable from the browser.
9.
Watch the logs of the Microgateway pod.

details...

Check the logs of the Microgateway configbuilder.

copy

kubectl logs -l app=microgateway -c configbuilder -f

Follow the logs of the Microgateway runtime container.

copy

kubectl logs -l app=microgateway -c microgateway -f

copy

kubectl logs -l app=microgateway -c microgateway -f | grep -iE "WR-SG-(SUMMARY|BLOCK|REJECT|BACK)"

There are no WR-SG-BLOCK log messages being logged even when entering the test strings which previously triggered false positives.

Instruction part 2 - Switch off the log only mode in the configuration

1.
Edit Microgateway's configuration file.

Edit the file config/config.yaml and configure the following settings:

For the mapping wordpress:
●
deny_rule_groups[].log_only: false

Use the (Microgateway) DSL reference to accomplish this task.

details...

The modified part of the config.yaml looks as follow:

copy

    mappings: 
      - name: wordpress 
        entry_path: 
          value: / 
        ... 
        deny_rule_groups: 
          - log_only: false 
          ...

2.
Apply the new configuration.

After modifying the configuration file, apply the new configuration by running the following command:

copy

kubectl apply -k .

3.
Deploy the Microgateway with the new configuration.

details...

copy

kubectl rollout restart deployment/microgateway

A running Microgateway does not automatically reload the new configmap. The existing Microgatway pod must be killed. This way a new pod is deployed with the adapted configuration.

4.
Check the status of the Microgateway pod.

details...

List the Microgateway pods:

copy

kubectl get pod

copy

kubectl get pod -l app=microgateway

Show Microgateway pod details:

copy

kubectl describe pod -l app=microgateway

Once the pod is ready to process requests, the output of the kubectl describe command shows that the pod is ready.

...
   Conditions: 
  Type              Status 
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True
...

5.
Connect to the website:

●
Open the URL in your browser: https://<MINIKUBE_IP>/

The web application should be reachable from the browser.
6.
Watch the logs of the Microgateway pod.

details...

Check the logs of the Microgateway configbuilder.

copy

kubectl logs -l app=microgateway -c configbuilder -f

Follow the logs of the Microgateway runtime container.

copy

kubectl logs -l app=microgateway -c microgateway -f

copy

kubectl logs -l app=microgateway -c microgateway -f | grep -iE "WR-SG-(SUMMARY|BLOCK|REJECT|BACK)"

There are no WR-SG-BLOCK log messages being logged even when entering the test strings which previously triggered false positives.
Sending the test string in another parameter than tested before results in a block.

Cleanup

Delete Kubernetes resources from previously exercises or solutions
1.
Run the following commands:

copy

kubectl delete all,ing,cm,secrets,pv,pvc,sa,roles,rolebindings,clusterroles,clusterrolebindings -l purpose=microgateway-tutorial

All relevant Kubernetes resources in the namespace have been deleted successfully.

Overview

Preparation

Test strings

Instruction part 1 - Adapt the configuration to prevent false-positives on the Contact page

Instruction part 2 - Switch off the log only mode in the configuration

Cleanup

Further information and links