ExamFinch.com My Study

Study guide

7.1 Configuring the Network

Practice this exam

Kali Linux Certified Professional KLCP

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 How to Use This Guide & Study Strategy 1.3 PEN-103 Syllabus & Study Path

2 About Kali Linux

2.1 A Bit of History: From BackTrack to Kali 2.2 Kali's Relationship with Debian 2.3 Purpose and Use Cases 2.4 Main Features and Design Policies

3 Getting Started with Kali Linux

3.1 Downloading and Verifying a Kali ISO 3.2 Booting Kali in Live Mode 3.3 Installation Options Overview 3.4 Troubleshooting Installations

4 Linux Fundamentals

4.1 What Linux Is and What It Does 4.2 The Command Line 4.3 The Filesystem Hierarchy Standard 4.4 Useful Commands: Files, Search, Environment

5 Permissions and Process Management

5.1 File Permissions and Ownership 5.2 Managing Processes 5.3 Shells, Variables, and the Environment

6 Installing Kali Linux

6.1 Minimal Installation Requirements 6.2 Step-by-Step Installation on a Hard Drive 6.3 Unattended Installations with Preseeding 6.4 ARM Installations

7 Configuring the Network, Users, and SSH

7.1 Configuring the Network 7.2 Managing Unix Users and Groups 7.3 Configuring SSH

8 Configuring Services

8.1 Apache Web Server 8.2 PostgreSQL Database 8.3 Managing Services with systemd

9 Helping Yourself and Getting Help

9.1 Documentation Sources 9.2 Kali Linux Communities 9.3 Filing Good Bug Reports

10 Security Policy and Network Services

10.1 Defining a Security Policy 10.2 Possible Security Measures 10.3 Securing Network Services

11 Firewalling and Monitoring

11.1 Netfilter and iptables Behavior 11.2 Writing iptables Rules and NAT 11.3 Monitoring and Logging

12 Debian Package Management: APT

12.1 Introduction to APT 12.2 The sources.list File 12.3 Kali Repositories 12.4 Basic Package Interaction with apt

13 dpkg and Advanced Package Management

13.1 dpkg Fundamentals 13.2 Inspecting .deb Files and Package State 13.3 Maintainer Scripts and Conffiles 13.4 APT Pinning and Package Authenticity

14 Advanced Usage

14.1 Modifying and Rebuilding Kali Packages 14.2 Recompiling the Kernel 14.3 Building Custom Kali Live ISO Images 14.4 USB Persistence with LUKS Encryption

15 Kali Linux in the Enterprise

15.1 Network Installation with PXE Boot 15.2 Configuration Management with SaltStack 15.3 Metapackages and Custom Repositories 15.4 Configuration Packages and Forking

16 Introduction to Security Assessments

16.1 Kali Linux in an Assessment 16.2 Types of Assessments 16.3 Types of Attacks 16.4 Formalization and the Road Ahead

7.1 Configuring the Network

Key Takeaways Explain This Topic AI

NetworkManager manages networking on Kali desktop systems; control it with nmcli or nmtui, while servers often use ifupdown configured in /etc/network/interfaces

Use nmcli device status to list interfaces, nmcli connection up/down <name> to toggle connections, and nmcli connection add with ipv4.method manual to assign a static IP

/etc/resolv.conf holds DNS resolver settings (nameserver lines), but it is often managed by NetworkManager or resolvconf, so edit the managing tool's config instead

hostnamectl set-hostname <name> persistently sets the system hostname by writing /etc/hostname

  • ip addr show , ip route show , and ss -tuln are the modern replacements for ifconfig, route, and netstat
  • Last updated: July 2026

NetworkManager on the Kali Desktop

On a standard Kali desktop installation, networking is handled by NetworkManager , the same service used by most Debian-based desktop distributions. It runs as the NetworkManager.service systemd unit and exposes three interfaces you should know for the exam:

  • nmcli — the command-line tool, scriptable and the most important for the KLCP exam
  • nmtui — a terminal-based menu UI, useful on systems without a desktop
  • The GNOME/Xfce panel applet — the graphical front end in the system tray

Start by inspecting state. nmcli device status lists every network device with its type, state, and active connection profile. nmcli connection show lists saved connection profiles (NetworkManager stores profiles in /etc/NetworkManager/system-connections/ ). A device can be connected , disconnected , or unmanaged ; unmanaged usually means another tool (like ifupdown) claims the interface in /etc/network/interfaces , and NetworkManager deliberately leaves it alone — a classic exam trap when nmcli seems to ignore an interface.

  • Essential nmcli operations: nmcli device status
  • nmcli connection show
  • nmcli connection up "Wired connection 1"
  • nmcli connection down "Wired connection 1"
  • nmcli device wifi list
  • nmcli device wifi connect "SSID" password "secret"
  • Adding a Static IP with nmcli

To create a new Ethernet profile with a static address instead of DHCP: nmcli connection add type ethernet con-name static-eth0 ifname eth0 \

  • ipv4.method manual ipv4.addresses 192.168.1.50/24 \
  • ipv4.gateway 192.168.1.1 ipv4.dns "8.8.8.8 1.1.1.1"
  • nmcli connection up static-eth0

