Communication system and communication method

Abstract

The application provides a communication system and a communication method. The communication system is applied to a WAF cluster, and the WAF cluster comprises a SaaS WAF management platform, an LB node and a plurality of WAF nodes. The SaaS WAF management platform is used for receiving a start SaaS service request input by a user, the start SaaS service request comprising a public network address to be protected and a protection bandwidth; and sending a first configuration file to the LB node, the first configuration file comprising a first sub-configuration file. The LB node is used for receiving the first configuration file sent by the SaaS WAF management platform, and obtaining the first sub-configuration file from the first configuration file; and configuring a virtual service and QoS of the virtual service locally according to the first sub-configuration file, the virtual service comprising the public network address to be protected, and the QoS comprising the protection bandwidth; wherein the virtual service is used for enabling the LB node to forward service traffic to the corresponding plurality of WAF nodes after the service traffic reaches the LB node.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a communication system and communication method. Background Technology

[0002] Web Application Firewall (WAF) service is an indispensable basic service for cloud services and one of the fundamental services required for compliance with information security standards. Currently, both public and private clouds are required to provide WAF services.

[0003] Cloud-based WAF services include two modes: image mode and cloud WAF mode. Currently, cloud WAF services are more prevalent in this mode. In cloud WAF mode, business traffic accessing a domain name is redirected to the cloud WAF by modifying the domain name. The cloud WAF then forwards the cleaned and protected business traffic to the web application.

[0004] Taking the domain name www.xxx.com as an example, before connecting to the cloud WAF service, the DNS resolution recorded within the switch directly maps the domain name to its public IP address, i.e., www.xxx.com -- 180.101.50.242. After the switch connects to the cloud WAF mode, the user adds the protected domain name (www.xxx.com) in the Web Application Firewall and sets the origin information (e.g., the switch address). The Web Application Firewall assigns a unique CNAME address to this protected domain name (e.g., www.a.yyy.com). This CNAME address can forward received business traffic to the protected domain name, i.e., www.a.yyy.com -- 180.101.50.242. Simultaneously, the user modifies the previously recorded DNS resolution (www.xxx.com -- 180.101.50.242) within the switch to a mapping relationship with the CNAME address, i.e., www.xxx.com -- www.a.yyy.com. Using the CANME address, the switch first redirects traffic accessing the protected domain to the Web Application Firewall (WAF). After performing malicious detection and cleaning on the traffic accessing the protected domain, the WAF redirects legitimate traffic back to the origin server based on the origin information, thus protecting web application security.

[0005] However, the existing cloud WAF model also exposes the following defects: 1) Users need to manually modify the DNS resolution previously recorded in the switch and redirect traffic, which is complicated, difficult to automate, and has a delay. Generally, DNS resolution modifications take 10 minutes to take effect; 2) If a hacker knows the public IP address of the original web application, they can directly bypass the cloud WAF model and access it, failing to protect the web application. Summary of the Invention

[0006] In view of this, this application provides a communication system and communication method to solve the problems of manually modifying DNS resolution, traffic redirection, latency, and bypassing cloud WAF mode access in existing cloud WAF modes.

[0007] In a first aspect, this application provides a communication system applied to a WAF cluster, the WAF cluster including a SaaS WAF management platform, a LB node, and multiple WAF nodes;

[0008] The SaaS WAF management platform is used to receive a user's request to start a SaaS service, the request including the public IP address to be protected and the protection bandwidth; and to send a first configuration file to the LB node, the first configuration file including a first sub-configuration file;

[0009] The LB node is used to receive the first configuration file sent by the SaaS WAF management platform, and obtain the first sub-configuration file from the first configuration file; configure the virtual service and the QoS of the virtual service locally according to the first sub-configuration file, wherein the virtual service includes the public network address to be protected, and the QoS includes the protection bandwidth;

[0010] The virtual service is used to ensure that after the service traffic reaches the LB node, the LB node forwards the service traffic to the corresponding multiple WAF nodes.

[0011] Secondly, this application provides a communication method applied to a SaaS WAF management platform, wherein the SaaS WAF management platform is located within a WAF cluster, and the WAF cluster further includes a load balancer node and multiple WAF nodes, the method comprising:

[0012] Receive a user's request to start a SaaS service, the request including the public IP address to be protected and the protection bandwidth;

[0013] Send a first configuration file to the LB node, the first configuration file including a first sub-configuration file, so that the LB node configures the virtual service and the QoS of the virtual service locally according to the first sub-configuration file, the virtual service including the public network address to be protected, and the QoS including the protection bandwidth;

