Method for protecting 5G core networks from attacks

Abstract

The present disclosure shows a method for providing protection for a 5G core network, a non-transitory computer-readable medium, a network traffic management device, and a network traffic management system. With this technique, a user plane state may be received from a network repository function indicating whether the user plane is restarted. The system may then determine whether an amount of error messages flowing from the user plane to a gNodeB of a source exceeds a predetermined threshold. In response to determining that the amount of error messages exceeds a predetermined threshold and determining that the user plane is not restarted, all messages may be blocked from flowing to the gNodeB of the source. Finally, in response to determining that an amount of return messages from the user plane to the gNodeB is below a second predetermined threshold and the user plane is not restarted, the source may be stored as an adverse actor.

Description

[0001] The present technology relates to methods and systems for protecting 5G core networks from scanning attacks. Background Art

[0002] In previous generations, mobile networks were closed and secure. However, ever since the evolution of mobile network architecture to 4G, mobile networks have become vulnerable to new threat vectors and attacks. A prominent attack on mobile networks involves embedding malicious evolved next generation Node Bs (e(g)NBs) into mobile networks to conduct TEID scanning attacks. Once the attacker detects the TEID, more sophisticated attacks can be launched that consume network resources, user plane functional resources, and gain access to the data network of the mobile network. Currently, GTP firewalls are evolving to protect the mobile core network from such attacks, but these solutions remain ineffective due to the new architecture introduced in 4G and 5G networks. Therefore, a new approach is needed to detect and prevent TEID scanning attacks on mobile core networks from such attacks. Summary of the invention

[0003] A method implemented by a network traffic management system, the method comprising receiving a user plane status from a network repository function indicating whether a user plane has been restarted. The system may then determine whether an amount of error messages flowing from the user plane to a source gNodeB exceeds a predetermined threshold. In response to determining that the amount of error messages exceeds a predetermined threshold and determining that the user plane has not been restarted, all messages may be blocked from flowing to the source gNodeB. Finally, in response to determining that an amount of backhaul messages from the user plane to the gNodeB is below a second predetermined threshold and the user plane has not been restarted, the source may be stored as a bad actor.

[0004] The network traffic management device includes: a memory including programmed instructions stored thereon; and one or more processors configured to be able to execute the stored programmed instructions to receive a user plane status indicating whether the user plane is restarted from a network repository function. The system can then determine whether the amount of error messages flowing from the user plane to the gNodeB of the source exceeds a predetermined threshold. In response to determining that the amount of error messages exceeds the predetermined threshold and determining that the user plane is not restarted, all messages can be blocked from flowing to the gNodeB of the source. Finally, in response to determining that the amount of backhaul messages from the user plane to the gNodeB is lower than a second predetermined threshold and the user plane is not restarted, the source can be stored as a bad actor.

[0005] A non-transitory computer-readable medium having instructions including executable code stored thereon, which, when executed by one or more processors, causes the processor to receive from a network repository function the user plane status indicating whether a user plane has been restarted. The system may then determine whether an amount of error messages flowing from the user plane to a source gNodeB exceeds a predetermined threshold. In response to determining that the amount of error messages exceeds a predetermined threshold and determining that the user plane has not been restarted, all messages may be blocked from flowing to the source gNodeB. Finally, in response to determining that an amount of backhaul messages from the user plane to the gNodeB is below a second predetermined threshold and the user plane has not been restarted, the source may be stored as a bad actor.

[0006] A network traffic management system having: a memory including programmed instructions stored thereon; and one or more processors configured to be able to execute the stored programmed instructions to receive a user plane status indicating whether the user plane is restarted from a network repository function. The system can then determine whether the amount of error messages flowing from the user plane to a source gNodeB exceeds a predetermined threshold. In response to determining that the amount of error messages exceeds a predetermined threshold and determining that the user plane is not restarted, all messages can be blocked from flowing to the gNodeB of the source. Finally, in response to determining that the amount of backhaul messages from the user plane to the gNodeB is below a second predetermined threshold and the user plane is not restarted, the source can be stored as a bad actor.

