Experimental Analysis of Security Attacks for Docker Container Communications

Abstract

Docker has become widely used as an open-source platform for packaging and running applications as containers. It is in the limelight especially at companies and IT developers that provide cloud services thanks to its advantages such as the portability of applications and being lightweight. Docker provides communication between multiple containers through internal network configuration, which makes it easier to configure various services by logically connecting containers to each other, but cyberattacks exploiting the vulnerabilities of the Docker container network, e.g., distributed denial of service (DDoS) and cryptocurrency mining attacks, have recently occurred. In this paper, we experiment with cyberattacks such as ARP spoofing, DDoS, and elevation of privilege attacks to show how attackers can execute various attacks and analyze the results in terms of network traffic, CPU consumption, and malicious reverse shell execution. In addition, by examining the attacks from the network perspective of the Docker container environment, we lay the groundwork for detecting and preventing lateral movement attacks that may occur between the Docker containers.

1. Introduction

With the outbreak of COVID-19 and digital transformation, developers are starting to use cloud computing environments to efficiently manage computing resources or to provision on-demand computing resources on the fly [1]. The most important technology to provide a cloud computing environment is virtualization technology, which solves the problems caused by the increase in the amount of data generated by various devices and provides fast software distribution, customized functions, and flexibility for users. Container technology, which is one of these virtualization technologies, is different from the existing virtual machine (VM), namespace, which provides a virtual independent space by separating the resources used by the container in one operating system kernel and the space where the container is isolated isolating processes using Cgroups, which allows resource control on the platform to run applications independently [2].

Docker, an open-source platform used to package and run applications as containers, has become an important platform used by more than half of developers for reasons such as software portability, application operation standardization, and efficient resource management [3]. However, security threats targeting Docker containers began to increase with the activities of malicious hacker teams such as TeamTNT, WatchDog, Kinsing, and Rocke [4]. They mainly infiltrate Docker container environments through misconfigured APIs for the purpose of DDoS or cryptocurrency mining. In the case of applications that are used by multiple users and acquire special privileges, such as Portainer, a web GUI tool to facilitate Docker container management, various attacks can occur in the Docker container environment [5,6]. In addition, as an attacker can enter the Docker container environment through the Docker API exposed on the Internet, the attacker can bypass the security program and execute various secondary attacks. Further research is needed to detect such attacks from a container network perspective [7].

In [8], a Docker image vulnerability diagnostic system was introduced to analyze Docker images. The system checks Docker images when uploading or downloading the Docker images from a Docker image repository if any known vulnerabilities are included in the images. In [9], the authors introduced a dynamic analysis method to assess the security of Docker images based on their behavior. The dynamic analysis method was shown to complement the static analyses typically used for security assessments for Docker images. The work presented in [10] introduced a Docker image traceability and security detection system based on inheritance graphs, called ZeroDVS, where a basic image graph is built with 160 official Docker images published by Docker Hub. Based on the built image graph, ZeroDVS can identify known vulnerabilities of a Docker image. In [11], various types of base images were compared in terms of security severity.

Among recent container security mechanisms applicable to Docker, major ones addressing container network security are Docker-sec, LiCshield, and Lic-sec.

Docker-sec is a Docker security mechanism based on AppArmor. It creates an AppArmor profile for a container and interacts with the Docker engine to apply it. The default AppArmor profile protects the container only after it is initialized by RunC, but Docker-sec protects the container during its entire life cycle [12]. Docker-sec shows excellent performance in defending against privilege escalation attacks but cannot defend well against privilege escalation attacks on images in the form of Docker in Docker [13].

LiCshield is a framework to automatically apply AppArmor policies to all Docker containers. It tracks all kernel activity with a tool called SystemTap5 while the Docker daemon is running. It can create access rules, mount rules, link rules, and execution rules that Docker-sec cannot create [14]. However, since LiCshield does not restrict malicious functions and commands such as /bin/bash, and it cannot defend against all kernel attacks [13].

Lic-sec has been proposed by combining the advantages of Docker-sec and LiCshield. It can create access rules, mount rules, link rules, and execution rules, as well as an audit function, while providing excellent performance in defending against privilege escalation attacks. However, a defense against DoS attacks is not supported [13].

The previous works have provided only defense mechanisms or assumed possible security threats. In other words, no specific details for security threats in the Docker container environment have been published. Rather than proposing a new defense mechanism, in this paper, we present our actual experimental results showing that various attacks are still possible even in the latest Docker container environment. The main contributions of this paper are as follows:

• It mainly focuses on Docker container networking and presents actual security attacks to show how attackers can execute various attacks even in the latest Docker container environment.
• It presents detailed experimental steps for executing attacks such as ARP spoofing, DDoS, and elevation of privilege attacks and presents analysis results of the security attacks in terms of network traffic, CPU consumption, and malicious reverse shell execution.

The structure of this paper is as follows. Section 2 describes the Docker container network configuration method based on a Docker container network methodology. Section 3 analyzes network security attacks between independent containers. Section 4 shows the experimental setup of this paper to demonstrate network security attacks in a Docker container environment. Section 5 analyzes the experimental results. Finally, Section 6 concludes this paper.

2. Docker Container Communication

When we implement a specific service based on Docker, we usually configure the service by running an application in a container environment. When composing a service based on the container, as communication between containers needs to be made, Docker configures the network environment for service configuration by connecting the container-to-container or existing network and VLAN. To clearly understand Docker networking, it is necessary to understand three concepts: container network model (CNM), libnetwork, and driver. First, the CNM is a standard for Docker networking and is composed of a sandbox, endpoint, and network, as shown in Figure 1. In the case of the sandbox in Figure 1, it can be defined as an isolated network stack, including Ethernet interfaces, ports, and DNS settings. Additionally, in the case of an endpoint, veth, which can be checked when configuring a Docker container network environment with a virtual Ethernet interface, corresponds to this. That is, the main role of the endpoint plays the role of a network interface, and in the CNM, it plays the role of connecting the sandbox to the network. A network is a software application implementation of one switch, and it plays the role of integrating or separating the endpoints for communication [15,16].

The roles of each component in the CNM are shown in Figure 2. In the case of Container A, it can be seen that the endpoint is connected to the back-end network, and Container B is connected to the back-end network and the front-end network based on the two endpoints. Additionally, the endpoint of Container C is connected to the front-end network. In the case of Figure 2, it can be seen that each container is connected to the back-end network and the front-end network, so communication between them is possible. However, in the case of the two endpoints of Container B, communication is impossible without a Layer 3 router, and communication is possible only through the Layer 3 router [15].

Next, in the case of libnetwork, it implements the CNM and performs all the roles of each component in the CNM. This can be explained as being responsible for native service discovery, ingress-based container load balancing, and network control and management plane functions. In the early days of Docker, these functions were supported by the Docker daemon, but now it has been refactored and established as libnetwork [15].

In the case of a driver, it can be explained compared to libnetwork, and if libnetwork provides network control and management plane functions, the driver implements the data plane. It can be seen that both the connection and isolation of the Docker container are handled by the driver, which can be seen in Figure 3. In the case of libnetwork, as cross-platform is supported, there is a difference in the driver depending on the Linux environment or Windows environment even in the case of the driver. On Linux, it has bridge, overlay, and macvlan drivers, and on Windows, it has nat, overlay, transparent, and l2bridge drivers. Each driver operates in the form of a plug-in and provides a role to manage as well as create all resources on the network [15].

Docker networking is based on these components, and more specifically, there is single-host communication between containers that share a single-host kernel and multi-host communication between containers on multiple hosts [15].

2.1. Single-Host Networking

The single-host communication method refers to communication between containers that share the same host kernel. Communication methods include ‘None Mode’, ‘Bridge Mode’, ‘Container Mode’, and ‘Host Mode’ [17]. Figure 4 is a diagram schematically showing the structure of various communication methods appearing in a single-host communication method [18].

First, ‘None Mode’ is a mode that sets the container to a closed network. It cannot connect to other containers on the same host or on an external network, and because of its characteristics, it has the highest isolation and security level of communication methods. ‘None Mode’ is used for tasks that do not require network access operations such as data calculations, batch processing, or backup operations. Figure 5 shows the network structure of the ‘None Mode’ method in a single host [18].

Second, ’Bridge Mode’ is a mode in which two networks are used as one network by connecting a container to a host. This is the network mode set by default when a Docker container is created, and it communicates by creating docker0 or a custom bridged network interface. Each container is isolated by a namespace, and they have a private IP address. Containers communicate by creating a virtual interface veth to connect to the bridge network interface that they must go through to communicate with each other. Although each container in ‘Bridge Mode’ is isolated, it provides relatively weak security compared to ‘None Mode’ because it is connected by a bridge. Figure 6 shows the ‘Bridge Mode’ network structure in a single host [19].