[0014] The virtual service is used to ensure that after the service traffic reaches the LB node, the LB node forwards the service traffic to the corresponding multiple WAF nodes.

[0015] Therefore, using the communication system and method provided in this application, the SaaS WAF management platform is used to receive a user-input request to start a SaaS service, which includes the public IP address to be protected and the protection bandwidth; send a first configuration file to the LB node, which includes a first sub-configuration file; the LB node is used to receive the first configuration file sent by the SaaS WAF management platform and obtain the first sub-configuration file from the first configuration file; configure virtual services and the QoS of virtual services locally according to the first sub-configuration file, whereby the virtual service includes the public IP address to be protected and the QoS includes the protection bandwidth; wherein, the virtual service is used to enable the LB node to forward the service traffic to multiple corresponding WAF nodes after the service traffic reaches the LB node.

[0016] Thus, by utilizing the SaaS WAF management platform, LB nodes, and multiple WAF nodes within the WAF cluster, business traffic destined for web applications reaching the cloud platform's core switch is protected, thereby protecting cloud platform web applications. This solves the problems of manually modifying DNS resolution, redirecting traffic, adjusting latency, and bypassing cloud WAF access in existing cloud WAF models. Compared to existing mirrored models, the communication method and system provided in this application enable multi-tenant shared use of web application protection, saving resource consumption; compared to existing cloud WAF models, the traffic redirection scheme is simpler and more timely, and also avoids the risks of directly accessing web applications. Attached Figure Description

[0017] Figure 1 A network diagram applicable to communication methods provided for embodiments of this application;

[0018] Figure 2 Signaling diagrams applicable to communication methods provided in embodiments of this application;

[0019] Figure 3 A flowchart illustrating the communication method provided in an embodiment of this application. Detailed Implementation

[0020] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0021] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the corresponding listed items.

[0022] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0023] The communication method provided in the embodiments of this application will be described in detail below. See also... Figure 1 , Figure 1 A network diagram applicable to communication methods provided for embodiments of this application. Figure 2 This includes cloud platforms and WAF clusters.

[0024] The cloud platform connects to the external network (Internet) and includes a core switch (border), access switches (leaf), and multiple servers. Servers can host web applications and provide access interfaces for them. Web applications are various types of applications that provide services to users.

[0025] Deploy a WAF cluster at the cloud platform's egress point. The WAF cluster includes a SaaS WAF management platform, a load balancer (LB) node, and multiple WAF nodes. Figure 2 (This example uses three WAF nodes) and a log node. The SaaS WAF management platform establishes a Netconf connection with the core switch, and the core switch establishes a communication connection with the LB node. The WAF cluster can protect web applications, such as performing malicious detection, attack detection, and cleansing on traffic accessing web applications. After receiving traffic accessing web applications, the core switch redirects the traffic to the WAF cluster. The WAF cluster performs protection processing on the traffic and feeds back the processed traffic to the core switch. The core switch then sends the processed traffic to the server, thus achieving WAF cluster protection for web applications.

[0026] The following is a brief introduction to the SaaS WAF management platform, LB nodes, multiple WAF nodes, and log nodes in the WAF cluster.

[0027] The SaaS WAF management platform provides users with self-service capabilities and WAF cluster resource management capabilities. User self-service capabilities refer to functions such as users being able to select and specify the protection bandwidth of the SaaS service, issue protection policies, view protection logs, skip protection with one click, and manage blacklists and whitelists. Cluster resource management capabilities refer to functions such as managing LB nodes, WAF nodes, log nodes, issuing configuration files to each component, monitoring the running status of each component, and displaying alarm information to users.

[0028] The LB node distributes service traffic to multiple WAF nodes using a load balancing algorithm based on source address hashing.

[0029] The WAF node is used to provide protection for web applications. It connects to the LB node through a transparent proxy mode, configures the public IP address of the web application to be protected and the protection policy locally, and executes the protection policy.

[0030] Log nodes collect a portion of the protection logs from each WAF node and store them categorized by web application.

[0031] In this embodiment of the application, the SaaS WAF management platform is used to receive a user-inputted request to start a SaaS service, the request including the public IP address to be protected and the protection bandwidth; and to send a first configuration file to the LB node, the first configuration file including a first sub-configuration file;

[0032] The LB node is used to receive the first configuration file sent by the SaaS WAF management platform and obtain the first sub-configuration file from the first configuration file; configure the virtual service and the QoS of the virtual service locally according to the first sub-configuration file, wherein the virtual service includes the public network address to be protected and the QoS includes the protection bandwidth; wherein the virtual service is used to enable the LB node to forward the service traffic to the corresponding multiple WAF nodes after the service traffic reaches the LB node.

