Praxis Multirole VM Network
The more work I was doing on Tapestry, and the more convinced I became it was possible to have the same script run correctly on multiple operating systems, the more I found myself moving between my Ubuntu Desktop-based laptop and my Win10-based desktop for testing. This was inconvenient enough, but when the desktop died beyond the possibility of economic repair, it became clear that a different solution was needed. A VM seemed the most tempting way to go.
Of course, you can never be satisified with just one VM, and in the process of learning about virtualization, I discovered this book by Tony Robinson (no, not that one), which detailed a process for building a general-use network in a variety of hypervisors and then talked a bit about what you could do with it. I spend a few month's worth of lunch breaks setting his network up and I gotta tell you, even its basic configuration is really useful for a lot of what I find intresting, which is studying the security of systems.
Of course, as with all generalized solutions, you can get even better results with a bit of specialization and tweaking. Out of that interest, an idea was born - is it possible to script the process of reconfiguring the overall network in order to better. At the moment that idea is in its earliest infancy. I haven't even selected a working language yet.
The concept, on the other hand, is pretty easy. Create a script that will modify properties of the saved VM states to alter their network connection values. While we're at it, have that same script then bring up the necessary machines in the necessary order - not all networking tasks will require my Snort IPS, the Kali VM, or whatever. This would allow, by calling the appropriate mode as an argument to the script, to quickly move machines between various subnets by changing their network interfaces.
Of course, this will require some additional work in the back-end as well. such as configuring the pfSense VM (which has the only bridged connection) to support these different machines being rearranged. I'm also tempted to set up some flavour of internal DNS to make addressing machines simpler regardless of the config state or current network map.
My intended preset configs will be: guest-managed, cross-NAT Pentesting, simulated-enterprise and simulated-SOHO.
Default/Multirole: A fairly basic configuration suited for a variety uses and as first discussed in the book. A central pfSense VM governs two subnets: 172.16.1.0/24 ("Management") and 172.16.2.0/24("Guest"). A subnetwork is further provided on "Guest" by use of an AFPACKET bridge provided by an IPS machine running Snort on Ubuntu 16.04LTS, this intended to emulate an "office" environment in the vaguest terms. I chiefly use this for pentesting a metasploitable2 machine on one side of the bridge with a kali machine on the other and study the logs - which are collected in a SIEM machine running Splunk on Ubuntu 16.04 LTS. I am also currently working on automating some of that work with python.
Development Testing Array: A slightly more complicated build. The SIEM, IPS, and central pfSense router from the multirole configuration are retained, as is the Kali Machine. On the far side of the AFPacket Bridge, I have placed another pfSense instance, which, after some configuration serves as a simulated firewall appliance for an Ubuntu Server host that is a clone of this very server. The intended application is testing server changes before deploying to production, as well as providing a limited lab for cross-NAT penetration testing.
This is a smaller-scale version of a larger, simulated-enterprise pentesting network I would gladly build if ever I figure out a way to pack the required RAM into my machine.
Malware Testing and Reversal: A tiny network of bare-bones windows, ubuntu desktop and ubuntu server machines I can use to study the activity patterns of malware and develop mitigations. This configuration is probably the least frequently used as I have yet to find a comfortable way to gather malware samples.