# Azure Malware Lab: Network Build Right, we've wrapped our heads around the theory [[Azure Malware Lab Design]], and now it's time for the fun part - actually building this thing! Before we dive in, I've got some good news: I've put together some automation code that'll handle all the heavy lifting for you. You can grab it here: [Azure Malware Lab Network Infrastructure](https://github.com/Syb3rs3c/Azure-Malware-Lab/tree/main/1.%20Build/Network_Infrastructure) Give that README a proper read though - there's quite a bit going on under the hood, and you'll need to know what to tweak for your setup. The code's pretty fancy - it'll sort out everything from your User Defined Routes to your NAT gateways, saving you a ton of clicking around in the Azure portal. But here's the thing - even if you're planning to use the automation (and honestly, why wouldn't you?), it's super important to understand what's actually happening. Remember, we're building a malware lab here - security isn't just a checkbox, it's the whole foundation! Understanding how all these pieces fit together will be a lifesaver when you're troubleshooting or need to adjust things later. So grab a coffee or a cuppa, and let's walk through how to build this thing piece by piece. Don't worry, I'll guide you through it step by step: 1. Set up our User Defined Routes (UDR) with a null route 2. Create our malware analysis network (*mal_net*) with its subnets 3. Build our template network (*sky_net*) for internet access ## Our Network Address Spaces Before we dive into the build, let's get our heads around the network ranges we'll be using. We've got two main networks: ### mal_net (10.0.2.0/24) This is our isolated malware analysis playground, split into two subnets: - **mal_sub**: 10.0.2.0/25 (gives us addresses 10.0.2.0 - 10.0.2.127) - Where our analysis VMs will live - Completely isolated from the internet - **Guac_Subnet**: 10.0.2.128/27 (gives us addresses 10.0.2.128 - 10.0.2.159) - For our Apache Guacamole access - If you're using Azure Bastion instead, you'll need a /28 subnet named "AzureBastionSubnet" ### sky_net (10.10.10.0/24) This is our internet-connected network for building templates: - **Sky_Sub**: 10.10.10.0/25 (gives us addresses 10.10.10.0 - 10.10.10.127) - Where we'll set up and configure our VM templates - Has internet access through NAT gateway ## Setting Up User Defined Routes (UDR) Let's start with our traffic control system. Think of User Defined Routes as our network's traffic cops - they're going to make sure nothing sneaks out of our malware lab when we don't want it to. ### Creating Our Traffic Control Centre First up, let's build our route table. Head over to Azure Services, search for "Route tables" and click **Create**. You'll need: - **Resource Group**: _malware_rg_ (or whatever you're calling your lab group) - **Name**: _mal_UDR_ (keep it simple but meaningful) - **Region**: Pick the same region you'll use for everything else - **Gateway Route Propagation**: Switch this off (set to **No**) > [!tip] > Trust me on this one - stick to a naming system that makes sense. Future-you will be thankful when you're digging through logs at 2 AM trying to figure out why something's not working! ### Setting Up Our Network Black Hole Now for the cool part - we're going to create what I like to call our network black hole. Any traffic that tries to leave our malware lab will just... disappear. Here's how: 1. Jump into your new route table 2. Find **Routes** and hit **Add** 3. Here's the magic formula: |Setting|Value|What it Does| |---|---|---| |Route Name|Null_Net|Just a clear name for our black hole| |Destination Type|IP Addresses|Tells Azure we're working with IP ranges| |Destination IP/CIDR|0.0.0.0/0|The clever bit - catches ALL outbound traffic| |Next Hop Type|None|Makes that traffic vanish into thin air| That `0.0.0.0/0` route is the real star here - it's like a catchall net that grabs every single packet trying to escape. And by setting Next Hop Type to 'None', we're essentially telling Azure "Nope, that traffic stops right here!" ## Building Our Malware Analysis Network (mal_net) Alright, now we're getting to the good stuff - building our malware analysis network! This is where the real magic happens, so we want to get it just right. ### Setting Up the Base Network First things first, let's create our main virtual network. Pop into the Azure portal and hit up the Virtual Networks section: - **Name**: mal_net (keeping it simple) - **Resource Group**: Use the same one as your UDR (malware_rg in our case) - **Region**: Stick to the same region as your UDR - **Address Space**: Remember that 10.0.2.0/24 we talked about earlier ### The Security Bit (This is Important!) Here's where things get interesting - when you hit the Security tab, you'll see options for network encryption. Now, normally you'd want encryption everywhere, but we're actually going to leave it off here. Why? Because we're like digital detectives - we need to see exactly what that malware is doing on our network! It's like trying to catch someone pick-pocketing while they're wearing an invisibility cloak - not very effective, right? We want to see every sneaky move that malware makes, every connection it tries to establish, every bit of data it tries to send. Don't worry though - we've got other security measures to keep everything contained. ### Building Our Analysis Subnet (mal_sub) This is where we'll put our analysis VMs - think of it as our secure lab space: |Setting|Value|Why We Need It| |---|---|---| |Name|mal_sub|Our malware playground| |Address Range|10.0.2.0/25|Gives us plenty of room to work| |Private Subnet|Enabled|Super important for isolation| |NAT Gateway|None|We definitely don't want internet here| |NSG|mal_NSG|Our traffic filtering rules| |Route Table|mal_UDR|Remember our network black hole?| ### Creating Our Access Point (Guac_Subnet) Now, we need a way to actually get into our lab. This is where Apache Guacamole comes in: |Setting|Value|What It Does| |---|---|---| |Name|Guac_Subnet|Our secure entrance| |Address Range|10.0.2.128/27|Just enough space for our gateway| |Private Subnet|Disabled|Needs to talk to the outside world| |NAT Gateway|Cloudron_NAT|Our internet connection| > [!tip] >If you're going with Azure Bastion instead of Guacamole, you'll need to name this subnet "AzureBastionSubnet" and use a /28 range instead. But personally? I prefer Guacamole - it's more cost-effective and gives us more control. ### Setting Up Our Network Bouncer (NSG) Time to configure our Network Security Group - think of it as a really picky bouncer who checks everyone's ID twice: ## Who Gets In (Inbound Rules) |Priority|Name|Port|Source|Destination|Action|Why| |---|---|---|---|---|---|---| |100|AllowFromGuac|22,3389,5901|10.0.2.128/27|mal_sub|Allow|Let's us connect in| |65000|AllowVnetInBound|Any|VirtualNetwork|VirtualNetwork|Allow|Internal traffic| |65500|DenyAllInbound|Any|Any|Any|Deny|Block everything else| ## Who Gets Out (Outbound Rules) |Priority|Name|Port|Destination|Action|Why| |---|---|---|---|---|---| |65000|AllowVnetOutBound|Any|VirtualNetwork|Allow|Internal communication| |65500|DenyAllOutbound|Any|Any|Deny|No sneaking out!| > [!caution] >Those default ports (22, 3389, 5901)? They work, but consider changing them when you set up your VMs. It's like changing the locks on your doors - just makes it that bit harder for unwanted visitors. ## Creating Our Template Workshop (sky_net) Last but not least, we need a place to build and configure our analysis tools. Think of sky_net as your workshop - it's where you put together all your tools before moving them into the secure lab. ### Setting Up the Template Network Create another virtual network, but this one's a bit different: - **Name**: sky_net (yeah, I couldn't resist the name) - **Resource Group**: Fresh one for this (we're using sky_rg) - **Address Space**: 10.10.10.0/24 (notice how it's nowhere near our mal_net range?) - **Region**: Keep it with your other resources ### Securing the Workshop Now, you might be thinking "Hey, this network touches the internet - shouldn't we crank up all the security features?" Well, yes and no. Here's the thing: while we definitely want to be security-conscious, we need to be careful about which features we enable. You might be tempted to turn on network encryption, but here's a gotcha: enabling network encryption automatically turns on network acceleration for your VMs. Sounds great, right? The problem is, when we go to take snapshots of these VMs later, that accelerated networking feature will be baked in - and that can cause us headaches when we try to use those snapshots in our malware analysis environment. So for our sky_net, let's focus on security measures that won't impact our template creation: - Set up our NAT gateway (Sky_NAT) for controlled outbound traffic - Consider DDoS protection if you're worried about targeted attacks - Keep the network isolated from our mal_net environment ### The Template Subnet One simple subnet for our template VMs: |Setting|Value|What's It For| |---|---|---| |Name|Sky_Sub|Our template building space| |Address Range|10.10.10.0/25|Plenty of room for templates| |NAT Gateway|Sky_NAT|Our internet connection| |Private Subnet|Your call*|But change is coming...| *Here's a heads up: Azure's changing things soon - you'll need a NAT gateway for internet access regardless of private subnet settings. Might as well set it up now! > [!important] > Azure's making changes soon - you'll need a NAT gateway for internet access even without private subnetting. Better to set it up now! ## Making Sure Everything's Working Right, let's run through a quick sanity check before we move on. Think of this as your pre-flight checklist: ### Network Check First, pop into the Azure Portal and make sure: - You can see both your networks (mal_net and sky_net) - Your subnets are showing the right address ranges - Your NAT gateways are properly attached where they should be ### Security Check This is the important bit - double-check your security controls: - Is your null route properly attached to mal_sub? - Do your NSG rules look right? - Did we accidentally leave any backdoors open? (Better to catch them now!) ### Routing Check Here's a neat trick - once you've got VMs deployed, try this: - From a VM in mal_sub, try to ping google.com - If it fails, give yourself a high five - that's exactly what we want! - If it works... well, time to go back and check those User Defined Routes ## What's Next? Phew! We've built quite a setup here - you've got your secure malware analysis network completely isolated from the internet, a separate network for building your templates, and all the security controls to keep everything in check. Ready to start filling these networks with some VMs? Head over to [[Azure Malware Lab VM Templates]] where we'll start building our analysis machines! > [!tip] > Keep those subnet ranges handy - you'll need them when we set up the VMs. I usually keep a little cheat sheet with my CIDR ranges and NSG rules. Trust me, it saves time later! And remember - if you're not keen on clicking through all these steps manually, check out the automation code we talked about at the start. It'll handle all of this for you, though it's still good to know what's happening under the hood. Happy building! 🛠️