InfoSec 3001 — Information Security from the Offensive Perspective

Step 112. Installing Metasploitable2 and Building the Isolated Lab — Completing a Safe Firing Range

Step 112. Installing Metasploitable2 and Building the Isolated Lab — Completing a Safe Firing Range

Level 2 — Security Introduction and Attack Skill Basics | Difficulty ★★★☆☆ | Estimated time: 2–3 hours (excluding download time)

Prerequisites: you’ve finished Step 111 and your Kali VM boots. You understand VirtualBox’s network modes (NAT, Host-only). Internet connection required (MS2 download).

  • What you need: VirtualBox, the Kali VM (Step 111), 10GB+ of free disk space, an internet connection.
  • Caution: ⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime. The Metasploitable2 we bring in today is a server deliberately made vulnerable — the isolation setup is today’s main event, more important than the installation. The writing environment has neither VirtualBox nor MS2, so all install/run screens are "Screen examples/output examples."

Attack practice needs a target. But you can’t get a target just anywhere — other people’s servers are a crime, and my real server is dangerous. The answer is a practice virtual machine deliberately built vulnerable: Metasploitable2 (MS2 below). Today we bring in this target — but into an isolated firing range that never touches the outside world. The installation procedure itself is simple; what you’ll really learn is the design and verification of network isolation.

1. Learning Objectives

By the end of this chapter, you will be able to:

  • Explain what an intentionally vulnerable VM is and why it exists
  • Distinguish and choose among VirtualBox’s network modes (NAT / Host-only / NAT Network)
  • Bind Kali and MS2 into an isolated lab over a Host-only network
  • Verify by experiment that MS2 cannot reach the internet
  • Establish the principle "no attack practice without isolation verification" as a rule of your lab

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category Details
Language/environment VirtualBox + Kali VM + Metasploitable2 VM
Today’s commands Inside MS2: ip a (check IP), ping (communication/isolation verification); in Kali: ping, ip a
Concepts needed Intentionally vulnerable VM, Host-only network, NAT Network, isolation verification, lab ethics
Today’s artifact An isolated lab where only Kali ↔ MS2 communicate + snapshots of both VMs

2-1. Metasploitable2 — A Server Deliberately Made Weak

Metasploitable2 is an Ubuntu-based virtual machine built for security education, with dozens of known vulnerabilities intentionally planted. An outdated FTP server, default passwords, unpatched web services — it’s an OS turned entirely into a workbook of attack techniques you must practice for real.

The reason such a VM exists is simple: the only systems that can legally be attacked are "systems made to be attacked." All of this book’s Level 2 second-half exercises are conducted against this MS2.

2-2. Why Isolation Is the Lifeline

Even with the "for practice" tag attached, MS2’s vulnerabilities are technically real vulnerabilities. What happens if this VM is exposed to the internet or your home network?

  • The internet’s automated scan bots will find and compromise this VM within minutes
  • If the attacker who got in uses this VM as a foothold to attack elsewhere, the origin of that attack becomes your home IP
  • If exposed on your home network, other devices on the same network (family PCs, NAS) are endangered too

In other words, exposing a vulnerable VM goes beyond "I get hacked" — it’s an incident where I provide a springboard for attacks. That’s why today’s completion criteria include not "it’s installed" but "I verified it’s cut off from the outside."

2-3. A Map of VirtualBox Network Modes

Mode VM→Internet VM↔Host VM↔Other VMs Use
NAT Yes Limited No (separate net per VM) Updates, downloads
Host-only No Yes Yes Isolated lab — today’s choice
NAT Network Yes Limited Yes Multi-VM labs needing internet
Bridged Yes Yes Yes (directly exposed to home network) ⚠️ Never use for vulnerable VMs

Host-only is a virtual switch VirtualBox creates inside your PC. Only the VMs connected to this switch — and the VMs and the host — can communicate; there’s no way out to the internet. A perfect firing range for vulnerable VMs.

There’s one inconvenience — a Kali connected only to Host-only has no internet. The solution is giving Kali two adapters: adapter 1 is NAT (for internet), adapter 2 is Host-only (for lab communication). MS2 gets one adapter, Host-only only. This asymmetry is the core of the design — the attacker side sees the world, but the target is locked in.

2-4. The Lab Blueprint

Let’s first draw the structure we’ll complete today:

                Internet
                  ▲
            (NAT adapter)
                  │
