10.2 Possible Security Measures

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

10.2 Possible Security Measures

Key Takeaways Explain This Topic AI

Reduce attack surface by disabling services with systemctl disable --now (or mask) and removing unneeded packages with apt purge

libpam-pwquality enforces password strength through /etc/security/pwquality.conf options such as minlen, dcredit, ucredit, and retry

fail2ban watches log files and bans offending IPs; the sshd jail is enabled by default on Debian/Kali and inspected with fail2ban-client status sshd

Never edit jail.conf directly — put local overrides in jail.local or a file under jail.d/

On kali-rolling, apt update && apt full-upgrade is itself a security measure, and LUKS full-disk encryption must be chosen at installation time

Last updated: July 2026

10.2 Possible Security Measures

Quick Answer: Once the policy exists, you implement it with concrete measures: disable or uninstall services you do not need, filter traffic with nftables , enforce password quality with libpam-pwquality , rate-limit brute-force attacks with fail2ban , add a second authentication factor, keep the system patched with apt update && apt full-upgrade , and encrypt the disk with LUKS at install time.

Disable or Remove Unneeded Services

Every running service is attack surface. The first hardening step is to enumerate what is active and shut down the rest: systemctl list-units --type=service --state=running

systemctl disable --now apache2
systemctl mask apache2

disable --now stops the service immediately and removes its boot-time symlink; mask goes further by linking the unit to /dev/null so it cannot be started at all, even accidentally or as a dependency of another unit. If you genuinely do not need a package, remove it with apt purge <package> (purge also deletes configuration files, unlike plain remove ). On Kali this matters doubly: with 600+ tools installed, some pull in daemons — know which ones you actually use.

Firewalling

Modern Debian and Kali use nftables (the nft command) as the packet-filtering framework, replacing the older iptables/xtables stack. Inspect the active ruleset with nft list ruleset . A default-deny inbound policy with explicit allows is the classic posture: nft add table inet filter

nft add chain inet filter input { type filter hook input priority 0 \; policy drop \; }
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input iif lo accept

For interactive use many administrators prefer the simpler ufw front end. One exam caution: Kali Linux Revealed teaches the kernel firewall as netfilter , configured from user space with iptables (IPv4) and ip6tables (IPv6). nftables is the modern replacement for that user-space stack — and on current Debian/Kali the iptables command is itself an nft-backed front end — but if a question asks for "Linux's firewall implementation" as the book states it, the answer is netfilter.

Strong Passwords and pwquality

You can enforce password strength with the libpam-pwquality PAM module — install it first ( sudo apt install libpam-pwquality ; it is not part of a default Kali install) and configure it in /etc/security/pwquality.conf . Key options:

Option Effect
minlen=12 Minimum acceptable password length
dcredit=-1 Require at least one digit (negative = required, positive = credit toward length)
ucredit=-1 Require at least one uppercase character
lcredit=-1 Require at least one lowercase character
ocredit=-1 Require at least one non-alphanumeric character
difok=3 At least 3 characters must differ from the old password
retry=3 Prompt up to 3 times before failing
enforce_for_root Apply the policy even when root sets a password

A classic exam trap: by default pwquality checks apply to regular users, but root can override them with a warning — enforce_for_root closes that gap. Even the best pwquality settings cannot rescue the default live-image credentials kali / kali ; change them immediately on any persistent install.

Throttling Brute-Force Attacks with fail2ban

fail2ban monitors log files for repeated authentication failures and dynamically bans the source IP address by inserting firewall rules. It is not part of a default Kali install — the book tells you to run sudo apt update && sudo apt install fail2ban first. Its architecture:

Filters (in /etc/fail2ban/filter.d/ ) define the regular expressions that recognize a failed login in a given service's log.

Jails (in /etc/fail2ban/jail.conf ) pair a filter with a log path, thresholds, and a ban action.

On Debian and Kali, the sshd jail is enabled by default via /etc/fail2ban/jail.d/defaults-debian.conf — most other jails ship disabled.

Never edit jail.conf directly — it is overwritten on package upgrades. Put overrides in /etc/fail2ban/jail.local or a new file under jail.d/ : [DEFAULT]

bantime = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true

Here maxretry failures within findtime trigger a ban lasting bantime . Inspect runtime state with the client tool: fail2ban-client status # lists active jails

fail2ban-client status sshd # shows banned IPs and counters for the sshd jail
fail2ban-client unban 203.0.113.7 # manually lift a ban
Two-Factor Authentication Concepts

Authentication factors fall into three categories: something you know (password), something you have (phone, hardware token), and something you are (fingerprint). Two-factor authentication (2FA) combines two different categories — two passwords are not 2FA. On Linux the common implementation is time-based one-time passwords (TOTP, RFC 6238) through the libpam-google-authenticator PAM module: after enrolling a shared secret into an authenticator app, PAM demands both the password and the six-digit code. Because codes expire every 30 seconds, a captured credential alone becomes useless to a remote attacker.

Patching and Disk Encryption

On a rolling distribution, keeping the system updated is a front-line security measure , not a chore. Use sudo apt update && sudo apt full-upgrade — full-upgrade (not plain upgrade ) is required on kali-rolling because it is allowed to remove packages when dependencies change; apt upgrade will install new packages if a dependency needs them but never removes one, so it holds back every upgrade that would require a removal — reporting them as "The following packages have been kept back" — and leaves the system partially updated. Subscribe to Kali's security announcements so you know which updates are urgent.

Finally, LUKS (Linux Unified Key Setup) full-disk encryption is offered by the Kali installer. It encrypts entire partitions with AES and demands a passphrase at boot, protecting confidentiality if the machine is lost or seized — essential for a laptop carrying client data. The trade-offs: you must choose it at installation time (retrofitting means reinstalling), and every boot requires the passphrase interactively, which complicates unattended or remote reboots. Some installers also offer an encrypted LVM variant; the exam point is that FDE is an install-time decision with a boot-time cost. The book pairs full-disk encryption with two more laptop measures. First, the LUKS nuke password ( cryptsetup-nuke-password ): a second passphrase that, when entered at the boot prompt, destroys every LUKS key slot and makes the disk permanently unrecoverable — protection for a machine that may be seized or confiscated. Second, a VPN kill switch : firewall rules that forbid all outbound traffic except through your VPN, so that when the tunnel drops you notice immediately instead of silently leaking a client's IP addresses over the local network.