The final step for the internal network is enabling access to the DMZ network from external devices by changing the Firewall and DNS configuration. This involves configuring port forwarding to route external traffic to the appropriate internal devices. I also need to change the DNS configuration to route the traffic for the domain correctly. First step, port forwarding in pfsense.
To route external traffic to internal devices, we will configure port forwarding. This routes external traffic destined to certain ports, like port 443 for HTTPS, to the appropriate internal server in the DMZ. Within pfsense, we go to NAT settings, and port forward. The image below shows an example configuration to route inbound HTTP traffic on the WAN interface to my DMZ host 10.10.1.12.
For my lab, I also added rules for DNS, SMTP, and HTTPS.
Due to my lab’s configuration using all private IP addresses and having a private IP on the WAN interface for the lab, I also had to remove the reserved network block.
To test the configuration, I used my external Kali machine to run an Nmap scan of port 80 and 443 of my firewall.
Configure DNS for External Access
The next step is to configure the simulated external DNS to route traffic to my lab network from the external network. I added an A record to the external Pihole.
I also need an A record for the email server.
Next, I need to create an MX record. For dnsmasq, this requires a custom configuration file.
# touch /etc/dnsmasq.d/99-mail.conf
# pihole restartdns
To check that the MX record is working, I use nslookup on the external Kali machine.
Now that the configuration is complete, I run a few Nmap scans to check that the ports are forwarded to the correct internal devices, and that I can scan by domain name.
With that, my Firewall and DNS configuration is complete and my lab is accessible from the simulated external network devices.
I could practice and work on hacking the machines I already built, but another good addition to my lab is vulnerable machines. A good source of these is VulnHub. In this post I will cover how to add a VulnHub machine to Proxmox.
The first step in adding the machine is to download it from vulnhub onto the host and extract it. For this example, I am using the machine Earth. To accomplish this, I entered the three commands below.
# mkdir vulnhub && cd vulnhub
# wget -O Earth.ova https://download.vulnhub.com/theplanets/Earth.ova
# tar xvf Earth.ova
Once downloaded you should have 3 files in the vulnhub directory.
Adding the VulnHub Machine to Proxmox
Now we need to create the VM in Proxmox to tie to the disk we downloaded. First we create the machine, and under operating system, select “Do not use any media.”
For the other options, I configured:
System: default
Disks: default
CPU: 1 socket / 1 core
Memory: 1024MB
Network: DMZnet / MTU: 1450
Once created, but before booting, the next step is to remove the hard disk. You do that by first detaching the existing disk, and then remove the unused disk.
Now you import the disk, using the command below. Replace “115” with the number corresponding to your virtual machine in Proxmox, and the vmdk file with the correct file corresponding to the machine you downloaded.
Once the disk imports, you need to go back to the GUI and change the disk type to SATA in the Proxmox interface.
After changing, you should see the hard drive in sata0.
The last step is to change the boot order to boot to the hard drive first, and then start the VM. After starting you should get the login screen.
The whole process is that simple. Now you can import new VulnHub machines anytime to try them out in your new Proxmox lab. Now that we have machines ready, its time to configure the DNS and firewall for external access.
The remaining server left to create in my lab is a Security Onion server. Security Onion is an out of the box blend of multiple open source tools that feed a central alert dashboard. I actually created a whole separate Pluralsight course called Security Onion Concepts and Basic Functionality if you are interested. The course covers the fundamentals, installation, and basic operation of the tool. This post is focused on capturing network traffic using my lab’s Security Onion server. To enable that, I configure a SPAN port for Security Onion in Proxmox on my pfsense virtual machine.
My Proxmox lab has multiple hosts which significantly complicate this operation. The Security Onion server and pfsense firewall are located on separate hosts which means I have to pass the network traffic between hosts. I enabled this capability previously with software defined networking. There was a problem though, this does not support SPAN ports effectively. The best way I found to enable a SPAN port in Proxmox is to configure a physical NIC passthrough on the host. This allows me to assign a physical port on the host directly to a virtual machine which successfully passes all traffic.
The first step I took is to enable IOMMU in the /etc/default/grub file by adding the line below as seen in the image.
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on"
Enable IOMMU in Proxmox
Then I ran update-grub and reboot the machine. To check that the setting is correct after reboot, I ran the command below and looked for “IOMMU enabled”.
# dmesg | grep -e DMAR -e IOMMU
Example output of dmesg command
Next I added the required modules to enable physical NIC passthrough by editing the /etc/modules file and adding the modules in the image below.
Added required modules for physical NIC passthrough
Just to be safe, I rebooted the machine at this point and then checked that I could add a PCI device in the hardware setting in Proxmox.
Configure a SPAN port for Security Onion in Proxmox
Now that I can map a physical NIC to one of my virtual machines, I added one of the host ethernet adapters to the hardware on my pfsense virtual machine.
To make this work correctly on my old servers, I also had to enable unsafe interrupts with this command:
Now when I access the pfsense interface menu from the command line, the new interface is available as bce0.
New interface available in pfsense
I assigned the interface the name OPT2 and then in the web configurator I enabled it and gave it a description of SPANport.
Enabling the interface in web configurator
To configure a SPAN port in pfsense, you actually create a bridge within the interface menu. I went to Interfaces > Interface Assignments > Bridges and made a new one to create the SPAN port. I selected the LAN interface, added a description and then selected the SPANPORT interface under Span Port in the advanced configuration.
Adding a SPAN port in pfsense
To complete my lab setup I did the same thing for the DMZ network, leaving me with two bridges.
SPAN ports in pfsense
The last step to verify operation is to test the SPAN port. To test, I used the packet capture tool in pfsense and set the interface to SPANPORT. I also enabled promiscuous mode to capture all data seen by the adapter.
Once I ran it, I could see multiple packets showing it was working as intended.
On the Security Onion server I will add another physical adapter, just like the pfsense machine. Then I will connect the interfaces directly with an ethernet cable.
Skipping ahead a bit to show it works
The output in Security Onion is not something I cover in the lab build, but it worked as configured in this post. Here is a tcpdump on my Security Onion Server and an overview of alerts.
I covered the how to install in a Pluralsight course, and you could also follow their documentation to build it. Security Onion is really one of the last steps to creating the basic structure of this lab other than adding the Kali machine and enabling remote access, but I also cover in the next post how to add VulnHub machines to the DMZ.
In this post I will go over the creation of a Windows client machine with Windows 11 as an OS. I also added the PC to the Globomantics domain. Once I add the machine to the domain, I installed a Thunderbird email client and configured it to connect to the iRedMail server. I also followed the same procedure on a Windows 10 machine, which is very similar so I will focus on the Windows 11 PC for this post.
The first step to creating a client machine in my Proxmox lab is to clone the template machines. I used the full clone mode in Proxmox. After creating the machine I started it up and chose the correct region, keyboard layout, and accepted the license agreement. For sign in options I selected domain join instead.
Example full clone menu
I configured the Windows 11 PC for my user Jane Johnson created in the previous post. Once it loaded, I went to settings to change the computer name and add it to the Globomantics domain.
Settings menu in Windows 11 to change computer name and add to domainChanging computer name and adding to domain
After adding to the domain I restarted the new PC. Then I could login as Jane Johnson to the CORP domain.
Logging in to the CORP domain on Windows 11 PC
Configuring the Thunderbird Email Client
Once logged in, I can access the Globomantics share created previously. I downloaded the Thunderbird client installer on my Windows Admin PC and uploaded it to the share. On each client I just run the installer from the share.
Uploading the Thunderbird email client to GloboshareRunning the email client from the Globoshare
After Thunderbird finished installing I configured it on each machine to map to the email accounts created in the last post. Part of that involved configuring the connection manually to iRedMail. An example of the configuration I used is in the image below.
Thunderbird email and password entryManual configuration of IMAP settings in Thunderbird
Once configured, the client will connect to the server. My email server is using a self-signed certificate, so I had to confirm a security exemption.
Confirming security exemption for self-signed certificate
After that Thunderbird loaded the inbox so I could send a test email between the user accounts to confirm my email server works.
Inbox on first login to ThunderbirdTest email between John Smith and Jane Johnson
Again, because of the self-signed certificate I had to confirm another security exemption.
Successful test email received
The test email succeeded, finishing up my internal configuration and user services! The domain is ready for internal use at least and all services are working. The next steps are finishing up my clients, installing Security Onion, and configuring the firewall to enable external traffic into the DMZ servers.
Now that I have a domain and working Email server, its time to create some users for the network. I could create these individually using the Active Directory Users and Computers interface in RSAT, but instead I am going to use PowerShell to script the process. User creation with PowerShell is an easy process and pretty straightforward. I will make a CSV file with the account information, and then use PowerShell to create the accounts quickly.
Creating a user with PowerShell is done using the Active Directory module for PowerShell to import the needed command. From there, it’s as easy as using the “New-ADUser” command to add a user. I am going to create a script that first reads a CSV file containing the user information, and assigns each piece to a variable. Then the script will check if the user already exists, and if it doesn’t create it using “New-ADUser”.
I also made the CSV file “Users.csv” and stored it on the Windows 10 Admin PC desktop where I wrote this script. The CSV has these headings matching the script’s variables: SAMAccount, password, FirstName, LastName, email, title, and department.
Example CSV file used for my domain
After creating both of these files, making the user accounts is as easy as running the script. After that the user accounts will show up in Active Directory.
New user accounts populate in Active Directory after running the script.
Using the iRedMail server admin page, making mailboxes for the new users is also a very easy and straightforward process. From the admin page, add a mail user and then fill out their required information.
Example creation of the mail user account for BobAll user mailboxes for the Globomantics domain
Once all the users are added, you can login to any of the domain workstations and then use either the webmail interface or an email application to check their email. In my next post I am going to create the client machines and use Thunderbird to connect to the iRedMail server.
My next step in adding Email services to my lab domain is to configure DNS for Email. This involves adding the required MX, CNAME, and A records on the Pi-Hole so external email traffic can route correctly to the Globomantics domain.
To enable Email services, I first need to add an A record for my new server. I used the Pi-Hole admin panel to create this record mapping the name “mx” to 10.10.1.5. After creation the new record is visible in the admin panel.
Pi-Hole admin panel after creating the new A record
Next, I am going to add a CNAME to my DNS configuration that creates an alias for mx.globomantics.local. The alias I am assigning is mail.globomantics.local. I am using the Pi-Hole admin panel again for this change.
Adding a CNAME record to Pi-Hole
Last I need to add an MX record which directs mail to my new Email server for the Globmantics domain. In the Pi-Hole configuration panel there is no option to add an MX record, so I need to add a custom file to dnsmasq. To create the file, I use the command below and then edit using Nano.
# touch /etc/dnsmasq.d/99-mail.conf
Within the file, I add this line to create the MX record mapping incoming mail destined to the globomantics.local domain to my MX host.
Once created, the last step in DNS configuration is testing that the records resolve correctly. I used nslookup on the Windows 10 Admin PC. Using the commands below queries MX records tied to the globomantics.local domain.
C:\Users\BAdmin>nslookup
> set q=mx
> globomantics.local
Output from nslookup shows that the domain MX record resolves correctly
A Quick Firewall Change
To enable the server to send outbound email I need to open a few firewall ports on the DMZ. Reading through the iRedMail configuration, the minimum ports I need open are 25 (SMTP), 587 (Submission), and 143 (IMAP). I added those in the same method used previously.
Added ports 25, 587, and 143 to DMZ interface on pfsense
Testing Login to Postmaster Account
Now that DNS and firewall configuration is done, I can test logging in to the Postmaster account and check my email. I am going to login to the Roundcube webmail by navigating to the alias address: mail.globomantics.local and then logging in as Postmaster.
Roundcube login page loaded after navigating to MX aliasSuccessful login to Postmaster account and inbox view in Roundcube
That’s all there is to it! My server is ready for user Email. That is the topic for my next post where I will create users in bulk, and create their mailboxes.
The next step to creating my lab is enabling email services. I decided to create my own email server by installing the open source email server iRedMail on an Ubuntu LXC. I chose iRedMail because of its simplicity to install, configure, and operate. This allows me to add email capabilities to the domain without purchasing software and without adding too much complexity to the build. I chose an LXC to minimize resource use.
Next, I downloaded iRedMail, renamed the file, uncompressed it, and ran the shell installer with these commands.
# wget https://github.com/iredmail/iRedMail/archive/tags/1.6.2.tar.gz
# mv 1.6.2.tar.gz iRedMail-1.6.2.tar.gz
# tar zxf iRedMail-1.6.2.tar.gz
# cd ./iRedMail-1.6.2.tar.gz
# bash iRedMail.sh
After running these commands, the installer will start.
iRedMail installer screen
When installing iRedMail I selected the following options:
Mailbox store: /var/vmail
Web server: Nginx
Backend: Postgres
Mail domain name: globomantics.local
Optional components:
Roundcube
netdata
iRedAdmin
Fail2ban
Then I just had to confirm the settings to install it.
Confirming options and installing
After the install finishes, I got a screen with the admin web page addresses and postmaster login information. I chose the next recommended option of reading the /root/iRedMail-x.y.z/iRedMail.tips file for more information. After that I just rebooted the server to enable email. The next step is to configure DNS for email services on my domain and login to test the email. That is the topic for my next post.
The next step to getting my lab ready is to make some updates to my servers and computers. The fastest way to update all of my machines is to update the group policy objects (GPOs). After I update the GPO policies I am going to check the DNS configuration an make sure my domain is ready for the remaining workstations.
I am going to use group policy management console (GPMC) to update GPO policies for my domain. The first policy change I need to make is to finish enabling WSUS on my domain by mapping all of the workstations and servers to WSUS for updates. To make this change I am going to make a new GPO for the domain called WSUS settings in GPMC.
Create a new GPO in this domain and link to domainEditing the new GPO
Now I go to Computer configuration > Policies > Administrative Templates > Windows components > Windows Update > Specify intranet Microsoft update service location.
Selecting the policy to update
First, I map the domain servers and workstations to my WSUS server, I need to enter the address for my WSUS server. Then I enable the policy so it takes effect.
Adding the web address for my internal WSUS
Next, I need to configure the schedule for automatic updates. This sets all the machines to download updates from the internal WSUS and selects the desired behavior. I set the Configure Automatic Updates setting to make this change.
Setting automatic updates in GPO
Update Policy for Add/Remove Features
I need to make one more change related to WSUS. Right now WSUS is only used for software updates, but I also need to map workstations and servers to WSUS for adding and removing features. That is in Computer configuration > Policies > Administrative Templates > System > Specify settings for optional component installation and component repair.
Mapping add/remove features to internal WSUS
That’s it for the WSUS GPO. Now my workstations will map to the internal server for updates and features. Next I need to check DNS settings. I am going to use the DNS manager in RSAT for this.
DNS Manager for my domain
First, I am going to set the server to only listen on the IPv4 interface for DNS queries. Then I am going to check the DNS forwarders and make sure it is using the Pi-hole in the DMZ.
Selecting the IPv4 interface for DNS listenersChecking DNS Forwarders
My DNS is configured and working as expected. Now that my domain is ready for workstations. Before I add workstations though, I am going to add one more service: Email.
In this step I am creating a new server using the Windows Server 2019 template created earlier in this process. The first role is providing my network with shared storage by creating a file server, then adding Windows Server Update Services (WSUS). I can install the basic services with PowerShell and use the remote administration tools on my Admin PC to manage WSUS.
The first step is to clone the Windows Server template into a new VM that I am going to call FileSrv. After cloning, I just start the machine and change the Administrator password.
New server started, changing the admin password
Joining the domain in Server Core is easily done using SConfig. I changed the name on the server to FileSrv and joined the CORP domain in my lab. I also checked the network settings to make sure everything is correct.
Rename the server in SConfigChecking IP address in SConfigJoining my lab network domain from SConfig
Once the server reboots, I logged in with the Bob Admin credentials and prepared to install the File Server role. Installing the file server role is done through Powershell using the command below.
Now the File share is available on the entire domain using \\Globoshare\ to access.
Installing Windows Server Update Services (WSUS)
Installing WSUS on Server Core is a little more complicated than configuring a shared file. For this role, I will need to use a combination of PowerShell commands and the admin tools on my Win10Admin PC. The first step is installing the Windows Feature in PowerShell.
Next I need to enable remote administration of this server. That involves adding Web Management Service, along with ensuring it starts up automatically on reboot. I also need to make a registry change to enable remote management.
From here the remaining steps are done in the remote admin tool. I followed the prompts and selected Microsoft Update as my upstream provider. This step took a long time for the initial sync.
Starting screen after configuring remote managementConnect to Upstream server
After that I selected the language and products that apply to my domain, along with the classifications. Then I configured the Synchronization schedule.
Synchronize Updates Manually in WSUS
After finishing I chose to begin the initial synchronization.
Begin initial synchronization in WSUS
With that, my new server is ready to go. I installed file services, created a network share, and configured WSUS so my machines have a single update server where I can approve each update. Next I have some group policy changes and other domain changes to make from RSAT on the Windows 10 Admin PC.
The next step in getting my lab up and running is to create a Windows 10 admin machine in Proxmox. As with most of my VMs, I am going to create a Windows 10 template first so I can quickly set up additional workstations using cloning. I created a new VM with the following settings:
Name: Win10Template
CD/DVD image: Win10Eval.iso
Disk: 60GB on local-lvm
CPU: 1 socket / 4 cores
Memory: 4096MB
Network: LANnet / 1450 MTU
Once it loads I started the standard Windows 10 install process.
Windows 10 Install Screen
I selected the following options during install:
Custom: Install Windows only (advanced)
Install Windows on Drive 0
I did not create any partitions
After reboot Windows enters OOBE, so I chose:
Selected region
Selected keyboard layout
Use domain join instead of a Microsoft account
Enter the information for Bob Admin created in the previous step
Answer security questions
Turn off all location and data sharing
No Coratana
Finally I got to the Windows Desktop and could start the remaining steps.
Windows 10 desktop after initial login
The next step was to run a Windows update and restart after updating.
Creating the Windows 10 template
Once I had all the desired configuration and updates covered, the final step was to remove all the specific information like user accounts. Just like with the Windows Server template, I can use the Windows Sysprep tool for this portion.
After the Sysprep finishes, Windows 10 will shutdown and the machine is ready. To create a Windows 10 template all I need to do is right click the machine and select the option to convert to template.
That’s it! Overall the process is a little faster than making a server template. Now it’s ready for cloning into the Windows Admin workstation.
Creating the Admin PC
Once I cloned the template, it goes through the same out of box experience as before. I selected the same options until I got to the main desktop.
My new Windows 10 Admin PC
Now I need to rename the machine and join it to the Globomantics domain I created in the last post. Renaming the PC is found in the system settings.
Workstation settings for Windows 10 Admin PCRenaming the PC
Now it’s ready to join to the domain. For that I use Advanced System Settings and select the change option to change to domain from workgroup.
Advanced System Properties
After adding to the domain and rebooting the machine, I could login to the CORP domain using the credentials for Bob Admin.
Login to the CORP domain after reboot
The last step was installing the Remote Server Admin Tools (RSAT). This is a simple download and install, but it is a Windows update pack and not an executable. After install the tools are available in the start menu and the Windows 10 Admin PC is ready for our next phase: creating a File Server and WSUS Server.