[0007] The present technology provides several advantages, including providing a method for protecting a 5G core network by detecting and preventing scanning attacks on a mobile core network, a non-transitory computer-readable medium, a network traffic management device, and a network traffic management system. By blocking error messages from going to malicious sources, the malicious source can be prevented from determining whether a TEID is legitimate, which can mitigate attacks. The present technology can block malicious sources without knowing all valid TEIDs from the control plane. By monitoring messages to the user plane and subscribing using the network repository function, the present technology can more effectively and appropriately protect 4G and 5G mobile network architectures. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 is a block diagram of an exemplary 5G system architecture having a network traffic manager device;

[0009] Figure 2 is an exemplary network traffic management device configured to protect a 5G core network;

[0010] Figure 3 is a diagram of an exemplary process for protecting a 5G core network; and

[0011] Figure 4 is a flow chart of an exemplary method for protecting a 5G core network. DETAILED DESCRIPTION

[0012] Figures 1 to 4 An example of a mobile network 10 (i.e., a 5G system architecture) having a network traffic manager device 24 for protecting the mobile network 10 is shown in FIG. The exemplary environment 10 includes a network traffic manager device 24, a user equipment (“UE”) 16, a user plane function (“UPF”) 12, a control plane (“CP”) 18, a data network (“DN”) 20, and a next-generation node Bm (“gNodeB”) 22 coupled together by point-to-point reference points N1 to N6, although the environment may include other types and numbers of systems, devices, components and / or elements and other topologies and deployments. The point-to-point reference points N1 to N6 may be tunneled interfaces, also known as TEIDs, through which traffic passes through tunnels. Although not shown, the exemplary environment 10 may include additional network components, such as functions, routers, switches, and other devices, which are well known to those of ordinary skill in the art and are therefore not described here.

[0013] refer to Figure 1 , an exemplary representation of a 5G core (5GC) network system architecture 10 as defined by the 3GPP standard is shown. As will be understood by those of ordinary skill in the art, the representation focuses on the interaction between a pair of network functions defined by a point-to-point reference point (e.g., N2) between any two network functions (e.g., AMF and gNodeB22), and is used when there is some interaction between any two network functions. As used herein, the term "network function" (NF) may refer to a component of a network infrastructure that provides well-defined functional behaviors (e.g., routing, switching, etc.). NF may be a functional building block within a network infrastructure that has a well-defined external interface and well-defined functional behaviors. NF may be a network node, a physical appliance, or a software implementation of a previously physically implemented network functionality. As used herein, NF may refer to a physical network function (PNF), a virtualized network function (VNF), and / or a cloud-native network function (CNF).

[0014] In addition, although the exemplary representation of the 5G core (5GC) network system architecture 10 also includes point-to-point reference points between NFs when necessary (e.g., see Figure 1), but the upper part of the diagram, i.e. the 5GC control plane (“control plane”) 18, has buses and service-based interfaces exposed by separate functions. This creates a so-called service-based architecture (SBA), where one CP network function (e.g., SMF) allows any other authorized NF to access its services. According to 3GPP standards, NFs within the control plane should only use service-based interfaces to execute their instructions.

[0015] The 5G core network or mobile network 10 consists of the following network functions: Access and Mobility Management Function (AMF), Session Management Function (SMF), Policy Control Function (PCF), Authentication Server Function (AUSF), Unified Data Management (UDM), Application Function (AF), Network Exposure Function (NEF), Network Repository Function (NRF) and Network Slice Selection Function (NSSF). As will be appreciated by those of ordinary skill in the art, all of these NFs are well known and defined by the standards organization 3GPP. Nevertheless, some brief overviews of each function are provided herein for reference:

[0016] AMF can support termination of NAS signaling, NAS encryption and integrity protection, registration management, connection management, mobility management, access authentication and authorization, and security context management.

[0017] The UPF 12 may support packet routing and forwarding, packet inspection, QoS handling, act as an external PDU session point interconnecting with a data network ("DN") 20, and be an anchor point for intra-RAT and inter-RAT mobility.

[0018] The SMF may support session management (e.g., session establishment, modification, and release), UE 16 IP address allocation and management, DHCP functionality, termination of NAS signaling related to session management, DL data notification, and traffic steering configuration of the UPF 12 to enable appropriate traffic routing.

