← Learning Log

Learning Log

Session 6: Networking Fundamentals — Part 2

Tutor-led demonstration of a small VirtualBox security lab: Kali Linux and Metasploitable networking, interface inspection with ifconfig, Nmap service and version detection, and researching detected versions.

Topics covered 9

Session type: Tutor-led learning
Topic: Networking Fundamentals — Part 2

Session overview

This session moved from networking theory to a small virtual lab. The tutor showed how to network two virtual machines in VirtualBox so that one can be used to examine the other: Kali Linux, a Linux distribution that bundles security-testing tools, and Metasploitable, a machine that is deliberately vulnerable so that people can practise on it safely.

The tutor then inspected each machine’s network interfaces, ran a service and version scan from Kali against Metasploitable, and explained how the scan results can lead into researching known vulnerabilities.

This entry records what the tutor configured and demonstrated. It does not record that I configured these machines, ran these commands or completed a lab myself. Boxes labelled Supplementary explanation are my own additions to make the demonstration understandable; they are not the tutor’s words. How this entry was put together gives the evidence details.

Previous entry: Session 5: Networking Fundamentals — Part 1.

1. Virtual machines and VirtualBox

The demonstration used VirtualBox to run both machines on one computer, and the tutor set each machine’s virtual network adapters to particular network modes.

A virtual machine (VM) is a software-defined computer running inside a physical host. It has virtual hardware, including virtual network adapters, and its own operating system. A hypervisor is the software that creates and manages virtual machines, including the virtual networks their adapters connect to. VirtualBox is a hypervisor that runs as an application on a desktop operating system.

Each virtual network adapter is attached to a network mode, and the mode decides what that adapter can reach. Virtual Machines explains hosts, hypervisors and guests from the beginning.

2. Kali Linux: two adapters

The tutor configured the Kali Linux VM with two network adapters:

AdapterModePurpose explained
Adapter 1NATGives Kali internet access
Adapter 2Host-only AdapterLets Kali communicate with the local lab and its target VM

NAT (Network Address Translation) mode lets the VM start connections out to the internet through the host computer’s own connection. Host-only mode connects the VM to a small virtual network shared with the host and any other VMs attached to it.

3. Metasploitable: host-only only

The Metasploitable VM had one network adapter, set to Host-only Adapter. It had no NAT adapter and no other adapter facing the internet.

The lab topology demonstrated in Session 6

Original diagram of the adapter settings the tutor configured. It shows which networks each VM is attached to, not any addresses, which were not recorded.

  1. Internet

    Reached through the host computer’s own connection

  2. Kali Linux VM

    Security-testing machine

    • Adapter 1NATInternet access
    • Adapter 2Host-onlyReaches the lab network
  3. Host-only network

    The isolated local lab network: the host and the VMs attached to it

  4. Metasploitable VM

    Deliberately vulnerable target

    No NAT or bridged adapter, so no direct path to the internet

    • Adapter 1Host-onlyLab network only

Supplementary note: having two adapters does not turn Kali into a router between them. Kali reaches the internet through NAT and the lab through host-only; Metasploitable only reaches the lab.

  • Kali may need the internet for legitimate reasons, such as installing updates or reading documentation, while also needing to reach the lab.
  • Metasploitable is deliberately vulnerable. It should stay isolated from the internet and from any wider, untrusted network, so that its weaknesses cannot be reached from outside the lab or used against other systems.
  • Host-only gives the two machines a shared network without placing Metasploitable on the internet or on the host’s real network.
  • NAT lets a VM start outbound connections, but systems on the internet do not normally get a direct inbound path to it just because NAT is enabled. Port-forwarding rules can change that.
  • Host-only reduces what can reach Metasploitable, but it is not total isolation: the host and any other VM attached to the same host-only network can still reach it, and extra adapters or host settings can change its reach.
  • A VM with a NAT adapter and a host-only adapter does not automatically forward traffic between the two networks. Forwarding would have to be deliberately enabled and configured.
  • A two-VM security lab develops these points.

4. Logging in to Metasploitable

The tutor logged in to Metasploitable with the username msfadmin and the password msfadmin. These are the machine’s known default credentials: it is a training target, and its weak defaults are part of what makes it deliberately vulnerable.

This is not an example to copy. On any real system, default and easily guessed passwords are themselves a vulnerability, and they are one reason Metasploitable must stay isolated.

5. Inspecting interfaces with ifconfig

The tutor ran ifconfig on Kali Linux and then on Metasploitable. ifconfig is a Linux utility for viewing, and configuring, network interfaces. Here it was used to:

  • view each machine’s network interfaces;
  • identify the IPv4 address assigned to each interface;
  • confirm that both machines were connected to the intended lab network.

The addresses shown in the demonstration are not recorded here.

An IP address identifies a device on a network, so the scan in section 7 needs Metasploitable’s address on the host-only network. Kali shows more than one interface, because it has two adapters. My inference from the topology is that the interface to use is the one on the host-only network, not the NAT one.