The third ‘Container Mode’ is a mode to communicate by sharing the namespace of the proxy container. Because containers sharing a single namespace use a common IP, they communicate with each other using Inter-Process Communication (IPC) and can be identified through port numbers. Communication with other containers is possible through ‘Bridge Mode’. In ‘Container Mode’, isolation from groups using different namespaces is high, but isolation between containers using the same group is low. Figure 7 shows the ‘Container Mode’ communication method in a single host [20].

Finally, ‘Host Mode’ is the mode in which the container uses the namespace of the host OS. It removes the network isolation between the container and the host and uses the host’s network directly. Therefore, this mode provides the lowest level of security. However, communication is as easy as exchanging processes with other hosts. Figure 8 shows the ‘Host Mode’ communication method in a single host [20].

Table 1. Comparison according to communication method in a single host.

Mode	Namespace	Network Interface	Network Driver	Security
None	Isolated	-	-	High
Bridge	Isolated	docker0/user-defined bridge interface	Bridge	Medium
Container	Connected with proxy container	Interface of proxy container	-	Medium
Host	Connected with host	Host	Host	Low

summarizes the characteristics of the communication method between containers on a single host according to the method in which each namespace is divided, the type of ‘Network Interface/Network Driver’ used, and the security strength.

2.2. Multi-Host Networking

Docker was developed for the purpose of networking between containers on a single host, so there were difficulties in container communication between different hosts. To solve this problem, solutions such as Calico and Weave began to appear, and after Docker version 1.9, Docker itself began to support overlay networking. Each support method can be selected according to the developer’s requirements.

First, a Docker overlay network plays a role of integrating into one network for containers running on multiple Docker daemons on one host or multiple Docker daemons on different hosts. In more detail, the Docker overlay network can be defined as a virtual networking solution using libnetwork and libk. It solves the scalability problem by using Virtual extensible LAN (VxLAN), an encapsulation protocol built into the libnetwork library. All management traffic is encrypted using AES algorithm by default, and application data encryption protects messages with IPsec on VxLAN [21]. Figure 9 shows an example of a Docker overlay network.

Second, Weave is a virtual networking solution developed by Weaveworks. It is configured as a Weave Net router and communicates by creating a veth–bridge network interface on each host to connect containers. Weave also uses the VxLAN encapsulation protocol, which allows for IP lookups of other containers using DNS queries for container names. In addition, the message is protected using the Networking and Cryptography library (NaCI), which provides network communication, encryption, decryption, and signature [22]. The fast data path in Weave uses the Open vSwitch module to announce to the kernel how to process packets. In addition, in the case of Weave NET, a method of issuing commands directly to the kernel is adopted, and context switching is reduced by using a fast data path, and there are advantages in terms of CPU overhead and latency efficiency. Figure 10 shows a general overview of Weave [22].

Finally, Calico is a virtual networking solution developed by Tigera. It uses two types of encapsulation, IP in IP (IPIP) and VxLAN, to explore routes to individual containers. IPIP is an IP tunneling protocol that encapsulates one IP packet in another IP packet, and routing information is exchanged between Calico nodes using the Border Gateway Protocol (BGP). VxLAN is applied to some environments such as Azure where IPIP is not applied and BGP is not used. Figure 11 shows an example of multi-host networking configuration for MySQL containers based on Calico [23].

Table 2. Characteristics of virtual networking solutions [18].

Overlay	Encapsulation Protocol	Name Service Support	Encryption Channel	Protocol Support
Docker overlay	VxLAN	N	N	ALL
Weave	VxLAN	Y	Y	ALL
Calico	VxLAN/IPIP	N	N	TCP, UDP, ICMP

is a table summarizing the characteristics of virtual networking solutions between containers on different hosts. It indicates the encapsulation protocol used, whether the name service is supported, the encryption channel used, and the supported protocol types.

3. Security Attacks Exploiting the Docker Container Network

In this section, we present our analysis of the network security attacks associated with communications between Docker containers. Container network security challenges can be expressed as the five challenges shown in Figure 12 below [24].