[0019] The PCF can support the unified policy framework, provide policy rules to the CP function, and access subscription information for policy decisions in the UDR.

[0020] AUSF can act as an authentication server.

[0021] UDM may support generation of authentication and key agreement (AKA) credentials, user identity handling, access authorization, and subscription management.

[0022] AF may support applications in influencing traffic routing, accessing NEFs, and interacting with the policy framework for policy control.

[0023] NEF may support exposure of capabilities and events, provision of information from external applications to 3GPP network security, and translation of internal / external information.

[0024] NRF may support service discovery functionality and maintain NF profiles and available NF instances.

[0025] The NSSF may support selection of a network slice instance to serve UE 16, determination of allowed NSSAI, and determination of the AMF set to be used to serve UE 16.

[0026] As will be appreciated by those skilled in the art, Figure 1 As further depicted in FIG, a user equipment (UE) 16 device (e.g., a smartphone) can access the 5G core network by connecting to a radio access network (R(AN)) or a gNodeB 22 (e.g., a cellular network), and can ultimately access an external data network (DN) 20 through a user plane function (UPF) 12. For example, the 5G architecture may also include other network devices, such as routers or switches, which are known in the art and are therefore not described in detail herein.

[0027] "Client" 16, "client device" 16, "user equipment" 16, and / or "user equipment device" 16 refers to a combination of integrated software components and an allocation of computing resources, such as memory, computing devices, and processes on the computing devices for executing the integrated software components. The combination of software and computing resources is configured to interact with one or more servers over a network, such as the Internet. A client may refer to a combination of components on one or more computers, or may refer to one or more computers. User equipment may be any device that an end user uses directly to communicate with a network, and may include devices such as a handheld phone, a smartphone, a laptop equipped with a mobile broadband adapter, or any other device capable of connecting to a Radio Access Network (RAN), a Wi-Fi network, or any other such network. Although Figure 1 Only a single UE 16 and a single NF (eg, AMF, SMF, etc.) are depicted, but it should be understood that it is contemplated that the system architecture may include a plurality of them. For example, there may be many UEs 16 communicating with a gNodeB 22.

[0028] In this example, the UE 16 of the 5G network architecture 10 includes any type of computing device that can exchange network data, such as a mobile, desktop, laptop or tablet computing device, a virtual machine (including a cloud-based computer), etc. Each of the UE devices includes a processor, a memory, and a communication interface coupled together by a bus or other communication link (not shown), although other numbers or types of components may also be used.

[0029] The UE 16 device may run an interface application, such as a standard web browser or a standalone client application. The interface application may provide an interface to request and receive content stored on one or more of the server devices as part of a data network (DN). For example, the UE device may further include a display device such as a display screen or a touch screen, or an input device such as a keyboard or a mouse (not shown).

[0030] The data network (DN) 22 or "server" (also referred to as a "server system" or "server computer system") refers to a combination of integrated software components and computing resource allocations, such as memory, computing devices, and processes on the computing devices for executing the integrated software components. The combination of software and computing resources provides a specific type of functionality on behalf of the client of the server. A server may refer to a combination of components on one or more computers, or may refer to one or more computers. A server may include multiple servers; that is, a server may include a first server computing device and a second server computing device that can provide the same or different functionality to the same or different set of clients. A user equipment (UE) can access the 5G core network of the control plane 18 by connecting to a radio access network (R(AN)) or gNodeB 22 (e.g., a cellular network), and ultimately can access an external data network (DN) 20.

[0031] The gNodeB 22 is a node in a cellular network that provides connectivity between a user device 16 and an AMF or UPF 12. The gNodeB 22 is functionally equivalent to a base station in a traditional cellular network and is responsible for radio communications with the UE 16 in its coverage area (called a cell). The gNodeB 22 may be a physical entity such as a tower, or it may also be a virtual entity such as a software defined radio (SDR). The gNodeB 22 may assist with radio resource management, mobility management, connection management, security, quality of service, billing, or a combination thereof.

