Methods and apparatuses for determining security attacks in core network

Abstract

In a first aspect of the present disclosure, there is presented a method performed by a system for determining low-rate DDoS attack in a communications system. The method comprises sending, by a Service Producer Entity, a request to an Analyser Entity to analyze network traffic of the Service Producer Entity, if a number of service requests received from a Service Consumer Entity in a time interval, t, is higher than a threshold value, th. The method further comprises, after receiving the request, determining, by the Analyser Entity, the low-rate DDoS attack based on at least one characteristic of the network traffic of the Service Producer Entity obtained within a pre-determined time interval, t'.

Description

[0001]Methods and Apparatuses for Determining Security Attacks in Core Network Technical Field The disclosure relates to methods for determining security attacks in core networks and entities configured to operate in accordance with those methods. Background The Third Generation Partnership Project, 3GPP, has defined a Service Based Architecture, SBA, for the Fifth Generation Core, 5GC, network. Services are the essential building blocks used to create and execute the functions of a mobile network. The SBA delivers core network services as a set of interconnected Network Functions, NFs, which communicate with each other via Application Programming Interfaces, APIs. Each NF is formed by a combination of small pieces of software code, called microservices. Some microservices can even be re-used for different NFs, making implementation more effective and facilitating independent life- cycle management which allows upgrades and new functionalities to be deployed with zero impact on running services. One of the services managed by the NFs in the SBA is about security. The SBA for control plane, CP, security in the 5GC was introduced in the 3GPP Rel-15 specification. One of the main security attacks is Distributed Denial of Service, DDoS, attack which targets the availability of networks. In the DDoS attacks, attackers send a high volume of traffic or requests to a targeted network. They aim at overwhelming the network and making it unavailable to legitimate users. It is difficult to detect and prevent the DDoS attacks, as the attackers use multiple systems, often referred to as a botnet, to generate a high volume of traffic or requests. With respect to the attack scenario, the DDoS attacks are mainly divided into two types, volumetric DDoS attacks and low-rate (slow-rate) DDoS attacks. In volumetric DDoS attacks, the attackers try to consume the resources of the victim, such as bandwidth or memory or Central Processing Unit, CPU, by frequently flooding the victim with a massive number of bogus packets. The volumetric DDoS attacks might be detected by Intrusion Detection Systems, IDS. However, the low-rate DDoS attacks benefit from existing vulnerabilities in the connection between the attacker and the victim. The attackers try to carry out the attack quietly. Within a short period, the attackers open a number of connections with the victim server and keep those connections open for a long time. Then they repeat the process. The victim server should spare some resources, such as memory or process power, for those opened connections. Therefore, the server is exhausted after a while and denies service for its legitimate clients. The low-rate attacks may be more dangerous in the case of critical operation scenarios in the 5GC network. During the attack on the 5GC network, the attackers deteriorate quality-of- service, QoS, and, even in the worst case, cripple the network functionality, while hiding themselves. A paper by Kim, Ye-Eun et al. (2022) entitled: “Effective Feature Selection Methods to Detect IoT DDoS Attack in 5G Core Network” carries out an experimental study to find the best feature set for DDoS attack detection in 5GC network for user plane, UP, security. However, no defense mechanism has been proposed in the study. In CN102457489A, authors propose a module for attacking, detecting and defending of Low-rate Denial of Service, LDoS, attack. They developed a detection algorithm based on time window statistics. A test result demonstrates that the technique can be effectively applied to identify the LDoS attacks. In CN113206859A, using a flow feature extraction tool, authors extract features from network flow and form Low-rate Distributed Denial of Service, LDDoS, attack data set. They use statistical threshold and feature engineering to obtain typical feature information of the LDDoS attacks and train a mixed deep learning model by typical feature information to obtain a model with best detection performance. However, there is no defense mechanism against the low-rate DDoS attacks in the SBA of the 5GC network for CP security. Against this background, there remains a need of a real-time defense mechanism to detect the low-rate application layer DDoS attacks in the 5GC network environment. Summary Accordingly, an object of aspects and embodiments herein is to address the above issues. In a first aspect of the present disclosure, there is presented a method performed by a system for determining low-rate DDoS attack in a communications system. The method comprises sending, by a Service Producer Entity, a request to an Analyser Entity to analyze network traffic of the Service Producer Entity, if number of service requests received from a Service Consumer Entity in a time interval, t, is higher than a threshold value, th. The method further comprises, after receiving the request, determining, by the Analyser Entity, the low-rate DDoS attack based on at least one characteristic of the network traffic of the Service Producer Entity obtained within a pre-determined time interval, t’. In a second aspect of the present disclosure, there is presented a method performed by an Analyser Entity for determining low-rate DDoS attack in a communications system. The method comprises receiving, from a Service Producer Entity, a request to analyze network traffic of the Service Producer Entity. The method further comprises, obtaining at least one characteristic of the network traffic of the Service Producer Entity within a pre-determined time interval, t’. The method further comprises, determining the low-rate DDoS attack, based on the at least one characteristic. In a third aspect of the present disclosure, there is presented a method performed by a Service Producer Entity for determining low-rate DDoS attack in a communications system. The method comprises sending (S501, S303) a request to the AE (400) to analyse network traffic of the SPE (300), if number of service requests received by the SPE (300) from a Service Consumer Entity, SCE, (200) in a time interval, t, is higher than a threshold value, th. In a fourth aspect of the present disclosure, a system, for determining low- rate DDoS attack in a communications system, is provided. The system, comprising a processor and a memory, the memory containing instructions executable by the processor, is configured to perform the method of the first aspect. In a fifth aspect of the present disclosure, an Analyser Entity, for determining low-rate DDoS attack in a communications system, is provided. The Analyser Entity, comprising a processor and a memory, the memory containing instructions executable by the processor, is configured to perform the method of the second aspect. In a sixth aspect of the present disclosure, a Service Producer Entity, for determining low-rate DDoS attack in a communications system, is provided. The Service Producer Entity, comprising a processor and a memory, the memory containing instructions executable by the processor, is configured to perform the method of the third aspect. In a seventh aspect of the present disclosure, a computer program for determining low-rate DDoS attack in a communications system, is provided. The computer program comprises instructions which, executed by processing circuitry of a system and / or an Analyser Entity and / or a Service Producer Entity, cause the system and / or the Analyser Entity and / or the Service Producer Entity to perform a method according to the first, the second and the third aspects, respectively. In an eighth aspect of the present disclosure, a computer program product for determining low-rate DDoS attack in a communications system, is provided. The computer program product comprises a computer program according to the seventh aspect, and a computer-readable storage medium on which the computer program is stored. The computer- readable storage medium can be a non-transitory computer-readable storage medium. Advantageously these aspects provide a real-time detection of the low-rate application layer DDoS attacks in the 5GC network environment. While doing so, these aspects advantageously introduce only a negligible amount of extra communication cost and computation overhead, when compared to existing methods which are based on machine learning, ML, or deep learning, DL, algorithms, with high computation overhead and high complexity cost, consuming the memory and process power of underlying network. Advantageously these aspects are software-based, utilizing the existing network infrastructure without requiring additional hardware. Advantageously these aspects also meet the criterion for low latency which is one of the main advantages of the 5G technology. Brief Description of the Drawings For a better understanding of the inventive concept, and to show how it may be put into effect, reference will now be made, by way of exemplary embodiments, to the accompanying drawings. In these drawings: Fig. 1 shows a schematic illustration of the Fifth Generation New Radio, 5G NR, architecture; Fig. 2 shows a schematic illustration of a system where the proposed solution is applied; Fig. 3 shows a flow diagram of method steps as performed according to the third aspect; Fig. 4 shows a flow diagram of method steps as performed according to the second aspect; Fig. 5 shows models to obtain a predicted value of at least one characteristic belonging to NFs / AFs in the network where the NFs / AFs are grouped based on the category of their functionality; Fig. 6 shows a model to obtain a predicted value of at least one characteristic belonging to NFs / AFs in the network where the NFs / AFs are not grouped based on the category of their functionality; Fig. 7 shows a signaling diagram of method steps as performed according to the first aspect; Fig.8 shows a schematic architectural view (in terms of functional units) of a Service Producer Entity and an Analyser Entity; Figs. 9 shows a schematic illustration of a computer program product, according to some example implementations of the present disclosure; Figs. 10 shows a schematic illustration (in terms of functional modules) of the Service Producer Entity; Figs. 11 shows a schematic illustration (in terms of functional modules) of the Analyser Entity; Fig. 12 shows boxplot graphs of the number of service requests during normal and DDoS-attack traffics; Fig. 13 shows General Likelihood Ratio Test, GLRT, and Receiver Operating Characteristic, ROC, plot used to select threshold; Fig. 14 shows Auto-Regressive Integrated Moving Average, ARIMA, model parameters obtained during a training phase; Fig.15 shows real and predicted values of number of service requests; and Fig.16 shows distance between the predicted and the real values. Detailed Description In the following description, for purposes of explanation and not limitation, specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be apparent to one of skill in the art that the present disclosure may be practiced in other embodiments that depart from these specific details. Those skilled in the art will appreciate that the examples outlined herein may be implemented using individual hardware circuits, using software functioning in conjunction with a programmed microprocessor or general- purpose computer, using one or more application specific integrated circuits (ASICs) and / or using one or more digital signal processors (DSP). It will also be appreciated that when the present disclosure is described in terms of a method, it may also be embodied in one or more processors and one or more memories coupled to the one or more processors, wherein the one or more memories store one or more computer programs that perform the steps, services and functions disclosed herein when executed by the one or more processors. Like numbers refer to like elements throughout the description. Any step or feature illustrated by dashed / dotted lines should be regarded as optional. As stated in the Background section, the present disclosure provides a real- time defense mechanism against the low-rate application layer DDoS attacks in the SBA of the 5GC network for CP security. Fig.1 shows a schematic illustration of the 5G NR architecture. The 5GC part of the 5G NR comprises a Network Slice Selection Function, NSSF, 10, a Network Exposure Function, NEF, 11, a Network Repository Function, NRF, 12, a Policy Control Function, PCF, 13, a Unified Data Management, UDM, 14, an Application Function, AF, 15, an Authentication Server Function, AUSF, 16, an Access and Mobility Management Function, AMF, 17, a Session Management Function, SMF, 18, and a Network Data Analytics Function, NWDAF, 2. The 5GC is a new network architecture introduced in the 3GPP Release 15. The 5GC networks are based on the SBA which is centered around NF services. An NF service is one type of capability exposed by an NF (NF Service Producer) to other authorized NF (NF Service Consumer) through a service- based interface, SBI, e.g., Nnssf, Nnef, Nnrf, Npcf, Nudm, Naf, Nausf, Namf, Nsmf and Nnwdaf. An NF may expose one or more NF services. NF services may communicate directly between NF Service Consumers and NF Service Producers, or indirectly via a Service Communication Proxy, SCP (not shown in Fig.1). In the SBI architecture, the NF Service Consumer creates and operates on resources provided by the NF Service Producer services. Reference points, N1, N2, N3, N4, N6 and N9 are point to point interfaces connecting network elements. A User Equipment, UE, 1, is connected to the Radio Access Network, RAN, 19, wherein a User Plane Function, UPF, 20 is provided to connect the UE 1 to a data network, DN, 21. The 5GC builds on the CP and UP separation. The CP carries the signaling traffic, while the UP carries the user traffic or data packets. One of the authorization mechanisms used in the SBA is the token-based authorization specified in clause 13.4.1 of TS 33.501 and clauses 5.4 and 6.3 of TS 29.510. According to this mechanism, the NRF assumes the role of authorization server. The NF Service Consumer requests an access token from the NRF to be used towards the NF Service Producer and then sends the service request with the received token to the NF Service Producer. Within the 5GC network, all NFs must support mutually authenticated Transport Layer Security, TLS, and HyperText Transport Protocol, HTTP or HTTP / 2, and thus use client and server certificates to protect the CP signaling. According to TS 29.500, HTTP / 2 is mandatory for the application layer serialization protocol. The NFs within the 5GC are already authenticated and allowed to communicate with each other based on successful authentication and authorization. Even if previously authenticated and authorized, the NF may be misconfigured or its internal data may be corrupted or there may be another reason for anomalous behavior. Then, the assumption of trust on that NF becomes invalid and the NF may cause potential threats and exploits. The 5GC supports different NF deployments. For example, in distributed or redundant fashion, the NFs can provide the services from several locations and several execution instances. When the NFs are distributed across diverse cloud infrastructures, it is possible that the NFs may behave in an undefined manner. Due to existing vulnerabilities in protocols, such as HTTP / 2 and Packet Control Forwarding Protocol, PCFP, the low-rate application layer attack, such as Slowloris and R.U.D.Y, is still one of the main threats in the SBA architecture. Slowloris is a DDoS attack software which opens multiple connections to the targeted server and keeping them open as long as possible. It does this by continuously sending partial HTTP requests, none of which are ever completed. Ultimately, the targeted server’s maximum concurrent connection pool is filled and additional legitimate connection attempts are denied. R.U.D.Y sends a legitimate HTTP POST request with an abnormally long ‘content-length’ header field. By sending numerous small packets, at a very slow rate, it creates a massive backlog of application threads, while the long ‘content-length’ field prevent the server from closing the connection. Ultimately, the attack exhausts the targeted server’s connection table, causing the server to crash. In such circumstances, in the literature, an analytics function, e.g., the NWDAF, is used to detect the anomaly by monitoring the behavior of all NFs and ensure that the NFs behave as defined. So that appropriate steps can be taken, e.g., by an operator, to control the potentially damaging behavior, if the NFs behave erroneously. The embodiments disclosed herein relate to improved techniques for determining the DDoS attacks in the 5GC networks. The techniques are specifically for the low-rate application layer DDoS attacks in the SBA of the 5GC network for CP security. For this, a two-step collaborative approach is introduced. In the first step, a threshold-based approach is applied to determine an anomaly. In the second step, a prediction-based approach, e.g., a time-series-based approach, is applied to determine whether the anomaly is resulted from the low-rate DDoS attack. Fig. 2 illustrates a system 100 where the embodiments presented herein can be applied. In order to realize the techniques, there is provided a Service Producer Entity, SPE, 300; an Analyser Entity, AE, 400 which is being communicatively connected to the SPE 300; methods performed by the SPE 300, the AE 400 and the system 100 comprising the SPE 300 and the AE 400; and computer program products comprising codes that when run on the SPE 300, the AE 400 and the system 100, causes them to perform the methods. The light-weight two-step collaborative approach, the methods performed by the SPE 300 in the first step and the methods performed by the AE 400 in the second step, benefits from the NWDAF data analysis power and increases the granularity to detect DDoS samples, making the solution scalable. The system 100 also comprises a Service Consumer Entity, SCE, 200 which sends service request(s) to the SPE 300 and a Network Entity, NE, 500 to which notification(s) are sent by the AE 400 according to embodiments that will be detailed later in the description. It will be appreciated that the members 200, 300, 400 and 500 of the system 100 are not limited to any particular number of nodes, devices or entities. For the sake of clarity and ease of description, but without loss of generality, only one of the members 200, 300, 400 and 500 of the system 100 will explicitly be mentioned hereinafter in the description. It will also be appreciated that the members 200, 300, 400 and 500 of the system 100 can be realized as a respective standalone device or as a part of a device or a hardware (e.g., a radio device, a base station) or a software. Alternatively, their functionalities may be distributed over different physical or virtual entities which may either be part of the same network part or may be spread between at least two such network parts. Thus, a part of method steps performed according to embodiments may be executed in a physical / virtual entity, while another part of the method steps may be executed in another physical / virtual entity. The herein disclosed embodiments are not limited to any particular number of physical / virtual entities. Hence, the methods according to the herein disclosed embodiments are suitable to be performed in a cloud computational environment. Reference is now made to Figs. 3 and 4 which illustrate the steps of methods S300 and S400 performed by the SPE 300 and the AE 400, respectively, for determining the DDoS attacks in a communication network. In general, the term "obtain / obtaining" used in the present context includes "calculate / calculating, receive / receiving, actively retrieve / retrieving, measure / measuring or calculate / calculating the required piece of information from another entity / node / storage place". Although the steps are illustrated in Figs. 3 and 4 in particular orders, they can be performed in different orders than shown and can be combined and / or divided into operations having different functionality than shown. Optional steps are indicated by dashed lines. Reference is first made to Fig. 3 which illustrates the steps of method S300 performed by the SPE 300, according to the third aspect. S301: The SPE 300 receives service requests from the SCE 200. A service request refers to a specific action or communication initiated by a network function or an application to request a particular service from another network function or application within the 5G system. S302: The SPE 300 compares number (amount) of service requests received S301 from the SCE 200 in a time interval, t, with a threshold value, th. S303: The SPE 300 sends a request to the AE 400 to analyze network traffic of the SPE 300, if the number of the service requests is higher than the threshold value, th. The network traffic is the flow of information across a network. It relates to influx and outflow of data, or network packets, within an network. Hence, the network traffic is the amount of data, or network packets, passing through the network at any given moment. Since the present disclosure provides a real-time detection of the low-rate application layer DDoS attacks in the 5GC network environment, the network traffic herein refers to the CP traffic. It will be appreciated that the time interval, t, can be predefined based on any method. It will also be appreciated that the threshold value, th, can be predefined separately based on any method, e.g., based on averaging historical (previous) numbers of the service requests received in normal (benign) executions where packet traffics are known as to be attack-free (legitimate). The request (sending) S303 by the SPE 300 can be regarded as a notification for an anomaly and, hence, a request from the AE 400 for analysis on its network traffic in order to determine S403, in the next (second) step (prediction-based approach), whether the anomaly is resulted from the low-rate DDoS attack. Reference is now made to Fig. 4 which illustrates the steps of method S400 performed by the AE 400, according to the second aspect. S401: Being a corresponding step of the requesting S303, the AE 400 receives, from the SPE 300, the request to analyze the network traffic of the SPE 300. S402: The AE 400 obtains at least one characteristic of the network traffic of the SPE 300 within a pre-determined time interval, t’. The characteristic of a network traffic may be defined as a collection of parameters and / or features which characterises the network traffic in view of direction, load or type of traffic. Examples of the at least one characteristic include, but are not limited to, at least one of number of forward packets sent by the SCE 200 to the SPE 300; number of backward packets sent by the SPE 300 to the SCE 200; total length of the forward packets; total length of the backward packets; average packet size of the forward packets; average packet size of the backward packets; number of (service) requests from each single node; arriving packet rate; Transmission Control Protocol, TCP, window size; number of HTTP requests; flow duration; number of simultaneous requests or TCP session time out. It will be appreciated that the pre-determined time interval, t’, within which the at least one characteristic is obtained S402 by the AE 400, can be defined as being different from the pre-defined time interval, t, or as being the same with the pre-defined time interval, t, within which the amount of service requests is received S301 by the SPE 300. S403: The AE 400 determines the low-rate DDoS attack, based on a predictive analysis, a predicted value, , of the at least one characteristic. The AE 400 can determine the low-rate DDoS attack, if a difference between the predicted value, , of the at least one characteristic and a real value, , of the at least one characteristic is higher than a pre-defined distance, d. The predictive analysis is a method used in data engineering to predict some occurrences, events or probabilities based on historical data. For example, we have a set of data, T = {18, 22, 21, 24, 19, 22, 24}, showing the hourly temperature of a room in degrees Celsius, °C, during a period between 12:00 and 18:00. In order to predict what the future / upcoming temperature would be, e.g., at 19:00, one way would be to take the average of the historical data which results in 21.42 °C. S403a: Hence, in some embodiments, the predicted , of the at least one characteristic can be obtained based on historical (past, previous) values of the at least one characteristic. In some embodiments, the predicted value, , of the at least one characteristic can be obtained by averaging the historical values of the at least one characteristic. In some embodiments, the historical values of the at least one characteristic and the historical predicted values of the at least one characteristic can be obtained in normal executions where packet traffics are known as to be attack-free (legitimate). In some embodiments, a model can be used to obtain S403a the predicted value, , of the at least one characteristic. In some embodiments, the model can be a time-series-based model, e.g., Auto-Regressive Integrated Moving Average, ARIMA, model. Different models can be generated and / or trained with the historical values of the at least one characteristic and the historical predicted values of the at least one characteristic belonging to NFs or AFs in the network, when there is no attack. The NFs or AFs can be grouped based on the category of their functionality, e.g., AMF, SMF, as illustrated in Fig. 5. Alternatively, the model can be more generalized by taking into consideration all the NFs or the AFs irrespective of their categories as illustrated in Fig.6. As the historical values of the at least one characteristic are obtained from the legitimate traffic, when there is no attack in the network, the predicted value, , is expected to be similar / close to those obtained from legitimate packet traffic. That is why the AE 400 determines S403 the low-rate DDoS attack, when the difference between the predicted value, , of the at least one characteristic and the real value, , of the at least one characteristic is higher than the pre-defined distance, d. S403b: Hence, similar to the case with the obtaining S403a the predicted value, , of the at least one characteristic, in some embodiments, the pre- defined distance, d, for the at least one characteristic can be obtained based on the historical values of the at least one characteristic mentioned above and historical predicted values of the at least one characteristic. Back to the temperature-related example mentioned above where the predicted value is 21.42 °C, let’s assume that the pre-defined distance, d, is obtained as being 5 for the corresponding characteristic of room temperature. If the real temperature (which corresponds to the real value, , of the at least one characteristic in our solution) is measured as 24 °C, the distance, 2.58, would be less than 5. Hence, there would be no anomalous behavior. If the real temperature is measured as 30 °C or 15 °C, the distance, 8.6 or 6.42, respectively, would be higher than the pre-defined distance, d. Hence, there would be an anomalous behavior. In some embodiments, the historical values of the at least one characteristic mentioned above and historical predicted values of the at least one characteristic are obtained in normal executions where packet traffics are known as being attack-free. In some embodiments, the pre-defined distance, d, for the at least one characteristic can be obtained S403b by the same model used to obtain S403a the predicted value, , of the at least one characteristic. Hence, the details explained above with reference to Figs. 5 and 6 apply to embodiments with regards to the pre-defined distance, d, for the at least one characteristic. Based on the structure and the historical values of the at least one characteristic, various distances, including all L-norms, e.g., L1 norm also known as Manhattan distance, can be used. To test if the obtained S403b pre-defined distance, d, for the at least one characteristic is a result of a DDoS attack, two methods of comparison can be utilized, a single-value method and a multiple-value (probability distribution similarity test) method. The single-value method involves two possible approaches. The first approach entails comparing the distance, d, value with a set of previous distances obtained from attack-free network traffic. By analyzing how the current distance, d, value deviates from the historical set, potential anomalies can be detected. The second approach involves subjecting the distance, d, value to an anomalous behavior test, such as chaotic behavior analysis. This test can help identify abnormal patterns or trends in the distance, d, values, indicative of potential attacks. Although the second approach by itself can follow the dynamic pattern of the network traffic to adapt the threshold, in the first approach the corresponding set can be updated by new distances that are labeled as legitimate ones therefore the set is always updated and can follow the dynamic pattern of the network traffic. The second, the multiple-value, method involves collecting a set of distance, d, values and examining their underlying probability distribution. This distribution is then compared with a probability distribution derived from a set of previous distances obtained from attack-free network traffic. Various statistical tests, such as Kolmogorov-Smirnov, Kullback-Leibler, Bhattacharyya, and others, can be employed to assess the similarity or dissimilarity between the distributions. Both test methods can be used simultaneously (concurrently) to enhance the robustness of the scheme and to meet specific requirements and to ensure a comprehensive analysis of the distance, d, values, and hence, to enable the detection of potential DDoS attacks with greater accuracy. S404: Depending on the determining S403, the AE 400 can transmit a notification to the NE 500 to perform at least one preventive and / or protective action to countermeasure the offending process. In some embodiments, the AE 400, which performs the method S400, is the NWDAF. Reference is now made to Fig.7 which illustrates the steps of method S500 performed by the system 100, according to the first aspect. In Fig. 7, the steps S501, S502, S503, S503a, S503b, and S504 correspond to the steps S303, S402, S403, S403a, S403b, and S404 respectively. S505: In response to the transmitting S404 the notification, the NE 500 performs the at least one preventive and / or protective action to countermeasure the offending process. For purposes of explanation and not limitation, the at least one first preventive and / or protective action pertains to at least one of: determining the address of the SCE 200 from which the SPE 300 having received the service requests where the low-rate DDoS attack is determined S403; labeling the SCE 200 as a threat; isolating the SCE 200; taking a snapshot of the system 100 as a backup and / or for a post-mortem analysis; or issuing a report of the determined S402 attack to an operator of the system 100. In some embodiments, the NE 500, which is notified by the AE 400, is the NRF 12 or an Operations, Administration and Maintenance, OAM or OA&M, function. The OAM function refers to processes used in provisioning and managing a network or element within a network. It is to be understood that the NE 500 can be a performer or an initiator of the at least one first preventive and / or protective action. Hence, in some embodiments, the NRF 12 performs or initiates the determining the Internet Protocol, IP, address of the SCE 200 which has already been registered to the NRF 12. Fig. 8 shows, in terms of a number of functional units, a schematic architectural view of the system 100, AE 400 and the SPE 300 which perform the steps disclosed above, e.g., according to the first, the second and the third aspects, respectively. A processing circuitry 310 is provided using any combination of one or more of a suitable central processing unit, CPU, multiprocessor, microcontroller, digital signal processor, DSP, etc., capable of executing software instructions stored in a computer program product 330A (as in Fig. 9), e.g., in the form of a storage medium 330. The processing circuitry 310 may further be provided as at least one application specific integrated circuit, ASIC, or field programmable gate array, FPGA. Particularly, the processing circuitry 310 is configured to cause the SPE 300 and the AE 400 to perform a set of operations, or steps, as disclosed above. For example, the storage medium 330 may store the set of operations, and the processing circuitry 310 may be configured to retrieve the set of operations from the storage medium 330 to cause the SPE 300 and the AE 400 to perform the set of operations. The set of operations may be provided as a set of executable instructions. Thus, the processing circuitry 310 is thereby arranged to execute methods as herein disclosed. The system 100, the SPE 300 and the AE 400 may further comprise a communications interface 320 which is provided for transmitting / receiving messages or any other data to / from other entities, functions, network nodes and / or other wireless devices. As such the communications interface 320 may comprise one or more transmitters and receivers, comprising analogue and digital components. The storage medium 330 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory. The processing circuitry 310 controls the general operation of the system 100, the SPE 300 and the AE 400, e.g., by sending data and control signals to the communications interface 320 and the storage medium 330, by receiving data and reports from the communications interface 320, and by retrieving data and instructions from the storage medium 330. Other components, as well as the related functionality, of the system 100, the SPE 300 and the AE 400 are omitted in order not to obscure the concepts presented herein. As depicted in Fig. 9, the computer program product 330A comprises computer program 330B code portions that, when executed a processing circuitry 310, configure the processing circuitry 310 to perform the method of any one of the example implementations in accordance with the first, the second or the third aspect. In the example of Fig. 9, the computer program product 330A is illustrated as an optical disc, such as a compact disc, CD, or a digital versatile disc, DVD, or a Blu-Ray disc. The computer program product 330A could also be embodied as a memory, such as a random access memory, RAM, a read- only memory, ROM, an erasable programmable read-only memory, EPROM, or an electrically erasable programmable read-only memory, EEPROM, and more particularly as a non-volatile storage medium of a device in an external memory such as a Universal Serial Bus, USB, memory or a Flash memory, such as a compact Flash memory. Thus, while the computer program 330A is here schematically shown as a track on the depicted optical disk, the computer program 330B can be stored in any way which is suitable for the computer program product 330A. Fig. 10 schematically illustrates, in terms of a number of functional modules, the components of the SPE 300 according to an embodiment. The SPE 300 of Fig. 10 comprises a sending module 303 configured to perform step S303. The SPE 300 of Fig. 10 may further comprise a number of optional functional modules; a receiving module 301 configured to perform step S301 and a comparing module 302 configured to perform step S302. In general terms, each functional module 301:303 may be implemented in hardware or in software. Preferably, one or more or all functional modules 301:303 may be implemented by the processing circuitry 310, possibly in cooperation with the communications interface 320 and the storage medium 330. The processing circuitry 310 may thus be arranged to from the storage medium 330 fetch instructions as provided by a functional module 301:303 and to execute these instructions, thereby performing any steps of the SPE 300 as disclosed herein. Fig.11 schematically illustrates, in terms of a number of functional modules, the components of the AE 400 according to an embodiment. The AE 400 of Fig. 11 comprises a number of functional modules; a receiving module 401 configured to perform step S401, an obtaining module 402 configured to perform step S402, and a determining module 403 configured to perform step S403. The AE 400 of Fig. 11 may further comprise a number of optional functional modules; such as an obtaining module 403a configured to perform step S403a, an obtaining module 403b configured to perform step S403b, and a transmitting module 404 configured to perform step S404. In general terms, each functional module 401:404 may be implemented in hardware or in software. Preferably, one or more or all functional modules 401:404 may be implemented by the processing circuitry 310, possibly in cooperation with the communications interface 320 and the storage medium 330. The processing circuitry 310 may thus be arranged to from the storage medium 330 fetch instructions as provided by a functional module 401:404 and to execute these instructions, thereby performing any steps of the AE 400 as disclosed herein. The SPE 300 and / or the AE 400 may be provided as a standalone device or as a part of at least one further device. For example, the SPE 300 and / or the AE 400 may be provided in a node of the radio access network or in a node of the core network. Alternatively, functionality of the SPE 300 and / or the AE 400 may be distributed between at least two devices or nodes. These at least two nodes or devices, may either be part of the same network part, such as the radio access network or the core network, or may be spread between at least two such network parts. In general terms, instructions that are required to be performed in real time may be performed in a device or node, operatively closer to the cell than instructions that are not required to be performed in real time. Thus, a first portion of the instructions performed by each of the SPE 300 and / or the AE 400 may be executed in a respective first device, and a second portion of the of the instructions performed by the SPE 300 and / or the AE 400 may be executed in a respective second device, and so on; the herein disclosed embodiments are not limited to any particular number of devices on which the instructions performed by the SPE 300 and / or the AE 400 may be executed. Hence, the methods according to the herein disclosed embodiments are suitable to be performed by a SPE 300 and / or an AE 400 residing in a cloud computational environment. Therefore, although a single processing circuitry 310 is illustrated in Fig. 8, the processing circuitry 310 may be distributed among a plurality of devices or nodes. The same applies to the functional modules 301:303 of Fig. 10 and 401:404 of Fig.11 and to the computer programs 330B of Fig.9. The capability of the present disclosure to determine low-rate DDoS attacks in a communications system 100 can be seen in an experiment below. In the experimental setup, a public dataset, including normal traffic and DDoS-attack traffic, e.g., slowloris DDoS attack traffic, was used. In the first step of the threshold-based approach, the number of service requests is sampled for each time interval, t = 1 second. As illustrated in Fig. 12, boxplot graphs of the number of service requests for both the normal and the DDoS-attack traffics are used, since they provide a quick visual summary of the variability of values in a dataset. They show the median, upper and lower quartiles, minimum and maximum values, and any outliers in the dataset. Outliers can reveal mistakes or unusual occurrences in data. Using the General Likelihood Ratio Test, GLRT, and the Receiver Operating Characteristic, ROC, plot, as shown in Fig. 13, the threshold, th, is selected as 14. The GLRT and the ROC curve are essential tools in binary classification for determining the optimal threshold to separate two classes. The GLRT compares the likelihood of data belonging to each class under different hypotheses, aiding in the identification of the threshold that maximizes class separation. On the other hand, the ROC curve graphically illustrates the trade-off between true positive rate and false positive rate at various threshold values. The threshold corresponding to the point on the ROC curve nearest to the top-left corner is considered the optimal threshold. Both methods contribute to improving the classification model's performance and decision-making capabilities, enhancing its ability to distinguish between the positive and negative classes. The threshold value, th1, is selected as 14 based on the concept of Youden's J statistic or Youden's index. Youden's J statistic is a commonly used metric to determine the optimal threshold that balances the true positive rate (sensitivity) and true negative rate (specificity) of a binary classifier, which is defined as: J = Sensitivity + Specificity – 1 In the second step of the prediction-based approach, the ARIMA prediction model is used to obtain the predicted value, , of the at least one characteristic. The at least one characteristic was selected as the amount of the service requests. So, the predicted value, , of the at least one characteristic was obtained based on historical values of the amount of the service requests. The ARIMA is a statistical analysis model that uses time-series data to either better understand the data set or to predict future trends. The general form of ARIMA (p,d,q) is defined as follows: where the parameters; p denotes the number of lag (previous) observations in the model, also known as the lag order (p is the order of Autoregressive component, AR(p)); d denotes the number of times that the raw observations are differenced; q denotes the size of the moving average window (the order of moving average component, MA(q) and shows how many of previous forecast error should be included in the formula). phi, ϕ, and theta, θ, are the parameters that represent the autoregressive, AR, and moving average, MA components, respectively. These parameters are used as the weight coefficient for the previous observations, Xt-aand the previous forecast errors, et-a, respectively. Xt, denotes the real value of a characteristic X, while denotes the predicted value of the characteristic X, predicted by k historical values, {Xt-k, Xt-k+1,…., Xt-1}, of the characteristic X. In order to use the ARIMA model, the parameters of p, d, q and corresponding coefficients need to be estimated during the training phase. While training the model using the normal traffic, cumulative flow duration is used for each 1 second. The first 400 samples are used for training. The result of the parameter estimation is shown in Fig. 14. According to the result, p, d, and q are selected as 4, 1 and 1, respectively. Once having trained, the model is used to predict upcoming values of the cumulative flow duration. Fig. 15 shows the predicted and the real values of the amount of the service requests. As seen in Fig. 15, the difference between the predicted and the real values increases during the attack. Fig. 16 shows that the distance between the predicted and the real values, proving that the distance is much higher during the attack traffic. It is to be understood that the examples and embodiments as explained above are merely illustrative and susceptible to various modifications. Moreover, it is to be understood that the above concepts may be implemented by using correspondingly designed software to be executed by one or more processors of an existing device or apparatus, or by using dedicated device hardware. Further, it should be noted that the illustrated apparatuses or devices may each be implemented as a single device or as a system of multiple interacting devices or modules.