The description of challenges shown in Figure 12 is summarized in Table 3 below. (1) Each container has its own virtual network interface through which Docker can bridge other containers. However, the security challenge is that inspection of packets can only be performed in each container, and packet inspection in the host network namespace must rely on packet header information. If a malicious container exists on the bridge, this container can forge packets of other containers and enables lateral movement, making it impossible to inspect normal container packets. (2) Containers have dynamic IP changes using Dynamic Host Configuration Protocol (DHCP), making it difficult to update security policies using iptables and are vulnerable to Layer 2 attacks such as ARP spoofing. (3) Each container is subdivided and a security policy suitable for the container is required. iptables is a centralized management mechanism for host network interfaces. When a large number of containers are created, management of each container’s security policy becomes difficult and performance suffers [25]. (4) Container networks have an external gateway interface. Containers can access that gateway, which allows them to access services running on the host and also access other connected hosts. If a malicious container exists on container network, the malicious container may perform an attack that violates the availability of the host, such as DoS. (5) In the case of a container that has network authority over the host through Host Mode, the container’s isolation is low, so it can monitor the traffic of all containers connected to the host and inject malicious attacks.

Table 4 describes the network security threats that can occur between containers among the security problems that can occur on the above Docker container network and the resulting attacks [26].

3.1. Poor Independence between Containers

The network connection between Docker containers can weaken the independent container characteristics. For this reason, attacks such as DDoS and man-in-the-middle (MITM) attacks can occur. A DDoS attack is one of the availability breach attacks that depletes the victim’s computer resources and prevents normal operation. When a malicious container is inserted into the Docker network and connected to other containers through a network, it shares the same CPU core resource on a single host and may infringe the area of other connected containers. An attacker may use this maliciously to lead to a DDoS attack that consumes service resources. In an MITM attack, when two or more containers sharing the same network interface communicate with each other on a single host, assuming that there is a malicious container using the same network interface, the malicious container can intervene in communication between the two containers. Typical MITM attacks include sniffing that eavesdrops on communications, ARP spoofing that pretends to be another user, and tampering that can modify information in other containers without permission [27].

Table 3. Challenges in Docker container networks [24].

No.	Challenges	Description
1	Loss of container context	Malicious containers can forge packet header information through the bridge network, enabling attacks such as spoofing
2	Limitations of IP-based access control	Because of the dynamic change of container IP, updating the policy table of iptables can be difficult and vulnerable to Layer 2 attacks
3	Network policy explosion	As each container requires a different security policy setting the security policy through the centralized mechanism iptables can result in severe performance degradation
4	Unrestricted host access	A container can access it through a gateway for external access connected to the host network, allowing lateral movement to access other containers
5	No restriction on network privileges container	It monitors the network traffic of all containers connected to the host and can inject malicious attacks

Table 3. Challenges in Docker container networks [24].

No.	Challenges	Description
1	Loss of container context	Malicious containers can forge packet header information through the bridge network, enabling attacks such as spoofing
2	Limitations of IP-based access control	Because of the dynamic change of container IP, updating the policy table of iptables can be difficult and vulnerable to Layer 2 attacks
3	Network policy explosion	As each container requires a different security policy setting the security policy through the centralized mechanism iptables can result in severe performance degradation
4	Unrestricted host access	A container can access it through a gateway for external access connected to the host network, allowing lateral movement to access other containers
5	No restriction on network privileges container	It monitors the network traffic of all containers connected to the host and can inject malicious attacks

Table 4. Network security threats and related attacks for an inter Docker container.

Threats	Attacks	Description	Ref.
Poor independence between Docker containers	DDoS	A malicious Docker container depletes the resource of another container	[28,29,30,31]
	Sniffing	Communication between two containers can be eavesdropped	-
	ARP Spoofing	ARP spoofing is possible for containers running in the kernel	[29,30,31]
	Tampering	In the case of host mode, a malicious Docker container can modify information because the Docker container user the same namespace as the host	[29,30,31]
		In the case of container mode, information of containers sharing a namespace can be modified	[29,30,31]
Lack of security protocols	Sniffing	Unencrypted packets can be eavesdropped	-
	Tampering	Unencrypted packets can be modified	-
	Privilege Escalation	A malicious Docker container can access the endpoint of a Rest API, allowing elevation of privilege	[28,29,30,31]

Table 4. Network security threats and related attacks for an inter Docker container.