[0032] The communication interface of the mobile network 10 is operatively coupled to and communicates between the network traffic manager device 24, various NFs (e.g., AMF, SMF, UDM, AF, PCF, NRF, AUSF, and NEF), and further allows communication with the UE 16, gNodeB 22, UPF 12, and DN 20, for example, as Figure 1According to some examples, some or all NFs may be executed as software on a single device, which may be configured to allow communication between NFs. According to some examples, the communication interface 206 may be coupled to a communication network that allows communication with NFs that may be located on a separate device different from the UPF 12 and other external devices (such as UE 16, gNodeB 22, and DN 20).

[0033] By way of example only, the communication network may include a local area network (LAN) or a wide area network (WAN), and may use TCP / IP and industry standard protocols over Ethernet, although other types or numbers of protocols or communication networks may be used. In this example, the communication network may employ any suitable interface mechanism and network communication technology, including, for example, any suitable form of telecommunication service (e.g., voice, modem, etc.), a public switched telephone network (PSTN), an Ethernet-based packet data network (PDN), combinations thereof, and the like.

[0034] The UPF 12 may include a GPRS Tunneling Protocol Firewall (GTPFW) 14. The GTPFW 14 may monitor and control all traffic from the gNodeB 22 and ensure that all traffic comes from a verified source and satisfies all necessary credentials to prevent interception and other attacks. The GTPFW 14 may provide full control over the signaling stack and may not require any network configuration on the PS node. The GTPFW 14 may be deployed independently or may be supplemented with additional protocols as additional modules as needed.

[0035] refer to Figure 1 and 2 , the network traffic manager device 24 can perform any number of functions, such as providing protection within the 5G core network as described herein. In this example, the network traffic manager device 24 includes a processor 202, a memory 204, and a communication interface 206 coupled together by a bus, although in other configurations, the network traffic manager device 24 may include other types or numbers of elements. In addition, although the network traffic manager device 24 is described herein as an apparatus, it should be understood that in some examples, the network traffic manager device 24 can be virtualized and some or all of the functions of the network traffic manager device 24 described herein can be embodied in software.

[0036] The processor 202 of the network traffic manager device 24 can execute programmed instructions stored in the memory 204 of the network traffic manager device 24 for any number of the functions described and illustrated herein. For example, the processor 202 of the network traffic manager device 24 can include one or more central processing units (CPUs) or a general-purpose processor having one or more processing cores, although other types of processors can also be used.

[0037] The memory 204 of the network traffic manager device 24 stores these programmed instructions for one or more aspects of the present technology as described and illustrated herein, although some or all of the programming instructions may be stored elsewhere. Various different types of memory storage devices such as RAM, ROM, hard disk, solid state drive, flash memory or other computer readable media can be used for memory, and the computer readable media is read and written by a magnetic, optical or other read-write system coupled to the processor.

[0038] Thus, the memory of the network traffic manager device 24 may store one or more modules that may include computer-executable instructions that, when executed by the network traffic manager device 24, cause the network traffic manager device 24 to perform actions such as transmitting, receiving, or otherwise processing network messages, for example, and perform the operations described below with reference to Figures 1 to 4 Other actions described and shown. The modules can be implemented as components of other modules. In addition, modules can be implemented as applications, software programs, operating system extensions, plug-ins, etc.

[0039] Although in this example, the network traffic manager device 24 is shown as including a single device, in other examples, the network traffic manager device 24 may include multiple devices or blades, each device or blade having one or more processors (each processor having one or more processing cores) that implement one or more steps of the present technology. In these examples, one or more of the devices may have a dedicated communication interface or memory. Alternatively, one or more of the devices may utilize memory, communication interfaces, or other hardware or software components of one or more other devices included in the mobile network 10.

[0040] Additionally, in other examples, one or more of the devices that together comprise the network traffic manager device 24 may be standalone devices or integrated with one or more other devices or apparatuses, such as, for example, one or more server devices. Moreover, in these examples, one or more of the devices of the network traffic manager device 24 may be in the same or different communication networks, including, for example, one or more public, private, or cloud networks.