[0033] For example, the public IP address to be protected could be the public IP address of the web application the user will subsequently access, such as 1.1.1.1; the protection bandwidth could be specifically 50 Mbps. It's understood that the user sends business traffic to the web application through a client. This business traffic includes a source address, a destination address, and a user identifier representing the user. The source address is the client's address; the destination address is the public IP address of the web application being accessed; and the user identifier can be the client's identifier.

[0034] Optionally, the first configuration file may further include a second sub-configuration file;

[0035] The LB node is also used to configure a load balancing algorithm for source address hashing locally according to the second sub-configuration file, and to configure the plurality of WAF nodes locally as real services corresponding to the virtual service;

[0036] The real service is used to protect the business traffic of the web application accessed by the user.

[0037] The second sub-configuration file and the first sub-configuration file can be sent to the LB node together through the first configuration. After the LB node has completed the configuration according to the first sub-configuration file, it can then configure the second sub-configuration file, or they can be configured at the same time.

[0038] Optionally, the SaaS WAF management platform is further configured to send a second configuration file to each of the multiple WAF nodes that provide the actual service, the second configuration file including protection assets, proxy rules and protection policies;

[0039] The WAF node is used to receive the second configuration file and configure the protected assets, proxy rules, and protection policies locally.

[0040] The protected asset is the public IP address to be protected.

[0041] In this embodiment of the application, the SaaS WAF management platform can send a second configuration file to the WAF node after sending the first configuration file to the LB node.

[0042] Optionally, a Netconf connection has been established between the SaaS WAF management platform and the core switch included in the cloud platform;

[0043] The SaaS WAF management platform is also used to send policy routes to the core switch through the Netconf connection, so that the core switch configures the policy routes locally. When the service traffic arrives at the core switch, the core switch forwards the service traffic to the LB node according to the policy routes.

[0044] In the core switch, policy-based routing has a higher priority than ordinary routing entries in the routing table. When the core switch receives service traffic, it first matches the traffic with policy-based routes. If a match is found, the traffic is forwarded to the load balancer (LB) node according to the outgoing interface and next hop specified in the policy-based route.

[0045] Optionally, the WAF cluster also includes log nodes;

[0046] The WAF node is also configured to, when receiving the service traffic and the destination address included in the service traffic is the same as the public network address to be protected indicated by the protection asset, perform protection processing on the service traffic according to the proxy rules and the protection policy, and generate partial protection logs; and transmit the partial protection logs to the log node.

[0047] The log node is used to receive partial protection logs transmitted by each WAF node; and to classify and store multiple partial protection logs according to the protection assets recorded in each partial protection log.

[0048] Optionally, the SaaS WAF management platform is further configured to receive a log viewing request input by the user, wherein the log viewing request includes log attributes;

[0049] Based on the log attributes, matching log information is obtained from the log node, the log information including at least one portion of the protection logs reported by the WAF node to the log node;

[0050] The log attribute is the public IP address to be protected.

[0051] Optionally, the LB node is further configured to receive service traffic sent by the core switch, wherein the destination address of the service traffic is the public network address to be protected; if the local virtual service matches the public network address to be protected, then according to the load balancing algorithm, a hash operation is performed on the source address included in the service traffic, and according to the hash operation result, the service traffic is forwarded to the plurality of WAF nodes corresponding to the virtual service;

[0052] The WAF node is also used to: receive the service traffic; if the destination address included in the service traffic is the same as the public network address to be protected indicated by the protection asset, perform protection processing on the service traffic according to the proxy rules and the protection policy; and send the protected service traffic to the LB node.

[0053] The LB node is also configured to receive the protected service traffic and send the protected service traffic to the core switch, so that the core switch forwards the protected service traffic to the web application indicated by the destination address.

[0054] Thus, by utilizing the SaaS WAF management platform, LB nodes, and multiple WAF nodes within the WAF cluster, business traffic destined for web applications reaching the cloud platform's core switch is protected, thereby protecting cloud platform web applications. This solves the problems of manually modifying DNS resolution, redirecting traffic, adjusting latency, and bypassing cloud WAF access in existing cloud WAF models. Compared to existing mirrored models, the communication method and system provided in this application enable multi-tenant shared use of web application protection, saving resource consumption; compared to existing cloud WAF models, the traffic redirection scheme is simpler and more timely, and also avoids the risks of directly accessing web applications.

