Month 5: Walls, doors and keys

One engine, many dashboards

Netfilter is the packet-filtering framework inside the kernel: hooks where packets are inspected, changed or dropped. You don't talk to it directly. iptables is the classic tool (chains INPUT, OUTPUT, FORWARD in tables like filter and nat). nftables (the nft command) is its modern replacement, with one syntax for IPv4 and IPv6 and built-in sets. ipset stores big lists of addresses that iptables rules can match in one step. firewalld and ufw are friendlier front ends that write the rules for you.

Exam tip Use ONE front end per host. Mixing hand-made iptables rules with firewalld causes surprises.

Stateful vs stateless

A stateful firewall tracks connections (conntrack). Allow the incoming SSH connection once, and its replies are let through automatically as ESTABLISHED traffic. A stateless filter judges each packet on its own, so you need rules for both directions and the return ports. firewalld, ufw and typical nftables rules are stateful.

# nftables, stateful core
ct state established,related accept
tcp dport 22 accept
drop

Address translation and forwarding

NAT rewrites addresses as packets pass. SNAT changes the source: inside hosts reach out using the gateway's address (masquerade is SNAT for a changing address). PAT (port address translation) lets many hosts share one address by tracking ports. DNAT changes the destination: port forwarding to an inside server. A Linux box only routes or NATs between interfaces if net.ipv4.ip_forward = 1 (sysctl -w now, /etc/sysctl.d/ for good).

Exam tip NAT gateway not passing traffic? Check ip_forward first. It's 0 by default.

firewalld: zones and services

firewalld groups rules into zones (public, internal, trusted, dmz, drop, block...). Each interface or source network belongs to one zone, and the zone says what's allowed. You can allow a service (a named definition like http, which knows its ports) or a raw port (8080/tcp). Services are self-documenting; ports cover anything else.

$ firewall-cmd --get-active-zones
$ firewall-cmd --zone=public --list-all
$ firewall-cmd --permanent \
    --zone=public --add-service=https
$ firewall-cmd --permanent \
    --add-port=8080/tcp
$ firewall-cmd --reload

Runtime vs permanent

firewalld keeps two configurations. Runtime changes (no --permanent) take effect at once but vanish at the next reload or reboot. Permanent changes (--permanent) are saved but do nothing until a reload. Either add --permanent then --reload, or test in runtime and save it all with --runtime-to-permanent.

Sam: Runtime is a sticky note. Permanent is the rulebook. Reload reads the rulebook again.

Exam tip Rule works today, gone after reboot? It was runtime only.

Rich rules

For anything finer than 'open this port to everyone', use a rich rule: source addresses, ports or services, an action, plus optional logging and rate limits.

firewall-cmd --permanent --add-rich-rule=
 'rule family="ipv4"
  source address="10.10.8.0/24"
  port port="5432" protocol="tcp"
  accept'

Exam tip Rich rules = who + what + action. Zones by source address are another way to do the same.

ufw: Ubuntu's simple firewall

ufw (Uncomplicated Firewall) takes plain commands. Like firewalld, it accepts service names (from /etc/services or app profiles) or ports. Allow SSH BEFORE you enable it on a remote server.

ufw default deny incoming
ufw allow ssh            # service
ufw allow 8080/tcp       # port
ufw allow from 10.10.8.0/24 \
  to any port 5432 proto tcp
ufw enable
ufw status numbered

Exam tip ufw delete 3 removes rule number 3 from ufw status numbered.

sudoers, safely

sudo rules live in /etc/sudoers and drop-in files in /etc/sudoers.d/. Always edit with visudo (visudo -f /etc/sudoers.d/rosa for a drop-in): it checks the syntax before saving, because a broken sudoers file can lock everyone out of sudo. A rule reads: who, on which hosts, = (as whom), which commands.

# /etc/sudoers.d/warehouse
rosa ALL=(root) /usr/bin/systemctl \
    restart label-print
%wheel ALL=(ALL) ALL

Exam tip Give the exact command, with a full path. "rosa ALL=(ALL) ALL" is full root.

wheel, sudo, NOPASSWD and NOEXEC

