Vigrid new release v1.1, validated for Ubuntu 22LTS.
Vigrid is an extension to the GNS3 Hypervisor to turn it to a Cyber Range or a industrial training platform.
Once GNS3 is redesigned to Vigrid standards, trainings, Blue Team/Red Team or classical Capture The Flags will be possible through unlimited (upon hardware capabilities of servers) number of clones so each user or team can work on his own.
Virtual machines can work on many CPU (amd64/x86 of course, but also ARM, PowerPC, MIPS, Sparc etc).
A simple functionnal web server provides clientless access to virtual devices consoles (telnet or graphical) without keyboard issues and virtual machine or lab basic controls (power). Finally, through easy CLI commands (Web GUI TODO), virtual machine snaping shot, massive project cloning are available. RBAC is not yet provided because it will be available with GNS3v3.
Your server power is the limit :-)
Vigrid relies on standard designs: Standalone (historical gns3 design), Standalone with NAS, slaves with NAS, scalable with NAS Vigrid covers all topics to have all features available, from start to end: NAS installation, GNS3 installation with Vigrid extensions
Name 'Vigrid' refers to the Ragnarok battleground, ultimate battle of the Gods (nordic mythology). You may also think it as 'V grid' (Virtualization Grid).
Vigrid extension is copyrighted to Laurent LEVIER, licensed under Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International
Vigrid (main) is now API ready:
- New NGinx+PHP installations to provide device load details are now part of install scripts.
- Requests performed over HTTPS will provide cpu/network/disk details in JSON format.
- Added to vigrid-addslave the actions to add Slave to Master NGinx configuration and then address them via Vigrid Master.
- Still to update Vigrid Web pages to move to API and no longer use the dirty SSH scripts.
- Ongoing developpement of a JS interface, expected much faster response than current synchronous PHP.
New service : Vigrid deployer. Its mission is to massively install operating systems on baremetal or virtual machines.
To install it, runs on your Vigrid NAS:
sudo /Vstorage/GNS3/bin/vigrid-update
sudo /Vstorage/GNS3/install/vigrid1-deployer-install.sh
Nota : Vigrid-deployer will install a DHCP server on the Vigrid NAS, it might conflict with your own one.
First, install the last Ubuntu server LTS version on your hosts(s).
Nota: install now validated until Ubuntu 22 LTS.
Recommendations:
- Ubuntu:
- 32GB for root filesystem
- Swap at your convenience
- GNS data storage:
- Either on NAS or standalone servers: add more disk(s) (the bigger the better) for data and others for cache (R/W speed++). These disks for Vigrid storage will be detected and managed by the install script.
If you want to build an infrastructure (development version), please first install NAS launching:
wget https://raw.githubusercontent.com/llevier/vigrid/main/install/vigrid1-nas-install.shsudo sh vigrid1-nas-install.sh, then provide the user password.Nota: all script input/output is logged to a file into /tmp..
Vigrid NAS design: the main ennemy of NAS is disk I/O. Roughly, it is considered a mecanical drive is able to perform 100 IOps. Accordingly, recommandations to have best NAS are:
- Rely on hardware RAID (check possible performance issues related to ReadAhead & WriteBack).
- Use RAID-1 or RAID-5, not RAID6 and more parity drives (loss of performance at writings).
- Use as maximum of physical hard drives to spread the load, dont care about too much disk space.
- Use SSD drives as cache, as with RAID, dont be afraid to have RAID-1 virtual drive as cache, spreading will raise IOps.
- Disable all hardware optimisation mecanisms for cache drives (again ReadAhead & WriteBack).
- Of course, obviously, if all hard drives are SSD, you will tremendously increase performance.
As an example: server with 2xe5-2620v3/128GB RAM, hardware RAID5 of 10x6TB HD + RAID1 of 2x400GB SSD as cache handled around 1000 32GB GNS3 VM simultaneously over a 10Gb/s network link.
Else or to install Vigrid server(s) (standalone, scalable or cloning farm), launch:
wget https://raw.githubusercontent.com/llevier/vigrid/main/install/vigrid2-gns-install.shsudo sh vigrid2-gns-install.sh, then provide the user password.Nota: all script input/output is logged to a file into /tmp.
You can read the documentation for further explanations about designs, installation and usage.
When Vigrid is in NAS mode, it means many projects/clones could be launched at a time. One must keep in mind that a NAS has not infinite disk or network bandwidth. Despite all my efforts, growing timeouts etc, if you launch too many nodes at a time with virtual hard drives stored on central NAS, network or disk saturation could lead to node failure or virtual machine disk I/O errors. For now I have no other (yet) cooking recipe than checking each node load time, then put enough delays between project/nodes launches to avoid this situation. With local data risk strong reduces, so I prepared Vigrid in a new design: Hybrid. In such a design, Vigrid keeps controlling centrally but projects are restricted to specific hosts where data is stored. Of course, this risk can be manage also with better network, storage devices etc, as well as using different network interfaces and NASes. Promissing study: ZFS over GlusterFS, itself sharing over NFS 4.2 (multipath). At the moment changes on ZFS are not propagated to GlusterFS :-(
For now, Vigrid is updated at high frequency and there is no starting version yet. Best method to be up to date is to regularly launch 'vigrid-update', considering this might generate short time issues. A v1 version is planned ASAP so versionning can be properly performed.
You can report your issues via github. For each issue, please at least provide the Vigrid Type (standalone, master etc) and the Vigrid network design (your concern, TINY of FULL cyber range).
Vigrid layer is only developped by a single person on best effort on personal time. All contributors to add new features are welcome.
Some most wanted features for a Cyber Range are in the TODO list: Cloning with docker nodes + PuppetMaster.
Feel free to contact me.
| Topic | Status |
| First GNS3v3 tests | Postponed to new RBAC model on GNS3v3 |
| Error handling by command in install scripts (failing command can be rerun endlessly) | Queued |
| Change Control Tower display (project first column, then host) so start button automatically select best available host | Queued |
| Check code for security issues (input controls etc) | Periodic action |
| Test & validate 'projects with docker nodes' cloning | Validated (limitations now known), queued |
| Try to build a ZFS snapshot hierarchical tree to show dependencies | Queued |
| Add ZFS hold/release management on snapshot page | Queued |
| Concurrent/conflicting action detector | Queued |
| Add BTRFS management on servers (tested/validated but not implemented in Vigrid) | DONE, extensive tests to perform |
| Finish snaping/cloning at nodes level | Validated with both FS, queued |
| Add IPMI support for power control commands (only HP iLO for now) | Queued |
| Add automatic ecological savings (power on/off slaves according to needs) | Validated, queued |
| Add control tower URL to VIGRIDclones.list query (for mail sent to clone owner) | Queued |
| Move from PHP to Javascript code so browser can control slaves directly (via Vigrid hybrid mode) with much faster web display response time | Hybrid mode validated, queued |
| Move Vigrid NAS so it can satisfy requirements + provide parallel network sharing (major risk of projects launch failures) | Study ongoing |
| Developing a scenario automation software (PuppetMaster) to control discrete agents (Ghosts) into project so they can perform actions. For now, only concept of a central server controlling Ghost nodes into projects has been proven. | Ongoing |
| Creating a life simulation systems so network behaves as if real users would be working (mail, surf etc). | Ongoing |
| Add a shortcut on each Qemu node to 'qemu rebase' node disk (thus removing appliance image dependancy) or 'qemu commit' node disk to have appliance disk updated (thus failing all other nodes depending on it). | Queued |