Christophe Maudoux

Selma Boumerdassi

LemonLDAP::NG A Full AAA Free Open Source WebSSO Solution

Keywords: WebSSO, Security, AAA, OIDC, SAML, CAS, MFA, Handler, Server2Server exchanges, DevOps, SSO as a Service, Authentication, Authorization, Accounting

Nowadays, security is becoming a major issue and concern. More and more organizations like hospitals, metropolis or banks are under cyberattacks and have to improve their network infrastructure security. The first prerequisites are to authenticate users, to provide identity and to grant just the needed and useful accesses. These requirements can be solved by implementing a Single Sign-On (SSO) solution. It is an authentication scheme that permits a user to log in with a single identity to any of several related, yet independent, systems. It allows users to log in once and to access services without authenticating again. SSO solutions are classified depending on Authentication, Authorization, and Accounting features. The 'AAA' acronym defines a framework for intelligently controlling access to resources, enforcing security policies, auditing usage, and providing the information necessary to bill for services. These combined processes are considered important for effective network management and cybersecurity. LemonLDAP::NG (LL::NG) is a full AAA WebSSO solution. It implements all standard authentication and identity federation (IdF) protocols. The main LL::NG's advantages compared to other products are its plug-in engine and its advanced handlerbased protection mechanism that can be employed to protect Server2Server exchanges or to offer the SSO as a Service, a solution to implement a full DevOps architecture. LL::NG is a community and professional project mainly employed by the French government to secure Police, Finance or Justice Ministries and a French mobile operator IT infrastructures since 2010. But for several years, contributions come from all around the world and LL::NG is becoming more and more popular.

I. INTRODUCTION

SSO is a centralized session and user authentication service in which one set of login credentials can be used to access multiple applications. Main advantage is in its simplicity; the service authenticates you on one designated platform or portal, enabling you to then use a variety of services without having to log in and out each time. Deploy an SSO architecture avoids multiplication of passwords and increase the overall IT security. Full SSO solutions provide the three essential services that are users authentication with different methods, access control with authorizations, and accounting by providing logs.

LemonLDAP::NG [START_REF] Guimard | LemonLDAP::NG[END_REF] works with PSGI, FastCGI or uwsgi [START_REF]The uWSGI project -uWSGI 2.0 documentation[END_REF] standards/protocols compliant web servers like Nginx, Apache, Starman. It offers different ways for authenticating users, checks authorizations before accessing resources, and provides logs for accounting. It is composed of four main components as depicted by Fig. 1.

(i) The Portal implements standard protocols. When a user tries to access an application protected by LL::NG and connected by using authentication or IdF protocols, he is redirected to the Portal. It displays authentication screen and then, redirects user to the requested application or it displays the applications menu. (ii) The Handler (depicted by a lock) can be employed to protect applications that do not implement standard authentication or IdF protocols but working with HTTP headers. Handler code can be embedded by applications or Reverse Proxies as explained in Section IV-D. When an unauthenticated user tries to access an application protected by a LL::NG handler, he is redirected to the Portal by the Handler. Then, the Portal displays authentication screen, builds a SSO session in the sessions back-end, provides a SSO cookie with the Session ID (SID) and redirects the authenticated user to the requested application. With the SID, the Handler can retrieve sessions data and send session attributes to the protected application by using HTTP headers. (iii) LL::NG relies on different back-ends that can be files, LDAP, Active Directory, SQL or noSQL (for SSO sessions) databases to store configuration, SSO sessions and persistent sessions (with history, second factors, consents), and users data. (iv) The Manager is the WebSSO administration interface used by administrator to set access rules, HTTP headers sent to protected applications, define the applications menu, configure identities and services providers, enable authentication methods.

Rest of this paper is organized as follow. Section II is an overall presentation of the LL::NG project. In Section III, we expose main authentication methods. Standard authentication or IdF protocols and applications protection are described in Section IV. LL::NG implements a plug-ins engine and some community supported plug-ins are presented in Section V.

II. BACKGROUND & RELATED WORK

SSO platforms can be implemented for different use cases.

To increase security, we can not rely on heterogeneous products. So, it is important to provide complete solutions like LemonLDAP::NG.

A. History & Development

The first stable LL::NG version has been released in 2010. It was a fork of LemonLDAP, an OpenLDAP-based authentication project that has been modified by the French 'Gendarmerie Nationale' (GN) to meet its specific needs.

B. Related Work

Some SSO solutions have been already implemented to protect data collection and server to server exchanges. Study in [START_REF] Chatterjee | Applying Spring Security Framework with KeyCloak-Based OAuth2 to Protect Microservice Architecture APIs: A Case Study[END_REF] describes how Spring Security and the Keycloak open-access platform can be employed to secure a microservices-based architecture Application Programming Interfaces (APIs). Embedded protection uses the OAuth2 method, the underlying concept behind the OIDC protocol that is presented in Section IV-C. Problem here is that the OAuth2 solution only consists in authenticating users. It can not be used for providing user's identity attributes to services unlike the OIDC protocol.

Some works have been conducted in [START_REF] Silva | Building A Zero Trust Architecture Using Kubernetes[END_REF] to deploy a Zero Trust Architecture (ZTA) using Kubernetes and a SSO product. As explained by the authors, a ZTA keeps checking the user's authenticity, monitors the user's devices, and checks for any location change initiated by the user device. Moreover, it also regularly checks for any discrepancies in the application that the user would be using. Main drawback here compared to ServiceToken handler explained in Section VI-A is that none authenticated logs are generated to track users activities.

III. USERS AUTHENTICATION

Many protocols or methods can be employed or combined to authenticate users. This section provides an overview of the main ones supported by LemonLDAP::NG.

A. Methods & Protocols

LL::NG provides several authentication methods and implements standard protocols. Users can authenticate by using network protocols like Gnu Private Guard (GPG) [START_REF]Index -GnuPG wiki[END_REF] that consists in asking user to sign a challenge and to post the result. Remote Authentication Dial-In User Service (Radius) is a client-server networking protocol that runs in the application layer [START_REF]How Does RADIUS Work?[END_REF]. LL::NG handles and forwards Radius authentication requests to the Radius server. With Kerberos [START_REF]Kerberos: The Network Authentication Protocol[END_REF], users are authenticated based on their desktop session. LL::NG validates the Kerberos ticket against a local keytab. LL::NG can also rely on an LDAP directory [START_REF]Main Page[END_REF] to authenticate users and to get user attributes. LL::NG is compliant with LDAP v2 or v3 server, including Active Directory (AD) [START_REF]Active Directory[END_REF], and is compatible with LDAP password policy to check password strength, to block brute-force attacks or can force password change on first connection. LL::NG proposes Pluggable Authentication Module (PAM) as a simple authentication back-end. It is a mechanism to integrate multiple low-level authentication schemes into a high-level Application Programming Interface (API). PAM permits software that rely on authentication to be written independently of the underlying authentication scheme.

Connectors based on OAuth2 protocol [START_REF]OAuth 2.0 -OAuth[END_REF] are available like Google, GitHub, Facebook, LinkedIn or Twitter that allows applications to reuse its own authentication process [START_REF] Dodanduwa | Role of Trust in OAuth 2.0 and OpenID Connect[END_REF].

Main authentication and standard SSO protocols like CAS or SAMLv2 and OIDC described in Section IV are also implemented for authentication, authentication delegation or identities federation [START_REF] Sette | Integrating Cloud Platforms to Identity Federations[END_REF].

Furthermore, "combo" back-ends like Authentication choice and Combination can be employed to propose different authentication methods or to combine sequences.

B. Multi Factor Authentication

MFA is supported since the LL::NG 2.0 release. This feature can be activated for confirming a user's claimed identity by using a combination of two different factors [START_REF] Huseynov | Chapter 50 -Context-Aware Multifactor Authentication Survey[END_REF] between:

• something you know (login/password, . . . )

• something you have (U2F Key, TOTP, mail, . . . )

• something you are (biometrics like fingerprints, . . . ) LL::NG provides some second factor plug-ins that can be enabled for completing authentication module with MFA: TOTP Time based One-Time Password is an algorithm that computes a one-time password from a shared secret key and current time [START_REF]What are Time Based One Time Passwords (TOTP)? -Security Encyclopedia[END_REF]. Then, users might register a device as smartphone by using a dedicated application like FREEOTP or GOOGLE AUTHENTICATOR U2F Universal 2nd Factor is an open authentication standard that enforces and simplifies two-factor authentication using specialized USB or NFC devices [START_REF]What is FIDO U2F?[END_REF]. LL::NG can propose to users to register their key(s). Then, 2F registered users can not login without using their key(s) Yubikey It is a hardware token manufactured by 'Yubico'. It sends an OTP, which is validated via Yubico server [START_REF]Let's get started with your YubiKey[END_REF] Mail After logging in via an authentication module, a onetime code is generated by the Portal and sent to the user's e-mail address. Then, user is prompted for this code in order to continue and to achieve the login process External This method can be used to append a second factor authentication device like SMS, OTP, and so on. It calls external commands to send or to validate a second factor REST/Radius Those methods rely on the corresponding protocol to submit and to check the second factor IV. APPLICATIONS PROTECTION Once users are authenticated, identity claims might be sent or provided to protected applications. Depending on applications and their capabilities different solutions can be used.

A. Central Authentication Service

CAS is an enterprise SSO solution and identity provider for web applications [START_REF]CAS -Home[END_REF], [START_REF] Hu | The application of cross-domain single sign-on in municipal portal[END_REF]. It is an open and well-documented authentication protocol. When a client try to access a "CASsified" application which is an application requiring CAS authentication, the application redirects it to the CAS server. CAS validates the client's authenticity, usually by checking a username and password against a database.

Unlike protocols below, CAS requires to modify the application code to authenticate and retrieve the user data.

B. Security Assertion Markup Language version 2

SAMLv2/Shibboleth is an open standard used for authentication [START_REF]SAML Explained in Plain English -OneLogin[END_REF], [START_REF] Sobh | Identity management using SAML for mobile clients and Internet of Things[END_REF]. Based upon the Extensible Markup Language (XML) format, web applications rely on SAML to transfer authentication data by using assertions (authentication request and response) between two parties -the Identity Provider (IdP) and an application known as the Service Provider (SP). SAMLv2 protocol requires an approbation link between the IdP and the SP. In fact, IdP and SP might exchange their respective metadata that permits to provide configuration parameters like end points and public keys.

SAMLv2 protocol does not require a direct link between IdP and SP. All network exchanges go through the browser that is not the case with OIDC.

C. OpenID Connect

OIDC is an evolution of SAMLv2 [START_REF]OpenID Connect explained[END_REF]. It employs REST protocol instead of SOAP to exchange assertions and JSON replaces XML to format messages. OIDC is easier to implement with mobile applications by using the refresh token mechanism.

OIDC standard defines 3 authentication flows. The Hybrid and Implicit flows are deprecated and should not be employed. The Authorization Code (AzC) flow is the most secured because user and applications are authenticated. The AzC is returned by the OP after user authentication. This code is provided to the application. This flow is used to prevent that the password is stolen by a malicious application. Then, it is provided with the Client Id and Secret to authenticate the application, and to retrieve Id, Access and Refresh tokens.

LL::NG implements all these standard SSO protocols. It can act as IdP/SP (SAML) or OP/RP (OIDC) and could be used as a "federation proxy" between all these protocols [START_REF]LL::NG as federation protocol proxy -LemonLDAP::NG 2.0 documentation[END_REF].

D. Handlers

Protection by handlers is a mechanism that can be employed to protect applications working with HTTP headers. Each request sent to the protected application is caught by the handler. It looks for a specific "token" depending on the used handler type. LL::NG proposes the following types: Main SID is retrieved from the SSO cookie value AuthBasic Performs Basic authentication [START_REF]IBM Documentation[END_REF] SecureToken Decrypts SID from a ciphered SSO cookie ServiceToken Retrieves SID from X-LLNG-TOKEN header DevOps Fetches configuration from 'rules.json' file OAuth2 Gets SID from an OAuth2 Access token Zimbra Performs Zimbra pre-authentication [28] CDA Used for Cross Domain Authentication [START_REF] Hu | The application of cross-domain single sign-on in municipal portal[END_REF], [START_REF]What Are Cross Domain Cookies and How Do They Work[END_REF] With the SID, handler collects user data from SSO sessions back-end, computes and checks access rules and sends HTTP headers with session attributes to the protected application.

Handler code can be embedded by the protected applications but it requires to have access to the application code and to modify it. To avoid this, applications can be hidden behind Reverse Proxies that embed the handler code. So, protected applications are not exposed to users and directly requested. Reverse Proxies-based architecture is described by Fig. 1.

Figure 3 details the Main handler kinematic: 1) User tries to access a protected application. His request is caught by Handler 2) SSO cookie is not detected, so Handler redirects user to Portal 3) User authenticates on Portal 4) Portal checks authentication 5) If authentication succeeds, Portal collects V. EXTENDED FEATURES LemonLDAP::NG offers possibility to extend its features by hooking internal processes or appending functionalities.

A. Plug-ins Engine & Entry Points

Since 2.0 version, LL::NG provides a plug-ins engine. It allows to append specific or custom features. Plug-ins can handle authenticated or unauthenticated routes. They can also be launched by using particular entry points (EP) during login or logout process. This mechanism is a very interesting feature to extend LL::NG and to meet specific needs.

B. Specific Plug-ins

AdaptativeAuthLevel

A. Server2Server Exchanges Protection

The ServiceToken handler is a mechanism to protect Server2Server exchanges. As described by Fig. 4, a web application (WebApp1) may need to request some other web applications (WebAppN) on behalf of the authenticated user. You just have to provide a header containing the ServiceToken (ST) to WebApp1 and to protect WebAppN with the corresponding handler. Then WebApp1 can request WebAppN by appending the 'X-LLNG-TOKEN' HTTP header with the ST as value that will be caught by the handler.

The ST is built by encrypting the SID and an authorized VHosts list to restricted its scope. The ST lifetime is limited in case of it is stolen. The ST can also be used for sending service headers to WebAppN like the source host by example.

B. SSO as a Service

The DevOps handler is a mechanism to implement the SSO as a Service (SSOaaS). '*aaS' means that application can drive underlying layer like IaaS for Infrastructure or PaaS for Platform. SSOaaS means provide the ability for an application to manage authorizations and choose user attributes to set. But authentication can not be really *aaS. This step must be performed by a well known, identified and managed service. It can not be delegated except with IdF protocols as described and explained in Section IV. Applications might just use it but not manage it. LL::NG offers some features that can be used for providing SSOaaS and implementing DevOps architectures.

DevOps concept means "development" and "operations". It is the combination of practices and tools designed to increase an organization's ability to deliver applications and services faster than traditional software development processes. This speed enables organizations agility to better serve their customers and compete more effectively in the market. DevOps breaks barriers between traditionally isolated development and operations teams. Under a DevOps model, development and operations The DevOps handler is an on-premises component (the LL::NG handler) designed to retrieve users data or SSO configuration from back-ends and VHost configuration (access rules and sent HTTP headers) not from LL:NG configuration but from the web application itself that can be hosted in a cloud environment. Rules and headers are set in a 'rules.json' file stored at the website root directory as described by

Fig. 1 .

 1 Fig. 1. Main components

Figure 2

 2 Figure 2 describes the LL::NG development process that is composed of two different cycles. (i) The community cycle, hosted by the OW2 GitLab forge [6], is used for opening issues, Continuous Integration & Development (CI/CD) pipelines and milestones. (ii) Then, when a new version is released by the community every three months, this one is tested, validated, and deployed during the STSISI 1-year cycle.

Fig. 2 .

 2 Fig. 2. Development process

Fig. 3 .

 3 Fig. 3. Main Handler kinematic

Fig. 4 .

 4 Fig. 4. ServiceToken handler kinematic

Fig. 5 .

 5 Fig. 5. DevOps handler kinematic

Fig. 5 .

 5 Communications between DevOps handler and web applications are based on a Common Gateway Interface (CGI) protocol like FastCGI or uwsgi. Rules.json files syntax and format can be checked by the DevOps teams with the CheckDevOps plug-in described in Section V. VII. CONCLUSION LEMONLDAP::NG [31] is a free and open source full AAA SSO project that supports standard SSO protocols (SAMLv2, CAS, OIDC, . . . ), provides several features (MFA, different handlers or authentication methods) and services. It is a complete, versatile and customizable SSO solution. Its main specific and original features compared to the few other existing products are SSOaaS and Server2Server protection mechanisms. Thus and standard IdF protocols can be deployed and implemented in a cloud infrastructure to easily authenticate users, protect web applications and provide logs. It can also be employed as a proxy to interconnect different cloud platforms or between heterogeneous identity federation protocols. Next release will offer a new Manager based on ReactJS framework, implement the WebAuthn protocol and a new MFA engine.


Christophe Maudoux

Selma Boumerdassi

Network Anomalies Detection by Unsupervised Activity Deviations Extraction

Keywords: Geohash, anomalies detection, activity deviation, unsupervised machine learning, networks, aggregation, security

More and more organizations are under cyberattacks. To prevent this kind of threats, it is essential to detect them upstream by highlighting abnormal activities within networks. This paper presents our anomalies detection approach that consists of aggregating pre-processed network flows into sectors. Then for each sector, data are split into equal time periods. Finally an unsupervised clustering algorithm is employed to extract that we called activity deviations. If a specific sector network activity for one specific period differs from others, it means that a network anomaly has been detected. Our experiments are based on a real dataset provided by a French mobile operator. With our proposed method, we have been able to detect anomalies corresponding to real crowded events like fire, soccer match or concert.

I. INTRODUCTION

Each day, some organizations are targetted by cyberattacks. Many types of threat exist like DDoS (Distributed Deny of Service) [START_REF] Russell | The world's largest DDoS attack took GitHub offline for fewer than 10 minutes[END_REF], security breach exploits that steal personal data, spam campaigns that try to reach a higher account level by deceiving users, stealing credentials to perform horizontal scanning and to spread malware for further gain. One common feature that characterizes all these cyberthreats is that specific data flows are exchanged over networks. To defeat or mitigate these kinds of attack, it is essential to deploy systems able to detect suspicious flows by extracting anomalies in networks.

Network anomalies can be defined as a 'behaviour that deviates from what is normal, standard, or expected'. So to detect network anomalies, it means that you might have a concept of expected or normal behaviour. Some researches have been done on this topic by monitoring network traffic and analysing message headers or payload content [START_REF] Vilac ¸a | Botnet traffic detection using RPCA and Mahalanobis Distance[END_REF]. Countermeasures mainly consist of analysing traffic flows by deploying network probes like Intrusion or Anomaly Detection Systems [START_REF] Wankhede | Anomaly Detection using Machine Learning Techniques[END_REF].

Anomaly detection is useful in identifying the patterns that are unexpected called outliers. Moreover, Machine Learning (ML) techniques are increasingly used to detect them. Several works are available in the literature. For example, authors in [START_REF] Guezzaz | Mathematical validation of proposed machine learning classifier for heterogeneous traffic and anomaly detection[END_REF] proposed a ML algorithm for classifying heterogeneous network traffic and anomaly detection. Also, a recognition algorithm was used in order to validate the model. On the other side, authors in [START_REF] Wang | Anomaly Detection of Industrial Control Systems Based on Transfer Learning[END_REF] proposed a solution based on both deep residual Conventional Neural Network (CNN) structure for dataset modelling and transfer learning for training the model to detect anomalies in Industrial Control Systems (ICS).

ML techniques can also be used to detect outliers in sensor data. Authors in [START_REF] Ghosh | Outlier Detection in Sensor Data Using Machine Learning Techniques for IoT Framework and Wireless Sensor Networks[END_REF] described several techniques of ML to detect outliers in IoT by classifying the existing techniques into different categories.

For our use case, we aim to detect behaviour changes relating to mobile application activity using an unsupervised ML technique and based on the fields described in Section III. To achieve this, we extracted that we call activity deviations by analysing network activity behaviours at a specific moment in time and for a particular network location.

This article presents our network anomalies detection approach using machine learning to extract deviations and detect outliers. Our paper is organized as follows. In Section II, we explain our proposed method. Section III describes the dataset that we used for performing our research that is based on real mobile network data and the provided raw flows. Section IV details our method implementation and summarizes obtained results. Finally, we suggest possible improvements and define our planned further works.

II. UNSUPERVISED ACTIVITY DEVIATIONS EXTRACTION

Our proposed approach is composed of three phases (i) data parsing and aggregations performed by some Perl parsers (ii) activity deviations extracted by the unsupervised X-Means Machine Learning Algorithm (MLA) (iii) outliers detection computed by the Local Outlier Factors (LOF) algorithm.

A. Data Parsing & Aggregation Processes

Due to the high number of sites and the huge amount of available flows, data cannot be directly and globally analysed. A pre-processing phase is needed. As depicted by Fig. 1, we have had to (i) aggregate raw network flows by sites: by-site aggregation (ii) followed by parsing them into sectors to extract the activity deviations: by-sector aggregation.

1) By-site aggregation: this process is used for transposing and aggregating raw network flows from the same Base Transmitting Station (BTS). Indeed, a BTS or site can serve several antennas where each antenna is defined by a unique identifier or location.

2) By-sector aggregation: this step aims to define some specific areas or sectors for further detailed analysis. The employed method consists of gathering data from neighbouring sites by using the Geohash concept [START_REF]Geohash Intro -Big Fast Blog[END_REF]. This is a public domain geocode system invented in 2008 by Gustavo Niemeyer which uses GPS coordinates to encode a geographic location into a short string of letters and digits [START_REF] Hill | Geohashing[END_REF]. It is a hierarchical spatial data structure which subdivides space into buckets of grid shape.

The sector area depends on the 'Geohash length' also known as Precision. The higher the Geohash precision value is, the smaller its corresponding sector area. Table I lists some cells dimensions depending on Geohash precision. To determine the most accurate precision value, different Geohash lengths from 5 to 7 characters were tested. A 6-character long Geohash has been selected because its precision fits the best understandable well-known places to study like Notre-Dame de Paris (N-d-P) or Stade de France (S-d-F) as depicted by Figs. 2a to 2c. A 6-character Geohash defines a cell with a height of 1.2km and a width equal to approximatively 0.6km.

B. Activity Deviations Extraction

This phase consists, for each sector, in joining data points together to define clusters for some given time periods or slices based on the attributes computed during the pre-processing phase. If a period-activity differs from others, it is deemed suspicious and highlights an abnormal behaviour. This step Problem is that we do not know in advance how the clusters will be constituted. Therefore, we selected the X-Means algorithm, an improved and better unsupervised MLA.

X-Means is a variation of K-Means clustering which further refines cluster assignments by repeatedly attempting subdivision, and keeping the best resulting splits [START_REF] Pelleg | X-means: Extending K-means with Efficient Estimation of the Number of Clusters[END_REF]. The algorithm begins by randomly positioning centre points named starter means. It then associates with the same cluster observations closest to those means, calculates the average observations from each cluster and moves corresponding means to a computed position. It continues to reassign the observations to the nearest means and so on, to achieve consensus. To ensure the stability of located groups, the starter means selection is repeated several times to overcome some initial draws that may give a different configuration from the majority of cases [START_REF] Ghosh | Comparative Analysis of K-Means and Fuzzy C-Means Algorithms[END_REF].

C. Outliers Detection

The third phase performs the Outliers detection. It aims to detect network anomalies by pointing out the outliers. It is performed by the Local Outlier Factors algorithm [START_REF]Detect Outlier (LOF) -RapidMiner Documentation[END_REF]. LOF is based on the concept of local density, where locality is given by k nearest neighbours, and whose distance like Euclidean, Mahalanobis or Chebyshev is used for estimating the density. By comparing the local density of an object to the local densities of its neighbours, it is possible to identify regions of similar density, and points that have a substantially lower density than their neighbours. These are considered as outliers and so highlight anomalies.

III. EMPLOYED DATASET

For this study, we have employed a dataset that has been generated to serve several research objectives [?]: (i) collecting new measurements that describe mobile network data traffic for different mobile services separately. Data are gathered in an operational nationwide network by combining the output of multiple monitoring technologies (ii) evaluating existing analytics for classification, prediction and anomaly detection within real-world high-detail per-service mobile network data that represents several terabytes of traffic per hour (iii) demonstrating the integration of data analytics within next-generation network architectures in practical case studies. This dataset consists of data collected from a major French mobile operator at large scale. It is made of novel anonymized high-detail flows of contextualized user mobility and mobile service usage traffic data records (xDR). Network flows have been obtained by leveraging passive probes deployed in the French operator mobile network. These data sources have different levels of spatio-temporal accuracy.

It characterizes the mobile traffic and application usage over a 3-month period for the entire national territory of France. Data has been erased according to GDPR rules and the national telecom code of conduct but anonymized aggregates are available for analyses. This paper focuses on the Ile-de-France area to detect anomalies in a mobile network based on recurring behaviour analysis at an application level. The dataset employed in this study is composed of 26 '.

IV. EXPERIMENTS & RESULTS

For this study, we chose to work on a 3-month period of data extracted from 16/03/2019 to 14/06/2019 divided into 30-minute time slots. A snippet describing few lines of raw data is presented by Fig. 3. Some values have been obfuscated to avoid privacy issues.

A. Data Aggregations

By-site and by-sector aggregation processes aim to reduce the amount of raw data and to extract the underlying structure for a better understanding and further analyses. Employed Perl parsers and tools can be freely downloaded from our repository [START_REF]Cmaudoux / digital-signatures-extraction[END_REF].

