CPU Exhaustion DoS Detection in Linux Containers

Ajith Kumar PM(TKM19CS007) Niranjan B(TKM19CS007) Dinoy Raj K(TKM19CS021) Merin Shaju K(TKM19CS039) Project Guide: Dr. Manu J Pillai

Department Of CSE, TKM College Of Engineering

Introduction Application Layer Action Module

CODAX is a tool for detecting CPU exhaustion DoS
attacks(Semantic) in Linux containers. The rise of
containerization technology has transformed the way software
is developed and deployed. However, with the increasing
complexity of containerized systems, they have become more
susceptible to attacks, particularly Denial-of-Service (DoS)
attacks.
CODAX uses extended Berkeley Packet Filter (eBPF) technology
at the kernel level to detect potential Denial-of-Service (DoS)
attacks in real time by modeling threshold CPU burst time.
Objectives
Language independent:
It is crucial for the tool to work independently of the
programming language used in the project, as the threat of
DOS attacks can affect any type of system or network
regardless of its underlying technology.
Transparent to Containers:
The tool should not require any modifications or additional
configurations to work with containerized environments,
allowing it to seamlessly integrate with the existing
infrastructure
Prevention:
Once detected there should be some prevention mechanisms
to prevent the further occurrences of the attack.
Container 1 Container 2 ... Container N codax-cli The Action Module of CODAX is designed to take action in
response to a possible DoS attack on a containerized
application. Action Module notifies the developer about the
Kernel Layer
attack and provides the necessary metadata in a remote server.
Monitoring Module
Action Module
Results
Detection Module
[ Figure 1 ]
To assess the effectiveness of CODAX, two containers are
Container Monitoring
The container monitoring process involves distinguishing containerized employed, each running on separate ports. The initial container
exhibits the ReDoS Vulnerability, while the second container
processes from regular processes. Process ID (PID) is obtained using the
bpf_get_current_task() function. Alternatively, the docker proxy can be used showcases the Billion Laughs XML vulnerability.
for identification. During the training phase, 10,000 benign requests were sent to
CPU Time Monitoring each of the containers to model the normal behavior, and
during the testing phase, 5000 benign requests and 100 attack
The accept system call tracer stores the current time with its corresponding requests were sent to evaluate the detection performance. The
process ID (pid) in the eBPF map. When the close system call is triggered, the process is repeated 100 times and the average is calculated.
elapsed time is calculated and used for threshold calculation. Based on the output TPR(True Positive Rate) and FPR(False
Attack Detection Positive Rate) are calculated.
CODAX uses the modeled threshold from the training phase to identify a DoS
attack. If the elapsed time of any container exceeds the threshold, it will be
TPR: 95.6% FPR: 0.085%
marked as a potential DoS attack. The threshold is calculated using
Chebyshev and Markov inequalities (τ = max ( tm, μ+kσ )) The detection efficiency of both CODA and CODAX is
comparable, but CODAX distinguishes itself from CODA in the
The figure below depicts the operational mechanism of CODAX within both following aspects:
the application and kernel layers.
Application Layer Feature CODA CODAX

Methodology Accept() Close() inform the admin via cli and Ziton Detection on close()

yes Detection on threshold exceed

CODAX is composed of three distinct modules: the Container no
Monitor, Detector, and Action Module. Each module plays a if container: if training_mode: if elapsed_time>threshold before close() call
crucial role in the overall functioning of CODAX. Figure 1 yes yes yes
serves as a visual representation of the intricate interworking Alert to the system admin
between these three modules. It showcases how information mark start_time calculate elapsed_time Compute Threshold
and signals flow between the modules. CLI for dynamic inspection
Kernel Layer
[ Figure 2 ]