Members of wheel (RHEL family) or sudo (Debian/Ubuntu) get full sudo by default; add admins with usermod -aG. NOPASSWD: skips the password: fine for one narrow automation command, risky on broad rules, because malware or anyone at an unlocked session gets root silently. NOEXEC: stops an allowed program from starting other programs, which blocks shell escapes like :!sh from vi or less.

Exam tip NOPASSWD on ALL = root for anyone who reaches that account. Keep it to specific commands.

sudo -i vs su -

sudo -i opens a root login shell using YOUR password and your sudo rights, and it's logged. su - switches to root with a full login environment, but needs ROOT's password, which then has to be shared. Plain su (no dash) keeps your environment, PATH included. Prefer sudo: per-person accountability and per-command limits.

Exam tip The dash matters: su - loads root's login environment; su alone doesn't.

Keys instead of passwords

Key authentication uses a key pair: the private key stays on your machine (protected by a passphrase), and the public key goes into ~/.ssh/authorized_keys on the server. Nothing guessable crosses the network, so brute force is pointless. Once keys work, set PasswordAuthentication no. An SSH agent (ssh-agent, ssh-add) holds your unlocked key in memory so you type the passphrase once per session.

$ ssh-keygen -t ed25519
$ ssh-copy-id sam@db01
$ ssh-add          # load into the agent

Exam tip If ~/.ssh or authorized_keys is writable by group or others, sshd ignores the key. 700 and 600 are the safe modes.

sshd_config hardening

