when i joined the OpenSOC team at the beginning of this year, everything resided on 3 intel skull canyon NUC's, a couple other systems for scenarios or applications with hardware requirements, a ubiquiti WAP, a synology NAS, and various other things.
it has since gained a NUC, we replaced a system due to a failed hard drive, we no longer have to use the WAP since we have adopted zerotier and are also able to run on cellular if necessary, and OpenSOC overall has undergone some serious restructuring, re:infrastructure.
the NUCs are ESXi servers, running a complete enterprise environment. windows systems (20+), directory server, mail generation, traffic generation, firewalls, you name it. plus various other windows and linux systems to support some of our scenarios, all the systems for the red team activity (can't have a CTF without a kali VM or 2). there's a lot going on.
when we (and mostly eric, this is his brainchild) initially built it, all of the DFIR systems (graylog, kolide, wazuh, moloch, GRR) were running on the same vSphere ESXi cluster as the windows environment. that's like 10 more resource intensive VMs.
it's a lot.
so in addition to hitting resource limitations, we were having to make sure we balanced said resources across each hypervisor, especially at boot before every event. we also started having issues with the dswitch configurations and connectivity dropping randomly, eric had to completely reinstall vsphere at one point, and i don't even remember all of the other things. a lot has happened in 6 months.
keep in mind, this is not our day job. this is what we work on until our eyes bleed at 4 in the morning. it is absolutely a passion/borderline obsession.
we decided to make a big change, to hopefully alleviate a lot of our issues, and make our event more scalable: move the DFIR systems to AWS, but still be able to fall back to the range systems.
let me stop right there for a moment to shed some light on the situation at hand. i was asked to rebuild this entire environment, to scale, and automate all of it. this is the equivalent of kid in a candy store for me.
so i got to work. i had already automated a LOT of the pieces that i needed in order to do this. my tools of choice? AWS cloudformation, and ansible.
i know some of you will scoff at one or both of those and be like, why didn't you use terraform? or GCP? anything else? TL;DR: ansible is my bread and butter as much as AWS is. i had a lot of the heavy lifting already written. and i know it works.
curve ball: all of our *nix systems are ubuntu. coming from a former fedora fan girl and official red hatter, my instinct these days is to type apt instead of yum or dnf. i am so conflicted (but no one will ever take my vim away).
visual representation of our current stack:
when we deploy our current stack, it builds the following, configured and ready to be hit by all of our windows systems and sensors in the range:
- our VPC
- subnets (omg so many subnets, like 40, network segmentation and HA FTW)
- routing tables
- VPN server
- VPN tunnel to the range
- security groups (again, so many)
- load balancers (classic or application, depending on what each setup needs, and sometimes multiple load balancers depending on public or private access)
- target groups
- DNS/route53 entries
- elasticsearch cluster
- redis cluster
- mongo replica set
- auto scaling groups (for graylog, wazuh, kolide, moloch, GRR, nginx, etc)
- launch configurations / user data
- mailgun configurations for services that need it
- ECS services, for things that need to be dockerized (see tangent below)
there are also pieces in there that run after everything is built. once the above cloudformation stack is done and ansible deploys all of those applications and configures everything, the playbook continues on to install new relic agents, telegraf agents, graylog sidecar collector / osquery / wazuh ossec agents on all of our own systems (FUN FACT: we monitor OpenSOC with our production stack!), and then add everything that needs to be user-facing to zerotier.
if you're curious, the ansible roles directory that this runs from? 47 roles. it is no joke.
you guys. in a single build.
to clarify, this is very much our environment when it builds. this isn't a vanilla graylog stack with a vanilla kolide setup and a vanilla wazuh and moloch. these are all configured to OUR specifications and with OUR data, our queries and our pipelines and our OSSEC rules and sysmon configurations (the list goes on), that we've consolidated over the last several months and years of experience. it is tailored to fit our needs. and it is the culmination of so many months of hard work to get it to this point.
granted, it takes like 30 minutes for it to finish all of that. but it's so beautiful at the end when it all turns green :)
additionally, this does not include any of the red team activities that make all of our scenarios come to life. that is an entirely separate effort in and of itself, as is the faux enterprise environment. both of those deserve a blog post of their own.
TANGENT: i'm all for docker. i love it. but i refuse to put anything in a docker container that doesn't belong in it. it's very much an "if the shoe fits" situation, for me. sometimes it makes things better and more awesome, but sometimes it adds unnecessary layers of complexity. and it needs to be done right. and i will admit, i went against my gut when we deployed the scoreboard that way. basically, we wanted it to be empty every time we deployed it. fresh image, and bam. preconfigured, hit go, and we're off. but. that didn't work out as intended. and i apologize (because there were a lot of facepalms at DEF CON, including mine). however, most of our issues had nothing to do with it being in docker. we're working a solution for all of that, regardless, and looking at other options. to be continued.
one of the best parts about this project? we have learned at every single event what we want to change, tweak, rip out, improve, etc. this is all infrastructure as code. see something that needs adjusting? done. it is 100% flexible. it will never be perfect, but we are still aiming for it.
at some point in the near future, we plan on automating a lot of our windows builds as well. one thing at a time!
if you have any questions, please reach out to us. we love doing this and we pour our hearts into it. we also love nerding out and talking about it. so hit us up on twitter or find us at an event in the future!