Frequently Asked Questions
Troubleshooting
Software
Pentesting
Formats
Virtual Machines
Networking
VulnHub
Troubleshooting
Well that depends on what you have downloaded:
- '.7z', '.RAR', '.TAR', '.TAR.BZ2' and '.ZIP' - These are different compressed archive formats. They can be
extracted to reveal additional files. 7-zip is free,
cross-platform and is able to extract all the mentioned formats.
- '.ISO' and '.IMG' - These are disk images of an optical disc. They could be burnt onto a CD/DVD (IMGBurn), loaded onto a USB stick (UNetbootin) or mounted inside a virtual machine.
- '.NVRAM' - The virtual machine's BIOS.
- '.OVA' - 'Open Virtualization Archive' is a single compressed archive ('.tar') which contains the entire
virtual machine (Virtual machine's settings ('.OVF') & hard drive ('.VMDK')). This can be imported into
virtualization software.
- '.OVF' - 'Open Virtualization Format' is the configuration file for the virtual machine. This can be
imported into virtualization software.
- '.VMDK' and '.VHD' - 'Virtual Machine Disk (VMDK)' and 'Virtual Hard Disk (VHD)' are virtual hard drive
formats. These can be compressed to save room and expand when required. These can be imported into an existing
virtual machine.
- '.VMEM' - The Virtual machine's paging file.
- '.VMSN' and '.VMSD' - VMSN are VMware snapshots and VMSD file stores metadata related to the snapshots.
- '.VMX' - Virtual machine's settings. This can be imported into virtualization software.
-
Did it download correctly?
Check the checksum of the file. For every download, we
list the MD5 and SHA1 checksum of the file. You can find all the checksums here. Alternatively they will be individually displayed on
their entry page. To check the checksum, you can do it here.
-
Using the right software?
See here.
-
How do you know it's not working?
See here.
If you're still having issues, see
here.
Below are different methods for Linux, OSX & Windows to calculate the checksum value of a file. We will use 'metasploitable-linux-2.0.0.zip' in the examples below.
Linux
If you have the 'coreutils' packaged install
(which is very common with major Linux distribution), you can
use 'md5sum' & 'sha1sum' for checking files checksums.
[dev@localhost ~]# md5sum metasploitable-linux-2.0.0.zip
8825f2509a9b9a58ec66bd65ef83167f metasploitable-linux-2.0.0.zip
[dev@localhost ~]# sha1sum metasploitable-linux-2.0.0.zip
84133002ef79fc191e726d41265cf5ab0dfad2f0 metasploitable-linux-2.0.0.zip
[dev@localhost ~]#
OSX
Simlar to Linux, OSX comes with 'md5' & 'shasum' to generate files' checksums.
[localhost:~ dev]$ md5 metasploitable-linux-2.0.0.zip
8825f2509a9b9a58ec66bd65ef83167f metasploitable-linux-2.0.0.zip
[localhost:~ dev]$ shasum metasploitable-linux-2.0.0.zip
MD5 (metasploitable-linux-2.0.0.zip) = 84133002ef79fc191e726d41265cf5ab0dfad2f0
[localhost:~ dev]$
Windows
By default, windows doesn't come with a program to calculate checksums. We recommend using a 3rd party tool called
'
hashtab'.
To use it:
- Right click on the file --> Properties --> File Hashes.
- Wait a short while, as it calculates the file's checksum (you can select which values to calculate by right
clicking in the hash window --> settings).
- You can easily compare the hash values by pasting a known value into the text box below, and hashtab will
automatically compare the values and display the outcome.
HashTab
Static IP? DHCP Server?
When the author created the virtual machine, they may have chosen for the machine to have a static IP address, or
for it to be assigned one via a Dynamic Host Configuration Protocol (DHCP) server.
If there is a README file to go along side the machine, it might be mentioned there. It may also be discussed on the
author's download page. However, there are certain cases when this hasn't been disclosed.
If you're new to setting up a lab, you might be unsure if the target machine is working correctly or not, or, if you
have over looked something. This is why on the entry page on VulnHub; we have listed the networking status of each
machine.
If it is using a static IP address it will have a pre-assigned IP address. As IP addresses are unique and shouldn't
have duplicates on the same network, you will need to check that there isn't already a device using the machine's
static IP address. Usually this shouldn't be a problem as these machines should be placed in an isolated
network.
However, if the virtual machine requires a DHCP server to assign an IP address, there needs to be a DHCP service
running within the environment. Both Virtualbox and VMware products offer a DHCP service, which, when using the
right 'network type', will isolate the machine from the current network. See the
lab for our
guide on doing this.
It is highly recommended that you DO NOT run these machines on a: production network, home network, a network with
Internet access and/or a network containing sensitive information
(VulnHub will not be responsible for any loss
or damage caused). These virtual machines will work in isolated networks. See
security for reasons why. Click
here to see how to setup a network
correctly.
Subnetwork
IPv4 network addresses can be broken down into various classes:
Class - Start-End Subnet Mask (Dotted)-CIDR notation - Common Ranges
Class A - 0.0.0.0-127.255.255.255 255.0.0.0 /8 - 10.xxx.xxx.xxx
Class B - 128.0.0.0-191.255.255.255 255.255.0.0 /16 - 172.16.xxx.xxx
Class C - 192.0.0.0-223.255.255.255 255.255.255.0 /24 - 192.168.xxx.xxx
If the machine is using a DHCP to get an IP address, it will be placed into the same subnet as the DHCP
configuration.
But, if the machine is using a static IP address, the machine could lie outside the subnet. Common ranges for a
class C network are 192.168.0.0/24, 192.168.1.0/24. However, if the virtual machine uses '192.168.2.50/24', or
'10.10.10.100/16' as examples, the attacker will need to adjust their virtual environment so they are in the same
subnet.
Being the attacker, you will need to learn techniques to locate machines on a network.
Ping
A common way to see if the machine is 'alive' on a network is to send a ping packet (Internet Control Message
Protocol (ICMP) echo request) and see if there is a reply.
However, if the machine has a firewall installed, it could be designed to drop the packet. This would result in no
response to the ping request, thus failing the test to see if the machine is 'alive'.
Being the attacker, you would have to discover/research other methods to see if the machine is actually online &
functioning correctly.
Depending on the virtual machine, that's the aim of it! You gain access to the system, with the highest user
privilege you can reach, usually by exploiting a service running on the machine. Giving you the user credentials
would defeat the purpose of the exercise.
This isn't always the case, some machines have local challenges which require you to login locally.
If this is the case, the username & password would be mentioned in the README file.
Such machines are: 'Damn Vulnerable Linux' & 'Exploit-Exercises'.
Holynix v2's & Damn Vulnerable Linux's login
screen
Sorry to hear that!
Depending on the nature of the question:
- You can try search the internet using a search engine.
- Contact the original author (You can find contact details on their profile).
- Get in touch with VulnHub (Please allow for 2 business days for a response).
- Join the IRC channel (Due to time-zone differences and/or peoples' personal lives it
could take 'a while' for someone to respond).
Software
A 'virtual machine (VM)', is the simulation of a machine (called the 'guest') that is running inside another machine
(the 'host').
The 'guest' machine uses the 'hosts' system resources to create a virtual environment, which allows for multiple
machines to be created and running at the same time.
These machines behave as close as possible to a 'real' instance.
Depending on the virtualization software, the virtual machine could use 'hypothetical specifications' or emulate the
host's hardware.
These machines can be integrated with a virtual network or interact with an existing network.
It depends what you want to get out of them:
- Virtualbox is free & open source. VMware has a freeware and commercial products. VMware player is
freeware; VMware workstation & VMware fusion are commercial.
- Both solutions work on Linux & Windows hosts, and both support Linux & Windows guests. However,
Virtualbox also supports OSX as a host & guest. Whereas VMware fusion is the only product which VMware
currently offers which supports OSX host & guest.
- VMware player has the same 'core' as workstation, but its either missing various features, or has limitations.
- Virtualbox has all the features of VMware player, including any features that are 'limited' (e.g. snapshots
& virtual network control) along with additional ones (e.g. cloning).
- Virtualbox has a few features that VMware doesn't (currently) offer, such as, capping 'processor
usage'.
- VMware workstation offers a lot more features which Virtualbox (currently) doesn't, for example, fully
automated installations of operating systems, USB3.0 support, better USB device control (more reliable
connecting & releasing devices).
- VMware player is free, and is a limited version of workstation. It's good if you just want to run a
virtual machine.
- Virtualbox is free, works everywhere and has various features over VMware player that are very beneficial:
this product is good if you want to run & manage various virtual machines.
- VMware workstation needs to be purchased, works everywhere and has additional features that are very
beneficial. This product is great if you want to run & manage various virtual machines, especially across
multiple hosts.
Pentesting
Our answer can be found here, and been touched on in the 'Lab' guide.
We answered this question here, in our 'Lab' guide.
These are our recommendations if you're completely new to this:
- De-ICE: S1.100, De-ICE:
S1.110 & De-ICE: S2.100 - Great way to start out.
- Metasploitable 1.0 - Lots of different ways into the box.
- pWnOS 1.0 - Good introduction to (fixing and) using exploits outside
metasploit.
- Damn Vulnerable Web Application - Good introduction into the basics of web application attacks.
- Webgoat - Good introduction into the basics of web application attacks.
- Mutillidae - Good introduction into the basics of web application attacks.
- sqli-labs - Good introduction into the SQL injection attacks.
Afterwards, that's up to you! If you're stuck for ideas/wanting to do something specific, feel free to join the
IRC channel and see what someone suggests.
Formats
Both Virtualbox and VMware use different virtual machine formats, but each support the 'Open Virtualization Format'.
However, you can be at risk of breaking a virtual machine by doing so. The reason for this is that there may be a
'new' network card attached (as each VM solution uses a different virtual network card). Because a different
interface will be active, it may conflict with the setup script of the machine (inside the VM itself) that
the author created. It really depends on how the original author designed the machine.
All the virtual machines can be converted, however, some will function correctly, others will not. Maybe at a
later date, this is something VulnHub will look into documenting.
In the following example, we will move a 'Windows 7' VM from Virtualbox 4.2.4 to VMware Player 5 & Workstation
9, on a windows host.
To do so, we will use 'OVF Tool', which comes pre-installed with VMware player, fusion & workstaion. You can
find the homepage of the tool here.
The basic method/principle is the same when the host OS is Linux or OSX.
Virtualbox (Export)
- Power off the machine (Make sure it's not suspended).
- Virtualbox --> File --> Export Appliance.
- <Machine name> --> Next.
- Choose --> <path to export to> (Leave the two boxes 'un-ticked').
- Check values --> Export.
- Wait.
VMware Player (Import)
- Press 'Open a Virtual Machine'.
- Locate exported file (See stage 4 of Virtualbox).
- Check machine name & where to store the virtual machine.
- Wait.
- The virtual machine should now work.
- The virtual machine will then detect new hardware as a result of the switch in the software.
VMware Workstation (Import)
- Press 'Open a Virtual Machine'.
- Locate exported file (See stage 4 of Virtualbox).
- Check machine name & where to store the virtual machine.
- Wait.
- If 'The import failed because <path> did not pass OVF specification conformance or virtual hardware
compliance checks', press 'Retry'.
- The virtual machine should now work.
- The virtual machine will then detect new hardware as a result of the switch in the software.
You can see what files were produced as a result.
(First window: the original Virtualbox format. Middle: an export in OVA format. Bottom: VMware format).
The same introduction message in converting 'Virtualbox' to 'VMware' applies
here. Even if it is successfully converted it may still not function correctly due to the internal scripts not being
coded to use the 'new' hardware.
VMware has the ability to convert to different formats, however, it is achieved by 'Command Line Interface (CLI)',
not a 'Graphical User Interface (GUI)'.
In this example, we will move a 'Windows 7' VM from VMware to Virtualbox 4.2.4.
It doesn't matter if it's player or workstation, as they are both in the same directory.
The basic method/principle is the same when the host OS is Linux or OSX.
VMware (Export)
- Power off the machine (Make sure it's not suspended).
- Locate the working path of VMware (Windows users can quickly find it by right clicking on the shortcut then
'Open file location').
Windows XP: 'C:\Program Files\VMware\VMware Workstation'
Windows Vista or higher: (x64) 'C:\Program Files (x86)\VMware\VMware Workstation' or (x86) 'C:\Program
Files\VMware\VMware Workstation'
Linux: '/usr/lib/vmware-ovftool/'
OSX: '/Applications/VMware Fusion.app/Contents/Library/VMware OVF Tool/'
- Once the path of VMware is known, open a command prompt window in the same directory (Window Vista or
higher users can quickly do this by holding 'shift' & right clicking then press 'Open command window
here').
- Type the following commands:
Windows
:
- cd OVFTool
- ovftool.exe <path of the virtual machine> <path to export to>
For example: ovftool.exe "C:\Virtual Machines\Windows 7.vmx" "C:\Virtual Machines\Windows 7.ovf"
Linux/OSX
:
- ./ovftool <path of the virtual machine> <path to export to>
For example: ./ovftool /home/user/vms/vmware/win7.vmx /home/user/vms/vbox/win7.vmx
- Wait.
Virtualbox (Import)
- Virtualbox --> File --> Import Appliance.
- Open appliance --> Locate exported file (See stage 4 of VMware) --> Next.
- Virtualbox then displays a summary of the machine which will be imported. The settings now can be altered from
the VMware values.
- Wait.
- The virtual machine should now work.
- The virtual machine will then detect new hardware as a result of the switch in the software.
In this example, we will add the virtual hard drive from Kioptrix level
1.3 to an existing machine.
If you don't have a existing machine to amend, you'll need to create a new virtual machine. This guide
doesn't
cover this.
It doesn't matter if it's player or workstation.
The principle is the same when the host OS is Linux or OSX.
- Power off the machine (Make sure it's not suspended).
- Edit virtual machine settings.
- Add --> Hard Disk --> Next (You may get a UAC prompted if you're using Windows Vista or higher and
have UAC enabled. Press 'Yes').
- Select 'Use an existing virtual disk'.
- Browse --> Locate the image file.
- Select 'Keep Existing Format'.
- Okay.
- The virtual machine should now work.
Virtual Machines
There are a few issues to take into consideration:
- You're taking a machine that has known vulnerabilities in it and its purpose is to be broken into. As a
result, you'll be increasing the risk of the network it's attached to.
- You're running someone else's code, so you're trusting the author hasn't made it perform/run in a malicious
manner. Just like running an unknown/untrusted program, the virtual machine could:
- Try and attack the host and/or network in-which its been attached to.
- Connect back to the author, becoming a 'zombie' in botnet.
- You could end up attacking yourself or the incorrect target. For example if the virtual machine network was
set to 'NAT' and uses port forwarding for the guest system, any other open ports which haven't been forwarded
are services running on the host machine.
DigiNinja wrote a blog post on exactly this, '
Blindly
Installing VMs and Using Live CDs'. Also to highlight the issue,
ScriptJunkie created a VM to demonstrate these issues, called '
The Hackers Games'. His blog post that explains the dangers of it can
be found here '
Malicious VM to Host
Attacks'.
Please see below on our recommendations on
protecting yourself.
- Isolate the virtual machine from the internal network & disable external access. It is
highly recommended
these machines are not attached to a
production network
or a home network
. Ideally they want to be in an
isolated lab environment. For our guide on creating a virtual lab, see here.
Alternatively, here is a quick breakdown:
- For machine(s) which have network access to the virtual machine(s) in question, make sure they are:
- Fully up-to-date with patches (Operating system & applications).
- Behind an internal firewall.
- Do not contain any sensitive information on them.
- Close any unneeded services.
- If possible, use another virtual machine to attack them, so a snapshot can be taken in a known 'clean'
state before attacking. Then it can be 'restored' once the target machine has been powered off.
- Have an anti-virus solution installed, working correctly and up-to-date.
- If possible, use an IDS or IPS. (See Security Onion
for a 'live CD' of a collection of useful network monitoring tools).
For tutorials on how to set up your lab: you can find our guide
here, a blog post from
metasploit on '
How to set up a penetration testing lab'
as well as a page from
SecurityXploded.
You have two options: 'I moved it' or 'I copied it'.
I moved it
This keeps the current 'Universally Unique Identifier (UUID)' for the VM. The UUID is generated from the host's
identifier and the location of the VM's configuration file.
If there is only a single instance of the virtual machine, it's safe to use this option.
For example, if you
have downloaded a virtual machine from the Internet)
You may also get this issue if you update VMware to a newer version, as the host's identifier could be updated as
well.
I copied it
This generates a new UUID for the VM, so that it doesn't clash with the original VM. (The UUID shouldn't clash as
it could cause issues with system management).
You will want to use this option if you're cloning machines.
For example, if you made a 'template' machine, and
cloning instances of it.
A link to VMware's answer is here
(KB:
1541).
This is a result of having a newer version of VMware compared to the version used to create the virtual disk
(and/or machine).
You have two options: 'Keep Existing Format' or 'Convert'.
Keep Existing Format
VMware has backwards compatibility with machines that were produced by older versions. As a result, VMware is able
to use an older virtual disk without having to modify it. This allows the virtual machine to be same as when the
author created it
(as we wish to keep any modification to a minimum).
We recommend selecting this option to maintain the integrity of virtual machines as much as possible.
Convert
By selecting this option, it would upgrade the virtual disk to current version of VMware. This update makes sure
its compatible with future versions of VMware.
Networking
- Bridged
- This allows for the VM to connect to the same network via the host's network card (You can specify which
interface to use).
- The VM will have its own unique IP address on the network (closest possible to simulating an additional
node on the network).
- If there is already a DHCP service running on the network, it will be automatically assigned an IP address.
Otherwise, it needs to be manually assigned one (a static IP address).
- This is useful when providing services externally to/from the VM
- Any external nodes on the same network are able to interact with the VM as well as any VMs which also have
access to the host network.
- NAT (Network Address Translation)
- This allows for the VM to connect to the same network as the host by using the hosts PC & IP address.
- The VM only has a unique IP address between the guest OS and the host OS. When traffic is leaving from the
hosts, it appears to originate from the host (masking the effect of an additional node on the network).
- Between the guest OS and the host OS, the VM will have an IP address automatically assigned to it from
VMware, but afterwards it uses the host's address. Therefore, no network configuration is needed.
- This is useful when IP addresses are limited/restricted. For example, dial up Internet or Wi-Fi hotspots.
- No external nodes on the same network are able to interact with the VM, however, other machines also using
'NAT' will be able to communicate with each other.
- Host-only
- This creates a separate network which is only connected to the host, thus causing an isolated virtual
network.
- The VMs will have their own unique IP addresses on the separate network.
- VMware has its own DHCP service (by default) running for the clients, however, IP addresses can still
be manually assigned.
- If multiple VMs use 'host-only' on the same host, they will all be able to communicate between themselves as
well as the host inside the virtual network.
- This is useful for separating machines from any existing network access, whilst allowing for communication
to still happen between the host and the VM.
- No external nodes are able to interact with the VM, however, other machines also using 'host-only' will be
able to communicate.
- LAN segment
- This creates a separate network, with no network access to the host, causing an isolated virtual network.
- The VM will have their own unique IP addresses on the separate network.
- IP addresses need to be a manually assigned or a DHCP service needs to be installed, configured and running
inside the segment. There isn't any communication to the host so VMware can't offer its DHCP service.
- Only machines that are in the same segments can communicate with each other. Multiple segments can be used
at once, however these are separate networks so nodes can't communicate between segments.
- This is useful for separating machines from any existing network access and the host, whilst allowing for
communication to still happen between VMs in their virtual segments.
- No external nodes are able to interact with the VM including the host. Only machines on the same segment are
able to communicate.
By enabling the option '
Replicate
physical network connection state' under 'Bridged' network type selection, when the network connection is
disconnected on the host this will be reflected inside the VM. For example, if the host was using a wired connection
and the cable is unplugged, or if disconnected from a wireless network, the VM will also be disconnected. By doing
so, the IP address of the VM will be renewed. This is useful for mobile devices that might not always have a
permitted network connection as they could be moving from wired connections or using a different wireless
connection.
A good guide explaining the differences in network modes can be found
here.
You can customise VMware player further by pressing on 'advanced', to reveal more control over the virtual
network.
Q.) VMware fusion: What's the difference
between: 'Share with my Mac/NAT', 'Bridged Networking' and 'Private to my Mac/Host-only'?
Back to the Top
- Share
with my Mac/NAT (Network Address Translation)
- This allows for the VM to connect to the same network as the host by using the hosts PC & IP address.
- The VM only has a unique IP address between the guest OS and the host OS. When traffic is leaving from the
hosts, it appears to originate from the host (masking the effect of an additional node on the network).
- Between the guest OS and the host OS, the VM will have an IP address automatically assigned to it from
VMware, but afterwards it uses the host's address. Therefore, no network configuration is needed.
- This is useful when IP addresses are limited/restricted. For example, dial up Internet or Wi-Fi hotspots.
- No external nodes on the same network are able to interact with the VM, however, other machines also using
'NAT' will be able to communicate with each other.
- Bridged
Networking
- This allows for the VM to connect to the same network via the host's network card (You can specify which
interface to use).
- The VM will have its own unique IP address on the network (closest possible to simulating an additional
node on the network).
- If there is already a DHCP service running on the network, it will be automatically assigned an IP address.
Otherwise it needs to be manually assigned one (a static IP address).
- This is useful when providing services externally to/from the VM
- Any external nodes on the same network are able to interact with the VM as well as any VMs that have
external access.
- You can select which interface to use, or VMware can 'auto detect' the interface.
- Private
to my Mac/Host-only
- This creates a separate network which is only connected to the host, thus causing an isolated virtual
network.
- The VM will have their own unique IP addresses on the separate network.
- VMware has its own DHCP service (by default) running for the clients, however, IP addresses can still
be manually assigned.
- If multiple VMs use 'host-only' on the same host, they will all be able to communicate between themselves as
well as the host inside the virtual network.
- This is useful for separating machines from any existing network access, whilst allowing for communication
to still happen between the host and the VM.
- No external nodes are able to interact with the VM, however, other machines also using 'host-only' will be
able to communicate.
- Bridged
- This allows for the VM to connect to the same network via the host's network card (You can specify which
interface to use).
- The VM will have its own unique IP address on the network (closest possible to simulating an additional
node on the network).
- If there is already a DHCP service running on the network, it will be automatically assigned an IP address.
Otherwise it needs to be manually assigned one (a static IP address).
- This is useful when providing services externally to/from the VM
- Any external nodes on the same network are able to interact with the VM as well as any VMs that have external
access.
- NAT
(Network Address Translation)
- This allows for the VM to connect to the same network as the host by using the hosts PC & IP address.
- The VM only has a unique IP address between the guest OS and the host OS. When traffic is leaving from the
hosts, it appears to originate from the host (masking the effect of an additional node on the network).
- Between the guest OS and the host OS, the VM will have an IP address automatically assigned to it from VMware,
but afterwards it uses the host's address. Therefore, no network configuration is needed.
- This is useful when IP addresses are limited/restricted. For example, dial up Internet or Wi-Fi hotspots.
- No external nodes on the same network are able to interact with the VM, however, other machines also using
'NAT' will be able to communicate with each other.
- Host-only
- This creates a separate network which is only connected to the host, thus causing an isolated virtual network.
- The VM will have their own unique IP addresses on the separate network.
- VMware has its own DHCP service (by default) running for the clients, however, IP addresses can still
be manually assigned.
- If multiple VMs use 'host-only' on the same host, they will all be able to communicate between themselves as
well as the host inside the virtual network.
- This is useful for separating machines from any existing network access, whilst allowing for communication to
still happen between the host and the VM.
- No external nodes are able to interact with the VM, however, other machines also using 'host-only' will be
able to communicate.
- Custom
This allows for custom settings for 'Bridged', 'NAT' or 'Host-only'. For example:
- Change which interface to use (Bridged).
- Port forwarding (NAT).
- DHCP settings (NAT & Custom).
- LAN
segment
- This creates a separate network, with no network access to the host, causing an isolated virtual network.
- The VM will have their own unique IP addresses on the separate network.
- IP addresses need to be a manually assigned or a DHCP service needs to be installed, configured and running
inside the segment. There isn't any communication to the host so VMware can't offer its DHCP service.
- Only machines that are in the same segments can communicate with each other. Multiple segments can be used at
once, however these are separate networks so nodes can't communicate between segments.
- This is useful for separating machines from any existing network access and the host, whilst allowing for
communication to still happen between VMs in their virtual segments.
- No external nodes are able to interact with the VM including the host. Only machines on the same segment are
able to communicate.
By enabling the option '
Replicate
physical network connection state' under 'Bridged' network type selection, when the network connection is
disconnected on the host this will be reflected inside the VM. For example, if the host was using a wired connection
and the cable is unplugged, or if disconnected from a wireless network, the VM will also be disconnected. By doing so,
the IP address of the VM will be renewed. This is useful for mobile devices that might not always have a permitted
network connection as they could be moving from wired connections or using a different wireless connection.
A good guide explaining the differences in network modes can be found
here.
You can customise VMware workstation further by pressing on 'advance' or going to 'virtual network editor'
(from
either the start menu or VMware workstation --> Edit), to reveal more control over the virtual network.
- Not attached
- This has the effect of not having been plugged in, causing the machine itself to be isolated from the network.
- The VM will not be able to get an IP address.
- No machine will be able to communicate to the VM.
- Useful for separating the machine from any network access.
- NAT (Network Address Translation)
- This allows for the VM to connect to the same network as the host by using the hosts PC & IP address.
- The VM only has a unique IP address between the guest OS and the host OS. When traffic is leaving from the
host's, it appears to originate from the host (masking the effect of an additional node on the network).
- Between the guest OS and the host OS, the VM will have an IP address automatically assigned to it from
Virtualbox, but afterwards it uses the host's address. Therefore, no network configuration is needed.
- This is useful when IP addresses are limited/restricted. For example, dial up Internet or Wi-Fi hotspots.
- No external nodes on the same network are able to interact with the VM, as well other VMs also using 'NAT'
(This is because each VM has the same NAT IP address).
- Bridged Adapter
- This allows for the VM to connect to the same network via the host's network card (You can specify which
interface to use).
- The VM will have its own unique IP address on the network (closest possible to simulating an additional
node on the network.
- If there is already a DHCP service running on the network, it will be automatically assigned an IP address.
Otherwise it needs to be manually assigned one (a static IP address).
- This is useful when providing services externally to/from the VM
- Any external nodes on the same network are able to interact with the VM as well as any VMs that have external
access.
- Internal Network
- This creates a separate network, with no network access to the host, causing an isolated virtual network.
- The VM will have their own unique IP addresses on the separate network.
- IP addresses need to be a manually assigned or a DHCP service needs to be installed, configured and running
inside the virtual network. There isn't any communication to the host so Virtualbox can't offer its DHCP
service.
- Only machines that are in the same 'network name' can communicate with each other. Multiple 'network names'
can be used at once, however these are separate networks so nodes can't communicate between networks.
- This is useful for separating machines from any existing network access and the host, whilst allowing for
communication to still happen between VMs in their virtual networks.
- No external nodes are able to interact with the VM including the host. Only machines with the name 'network
name' can communicate.
- Host-only
- This creates a separate network which is only connected to the host, thus causing an isolated virtual network.
- The VM will have their own unique IP addresses on the separate network.
- Virtualbox has its own DHCP service (by default) running for the clients, however, IP addresses can
still be manually assigned.
- If multiple VMs use 'host-only' on the same host, they will all be able to communicate between themselves as
well as the host inside the virtual network.
- This is useful for separating machines from any existing network access, whilst allowing for communication to
still happen between the host and the VM.
- No external nodes are able to interact with the VM, however, other machines also using 'host-only' will be
able to communicate.
- Generic Driver
Requires downloading the extension pack for
Virtualbox.
- UDP Tunnel - Enabling virtual
machines to be interconnecting using different hosts machines.
- 'Virtual Distributed Ethernet (VDE)'
networking - "a flexible, virtual network infrastructure system, spanning across multiple hosts in a secure way.
It allows for L2/L3 switching, including spanning-tree protocol, VLANs, and WAN emulation".
If '
Promiscuous mode' is disabled, only the traffic that was intended to receive will be passed along.
It's seen as more 'secure' because only the intentional traffic for each node will forward along. This is how a
'network switch' functions.
However, if it's enabled, the 'network interface controller (NIC)' will pass all the traffic which is going though.
This is used for 'packet sniffing' and a single node can view all the traffic on the network, useful for inspecting
& debugging the network. This is how a 'network hub' functions.
Virtualbox has multiple settings regarding promiscuous mode:
- Deny - Disables promiscuous mode. It has the effect of using a virtual switch, rather than a virtual hub.
- Allow VMs - Only the traffic between VMs will be promiscuous mode.
- Allow All - All traffic (VMs & supported devices in the physical network) will be promiscuous mode.
VulnHub
We all learn in different ways. What works for some people, doesn't for others.
Some people learn by "watching others", or "hands on experiences", other learn by "reading about it".
We offer walkthroughs for various reasons:
- If this is all new to you, you might want a helping hand to get you started.
- After giving it a go, you might become stuck for a few hours, so they offer a nudge in the right direction.
- Once completing it, you can compare methods.
We don't make you press the 'walkthrough' button, if you wish to 'cheat' - that's your decision and you're only
'cheating' yourself.
This is the reason why we will not have a 'hall of fame' or 'user rankings' as it wouldn't be fair to the people who
tried.
Either because we don't know about it, busy or both!
Please get in
contact with us and make sure we are aware of it.
This isn't our job & we do have personal lives to live, so don't expect it to be added instantly.
If you have taken the time to write up a walkthrough, we would love to mention it on the list.
Either submit it on the entry page, or get in
touch with us and it will be added.
You can:
- Help out other people (Check out the IRC channel).
- Create an entry for us to index & others to complete (and then submit it!)
- Write up a walkthrough (afterwards submit it!)
- If you wish to help with the project (VulnHub) itself, please do get in touch (We
have the ideas/plans but not the time/man power to achieve them!)