Claims

Claims 1. A method (S500) for determining low-rate DDoS attack in a communications system (100), the communications system (100) comprising a Service Producer Entity, SPE, (300), being communicatively connected to an Analyser Entity, AE, (400), the method comprising: sending (S501, S303), by the SPE (300), a request to the AE (400) to analyse network traffic of the SPE (300), if a number of service requests received by the SPE (300) from a Service Consumer Entity, SCE, (200) in a time interval, t, is higher than a threshold value, th; and after receiving (S401) the request, determining (S503, S403), by the AE (400), the low-rate DDoS attack based on at least one characteristic of the network traffic of the SPE (300) obtained (S402) within a pre-determined time interval, t'.

2. The method as claimed in claim 1, wherein the determining (S503, S403) further comprising: determining (S503, S403) the low-rate DDoS attack, if a difference between a predicted value, , of the at least one characteristic and a real value, , of the at least one characteristic is higher than a pre-defined distance, d.

3. The method as claimed in claim 2, wherein the determining (S503, S403) further comprising:obtaining (S503a, S403a) the predicted value, , of the at least one characteristic based on historical values of the at least one characteristic; and obtaining (S503b, S403b) the pre-defined distance, d, based on the historical values of the at least one characteristic and historical predicted values of the at least one characteristic.

4. The method as claimed in claim 3, wherein the historical values of the at least one characteristic and the historical predicted values of the at least one characteristic are obtained in attack-free packet traffic.

5. The method as claimed in claims 3 or 4, wherein the obtaining (S503a, S403a) the predicted value, , of the at least one characteristic and / or the obtaining (S503b, S403b) the pre-defined distance, d, can be performed by a time-series-based model.

6. The method as claimed in any preceding claim, wherein the at least one characteristic pertains to at least one of: number of forward packets sent by the SCE (200) to the SPE (300); number of backward packets sent by the SPE (300) to the SCE (200); total length of the forward packets; total length of the backward packets; average packet size of the forward packets; average packet size of the backward packets; number of requests from each single node; arriving packet rate; Transmission Control Protocol, TCP, window size; number of Hypertext Transfer Protocol, HTTP, requests;flow duration; number of simultaneous requests; or TCP session time out.

7. The method as claimed in any preceding claim, further comprising: depending on the determining (S503, S403), transmitting (S504, S404), by the AE (400), a notification to a Network Entity, NE, (500) to perform (S505) at least one preventive and / or protective action.

8. The method as claimed in claim 7, wherein the at least one preventive and / or protective action pertains to at least one of: determining the address of the SCE (200) from which the SPE (300) having received (S301) the service requests; labeling the SCE (200) as a threat; isolating the SCE (200); taking a snapshot of the system (100) as a backup and / or for a post-mortem analysis; or issuing a report of the determined (S503, S403) attack to an operator of the system (100).

9. A method (S400) for determining low-rate DDoS attack in a communications system (100), the communications system (100) comprising a Service Producer Entity, SPE, (300), being communicatively connected to an Analyser Entity, AE, (400), the method is performed by the AE (400) and comprising: after receiving (S401) a request from the SPE (300), determining (S503, S403) the low-rate DDoS attack based on at leastone characteristic of the network traffic of the SPE (300) obtained (S402) within a pre-determined time interval, t'.

10. The method as claimed in claim 9, wherein the determining (S503, S403) further comprising: determining (S503, S403) the low-rate DDoS attack, if a difference between a predicted value, , of the at least one characteristic and a real value, , of the at least one characteristic is higher than a pre-defined distance, d.

11. The method as claimed in claim 10, wherein the determining (S503, S403) further comprising: obtaining (S503a, S403a) the predicted value, , of the at least one characteristic based on historical values of the at least one characteristic; and obtaining (S503b, S403b) the pre-defined distance, d, based on the historical values of the at least one characteristic and historical predicted values of the at least one characteristic.

12. The method as claimed in claim 11, wherein the historical values of the at least one characteristic and the historical predicted values of the at least one characteristic are obtained in attack-free packet traffic.

13. The method as claimed in claim 11 or 12, wherein the obtaining (S503a, S403a) the predicted value, , of the at least one characteristic and / or the obtaining (S503b, S403b) the pre-defined distance, d, can be performed by a time-series-based model.

14. The method as claimed in any one of claims 9 to 13, wherein the at least one characteristic pertains to at least one of: number of forward packets sent by the SCE (200) to the SPE (300); number of backward packets sent by the SPE (300) to the SCE (200); total length of the forward packets; total length of the backward packets; average packet size of the forward packets; average packet size of the backward packets; number of requests from each single node; arriving packet rate; Transmission Control Protocol, TCP, window size; number of Hypertext Transfer Protocol, HTTP, requests; flow duration; number of simultaneous requests; or TCP session time out.

15. The method as claimed in any one of claims 9 to 14, further comprising: depending on the determining (S503, S403), transmitting (S504, S404) a notification to a Network Entity, NE, (500) to perform (S505) at least one preventive and / or protective action.

16. The method as claimed in claim 15, wherein the at least one preventive and / or protective action pertains to at least one of: determining the address of the SCE (200) from which the SPE (300) having received the service requests;labeling the SCE (200) as a threat; isolating the SCE (200); taking a snapshot of the system (100) as a backup and / or for a post-mortem analysis; or issuing a report of the determined (S503, S403) attack to an operator of the system (100).

17. A method (S300) for determining low-rate DDoS attack in a communications system (100), the communications system (100) comprising a Service Producer Entity, SPE, (300), being communicatively connected to an Analyser Entity, AE, (400), the method is performed by the SPE (300) and comprising: sending (S501, S303) a request to the AE (400) to analyse network traffic of the SPE (300), if a number of service requests received by the SPE (300) from a Service Consumer Entity, SCE, (200) in a time interval, t, is higher than a threshold value, th.

18. A system (100) for determining low-rate DDoS attack, the system (100) comprising a Service Producer Entity, SPE, (300), being communicatively connected to an Analyser Entity, AE, (400), configured to: send (S501, S303), by the SPE (300), a request to the AE (400) to analyse network traffic of the SPE (300), if a number of service requests received by the SPE (300) from a Service Consumer Entity, SCE, (200) in a time interval, t, is higher than a threshold value, th; after receiving (S401) the request, determine (S503, S403), by the AE (400), the low-rate DDoS attack based on at least onecharacteristic of the network traffic of the SPE (300) obtained (S402) within a pre-determined time interval, t'.

19. The system (100) as claimed in claim 18, further configured to: determine (S503, S403) the low-rate DDoS attack, if a difference between a predicted value, , of the at least one characteristic and a real value, , of the at least one characteristic is higher than a pre- defined distance, d.

20. The system (100) as claimed in claim 19, further configured to: obtain (S503a, S403a) the predicted value, , of the at least one characteristic based on historical values of the at least one characteristic; and obtain (S503b, S403b) the pre-defined distance, d, based on the historical values of the at least one characteristic and historical predicted values of the at least one characteristic.

21. The system (100) as claimed in claim 20, wherein the historical values of the at least one characteristic and the historical predicted values of the at least one characteristic are obtained in attack-free packet traffic.

