How Cloud Native Gateway Realizes Security Protection Capabilities

Cloud native gateway: three-in-one security, traffic and microservices

As a north-south oriented public network gateway, it is a common requirement to use Waf to protect abnormal traffic, and as the Internet environment becomes more and more complex, users' demand for protection continues to increase. The conventional method is to first access the traffic The Waf security gateway, after filtering, forwards the traffic to the traffic gateway, and finally reaches the microservice gateway. A typical multi-layer gateway architecture is shown in the following figure:

In this architecture, the WAF gateway is used to realize the security capability, the Ingress gateway realizes the cluster entrance gateway capability (a layer of Nginx may be deployed in non-K8s scenarios), and the SCG (Spring Cloud Gateway) realizes the microservice gateway capability. Under such an architecture, it is necessary to evaluate the capacity of each layer of gateways. Each layer of gateways is a potential bottleneck point and may need to be expanded. The resource cost and operation and maintenance labor cost caused by this are huge. And with every additional layer of gateways comes an additional layer of availability risk. Once an availability problem occurs, the multi-layer gateway will lead to a significant increase in the complexity of problem location, and the corresponding mean time to recovery (MTTR) will increase significantly.

The cloud-native gateway proposes the concept of combining security, traffic, and microservice gateways into one. The architecture is shown in the following figure:

Adopting the three-in-one architecture of the cloud-native gateway can significantly reduce costs and improve the overall availability of the system. At the same time, this is also in line with the microservice evolution trend of DevSecOps. Microservice developers can pay more attention to security from the perspective of business interfaces, instead of adopting a one-size-fits-all WAF protection mode for all routes.

The evolution process of the cloud-native gateway technology architecture is shown in the following figure:

Behind the evolution of technical architecture is the evolution of organizational architecture, which is also what microservice DevOps has been emphasizing. It should focus on developers to improve the efficiency of microservice development. There is no shortcut to the evolution to DevSecOps. It still requires two-way running between development roles and operation and maintenance roles, breaking the barriers between traditional development and operation and maintenance, and forming a full-featured agile team from development, deployment, and security operations.

Cloud native gateway security protection practice

The cloud-native gateway provides security capabilities in the form of WAF plug-ins, implements a ModSecurity-based rule protection engine, can block suspicious requests according to user-configured rules, and supports OWASP CRS to provide basic protection functions for sites.

Plug-in configuration instructions

The plug-in is easy to use and supports fine-grained protection at the route level/domain name level. The configuration fields include:

name	type of data	fill in the request	Defaults	describe
useCRS	bool	optional	false	Whether to enable OWASP CRS, please refer to coreruleset[1] for details
secRules	array of string	optional	-	User-defined waf protection rules, syntax rules can refer to ModSecurity Chinese manual [2]

The configuration example is as follows:

1. Enable the default configuration to intercept

useCRS: true

2. Enable the default configuration, only observe, not intercept

useCRS: true
secRules:
  - "SecRuleEngine DetectionOnly"

3. Customize protection rules

useCRS: true
secRules: 
  - "SecRule REQUEST_URI \"@streq /admin\" \"id:101,phase:1,t:lowercase,deny\""
  - "SecRule REQUEST_BODY \"@rx maliciouspayload\" \"id:102,phase:2,t:lowercase,deny\""

According to this configuration, the following requests will be denied access:

curl http://example.com/admin
curl http://example.com -d "maliciouspayload"

4. Enable for specific routes or domain names

useCRS: true
secRules: 
  - "SecRule REQUEST_URI \"@streq /admin\" \"id:101,phase:1,t:lowercase,deny\""
  - "SecRule REQUEST_BODY \"@rx maliciouspayload\" \"id:102,phase:2,t:lowercase,deny\""
_rules_:
- _match_route_:
    - "route-1"
  secRules:
    - "SecAction \"id:102,phase:1,deny\""
- _match_domain_:
    - "*.example.com"
    - test.com
  secRules:
    - "SecAction \"id:102,phase:1,pass\""

The route-1 specified in _match_route_ in this example is the route name filled in when creating the gateway route. When these two routes are matched, this configuration will be used; the *.http://example specified in _match_domain_ in this example .com and http://test.com are used to match the domain name of the request. When the domain name is found to match, this configuration will be used; the matching order of the configuration will be in accordance with the order of the rules under _rules_, matching the first rule After the corresponding configuration takes effect, subsequent rules will be ignored.

open plugin

Select a gateway instance, click on the plug-in market, search for waf, and click to enter the plug-in configuration interface:

Fill in the WAF protection rules in the console and start the WAF plug-in:

You can view the log generated by the plug-in in the plug-in log column (the following figure shows the log generated by the WAF plug-in during a shell injection attack):

Offensive and defensive example

Send a simple web attack request to the gateway, the example is as follows:

1. Example of shell injection attack and defense

2. SQL injection attack and defense example

3. Example of remote file inclusion (RFI) attack and defense

4. Example of xss attack and defense

5. PHP injection attack and defense example

Overall Defense Capability Assessment

GoTestWAF [3] is an API and OWASP attack simulation tool that supports multiple API protocols including REST, GraphQL, gRPC, WebSockets, SOAP, XMLRPC, etc., and aims to evaluate web application security solutions, such as API security proxy, web application firewall (WAF), IPS, API Gateway, etc. The tool uses encoded payloads placed in different parts of HTTP requests to generate malicious requests: its body, headers, URL parameters, etc., covering various common attack types. The test results of various attacks are shown in the figure below. The test results show that WAF The plug-in can effectively detect illegal requests of various attack types.

GoTestWAF provides four benchmarks based on ModSecurity. In the benchmark, paranoia represents the protection level. The larger the value, the higher the protection level and the higher the overall score. The overall score of the WAF plug-in is 74.1, surpassing the benchmark with the highest protection level, indicating that the plug-in has good protection capabilities.

Alibaba Cloud Web Application Firewall

The free WAF plug-in provided by the cloud-native gateway only supports basic protection rules. If you have higher protection requirements, you can choose Alibaba Cloud Web Application Firewall [4] . In addition to having higher protection capabilities and higher performance , and can purchase an insurance policy for your application.

Protection rules can be managed on the WAF console [5] :