The paper proposes an approach to creating a system for modeling network activity. To demonstrate the proposed approach, a web-based modeling platform for network activity was developed based on the container virtualization technology. Docker containers were used as virtual machines. Demonstration and testing of the developed system was carried out. The results of the temporal characteristics of modeling the behavior of network activity in the following scenarios: ping, synood and WinFreeze.
approach require, signi cantly less resources and use for this purpose virtualization and emulation at the host level.
Table 1 provides a brief overview of the main existing systems for modeling the behavior of network activity.
One of the approaches to virtualization is the use of virtual containers, each of which runs the corresponding operating system. This approach to virtualization uses the Docker development platform. It shields the user from complex virtualization mechanisms, and provides a convenient interface for using. 2
Development of a common structure for a system for modeling network activity of the CS As a development platform, it is proposed to use web technologies. The advantage of this approach is the possibility of cross-platform use of the system and the provision of an open service without installing specialized software. Figure 1 shows the general scheme of interaction between the elements of the system emulating the behavior of a CS.
Connection to the developed system occurs via the http protocol through port 8001. Nginx is used as a web server. Django was used as a framework for developing server-side applications. Upon successful authorization and transition to the simulation page, the application server creates a new virtualization project and saves it to the database (DB). Adding a new node to the workspace binds it to the current project and puts the selected parameters for it in the database. The following components are available for building a network topology: computers, switches and routers, and communication lines. All components are emulated on Ubuntu 18.04 LTS with the creation of appropriate network interfaces. After building the computer network topology, the server software sends the Docker creation commands for con guring the containers with the parameters speci ed for them. Each Docker-container contains all possible networking scenarios.
After the con gured computer network is started, one of the prede ned network interaction scripts is selected and executed on the already running Docker containers that are already running. Figure 2 shows a diagram of how to run networking scenarios through a web interface.
The user in the web interface select the script to run, enter the required parameters and send an http request to the Django-server. The request contains: script name, source address (IP of the container from which script will be run), destination IP and additional parameters. The server retrieves the script startup parameters, con gure the docker exec command according to the received parameters, and then execute. Executing the command will run a network communication script on one of the containers.
Here is an example of running the script ping. Select the script "ping in the web interface, enter 192.168.0.2 in the "source Address" and 192.168.0.3 in the "destination Address". Additionally, you can ll in the "number of packages" and "package Size" elds, initially they contain the values 3 and 64 respectively. After lling in the required elds, click "Run". Clicking this button generates an http packet containing the speci ed script launch parameters and send it to the Django server. The server receives the packet, extracts the parameters run a script that generates the command "docker exec container02 python3 ping.py -c 3-s 64 192.168.0.3 &" and execute it. Executing the command activate the "ping" script on the container that corresponds to the IP address 192.168.0.2. The container sends 3 ICMP at 64K on the container with an IP address of 192.168.0.3, then the script exits.
During the execution of scripts, Docker-containers send a request about their state, containing the following elds: IP address of the sender, IP address of the recipient, error status, structure state of the node, containing information about the state of the node on the server. Tornado server and WebSockets are used as a receiver of this data. Tornado returns a response structure, whose elds match the request, to the network activity modeling page to visualize the process. Tornado saves intermediate results to the database. Results contains the following elds: source address, destination address, error status, and site status structure. In the error status eld, 0 is written if the packet was successfully delivered, otherwise, the error code, the node state structure is abstract, because of the script that was selected will depend on which elds it will contain. Figure 2 shows the system state diagram.
The initial state is the open project state. From it you can go to the following states: add node, add link, start emulation, save project, close project. From the add node state, a transition to the add link state is possible, a reverse transition is also available. From these two states there is a transition to the states start emulation, close project, save project. From the start emulation state you can return to the initial open project state in order to recon gure the network topology and restart the project. Also from this state there are transitions to the ping, SYN- ood and WinFreeze states. These states assume the execution of the corresponding python scripts. After executing the corresponding script, the system returns to the start emulation state, or goes to the save project or close project state. From the save project state, it is possible to switch to the start emulation and close project states. The close project status means the shutdown of the network activity modeling system.
For testing the developed system, three types of scripts are implemented: ping, SYN- ood and WinFreeze. The ping script is designed to verify the integrity of the connection between two nodes. To perform it, the user enters the following parameters: the source address, the destination address, the number of packets, the size of each packet. The script collects ICMP packets with the parameters speci ed by the user, calculates a checksum, encapsulates them into IP packets, sends them and waits for an echo reply or timeout. Returned responses are sent to the Tornado server and contain the elds for the destination address, the source address, error status, packet size, sequence ID, TTL, response time. In the event of a timeout, only the direction, destination and error status are sent to the server.
The SYN ood script implements a denial of service attack. The user must specify the IP address of the machine from which the attack will be conducted, the IP address and port of the victim. The attacker's computer over ows the connection queue on the victim's computer, sending SYN requests. SYN + ACK packets received from the victim are ignored, keeping its ports in a half-open state. The script keeps the queue full so that the connection to the ports of the victim is di cult or impossible [BSR13]. When receiving a SYN + ACK packet, the script sends a packet to the Tornado server containing the attacker's IP, the victim's IP and port number.
The WinFreeze script causes the victim's computer to attack itself. The user speci es the attacker's IP and attack target IP. The attack is performed inside the victim's network. The attacker sends ICMP redirect messages on behalf of the router to the target address, informing about the choice of a non-optimal route and the need to add the best route to the routing table. All victim packets are redirected back at the victim by attacker. Due to the large number of such messages, the victim will spend most of his resources processing packets and attempting to modify the routing table. With each packet received, the script sends to the Tornado server a packet containing the attacker's IP, the victim's IP and the number of packets already forwarded. Figure 3 shows a web interface with an example of network topology.
The gure shows a topology with two subnets with the following addresses: 192.168.0.0/24 and 192.168.1.0/24. Green lines indicate routes that ping between nodes 192.168.0.4 and 192.168.1.4. Under the working area there are buttons for adding switches, routers, computers and communication lines, a button for starting the emulation, as well as buttons for emulating network activity: ping, syn- ood and WinFreeze. 3
Experimental results of the time characteristics of the developed system for modeling the behavior of network activity
The time of visualization of the experiment coincides with the time of its holding. The graph shows that the time between the experiment and the transfer of results to the user almost coincides. Due to the lack of desynchronization of time intervals on the main OS and containers, it allows the user to connect to the corresponding container to conduct a more detailed analysis of the script.
Experiments show that the use of virtualization signi cantly reduces the simulation time. This is due to the following factors: packets are not sent outside the network interface of the host, containers of the same subnet are connected to a common virtual interface such as a bridge. As the number of devices grows, and consequently the number of containers deployed by Docker, the simulation time starts to slow down. The limit value of the maximum number of running containers is determined by the resources of the server running the network activity modeling system.
The results of the work in comparison with the Kathara system are show in table 2.
The paper proposed an approach to creating a system for modeling network activity. A web platform for modeling network activity was developed based the Docker containers. A study of the developed system for compliance with the requirements. The study showed the possibility of using the Docker platform for the implementation of a network activity modeling system. All network attacks carried out in the created virtual network work equivalently to real network. The time delay between the experiment being conducted and the virtualization time does not exceed one second. The proposed approach and the developed web-platform can be used in testing and developing mechanisms for countering network threats. A feature of the developed system is the ability to package in a single Docker image for rapid deployment. [Ora] Oracle weblogic deserialization rce vulnerability (0day). [Sha] Internet issues & availability report 20182019. [Unp] Unpatched zero-day vulnerability in social warfare plugin exploited in the wild.