CN113810347A - Method and system for switching service modes under SDP architecture - Google Patents

Method and system for switching service modes under SDP architecture Download PDF

Info

Publication number
CN113810347A
CN113810347A CN202010547521.4A CN202010547521A CN113810347A CN 113810347 A CN113810347 A CN 113810347A CN 202010547521 A CN202010547521 A CN 202010547521A CN 113810347 A CN113810347 A CN 113810347A
Authority
CN
China
Prior art keywords
sdp
mode
client
port
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202010547521.4A
Other languages
Chinese (zh)
Other versions
CN113810347B (en
Inventor
王海燚
樊宁
沈军
金华敏
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Telecom Corp Ltd
Original Assignee
China Telecom Corp Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Telecom Corp Ltd filed Critical China Telecom Corp Ltd
Priority to CN202010547521.4A priority Critical patent/CN113810347B/en
Publication of CN113810347A publication Critical patent/CN113810347A/en
Application granted granted Critical
Publication of CN113810347B publication Critical patent/CN113810347B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/29Flow control; Congestion control using a combination of thresholds
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441Countermeasures against malicious traffic

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

The invention relates to a method and a system for switching service modes under a software defined boundary SDP framework. The method for switching the service mode under the SDP architecture comprises the following steps: the SDP controller performs traffic identification on a legal authentication request from an SDP client and performs service mode switching between a network stealth mode and a performance mode according to a legal traffic change, wherein in the network stealth mode, the SDP controller performs single packet authorization SPA authentication before a TCP connection is established with the SDP client, and in the performance mode, the SDP controller does not perform SPA authentication before a TCP connection is established with the SDP client, wherein the SDP controller switches the service mode from the network stealth mode to the performance mode when the legal traffic rises above a first threshold, and wherein the SDP controller switches the service mode from the performance mode to the network stealth mode when the legal traffic falls below a second threshold.

Description

Method and system for switching service modes under SDP architecture
Technical Field
The present disclosure relates to the field of network technologies and security technologies, and in particular, to a method and system for switching service modes in a Software Defined border (SDP) architecture.
Background
SDP is a Security framework developed by the Cloud Security Alliance (CSA), which uses the Single Packet Authorization (SPA) technology to implement network stealth and hide core network assets and facilities from being exposed under the internet, thereby protecting them from external Security threats. The SPA is a lightweight security protocol, and the data packet contains the necessary information for authentication. The authorization scheme adopting the SPA technology is based on an access control strategy of discarding all data packets by default, the client sends an authentication and authorization request through a single encrypted data packet, only the client passing the authentication and authorization can access the protected application resource, and an unauthorized user and equipment cannot sense or detect the protected application port, so that the attack area is obviously reduced, and the safety level of the system is improved.
However, there is a performance bottleneck in the component that operates on the SDP controller side to perform monitoring and capturing the SPA packet, and when a sudden and large number of authentication requests (e.g., power-off restart, special time point, etc.) are faced, only the capacity can be expanded in real time or a solution of opening a port is directly adopted, which may cause resource waste, increase of system processing delay, and expansion of an attack plane of the SDP architecture after the port is opened. Therefore, there is a need to avoid resource waste and delay increase while ensuring security of the SDP system in the face of a large number of burst authentication requests.
Disclosure of Invention
The utility model provides a service mode switching method and system under SDP architecture, which can meet the system availability requirement when facing sudden and large amount of authentication requests under the condition of limited resources, realize balance between safety and performance, reduce the exposure window period of ports and improve the system safety.
According to an aspect of the embodiments of the present invention, a method for switching service modes under a software defined boundary SDP architecture is provided, including: the SDP controller performs traffic identification on a legal authentication request from an SDP client and performs service mode switching between a network stealth mode and a performance mode according to a legal traffic change, wherein in the network stealth mode, the SDP controller performs single packet authorization SPA authentication before a TCP connection is established with the SDP client, and in the performance mode, the SDP controller does not perform SPA authentication before a TCP connection is established with the SDP client, wherein the SDP controller switches the service mode from the network stealth mode to the performance mode when legal traffic rises above a first threshold, and wherein the SDP controller switches the service mode from the performance mode to the network stealth mode when legal traffic falls below a second threshold.
According to another aspect of the embodiments of the present invention, there is provided a system for switching service modes under a software defined boundary SDP architecture, including: an SDP controller comprising: the traffic identification and judgment module is configured to identify traffic of a legal authentication request from the SDP client and generate a service mode switching instruction according to a legal traffic change condition; and a service mode switching module configured to switch a service mode between a network stealth mode and a performance mode based on the service mode switching instruction, wherein in the network stealth mode, the SDP controller performs single packet authorization, SPA, authentication before establishing a TCP connection with the SDP client, and in the performance mode, the SDP controller does not perform SPA authentication before establishing a TCP connection with the SDP client, wherein the service mode switching instruction instructs to switch the service mode from the network stealth mode to the performance mode when legitimate traffic rises above a first threshold, and wherein the service mode switching instruction instructs to switch the service mode from the performance mode to the network stealth mode when legitimate traffic falls below a second threshold.
According to another aspect of embodiments of the present invention, there is provided a computer-readable storage medium having stored thereon instructions, which, when executed by a processor, cause the processor to execute the method for switching service mode in SDP architecture as described above.
Other features of the present invention and advantages thereof will become apparent from the following detailed description of exemplary embodiments thereof, which proceeds with reference to the accompanying drawings.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to these drawings without inventive exercise.
Fig. 1 shows a schematic diagram of a conventional SDP architecture.
Figure 2 illustrates an exemplary signaling flow diagram for a service mode switch under SDP architecture according to one embodiment of the present invention.
Fig. 3A shows a schematic diagram of the operations required for switching the network stealth mode to the performance mode according to one embodiment of the present invention.
Fig. 3B shows a schematic diagram of the operations required for switching the performance mode to the network stealth mode according to one embodiment of the present invention.
Fig. 4 shows an exemplary flow diagram of policy switching from a performance mode to a network stealth mode according to one embodiment of the present invention.
Figure 5 shows a schematic diagram of a traffic change and a corresponding service mode switch under the SDP architecture according to an embodiment of the present invention.
Fig. 6 shows an overall flowchart of a method for switching service modes in the SDP architecture according to an embodiment of the present invention.
Fig. 7 shows a block diagram of an example architecture of a system for switching service modes in the SDP architecture according to an embodiment of the present invention.
Detailed Description
Various exemplary embodiments of the present invention will now be described in detail with reference to the accompanying drawings. It should be noted that: the relative arrangement of the components and steps, the numerical expressions and numerical values set forth in these embodiments do not limit the scope of the present invention unless specifically stated otherwise. Meanwhile, it should be understood that the sizes of the respective portions shown in the drawings are not drawn in an actual proportional relationship for the convenience of description.
The following description of at least one exemplary embodiment is merely illustrative in nature and is in no way intended to limit the invention, its application, or uses.
Techniques, methods, and apparatus known to those of ordinary skill in the relevant art may not be discussed in detail but are intended to be part of the specification where appropriate. In all examples shown and discussed herein, any particular value should be construed as merely illustrative, and not limiting. Thus, other examples of the exemplary embodiments may have different values. It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, further discussion thereof is not required in subsequent figures.
SDP, also known as "black cloud," requires that SPA packets be used for authentication and authorization before a client accesses a protected server, ensuring that the client is a secure and allowed-to-access client. In this way, the SDP provides zero visibility and zero connectivity to the outside, hiding core network assets such as user's data and infrastructure in the user's own black cloud, which are not visible to the outside whether they are located in the public or private cloud, and can establish connectivity with a protected server to allow legitimate traffic to pass only after the client proves that they can be trusted, thus preventing all network-based external attacks.
The SDP creates a security boundary based on the above-described policies, thereby isolating the server from the unsecured network. Clients are first authenticated prior to authorization in order to securely connect to the isolated service, while unauthorized clients cannot connect to the protected server, thereby defending against network-based attacks.
Fig. 1 shows a schematic diagram of a conventional SDP architecture 100. As shown in fig. 1, the SDP architecture 100 includes an SDP controller, an SDP client, and an SDP application gateway. Generally, an SDP client sends an SPA packet to a port of an SDP controller through a control channel, and the SDP controller obtains the SPA packet sent by the SDP client through a network monitoring and packet capturing program running on a firewall side and performs identity authentication on the SPA packet. The SDP controller is protected by the firewall, all connection requests with the SDP controller are rejected by default, but the SPA data packet of the connection request can be stored by a network monitoring program and a data packet capturing program which run simultaneously, the SDP controller can authenticate the SPA data packet, and if the authentication is passed, the firewall is informed to add a rule which allows a corresponding SDP client to communicate with the SDP controller. After authentication, the SDP controller establishes a mutual TLS (mTLS) connection with the SDP client over the data channel and allows the SDP client to connect to the SDP application gateway, thereby accessing the protected servers 1-N.
However, when the SDP system is faced with a sudden and large amount of authentication requests, due to performance bottleneck of the snooping and packet capturing components, the capacity can be temporarily expanded or the port can be directly opened to ensure the availability of the system, which may cause a series of problems such as resource waste, increased connection delay, and increase of the exposed internet of the server.
Therefore, the invention provides a switching technology of the service mode under the SDP framework, and the service mode is dynamically switched under the SDP framework according to the flow of the authentication request. Specifically, the SDP controller identifies and judges the legal traffic of the authentication request, and different working strategies preset by the SDP client are combined, so that when the traffic of the legal authentication request is remarkably changed, the SDP controller takes the attack plane minimization principle to realize dynamic switching between a network stealth mode (namely, a safety mode) of firstly authenticating and then connecting and a performance mode of firstly connecting and then authenticating. Therefore, the system availability is satisfied, and meanwhile, the exposure window period of the port is reduced, so that potential network-based attacks are prevented, and the security of the system is ensured.
The principle and method of switching service modes in the SDP architecture according to an embodiment of the present invention will be described with reference to fig. 2-6.
Figure 2 illustrates an exemplary signaling flow diagram for a service mode switch under SDP architecture according to one embodiment of the present invention.
As shown in fig. 2, the switching of service modes under the SDP architecture involves signaling interactions between the SDP controller 100, the SDP client 200 and the SDP gateway 300.
According to this embodiment, the SDP client 200 sets configuration information and corresponding working mechanism in two modes, i.e., a network stealth mode and a performance mode, in advance. Specifically, the configuration information includes, for example, an access address of the SDP controller and a port (hereinafter, also referred to as a first port) that receives a packet in the network stealth mode, and an access address of the SDP controller and a port (hereinafter, also referred to as a second port) that receives a packet in the performance mode. As an example, the access address of the SDP controller may be set to 1.1.1.1, the first port to 1234, and the second port to 5678 in advance.
Note that although only one SDP controller is described herein, in some embodiments, in order to ensure the availability of the whole system, the SDP controller may be provided with redundancy, that is, multiple SDP controllers are provided, so that the load can be shared, and the SDP controller is not affected to implement the original authentication function. In this case, the access addresses of the SDP controllers in the two modes may be set to be different. As an example, the SDP architecture may comprise SDP controller 1 and SDP controller 2, the IP address of SDP controller 1 being set to 1.1.1.1, which may be used to perform authentication functions in network stealth mode, and the IP address of SDP controller 2 being set to 2.2.2.2, which may be used to perform authentication functions in performance mode.
According to this embodiment, the working mechanism is the interaction flow requirement of the SDP client and SDP controller in different modes. Under the network stealth mode, a working mechanism of 'authentication before connection' is adopted. Specifically, the SDP client sends an SPA packet to the SDP controller first, waits for the SDP controller to authenticate the SPA packet, then tries to establish a TCP connection with the first port, and after the TCP connection is successfully established, the SDP client establishes an mTLS connection with the SDP controller again to perform subsequent communication. In the performance mode, a working mechanism of connection first and authentication later is adopted. Specifically, the SDP client establishes a TCP connection with the second port of the SDP controller, and after the TCP connection is successfully established, the SDP client sends an SPA packet to the SDP controller, waits for the SDP controller to authenticate the SDP controller, and after the authentication is passed, the SDP client establishes an mTLS connection with the SDP controller again to perform subsequent communication.
According to this embodiment, the switching policy of the SDP client between the two modes includes accepting notification of active switching and connection failure automatic switching. Specifically, the strategy for receiving the notification of the active switching is that after the SDP client receives a strategy switching instruction sent by the SDP controller, the SDP client switches from the configuration information and the working mechanism in one mode to the configuration information and the working mechanism in another mode according to the strategy switching instruction when performing data interaction with the SDP controller next time. The strategy of the connection failure automatic switching is that the SDP client does not receive a strategy switching instruction sent by the SDP controller due to reasons such as offline and the like, and automatically switches to the working mechanism and the configuration information in another mode when the TCP connection with the SDP controller cannot be established under the working mechanism of the current mode. By combining the two switching strategies, the speed of switching the service mode by the SDP client can be increased, and the availability of the system can be improved.
As shown in fig. 2, in the network stealth mode, the SDP controller 100 enables a network listening and packet capturing program on the firewall side to listen and capture an SPA packet transmitted from the SDP client 200 in step S201. In step S202, the SDP client 200 transmits an SPA packet to a first port (e.g., 1234 port) of the SDP controller 100. In step S203, the network snooper and packet capture program snoops and captures the SPA packet and performs identity authentication on it. Next, in step S204, the authenticated SDP client 200 establishes a TCP connection with the SDP controller 100. Next, in step S205, an mTLS connection is established between the SDP controller 100 and the SDP client 200, and in step S206, service information transfer is performed between the SDP controller 100 and the SDP gateway 300. Then, in step S207, the authenticated SDP client 200 performs subsequent communication with the SDP gateway 300.
Next, when a large number of sudden authentication requests occur, in step S208, the SDP controller 100 recognizes that legitimate traffic of a legitimate authentication request in the authentication requests exceeds a certain threshold (hereinafter, also referred to as a first threshold), and the SDP controller 100 switches the service mode from the network stealth mode to the performance mode.
According to this embodiment, the SDP controller 100 may perform traffic identification on the authentication request, distinguishing legitimate traffic from illegitimate traffic. In some embodiments, the SDP controller 100 may perform traffic determination according to the authenticity of the SPA packet, in combination with information such as an asset list and a traffic model, distinguish a legitimate authentication request from an illegitimate authentication request such as malicious network scanning or DoS/DDoS attack, and switch a service mode when legitimate traffic exceeds a first threshold. In this way, it is possible to prevent an increased risk of the SDP controller being attacked by falsely opening the second port.
In some embodiments, the SDP controller 100 may perform identity authentication on the SPA packet according to a preset authentication mechanism, and when the authentication passes, the SPA packet is determined to be true, and the corresponding authentication request is a legal authentication request, and when the authentication fails, the SPA packet is determined to be not true, and the corresponding authentication request is an illegal authentication request.
In some embodiments, only SDP clients within an inventory may be allowed to connect to the SDP controller for authentication. As an example, assuming that the SDP client is required to connect to the SDP controller only in an office environment, the office IP address may be part of the inventory of assets from which the traffic may be determined to be illegal if the SDP client attempts to connect to the SDP controller in another environment (e.g., home, or off-site).
In some embodiments, the first threshold may be calculated by a flow model or may be set based on empirical values.
Referring to fig. 3A, the SDP controller 100 switching the service mode from the network stealth mode to the performance mode includes the following operations: 1. the SDP controller 100 closes a first port (e.g., 1234 port) for receiving an SPA packet sent by the SDP client 200 in the network stealth mode; 2. deactivating the network listening and packet capture procedures; 3. a second port (e.g., 5678 port) is opened for receiving the SPA sent by the SDP client 200; 4. the firewall is notified to add a rule to open the second port, allowing the external connection. Note that the above operations may be performed simultaneously or sequentially in order, and the execution order is not limited to the illustrated order.
As an example, SDP controller 100 recognizes that the traffic of SPA packets destined for port 1234 has exceeded a first threshold, closes port 1234, and disables network snooping and packet capture procedures, opens port 5678, and notifies the firewall to add access control rules that allow external connections to port 5678, thereby completing the switch from network stealth mode to performance mode.
As described above, in this embodiment, different ports are used in the network stealth mode and the performance mode, so that it is avoided that the first port in the network stealth mode is opened to the outside so that the related information is exposed to the outside and even utilized, thereby protecting various system information in the network stealth mode, ensuring the availability of the system and the security of the system, and achieving a balance between the performance and the security. In addition, in the performance mode, the SDP controller 100 allows the SDP client 200 to perform TCP connection with it first, and then perform identity authentication through the SPA packet, so that the performance bottleneck of the network monitoring and packet capturing program is not limited, and the processing efficiency can be improved.
Returning to fig. 2, next, in step S209, the SDP client 200 performs policy switching. According to this embodiment, the SDP client 200 may automatically execute the mode switching policy after failing to establish a connection with the first port for a plurality of times, and switch from the operating mechanism and configuration information in the network stealth mode to the operating mechanism and configuration information in the performance mode. In some embodiments, the upper limit of the number of connection failures may be preset according to the service requirement, and may preferably be set to three times.
As an example, in a case where SDP controller 100 has switched to the performance mode while SDP client 200 newly brought online is still operating in the network stealth mode, SDP client 200 may send an SPA packet to 1234 port of SDP controller 100, and then attempt to establish a TCP connection with 1234 port. However, since the 1234 port is closed at this time, the TCP connection is failed to be established, and after a plurality of connection failures, the SDP client 200 performs policy switching to switch to the operating mechanism and configuration information in the performance mode.
Alternatively, in some embodiments, the SDP controller 100 may further send a policy switching instruction to the SDP client 200 when switching from the network stealth mode to the performance mode, and the SDP client 200 switches from the operating mechanism and configuration information in the network stealth mode to the operating mechanism and configuration information in the performance mode in response to receiving the policy switching instruction in step S209.
Next, in step S210, the SDP client 200 establishes a TCP connection with a second port (e.g., 5678 port) of the SDP controller 100 according to the switched configuration information. Next, in step S211, after the TCP connection is successfully established, the SDP client 200 transmits an SPA packet to the SDP controller 100. Then, in step S212, the SDP controller 100 performs authentication on the SPA packet. After the authentication is passed, mTLS connection is established between the SDP controller 100 and the SDP client 200 in step S213, and service information transfer is performed between the SDP controller 100 and the SDP gateway 300 in step S214. Then, in step S215, the authenticated SDP client 200 performs subsequent communication with the SDP gateway 300.
In this embodiment, the SDP controller 100 maintains communication with the SDP client 200, the SDP gateway 300, or a server under the protection of the SDP gateway 300, and acquires the situation of the SDP client on line in real time. Specifically, the SDP gateway 300 or a server under the protection of the SDP gateway 300 may send information about the SDP clients requesting a service, including but not limited to the number of SDP clients, whether or not online, etc., to the SDP controller 100. The SDP controller 100 may confirm that the SDP client is online by keep-alive information, log-out information, and the like sent from the SDP client.
Next, in step S216, when the legitimate traffic of the legitimate authentication request in the authentication requests received by the SDP controller 100 has been lower than a certain threshold (hereinafter, also referred to as a second threshold), the SDP controller 100 switches the service mode back to the network stealth mode.
Referring to fig. 3B, the SDP controller 100 switching the service mode from the performance mode to the network stealth mode includes the following operations: 1. re-enabling the network monitoring and data packet capturing program; 2. closing a second port for receiving the SPA sent by the SDP client 200; 3. the open first port is used for receiving the SPA sent by the SDP client 200; 4. the firewall is notified to delete the rule opening the second port. Note that the above operations may be performed simultaneously or sequentially in order, and the execution order is not limited to the illustrated order.
As an example, the SDP controller 100 recognizes that the authentication traffic to the client on-line and to the 5678 port has fallen below the second threshold, re-enables the network listening and packet capturing procedures, opens 1234 the port, closes 5678 the port, and notifies the firewall to remove the rule of opening the external available 5678 port.
In some embodiments, the second threshold may be calculated by a flow model or may be set based on empirical values.
Returning to fig. 2, in step S217, the SDP controller 100 sends a policy switching instruction to the online SDP client 200 to notify the online SDP client of policy switching. Next, in step S218, the SDP client 200 performs policy switching. Then, the SDP system continues the work flow of 'first authentication and then connection' in the network stealth mode.
According to this embodiment, the policy switch of the SDP client 200 from the performance mode to the network stealth mode includes accepting notification of proactive switch and connection failure automatic switch.
Fig. 4 shows an exemplary flow 400 for policy switching from a performance mode to a network stealth mode according to one embodiment of the present invention. As shown in fig. 4, in step S401, the SDP controller switches from the performance mode to the network stealth mode. Next, in step S402, the SDP controller transmits a policy switching instruction to the SDP client. Next, in step S403, the SDP determines whether a policy switching instruction is received.
When the SDP client receives the policy switching instruction sent by the SDP controller, in step S404, the SDP client actively performs policy switching when requesting access next time, and switches from the operating mechanism and configuration information in the performance mode to the operating mechanism and configuration information in the network stealth mode. As an example, an online SDP client receives a policy switching instruction sent by an SDP controller, and when applying for access to an SDP gateway again after being offline, executes switching of a policy to a network stealth mode, and then continues a work flow of "authentication before connection" in the network stealth mode.
When the SDP client does not receive the policy switching instruction sent by the SDP controller, in step S405, when requesting access next time, the SDP client still tries to establish connection with the second port, and after failing to try connection for many times, policy switching is automatically performed, and the working mechanism and configuration information in the performance mode are switched to the working mechanism and configuration information in the network stealth mode. As an example, the SDP client goes offline in the operating process of the performance mode, so a policy switching instruction sent by the SDP controller is not received, the SDP controller is switched to the network stealth mode when the SDP client goes online again, because the SDP client still follows the working mechanism in the performance mode, the SDP client will first try to establish TCP connection with the second port, and after multiple attempts fail, the SDP client automatically performs policy switching, and switches to the working flow of "authentication before connection" in the network stealth mode. In some embodiments, the upper limit of the number of connection failures may be preset according to the service requirement, and may preferably be set to three times.
Figure 5 shows a schematic diagram of a traffic change and a corresponding service mode switch under the SDP architecture according to an embodiment of the present invention. As shown in fig. 5, when the flow rate is below the threshold, in the network stealth mode, 1234 ports are used. When the flow gradually rises above the threshold, the performance mode is switched to and 5678 ports are used instead. And when the traffic gradually drops below the threshold again, switch back to the network stealth mode and use the 1234 port instead. This may ensure availability of the system in the event that traffic exceeds the upper limit of the listening and packet capture components of the SDP controller.
Note that although only an example in which the first threshold and the second threshold are the same threshold is shown in fig. 3, it should be understood that the first threshold and the second threshold may be different thresholds. In some embodiments, the first threshold may be set near the highest processing capacity of the system, and the first threshold may be greater than or equal to the second threshold.
As an example, assuming that the SDP gateway can support 100 authentication requests simultaneously, when the authentication requests increase again, a request failure occurs due to a performance bottleneck, so the first threshold may be set to 90, for example, to ensure the availability of the SDP system. The second threshold when the number of authentication requests decreases and is to be switched from the performance mode to the network stealth mode may be set lower than the first threshold, for example, may be set to 80, so that even if a small fluctuation of the number of authentication requests occurs after the service mode is switched (for example, a small increase of the authentication requests), the mode switching is not performed again, thereby avoiding frequent mode switching and resulting unnecessary overhead.
It should be understood that the specific numbers (e.g., 100, 90, 80) mentioned above are only specific examples given as examples and are not limiting to the present disclosure, and that the first threshold and the second threshold may naturally take other values as long as both are less than or equal to the maximum processing capacity of the SDP gateway and the first threshold is greater than or equal to the second threshold.
Fig. 6 shows an overall flow 600 of a method for switching service modes in the SDP architecture according to an embodiment of the present invention.
As shown in fig. 6, in step S601, the SDP controller performs traffic identification on a valid authentication request from the SDP client. According to this embodiment, the SDP controller may determine whether the authentication request from the SDP client is a legitimate authentication request based on at least one of authenticity of the received SPA packet, an asset manifest, or a traffic model, and in response to determining that the authentication request is a legitimate authentication request, credit it to legitimate traffic.
Next, in step S602, the SDP controller performs service mode switching between a network stealth mode and a performance mode according to a legitimate traffic change, where in the network stealth mode, the SDP controller performs SPA authentication before establishing a TCP connection with the SDP client, and in the performance mode, the SDP controller does not perform SPA authentication before establishing a TCP connection with the SDP client. Therefore, the SDP system can meet the availability of the system and reduce the risk exposure window period of the open port and improve the safety of the system by dynamically switching between the network stealth mode and the performance mode when the authentication request flow is obviously changed.
According to this embodiment, in the network stealth mode, the SDP controller obtains the SPA packet for authentication through a network snooping and packet capture program running on the firewall side.
According to this embodiment, in the network stealth mode the SDP controller receives data packets via a first port, and in the performance mode the SDP controller receives data packets via a second port different from the first port.
According to the embodiment, in the network stealth mode, the SDP controller receives the SPA packet from the SDP client through the first port, and after the SDP controller authenticates the SPA packet, the SDP client establishes TCP connection with the first port of the SDP controller. In the performance mode, after the SDP client establishes a TCP connection with the second port of the SDP controller, the SDP controller receives the SPA packet from the SDP client through the second port and authenticates the SPA packet.
Next, in step S603, when the legitimate traffic rises above the first threshold, the SDP controller switches the service mode from the network stealth mode to the performance mode. Specifically, as described in step S605, when the service mode is switched from the network stealth mode to the performance mode, the SDP controller closes the first port in the network stealth mode for receiving the SPA packet sent by the SDP client, opens the second port for receiving the SPA packet sent by the SDP client, notifies the firewall of a rule for opening the second port, and disables the network snooping and packet capturing programs.
Alternatively, in step S604, when the legitimate traffic drops below the second threshold, the SDP controller switches the service mode from the performance mode to the network stealth mode. Specifically, as described in step S606, when the service mode is switched from the performance mode to the network stealth mode, the SDP controller enables the network listening and packet capturing programs, closes the second port for receiving the SPA packet sent by the SDP client in the performance mode, opens the first port for receiving the SPA packet sent by the SDP client, and notifies the firewall to delete the rule for opening the second port.
According to this embodiment, the first threshold and the second threshold may be the same threshold or different thresholds. In some embodiments, the first threshold may be set to be greater than or equal to the second threshold.
In some embodiments, the SDP controller sends policy switch instructions to the SDP client when performing service mode switching. Alternatively, in further embodiments, the SDP controller does not send the policy switch instruction to the SDP client when the service mode switches from the network stealth mode to the performance mode, and sends the policy switch instruction to the SDP client when the service mode switches from the performance mode to the network stealth mode.
According to the embodiment, the SDP client sets two working mechanisms and configuration information in advance aiming at two service modes, namely a network stealth mode and a performance mode. Wherein the configuration information comprises information about the port on which the SDP controller receives the data packet.
According to the embodiment, the SDP client responds to the received policy switching instruction when receiving the policy switching instruction, and switches the working mechanism and the configuration information in the current service mode to the working mechanism and the configuration information in another service mode. Alternatively, the SDP client automatically switches to the operating mechanism and configuration information in another service mode when it does not receive the policy switching instruction and cannot establish a TCP connection with the SDP controller under the operating mechanism of the current service mode. Therefore, the SDP client can rapidly switch the service mode when the authentication request flow is remarkably changed, and the switching speed is increased, so that the usability of the system is met and the safety of the system is improved.
The principles and methods of switching service modes in the SDP architecture according to one embodiment of the present invention have been described above. A system for switching service modes in the SDP architecture according to this embodiment will be described below.
Fig. 7 shows a block diagram of an example architecture of a system 700 for switching service modes in the SDP architecture according to an embodiment of the present invention.
As shown in fig. 7, the SDP service mode switching system 700 includes an SDP controller 100, an SDP client 200, an SDP application gateway 300, and a firewall.
According to this embodiment, the SDP controller 100 comprises a traffic identification and decision module 1001, a service mode switching module 1002, and a policy issuing module 1003.
According to this embodiment, the traffic identification and decision module 1001 is configured to perform traffic identification on a legitimate authentication request from the SDP client 200 and to generate a service mode switching instruction according to a legitimate traffic change situation, wherein the service mode switching instruction instructs to switch the service mode from the network stealth mode to the performance mode when legitimate traffic rises above a first threshold and instructs to switch the service mode from the performance mode to the network stealth mode when legitimate traffic falls below a second threshold. In some embodiments, the traffic identification and determination module 1001 is further configured to determine whether the authentication request from the SDP client 200 is a legitimate authentication request based on at least one of authenticity of the received SPA packet, an asset manifest, or a traffic model, and in response to determining that the authentication request is a legitimate authentication request, credit it to legitimate traffic.
According to this embodiment, the service mode switching module 1002 is configured to switch the service mode between the network stealth mode and the performance mode based on the service mode switching instruction.
According to this embodiment, in the network stealth mode, SDP controller 100 performs single packet authorization, SPA, authentication before establishing a TCP connection with SDP client 200, whereas in the performance mode, SDP controller 100 does not perform SPA authentication before establishing a TCP connection with SDP client 200.
According to this embodiment, in the network stealth mode, the SDP controller 100 receives an SPA packet from the SDP client 200 through the first port, and after the SDP controller 100 authenticates the SPA packet, the SDP client 200 establishes a TCP connection with the first port of the SDP controller 100. According to this embodiment, in the performance mode, after the SDP client 200 establishes a TCP connection with the second port of the SDP controller 100, the SDP controller 100 receives an SPA packet from the SDP client 200 through the second port and authenticates the SPA packet, where the first port is different from the second port.
According to this embodiment, the SDP service mode switching system 700 further comprises a network listen and packet capture program 1004 running on the firewall side of the SDP controller 100, said network listen and packet capture program 1004 being configured to obtain SPA packets for authentication in the network stealth mode.
According to this embodiment, service mode switching module 1002 is configured to, when the service mode is switched from the network stealth mode to the performance mode, close a first port for receiving an SPA packet sent by SDP client 200 in the network stealth mode, open a second port for receiving an SPA packet sent by SDP client 200, notify a firewall to add a rule to open the second port, and disable network snooping and packet capture program 1004. According to this embodiment, the service mode switching module 1002 is further configured to enable the network listening and packet capturing program 1004, close the second port for receiving the SPA packet sent by the SDP client 200 in the performance mode, open the first port for receiving the SPA packet sent by the SDP client 200, and notify the firewall to delete the rule for opening the second port when the service mode is switched from the performance mode to the network stealth mode.
In some embodiments, the policy issuing module 1003 is configured to send a policy switching instruction to the SDP client 200 when performing service mode switching. Alternatively, in other embodiments, the policy issuing module 1003 is configured not to send the policy switching instruction to the SDP client 200 when the service mode is switched from the network stealth mode to the performance mode, and to send the policy switching instruction to the SDP client 200 when the service mode is switched from the performance mode to the network stealth mode.
According to this embodiment, the SDP client 200 includes a policy setting module 2001 and a policy enforcement module 2002.
According to this embodiment, the policy setting module 2001 is configured to preset two kinds of operation mechanisms and configuration information (e.g., configuration 1 and configuration 2) for two kinds of service modes, a network stealth mode and a performance mode, wherein the configuration information includes information on a port on which the SDP controller 100 receives a packet.
According to this embodiment, the policy enforcement module 2002 is configured to switch the operating mechanism and configuration information in the current service mode to the operating mechanism and configuration information in another service mode in response to the policy switching instruction in case of receiving the policy switching instruction, and to automatically switch to the operating mechanism and configuration information in another service mode in case of not receiving the policy switching instruction and the SDP client 200 being unable to establish a TCP connection with the SDP controller 100 in the operating mechanism of the current service mode.
According to this embodiment, the SDP application gateway 300 enforces protection for the servers 1-N. The servers 1-N are only visible to authenticated SDP clients 200, but are invisible to other devices that are not authenticated.
It should be noted that the above modules are only logic modules divided according to the specific functions implemented by the modules, and are not used to limit the specific implementation manner, and may be implemented in software, hardware or a combination of software and hardware, for example. In actual implementation, the above modules may be implemented as separate physical entities, or may also be implemented by a single entity (e.g., a processor (CPU or DSP, etc.), an integrated circuit, etc.). Furthermore, the various modules described above are shown in dashed lines in the figures to indicate that these modules may not actually be present, but that the operations/functions that they implement may be implemented by processing circuitry.
As described above, according to the switching method and system of the present invention, the service mode can be dynamically switched according to the traffic change, the SDP client can automatically perform policy switching, and in the face of a sudden and large traffic authentication request, the availability of the system can be maintained without additionally increasing resources, and the SDP client can return to the network stealth mode again when the authentication request is reduced to a set threshold, thereby reducing the exposure window period of the port. In addition, the SDP controller can also be combined with various information to carry out flow judgment and distinguish a legal authentication request from an external attack, thereby preventing the port from being opened by trade and improving the safety of the system.
So far, the method and system for switching service mode under SDP architecture according to the present invention have been described in detail. Some details well known in the art have not been described in order to avoid obscuring the concepts of the present invention. It will be fully apparent to those skilled in the art from the foregoing description how to practice the presently disclosed embodiments.
The method and system of the present invention may be implemented in a number of ways. For example, the methods and systems of the present invention may be implemented in software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order for the steps of the method is for illustrative purposes only, and the steps of the method of the present invention are not limited to the order specifically described above unless specifically indicated otherwise. Furthermore, in some embodiments, the present invention may also be embodied as a program recorded in a recording medium, the program including machine-readable instructions for implementing a method according to the present invention. Thus, the present invention also covers a recording medium storing a program for executing the method according to the present invention.
Although some specific embodiments of the present invention have been described in detail by way of illustration, it should be understood by those skilled in the art that the above illustration is only for the purpose of illustration and is not intended to limit the scope of the invention. It will be appreciated by those skilled in the art that modifications may be made to the above embodiments without departing from the scope and spirit of the invention. The scope of the invention is defined by the appended claims.

Claims (20)

1. A method for switching service modes under a software defined boundary (SDP) architecture comprises the following steps:
the SDP controller carries out flow identification on a legal authentication request from an SDP client and carries out service mode switching between a network stealth mode and a performance mode according to the legal flow change condition,
wherein, in the network stealth mode, the SDP controller performs single packet authorization SPA authentication before establishing a TCP connection with the SDP client, and in the performance mode, the SDP controller does not perform SPA authentication before establishing a TCP connection with the SDP client,
wherein the SDP controller switches the service mode from a network stealth mode to a performance mode when legitimate traffic rises above a first threshold, and
wherein the SDP controller switches the service mode from a performance mode to a network stealth mode when legitimate traffic falls below a second threshold.
2. The method of claim 1, wherein,
in a network stealth mode, an SDP controller receives a data packet through a first port; and is
In the performance mode, the SDP controller receives a data packet via a second port different from the first port.
3. The method of claim 2, wherein
In the network stealth mode, the SDP controller receives an SPA data packet from an SDP client through a first port, and after the SDP controller authenticates the SPA data packet, the SDP client establishes TCP connection with the first port of the SDP controller; and
in the performance mode, after the SDP client establishes a TCP connection with the second port of the SDP controller, the SDP controller receives the SPA packet from the SDP client through the second port and authenticates the SPA packet.
4. The method of claim 3, wherein,
in the network stealth mode, the SDP controller obtains the SPA data packet for authentication through a network monitoring and data packet capturing program running on the firewall side.
5. The method of claim 1, further comprising:
when the service mode is switched from the network stealth mode to the performance mode, the SDP controller closes a first port which is used for receiving an SPA data packet sent by an SDP client side in the network stealth mode, opens a second port which is used for receiving the SPA data packet sent by the SDP client side, informs a firewall of adding a rule for opening the second port, and stops a network monitoring and data packet capturing program; and
when the service mode is switched from the performance mode to the network stealth mode, the SDP controller enables a network monitoring and data packet capturing program, closes a second port used for receiving an SPA data packet sent by the SDP client side in the performance mode, opens a first port used for receiving the SPA data packet sent by the SDP client side, and informs a firewall to delete a rule for opening the second port.
6. The method of claim 1, further comprising:
the SDP controller judges whether the authentication request from the SDP client is a legal authentication request or not based on at least one of authenticity, an asset list or a traffic model of the received SPA data packet; and is
And in response to determining that the authentication request is a legal authentication request, the authentication request is counted into legal traffic.
7. The method of claim 1, wherein,
the first threshold is greater than or equal to the second threshold.
8. The method of claim 1, further comprising:
and the SDP controller sends a strategy switching instruction to the SDP client when the service mode is switched.
9. The method of claim 1, further comprising:
the SDP controller does not send a policy switching instruction to the SDP client when the service mode is switched from the network stealth mode to the performance mode, and sends a policy switching instruction to the SDP client when the service mode is switched from the performance mode to the network stealth mode.
10. The method of claim 8 or 9, further comprising:
the SDP client presets two working mechanisms and configuration information aiming at two service modes, namely a network stealth mode and a performance mode, wherein the configuration information comprises information about a port of an SDP controller for receiving a data packet;
the SDP client responds to the strategy switching instruction under the condition of receiving the strategy switching instruction, and switches the working mechanism and the configuration information in the current service mode into the working mechanism and the configuration information in another service mode; and
and when the SDP client does not receive the strategy switching instruction and cannot establish TCP connection with the SDP controller under the working mechanism of the current service mode, the SDP client automatically switches to the working mechanism and the configuration information under another service mode.
11. A system for switching service modes under a software defined boundary SDP architecture, comprising:
an SDP controller comprising:
the traffic identification and judgment module is configured to identify traffic of a legal authentication request from the SDP client and generate a service mode switching instruction according to a legal traffic change condition; and
a service mode switching module configured to switch a service mode between a network stealth mode and a performance mode based on the service mode switching instruction,
wherein, in the network stealth mode, the SDP controller performs single packet authorization SPA authentication before establishing a TCP connection with the SDP client, and in the performance mode, the SDP controller does not perform SPA authentication before establishing a TCP connection with the SDP client,
wherein the service mode switching instruction instructs to switch the service mode from a network stealth mode to a performance mode when legitimate traffic rises above a first threshold, and
wherein the service mode switching instruction instructs to switch the service mode from a performance mode to a network stealth mode when legitimate traffic falls below a second threshold.
12. The system of claim 11, wherein
In the network stealth mode, the SDP controller receives an SPA data packet from an SDP client through a first port, and after the SDP controller authenticates the SPA data packet, the SDP client establishes TCP connection with the first port of the SDP controller; and
in the performance mode, after the SDP client establishes a TCP connection with a second port of the SDP controller, the SDP controller receives an SPA packet from the SDP client through the second port and authenticates the SPA packet, wherein the first port is different from the second port.
13. The system of claim 12, further comprising:
a network listen and packet capture program running on a firewall side of an SDP controller, the network listen and packet capture program configured to obtain the SPA packet for authentication in the network stealth mode.
14. The system of claim 11, wherein the service mode switching module is further configured to:
when the service mode is switched from the network stealth mode to the performance mode, closing a first port which is used for receiving an SPA data packet sent by an SDP client in the network stealth mode, opening a second port which is used for receiving the SPA data packet sent by the SDP client, informing a firewall of adding a rule for opening the second port, and stopping a network monitoring program and a data packet capturing program; and
when the service mode is switched from the performance mode to the network stealth mode, a network monitoring and data packet capturing program is started, a second port used for receiving an SPA data packet sent by an SDP client side in the performance mode is closed, a first port is opened and used for receiving the SPA data packet sent by the SDP client side, and a firewall is informed to delete a rule for opening the second port.
15. The system of claim 11, wherein the traffic identification and determination module is further configured to:
determining whether the authentication request from the SDP client is a legitimate authentication request based on at least one of authenticity, an asset manifest, or a traffic model of the received SPA data packet; and is
And in response to determining that the authentication request is a legal authentication request, the authentication request is counted into legal traffic.
16. The system of claim 11, wherein
The first threshold is greater than or equal to the second threshold.
17. The system of claim 11, wherein the SDP controller further comprises:
and the strategy issuing module is configured to send a strategy switching instruction to the SDP client when the service mode is switched.
18. The system of claim 11, wherein the SDP controller further comprises:
and the strategy issuing module is configured not to send a strategy switching instruction to the SDP client when the service mode is switched from the network stealth mode to the performance mode, and to send the strategy switching instruction to the SDP client when the service mode is switched from the performance mode to the network stealth mode.
19. The system of claim 17 or 18, further comprising:
an SDP client, comprising:
the system comprises a policy setting module, a service management module and a service management module, wherein the policy setting module is configured to preset two working mechanisms and configuration information aiming at two service modes, namely a network stealth mode and a performance mode, and the configuration information comprises information about a port of an SDP controller for receiving a data packet; and
and the strategy execution module is configured to respond to the strategy switching instruction under the condition that the strategy switching instruction is received, switch the working mechanism and the configuration information in the current service mode into the working mechanism and the configuration information in another service mode, and automatically switch to the working mechanism and the configuration information in the another service mode under the condition that the strategy switching instruction is not received and the SDP client cannot establish TCP connection with the SDP controller under the working mechanism in the current service mode.
20. A computer-readable storage medium having stored thereon instructions that, when executed by a processor, cause the processor to perform the method of any one of claims 1-10.
CN202010547521.4A 2020-06-16 2020-06-16 Service mode switching method and system under SDP architecture Active CN113810347B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010547521.4A CN113810347B (en) 2020-06-16 2020-06-16 Service mode switching method and system under SDP architecture

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010547521.4A CN113810347B (en) 2020-06-16 2020-06-16 Service mode switching method and system under SDP architecture

Publications (2)

Publication Number Publication Date
CN113810347A true CN113810347A (en) 2021-12-17
CN113810347B CN113810347B (en) 2023-07-18

Family

ID=78944285

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010547521.4A Active CN113810347B (en) 2020-06-16 2020-06-16 Service mode switching method and system under SDP architecture

Country Status (1)

Country Link
CN (1) CN113810347B (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115776408A (en) * 2022-12-08 2023-03-10 四川启睿克科技有限公司 Single-packet multi-stage authentication method based on zero trust
CN115865370A (en) * 2022-11-25 2023-03-28 四川启睿克科技有限公司 TCP option-based single-packet authorization verification method
WO2023178590A1 (en) * 2022-03-24 2023-09-28 Qualcomm Incorporated Service-based architecture for providing a data channel associated with an internet protocol multimedia subsystem
CN115865370B (en) * 2022-11-25 2024-06-04 四川启睿克科技有限公司 Single-packet authorization verification method based on TCP options

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130347062A1 (en) * 2010-02-26 2013-12-26 Eldad Matityahu Secured network arrangement and methods thereof
CN107135127A (en) * 2017-06-26 2017-09-05 福建中金在线信息科技有限公司 A kind of network flow abnormal detecting method and device
CN111131310A (en) * 2019-12-31 2020-05-08 奇安信科技集团股份有限公司 Access control method, device, system, computer device and storage medium

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130347062A1 (en) * 2010-02-26 2013-12-26 Eldad Matityahu Secured network arrangement and methods thereof
CN107135127A (en) * 2017-06-26 2017-09-05 福建中金在线信息科技有限公司 A kind of network flow abnormal detecting method and device
CN111131310A (en) * 2019-12-31 2020-05-08 奇安信科技集团股份有限公司 Access control method, device, system, computer device and storage medium

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023178590A1 (en) * 2022-03-24 2023-09-28 Qualcomm Incorporated Service-based architecture for providing a data channel associated with an internet protocol multimedia subsystem
CN115865370A (en) * 2022-11-25 2023-03-28 四川启睿克科技有限公司 TCP option-based single-packet authorization verification method
CN115865370B (en) * 2022-11-25 2024-06-04 四川启睿克科技有限公司 Single-packet authorization verification method based on TCP options
CN115776408A (en) * 2022-12-08 2023-03-10 四川启睿克科技有限公司 Single-packet multi-stage authentication method based on zero trust
CN115776408B (en) * 2022-12-08 2024-05-14 四川启睿克科技有限公司 Single-packet multi-stage authentication method based on zero trust

Also Published As

Publication number Publication date
CN113810347B (en) 2023-07-18

Similar Documents

Publication Publication Date Title
CN107222433B (en) SDN network path-based access control method and system
EP2779574B1 (en) Attack detection and prevention using global device fingerprinting
US7549166B2 (en) Defense mechanism for server farm
US9203802B2 (en) Secure layered iterative gateway
CN111131310B (en) Access control method, device, system, computer device and storage medium
US8079030B1 (en) Detecting stealth network communications
US20060224897A1 (en) Access control service and control server
Chao-Yang DOS attack analysis and study of new measures to prevent
WO2003065186A1 (en) Network monitoring system
CA3021285C (en) Methods and systems for network security
CN110830447A (en) SPA single packet authorization method and device
CN108605264B (en) Method and apparatus for network management
Hijazi et al. Address resolution protocol spoofing attacks and security approaches: A survey
US11165817B2 (en) Mitigation of network denial of service attacks using IP location services
US11201847B2 (en) Address resolution protocol entry verification
EP3545451B1 (en) Automatic forwarding of access requests and responses thereto
CN113810347B (en) Service mode switching method and system under SDP architecture
CN101764788B (en) Safe access method based on extended 802.1x authentication system
Patidar et al. Information Theory-based Techniques to Detect DDoS in SDN: A Survey
CN113972992B (en) Access method and device for SDP controller and computer storage medium
Salim et al. Preventing ARP spoofing attacks through gratuitous decision packet
WO2005026872A2 (en) Internal lan perimeter security appliance composed of a pci card and complementary software
KR101977612B1 (en) Apparatus and method for network management
CN116015977A (en) Network access control method and system for Internet of things equipment
CN114915427A (en) Access control method, device, equipment and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant