A security protection method and storage medium for a capability platform based on SIP signaling

Abstract

A SIP signaling-based security protection method and storage medium for a capability platform. First, Iptables commands are implemented in user space to send the capability platform's maximum concurrent processing capacity to the kernel's Netfilter module. In the kernel, a dedicated SIP signaling firewall module is implemented by adding a hook point to the Netfilter INPUT chain. When paging requests do not exceed the platform's processing capacity, they are directly forwarded to the upper-level signaling proxy for processing. However, when they exceed the platform's maximum processing capacity, the excess paging is routed to a rejection server to avoid impacting the platform. Simultaneously, overall monitoring is performed on the first-level signaling proxy server. When the platform's overall processing capacity does not reach its upper limit, all paging calls are allowed to proceed, ensuring the highest connection rate. When paging requests reach the platform's processing capacity limit, the group call restriction function is automatically activated. This solution provides multi-level SIP signaling-based security protection for the capability platform.

Description

Technical Field

[0001] The present invention relates to the field of network security technology, and in particular to a multi-level security protection method for a capability platform based on SIP signaling. Background Art

[0002] The capability platform hosts cloud relay, work number, and cloud recording services, handling tens of millions of high-concurrency call connections daily. The widespread use of AI-powered robot paging among enterprise customers, in particular, can reach tens of thousands of concurrent calls per second, placing unprecedented pressure on the capability platform. This large volume of AI-powered paging creates a "flood attack," with a flood of requests arriving instantly on the platform, severely congesting its bandwidth and system resources, and even causing the entire platform to crash and disrupt service, severely impacting and causing losses for users.

[0003] Therefore, the capability platform urgently needs a dedicated SIP signaling firewall to prevent AI-based paging attacks similar to DoS / DDoS attacks, while also ensuring priority paging for key VIP customers. However, there is currently no such dedicated SIP signaling firewall on the market. Therefore, this application proposes a multi-level security protection method for the capability platform based on SIP signaling. Summary of the Invention

[0004] In response to the deficiencies in the prior art, the present invention provides a multi-level security protection method for a capability platform based on SIP signaling; a dedicated SIP signaling firewall is established to prevent AI-like DoS / DDoS attack paging, while ensuring priority paging connections for key customers.

[0005] To achieve the above object, the present invention adopts the following technical solutions:

[0006] A multi-level security protection method for a capability platform based on SIP signaling includes the following steps:

[0007] S1: In user space, a call limit instruction is sent to the kernel Netfilter module through the Iptables interface. The call limit instruction is the threshold of the maximum concurrent paging request processing capability of the capability platform, that is, the number of INVITE request messages in the SIP information is limited;

[0008] S2: Add a hook point to the INPUT chain of the kernel Netfilter module to form a dedicated SIP signaling firewall module SIP-Filter. It analyzes all SIP information sent to the capability platform to determine whether the capability platform is affected by call request impact;

[0009] S3: When the platform is not experiencing a call request surge, the SIP-Filter firewall module transmits all paging requests sent to the capability platform to the first-level signaling proxy server. Conversely, if the platform is experiencing a call request surge, the SIP-Filter firewall module circumvents the surge based on the call restriction instructions and transmits the maximum number of paging requests to the first-level signaling proxy server.

[0010] S4: Two levels of rate limiting are introduced in the first-level signaling proxy server. The first level is global rate limiting, which calculates the call load of the capability platform in real time. If the call load does not exceed the set standard value, all paging requests are allowed. Otherwise, the second-level group rate limiting is activated, which partially allows calls. This prevents high-frequency AI calls from occupying the capability platform's processing speed, thereby ensuring a better user experience.

[0011] S5: Through steps S1-S5, security protection is implemented when the capability platform processes paging requests.

[0012] To optimize the above technical solutions, specific measures taken also include:

[0013] Furthermore, in step S2, the SIP-Filter firewall module analyzes all SIP information sent to the capability platform to determine whether the capability platform is impacted by call requests. Specifically, the following are the contents:

[0014] The SIP-Filter firewall module only parses the INVITE request message in the SIP information. Specifically, it first offsets the 20-byte IP header and 8-byte UDP header of each paging request message sent to the capability platform. Then, it parses the paging request message for the SIP signaling feature code "SIP / 2.0". If it is SIP signaling, it will continue to parse and only consider the SIP header field Request URI to be INVITE when it is considered a new request.

[0015] Notify the counting module limit in Netfilter that this is a new request. After receiving the notification, the counting module limit accumulates the CAPS number in real time. The CAPS number refers to the number of call attempts per second, which reflects the value of the information processing capability;

[0016] When the real-time accumulated CAPS number of the counting module limit exceeds the call limit instruction, it is determined that the call request impact is suffered, otherwise it is determined that the call request impact is not suffered.

[0017] Furthermore, in step S3, when the call request impact is encountered, the SIP-Filter firewall module evades the impact based on the call restriction instruction and transmits the maximum amount of paging requests to the primary signaling proxy server. The specific content is:

[0018] When subjected to call request impact, the SIP-Filter firewall module will transfer the excessive paging requests to the rejection server. The rejection server responds to excessive paging requests with a response speed of 480sip, indicating that the capability platform has reached the call limit and is temporarily unavailable, thereby avoiding the impact of excessive paging requests in an instant. At the same time, based on the call limit instruction, the SIP-Filter firewall transmits the paging requests within the maximum range to the first-level signaling proxy server.

[0019] Furthermore, in the global rate limit of the first level in step S4, if the call load of the real-time computing platform does not exceed the set standard value, the specific content of allowing all paging requests is as follows:

[0020] Call load = number of paging requests within a certain period / load threshold;

[0021] When the call load is less than or equal to the set standard value, it means that the call traffic of the capability platform as a whole has not yet reached the full load, so no restriction is imposed on paging requests.

[0022] Furthermore, in the second-level group rate limiting in step S4, partial release is adopted to prevent high-frequency AI calls from occupying the processing speed of the capability platform, and to ensure the user experience. The specific contents are as follows:

[0023] When the call load exceeds the set standard value, it means that the call traffic of the capability platform is fully loaded, so it is necessary to group and rate-limit the paging requests;

[0024] Set up three groups and set the CAPS values ​​of the corresponding groups to control the call traffic of each group, including the ordinary user group, the corresponding CAPS value is a, the priority user group, the corresponding CAPS value is b, and the AI ​​user group, the corresponding CAPS value is c; <b;

[0025] By accumulating the number of paging requests by number and assigning them to the corresponding group, and querying the group's used call volume within a certain period of time, that is, the CAPS used value, if the call volume of a certain group reaches the upper limit, subsequent paging requests will be diverted and the calling end will be notified of the call limit exceeding. This prevents the AI ​​user group from encroaching on the resources of other user groups when it has used up its call volume, and reduces the call interference caused to the capability platform by excessive AI calls.

[0026] A computer-readable storage medium stores a computer program, wherein the computer program enables a computer to execute any of the multi-level security protection methods described above.

[0027] An electronic device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the multi-level security protection method as described in any one of the above items is implemented.

[0028] The beneficial effects of the present invention are:

[0029] 1. The underlying SIP signaling firewall SIP-Filter is implemented based on the Linux kernel module Netfilter, which has the characteristics of strong stability, fast processing speed, high interception efficiency and low system resource consumption.

[0030] 2. It is unique. There are no other dedicated SIP signaling firewalls on the market, and no comparable products exist. It can be widely used in similar high-concurrency paging connection platforms or enterprise security products. As a kernel module, it can not only be directly loaded on the server to be protected, but can also be further upgraded and integrated with hardware to function as an independent, specialized firewall for specific applications.

[0031] 3. Strong prevention capability. For AI paging that exceeds the limit, the SIP-Filter directly directs the traffic to the rejection server and responds with a specific response code, avoiding a larger secondary network surge impact. Because if the AI ​​paging request message is directly discarded, the caller will be triggered to automatically resend the SIP request message (INVITE) according to RFC3261, which will inadvertently trigger more INVITE requests to reach the platform, causing a more serious "flood" network impact; this application uses SIP-filter to transfer the excessive paging to the rejection server to reply with a 480 response message, eliminating this serious consequence and avoiding a more serious call impact on the capability platform.