[0041] Although the network traffic manager device 24 is shown as a single device, one or more actions of each of the network traffic manager devices 24 may be distributed across one or more different network computing devices that together include one or more of the network traffic manager devices 24. Moreover, the network traffic manager device 24 is not limited to a particular configuration. Thus, the network traffic manager device 24 may include network computing devices that operate using a master / slave approach, whereby one of the network computing devices of the network traffic manager device 24 operates to manage or otherwise coordinate the operations of another network computing device. The network traffic manager device 24 may operate as multiple network computing devices within a cluster architecture, a peer-to-peer architecture, a virtual machine, or a cloud architecture.

[0042] Therefore, the techniques disclosed herein should not be construed as limited to a single environment, and other configurations and architectures are also contemplated. For example, in some examples, one or more of the modules of the network traffic manager device 24 may be an integrated software component of a device such as the network traffic manager device 24. In some examples, one or more of the modules of the network traffic manager device 24 may run as a separate container in a cloud-based deployment and may interact with the network traffic manager device 24 or any other NF.

[0043] Even further, these modules can operate in a cloud-based computing environment. The modules can be executed in or as a virtual machine or virtual server that can be managed in a cloud-based computing environment. Moreover, the modules and even the network traffic manager device 24 itself can be located in a virtual server that runs in a cloud-based computing environment rather than being tied to one or more specific physical network computing devices. Moreover, the modules may be running in one or more VMs executing on a security server device. In addition, in one or more examples of the present technology, the virtual machines running on the network traffic manager device 24 can be managed or supervised by a hypervisor.

[0044] Although an exemplary 5G system architecture with a network traffic manager device 24, UE devices 16, gNodeB 22, DN 20, and various NFs is described and shown herein, other types or numbers of systems, devices, components, or elements in other topologies may be used. It should be understood that the example systems described herein are for exemplary purposes, as many variations of the specific hardware and software used to implement the examples are possible, as will be appreciated by those skilled in the relevant art.

[0045] One or more of the components depicted in the 5G system architecture 10, such as the network traffic manager device 24 and various NFs, can be configured to operate as virtual instances on the same physical machine. In other words, the network traffic manager device 24 and one or more of the various NFs can operate on the same physical device, rather than as independent devices that communicate through a communication network. Figure 1 There may be more or fewer instances of the network traffic manager device 24 or various NFs in the different configurations shown.

[0046] In addition, two or more computing systems or devices may replace any of the systems or devices in any example. Therefore, the principles and advantages of distributed processing, such as redundancy and replication, may also be implemented as needed to improve the robustness and performance of the devices and systems of the examples. The examples may also be implemented on a computer system that extends across any suitable network using any suitable interface mechanism and traffic technology, including (by way of example only) a wireless traffic network, a cellular traffic network, a packet data network (PDN), the Internet, an intranet, and combinations thereof.

[0047] For one or more aspects of the present technology, examples may be embodied as one or more non-transitory computer-readable media having instructions stored therein, such as in a memory of a network traffic manager device 24, as described and shown with reference to the examples herein. In some examples, the instructions include executable code that, when executed by one or more processors (such as a processor of the network traffic manager device 24), may cause the processor to perform the steps necessary to implement the methods of the examples of the present technology described and shown herein.

[0048] Reference Figures 1 to 4 An exemplary method for providing protection for a 5G core network is described. More specifically, reference is made to Figure 4 , a flow chart of an example method 400 for providing protection for a 5G core network is shown. As described in detail above, gNodeB 22 communicates with UPF 12 via tunnel interface N3. A malicious user at user equipment 16 may send random messages to gNodeB 22 via tunnel interface N3 and trigger multiple error messages from gNodeB 22 in an attempt to elicit legitimate messages.

[0049] To protect the network from such attacks, in step 405 in this example, the network traffic manager device 24 may receive a user plane status indicating whether the user plane 12 has been restarted from the network repository function. The user plane status may be received from the network repository function after the network traffic manager device 24 registers the user plane status with the network repository function. The network traffic manager device 24 checks whether the user plane 12 has been restarted because even legitimate traffic may trigger an error message from the gNodeB 22 if the user plane 12 has been restarted. Therefore, the network traffic manager device 24 may verify whether the error message received from the gNodeB 22 is accurate by checking the user plane status from the network repository function.