1) By-site aggregation: during this process, raw traffic flows are aggregated by BTS to split data into sites. As described in Section III, 11 fields are available. To perform this initial aggregation step, we employed a 3-tuple aggregation key built as follows 'TimeSlot; SiteName; AppGroup'. 'PortApp' defines the application types and different 'PortApp' can correspond to the same 'AppGroup'. So, we have had to transpose 'PortApp' into 'AppGroup' in first place. For this purpose, the dictionary detailed below has been generated from the correspondence table provided by the mobile operator and used for merging flows related to the same 'AppGroup': Obtained data after this aggregation phase are composed of 9 fields: 'TimeSlot, SiteName, Coord X, Coord Y, AppGroup, Packets, Duration, Users, Flows'. This first step allowed us to reduce the total amount of raw data from 184 GB to 12 GB that represents a reduction factor near 16 as detailed in Table II with a resulting number of extracted BTS equal to 2,736. You can notice that no BTS with a name starting with the 'X' letter exists.

2) By-sector aggregation: this second aggregation consists in grouping BTS into sectors. For each flow, the corresponding Geohash is computed by using the 'Coord X/Y' values and the Perl Geohash package [START_REF]Geohash -Great all in one Geohash library -metacpan[END_REF] with a precision value equal to 6. Then, the merging process is based on the 3-tuple primary key 'TimeSlot; Geohash; AppGroup'. As depicted by Fig. 4, structure of the obtained aggregated data corresponds to this scheme: 'TimeSlot, Geohash, AppGroup, Packets, Duration, Users, Flows'. The last 4 fields are employed to characterize network activity for each sector and time slice. Table III lists the number of obtained sectors depending on the Geohash precision value.

B. Activity Deviations Extraction

To test and validate our proposed anomalies detection method, we focused on April from Monday 1st to Sunday 28th and some days in May, 2019. Parsed data relative to these dates have been split by weeks, days or time slices using the bash 'grep' command to filter desired timestamps.

Activity deviations extraction is performed with the X-Means algorithm. This unsupervised MLA is used for clustering parsed data for each sector for specific time slices based on the 4 fields describing the network activity previously computed.

df A 9.7G 645M df M 13G 806M df B 14G 811M df N 6.6G 377M df C 23G 1.4G df O 5.9G 572M df D 3.2G 205M df P 19G 1.2G df E 3.6G 217M df Q 1.9G 87M df F 5.3G 295M df R 13G 739M df G 6.7G 431M df S 18G 1.1G df H 4.0G 220M df T 3.8G 346M df I 3.0G 154M df U 681M 38M df J 1.5G 88M df V 13G 814M df K 881M 53M df W 211M 8.7M df L 18G 1.1G df Y/Z 70M/316K 5.4M/128K
By-site aggregation details -Ratio ≈ 16 Fig. 4. By-sector aggregated data snippet It has been implemented using Weka [START_REF] Witten | Data Mining: Practical Machine Learning Tools, ser. MK Series in Data Management Systems[END_REF]. We employed the Waikato Environment for Knowledge Analysis Toolbox [START_REF]Weka 3 -Data Mining with Open Source Machine Learning Software in Java[END_REF] to conduct our experiments. It is a freely available open source software developed at the University of Waikato in New Zealand providing a set of visualization tools, different machine learning algorithms for data analysis and extensions, together with graphical user interfaces for ease of access to these functions. Overall, data must be transformed into an ASCII text file that describes a list of instances sharing a set of attributes to be analysed with Weka. This step is done by the parsers during the aggregation processes.

An activity analysis is performed for each time period and for each sector [sector's name (Geohash)]: 1) By-week time periods: Figure 5 is a representation by week of cluster assignments with number of users based on the application groups for Notre-Dame de Paris (u09tvm) and Gare de Lyon (u09ty5).

From Figs. 5a and 5b, we can deduce that activity of Gare de Lyon is similar each week. This is also the case for the first and fourth week of April, 2019. We can conclude that no anomaly exists and therefore no particular event occurred. 2) By-day time periods: Figure 6 is a representation by day of cluster assignments with number of users based on the application groups for Stade de France (u09wmd). We selected the 20th, the 27th of April and the 4th of May, 2019 which are 3 Saturdays.

By focusing on Fig. 6b, it is obvious that clusters distribution is completely different from the others. We can deduce that network activity has deviated compared to the other days. So, the network activity has deviated.

3) By-hours time periods: Figure 7 is a representation by hours of cluster assignments with number of users based on the application groups for Stade de France (u09wmd). We selected the 5th, the 12th and the 19th of May, 2019 which are 3 Sundays and then we extracted a 4-hour time slice from 8pm to 11pm for each Sunday.