[0032] 4. Group traffic control: Real-time monitoring of the platform load status, flow control based on the CAPS processing capacity of the customer group, to ensure that priority users, such as government users, are not preempted by AI paging calls. Specifically, when the call volume of a group reaches the upper limit, subsequent paging requests are diverted and the caller is notified of the call limit. By limiting the call volume of each user group, the AI ​​user group is prevented from encroaching on the resources of other user groups when the call volume is exhausted. This ensures user experience while reducing the processing pressure on the capability platform caused by excessive AI calls, thus playing a protective role. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 This is a diagram of the telephone paging connection processing flow on the existing capability platform.

[0034] Figure 2 This is a schematic diagram of the telephone paging connection processing flow of the capability platform designed by this application.

[0035] Figure 3 This is a schematic diagram of the application sending a call restriction instruction to the kernel Netfilter module through the Iptables interface in user space.

[0036] Figure 4 This is a schematic diagram of the SIP-Filter firewall module that forms a dedicated SIP signaling firewall module by adding a HOOK point to the INPUT chain of the kernel Netfilter module.

[0037] Figure 5 This is a schematic diagram of the SIP-filter module in this application forwarding excessive AI paging requests to the rejection server and responding to excessive AI paging requests with a 480sip response message.

[0038] Figure 6 This is a schematic diagram of the two-level speed limit introduced by this application in the first-level signaling proxy server.

[0039] Figure 7 This is a schematic diagram of the relationship between the first-level global speed limit and the second-level group speed limit in this application. DETAILED DESCRIPTION

[0040] The present invention will now be described in further detail with reference to the accompanying drawings.

[0041] refer to Figure 1 In contrast, the traditional original platform telephone paging connection processing process Figure 2 The paging connection processing flow scheme designed by this application is as follows:

[0042] This application includes the following core modules: user space implementation of IPTABLES commands, implementation of SIP-specific firewall based on NetfilterHOOK point, response service to avoid retransmission of INVITE requests, algorithm based on flow request, packet flow control according to customer level, etc.; the specific coordination between them can be seen in the embodiment section below.

[0043] The general working principle is as follows: The multi-level protection of the capability platform is divided into: 1. Implementing DoS / DDoS interception for AI paging by the underlying kernel module SIP signaling dedicated firewall; 2. First-level signaling proxy service packet paging traffic control.

[0044] First, the Iptables command is implemented in user space, and the maximum concurrent processing capacity that the capability platform can bear is sent to the kernel Netfilter module, such as 1000CAPS. In the kernel, a HOOK point is added based on the Netfilter INPUT chain to implement the SIP signaling firewall module SIP-Filter dedicated to this application. This module only parses the SIP INVITE request information and does not process other signaling. It has extremely high message processing and forwarding speeds. When the paging request does not exceed the platform's processing capacity, it is directly forwarded to the upper-level signaling agent for processing. However, when it exceeds the platform's maximum processing capacity, the excess paging will be routed to the rejection server to avoid the retransmission of the paging request on the calling side causing a larger network surge, thereby causing further impact on the platform.

[0045] At the same time, overall monitoring is performed on the first-level signaling proxy server. When the platform's overall processing capacity has not reached the upper limit, all paging calls are released to ensure the highest connection rate. When the paging request reaches the upper limit of the platform's processing capacity, the group call restriction function is automatically activated. Customers are divided into different groups based on the amount of concurrent processing capacity (CAPS) purchased by the customer. The group to which VIP government and enterprise customers belongs has a larger CAPS concurrent processing capacity, which prioritizes the smooth connection of manual paging for VIP government and enterprise customers without interference from AI paging.

[0046] The following is a detailed description with reference to specific embodiments.

[0047] Step 1: Implement Iptables call restriction instructions