[0050] In step 410, the network traffic manager device 24 may then determine whether the amount of error messages flowing from the user plane 12 to the gNodeB 22 of the source at the user equipment 16 exceeds a predetermined threshold. As mentioned in step 405, the malicious user at the user equipment 16 sends random messages to the gNodeB 22. When the amount of error messages flowing from the user plane 12 to the gNodeB 22 exceeds the predetermined threshold, this may be an indication that a malicious user is sending requests at the user equipment 16. Considering that the network traffic manager device 24 has verified in step 405 that the error messages from the gNodeB 22 are accurate and are not the result of a user plane 12 restart, when the amount of error messages exceeds the predetermined threshold, there is a high likelihood that the user at the user equipment 16 is malicious.

[0051] In step 415, the network traffic manager device 24 may block all messages from flowing to the source's gNodeB 22 in response to determining that the amount of error messages exceeds a predetermined threshold and determining that the user plane 12 has not been restarted, wherein the messages include error messages and legitimate messages. By blocking all messages from flowing to the gNodeB 22, the network traffic manager device 24 is able to prevent a malicious user at the user equipment 16 from accidentally triggering a legitimate response from the gNodeB 22, thereby granting the malicious user at the user equipment 16 access to the mobile network 10. When the network traffic manager device 24 determines that the amount of error messages exceeds a predetermined threshold and determines that the user plane 12 has not been restarted, the network traffic manager device 24 may also store the source at the user equipment 16 as a graylist actor to ensure that future responses from the gNodeB 22 are blocked from being sent to the user equipment 16. The network traffic manager device 24 may continue to block all messages from the user plane 12 of the source at the user equipment 16 to the gNodeB 22 until the source at the user equipment 16 is removed as a graylist actor. By blocking all messages to the gNodeB 22 at the source at the user equipment 16, TEID detection becomes difficult for malicious users at the user equipment 16.

[0052] In step 420, the network traffic manager device 24 may then determine the amount of backhaul messages flowing from the user plane 12 to the gNodeB 22 and whether the user plane 12 has restarted. If the amount of backhaul messages is zero and the user plane 12 has not restarted (meaning that legitimate traffic is receiving accurate responses), then the lack of backhaul messages indicates that the gNodeB 22 has no active connections on the user plane 12. When there are no active connections, there is a high likelihood that the user at the user equipment 16 sending the message to the gNodeB 22 is a malicious actor.

[0053] Thus, in step 425, the network traffic manager device 24 may store the source as a bad actor to prevent future attacks in response to determining that the amount of backhaul messages from the user plane 12 to the gNodeB 22 is below a second predetermined threshold and the user plane 12 has not been restarted. The network traffic manager device 24 may program the FPGA to drop all packets from the stored bad actor, which may be marked as a blocklisted actor. Users on the user equipment 16 may continue to be stored as bad actors for a specified time until the attack is mitigated.

[0054] In step 430, in response to determining that the amount of backhaul messages from the user plane 12 to the gNodeB 22 is above a second predetermined threshold, the network traffic manager device 24 may determine whether the updated amount of error messages flowing from the user plane 12 to the source's gNodeB 22 is less than the previous amount of error messages, where the previous amount of error messages is the amount of error messages. When the amount of backhaul messages from the user plane 12 is above the second predetermined threshold or is not equal to zero, the likelihood that the user at the user equipment 16 is malicious is medium. If the network traffic manager device 24 determines that the error message ratio is decreasing, the network traffic manager device 24 may determine that the source at the user equipment 16 is not a malicious actor and remove the source at the user equipment 16 as a graylist actor stored in the memory.

[0055] In step 435, the network traffic manager device 24 may unblock all messages flowing to the source gNodeB 22 in response to determining that the updated error message volume flowing from the user plane 12 to the source gNodeB 22 is less than the previous error message volume and end the exemplary process.

