cyberrange

Incus based Cyberrange

Why Incus?

Incus Advantages:

System vs. Application Containers: Incus specializes in system containers, which mimic an entire operating system environment. This allows you to run complex setups with multiple applications and dependencies within a single container. Docker, on the other hand, focuses on application containers, ideal for isolating single processes or services.

Security: Incus arguably offers better security by default. Docker containers traditionally run with root privileges, which can be risky. Incus containers can run with non-root users, reducing potential security breaches.

Resource Allocation: Incus provides finer-grained control over resource allocation compared to Docker. You can assign specific CPU cores, memory limits, and network resources to each Incus container.

Order of platform bringup

1. Ensure the Hardware system supports virtualization and it is enabled. For Windows: You can check if the services are running: Win+R -> services.msc Look in the list for all services beginning with Hyper-V. If any of them are Running, it's on. (Specifically, the core of it is labelled Hyper-V Virtual Machine Management)

2. Ensure Virtualization is enabled for the Linux VM that will function as Incus host. Similar to VMWARE. Check "VM advanced settings --> Processors --> Virtualization Engine --> Virtualize Intel VT-x/EPT or AMD-V/RVI" Tick box is set on VMWare workstation

3. Create an Ubuntu Linux server with minimal footprint.

4. Install "Incus" by referring to https://linuxcontainers.org/incus/docs/main/tutorial/first_steps/ .

5. Directory Structure:

      kaushal@incushost:~$ tree  microcr/
      microcr/
      ├── launcher.py                             --> Python script for Launching any topology.
      └── topologies                              --> Topologies collection.
         ├── ent_2t1                              --> Enterprise Tier 2 type I.
         │   ├── clear.sh                         --> Clears ent_2t1 scenario deployment.
         │   ├── containers                       --> All containers of ent_2t1.
         │   │   ├── Attacker                     --> One container in ent_2t1.
         │   │   │   ├── Attacker.yaml            --> Incus config for launching this container
         │   │   │   ├── container_config.sh      --> Container specific configuration.
         │   │   │   ├── etc
         │   │   │   │   └── rc.local
         │   │   │   └── root
         │   │   │       └── hey_http_traffic.sh
         │   │   ├── cfg.sh                       --> Invokes container specific configs for all.
         │   │   ├── cr.sh                        --> Creates all Incus containers for ent_2t1
         │   │   ├── ExternalFirewall
         │   │   │   ├── container_config.sh
         │   │   │   ├── etc
         │   │   │   │   ├── dnsmasq.conf
         │   │   │   │   └── netplan
         │   │   │   │       └── 10-lxc.yaml
         │   │   │   └── ExternalFirewall.yaml
         │   │   ├── InsideLinux
         │   │   │   ├── container_config.sh
         │   │   │   ├── etc
         │   │   │   │   └── rc.local
         │   │   │   └── InsideLinux.yaml
         │   │   └── WebServer1
         │   │       ├── container_config.sh
         │   │       ├── etc
         │   │       │   └── rc.local
         │   │       └── WebServer1.yaml
         │   ├── cr.sh
         │   ├── network
         │   │   ├── cr.sh
         │   │   ├── incusBrDMZ.yaml
         │   │   ├── incusBrINSIDE.yaml
         │   │   └── incusBrOUTSIDE.yaml
         │   └── topology_diagram
         │       └── basic_corp
         ├── ent_2t2
         │   ├── containers
         │   └── network
         ├── ent_3t1
         │   ├── containers
         │   └── network
         └── ent_3t2
            ├── containers
            └── network

6. Incus generic configuration details:

   (i) Incus Linux host's main interface gets internet from the local wifi/LAN directly instead of NATTING from host.
   
   (ii) All containers have one interface in mgmt bridge for configuring/managing that container. In future, this can be disabled once the scenario training starts and instead a port forwarding based container access can be provided.
   
   (iii) Depending on the container, it will have additional interfaces in different other bridges that form the corporate network.
   
   (iv) Corporate network is made up of three main bridges: OUTSIDE, DMZ and INSIDE.
   
   (v) All attacks and traffic go through the non-mgmt interface.
   

7. By default the iptables rules for "FORWARDING" is to DROP. However if iptables drops, then none of the incus containers can "ping" to the external world through mgmt interface for any package installation. To avoid this we can use the following cmd:

   sudo iptables -P FORWARD ACCEPT

8. To install the ctf web interface platform on the incus host:

   kaushal@incushost:~$ sudo docker run -d -p 8090:8000 ctfd/ctfd

   Above command leads to: sudo docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 9094114e5abb ctfd/ctfd "/opt/CTFd/docker-en…" 2 minutes ago Up About a minute 8000/tcp, 0.0.0.0:8090->80/tcp, :::8090->80/tcp keen_turing

9. To configure the ctfd environment:

   Login into : http://192.168.29.178:8090/setup This logs into admin panel for the first login by default. Configure the details starting for each tab: A. General, Mode, Settings, etc. It also asks for admin login credentials. Once populated, it will give the admin panel for next steps. B. Go to Challenges and click on the "+" . Start adding the challenge and its associated flags etc. C. Login from another browser or incognito window. When prompted from username and password, click on register to start a team and play the game.