[0048] When an IMS network call connection request is sent to the first-level signaling proxy server of the capability platform, the data packet will be sent from the underlying network interface layer to the transport layer (TCP / UDP) via the network layer (IP) and then handed over to the user space APP. The Linux kernel Netfilter firewall module has multiple hook points at the network layer (IP) to filter and update any incoming packets. Figure 3 .

[0049] In order to achieve the hooking of the Netfilter HOOK chain, a dedicated SIP signaling firewall of the capability platform is implemented to prevent too many AI calls that are too fast. This application must first implement the Iptables command in the user space to support the issuance of call restriction instructions for CAPS, SIP request (INVITE) messages and SIP signaling port (5060). For example, Iptables is applied in the user space to implement the method interface to support the issuance of sip INVITE request restrictions to the corresponding SIP-filter hook module in the kernel. If the maximum processing capacity that the first-level signaling agent of the capability platform can handle is 1000CAPS, then the SIP requests arriving per second will not exceed 1000CAPS without any restrictions and will pass normally. When it exceeds 1000CAPS instantly, the firewall function begins to intercept.

[0050] Step 2: Implementation of SIP-specific firewall based on Netfilter

[0051] Implement a SIP-filter kernel module with deep packet parsing function for SIP signaling in the Linux kernel firewall framework Netfilter, and enter the HOOK filter point of the module that hooks into the Netfilter INPUT chain. Figure 4 , SIP messages sent to port 5060 of this machine are processed by it.

[0052] This module only parses SIP INVITE request messages. It offsets each paging request message by a 20-byte IP header and an 8-byte UDP header, then analyzes the SIP signaling signature "SIP / 2.0." If the SIP signaling message contains an INVITE in the Request URI field, it is considered a new request and notifies the Netfilter counting module, Limit, of this new request. Upon receiving this notification, the Limit module accumulates the CAPS count in real time, while ignoring other SIP messages such as UPDATE and ACK to ensure that ongoing call signaling is not affected. If the number of SIP (INVITE) requests exceeds the call limit limit issued by Iptables, the subsequent call rejection process is automatically triggered. Meanwhile, the capability platform continues to provide full call connection services within its maximum CAPS capacity. This ensures that the capability platform does not suffer from resource exhaustion due to a large number of calls, leading to serious problems and a loss of call connection services.

[0053] Step 3: Avoid the impact of resending requests

[0054] When a large number of AI robot paging requests exceeds the control limit of the platform's SIP dedicated firewall, the SIP-filter module will forward the excessive AI paging requests to the "denial of service" prompt server and respond to excessive AI paging requests with a 480 SIP response message, indicating that the capability platform has reached the call limit and is temporarily unavailable. Figure 5 .

[0055] If AI paging request messages are discarded directly, the caller will automatically resend the SIP request message (INVITE) according to RFC3261, inadvertently causing more INVITE requests to reach the platform, causing a more severe "flood" network impact. However, using SIP filters to forward excessive paging requests to the rejection server and respond with a 480 response message eliminates this serious consequence and avoids further call impact on the capability platform.

[0056] Step 4: Global monitoring of the first-level signaling agent

[0057] The SIP signaling-specific firewall SIP-filter implemented based on the kernel module netfilter module has played a good role in blocking the instantaneous excessive AI paging requests, but it cannot intercept at the user level, and the call connection rate of VIP government and enterprise customers will still be affected. For example, the SIP-filter firewall is set with a protection capacity of 1000CAPS, but when an INVITE request within 1000CAPS reaches the first-level signaling proxy server, ordinary users may occupy the entire processing capacity of the first-level signaling proxy of 1000CAPS at an ultra-high frequency, resulting in a reduction in the manual paging connection capacity of VIP customers. For example, VIP government and enterprise customers paid a high fee to purchase the concurrent processing capacity of 500CAPS of the capability platform, while other ordinary customers only purchased 1CAPS concurrent processing capacity, but occupied the entire concurrent processing capacity of 1000CAPS of the first-level signaling proxy with ultra-high frequency AI call restrictions. Therefore, a two-level speed limit is introduced in the first-level signaling proxy server. Figure 6 : The first is global speed limit. If the overall traffic does not exceed the threshold, all traffic will be released. Otherwise, part of the traffic will be released according to the load multiple. The second is group speed limit. According to the threshold set for the group, all or part of the traffic will be released to protect customers with low workloads as much as possible and limit customers with excessively high workloads.