[0056] Having thus described the basic concepts of the present invention, it will be quite apparent to those skilled in the art that the foregoing detailed disclosure is intended to be presented by way of example only and is not restrictive. Although not expressly stated herein, various changes, improvements and modifications will occur and are intended to be used by those skilled in the art. These changes, improvements and modifications are intended to be proposed hereby and are within the spirit and scope of the present invention. In addition, except as may be specified in the claims, the order of the listed processing elements or sequences or the use of numbers, letters or other names is therefore not intended to limit the claimed process to any order. Therefore, the present invention is limited only by the following claims and their equivalents.

Claims

1. A method implemented by a network traffic management system including one or more network traffic management devices and a network function (NF), the method comprising: receiving, from a network repository function, a user plane status indicating whether the user plane was restarted; determining whether the amount of error messages flowing from the user plane to the source gNodeB exceeds a predetermined threshold; In response to determining that the amount of error messages exceeds a predetermined threshold and determining that the user plane is not restarted, blocking all messages from flowing to the gNodeB of the source, wherein the messages include error messages and legitimate messages; determining the amount of backhaul messages flowing from the user plane to the gNodeB and whether the user plane is restarted; and In response to determining that the amount of backhaul messages from the user plane to the gNodeB is below a second predetermined threshold and the user plane is not restarted, storing the source as a bad actor.

2. The method of claim 1 , wherein in response to determining that the amount of error messages does not exceed a predetermined threshold or determining that the user plane has been restarted, unblocking the message from flowing to the gNodeB of the source.

3. The method according to claim 1, further comprising: In response to determining that the amount of backhaul messages from the user plane to the gNodeB is above the second predetermined threshold, determining whether an updated amount of error messages flowing from the user plane to the gNodeB of the source is less than a previous amount of error messages, wherein the previous amount of error messages is the amount of error messages; and In response to determining that the updated amount of error messages flowing from the user plane to the gNodeB of the source is less than the previous amount of error messages, all of the messages are unblocked from flowing to the gNodeB of the source.

4. The method of claim 3, wherein in response to determining that the updated error message amount flowing from the user plane to the source gNodeB is equal to or greater than the previous error message amount, continuing to block all of the messages from flowing to the source gNodeB.

5. The method of claim 1, wherein when the amount of error messages exceeds the predetermined threshold, the source is stored as a grey-list actor, and wherein the messages continue to be blocked from going to the source until the source is no longer stored as the grey-list actor.

6. A network traffic management device, comprising: a memory including programming instructions stored thereon; and one or more processors configured to execute the stored programmed instructions to: receiving, from a network repository function, a user plane status indicating whether the user plane was restarted; determining whether the amount of error messages flowing from the user plane to the source gNodeB exceeds a predetermined threshold; In response to determining that the amount of error messages exceeds a predetermined threshold and determining that the user plane is not restarted, blocking all messages from flowing to the gNodeB of the source, wherein the messages include error messages and legitimate messages; determining the amount of backhaul messages flowing from the user plane to the gNodeB and whether the user plane is restarted; and In response to determining that the amount of backhaul messages from the user plane to the gNodeB is below a second predetermined threshold and the user plane is not restarted, storing the source as a bad actor.

7. The apparatus of claim 6, wherein in response to determining that the error message amount does not exceed a predetermined threshold or determining that the user plane has been restarted, unblocking the message from flowing to the gNodeB of the source.

8. The device of claim 6, wherein the one or more processors are further configured to be capable of executing the stored programmed instructions to: In response to determining that the amount of backhaul messages from the user plane to the gNodeB is above the second predetermined threshold, determining whether an updated amount of error messages flowing from the user plane to the gNodeB of the source is less than a previous amount of error messages, wherein the previous amount of error messages is the amount of error messages; and In response to determining that the updated amount of error messages flowing from the user plane to the gNodeB of the source is less than the previous amount of error messages, all of the messages are unblocked from flowing to the gNodeB of the source.

9. The apparatus of claim 8, wherein in response to determining that the updated error message amount flowing from the user plane to the source gNodeB is equal to or greater than the previous error message amount, continuing to block all of the messages from flowing to the source gNodeB.

10. The apparatus of claim 6, wherein when the amount of error messages exceeds the predetermined threshold, the source is stored as a greylist actor, and wherein the messages continue to be blocked from going to the source until the source is no longer stored as the greylist actor.