Like by-day analysis, if we focus on Fig. 7b, we can conclude that network activity is very different from the other time slices. So, this particular day, the network activity has changed for this specific time period.

This activity deviations extraction highlights some network behaviour changes that required further analysis. It is performed during the next step by means of an unsupervised classifier. From Table IV, where some of the detected outliers are summarized, we can deduce that an anomaly concerning sector Notre-Dame de Paris occurred from April 15th, 2019 at 6pm to April 17th, 2019 at 10am. This event can be correlated with actualities and is relative to the Notre-Dame de Paris fire. The other anomalies correspond to the French soccer cup final match on 27th of April at 8pm or the Metallica concert on 12th of May, 2019 at 9pm that were held in Stade de France.

V. CONCLUSION & FURTHER WORKS

From this study, we can conclude that our proposed process based on an Unsupervised Activity Deviations Extraction is able to detect network anomalies. In this use case, anomalies are defined by a behaviour change in network activity. We selected this kind of behaviour because application activity was a feature available in our dataset but it can be transposed over other networks with different parameters.

Our approach consists in the first place to aggregate data into sectors that represent specific areas. Then, an unsupervised MLA is employed to extract network behaviours from these sectors. Based on those features, we characterize some activity deviations for each sector and for particular time periods. After that, we extracted outliers to detect any network anomalies. This last step helped us to highlight particular events.

Furthermore, we can classify sectors depending on the type of activity by selecting more sectors to compare. We plan to apply our concept on smaller sectors defined by 7-character Geohash values, to detect less significant events or a lack of particular network traffic where a usual high activity level is the norm or required. We also want to detect network security anomalies by using an hybrid approach [START_REF] Maudoux | Combined Forest: A New Supervised Approach for a Machine-Learning-based Botnets Detection[END_REF].

Fig. 1 .

 1 Fig. 1. Aggregations overview

Fig. 2 .

 2 Fig. 2. Sector size depending on Geohash precision value

  csv' files describing each radio access site sorted in alphabetical order. The total file size represents 184Go of raw data. Provided network flows provided in each file are composed of 11 fields: PortApp Mobile application type, LocInfo Antenna's identifier, Coord X/Y Site coordinates, SiteName Site's name, TimeSlot Date and time in 30mn slots, Duration TCP session duration, Users Number of distinct users, nPktUp & nPktDn Total number of packets, Flows Number of traffic flows exchanged during TCP session.

Fig. 3 .

 3 Fig. 3. Raw data snippet

1 )

 1 Unknown 2) Web 3) P2P 4) Download 5) CloudStorage 6) Mail 7) DB 8) Others 9) Control 10) Games 11) Streaming 12) Chat 13) VoIP 14) MailOperator 15) VPN 16) VVM 17) MMS 18) StreamAVSP 19) Portal.

Fig. 5 .

 5 Fig. 5. Activity deviations by week

Fig. 6 .

 6 Fig. 6. Activity deviations by day

Fig. 7 .

 7 Fig. 7. Activity deviations by hours

TABLE II RAW

 II VS AGGREGATED DATA

	File	Raw	Aggregated	File	Raw	Aggregated

TABLE III GEOHASH

 III PRECISION VS NUMBER OF SECTORS Number of sectors and file size increase with precision value

	Geohash precision	5	6	7	8
	Sectors	109 1,233 2,545	2,707
	File size (MB)	16	139	246	258

TABLE IV OUTLIERS

 IV EXTRACTED BY THE LOF ALGORITHM

	Instance	TimeSlot	AppGroup	Packets	Geohash	Flows
	528	2019-04-15 18:00:00	12	1745	u09tvm	9
	714	2019-04-15 23:30:00	12	360	u09tvm	2
	808	2019-04-16 02:30:00	4	8347	u09tvm	68
	926	2019-04-16 07:00:00	4	9425	u09tvm	175
	1012	2019-04-16 10:00:00	1	29726	u09tvm	235
	1355	2019-04-16 20:00:00	10	731148	u09tvm	9194
	1767	2019-04-17 10:00:00	0	4372	u09tvm	15
	379	2019-04-27 18:00:00	15	2354	u09wmd	6
	443	2019-04-27 20:00:00	10	8256608	u09wmd	8550
	559	2019-04-27 23:00:00	5	43482	u09wmd	135
	74	2019-05-12 22:00:00	16	167652	u09wmd	605
			Events detection