Savvy contestants who know their way around around the IP Address Block can lock down a service, such that only the Scoring Engine can reach through the firewall, leaving red team with no options. While it's great that the participant is demonstrating defensive networking skills, they would not be able to do this in a production IT shop with real customers. To this effect, we would like service checks to be performed over multiple networks. Blue teams should be black-listing bad actors, not white-listing when their services are supposed to be public.
As Worker Nodes
The initial idea I had for this, would have been to permit the configuration of other VMs as worker nodes to the Service Checker. The master would schedule nodes to run a check against each team, and report back the results.
Adding whole other machines distributes the work load, but this also brings all the complexity of distributed systems into the mix (implementing fail over, networking, etc).
You can do this in a crude way - right now with no application changes - by deploying multiple Service Checkers, and coordinating toggles of which checks are run on each VM. This could be done using something like salt stack or even pssh to orchestrate changes over the checks.toml file.
As Linux Network Namespaces
Continued research led me to "Linux Network Namespaces", which would allow the service checks to be run on different networks without updates to the check scripts themselves. I've found several posts detailing this feature or using comparable methods, such as cgroups:
My idea is to add a config file option which provides a set of network namespaces. One would be randomly selected before each check is run. Then, the script would be wrapped in an ip netns exec <ns> ... call, using the same ns for all teams.
This solution would be restricted to Linux environments. To support BSD, jails would be the tech to look at, but let's stick to Linux for now.
If there are any other ideas to achieve this, I'm all ears. There are definitely trade-offs to weigh.
Background
Savvy contestants who know their way around around the IP Address Block can lock down a service, such that only the Scoring Engine can reach through the firewall, leaving red team with no options. While it's great that the participant is demonstrating defensive networking skills, they would not be able to do this in a production IT shop with real customers. To this effect, we would like service checks to be performed over multiple networks. Blue teams should be black-listing bad actors, not white-listing when their services are supposed to be public.
As Worker Nodes
The initial idea I had for this, would have been to permit the configuration of other VMs as worker nodes to the Service Checker. The master would schedule nodes to run a check against each team, and report back the results.
Adding whole other machines distributes the work load, but this also brings all the complexity of distributed systems into the mix (implementing fail over, networking, etc).
You can do this in a crude way - right now with no application changes - by deploying multiple Service Checkers, and coordinating toggles of which checks are run on each VM. This could be done using something like salt stack or even
psshto orchestrate changes over thechecks.tomlfile.As Linux Network Namespaces
Continued research led me to "Linux Network Namespaces", which would allow the service checks to be run on different networks without updates to the check scripts themselves. I've found several posts detailing this feature or using comparable methods, such as cgroups:
My idea is to add a config file option which provides a set of network namespaces. One would be randomly selected before each check is run. Then, the script would be wrapped in an
ip netns exec <ns> ...call, using the same ns for all teams.This solution would be restricted to Linux environments. To support BSD, jails would be the tech to look at, but let's stick to Linux for now.
If there are any other ideas to achieve this, I'm all ears. There are definitely trade-offs to weigh.