[0058] Step 5: Call flow control algorithm implementation

[0059] 1. Call load = number of calls in the statistical period / load threshold. A shorter statistical period is more sensitive, but the CPU load will increase. The specific period length needs to be adjusted appropriately based on historical voice service data. The threshold required by the call limit instruction is greater than the load threshold. For example, if the former is set to 1500 CAPS and the latter is set to 1000 CAPS, the system is fully loaded when it reaches 1000. The purpose of setting a larger threshold for the call limit instruction is to accept as many paging requests as possible while ensuring that it is not overwhelmed by excessive paging requests. Setting the threshold to 1500 prevents the capability platform from being paralyzed by too many paging requests.

[0060] 2. Call load <= 1, that is, the platform as a whole is not initiating full-load calls, and all calls are not restricted.

[0061] 3. If the call load is greater than 1, for example, 2, half of the calls will be restricted and the other half will be allowed to pass. For example, if the threshold of a group is set to 100 CAPS, but the CAPS for initiating calls to the group is 200, the calculated call load will be 2. In this case, only 50% of the calls will be allowed to pass and 50% of the calls will be restricted.

[0062] Step 6: Packet Paging Flow Control

[0063] Set a grouping policy on the first-level signaling proxy. For example, divide the group into three groups: ordinary user group, VIP user group, and AI user group. The CAPS value of the VIP user group is 100, and the CAPS values ​​of the other two groups are 50.

[0064] After the grouping is completed, the number of times each paging is accumulated by number and the used call volume is queried based on the grouped real number;

[0065] If the number of calls exceeds the previously set threshold (group CAPS), the current part of the call will be diverted and the calling party will be notified of the call exceeding the limit; the other part that does not exceed the threshold will be forwarded and connected normally, such as Figure 7 VIP government and enterprise customers have higher CAPS thresholds. Even when the entire platform is operating at full capacity, the paging connection capacity remains high, meeting the high paging connection service requirements of VIP government and enterprise customers. While ensuring user experience, it also reduces the processing pressure on the capacity platform, achieving a protective effect.

[0066] In addition, the relevant professional terms are explained:

[0067] Netfilter: It is a general and abstract framework of the Linux kernel, providing a complete set of hook function management mechanisms, making it possible to perform packet filtering, network address translation (NAT), and protocol-based connection tracking.

[0068] Sip (Session Initialization Protocol): Session Initiation Protocol, refer to Rfc3261.

[0069] CAPS (Call Attempt Per Second): The number of call attempts per second.

[0070] DoS / DDoS (Distributed denial of service attack): Denial of service attack.

[0071] It should be noted that the terms such as "upper", "lower", "left", "right", "front", "back", etc. cited in the invention are only for the convenience of description and are not used to limit the scope of implementation of the present invention. Changes or adjustments to their relative relationships should be regarded as the scope of implementation of the present invention without substantially changing the technical content.

[0072] The above are merely preferred embodiments of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions based on the principles of the present invention are within the scope of protection of the present invention. It should be noted that for those skilled in the art, various improvements and modifications that do not depart from the principles of the present invention should be considered within the scope of protection of the present invention.

Claims

1. A multi-level security protection method for a capability platform based on SIP signaling, characterized in that: The following steps are involved: S1: In user space, a call limit instruction is sent to the kernel Netfilter module through the Iptables interface. The call limit instruction is the threshold of the maximum concurrent paging request processing capability of the capability platform, that is, the number of INVITE request messages in the SIP information is limited; S2: Add a hook point to the INPUT chain of the kernel Netfilter module to form a dedicated SIP signaling firewall module SIP-Filter. It analyzes all SIP information sent to the capability platform to determine whether the capability platform is affected by call request impact; S3: When the platform is not experiencing a call request surge, the SIP-Filter firewall module transmits all paging requests sent to the capability platform to the first-level signaling proxy server. Conversely, if the platform is experiencing a call request surge, the SIP-Filter firewall module circumvents the surge based on the call restriction instructions and transmits the maximum number of paging requests to the first-level signaling proxy server. S4: Two levels of rate limiting are introduced in the first-level signaling proxy server. The first level is global rate limiting, which calculates the call load of the capability platform in real time. If the call load does not exceed the set standard value, all paging requests are allowed. Otherwise, the second-level group rate limiting is activated, which partially allows calls. This prevents high-frequency AI calls from occupying the capability platform's processing speed, thereby ensuring a better user experience. S5: Through steps S1-S4, security protection is implemented when the capability platform processes paging requests.

