After several months of using ludus, creating my own roles, and spinning up / tweaking several labs, I’m starting to feel confident enough to write about it.
This is a work-in-progress – a few notes that I thought I’d share, which have saved me some time and which I will continue to update. Watch this space.
And fair warning: there is nothing earth-shattering in this post obviously - it’s more of a reader’s guide to the documentation, with a few tips and tricks I’ve picked up along the way.
Ludus is a great way for red-teamers and blue-teamers to create cyber-ranges. It’s built on existing tools - such as proxmox, ansible and packer - but geared toward creating infrastructure that is easy to set up and tear down.
The ludus documentation site has become my number one reference
The ludus documentation wiki is a real gold mine of information. I would highly recommend perusing it from cover to cover once so that you know what’s in there. A lots of the issues that I had started working on would have spared me a lot of time if I’d just RTFM, and this is the kind of manual that is a pleasure to read. Short, to the point, and with lots of screenshots.
The Security section is a must-read. You’re deploying machines with default passwords and a system that allows people to deploy arbitrary infrastructure; make sure you know what you’re getting into.
I particularly appreciated the snapshots and nexus cache sections, as you’ll see below The deploy tags and roles are sections you won’t want to ignore either.
Making the most out of snapshotting
When I have an idea, I want to get started on it right away. Tempus fugit, you know.
So I’ll often want to spin up an environment, play around with it, and then tear it down. However, it takes a bit of time to spin up a range. If I’m spinning up a range from scratch it will take a couple of hours. Spinning up an environment like GOAD takes even longer on my commodity hardware.
So what I’ve been doing is taking a page off of GOAD - I’ll create a user dedicated to a type of range and I’ll spin it
up. Once it’s deployed for the first time, I’ll create a snapshot of it with ludus snapshots create first-deploy; and
then I’ll power it down with ludus power off -n all.
When I want to conduct an experiment, I’ll power the infrastructure back on with ludus power on -n all and then at the
end rollback my state with ludus snapshots rollback first-deploy. Your deployments stay clean and they’re quick set
setup/teardown.
One caveat with this, as you can imagine, is the space this approach takes up on your disk. The 100 GB recommendation for space that ludus describes in its documentation is good for about a single, simple range. Make sure you have a beefier disk that can handle it!
Adding infrastructure and roles on the fly
Sometimes I’ve built a lab for experimentation and then realized that I need an extra machine for my experimentation, or an extra tool that’s available in a role.
I used to trash my existing range, modify it, and then redeploy it. This, of course, works fine; but it takes a while to redeploy your infrastructure and in the meantime you lose traction / context.
So, I’ve been leveraging the following technique. I’ll sometimes need Visual Studio, so I’ll install it on a windows box:
# Step one: pull the existing config into a temp file.
ludus range config get > temprange.yml
# Step two: modify the config to include your tool. In this case, we add the `visual_studio_version` parameter of the
# `windows` section. See the range config schema in https://docs.ludus.cloud/docs/configuration for more info.
# Step three: set the config.
ludus range config set -f temprange.yml
# Step four: redeploy, limiting the deployment to the machine. And watch live as the range updates.
ludus range deploy -t install-visual-studio --limit <yourrangeid>-ad-win11-22h2-enterprise-x64-1 && ludus range logs -f
Adding a machine on the fly is actually documented on the ludus wiki so I’ll just link to it: https://docs.ludus.cloud/docs/tags/#adding-a-single-vm-to-a-range-then-configuring-it