22. The system (100) as claimed in claims 20 or 21, wherein the obtaining (S503a, S403a) the predicted value, , of the at least one characteristic and / or the obtaining (S503b, S403b) the pre-defined distance, d, can be performed by a time-series-based model.

23. The system (100) as claimed in any one of claims 18 to 22, wherein the at least one characteristic pertains to at least one of: number of forward packets sent by the SCE (200) to the SPE (300); number of backward packets sent by the SPE (300) to the SCE (200); total length of the forward packets; total length of the backward packets; average packet size of the forward packets ; average packet size of the backward packets; number of requests from each single node; arriving packet rate; Transmission Control Protocol, TCP, window size; number of Hypertext Transfer Protocol, HTTP, requests; flow duration; number of simultaneous requests; or TCP session time out.

24. The system (100) as claimed in any one of claims 18 to 23, further configured to: depending on the determining (S503, S403), transmit (S504, S404), by the AE (400), a notification to a Network Entity, NE, (500) to perform (S505) at least one preventive and / or protective action.

25. The system (100) as claimed in claim 24, wherein the at least one preventive and / or protective action pertains to at least one of: determining the address of the SCE (200) from which the SPE (300) having received (S301) the service requests; labeling the SCE (200) as a threat;isolating the SCE (200); taking a snapshot of the system (100) as a backup and / or for a post-mortem analysis; or issuing a report of the determined (S503, S403) attack to an operator of the system (100).