[0055] In this embodiment, a user wishes to activate a SaaS service. The user enters the address of the SaaS WAF management platform in the address bar of their browser and accesses the SaaS WAF management platform. After receiving the access request from the user, the SaaS WAF management platform determines that the user wishes to activate the SaaS service and displays the SaaS service activation interface to the user.

[0056] Following the prompts on the SaaS service activation interface, the user enters a request to start the SaaS service again into the SaaS WAF management platform. This request includes the public IP address to be protected and the protection bandwidth. The public IP address to be protected is the public IP address of the web application the user will subsequently access (e.g., 1.1.1.1); the protection bandwidth is one that the user can choose from multiple protection bandwidths displayed on the SaaS service interface, for example, 50M.

[0057] The SaaS service interface displays information including the public IP address to be protected and the protection bandwidth field. The public IP address to be protected field is the address of the web application the user wants protected. The protection bandwidth field can display various options from a dropdown list, such as 20M, 50M, 100M, etc., allowing users to select and enter the appropriate option based on their network needs.

[0058] After receiving a user's request to start the SaaS service, the SaaS WAF management platform obtains the public IP address to be protected and the protection bandwidth from it.

[0059] The SaaS WAF management platform generates a first configuration file. This first configuration file includes a first sub-configuration file and a second sub-configuration file. The first sub-configuration file is used to enable the LB node to configure virtual services and their QoS locally. The second sub-configuration file is used to enable the LB node to configure the load balancing algorithm based on source address hashing locally and to configure the real services corresponding to the virtual services for multiple WAF nodes.

[0060] The SaaS WAF management platform sends the first configuration file to the LB node.

[0061] After receiving the first configuration file, the LB node retrieves a first sub-configuration file and a second sub-configuration file from it. The LB node then creates a virtual service and its QoS locally based on the first sub-configuration file. In this embodiment, the first sub-configuration file includes the public IP address to be protected and the protection bandwidth. The virtual service created locally by the LB node includes the public IP address to be protected, and the QoS includes the protection bandwidth. This virtual service is used so that when service traffic arrives at the LB node, and the LB node determines that the destination address matches the address of the virtual service, it forwards the service traffic to the corresponding multiple WAF nodes without dropping the service traffic.

[0062] When configuring a virtual service, the LB node can configure the public IP address to be protected as the virtual service's IP address. That is, the virtual service's IP address is 1.1.1.1, and the QoS of the virtual service is 50M.

[0063] Simultaneously, the LB node configures a source address hashing load balancing algorithm locally and configures multiple WAF nodes locally as real services corresponding to virtual services. The aforementioned source address hashing load balancing algorithm is used by the LB node to perform hash calculations on the source addresses included in the service traffic after receiving it. Based on the hash calculation result, the service traffic is evenly distributed to multiple WAF nodes to achieve load balancing and improve the performance of the WAF cluster. The real services are used to provide protection for the service traffic of the web applications that users are about to access.

[0064] It's important to note that at the initial setup of the WAF cluster, the LB node, each WAF node, and the log node all send registration messages to the SaaS WAF management platform. This allows the SaaS WAF management platform to determine the attributes of each component within the current WAF cluster. These attributes include, but are not limited to, ID, address, port, and location. When generating the second sub-configuration file, the SaaS WAF management platform includes the attributes of each WAF node in the WAF cluster, enabling the LB node to configure multiple WAF nodes locally as real services corresponding to virtual services.

[0065] In this embodiment of the application, the SaaS WAF management platform typically treats all WAF nodes included in the WAF cluster as the real services corresponding to the virtual services.

[0066] The first configuration file example is as follows:

[0067]

[0068]

[0069] After the SaaS WAF management platform sends the first configuration file to the LB node, it generates and sends a second configuration file to the WAF nodes that provide the actual service (i.e., all WAF nodes included in the current WAF cluster). This second configuration file includes protection assets, proxy rules, and protection policies.

[0070] After receiving the second configuration file, each WAF node will retrieve the protection assets, proxy rules, and protection policies from the second configuration file and configure them locally. The protection assets are the public IP addresses to be protected, such as 1.1.1.1; the proxy rules are used to configure information such as the port and certificate of the web application to be accessed; and the protection policies are specific protection configurations against web attacks.

[0071] The protection strategy includes basic policy attributes and policy configuration details. Basic policy attributes include, but are not limited to, policy name (advanced, medium, low level), application assets, blocking return information, remarks, selected template, etc.; policy configuration details include, but are not limited to, SQL injection protection, feature detection, semantic algorithm detection, processing actions, detection level, feature rules, etc.

[0072] After sending the second configuration file, the SaaS WAF management platform also generates policy routes. Through the Netconf connection, the SaaS WAF management platform sends these policy routes to the core switch.

