Kali Linux Fundamentals and Responsible Security Auditing¶

How it works¶

Kali Linux is a Debian-based distribution that ships with security tooling preinstalled, rather than being a different operating system in any technical sense — everything in this article about Debian's package management, systemd, and general Linux behavior from elsewhere in this handbook applies to Kali unchanged.

Setting up an isolated lab (the only context this article assumes)¶

Before running any of the tools below, set up a network that cannot reach anything outside your control:

# Using VirtualBox as an example. An *internal* network is fully isolated: no route to the
# host, your LAN or the internet. Replace the VM names with your own; the VMs must be powered off.
VBoxManage modifyvm "kali" --nic1 intnet --intnet1 lab-net
VBoxManage modifyvm "metasploitable2" --nic1 intnet --intnet1 lab-net

Both VMs get exactly one adapter, on the internal network, and no NAT or bridged adapter. An internal network has no DHCP server, so give each VM a static address on 192.168.56.0/24 (this article uses 192.168.56.10 for the target and 192.168.56.20 for Kali). This is the only configuration this article's examples assume.

Reconnaissance: nmap¶

nmap -sV 192.168.56.10

Nmap scan report for 192.168.56.10
Host is up (0.00041s latency).
PORT     STATE SERVICE VERSION
21/tcp   open  ftp     vsftpd 2.3.4
22/tcp   open  ssh     OpenSSH 4.7p1 Debian
80/tcp   open  http    Apache httpd 2.2.8

-sV requests version detection — nmap doesn't just report a port is open, it attempts to identify the specific software and version listening, which is what you'd cross-reference against known vulnerabilities next. -sS (SYN scan, needs root) is faster/stealthier than a full TCP connect scan (-sT) because it never completes the TCP handshake.

Vulnerability identification workflow¶

The responsible workflow is: identify a service and version (nmap -sV) → check whether that specific version has known, documented vulnerabilities (via the service's own changelog, CVE databases, or searchsploit locally) → do not run exploitation tooling against anything you haven't confirmed both the version match and your authorization for.

searchsploit vsftpd 2.3.4

searchsploit searches a local, offline copy of the Exploit-DB database by software name/version — useful for identifying that a known issue exists without needing network access to a vulnerability database (and without alerting any monitoring on a target you're authorized to exploit for a real engagement).

Web application scanning: nikto¶

nikto -h http://192.168.56.10

Flags a web server for known misconfigurations, outdated software signatures, and missing security headers. Like nmap, this is reconnaissance, not exploitation — it tells you what's potentially wrong, which you then verify manually before concluding anything.

Ubuntu/Debian vs. RHEL-family differences¶

Not directly applicable — Kali is itself Debian-based. The tools covered here (nmap, nikto, searchsploit) are also installable on any distribution via their own package managers; Kali's value is having them preinstalled, curated, and kept current as a set, not unique availability.

Practical exercise¶

1. Build the isolated lab network described above.
2. Deploy a deliberately vulnerable practice VM (Metasploitable2 is the standard choice for learning — it's designed to be broken into, in an isolated network only).
3. Run nmap -sV against it and identify at least three distinct services with their versions.
4. For one identified service, use searchsploit to check whether known issues exist for that exact version, without running any exploit module yet.

How to verify you did it correctly¶

• nmap -sV should return a clean service/version table matching Metasploitable2's known, documented set of intentionally-vulnerable services.
• searchsploit <service> <version> should return at least one matching result for the well-known vulnerable versions shipped in Metasploitable2 (this VM exists specifically to have discoverable, well-documented issues for training).

Common mistakes¶

• Running any scan against a real IP address instead of your lab's isolated subnet, because of a typo'd target or a misconfigured "host-only" network that's actually bridged. Double-check ip -br addr show on the Kali VM itself confirms it's only on the isolated lab subnet before running anything.
• Treating a vulnerability scanner's findings as confirmed facts without manual verification — automated tools produce false positives, and reporting unverified findings (in a real, authorized engagement) damages your credibility with the client.
• Skipping the authorization step entirely "just to practice" against a real site you don't own, reasoning that a read-only scan is harmless. It usually isn't legally harmless, regardless of technical intent.

⚠ Dangerous commands / legal warnings¶

• Do not run any tool from this article against an IP address or domain you do not own or have explicit written authorization to test. This is a legal boundary, not merely a best practice — computer-crime statutes in most countries (the U.S. Computer Fraud and Abuse Act, the UK Computer Misuse Act, and equivalents elsewhere) do not require "intent to cause damage" to constitute an offense; unauthorized access attempts alone are frequently sufficient.
• Exploitation frameworks (Metasploit and similar) are entirely out of scope for this introductory article precisely because running them safely and legally requires an engagement-specific understanding of authorized scope that no generic wiki page can responsibly substitute for.

Related articles¶

• Linux Firewall with nftables and iptables
• SSH Hardening and Key-Based Authentication
• TCP/IP Networking and the ip Command Suite

Review questions¶

1. Why is "I only ran a port scan, I didn't access anything" not a reliable legal defense in most jurisdictions?
2. What's the difference between what nmap -sS and nmap -sT each do at the TCP level, and why does it matter for stealth?
3. Why is "the scanner flagged it" not sufficient to report a finding as confirmed in a real engagement?
4. What specific network configuration mistake would cause a "lab-only" exercise to accidentally target real, external infrastructure?