TLS-Resilient Monitoring for Open5GS in Secure

and Low-Footprint 5G Deployments

This article summarizes key insights from my Bachelor’s thesis, representing the final stage in a year-long exploration of monitoring solutions for Open5GS deployments. Much of the text is adapted with assistance from OpenAI GPT-4.5 for clarity, but the concepts, design, and implementation are based directly on my own experience and investigation.

Previous foundational articles include:

• Open5GS set-up from modified source code to custom deploy
• Open5GS mTLS configuration

GitHub repository of the project.

Introduction

In previous articles, we explored how to deploy Open5GS directly from source code and configure it with mutual TLS for enhanced security (Open5GS setup, Open5GS mTLS Configuration). Building upon this foundation, today’s article focuses on addressing a critical gap: practical, low-overhead monitoring for private 5G networks using Open5GS.

Why Another Monitoring Solution?

Built-in Open5GS debugging tools are excellent for troubleshooting but unsuitable for production:

• Excessive logging can severely degrade performance.
• Encrypted internal communication (TLS/IPSec) makes traditional packet-sniffing ineffective.

Thus, we require real-time, low-overhead monitoring solutions that remain effective under encryption.

Our Approach

Software design of the monitoring solution

The monitoring solution we developed integrates deeply into the Open5GS codebase, ensuring minimum interference while providing precise visibility into network operations. Here are key points of our design:

1. Application-Level Data Extraction

• We inject lightweight monitoring hooks directly into the Open5GS protocol handlers.
• This is achieved using a dynamically linked library that serializes relevant control-plane events to JSON and sends them via UDP. UDP usage ensures minimal performance impact, though it introduces minor trade-offs in reliability.

2. ELK Stack Integration

• To effectively manage and visualize the data, we use the robust ELK stack (ElasticSearch, Logstash, Kibana).
• Logstash receives UDP messages and indexes them through ElasticSearch for quick retrieval and analysis.
• Kibana provides an intuitive interface for network administrators to examine and visualize these logs manually.

3. Real-time Alerting

• Alerts are crucial to timely detection and response. We leverage ElastAlert2, an open-source solution suitable for basic monitoring scenarios.
• Alerts are dispatched via a lightweight custom Go-based server to Discord, chosen for simplicity, reliability, and cost-effectiveness compared to traditional email-based alerts.

Demonstration: Sample Scenarios

We demonstrate this monitoring system with two essential scenarios: gNB and UE registration.

Scenario 1: gNB Registration

When a gNB (base station) attempts to register:

• The monitoring hook captures initial NGAP messages with key details: gNB name, PLMN ID, and gNB ID.
• The system immediately alerts administrators of attempts by suspicious gNB names or unexpected PLMNs, helping to swiftly identify potential threats or misconfigurations.

Scenario 2: UE Registration and SUCI Decryption

• We track the initial UE message and subsequent SUCI (Subscriber Concealed Identifier) decryption.
• Our system checks that every UE registration message is followed by successful SUCI decryption. If a mismatch or a failed decryption occurs (e.g., incorrect encryption keys), an alert is triggered.

Deploying the Monitoring System

The deployment strategy prioritizes performance and reliability, achieved through native Debian package management rather than Docker or other virtualization tools:

• Open5GS is compiled and packaged directly from source.
• Systemd manages all service components (Open5GS, Logstash, ElasticSearch, Kibana, and the custom dispatcher), simplifying administration.
• Detailed deployment instructions are available in our previous Medium article.

ARM Compatibility

We confirmed partial compatibility with ARM architecture, specifically testing Open5GS deployment on Raspberry Pi hardware. This enables cost-effective, low-power deployments suitable for remote or constrained environments.

Sustainability and Environmental Impact

The lightweight, OS-native design optimizes resource usage, making this solution suitable for sustainable deployments in energy-constrained or isolated environments. ARM compatibility further enhances energy efficiency.

Considerations and Limitations

While our approach effectively addresses core monitoring needs, we acknowledge certain limitations:

• Reliability of UDP: UDP ensures minimal latency but may lose messages in rare conditions. For ultra-critical monitoring, switching to TCP is a feasible alternative.
• Complex alerting scenarios: ElastAlert2, while suitable for basic use-cases, lacks comprehensive alerting features available in premium services like Elastic Watchers.

Example

I suggest adding SMF session establishment report for demonstration how it is done ‘on top’ of the existing project.

I chose internal logic handling file instead of network-level decoder first entry point to present the flexibility of the solution to catch internal flow (unlike proxy-based alternatives). We will use src/smf/nsmf_handler.c function to catch the session registration.

The entire edit is easily available by *this commit. *Let me explain each in details:

Step 1

We add the report declaration and json wrapper to lib/monitoring/reports.c

Some formatters might be required to convert internal data types to human readable format — use lib/monitoring/helpers.cor add a new helper there.

Step 1.1

Do not forget about function declaration

Step 2

The second part is to determine which data we extract from the internal flow. Debuggers help a lot to look which structures are available at each time. They also follow the 3GPP specifications.

Note: for debugger overflow issue see this troubleshoot.

Step 3 (first time per NF only)

Custom monitoring library must be linked with meson project as well. Only required on first occurrance per NF.

That’s it! Voila the report is working:

Wireshark UDP capture

Conclusion and Next Steps

Our TLS-resilient monitoring solution represents a significant step forward in secure and efficient Open5GS deployments. It combines minimal resource overhead, robust data visibility, and real-time alerting capabilities tailored for private 5G network scenarios.

Future work involves performance benchmarking with realistic deployments, expansion of alerting logic using premium monitoring solutions (e.g., Elastic Watchers), and further validation across varied hardware setups.