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

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)

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.

1 Like

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

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. :slight_smile:

2 Likes

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! :slight_smile:

2 Likes

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:

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

2 Likes

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

1 Like

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.

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.

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).

1 Like

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:

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.

2 Likes

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.

1 Like

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

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.