Key point: ipv4.method manual means static, ipv4.method auto means DHCP. To convert an existing profile, modify it instead of recreating it: nmcli connection modify static-eth0 ipv4.method auto switches it back to DHCP. Changes only apply after you bring the connection down and up again.

ifupdown and /etc/network/interfaces

Debian's traditional mechanism is ifupdown , driven by the file /etc/network/interfaces plus drop-in files in /etc/network/interfaces.d/ . Kali installs this file even on desktop systems, usually containing only auto lo and iface lo inet loopback so the loopback interface comes up while NetworkManager handles everything else. On servers or minimal installs without NetworkManager, you configure interfaces directly: auto eth0

  • iface eth0 inet static
  • address 192.168.1.50/24
  • gateway 192.168.1.1
  • dns-nameservers 8.8.8.8 1.1.1.1

For DHCP the stanza shrinks to auto eth0 and iface eth0 inet dhcp . Apply changes with ifup eth0 / ifdown eth0 or systemctl restart networking . The keywords matter: auto brings the interface up at boot, allow-hotplug brings it up when the kernel detects the device, and inet static versus inet dhcp selects the address method.

  • Feature NetworkManager (nmcli) ifupdown (/etc/network/interfaces)
  • Typical use Desktops, laptops, Wi-Fi Servers, minimal installs
  • Config location /etc/NetworkManager/system-connections/ /etc/network/interfaces
  • Control command nmcli / nmtui ifup / ifdown
  • Roaming between networks Yes, automatic No

A critical rule: an interface declared in /etc/network/interfaces is marked unmanaged by NetworkManager. Do not configure the same interface in both systems.

systemd-networkd: the third mechanism

Kali Linux Revealed documents a third option alongside NetworkManager and ifupdown: systemd-networkd , the systemd-native network manager. It is small, scriptable, and not Debian-specific, which makes it the usual choice in containers, cloud images, and headless VMs. Configuration lives in .network files under /etc/systemd/network/ (packaged files in /lib/systemd/network/ ), where a [Match] section selects interfaces and a [Network] section describes the configuration: # /etc/systemd/network/50-static.network

  • [Match]
  • Name=enp2s0
  • [Network]
  • Address=192.168.0.15/24
  • Gateway=192.168.0.1
  • DNS=8.8.8.8

Three exam-relevant caveats: systemd-networkd is disabled by default , so it must be enabled explicitly ( systemctl enable --now systemd-networkd ); DNS integration depends on systemd-resolved , which means replacing /etc/resolv.conf with a symlink to /run/systemd/resolve/resolv.conf ; and it has no built-in Wi-Fi support, so wireless still needs a separate wpa_supplicant configuration.

DHCP vs Static Addressing

DHCP (Dynamic Host Configuration Protocol) leases an address, gateway, and DNS servers automatically — the default for Kali desktop installs and live sessions. Static addressing pins the configuration manually, which you want for machines others must reach reliably: servers, jump boxes, and targets in a lab. On a penetration test you will frequently switch your own machine to a static address on an isolated lab network where no DHCP server exists, so the nmcli connection add ... ipv4.method manual workflow above is practical, not just theoretical.

DNS and /etc/resolv.conf

Name resolution is configured in /etc/resolv.conf , which contains nameserver lines (up to three are used), plus optional search and domain directives: nameserver 8.8.8.8

  • nameserver 1.1.1.1
  • search lab.local

The exam-relevant subtlety: /etc/resolv.conf is frequently a symlink or a generated file rewritten by NetworkManager, resolvconf, or systemd-resolved. Hand-editing it may work until the next DHCP renewal or connection bounce wipes your change. The durable fix is to set DNS where the manager reads it — ipv4.dns in nmcli, or dns-nameservers in an interfaces stanza. The resolver library consults /etc/nsswitch.conf (the hosts: line, normally files dns ) to decide the lookup order: /etc/hosts first, then DNS.

Hostname Management

View and set the hostname with hostnamectl . hostnamectl alone shows the static hostname, chassis, and operating system; hostnamectl set-hostname kali-lab sets it persistently by writing /etc/hostname (and updates the pretty hostname in /etc/machine-info when used with --pretty ). The legacy hostname command changes the name only until reboot. After renaming, check /etc/hosts — you typically want an entry mapping 127.0.1.1 to the new name so local services resolve it.

Diagnostic Commands: ip, route, ss

The net-tools suite (ifconfig, route, netstat) is deprecated upstream but still ships on Kali — the Debian net-tools package carries Priority: important , so it is part of the base system — yet all new work should use the iproute2 replacements:

  • ip addr show (or ip a ) — interfaces and their addresses; ip link set eth0 up toggles link state
  • ip route show (or ip r ) — the routing table; add a default gateway with ip route add default via 192.168.1.1
  • ss -tuln — listening TCP/UDP sockets without name resolution; the modern netstat -tuln
  • ping -c 4 192.168.1.1 and dig example.com / host example.com — connectivity and DNS verification

A standard troubleshooting order: check link and address with ip a , check the gateway with ip r , ping the gateway, ping an external IP, then test DNS with dig . This isolates whether the fault is layer-2, routing, or name resolution.