[0073] After receiving a policy-based route, the core switch configures it locally. When service traffic arrives at the core switch, it first matches the traffic with the policy-based route. If a match is found, the core switch forwards the traffic to the load balancer (LB) node according to the policy-based route. If no match is found, the core switch forwards the traffic using its existing routing table lookup method.

[0074] In this embodiment, policy routing includes information such as matching conditions, outgoing interface, and next hop. Specifically, the matching condition may be the public IP address of the web application to be accessed, for example, 1.1.1.1; the outgoing interface may be the port on which the core switch establishes a communication connection with the load balancer (LB) node; and the next hop may be the address of the LB node.

[0075] like Figure 2 As shown, Figure 2 A signaling diagram applicable to a communication method provided for embodiments of this application. Figure 2In the process, after receiving the public IP address to be protected and the protection bandwidth input by the user, the SaaSWAF management platform generates the first configuration file, the second configuration file, and the policy route, and distributes them to the LB node, each WAF node, and the core switch so that the LB node, each WAF node, and the core switch can perform the corresponding configuration locally.

[0076] After receiving service traffic, the LB node obtains the destination address included in the service traffic, which is the public IP address to be protected. The LB node determines whether the public IP address to be protected matches the address of the local virtual service. If the address of the local virtual service matches the public IP address to be protected, the LB node performs a hash operation on the source address included in the service traffic according to the load balancing algorithm, and forwards the service traffic to multiple WAF nodes corresponding to the virtual service based on the hash operation result.

[0077] After receiving the service traffic, the WAF node determines whether the destination address is the same as the public IP address to be protected as indicated by the protection asset. If the destination address is the same as the public IP address to be protected as indicated by the protection asset, the WAF node performs protection processing on the service traffic according to the proxy rules (e.g., transparent proxy rules, which require authentication with each sub-rule of the transparent proxy rule and successful authentication) and the protection policy; the WAF node then sends the protected service traffic to the LB node.

[0078] After receiving the protected traffic, the LB node sends the protected traffic to the core switch, so that the core switch forwards the protected traffic to the web application indicated by the destination address.

[0079] If a user wants to view the log information of a web application, the user enters a log viewing request into the SaaS WAF management platform. This log viewing request includes log attributes. After receiving the log viewing request, the SaaS WAF management platform retrieves the log attributes from it.

[0080] Based on the log attributes, the SaaS WAF management platform retrieves matching log information from the log nodes. This log information includes partial protection logs reported by at least one WAF node to the log nodes. The SaaS WAF management platform then displays this log information to the user.

[0081] Specifically, the log attribute mentioned above can be the public IP address of the web application.

[0082] The following is a partial example of the protection logs:

[0083] String format:

[0084] <188>time WAF:time WAF:source ip:source port->dest ip dport=%ddevicename=%s url=%s method=%s args=%s flag_field=%s block_time=%dhttp_type=%s attack_field=%d profile_id=%d rule_id=%d type=%sseverity=%saction=%s referer=%s useragent=%s post=%s xip=%s code=%d country=%sprovince=%s equipment=%s os=%s browser=%s|

[0085] Log sample:

[0086] <188>Jun 15 07:10:49WAF:2021-06-15 07:10:49WAF:192.168.123.61:8739->192.168.123.248dport=80devicename=waf url= / bWAPP / login.php / images / netsparker.png method=GET args=flag_field=block_time=0http_type=attack_field=4profile_id=-1rule_id=10type=Web Scan Protection severity=HIGHaction=PASS referer=useragent=post=xip=192.168.123.61code=30090country=province=local area network equipment=PC os=WINDOWS browser=BROWSERCHROME|

[0087] It should be noted that in this embodiment, the SaaS WAF management platform also has a blacklist / whitelist function. The whitelist stores the addresses of trusted clients, while the blacklist stores the addresses of untrusted clients. The SaaS WAF management platform sends the blacklist / whitelist to the core switch via a Netconf connection. When the core switch subsequently receives service traffic from a client in the whitelist, it can allow the traffic directly without forwarding it to the load balancer (LB) node. Similarly, when the core switch subsequently receives service traffic from a client in the blacklist, it can directly block that traffic.

[0088] Of course, the SaaS WAF management platform can also send blacklists and whitelists to the LB nodes instead of the core switch. After receiving service traffic, the core switch sends it to the LB nodes normally. The LB nodes can first match the source addresses included in the service traffic with the blacklists and whitelists. If a match is found in the whitelist, the LB node directly forwards the service traffic to the core switch; if a match is found in the blacklist, the LB node discards the service traffic.

