110.2 Setup Host Security

Weight: 3

Goal: Know how to set up a basic level of host security.

This objective is about hardening a single Linux machine — turning off what shouldn’t be on, protecting passwords, and choosing the right authentication mechanism.


1. Use a Shadow Password Suite

Old Unix stored password hashes in the world-readable /etc/passwd. Anyone could read them and run an offline cracker. The shadow password suite moves the hashes to /etc/shadow, which is readable only by root.

You have already met these files in 107.1. For 110.2 the key facts are:

On any modern Linux, the shadow suite is on by default. The relevant administrative commands:

Command What it does
pwconv Convert from /etc/passwd to /etc/passwd + /etc/shadow (turn on shadow).
pwunconv Reverse: move hashes back into /etc/passwd (turn off shadow — almost never done).
grpconv Same idea for /etc/group/etc/gshadow.
grpunconv Reverse for groups.

You should never need to run these on a real system, but they appear on the exam.


2. Disable Unneeded Services

The fewer services that run, the smaller the attack surface. The procedure is the same regardless of distribution:

systemctl list-units --type=service --state=running    # what is running
systemctl list-unit-files --state=enabled              # what starts at boot

systemctl stop SERVICE                                  # stop now
systemctl disable SERVICE                               # don't start at boot
systemctl disable --now SERVICE                         # both in one command

systemctl mask SERVICE                                  # forcibly prevent starting
                                                        # (even by dependency)
systemctl unmask SERVICE                                # undo masking

mask is stronger than disable: a masked unit cannot be started at all, even by another service that depends on it.

On older or non-systemd systems

You should recognize these from older systems but systemctl is the modern reference.

inetd and xinetd (legacy superservers)

Historically, inetd or xinetd ran in the background and listened on many ports, starting the actual service only when a connection came in. This saved resources but is largely obsolete — most services now run standalone or under systemd socket activation.

Files to recognize:

For the exam: know that they exist, that disabling a service means commenting it out (inetd) or setting disable = yes (xinetd), and that they have been replaced by systemd socket units on most modern distros.


3. Limiting Root Logins

A few practical hardening choices for the root account:

/etc/securetty

Lists the terminals on which root may log in directly. If a tty is not listed here, root cannot log into it via the local login program. A common setup limits root to physical consoles only:

console
tty1
tty2
tty3
tty4
tty5
tty6

Removing entries (or emptying the file) prevents direct root login on those terminals — administrators must log in as themselves and use su or sudo.

/etc/nologin

If this file exists, only root may log in. Useful right before shutdown or during maintenance. Its contents are shown to users whose login is refused.

Disabling root SSH login

In /etc/ssh/sshd_config, set:

PermitRootLogin no

Force admins to log in as themselves and use sudo. (More on SSH in 110.3.)

Empty passwords

The default PAM and SSH configurations forbid empty passwords. Keep it that way:


4. Password Aging (Quick Recap)

Already covered in 107.1, summarised here because it’s a host-security task:

chage -l alice                    # show aging info
chage -M 90 alice                 # password must be changed every 90 days
chage -m 7 alice                  # min days between changes
chage -W 14 alice                 # warn 14 days before expiry
chage -I 30 alice                 # disable 30 days after expiry
chage -E 2026-12-31 alice         # account expiration
chage -d 0 alice                  # force change at next login

System-wide defaults live in /etc/login.defs (PASS_MAX_DAYS, PASS_MIN_DAYS, PASS_WARN_AGE).


5. PAM and Password Policy (Awareness)

PAM (Pluggable Authentication Modules) is the framework that handles authentication on Linux. You don’t need to write PAM rules for this objective, but you should recognize:

That set of names is the level the exam expects.


6. NIS — Network Information Service (Awareness)

NIS (Network Information Service), originally called YP (Yellow Pages), is an old Sun-developed system for centralized account databases on a LAN. It distributes /etc/passwd, /etc/group, and similar files to many clients from a master server.

For the exam, recognize:

Don’t deploy NIS on a new system today — but expect to see it referenced.


7. Be Aware of TCP Wrappers

Covered in 110.1; mentioned again here because it’s part of host-security history.


8. A Brief Word on Firewalls

The 110.2 objective mentions awareness of firewalls — full detail is in objective 110.3 / advanced. The point here is that disabling unused services plus a firewall on the host is the standard belt-and-braces for host security.

You should recognize at least:

A simple default policy: drop everything inbound, allow ESTABLISHED, allow SSH.


9. Find and Remove Suspect Files

Recap from 110.1: the things you check during a host-security review.

# Unowned files (orphaned UID/GID)
find / -nouser 2>/dev/null
find / -nogroup 2>/dev/null

# World-writable files
find / -type f -perm -002 2>/dev/null

# SUID and SGID
find / -perm -4000 -type f 2>/dev/null
find / -perm -2000 -type f 2>/dev/null

# Recently modified system binaries
find /usr/bin -mtime -1

10. Information Sources for Security Updates

The objective explicitly mentions being aware of security alerts and best practices. Recognize at least:

In practice, the system administrator subscribes to the distribution’s security mailing list and applies updates promptly.


11. Quick Reference for the Exam

Concepts:

Commands:

Files:


12. Likely Exam Questions (Self-Check)

  1. What is the purpose of the shadow password suite? To move encrypted password hashes from the world-readable /etc/passwd into /etc/shadow, which only root can read.

  2. What commands convert a system to and from the shadow password suite? pwconv enables shadow; pwunconv reverses it. Group equivalents are grpconv / grpunconv.

  3. What file lists the terminals on which root may log in? /etc/securetty.

  4. What does the existence of /etc/nologin cause? Prevents all non-root users from logging in; its contents are shown to them.

  5. What does systemctl mask SERVICE do that disable doesn’t? mask makes the unit impossible to start — even by another service that depends on it. disable only stops it from starting at boot; another unit may still pull it in.

  6. How do you disable a service in xinetd? Set disable = yes in the service’s file under /etc/xinetd.d/ and reload xinetd.

  7. How do you disable a service in classic inetd? Comment out (#) its line in /etc/inetd.conf and reload inetd.

  8. Where do you turn off direct root login over SSH? In /etc/ssh/sshd_config, set PermitRootLogin no.

  9. What file holds the system-wide defaults for password aging? /etc/login.defs — keys like PASS_MAX_DAYS, PASS_MIN_DAYS, PASS_WARN_AGE.

  10. What is the role of PAM? A modular framework that handles authentication and related policies (password quality, account locking, resource limits) for system services. Configured under /etc/pam.d/.

  11. What is NIS, and why is it considered obsolete? Network Information Service — a centralized account-distribution system, predecessor to LDAP. It is insecure (essentially unencrypted) and has been replaced by LDAP and similar.

  12. What is a CVE? A Common Vulnerabilities and Exposures identifier — a unique label (CVE-YYYY-NNNNN) for a publicly known security flaw.

  13. What is CERT? A Computer Emergency Response Team — an organization that coordinates vulnerability reports and responses. The original is CERT/CC at Carnegie Mellon.

  14. A user has an empty password field in /etc/shadow. What is wrong, and how do you fix it? No password is required to log in as this user. Set a password with passwd USER, or lock the account with passwd -l USER while you investigate.

  15. What is the order of evaluation between /etc/hosts.allow and /etc/hosts.deny? hosts.allow is consulted first; a matching rule there grants access. Otherwise hosts.deny is consulted. If neither file matches, the connection is allowed.