Modern Linux distributions often use the ip command suite instead, such as ip addr to list interfaces and their addresses. The session used ifconfig; ip addr is later Study Guide context, not something demonstrated in class. Linux: ifconfig compares them.

6. The security-testing machine and the target

The tutor described Kali Linux as the attacking machine and Metasploitable as the victim. In professional terms, Kali is the security-testing machine and Metasploitable is the deliberately vulnerable, authorised lab target: a machine built to be examined in a lab.

7. Service and version detection with Nmap

From Kali, the tutor ran:

nmap -sV <metasploitable-ip>
  • nmap is a tool for network and service discovery: finding which hosts respond and which ports and services they expose.
  • -sV asks Nmap to attempt service and version detection: to identify which service is behind each discovered port and, where possible, its version.
  • <metasploitable-ip> stands for the Metasploitable VM’s address on the lab network, as found with ifconfig. It is a placeholder, not a real address.

The ports, services and versions reported in the demonstration are not recorded in this entry.

A port is a numbered endpoint that lets one device offer several network services at once. A service is a program listening on a port and responding to requests, such as a web or file-transfer server.

  • Discovery is not exploitation. Finding hosts, ports, services and versions is reconnaissance. Exploitation means actively trying to use a weakness to access, change or affect a target, which is a separate step.
  • Version results are evidence, not guarantees. Nmap works out versions from how a service responds, so a result can be incomplete or wrong.
  • Scanning needs authorisation. Only scan systems you own or are explicitly authorised to test. Metasploitable in an isolated lab is a suitable target; other people’s systems are not. Ethics, Authorisation and Responsible Disclosure explains why.

8. From versions to vulnerability research

The tutor explained that once the Nmap scan has identified services and their versions, the learner can research those versions online for known vulnerabilities.

  1. Identify an exposed service.
  2. Identify the observed version where possible.
  3. Research trustworthy vulnerability information, such as CVE records, the NVD and the vendor’s own security advisories.
  4. Compare the product, version and configuration details with what you actually observed.
  5. Decide whether the vulnerability really applies, does not apply or is still uncertain.
  6. Keep any active testing within authorised scope.

A detected version is a lead, not proof that the target is vulnerable. A CVE for a similar product or version is not proof either. Service Discovery and Vulnerability Research explains why.

9. Using AI to plan a lab

The tutor suggested that AI could be used to create a step-by-step guide for building a similar lab. This was a suggestion for future study; I have not created or followed such a guide as part of this session.

The Study Guide now includes an instructional guided lab based on the concepts demonstrated here. It is a plan for future authorised practice, not a record of completed work.

Session reflection

Session 5 explained how addresses, ports and protocols work. This session showed them in use: a lab designed with a clear boundary, addresses read from each machine’s interfaces, and a scan that turns ports into named services and versions.

The part I most want to remember is the order of the work. Discovery tells you what is there; research tells you what might be wrong with it; and neither gives permission to go further. A lab like this is useful precisely because it provides a safe, authorised target.

Further revision

  • Explain why Kali had a NAT adapter and a host-only adapter, while Metasploitable had only a host-only adapter.
  • Describe what ifconfig was used for, and which interface identifies each machine on the lab network.
  • Explain what nmap -sV does, and why its results need interpreting.
  • Explain why a detected version or a matching CVE is a lead rather than proof.

Learning-only questions on these points are embedded in Virtual Machines, Inspecting Network Configuration and Service Discovery and Vulnerability Research. Related flashcards are in the Study & Revision topics. Where items go beyond the demonstration, they name the Study Guide as the source. They reproduce no addresses or scan output, and answering them is not evidence of completed lab work.

How this entry was put together

  • Tutor-demonstrated material: the VirtualBox adapter settings for Kali Linux (NAT and host-only) and Metasploitable (host-only only), the msfadmin login, ifconfig on both machines, the attacker and victim roles, nmap -sV against the Metasploitable lab address, researching detected versions for known vulnerabilities, and the suggestion to use AI to create a lab guide.
  • Supplementary explanations: everything in the boxes labelled Supplementary explanation is my own explanation, checked against standard references, and is not attributed to the tutor. That includes the beginner VM, hypervisor, port and service definitions, the NAT and host-only detail, why the topology makes sense and its limits, the inference about which Kali interface to use, the discovery and authorisation notes and the research workflow. The note on the diagram is also supplementary. The mention of ip addr is Study Guide context.
  • Not recorded: IP addresses, interface names, ifconfig output, the ports, services and versions shown by the scan, any specific vulnerability, and any exploitation. Nothing in this entry should be read as scan results.
  • Original diagram: the lab topology diagram is my own and does not reproduce the tutor’s screenshots or training materials.
  • No completed lab work: this entry records a demonstration. It is not evidence that I configured the VMs, ran the scan or completed a lab.

Next steps: work through the Study Guide lessons linked above, and complete the guided lab only in an isolated environment I control, recording the work separately if and when it is done.