2. The multi-level security protection method based on SIP signaling for a capability platform according to claim 1 is characterized in that: In step S2, the SIP-Filter firewall module analyzes all SIP information sent to the capability platform to determine whether the capability platform is impacted by call requests. The specific content is: The SIP-Filter firewall module only parses the INVITE request message in the SIP information. Specifically, it first offsets the 20-byte IP header and 8-byte UDP header of each paging request message sent to the capability platform. Then, it parses the paging request message for the SIP signaling feature code "SIP / 2.0". If it is SIP signaling, it will continue to parse and only consider the SIP header field Request URI to be INVITE when it is considered a new request. Notify the counting module limit in Netfilter that this is a new request. After receiving the notification, the counting module limit accumulates the CAPS number in real time. The CAPS number refers to the number of call attempts per second, which reflects the value of the information processing capability; When the real-time accumulated CAPS number of the counting module limit exceeds the call limit instruction, it is determined that the call request impact is suffered, otherwise it is determined that the call request impact is not suffered.

3. The multi-level security protection method based on SIP signaling for a capability platform according to claim 2 is characterized in that: In step S3, when the call request impact occurs, the SIP-Filter firewall module evades the impact based on the call restriction instruction and transmits the maximum amount of paging requests to the primary signaling proxy server. The specific content is: When subjected to call request impact, the SIP-Filter firewall module will transfer the excessive paging requests to the rejection server. The rejection server responds to excessive paging requests with a response speed of 480sip, indicating that the capability platform has reached the call limit and is temporarily unavailable, thereby avoiding the impact of excessive paging requests in an instant. At the same time, based on the call limit instruction, the SIP-Filter firewall transmits the paging requests within the maximum range to the first-level signaling proxy server.

4. The multi-level security protection method based on SIP signaling for a capability platform according to claim 1 is characterized in that: In the global rate limit of the first level in step S4, if the call load of the real-time computing platform does not exceed the set standard value, all paging requests are allowed to proceed as follows: Call load = number of paging requests within a certain period / load threshold; When the call load is less than or equal to the set standard value, it means that the call traffic of the capability platform as a whole has not yet reached the full load, so no restriction is imposed on paging requests.

5. The multi-level security protection method based on SIP signaling for a capability platform according to claim 1 is characterized in that: In the second-level group rate limiting in step S4, partial release is adopted to prevent high-frequency AI calls from occupying the processing speed of the capability platform and to ensure the user experience. The specific contents are as follows: When the call load exceeds the set standard value, it means that the call traffic of the capability platform is fully loaded, so it is necessary to group and rate-limit the paging requests; Set up three groups and set the CAPS values ​​of the corresponding groups to control the call traffic of each group, including the ordinary user group, the corresponding CAPS value is a, the priority user group, the corresponding CAPS value is b, and the AI ​​user group, the corresponding CAPS value is c; <b; By accumulating the number of paging requests by number and assigning them to the corresponding group, and querying the group's used call volume within a certain period of time, that is, the CAPS used value, if the call volume of a certain group reaches the upper limit, subsequent paging requests will be diverted and the calling end will be notified of the call limit exceeding. This prevents the AI ​​user group from encroaching on the resources of other user groups when it has used up its call volume, and reduces the call interference caused to the capability platform by excessive AI calls.

6. A computer-readable storage medium storing a computer program, characterized in that: The computer program enables a computer to execute the multi-level security protection method according to any one of claims 1 to 5.

Images