┌─────────────┐   │   ┌──────────────────┐
│  Kali VM    │───┘   │  MS2 VM          │
│  adapter1: NAT      │  adapter1: Host-only│
│  adapter2: Host-only│  (no internet)      │
└──────┬──────┘       └────────┬─────────┘
       └──── Host-only virtual LAN ─┘
            (192.168.56.x range)
        communicates only inside the host PC

3. Follow Along

3-1. Downloading Metasploitable2

  1. Open the Metasploitable2 project page on SourceForge in your browser (search: "metasploitable2 sourceforge")
  2. Download the archive (about 800MB–1GB, zip)
  3. Extract → VMware-format files (.vmx, .vmdk) appear

Screen example — after extraction:

Metasploitable2-Linux/
├── Metasploitable.vmx     ← VM configuration file
├── Metasploitable.vmdk    ← virtual disk (the substance)
└── ...

How to read it: MS2 is distributed in VMware format, but VirtualBox can read .vmdk virtual disks as-is. You register it by "creating a new VM while attaching an existing disk," with no conversion.

3-2. Registering MS2 in VirtualBox

  1. VirtualBox Manager → New
  2. Name: Metasploitable2, Type: Linux, Version: Ubuntu (64-bit) — if not shown, Other Linux (64-bit)
  3. Memory: 1024MB (MS2 is lightweight)
  4. Hard disk: select "Use an existing virtual hard disk file" → point to the Metasploitable.vmdk you just extracted
  5. After creation, don’t start it yet — network settings come first

Screen example — creation summary:

Name: Metasploitable2
Type: Linux (Ubuntu 64-bit)
Memory: 1024 MB
Hard disk: Metasploitable.vmdk (existing file, 8GB)

3-3. Preparing the Host-only Network

Check the virtual LAN card VirtualBox provides.

  1. VirtualBox Manager menu → File → Tools → Network Manager (called "Host Network Manager" in some versions)
  2. Confirm a VirtualBox Host-Only Ethernet Adapter exists — if not, Create one
  3. Confirm the DHCP server is enabled (usually on by default; range example: 192.168.56.x)

Screen example:

Adapter: VirtualBox Host-Only Ethernet Adapter
IPv4 address: 192.168.56.1  (this is the host PC's address)
DHCP server: enabled — assigns from 192.168.56.101

How to read it: 192.168.56.1 is the address your host PC holds inside this virtual LAN, and VMs receive addresses from 101 via DHCP. This range is VirtualBox’s default and may differ in your environment — what matters is the "private range + no internet connection" structure.

3-4. Configuring Both VMs’ Networks

Kali (Settings → Network):

  • Adapter 1: NAT (leave as-is — for internet)
  • Adapter 2: check Enable Adapter → select Host-only Adapter

Metasploitable2 (Settings → Network):

  • Adapter 1: Host-only Adapter
  • Do not attach NAT — this is the substance of the isolation

Caution: never choose Bridged from the adapter list. Bridged exposes the VM directly to your home network — for a vulnerable VM, that’s the start of an incident.

3-5. Booting MS2 and Logging In

Start MS2. Instead of a flashy graphical screen, a black text console appears — MS2 is a server, so it has no GUI.

Screen example — after boot completes:

Metasploitable2 login: msfadmin
Password: msfadmin

Log in with the default account msfadmin/msfadmin (the password shows nothing on screen as you type). This default account is practice-only, used solely inside the isolated lab, so we leave it unchanged — but pass this point understanding that the reason it’s allowed is "because of the isolation."

3-6. Checking the IP and Testing Communication

Input (MS2 console)

ip a

Output example (not run in the writing environment — read the address from your own screen):

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
    inet 192.168.56.101/24 brd 192.168.56.255 scope global eth0

How to read it: eth0 was assigned 192.168.56.101. This is MS2’s lab address — the target we’ll call "MS2_IP" in all future exercises. Yours may differ, so note down what’s on your screen, not what’s written here.

Now verify communication from Kali.

Input (Kali terminal)

ping -c 4 192.168.56.101

Output example:

PING 192.168.56.101 (192.168.56.101) 56(84) bytes of data.
64 bytes from 192.168.56.101: icmp_seq=1 ttl=64 time=0.543 ms
...
4 packets transmitted, 4 received, 0% packet loss

How to read it: 0% packet loss — MS2 is visible from Kali. The firing range’s target has entered shooting distance.

3-7. Isolation Verification — Today’s Most Important Command

Seeing the target isn’t enough. Today ends only when you confirm the target can’t see the outside.

Input (MS2 console)

ping -c 3 8.8.8.8
ping -c 3 google.com

Output example (the normal screen when isolation is done right):

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss

ping: google.com: Temporary failure in name resolution

How to read it: paradoxically, 100% packet loss is today’s success message. MS2 can’t reach Google’s DNS server (8.8.8.8), and it can’t resolve domain names either — it’s completely locked in. If you get a response here, the network settings are wrong (Bridged or NAT got attached), so power off the VM right now and go back to 3-4.

3-8. Snapshots — Preserving the Completed Lab State

  1. Shut down MS2 and Kali cleanly
  2. Take snapshots on each VM:
    • Kali: lab connection complete (state with adapter 2 added)
    • MS2: MS2 clean state (first boot, isolation verified)

Why: these snapshots are the starting line of every attack exercise ahead. Even when MS2 gets wrecked by practice (and that is this VM’s raison d’être), one snapshot returns you to a "verified isolated lab" in seconds.

4. Missions & Exercises

Mission — Write the Isolated Lab Verification Certificate

Write a verification certificate containing these items:

  1. A table of both VMs’ network adapter configurations (Kali: NAT + Host-only / MS2: Host-only only)
  2. Quote the lab IP portion from MS2’s ip a output
  3. Quote the Kali→MS2 ping result (success — 0% loss)
  4. Quote the MS2→internet ping result (failure — 100% loss)
  5. The host PC→MS2 ping result (ping 192.168.56.101 from Windows — since Host-only also reaches the host, success is normal)
  6. Both snapshots’ names and times
  7. A one-line declaration: "I will not perform any attack on a vulnerable VM whose isolation has not been verified."

How to verify yourself: item 3 succeeds, item 4 fails — if this contrast remains quoted, it’s complete. This certificate is the lab’s "safety certificate."

Exercises

Exercise 1. State two or more harms that can occur when an intentionally vulnerable VM like MS2 is exposed to the internet — from a perspective beyond "my VM gets hacked."

Exercise 2. Explain why Kali gets both NAT + Host-only while MS2 gets only Host-only, from the perspective of the safety structure this asymmetry creates.

Exercise 3. An MS2 fails ping 8.8.8.8 but succeeds ping 192.168.56.1 (the host). What is this VM’s network mode, and why do you judge so?

Exercise 4. Explain why VirtualBox’s Bridged mode must not be used for vulnerable VMs, connecting it to how that mode works.

5. Model Answers & Completion Criteria

Mission Model Answer

Certificate example (for format reference — use your environment’s IPs and times):

[Isolated Lab Verification Certificate]
1. Network configuration
   - Kali: adapter1 NAT / adapter2 Host-only
   - MS2: adapter1 Host-only (no NAT)
2. MS2 lab IP: inet 192.168.56.101/24 (eth0)
3. Kali→MS2: 4 packets transmitted, 4 received, 0% packet loss
4. MS2→8.8.8.8: 3 packets transmitted, 0 received, 100% packet loss
   MS2→google.com: Temporary failure in name resolution
5. Host→MS2: responses received (Host-only working normally)
6. Snapshots: Kali "lab connection complete", MS2 "MS2 clean state" (2026-09-XX)
7. Declaration: I perform no attacks on vulnerable VMs with unverified isolation.

How to verify: ① are the Kali→MS2 success and the MS2→internet failure quoted side by side? ② does the table confirm MS2 has no NAT adapter? ③ is the declaration present?

Exercise Answers

Answer 1. First, if an external attacker who got in uses this VM as a foothold (jump server) to attack third parties, the attack’s source IP becomes your home, potentially leading to legal liability. Second, if exposed on the same network, the vulnerable VM becomes a springboard for attacking the family’s other devices. Third, the records, keys, and scripts you stored while practicing inside the VM leak. The "for practice" tag means nothing to attackers.

Answer 2. Running the lab requires the internet (tool updates, research) — and that need exists only on the attacker’s side (Kali). The target (MS2) has no reason to touch the internet. So Kali gets a dual configuration of NAT (outside) + Host-only (lab), while MS2 gets a single Host-only configuration, physically making the path outside absent. "Guaranteeing the target’s isolation not by settings but by the absence of a connection" is the point of this design.

Answer 3. Host-only mode. Host-only communicates only with the host PC and VMs inside the same virtual LAN, with no internet routing — so 8.8.8.8 (the internet) failing and 192.168.56.1 (the host’s virtual LAN address) succeeding is this mode’s normal behavior.

Answer 4. Bridged mode makes the VM behave like an independent device connected directly to the home network through the host’s physical network card — it receives an IP directly from the router and communicates as a peer with every device on the network. When a vulnerable VM enters this state, it’s no longer "a target inside a lab" but "a hole-riddled server connected to our home network," and depending on router settings it can even lead to external exposure.

Completion Criteria Checklist

  • [ ] I downloaded MS2 and registered it in VirtualBox
  • [ ] I confirmed the Host-only network adapter’s existence and range
  • [ ] I configured Kali with NAT + Host-only, and MS2 with Host-only only
  • [ ] I logged into MS2 as msfadmin/msfadmin and confirmed the lab IP with ip a
  • [ ] I confirmed Kali→MS2 ping succeeds
  • [ ] I confirmed MS2→internet ping fails (100% loss)
  • [ ] I took snapshots of both VMs
  • [ ] Mission: I wrote the isolated lab verification certificate

6. Common Pitfalls & Fixes

Wall 1. MS2 can’t get an IP (no eth0 address in ip a)

Symptom (Screen example): eth0 has no inet line, or it’s in a range other than 192.168.56.x.
Cause: mostly the Host-only network’s DHCP is off, or the adapter isn’t set to Host-only.
Fix: ① in VirtualBox Network Manager, confirm the Host-only adapter’s DHCP server is on. ② In MS2’s Settings → Network, confirm the attachment is exactly that adapter. ③ If it still fails, run sudo /etc/init.d/networking restart in MS2 and recheck ip a.

Wall 2. Ping from Kali to MS2 doesn’t work

Symptom (Screen example): 100% packet loss (in the Kali→MS2 direction).
Three candidate causes: ① Kali’s adapter 2 (Host-only) was added while the VM was running and isn’t recognized. ② The two VMs are looking at different Host-only adapters. ③ MS2 is still booting.
Fix: fully shut down Kali and restart it (adapters are recognized at boot), first check in Kali with ip a that a 192.168.56.x address was assigned, and compare whether both VMs’ Host-only adapter names match.

Wall 3. With Host-only, Kali has no internet

Symptom: ping 8.8.8.8 fails in Kali.
Cause: Kali’s adapter 1 (NAT) is off or missing. Host-only alone having no internet is normal — that’s this mode’s raison d’être.
Fix: confirm the dual configuration in Kali’s Settings → Network: adapter 1 as NAT, adapter 2 as Host-only. It’s common to have overwritten adapter 1 while changing adapter 2 to Host-only.

Wall 4. MS2 login doesn’t work

Symptom: typing msfadmin repeats Login incorrect.
Cause: mostly an input mistake — the Linux console displays nothing on screen for passwords. You think nothing was typed, type again, and get it wrong.
Fix: quietly type the password msfadmin and press Enter. If it still fails, check the keyboard layout (Korean/English state). The MS2 console assumes an English layout.

Wall 5. "Can’t I just briefly connect MS2 to the internet and update it?"

Symptom: MS2 is an old Ubuntu, so you’re tempted to update it.
Cause: a good habit misapplied.
Fix: no — for two reasons. ① MS2’s vulnerabilities are practice assets; patching them makes the targets disappear. ② Updating requires attaching NAT, and in that moment the vulnerable VM is exposed to the internet. "Old and locked in" is MS2’s design intent. Do your updating only on the Kali side.

7. Summary

Today’s Concepts

Concept One-line explanation
Metasploitable2 An Ubuntu-based VM deliberately made vulnerable for practice
Intentionally vulnerable VM The only kind of target that can legally be attacked
Host-only network A virtual LAN communicating only inside the host PC — internet blocked
Isolation verification A procedure proving by experiment (100% loss) that a vulnerable VM is cut off from the outside
Dual adapters Kali: NAT (outside) + Host-only (lab) / MS2: Host-only only — asymmetric design
Lab ethics No attack begins before isolation is verified

Today’s Commands

Command What it does
ip a Check the VM’s IP address (note the lab IP)
ping -c 4 targetIP Confirm in-lab communication (must succeed)
ping -c 3 8.8.8.8 Confirm internet is blocked (must fail)
ping domain Confirm name resolution is blocked (must fail)

An Instinct More Important Than Commands

The message announcing today’s lab completion was, paradoxically, a failure message — 100% packet loss. In security, "proof of not working" is as important as "proof of working," and it can be obtained not by assumption but only by experiment.

The firing range is now complete. On one side, Kali full of tools; on the other, MS2 full of vulnerabilities; between them, a virtual LAN that communicates only inside your PC. And the last wall enclosing the two is not a setting but your rule — unverified isolation, no attacks.

Once every box is checked, Step 112 is complete.

← 이전 스텝
다음 스텝 →