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

  1. Deploy the Kubernetes exercise
  2. Run the following commands:
    3. copy
    cd deny-rules/exercise/
    copy
    kubectl apply -k .
  3. 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.
      4. 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
      message
      exceptions[].parameter_name.pattern
      "message":"Blocked parameter: \"s=..."
      exceptions: 
  - parameter_name: 
      pattern: ^(?:s)$
    4. Edit Microgateway's configuration file.

      5. 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)$

      6. 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.
      7. 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.
      8. 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>/
    9. The web application should be reachable from the browser.
    10. Watch the logs of the Microgateway pod.
      11. 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)"
    11. 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.

      2. 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 
          ...

      3. 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.
      4. 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.
      5. 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>/
    6. The web application should be reachable from the browser.
    7. Watch the logs of the Microgateway pod.
      8. 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)"
    8. There are no WR-SG-BLOCK log messages being logged even when entering the test strings which previously triggered false positives.
    9. Sending the test string in another parameter than tested before results in a block.

    Cleanup

    1. Delete Kubernetes resources from previously exercises or solutions
    2. Run the following commands:
      3. copy
      kubectl delete all,ing,cm,secrets,pv,pvc,sa,roles,rolebindings,clusterroles,clusterrolebindings -l purpose=microgateway-tutorial
    3. All relevant Kubernetes resources in the namespace have been deleted successfully.