Threats	Attacks	Description	Ref.
Poor independence between Docker containers	DDoS	A malicious Docker container depletes the resource of another container	[28,29,30,31]
	Sniffing	Communication between two containers can be eavesdropped	-
	ARP Spoofing	ARP spoofing is possible for containers running in the kernel	[29,30,31]
	Tampering	In the case of host mode, a malicious Docker container can modify information because the Docker container user the same namespace as the host	[29,30,31]
		In the case of container mode, information of containers sharing a namespace can be modified	[29,30,31]
Lack of security protocols	Sniffing	Unencrypted packets can be eavesdropped	-
	Tampering	Unencrypted packets can be modified	-
	Privilege Escalation	A malicious Docker container can access the endpoint of a Rest API, allowing elevation of privilege	[28,29,30,31]

3.2. Lack of Security Protocols

The Docker communication system consists of a client–server structure. It is represented as a Docker client and a Docker daemon, respectively, which communicate with each other via the REST API. As the REST API uses the HTTP protocol, there is a possibility that it may be exposed to vulnerabilities in the protocol. Since the HTTP protocol is weak in security as security protocols such as TLS/SSL are not applied, MITM attacks such as sniffing and tampering are easy, and further security attacks that infringe confidentiality and integrity may occur.

In addition, the firewall of the REST API protects the intrusion of external attackers, but does not respond to security threats that occur inside when a malicious container is inserted. Recently, privilege escalation attacks using this vulnerability have occurred frequently, and through this, cases where the target host is exploited for cryptocurrency mining are increasing [32].

4. Experimental Setup

We now demonstrate some of the Docker network security attacks described in Section 3. We use Ubuntu version 20.04.3, and the experiments are carried out in Docker version 20.10.12. The host IP and container addresses are shown in

Table 5. Summary of Docker network security threats [26].

Attack	OS	Docker	Classification	Host IP	Container	IP Address
ARP spoofing	Ubuntu 20.04.3	Docker 20.10.12	Target host	192.168.19.130	busybox1	172.17.0.2
					busybox2	172.17.0.3
					ARP spoofer	172.17.0.4
DDoS					MySQL	172.18.0.2
					phpMyAdmin	172.18.0.3
					Ubuntu	172.18.0.4
Privilege escalation			Malicious host	192.168.19.129	my_registry	172.17.0.2
					ubuntu_attacker	172.17.0.3
			Target host	192.168.19.130	ubuntu_target	172.17.0.3

.

At this time, the MAC address of busybox1 is 02:42:ac:11:00:02, and the MAC address of busybox2 is 02:42:ac:11:00:03. Additionally, the MAC address of ARP Spoofer is 02:42:ac:11:00:04. The configuration of environment information for the DDoS attack consists of the MySQL container required for web construction, the phpMyAdmin container acting as the victim, and 20 Ubuntu containers acting as the attacker. After preparing two hosts, malicious host and target host, for the containers required for privilege elevation, the Ubuntu container required for attack on the malicious host, the registry to upload the image, and the Ubuntu container required for the target host to be attacked are prepared.

The ARP spoofing, DDoS, and privilege escalation attacks are performed based on the experimental environment specified in Table 5, and the main outline of each attack execution is as follows.

• ARP spoofing

For the ARP spoofing experiment in communication between Docker containers, it is assumed that a malicious container ARP spoofer exists on a single host. The ARP spoofer intercepts communication between busybox1 and busybox2 and disguises its IP as the IP of busybox1 and busybox2. Figure 13 shows the environment of the ARP spoofing experiment.

• DDoS

To experiment with a DDoS attack in Docker container-to-container communication, it is assumed that a malicious container exists on a single host. In the experiment, when the phpMyAdmin container and the MySQL container communicate with each other, 20 malicious Ubuntu containers simultaneously conduct a SYN flood attack through the hping3 tool. Figure 14 is a diagram showing the corresponding experimental environment.

• Privilege escalation

For privilege escalation experiments in communication between Docker containers, experiments are conducted on multiple hosts. First we need to set up a malicious host, which is the host of the attacker, and the target host, which is the host of the victim. The malicious host uploads a malicious Ubuntu image file to its registry my_registry and attacks the target host through its own Ubuntu. The target host downloads the malicious ubuntu image file from the attacker’s registry. When the target host executes the ubuntu file, the reverse shell is executed. Figure 15 shows the experimental environment briefly, and Figure 16 shows the overall workflow between the attacker and the victim in detail.

