Setting Up A Pentesting Lab

[TT1TTONE]

Hi!

My interest for pen-testing or computer security in general keeps growing for each day. For a long time I've thought about setting up a computer with 2 guest OSes that would be in their own network if possible, - one of them being the attacker and the other being the victim. It has been kinda hard to realize this mostly because of the lack of a computer with decent hardware that is needed for virtualization, and because I don't have the money to spend on a new computer at the moment.

Now, I've a pretty good main computer that I use for "normal" things (banking, storing personal images/videos, playing games, etc) and since my desire to start experimenting with pen-testing has become so big, I've actually started thinking about using that computer for hosting the earlier mentioned VMs.

Is this stupid, as I've personal stuff on that computer that I absolutely wouldn't want to lose or contaminate with something nasty?

To make things even worse, the computer mentioned is full-disk encrypted (Truecrypt), and needs to stay so. As Truecrypt's official forum doesn't allow members registered with certain e-mails to post or start any threads, I've failed to direct this question to their community. But I doubt that you wouldn't know more than them so I ask you guys instead;

Is there any risk that the safety that is maintained by the encryption gets compromised as it runs VMs that maybe leads to data leaks or so?

The pen-testing would be conducted using Back-Track (mainly NMAP, Metasploit and SET) on the attacker-side, and Windows XP SP2/SP3 on the victim-side.

Thanks in advance,

TT1TTONE

[TT1TTONE]

I am not sure what kind of financial state you are in right now but you could definitely find some older computers that have been used for sale dirt cheap, or even donations from friends and family etc. then you wouldn't need to subject your machine to any possible threat.

I do have some older(!) computers but I'm talking about 10 years old ones. I might buy a second hand laptop with a decent processor and double its RAM. I do think about that. Would a laptop with Intel Core 2 Duo @ 2,0GHz and 4GB of RAM be sufficient?

[telot]

I've found that offering to do tech support help for friends family will automatically make you top of the list for when they wish to get rid of any computers. The VM thing is great, if you've got the ram to rock it - but its totally unnecessary and not really optimal for a pentest lab imho. To *truly* simulate a pentesting enviroment, you want the attacker on separate hardware. Of course its not totally necessary, but it makes life a lot easier to be running exploits on "bare metal" (did I use that phrase right? lol). In your situation, I would put Backtrack on a live disk, run it on your main machine and load XP on your crap machine as your victim. Problem solved!

telot

[TT1TTONE]

If your looking to set up a lab I would reccomend using desktops, as they will be cheaper and you really don't need the mobility of the laptop. Sufficient for what purpose? Using it as your primary or using it as a victim?

Sufficient for hosting the 2 virtual machines.

[Mr-Protocol]

I would vote for Virtual Machines.

• You can have the entire test lab on a laptop
  
• You can snapshot your test machines so if you totally screw it up; restore from the snapshot
  
• Can segregate the network off of any physical LAN
  
• Ability to switch to any machine's desktop quickly to see if things worked.
  

[Infiltrator]

