Recommended Ways to Setup Security Labs? (Pentesting Lab, Malware Lab)

[default8080]

So I’m on the fence, I’ve been a Qubes user as my daily driver for a couple of years now, but been using it as a standard laptop, never diving too much into building labs out of it, I explore tor, compartmentalize my life a bit, social media, work emails etc. But I found a few things, such as CTF(Hack the Box mainly, though I’m moving to Vulnhub for this) and Malware Analysis(Ghidra) a bit of a pita in Qubes due to the networking as well as the isolation done by Qubes.

Picked up a much more powerful laptop, Legion 5, specs are as follows:

-i7-10750H
-32GB Ram DDR4
-512GB NVME
-1TB HDD
-GTX1660ti

I’d like to have 2 lab setups within it

CTF, where I can install either a KaliVM or a Custom DebianVM, and be able to connect it and talk to another VulnerableVM.

      NetVM
           |
      Firewall
   /                \

Kali VulnVM(OVA Files from VulnHub)

Setting Up a Pentesting Environment based on Qubes OS – Step by Step

This would be isolated so they can only talk to each other. This seems feasable enough, just need to change out the firewall rules when changing out the VulnVM(maybe?)

Another would be a Malware Lab,

With a similar build

      NetVM
           |
      Firewall
   /                \

Ghidra MalwareVM (Win7/WinXP)

I’ve read a few articles, that QubesOS isn’t the greatest OS for this sort of instance, and that it’s better to use just a simple setup Debian/Ubuntu/Mint for this whole setup. Which is what I’m currently running, but I am just curious what the Qubes community thinks and if there’s any good setups in going about it beyond the one I linked above.

EDIT: Formatting got a bit weird with my layouts, but you can see the layout in the link I provided. Apologies.

[Plexus]

@default8080

I’ve read a few articles, that QubesOS isn’t the greatest OS for this sort of instance

ii dont see why… like the linked article shows you make a virtual LAN which uses a pentest firewall instance that you can link two VMs together on. Then if you have a specific ISO you want to use as install medium look into a HVM

[unman]

If you want these to be isolated, why bother with the NetVM in the first
instance?
Qubes is a great OS for this sort of work - it’s simple to set up a
classic Internet-inna-box, cloning and spinning up qubes as you will.
You can monitor all traffic, create target qubes if you see calls to a
control center, pause, replay events, and so on.
I don’t know what articles you’ve been reading but they are the wrong
ones.

[gonzalo-bulnes]

Hi @default8080! I edited the title of the topic to make it more specific, and easier to find for people with the same questions. Please feel free to change it again if you think I didn’t get it quite right!

[gonzalo-bulnes]

You may have already read this, but just in case, note that there is a section of the Firewall docs that explains how to enable networking between two qubes:

Firewall

If useful, you can find a concrete example of that setup in action in the SecureDrop docs:

https://docs.securedrop.org/en/stable/development/qubes_staging.html#inter-vm-networking

[gonzalo-bulnes]

On the topic of working with Kali, please note that a template is available for both R4.0 and R4.1:

Kali template for 4.0 updated

I’ve uploaded an updated Kali template for 4.0.You can pull this from https://qubes.3isec.org/Templates As always, signed by my QubesOS key - you’re trusting me to do the right thing with this build. The template works fine except that Kali enforces python-is-python2 when Qubes wants python-is-python3. There’s a helpful warning about this at the Kali shell and instructions on how to change it. The only effect seems to be that qvm-copy IN throws an error message, although files are transf…

Kali template available