5. Analysis of the Attack Results

• ARP spoofing

The ARP spoofing attack is performed based on the attack method configured in Section 4. First, in order to determine the success of the ARP spoofing attack, the packets of busybox1 and busybox2 performing general ICMP communication are checked using Wireshark. From Figure 17, it is confirmed that busybox1 and busybox2 communicate normally with source and destination MAC addresses of 02:42:ac:11:00:02 and 02:42:ac:11:00:03, respectively.

However, when the ARP spoofer is involved in inter-container communication, if busybox1 (02:42:ac:11:00:02) and busybox2 (02:42:ac:11:00:03) communicate with each other, the destination MAC address 02:42:ac:11:00:04 can be seen through Wireshark. On the IP address, it is confirmed as the original communication between busybox1 and busybox2, but when it is checked through the MAC address, it can be seen from Figure 18 that the MITM attack that ARP spoofer intervened in is executed.

• DDoS

As previously described in Section 4, in the case of a DDoS attack, the attack is performed based on 20 Ubuntu containers and is performed based on the hping3 tool. Figure 19 shows that the hping3 command executed in each Ubuntu container acting as an attacker performs a SYN flooding attack on port 80 of the container whose IP address is 172.18.0.3. In the case of attacking the target by executing the command in Figure 19 in the 20 Ubuntu containers, we can confirm the network traffic through Wireshark as shown in Figure 20. It can be seen that when phpMyAdmin and MySQL communicate with each other, the Ubuntu container continuously sends the SYN messages to the target container, phpMyAdmin, and the Ubuntu container sends the RST messages to phpMyAdmin after receiving the SYN and ACK messages in response. Additionally, we can confirm that the traffic is classified as malicious (bad) TCP traffic in Figure 21.

As a result of observing the amount of accumulated traffic through the Wireshark I/O graph, it can be observed that there is no change in terms of packets per second (PPS), as shown in Figure 22 when the DDoS attack is not executed.

In the case of abnormal traffic confirmed by the execution of the DDoS attack, it is confirmed that the amount of packets per 100 ms is between 1500 and 2000, as shown in Figure 23. This confirms that the availability of the target environment is violated.

In more detail, the cAdvisor tool [33] is used to compare a CPU usage when a DDoS attack does not occur and when it occurs. The CPU usage in a normal state where the DDoS attack does not occur showed mainly usage 0% to 20% as shown in Figure 24.

However, as a result of measuring the CPU usage based on the time of the DDoS attack, the result shown in Figure 25 is confirmed, which means a high usage of 25% to 100%. This result shows that attackers can waste host resources regardless of intention when using Docker, which is a fatal security threat that harms availability.

• Privilege escalation

The privilege escalation attack described in Section 4 is performed. First, as mentioned above, it is assumed that the malicious host has uploaded a malicious image with a backdoor code inserted to access the target host to the registry. In addition, the target host is the situation in which the malicious image file uploaded by the attacker is downloaded, and the container is executed based on the malicious image. At this time, the ubuntu_attacker container of the malicious host is connected to the ubuntu_target of the target host. Figure 26 shows that the malicious host’s ubuntu_attacker container is connected to the target host’s ubuntu_target container.

When the ubuntu_target container is executed on the target host, that the reverse shell can be seen to have been executed as follows. To check this, it can be seen from Figure 27 and Figure 28 that the same result is obtained after inputting the same command into the ubuntu_attacker container of malicious host and the ubuntu_target container of the target host.

Figure 29 shows that the container of the ubuntu_target container is deleted from the ubuntu_attacker container through privilege escalation.

As a result, it can be confirmed through Figure 30 and Figure 31 that the information of the ubuntu_target container identified in the ubuntu_attacker container of the malicious host and the information of the ubuntu_target identified in the target host are the same.

6. Conclusions

This paper demonstrated through experiments that security attacks, i.e., ARP spoofing, DDoS, and privilege escalation attacks, can occur in communication between the Docker containers. We have analyzed the impacts of the security attacks in terms of network traffic, CPU consumption, and malicious reverse shell execution. Security attacks occurring in inter-container communication must be prevented, and efforts to demonstrate and analyze attacks based on the security mechanisms presented above are required. For future research, in order to conduct research on security systems usable on inter-container communication, we will demonstrate and analyze various Docker network attacks to which security mechanisms are applied and propose new ways to overcome the limitations of security mechanisms.