# GoibhniUWE: A Lightweight and Modular Container-Based Cyber Range
## 4 Design of the GoibhniUWE Cyber Range  
The idea behind the development of the GoibhniUWE cyber range is to provide a containerised environment which can be used for both education and research purposes. The design principles behind its development are supported by the following requirements:  
* \(R1\)--Minimal deployment: The cyber range should deploy and run with minimal resource overhead. * \(R2\)--Modular: The cyber range should support the ability to easily swap out different vulnerable services depending on the desired scenario. * \(R3\)--Real-time: The cyber range should support real-time monitoring and logging from multiple sources. * \(R4\)--Scalability: The cyber range should support the ability to scale up the infrastructure as required by the deployed scenario. These requirements also underpin our proposed solution to issues highlighted as part of the CRDF [20]; the consideration of \"workspace requirements\" for on-demand learning and deployment (\(R1\)); and the need for ongoing, layered learning (\(R2\)-\(R4\)). Figure 1 provides a high-level graphical overview of the GoibhniUWE cyber range. The use of containers as an alternative to VMs in the implementation of our cyber range allows for quicker deployment, with minimal performance overhead (\(R1\)). Different vulnerable services can be selected through the User Interface (UI), and these will be deployed using Docker (through a Python API). These vulnerable services are then run as containers, with networking and IP assignment managed by GoibhniUWE. This allows for ease of scaling (\(R4\)) of the range to add other functionalities, such as internal services, which require pivoting from the initial access point or target OS to access them. Designed to facilitate the analysis of various attacks and Tactics, Techniques, and Procedures (TTPs), our container-based cyber range is composed of multiple containers. The AttackBox runs Parrot OS, a Linux-based distribution that is designed for penetration testing and that comes pre-loaded with multiple, relevant tools, such as Nmap, msfvenom, etc. This is used to simulate an engagement by a malicious actor. Vulnerable services are launched separately and will vary depending on the target architecture desired. These can consist of single to multiple services which are positioned throughout the target network, with the option to have these set up to mimic external or internal services. End users can set up process monitoring on a specific \"target\" container. This can be a default Ubuntu or Alpine OS or one of the selected vulnerable container instances (\(R2\)). Auxiliary containers can also be launched as part of the scenario setup and deployment. For example, a RandomTraffic container that will generate random traffic targeted at a provided list of endpoints (or single running service) and an AutoAttack container which runs automated scans against vulnerable service(s) can be utilised, adding additional \"malicious\" traffic to the captured logging. These containers add a degree of \"realism\" to scenarios and provide noise to captured logging which can be useful when using the generated logging in support of research (such as input to Machine Learning (ML), Deep Learning (DL), or Artificial Intelligence (AI) tooling), as well as for educational purposes. Figure 1: Container-based architecture of GoibhniUWE. Logging is conducted at multiple points to ensure maximum coverage of actions taken. Network traffic is captured using tcpdump, which is deployed on the host, and Packetbeat is deployed as a container. A Suricata container configured with default rules is used as an Intrusion Detection System (IDS). Container logs are captured using Filebeat and, along with the Suricata logs, are fed into a containerised Elasticsearch instance. The log aggregation simulates a Security Information and Event Management (SIEM) system and is fed into a Kibana container, which provides a dashboard for real-time monitoring and analysis, which can be accessed on the host machine.