[0089] Understandably, business traffic sent by clients on the blacklist or whitelist will no longer be protected.

[0090] In this embodiment, the SaaS WAF management platform also features a one-click skip function. A skip button is included in the SaaS service activation interface, used to disable Web application protection. After the user clicks this button, the SaaS WAF management platform determines that the service traffic sent by the client used by that user (the user can input a user identifier (e.g., client identifier) ​​so that the SaaS WAF management platform can determine which client's service traffic should not be protected) will no longer be protected. The SaaS WAF management platform generates a one-click skip list and distributes it to the LB node. Upon receiving the service traffic, the core switch forwards it normally to the LB node. The LB node can first match the source address included in the service traffic with the one-click skip list. If a match is found, the LB node directly returns the service traffic to the core switch. The core switch forwards the service traffic according to the existing routing table lookup forwarding method.

[0091] The communication method provided in the embodiments of this application will be described in detail below. See also... Figure 3 , Figure 3 A flowchart illustrating a communication method provided in an embodiment of this application. This method is applied to a SaaS WAF management platform, and the communication method provided in this application embodiment may include the following steps.

[0092] Step 310: Receive a user's request to start the SaaS service, wherein the request to start the SaaS service includes the public IP address to be protected and the protection bandwidth;

[0093] Specifically, a user wants to activate Software as a Service (SaaS). The user enters the address of the SaaS WAF management platform in the address bar of their browser and accesses the SaaS WAF management platform. After receiving the user's access request, the SaaS WAF management platform determines that the user wants to activate the SaaS service and displays the SaaS service activation interface to the user.

[0094] Following the prompts on the SaaS service activation interface, the user enters a request to start the SaaS service again into the SaaS WAF management platform. This request includes the public IP address to be protected and the protection bandwidth. The public IP address to be protected is the public IP address of the web application the user will subsequently access (e.g., 1.1.1.1); the protection bandwidth is one that the user can choose from multiple protection bandwidths displayed on the SaaS service interface, for example, 50M.

[0095] The SaaS service interface displays information including the public IP address to be protected and the protection bandwidth field. The public IP address to be protected field is the address of the web application the user wants protected. The protection bandwidth field can display various options from a dropdown list, such as 20M, 50M, 100M, etc., allowing users to select and enter the appropriate option based on their network needs.

[0096] After receiving a user's request to start the SaaS service, the SaaS WAF management platform obtains the public IP address to be protected and the protection bandwidth from it.

[0097] In this embodiment, the SaaS WAF management platform is located within a WAF cluster. The WAF cluster also includes a load balancer (LB) node and multiple WAF nodes.

[0098] Step 320: Send a first configuration file to the LB node. The first configuration file includes a first sub-configuration file, so that the LB node can configure virtual services and the QoS of the virtual services locally according to the first sub-configuration file. The virtual service includes the public network address to be protected, and the QoS includes the protection bandwidth. The virtual service is used to enable the LB node to forward the service traffic to the corresponding multiple WAF nodes after the service traffic arrives at the LB node.

[0099] Specifically, as described in step 310, after obtaining the public IP address to be protected and the protection bandwidth, the SaaS WAF management platform generates a first configuration file. This first configuration file includes a first sub-configuration file, which in turn includes the public IP address to be protected and the protection bandwidth.

[0100] The SaaS WAF management platform sends the first configuration file to the LB node.

[0101] After receiving the first configuration file, the LB node retrieves the first sub-configuration file from it. The LB node creates a virtual service based on the public IP address to be protected and configures QoS for the virtual service according to the protection bandwidth. This virtual service ensures that when service traffic reaches the LB node, the LB node forwards the traffic to multiple corresponding WAF nodes without dropping the traffic.

[0102] When configuring a virtual service, the LB node can configure the public IP address to be protected as the virtual service's IP address. That is, the virtual service's IP address is 1.1.1.1, and the QoS of the virtual service is 50M.

[0103] Optionally, in this embodiment of the application, the first configuration file generated by the SaaS WAF management platform further includes a second sub-configuration file, which is used to enable the LB node to configure the load balancing algorithm of the source address hash locally, and to configure multiple WAF nodes locally as real services corresponding to virtual services.

[0104] The aforementioned source address hashing load balancing algorithm is used by the LB node to perform hash calculations on the source addresses included in the service traffic after receiving it. Based on the hash calculation results, the service traffic is evenly distributed to multiple WAF nodes to achieve load balancing and improve the performance of the WAF cluster. The actual service is used to provide protection for service traffic to web applications that users are about to access.

[0105] Optionally, in this embodiment of the application, the step of generating a second configuration file by the SaaS WAF management platform is also included.

[0106] Specifically, after obtaining the public IP address to be protected and the protection bandwidth, the SaaS WAF management platform generates a second configuration file. The SaaS WAF management platform then sends this second configuration file to each of the multiple WAF nodes providing the actual service. This second configuration file includes protection assets, proxy rules, and protection policies.

[0107] After receiving the second configuration file, each WAF node configures the protected assets, proxy rules, and protection policies obtained from the second configuration file locally. The protected assets are the public IP addresses to be protected, such as 1.1.1.1; the proxy rules are used to configure the ports, certificates, and other information of the web applications to be accessed; and the protection policies are specific protection configurations against web attacks.

[0108] Optionally, in this embodiment, a Netconf connection has been established between the SaaS WAF management platform and the core switch included in the cloud platform. Through the Netconf connection, the SaaS WAF management platform can send policy routes to the core switch, so that the core switch can redirect service traffic to the LB node.

[0109] Specifically, after obtaining the public IP address to be protected, the protection bandwidth, and the WAF protection policy template selected by the user, the SaaS WAF management platform generates a policy route. Through a Netconf connection, the SaaS WAF management platform sends the policy route to the core switch.

[0110] After receiving a policy-based route, the core switch configures it locally. When service traffic arrives at the core switch, it first matches the traffic with the policy-based route. If a match is found, the core switch forwards the traffic to the load balancer (LB) node according to the policy-based route. If no match is found, the core switch forwards the traffic using the existing table lookup forwarding method.

[0111] In this embodiment, policy routing includes information such as matching conditions, outgoing interface, and next hop. Specifically, the matching condition may be the public IP address of the web application to be accessed, for example, 1.1.1.1; the outgoing interface may be the port on which the core switch establishes a communication connection with the load balancer (LB) node; and the next hop may be the address of the LB node.

[0112] Optionally, in this embodiment of the application, the SaaS WAF management platform can also receive a log viewing request input by the user and provide the user with the corresponding log information.

[0113] Specifically, the WAF cluster also includes log nodes, which are used to acquire and store partial protection logs transmitted by each WAF node, and to categorize and store these logs. It should be noted that because the traffic accessing web applications is distributed to multiple WAF nodes for protection processing by the load balancer (LB) nodes, each WAF node will generate partial protection logs for that web application. Therefore, by adding log nodes to the WAF cluster and using these log nodes to collect, categorize, and store the protection logs for different web applications, users can subsequently view the overall protection effectiveness for a particular web application.

[0114] A user submits a log viewing request to the SaaS WAF management platform, which includes log attributes. Upon receiving the log viewing request, the SaaS WAF management platform retrieves the log attributes from it.

[0115] Based on the log attributes, the SaaS WAF management platform retrieves matching log information from the log nodes. This log information includes partial protection logs reported by at least one WAF node to the log nodes. The SaaS WAF management platform then displays this log information to the user.

[0116] Thus, by utilizing the SaaS WAF management platform, LB nodes, and multiple WAF nodes within the WAF cluster, business traffic destined for web applications reaching the cloud platform's core switch is protected, thereby protecting cloud platform web applications. This solves the problems of manually modifying DNS resolution, redirecting traffic, adjusting latency, and bypassing cloud WAF access in existing cloud WAF models. Compared to existing mirrored models, the communication method and system provided in this application enable multi-tenant shared use of web application protection, saving resource consumption; compared to existing cloud WAF models, the traffic redirection scheme is simpler and more timely, and also avoids the risks of directly accessing web applications.

[0117] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A communication system, characterized in that, The communication system is applied to a WAF cluster, which includes a SaaSWAF management platform, a load balancer node, and multiple WAF nodes. The SaaS WAF management platform is used to receive a user's request to start a SaaS service, the request including the public IP address to be protected and the protection bandwidth; and to send a first configuration file to the LB node, the first configuration file including a first sub-configuration file; The LB node is used to receive the first configuration file sent by the SaaS WAF management platform and obtain the first sub-configuration file from the first configuration file; Configure the virtual service and the QoS of the virtual service locally according to the first sub-configuration file. The virtual service includes the public network address to be protected, and the QoS includes the protection bandwidth. The virtual service is used to ensure that after the service traffic reaches the LB node, the LB node forwards the service traffic to the corresponding multiple WAF nodes. A Netconf connection has been established between the SaaS WAF management platform and the core switches included in the cloud platform. The SaaS WAF management platform is also used to send policy routes to the core switch through the Netconf connection, so that the core switch configures the policy routes locally. When the service traffic arrives at the core switch, the core switch forwards the service traffic to the LB node according to the policy routes. The policy routing includes a destination address and a next hop, wherein the destination address is the public network address to be protected, and the next hop is the address of the LB node.

2. The system according to claim 1, characterized in that, The first configuration file also includes a second sub-configuration file; The LB node is also used to configure a load balancing algorithm for source address hashing locally according to the second sub-configuration file, and to configure the plurality of WAF nodes locally as real services corresponding to the virtual service; The real service is used to protect the business traffic of the web application that the user is about to access.

3. The system according to claim 2, characterized in that, The SaaS WAF management platform is also used to send a second configuration file to each of the multiple WAF nodes that provide the actual service, the second configuration file including protection assets, proxy rules and protection policies; The WAF node is used to receive the second configuration file and configure the protected assets, proxy rules, and protection policies locally. The protected asset is the public IP address to be protected.

4. The system according to claim 3, characterized in that, The WAF cluster also includes log nodes; The WAF node is also configured to, when receiving the service traffic and the destination address included in the service traffic is the same as the public network address to be protected indicated by the protection asset, perform protection processing on the service traffic according to the proxy rules and the protection policy, and generate partial protection logs; and transmit the partial protection logs to the log node. The log node is used to receive partial protection logs transmitted by each WAF node; and to classify and store multiple partial protection logs according to the protection assets recorded in each partial protection log.

5. The system according to claim 4, characterized in that, The SaaS WAF management platform is also used to receive the log viewing request input by the user, the log viewing request including log attributes; Based on the log attributes, matching log information is obtained from the log node, the log information including at least one portion of the protection logs reported by the WAF node to the log node; The log attribute is the public IP address to be protected.

6. The system according to claim 3, characterized in that, The LB node is also used to receive service traffic sent by the core switch of the cloud platform, wherein the destination address of the service traffic is the public network address to be protected; if the local virtual service matches the public network address to be protected, then according to the load balancing algorithm, the source address of the service traffic is hashed, and according to the hash result, the service traffic is forwarded to the multiple WAF nodes corresponding to the virtual service. The WAF node is also used to receive the service traffic; If the destination address included in the service traffic is the same as the public network address to be protected indicated by the protection asset, then the service traffic is protected according to the proxy rules and the protection policy; and the protected service traffic is sent to the LB node. The LB node is also configured to receive the protected service traffic and send the protected service traffic to the core switch, so that the core switch forwards the protected service traffic to the web application indicated by the destination address.

7. A communication method, characterized in that, The method is applied to a SaaS WAF management platform, which is located within a WAF cluster. The WAF cluster also includes a load balancer (LB) node and multiple WAF nodes. The method includes: Receive a user's request to start a SaaS service, the request including the public IP address to be protected and the protection bandwidth; Send a first configuration file to the LB node, the first configuration file including a first sub-configuration file, so that the LB node configures the virtual service and the QoS of the virtual service locally according to the first sub-configuration file, the virtual service including the public network address to be protected, and the QoS including the protection bandwidth; The virtual service is used to ensure that after the service traffic reaches the LB node, the LB node forwards the service traffic to the corresponding multiple WAF nodes. The SaaS WAF management platform and the core switch included in the cloud platform have established a Netconf connection, and the method further includes: Through the Netconf connection, a policy route is sent to the core switch so that the core switch configures the policy route locally. When the service traffic arrives at the core switch, the core switch forwards the service traffic to the LB node according to the policy route. The policy routing includes a destination address and a next hop, wherein the destination address is the public network address to be protected, and the next hop is the address of the LB node.

8. The method according to claim 7, characterized in that, The first configuration file also includes a second sub-configuration file, which is used to enable the LB node to configure the load balancing algorithm of source address hash locally, and to configure the multiple WAF nodes locally as real services corresponding to the virtual service; The real service is used to protect the business traffic of the web application that the user is about to access.

9. The method according to claim 8, characterized in that, The method further includes: A second configuration file is sent to each of the multiple WAF nodes that provide the actual service. The second configuration file includes protection assets, proxy rules, and protection policies, so that each WAF node configures the protection assets, proxy rules, and protection policies locally. The protected asset is the public IP address to be protected.

10. The method according to claim 7, characterized in that, The WAF cluster also includes log nodes, and the method further includes: Receive the log viewing request input by the user, the log viewing request including log attributes; Based on the log attributes, matching log information is obtained from the log node, the log information including at least one portion of the protection logs reported by the WAF node to the log node; The log attribute is the public IP address to be protected.

Images