Settings in /etc/ssh/sshd_config (or sshd_config.d/*.conf):

• PermitRootLogin no: log in as yourself, then sudo
• AllowUsers / AllowGroups: only these may log in at all
• X11Forwarding no: disable X forwarding on servers that need no GUI

PermitRootLogin no
PasswordAuthentication no
AllowGroups sshusers admins
X11Forwarding no

$ sudo sshd -t       # test syntax
$ sudo systemctl reload sshd

Exam tip Keep your current session open while you test a new one. A typo can lock you out.

Tunnels, SFTP, chroot and fail2ban

SSH tunneling carries other traffic inside SSH: ssh -L 5432:localhost:5432 db01 makes the remote database reachable on your local port 5432 (-R is the reverse, -D a SOCKS proxy). SFTP moves files over SSH. A chroot jail (ChrootDirectory with ForceCommand internal-sftp) traps an SFTP-only user in one directory, which must be owned by root. fail2ban watches logs and bans IPs in the firewall after repeated failures.

Exam tip A partner who only uploads price lists gets SFTP + chroot, not a shell.

Retire the cleartext protocols

Telnet (23) sends everything, passwords included, in clear text: use SSH. FTP (21) does the same: use SFTP (or FTPS). TFTP (69) has no authentication at all: keep it to isolated PXE install networks. Remove the server packages, don't just stop them.

Exam tip On the exam, Telnet, FTP and TFTP are the "replace me" answers.

Disable unused filesystems

Every filesystem driver the kernel can load is code an attacker might exploit, for example through a crafted USB stick. Hardening guides block rarely used ones (cramfs, freevxfs, hfs, udf...) with a modprobe.d file so they can't load.

# /etc/modprobe.d/cis-fs.conf
install cramfs /bin/false
blacklist cramfs
install udf /bin/false
blacklist udf

Exam tip blacklist alone only stops automatic loading. install ... /bin/false stops explicit loading too.

Secure boot

UEFI Secure Boot checks signatures from the firmware up: the firmware verifies the signed shim, the shim verifies GRUB, and GRUB verifies the kernel, which then checks modules. Bootkits and tampered kernels are refused. Check with mokutil --sb-state. A self-built or third-party kernel module must be signed with a key enrolled as a MOK (machine owner key), or it won't load.

Exam tip Vendor driver won't load only on Secure Boot machines? It's unsigned. Sign it and enroll the key.

Zones and rules

firewalld groups rules into zones (public, internal, trusted, drop...). Each interface belongs to a zone.

• firewall-cmd --state, --get-active-zones
• firewall-cmd --list-all (default zone) or --zone=public --list-all
• firewall-cmd --add-service=https --permanent
• firewall-cmd --add-port=8443/tcp --permanent
• firewall-cmd --reload to apply permanent changes
• --add-rich-rule for source-specific rules

Two configurations

Without --permanent, a change is runtime only: active immediately but lost on reload or reboot. With --permanent it's saved but not active until --reload.

• Test first at runtime, then make it permanent: firewall-cmd --runtime-to-permanent
• Or add both: run the command once with --permanent and once without, or --permanent then --reload

Exam tip Rule works now but disappears after reboot: you forgot --permanent. Rule saved but not working: you forgot --reload.

Two ways to open traffic

--add-service=http uses a named service definition (XML files in /usr/lib/firewalld/services/) that can include several ports and helpers. --add-port=8080/tcp opens a raw port. Prefer services for standard software (clearer, maintained by the package); use ports for custom apps.

Basics

ufw keeps firewall rules simple on Ubuntu:

• ufw enable, ufw status verbose
• ufw allow 22/tcp (port) or ufw allow OpenSSH (application profile, like a service; list with ufw app list)
• ufw allow from 10.0.0.0/24 to any port 5432
• ufw deny 23, ufw delete allow 80
• Default policy: ufw default deny incoming

Exam tip Allow SSH before you enable ufw on a remote server or you'll lock yourself out.

The layers

iptables is the classic tool for Netfilter rules (tables like filter and nat; chains INPUT, OUTPUT, FORWARD). nftables (nft) is its modern replacement with one syntax for IPv4/IPv6 and better performance; current firewalld and ufw use it underneath. ipset stores large lists of addresses/networks that one rule can match (block thousands of IPs efficiently).

• iptables -L -n -v; iptables -A INPUT -p tcp --dport 22 -j ACCEPT
• nft list ruleset
• ipset create blocklist hash:ip; ipset add blocklist 203.0.113.9; iptables -A INPUT -m set --match-set blocklist src -j DROP

Don't mix them

Use one management tool. If firewalld is running, adding raw iptables rules by hand can be overwritten or conflict.

What it is

Netfilter is the framework inside the Linux kernel that inspects packets at hooks (prerouting, input, forward, output, postrouting). iptables, nftables, firewalld and ufw are all user-space tools that load rules into Netfilter. Connection tracking (conntrack) is part of it and enables stateful rules and NAT.

The terms

Address translation comes in several flavors:

• NAT: rewriting IP addresses as packets pass through a router
• SNAT (source NAT): change the source address of outgoing traffic, so private hosts reach the internet with the router's public IP. Masquerade is SNAT that uses whatever the interface's current IP is
• DNAT (destination NAT): change the destination, for port forwarding a public port to an internal server
• PAT (port address translation, NAT overload): many internal hosts share one public IP, told apart by port numbers

On Linux

Enable forwarding with sysctl net.ipv4.ip_forward=1. firewalld: --add-masquerade, --add-forward-port=port=80:proto=tcp:toaddr=10.0.0.5.

The difference

A stateful firewall tracks connections: once an outgoing connection is allowed, the replies are allowed automatically (rule: ESTABLISHED,RELATED accept). A stateless firewall judges each packet alone, so you must write rules for return traffic too. Netfilter with conntrack is stateful; firewalld and ufw rules are stateful.

Attributes beyond permissions

ext4 and XFS support extra attributes that even root must remove before acting. lsattr file shows them; chattr +i file sets, chattr -i file removes.

Exam tip rm says 'Operation not permitted' even as root: check lsattr for i or a.

The two that matter

Two attributes are tested most often:

• i (immutable): can't be modified, deleted, renamed or linked, even by root, until chattr -i. Protects critical configs
• a (append only): data can only be added to the end, never rewritten or deleted. Good for log files attackers might try to clean

Reading permissions

-rwxr-x--- = file type, then user, group, other. r=4, w=2, x=1. So rwx=7, r-x=5, ---=0: 750. On a directory, x means you can enter it, r list it, w create/delete files in it.

Changing them

Use chmod for permissions and chown/chgrp for ownership:

• chmod 640 file (octal) or chmod u=rw,g=r,o= file / chmod g+w file (symbolic)
• chmod -R recursive (careful)
• chown alice:web file changes owner and group; chown -R
• chgrp web file changes group only
• umask (e.g. 022) sets default permissions for new files: 666-022 = 644, directories 777-022 = 755

Three special bits

Three extra permission bits change how files and directories behave:

• setuid (SUID, 4000): an executable runs as its owner (e.g. /usr/bin/passwd runs as root). Shown as s in the user x position: -rwsr-xr-x
• setgid (SGID, 2000): on an executable, runs as the group; on a directory, new files inherit the directory's group (shared team folders)
• sticky bit (1000) on a directory: users can delete only their own files (/tmp: drwxrwxrwt)

Setting and auditing

chmod u+s, chmod g+s dir, chmod +t dir, or octal chmod 2775 /srv/team. Find SUID files to audit: find / -perm -4000 -type f 2>/dev/null. Unneeded SUID binaries are a privilege-escalation risk.

Three states

SELinux is always in one of three modes:

• Enforcing: policy is applied; violations are blocked and logged
• Permissive: nothing is blocked, but violations are logged (troubleshooting)
• Disabled: SELinux is off (needs a reboot to change, and a full relabel when turning it back on)

Commands

getenforce shows the mode; setenforce 0/1 switches between permissive and enforcing until reboot; sestatus gives details. The boot-time setting is SELINUX= in /etc/selinux/config.

Exam tip App broken and you suspect SELinux: setenforce 0 briefly. If it works, fix the label/boolean (restorecon, setsebool, semanage) and go back to enforcing. Never leave it disabled.

sshd_config essentials

The SSH server (sshd) is configured in /etc/ssh/sshd_config (and drop-ins in /etc/ssh/sshd_config.d/). Common hardening:

• PermitRootLogin no (or prohibit-password)
• PasswordAuthentication no once keys work
• AllowUsers alice bob / AllowGroups sshusers
• X11Forwarding no, AllowTcpForwarding no if not needed
• MaxAuthTries 3, LoginGraceTime 30
• Change the port only as noise reduction, not real security

Apply safely

Check syntax with sshd -t, then systemctl reload sshd, and keep your current session open while you test a new login. fail2ban bans IPs after repeated failures.

Why keys

Passwords can be guessed or brute-forced. Key-based authentication uses a key pair: the private key stays on your machine (protect it with a passphrase); the public key goes in the server's ~/.ssh/authorized_keys.

• ssh-keygen -t ed25519: make a key pair
• ssh-copy-id user@server: install the public key
• Permissions: ~/.ssh 700, authorized_keys 600 (sshd refuses keys with loose permissions)
• ssh-agent / ssh-add keeps the unlocked key in memory

Then turn passwords off

After confirming key login works, set PasswordAuthentication no (and KbdInteractiveAuthentication no) in sshd_config.

Exam tip Key login refused even though the key is in authorized_keys: check permissions on ~/.ssh and the home directory.

Why turn it off

X11 forwarding lets graphical programs on the server display on your screen through SSH. It also opens a path for a compromised server to interact with your desktop session. Servers rarely need it: set X11Forwarding no in sshd_config and reload sshd.

Why they're unsafe

Telnet (23), FTP (21) and TFTP (69/UDP) send data, and for Telnet/FTP usernames and passwords, in clear text; anyone on the path can read them. TFTP has no authentication at all.

• Telnet → SSH
• FTP → SFTP (over SSH) or FTPS
• TFTP → only where required (PXE boot, network gear) and on isolated networks

Remove them

Uninstall the packages (telnet-server, vsftpd, tftp-server), disable their services/sockets, and close the ports. Check listening services with ss -tulpn.

Shrinking the attack surface

The kernel can load modules for rarely used filesystems (cramfs, freevxfs, hfs, hfsplus, jffs2, udf, squashfs...). Bugs in them have been exploited by mounting crafted images. CIS Benchmarks recommend blocking the ones you don't use:

• Create /etc/modprobe.d/disable-fs.conf with lines like install cramfs /bin/false and blacklist cramfs
• Unload if loaded: modprobe -r cramfs
• Check: lsmod | grep cramfs