26. An Analyser Entity, AE, (400) for determining low-rate DDoS attack in a communications system (100), the communications system (100) comprising a Service Producer Entity, SPE, (300), being communicatively connected to the AE (400), configured to: after receiving (S401) a request from the SPE (300), determine (S503, S403), by the AE (400), the low-rate DDoS attack based on at least one characteristic of the network traffic of the SPE (300) obtained (S402) within a pre-determined time interval, t'.

27. The AE (400) as claimed in claim 26, further configured to: determine (S503, S403) the low-rate DDoS attack, if a difference between a predicted value, , of the at least one characteristic and a real value, , of the at least one characteristic is higher than a pre- defined distance, d.

28. The AE (400) as claimed in claim 27, further configured to: obtain (S503a, S403a) the predicted value, , of the at least one characteristic based on historical values of the at least one characteristic; andobtain (S503b, S403b) the pre-defined distance, d, based on the historical values of the at least one characteristic and historical predicted values of the at least one characteristic.

29. The AE (400) as claimed in claim 28, wherein the historical values of the at least one characteristic and the historical predicted values of the at least one characteristic are obtained in attack-free packet traffic.

30. The AE (400) as claimed in claims 28 or 29, wherein the obtaining (S503a, S403a) the predicted value, , of the at least one characteristic and / or the obtaining (S503b, S403b) the pre-defined distance, d, can be performed by a time-series-based model.

31. The AE (400) as claimed in any one of claims 26 to 30, wherein the at least one characteristic pertains to at least one of: number of forward packets sent by the SCE (200) to the SPE (300); number of backward packets sent by the SPE (300) to the SCE (200); total length of the forward packets; total length of the backward packets; average packet size of the forward packets; average packet size of the backward packets; number of requests from each single node; arriving packet rate; Transmission Control Protocol, TCP, window size; number of Hypertext Transfer Protocol, HTTP, requests; flow duration; number of simultaneous requests; or TCP session time out.

32. The AE (400) as claimed in any one of claims 26 to 31, further configured to: depending on the determining (S503, S403), transmit (S504, S404) a notification to a Network Entity, NE, (500) to perform (S505) at least one preventive and / or protective action.

33. The AE (400) as claimed in claim 32, wherein the at least one preventive and / or protective action pertains to at least one of: determining the address of the SCE (200) from which the SPE (300) having received the service requests; labeling the SCE (200) as a threat; isolating the SCE (200); taking a snapshot of the system (100) as a backup and / or for a post-mortem analysis; or issuing a report of the determined (S503, S403) attack to an operator of the system (100).

34. A Service Producer Entity, SPE, (300) for determining low-rate DDoS attack in a communications system (100), the communications system (100) comprising the SPE (300), being communicatively connected to an Analyser Entity, AE, (400), configured to: send (S501, S303) a request to the AE (400) to analyse network traffic of the SPE (300), if a number of service requests received by the SPE (300) from a Service Consumer Entity, SCE, (200) in a time interval, t, is higher than a threshold value, th.

35. A computer program (330B) comprising instructions which, when executed by processing circuitry (310), cause the processing circuitry (310) to perform a method according to any of claims 1 to 8, and / or any of claims 9 to 16 and / or claim 17.

36. A computer program product (330A) comprising a computer program (330B) according to claim 35 and a computer-readable storage medium (330) on which the computer program (330B) is stored.

Images