Update 2024 Hi, you are probably aware that we do have template build for Kali in R4.0 and R4.1 but we have built it for R4.1 only currently. I need to add generic documentation on it but currently I’m lacking of time. This is a message for anyone who wants to test it and to give a feedback. First, ensure to have qubes-core-admin-linux-4.1.8. We had to increase default max bytes size to download the template because the template size is bigger than the others (standard kali with lot of pack…

[default8080]

Thanks for the update to the topic, I do appreciate it. I saw that 4.1 had a Kali Template out, however I did not see one for 4.0 so I do appreciate this. I’ll give this a try when I get back on my local machine over the weekend.

[default8080]

Malware typically tends to want to talk to the internet. As well as updating Kali or doing custom VM builds within the Vulnerable side. I can always disconnect them from the network by removing the firewall from using the netvm easily if I want more forced isolation.

Again not dabbled too much into this, I’ve had a lab machine built on Debian for the longest time and it’s just worked for my needs, but I’d like to rid myself of having two machines.

[unman]

Malware typically tends to want to talk to the internet. As well as updating Kali or doing custom VM builds within the Vulnerable side. I can always disconnect them from the network by removing the firewall from using the netvm easily if I want more forced isolation.

Yes, but you dont need to let it.
The principle of internet-inna-box is that it can be completely isolated, and
you can provide whatever services are required.
Since you monitor all traffic at sys-firewall you can spin up upstream
servers or honeypots as required. (Have these templates and qubes
prepared beforehand).

[deeplow]

For doing wifi pentesting you should have another sys-net with a dedicated wifi card. This talk has some hints on how to do that:

Qubes for Organizational Security Auditing (talk notes)

These are text notes that I made from a presentation Harlo Holmes from Freedom of The Press Foundation (FPF) gave at the HOPE 2020 conference: Qubes OS for Organizational Security Auditing. The talk mainly about explaining how Qubes is ideal for this use-case and showing off the tooling Harlo uses to do security audits on Qubes as part of the Digital Security Team at FPF. These notes include most of Harlo’s remarks and they’ve been curated to have links to the Qubes documentation and well as …

[adw]

@default8080

So I’m on the fence, I’ve been a Qubes user as my daily driver for a couple of years now, but been using it as a standard laptop, never diving too much into building labs out of it, I explore tor, compartmentalize my life a bit, social media, work emails etc. But I found a few things, such as CTF(Hack the Box mainly, though I’m moving to Vulnhub for this) and Malware Analysis(Ghidra) a bit of a pita in Qubes due to the networking as well as the isolation done by Qubes.

@default8080

I’ve read a few articles, that QubesOS isn’t the greatest OS for this sort of instance, and that it’s better to use just a simple setup Debian/Ubuntu/Mint for this whole setup. Which is what I’m currently running, but I am just curious what the Qubes community thinks and if there’s any good setups in going about it beyond the one I linked above.

Since you asked what the Qubes community thinks, I’ll offer my opinion: You’re trying to use a tool for a different purpose than the one for which it was designed, so don’t be surprised if it’s difficult and you run into problems. Qubes OS is designed to be defensive. It’s designed to protect a single general purpose desktop computer user through strong compartmentalization. It’s not designed to be a pen-testing or malware lab. Can you do it anyway? Sure, just don’t blame the hammer for not being a screwdriver.

On the other hand, if @unman says that Qubes is great for this sort of work, then take his word over mine. He knows much more about this than I do.

[default8080]

I wanted the Qubes Communities opinion so I do appreciate you taking the time to respond. Thank you very much. I like Qubes, I use it as my daily driver. However I have a debian lab that I also mentioned above.

So my current layout of hardware 2x Qubes Machines(Daily Drivers) and 2x Lab Machines(Desktop and a Laptop) I did HTB for awhile but have just moved to VulnHub due to some issues with HTB (Mostly restarts of machines causing issues) which was my biggest concern as it’s a fun hobby.

So I’m just looking to cut those machines down to the 2. I’m not looking to pentest a company network, or to do anything interacting outside the lab within Qubes. I understand it’s not designed for that purpose. But building an internal lab I do feel Qubes is adequate for. Again, I’ve never used Qubes beyond a daily use and some minor tinkering(ie hardening Debian, with Kickstart and a few emulators and developer aspects) so just wanted some more user input. Again thank you very much for taking the time to reply.

[peter_griffin]

Any luck on your try?
I want exactly the same for vulnhub machines.

[unman]

I’m not sure what “exactly the same” means.
You can create a simple lab very easily - all you have to do is enable
networking between qubes in the netvm to which they are attached.
This is covered in detail in the docs

If you want to create a full internet-inna-box, again this is relatively
simple. The netvm will not be connected to upstream netvm, so the whole
system will be offline.
Create qubes to provide the network services that you need -
DNS, web server, sshd, and so forth. (You can attach these to a netvm,
upstream from the netvm to which your qubes are attached, but in this
case you will have to adjust routing and remove NAT: it’s simpler if
you use a single master netvm.)
Enable networking between all these qubes.
You will want to run a packet analyser on the (or both) netvm.

If you have all the service qubes ready, you can spin them up as needed,
and replay traffic to aid analysis.
Almost all the work will be in adjusting the firewall on the netvm to
route (and NAT) traffic as needed. That’s quite straight forward.

[ckN6QwSZ]

Are we talking about a setup like this?

pentester -----------------------|
                                 |
empire ------------------------| |
                              sys-bridge --- sys-firewall --- sys-net --- uplink
vuln_tux1 --------------------|||||      \ or
                               ||||       --- sys-whonix --- sys-firewall --- asf
vuln_tux2 ---------------------||||       \ or
                                |||        --- (none)
vuln_win1 ----------------------|||
                                 ||
vuln_win2 -----------------------||
                                  |
domain_controller ----------------|

You need to change /rw/config/qubes-firewall-user-script in sys-bridge to allow forwarding traffic from anywhere to anywhere:

#!/bin/sh

# This script is called at AppVM boot if this AppVM has the qubes-firewall
# service enabled. It is executed after the empty chains for the Qubes firewall
# are created, but before rules for attached qubes are processed and inserted.
#
# It is a good place for custom rules and actions that should occur when the
# firewall service is started.
# 
# Executable scripts located in /rw/config/qubes-firewall.d are executed
# immediately before this qubes-firewall-user-script.

# allow connected qubes to talk to each other
iptables -I FORWARD -j ACCEPT

pentester and empire i.e. need to have their firewalls switched off or at least a

sudo iptables -I INPUT -j ACCEPT

to allow incoming traffic since you want to serve stuff with

sudo python3 -m http.server 80 &

or catch an incoming shell with

sudo rlwrap nc -lvnp 443

You can cut off the vulnerable machines from the internet by disconnecting sys-bridge from it’s uplink or setting up specific and cumbersome iptables rules. sys-bridge needs to have provides_network set to True.

[ckN6QwSZ]

Meanwhile my /rw/config/qubes-firewall-user-script in sys-bridge looks like this:

#!/bin/sh

# This script is called at AppVM boot if this AppVM has the qubes-firewall
# service enabled. It is executed after the empty chains for the Qubes firewall
# are created, but before rules for attached qubes are processed and inserted.
#
# It is a good place for custom rules and actions that should occur when the
# firewall service is started.
#
# Executable scripts located in /rw/config/qubes-firewall.d are executed
# immediately before this qubes-firewall-user-script.

# allow redirects to localhost
sysctl -w net.ipv4.conf.all.route_localnet=1

# nuke all iptables but NAT table
/usr/sbin/iptables -P INPUT ACCEPT
/usr/sbin/iptables -P FORWARD ACCEPT
/usr/sbin/iptables -P OUTPUT ACCEPT
/usr/sbin/iptables -F
/usr/sbin/iptables -X
/usr/sbin/iptables -F -t mangle
/usr/sbin/iptables -X -t mangle

# setup iptables to redirect to DNS requests to localhost
/usr/sbin/iptables -t nat -F PR-QBS
/usr/sbin/iptables -t nat -A PR-QBS -d 10.139.1.1/32 -p udp -m udp --dport 53 -j DNAT --to-destination 127.0.0.1
/usr/sbin/iptables -t nat -A PR-QBS -d 10.139.1.1/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination 127.0.0.1
/usr/sbin/iptables -t nat -A PR-QBS -d 10.139.1.2/32 -p udp -m udp --dport 53 -j DNAT --to-destination 127.0.0.1
/usr/sbin/iptables -t nat -A PR-QBS -d 10.139.1.2/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination 127.0.0.1

# setup iptables to allow network scans
/usr/sbin/iptables -t nat -D POSTROUTING 3
/usr/sbin/iptables -t nat -A POSTROUTING ! -d 10.137.0.0/24 -j MASQUERADE

sys-bridge is based on a kali template and I’m running a dnscrypt-proxy.service in there to enable dns-cloaking for my vulnerable machines.

[WeuXgnj]

Hint how to set up a dhcp network inside Vulnhub virtual machines without having root access beforehand I’ve been thinking about this for days now but can’t come up with anything, the only thing I’ve found is this thread

[qubes-users] Custom LAN Network with dhcpd

Hello, I am trying to implement an internal Qubes LAN with HVMs that receive dhcp from a netvm using dhcpd. A classical network layout sort of speak. Reading Xen Networking makes it look possible but Qubes auto configuring the VM networking is being a bit troublesome for what I am trying to setup. Note that the entire network will be on Qubes only with no internet access. The reason I am trying to set this up is I have some HVMs that are not getting an ip through dhcp and I cannot access them …

[ckN6QwSZ]

Not sure what you want or need to achieve, but if you use Vulnhub VMs as HVMs on Qubes and these machines expect to receive their ip settings and stuff from uplink, you might want to install a dhcp server on the direct uplink machine (in my case sys-bridge). My suggested readings on that topic:

https://wiki.archlinux.org/title/Dnsmasq
https://wiki.archlinux.org/title/Dhcpd

Don’t forget to disarm your iptables.

[dotivarup.hofamucum]

hi I have a kali linux based appwm and a vulnhub hvm virtual machine I tried to understand in the wiki but didn’t understand how to apply this in the context of qubes and sys-bridge could you write the commands to be entered in sys-bridge ? thanks

[ckN6QwSZ]

@dotivarup.hofamucum

could you write the commands to be entered in sys-bridge

Just scroll up.

@dotivarup.hofamucum

I have a kali linux based appwm and a vulnhub hvm virtual machine

Sure you have. And since you engage in this kind of activity you won’t need help with iptables or dnsmasq, am I right?

This forum has lately been populated by trolls and sockpuppets which create burner accounts ask or even demand help. That is a highly unsocial behaviour threatening the motivation of all those user honestly trying to help other users.