How To Protect Your Kubernetes Cluster with Wallarm – Configuration and Finetuning – part 2 of 3

Wallarm’s Kubernetes Ingress controller is designed to help protect your Kubernetes cluster against cyberattacks.  Its built-in web application firewall (WAF) is capable of detecting and blocking a wide range of common attacks against Kubernetes deployments.

The previous article in this series discussed how to set up Wallarm’s Ingress controller to protect your Kubernetes cluster.  However, there are a few configuration settings that you may need to modify in order to ensure optimal protection and performance of the controller.

With any WAF, the ability to allow or block traffic based upon the origin IP address is essential to protecting against sustained attacks.  Wallarm’s Ingress controller has this capability; however, after deploying the controller, it may be necessary to modify the configuration to meet the needs of your particular infrastructure.

Ensuring Proper IP Address Reporting

By default, Wallarm’s Ingress controller assumes that it is directly connected to the client.  However, this may not be true in a production setting as multiple controllers can be deployed behind a load balancer to ensure application availability.

If the Wallarm Ingress controller is located behind a load balancer, it will report the IP address of the load balancer as that of the end user.  This is not ideal since it means that placing an IP-based block on traffic will affect all inbound connections.

This issue can be corrected, but the approach can depend on the type of load balancer in use.

Passing the Real Client IP on the Network Layer

Open the value.yml file attribute.  Modify it to set the controller.service.externalTrafficPolicy to the value "Local" as shown below.

controller:
    service:
        externalTrafficPolicy: "Local"

Taking the End-User IP Address from the X-FORWARDED-FOR HTTP Request Header

This approach applies if the cloud service is using an external CDN service such as Cloudflare or Fastly.  To use this technique, first configure the load balancer to pass the IP address of the end-user in an HTTP header named X-FORWARDED-FOR. Then, open the Helm chart file named values.yml and set controller.config.use-forwarded-headers to true as shown below.

controller:
    config:
        use-forwarded-headers: "true"

Blocking Malicious IP Addresses

Wallarm’s Ingress controller is capable of blocking traffic from suspicious or malicious IP addresses.  Blocking is performed based upon the following conditions:

• An IP address is blocked for an hour after three attempted attacks from that IP address are observed
• IP address blocks are extended if additional attack traffic is observed from that IP address

The default installation of the Wallarm Ingress controller does not have IP address blocking turned on.  However, turning it on is a good idea since it provides protection against brute-force password attacks, path traversal attacks, and forced browsing.

To enable IP blocking functionality in Wallarm’s Ingress controller, perform the following steps:

1. Upgrade Wallarm Ingress controller Helm chart to version 1.7.0 or later from the Github repository (including the values.yaml file)
2. Modify the updated Helm chart file ingress-chart/wallarm-ingress/values.yaml to set the value of controller.wallarm.acl.enabled to true as shown below.

3. controller:
       wallarm:
           acl:
               enabled: true

3. Apply updates by running the command helm upgrade INGRESS_CONTROLLER_NAME VALUES_YAML_FOLDER --reuse-valuesdf
   • INGRESS_CONTROLLER_NAME should replaced with the name of the existing Wallarm Ingress controller
   • VALUES_YAML_FOLDER is the path to the folder with the updated version of values.yaml

4. Enable IP blocking functionality by running the command kubectl annotate ingress YOUR_INGRESS_NAME nginx.ingress.kubernetes.io/wallarm-acl=on

• YOUR_INGRESS_NAME is the name of your Ingress.
• The functionality can be disabled by running the same command with on replaced with off

At this point, Wallarm’s IP blocking functionality is enabled.  The list of blocked IP addresses can be managed via the user interface in your Wallarm account.  This enables you to manually specify IP addresses that should be blocked - in order to enforce corporate policies or protect against cyber threats -  or to remove IP addresses that have been accidentally added to the blocklist - such as corporate vulnerability scanners and other security solutions.

Whitelisting Trusted IP Addresses

Wallarm’s Ingress Controller is designed to block any IP address that is sending malicious traffic to protected systems.  This is a problem if an organization is using vulnerability scanners or similar security products that send malicious traffic to test for the existence of a vulnerability or if a patch has been correctly applied.

Wallarm’s vulnerability scanners are an example of trusted systems that are likely to be incorrectly blocked by the Wallarm Ingress controller.  To prevent this from happening, take the following steps:

1. Modify the values.yml file as shown below.  Add the IP addresses of any other trusted  systems that may be sending attack traffic to your Kubernetes cluster as part of security testing.

   controller:
     config:
       use-forwarded-headers: "true"
       http-snippet: |
         geo $remote_addr $wallarm_mode_real {
           default block; # default filter node mode: off to disable request processing, monitoring to process but not block requests, block to process all requests and block the malicious ones
           # IP addresses and rules for US Cloud scanners
           104.237.151.202 off;104.237.155.105 off;172.104.208.113 off;172.104.21.210 off;172.104.22.150 off;173.255.193.92 off;192.155.82.205 off;192.155.92.134 off;192.81.135.28 off;23.239.30.236 off;23.239.4.41 off;23.92.30.204 off;34.94.218.5 off;35.236.1.4 off;35.236.118.146 off;35.236.20.89 off;45.33.15.249 off;45.33.16.32 off;45.33.43.225 off;45.33.65.37 off;45.33.79.18 off;45.33.86.254 off;45.56.113.41 off;45.56.114.24 off;45.56.122.184 off;45.56.71.221 off;45.56.72.191 off;45.79.10.15 off;45.79.115.178 off;45.79.143.18 off;45.79.186.159 off;45.79.194.128 off;45.79.216.187 off;45.79.75.59 off;45.79.75.91 off;45.79.93.164 off;50.116.11.251 off;50.116.42.181 off;66.175.222.237 off;69.164.202.55 off;72.14.184.100 off;74.207.237.202 off;96.126.124.141 off;96.126.127.23 off;88.80.188.20 off;198.58.123.222 off;192.155.84.216 off;23.92.18.193 off;23.92.18.191 off;170.187.207.244 off;198.58.123.201 off;192.155.84.159 off;88.80.188.16 off;170.187.207.246 off;
           # IP addresses and rules for European Cloud scanners
           104.200.29.36 off;104.237.151.23 off;139.162.130.123 off;139.162.130.66 off;139.162.132.87 off;139.162.144.202 off;139.162.145.238 off;139.162.146.245 off;139.162.151.10 off;139.162.151.155 off;139.162.153.16 off;139.162.156.102 off;139.162.157.131 off;139.162.158.79 off;139.162.159.137 off;139.162.159.244 off;139.162.162.71 off;139.162.163.61 off;139.162.164.41 off;139.162.166.202 off;139.162.167.19 off;139.162.167.48 off;139.162.167.51 off;139.162.168.17 off;139.162.170.84 off;139.162.171.141 off;139.162.171.208 off;139.162.172.35 off;139.162.174.220 off;139.162.174.26 off;139.162.175.71 off;139.162.176.169 off;139.162.177.83 off;139.162.178.148 off;139.162.179.214 off;139.162.180.37 off;139.162.182.156 off;139.162.182.20 off;139.162.184.225 off;139.162.184.33 off;139.162.185.243 off;139.162.186.129 off;139.162.186.136 off;139.162.187.138 off;139.162.188.246 off;139.162.190.165 off;139.162.190.22 off;139.162.190.86 off;139.162.191.89 off;172.104.128.103 off;172.104.128.67 off;172.104.139.37 off;172.104.146.90 off;172.104.150.243 off;172.104.151.59 off;172.104.152.244 off;172.104.152.28 off;172.104.152.96 off;172.104.154.128 off;172.104.157.26 off;172.104.229.59 off;172.104.233.100 off;172.104.240.115 off;172.104.241.162 off;172.104.250.27 off;172.104.252.112 off;172.105.64.135 off;172.105.65.182 off;173.230.130.253 off;173.230.138.206 off;173.230.156.200 off;173.230.158.207 off;173.255.192.83 off;173.255.200.80 off;173.255.214.180 off;23.239.11.21 off;23.92.18.13 off;34.90.114.30 off;34.91.133.93 off;34.91.54.247 off;35.204.60.30 off;45.33.105.35 off;45.33.115.7 off;45.33.33.19 off;45.33.41.31 off;45.33.64.71 off;45.33.72.81 off;45.33.73.43 off;45.33.80.65 off;45.33.81.109 off;45.33.88.42 off;45.33.97.86 off;45.33.98.89 off;45.56.102.9 off;45.56.104.7 off;45.56.119.39 off;45.56.69.211 off;45.79.16.240 off;50.116.23.110 off;50.116.35.43 off;50.116.43.110 off;66.228.58.101 off;72.14.181.105 off;72.14.191.76 off;85.90.246.120 off;85.90.246.49 off;
           }

2. Open the configuration file of the associated Ingress resource and modify as shown below to set the value of nginx.ingress.kubernetes.io/wallarm-mode to "$wallarm_mode_real".
   

   apiVersion: extensions/v1beta1
       kind: Ingress
       metadata:
           annotations:
               nginx.ingress.kubernetes.io/wallarm-mode: "$wallarm_mode_real"

3. Apply the updated configuration settings of the Ingress controller and resource.

At this point, your security solutions should not be blocked by the Wallarm Ingress controller.  To test this, it is a good idea to run a security scan against your Kubernetes cluster and verify that the scan is successful and that none of the scanning IP addresses have been blocked by the controller.

Deploying Wallarm Ingress Controller in Production

After completing the steps described in this and the previous article in this series, you should have a fully-functional Wallarm Ingress controller protecting your Kubernetes cluster.  This controller is capable of identifying a range of potential attacks and blocking the IP addresses of identified malicious nodes.

Before deploying the Wallarm Ingress controller in a production environment, it is important to consider its potential impacts on the availability of the services hosted within your Kubernetes cluster.  The final blog in this three-part series discusses slight modifications to the configuration of the Wallarm Ingress controller that can improve its performance on mission-critical systems.