11. A non-transitory computer readable medium having stored thereon instructions including executable code, which when executed by one or more processors causes the one or more processors to: receiving, from a network repository function, a user plane status indicating whether the user plane was restarted; determining whether the amount of error messages flowing from the user plane to the source gNodeB exceeds a predetermined threshold; In response to determining that the amount of error messages exceeds a predetermined threshold and determining that the user plane is not restarted, blocking all messages from flowing to the gNodeB of the source, wherein the messages include error messages and legitimate messages; determining the amount of backhaul messages flowing from the user plane to the gNodeB and whether the user plane is restarted; and In response to determining that the amount of backhaul messages from the user plane to the gNodeB is below a second predetermined threshold and the user plane is not restarted, storing the source as a bad actor.

12. The non-transitory computer-readable medium of claim 11, wherein in response to determining that the error message volume does not exceed a predetermined threshold or determining that the user plane has been restarted, unblocking the message from flowing to the gNodeB of the source.

13. The non-transitory computer-readable medium of claim 11, further comprising instructions that, when executed by the one or more processors, cause the one or more processors to: In response to determining that the amount of backhaul messages from the user plane to the gNodeB is above the second predetermined threshold, determining whether an updated amount of error messages flowing from the user plane to the gNodeB of the source is less than a previous amount of error messages, wherein the previous amount of error messages is the amount of error messages; and In response to determining that the updated amount of error messages flowing from the user plane to the gNodeB of the source is less than the previous amount of error messages, all of the messages are unblocked from flowing to the gNodeB of the source.

14. The non-transitory computer-readable medium of claim 13, wherein in response to determining that the updated error message amount flowing from the user plane to the source gNodeB is equal to or greater than the previous error message amount, continuing to block all of the messages from flowing to the source gNodeB.

15. The non-transitory computer-readable medium of claim 11, wherein when the amount of error messages exceeds the predetermined threshold, the source is stored as a greylist actor, and wherein the messages continue to be blocked from going to the source until the source is no longer stored as the greylist actor.

16. A network traffic management system comprising one or more network traffic management modules and a network function (NF), the network function having a memory having programmed instructions stored thereon and one or more processors, the one or more processors being configured to be able to execute the stored programmed instructions to: receiving, from a network repository function, a user plane status indicating whether the user plane was restarted; determining whether the amount of error messages flowing from the user plane to the source gNodeB exceeds a predetermined threshold; In response to determining that the amount of error messages exceeds a predetermined threshold and determining that the user plane is not restarted, blocking all messages from flowing to the gNodeB of the source, wherein the messages include error messages and legitimate messages; determining the amount of backhaul messages flowing from the user plane to the gNodeB and whether the user plane is restarted; and In response to determining that the amount of backhaul messages from the user plane to the gNodeB is below a second predetermined threshold and the user plane is not restarted, storing the source as a bad actor.

17. The system of claim 16, wherein in response to determining that the error message volume does not exceed a predetermined threshold or determining that the user plane has been restarted, unblocking the message from flowing to the gNodeB of the source.

18. The system of claim 16, wherein the one or more processors are further configured to be capable of executing the stored programmed instructions to: In response to determining that the amount of backhaul messages from the user plane to the gNodeB is above the second predetermined threshold, determining whether an updated amount of error messages flowing from the user plane to the gNodeB of the source is less than a previous amount of error messages, wherein the previous amount of error messages is the amount of error messages; and In response to determining that the updated amount of error messages flowing from the user plane to the gNodeB of the source is less than the previous amount of error messages, all of the messages are unblocked from flowing to the gNodeB of the source.

19. The system of claim 18, wherein in response to determining that the updated error message amount flowing from the user plane to the source gNodeB is equal to or greater than the previous error message amount, continuing to block all of the messages from flowing to the source gNodeB.

20. The system of claim 16, wherein when the amount of error messages exceeds the predetermined threshold, the source is stored as a greylist actor, and wherein the messages continue to be blocked from going to the source until the source is no longer stored as the greylist actor.

Images