I would definitely use virtual machines, making sure they are totally isolated from your production hosts (we don't want to exploit the wrong machine) or main network.

On the main machine hosting the VMs, ensure it has plenty of RAM and a faster CPU, as well as if you can afford, install an SSD for increased I/O, and to have a good performance when running several VMs.

[telot]

Don't listen to these fools ;) VM's are overrated!

I'm just kidding of course, but I don't share their opinion about VM's being the best for pentesting. Mr. Protocol does list out a number of pros, but there are cons as well, such as:

Its not a real-world environment. In the real world, your targets aren't sharing your computer hardware.

You're not running direct on hardware. Hacking hardware devices (e.g. usb to serial cables) is a pain, and in some cases impossible.

Its not as cool looking. Having a full blown computer lab setup in your basement screams "this guys a freakin' badass". lol

Having a multiple machine hack lab is modular. You can move from one project to the next more easily when you have multiple hardware setups configured to do multiple things.

As you can see, I am very hardware focused, which is why I feel the way I do about having multiple machines. Now I'm sure Mr. Protocol and Infiltrator can come up with a thousand more reasons to go with VM's - they are both very intelligent guys who know their stuff. But its a personal decision, and truly the ideal situation is to have a mix of both VM's and multiple computers with multiple hardware configurations. So yeah, save your money for a machine that can handle VM's and play around with them. But also try and procure spare/old computers friends and family have lying around so you can have some variety in your targets. Good luck!

telot

Edited December 25, 2011 by telot

[digip]

My vote is for Virtual Machines as well. Especially when there are free options out there to help you get started with setting up virtual networks. Saves space, electricity and keeps down the heat from multiple machines in my room.

An XP virtual machine will run on 256mb of ram with no issues, and a base 32bit Server 2003 VM with Active Directory/DNS can get away with 512mb of ram. If you got 4gb of ram, you can run your main host desktop, a server 2003 VM, and a few XP VM's at the same time with no real issues. If you bridge the VM's to the main network, you can make them part of the lan and attack from another physical machine. can also attack from the Host machine or if your machine is a little beefier on CPU side and handles 4 or more VM's, a vm of backtrack on the same host with the other 3 VM's at the same time.

I used to run a server 2003 AD VM setup with 2 XP vm's joined to the domain and a backtrack 3 VM all at the same time, with no more then 3.x GB of ram in Windows XP as the host on a Quad core AMD Phenom and it was stable. Little slow, but stable. Now I'm rocking 64bit system with 16GB ram, 6 core Phenom II and a high end graphics card, and often forget that I have several VM's open at the same time when working on stuff.

Anyway.....Virtual Machines, more than capable for any home user to setup a simple network to attack. The only thing it won't do well, is virtualizing networking equipment, so if you wanted to say, do vlan attacks against specific Cisco equipment or routing ptocols or specific versions of IOS on Cisco, juniper, etc routers and switches, then you need physical hardware for best results with the vulnerable software running on them.

[Infiltrator]

As a suggestion, you could add a mixture of both virtual machines and physical machines to your lab and experiment with both. Each will have their advantages of course, but it should make your lab more exciting and with more tools to work with.

In addition, since its a pen-testing lab, you might want to include some WAPs (wireless access points) and use them to sharpen your wireless pen-testing skills as well.

[TT1TTONE]

As a suggestion, you could add a mixture of both virtual machines and physical machines to your lab and experiment with both. Each will have their advantages of course, but it should make your lab more exciting and with more tools to work with.

In addition, since its a pen-testing lab, you might want to include some WAPs (wireless access points) and use them to sharpen your wireless pen-testing skills as well.

I'll have to save that until I got some more time, but it definitely sounds like the way to go when I feel for advancing beyond the basics

So I've got myself a decent computer with a Core 2 Duo @ 2,3 GHz and 4GB of RAM some days ago, but I have yet to install a (host) OS and a good virtualization software. Thought of Windows 7 and VMware, how does that sound?

Oh, and I've got a D-Link 655 as a router at home, how would I go on if I would want to isolate the above mentioned computer from the rest of the network, but yet be able to connect through it wirelessly?

Edited January 4, 2012 by TT1TTONE

[Infiltrator]

So I've got myself a decent computer with a Core 2 Duo @ 2,3 GHz and 4GB of RAM some days ago, but I have yet to install a (host) OS and a good virtualization software. Thought of Windows 7 and VMware, how does that sound?

I don't see any problems with that, in fact my machine at home, has Windows 7 with Vmware and 3 VMs, all running at the same time.

However, you will need more than just 4 GB of RAM, if you plan to run more than 2 VMs at once and a quad core CPU, to retain the performance from dropping too much.

Oh, and I've got a D-Link 655 as a router at home, how would I go on if I would want to isolate the above mentioned computer from the rest of the network, but yet be able to connect through it wirelessly?

Will Internet access be required in your LAB?

[TT1TTONE]

I don't see any problems with that, in fact my machine at home, has Windows 7 with Vmware and 3 VMs, all running at the same time.

However, you will need more than just 4 GB of RAM, if you plan to run more than 2 VMs at once and a quad core CPU, to retain the performance from dropping too much.

Will Internet access be required in your LAB?

Initially, I will go with just 2 VMs, one running BackTrack and the other running Windows XP or Windows 7. I'm not so sure but I believe that since BackTrack basically is a Linux-dist it shouldn't be too hungry on resources? And the victim OS will not be running anything too demanding after all.

Internet access would be needed for the host only, so that I can access info, tools, exploits, updates etc. But I would prefer if I somehow could put the two guests in their own "LAN".

Edited January 5, 2012 by TT1TTONE

[TT1TTONE]

... But I would prefer if I somehow could put the two guests in their own "LAN".

Anyone who can point me to the right direction? I've been trying to understand the differences between the various network connections that VMware supports, which are bridged networking, network address translation (NAT), and host-only networking, but don't understand which one that would do what I wanted to do (putting the VMs in their own network so that I don't target wrong devices on the LAN).

[Infiltrator]

Anyone who can point me to the right direction? I've been trying to understand the differences between the various network connections that VMware supports, which are bridged networking, network address translation (NAT), and host-only networking, but don't understand which one that would do what I wanted to do (putting the VMs in their own network so that I don't target wrong devices on the LAN).

You need to set each of your VM interfaces to NAT, they will each receive an IP address in a different subnet range.

For example, my main LAN IP address is 192.168.1.X, my VMs use the same IP address range 192.168.1.x but they are in a different subnet, which is 192.168.85.x

I can still ping my default gateway 192.168.1.1 and access internet, but when pen-testing/exploiting my virtual machines, all I have to remember is to use the subnet 192.168.85.x, instead of subnet 192.168.1.x

As simple as that!

[TT1TTONE]

You need to set each of your VM interfaces to NAT, they will each receive an IP address in a different subnet range.

For example, my main LAN IP address is 192.168.1.X, my VMs use the same IP address range 192.168.1.x but they are in a different subnet, which is 192.168.85.x

I can still ping my default gateway 192.168.1.1 and access internet, but when pen-testing/exploiting my virtual machines, all I have to remember is to use the subnet 192.168.85.x, instead of subnet 192.168.1.x

As simple as that!

Thanks alot, much appreciated! :D

[Infiltrator]

Thanks alot, much appreciated! :D

Let us know how you go?

[TT1TTONE]

Let us know how you go?

I know that this might sound like that I'm stupid, but I don't get where I should get to choose more specific options regarding the NATing? In VMware that is.

Nevermind that...

So now I've set up so that the VM gets an IP-adress (192.168.3.X) while the clean and non-experimental devices is in the range of 192.168.0.0-255.

BUT, there is a major problem; I can ping across the subnets...

Edited January 5, 2012 by TT1TTONE

[Infiltrator]

BUT, there is a major problem; I can ping across the subnets...

Yeah I know that and it does happen to me too. But your VMs are on a different subnet 192.168.3.X, and as long as you set your tools to operate off that subnet it shouldn't be a problem.

Alternatively, you could buy a router or a layer 3 switch and configure Vlans on it, so that way both subnets will be isolated from each other.

Edited January 5, 2012 by Infiltrator

[TT1TTONE]

Yeah I know that and it does happen to me too. But your VMs are on a different subnet 192.168.3.X, and as long as you set your tools to operate off that subnet it shouldn't be a problem.

Alternatively, you could buy a router or a layer 3 switch and configure Vlans on it, so that way both subnets will be isolated from each other.

OK, sounds better than I thought then. So this is the furthest I can go in order to separate the dirty and the good, without going as far as physically dividing them?

[digip]

OK, sounds better than I thought then. So this is the furthest I can go in order to separate the dirty and the good, without going as far as physically dividing them?

If set to NAT, only the host machine will be able to access the VM's. The host machine will always be able to ping the VM's, or should be able to see them via arp after a ping, but the reverse is not always true. The VM's would not be pingable, from say, another machine on the local lan, unless you bridged them to the physical network and were part of your routers same subnet. This is one of the reasons you want to make sure all VM's are setup with NAT and not BRIDGED and when attacking them, only using the IP subnet for the VMs, or everyone will be able to see the VM's and vice versa if you make them bridged to the physical network.

[TT1TTONE]

If set to NAT, only the host machine will be able to access the VM's. The host machine will always be able to ping the VM's, or should be able to see them via arp after a ping, but the reverse is not always true. The VM's would not be pingable, from say, another machine on the local lan, unless you bridged them to the physical network and were part of your routers same subnet. This is one of the reasons you want to make sure all VM's are setup with NAT and not BRIDGED and when attacking them, only using the IP subnet for the VMs, or everyone will be able to see the VM's and vice versa if you make them bridged to the physical network.

I didn't really understand what you meant with "see the VM's"?

The lack of configuration that can be done in VMware Player tires me...

  192.168.0.1 [Router]
 /
|
|-192.168.0.X [Bunch of "clean" devices ++ the host]
| 
|-192.168.2.43 [Where the victim VM is up]

Now, the VM can ping the router, and some but not all of the "clean" devices and the host can ping the VM aswell. But whenever I try to ping the VM from a device on the other subnet, I get a reply from a what looks like an class-A IP-adress:

C:\Users\Thomas>ping 192.168.2.128

Pinging 192.168.2.128 with 32 bytes of data:
Reply from 82.XXX.17X.1X5: TTL expired in transit.
Reply from 82.XXX.17X.1X5: TTL expired in transit.
Reply from 82.XXX.17X.1X5: TTL expired in transit.
Reply from 82.XXX.17X.1X5: TTL expired in transit.

What's going on?

Edited January 5, 2012 by TT1TTONE

[Infiltrator]

Now, the VM can ping the router, and some but not all of the "clean" devices and the host can ping the VM aswell. But whenever I try to ping the VM from a device on the other subnet, I get a reply from a what looks like an class-A IP-adress:

C:\Users\Thomas>ping 192.168.2.128

Pinging 192.168.2.128 with 32 bytes of data:
Reply from 82.XXX.17X.1X5: TTL expired in transit.
Reply from 82.XXX.17X.1X5: TTL expired in transit.
Reply from 82.XXX.17X.1X5: TTL expired in transit.
Reply from 82.XXX.17X.1X5: TTL expired in transit.

What's going on?

NAT (network address translation) acts as a barrier between the VMs and your "clean" machines. Only the VMs can see/ping your clean machines. That's because NAT knows the subnet of your clean machines, furthermore, your clean machines are not on the same subnet as your VMs, and they do not have direct access to the VMs, because of NAT acting as a barrier. As result, you can't ping any of your VMs machines from within a clean machine.

That's the reason why you are receiving the above "expired in Transit" error message, your clean machine is not on the same subnet as your virtual machine.

You would have to set each of your VMs interface to BRIDGE, in order to be able to ping one another. But doing that, would put your "Clean" machines at risk, and you don't want that.

Edited January 5, 2012 by Infiltrator

[digip]

If your home network is on say 192.168.1.0/24, and if your VM's are on 192.168.2.0/24 (make sure they have proper subnet masks) they shouldn't be able to see each other or communicate with any of the other machines on the real, live network, other other the host running the VM's, without going through a gateway that has interfaces for both of the unique subnets. Your home router, should not be forwarding broadcasts from the VM network into the general home lan on 192.168.1.0/24 unless the host machine is forwarding the requests. The HOST machine running the guest VM's however, will see both the 192.168.1.0/24 AND 192.168.2.0/24 subnets, because it has a NIC (both physical and virtualized) within both subnets, so the host running the VM's can see, ping and connect to both sides of the fence.

If you want the VM's to be reachable from another home machine on the lan, you would have to bridge the VM's to the physical home network, where they would share the same IP Subnet as the main home computers and your router, or create static routes to the VM's and force the host machine running the VM's to act as a gateway and forward all traffic destined to the VM's and vice versa. If you want the VM's to be able to see other live machines on the home lan without bridging, you need to make the host machine a gateway with routes to each the subnets of the home lan and VM lan, passing through the host machine as if it was a router.

Kine of hard to explain networking without going into all of the aspects and how the layers work, but the general thing to understand is, different subnets can not speak to each other, unless they have a common gateway that sees both subnets and is configured to forward the requests to the other subnet. The reason people can't see all your home machines from the internet, is your router uses NAT, which gives you a different subnet on the inside home lan, vs your outside interface, which is the IP assigned by your ISP. When you make a request for a website, your router looks in its routing table for the address, and when it can't find it, it forwards it off to its gateway(namely your ISP) which also does a DNS lookup, traverses the itnernet and then gets sent back to you, and the router then sends back the info to the requesting machine.

Things to read up on: OSI model, NAT, DNS, subnetting/subnet masks, and routes.

Edited January 6, 2012 by digip

[TT1TTONE]

NAT (network address translation) acts as a barrier between the VMs and your "clean" machines. Only the VMs can see/ping your clean machines. That's because NAT knows the subnet of your clean machines, furthermore, your clean machines are not on the same subnet as your VMs, and they do not have direct access to the VMs, because of NAT acting as a barrier. As result, you can't ping any of your VMs machines from within a clean machine.

That's the reason why you are receiving the above "expired in Transit" error message, your clean machine is not on the same subnet as your virtual machine.

You would have to set each of your VMs interface to BRIDGE, in order to be able to ping one another. But doing that, would put your "Clean" machines at risk, and you don't want that. ...

So the host acts as the NAT which can be compared to what my router is doing (Internet <-> home network), I can understand that part.

... your clean machines are not on the same subnet as your VMs, and they do not have direct access to the VMs, because of NAT acting as a barrier. As result, you can't ping any of your VMs machines from within a clean machine. ...

Except for the VM-host, right? Since that computer logically is in both subnets, if I've understood it correctly.

If your home network is on say 192.168.1.0/24, and if your VM's are on 192.168.2.0/24 (make sure they have proper subnet masks) they shouldn't be able to see each other or communicate with any of the other machines on the real, live network, other other the host running the VM's, without going through a gateway that has interfaces for both of the unique subnets. ...

The subnet masks of both networks are 255.255.255.0, isn't that how it's supposed to be in this case?

... Your home router, should not be forwarding broadcasts from the VM network into the general home lan on 192.168.1.0/24 unless the host machine is forwarding the requests. The HOST machine running the guest VM's however, will see both the 192.168.1.0/24 AND 192.168.2.0/24 subnets, because it has a NIC (both physical and virtualized) within both subnets, so the host running the VM's can see, ping and connect to both sides of the fence. ...

I understand the underlined part as i think that it's pretty logical, but how can I confirm whether or not the router is forwarding broadcasts from the visualized network with or without that the host interferes?

... If you want the VM's to be reachable from another home machine on the lan, you would have to bridge the VM's to the physical home network, where they would share the same IP Subnet as the main home computers and your router, or create static routes to the VM's and force the host machine running the VM's to act as a gateway and forward all traffic destined to the VM's and vice versa. If you want the VM's to be able to see other live machines on the home lan without bridging, you need to make the host machine a gateway with routes to each the subnets of the home lan and VM lan, passing through the host machine as if it was a router. ...

Well that is what I'm trying to avoid in this case, so it's its opposite that I should consider now I believe.

... Kine of hard to explain networking without going into all of the aspects and how the layers work, but the general thing to understand is, different subnets can not speak to each other, unless they have a common gateway that sees both subnets and is configured to forward the requests to the other subnet. The reason people can't see all your home machines from the internet, is your router uses NAT, which gives you a different subnet on the inside home lan, vs your outside interface, which is the IP assigned by your ISP. When you make a request for a website, your router looks in its routing table for the address, and when it can't find it, it forwards it off to its gateway(namely your ISP) which also does a DNS lookup, traverses the itnernet and then gets sent back to you, and the router then sends back the info to the requesting machine. ...

That pretty much confirms what I thought, so I guess that this is what I'll try to setup on VMware :)

... Things to read up on: OSI model, NAT, DNS, subnetting/subnet masks, and routes.

Believe it or not, but I actually got a A on this when we read about it in school back in the days

Edited January 6, 2012 by TT1TTONE

[digip]

The subnet masks of both networks are 255.255.255.0, isn't that how it's supposed to be in this case?

Ah yes, their masks are the same, BUT, they are actually two different subnets. If however, the mask was 255.255.0.0., then they would both be able to see each other, as then, the network would be 192.168.0.0/16. and any address in 192.168.1.x and 2.x would be under the same subnet for the 192.168.0.0 network.

192.168.1.0/24 and 192.168.2.0/24, are two different subnets. The gateway in the first subnet is 192.168.1.1(or whatever you set it to) and its broadcast would be 192.168.1.255. The other subnet would be 192.168.2.1(or whatever vmware sets it to) and its broadcast would be 192.168.2.255. The network essentially ends at its broadcast address. They would only broadcast to their respective subnets, regardless if the mask is the same.

To illustrate it further, break down the 192.168.1.x network into 2 subnets. Using a subnet mask of 255.255.255.128, you effectively cut the ip range in half. You end up with a range of 192.168.1.0-192.168.1.127 (where usable addresses are 1-126, x.x.x.0 is the network and x.x.x.127 is the broadcast), the next range usable would be 192.168.1.128-192.168.1.255 (where usable space is 129-254 and the broadcast is x.x.x.255). These two subnets, would not be able to speak to each other with a subnet mask of /25 or 255.255.255.128. They share the same mask, but would be two independent subnets. Only way they could see one another, is a common gateway who has a 2 interfaces with 1 address for each subnet.

Edited January 6, 2012 by digip