Security Administration with Debian GNU/Linux

Planning Disk Layout and Partition Strategy for Security

When you install Debian, the first decision that shapes the security posture of the system is how the disk is partitioned. A single, oversized root partition may look convenient during the installation wizard, but it exposes the machine to a range of risks. If a filesystem on /var becomes corrupted or runs out of space, the entire system can become unstable. Likewise, a full /tmp can lead to denial‑of‑service conditions for services that rely on temporary files. By distributing directories across separate partitions, each with its own mount options, you confine problems to a single area of the disk and limit the attack surface.

Begin by allocating a small partition for the boot loader – usually 512 MiB – and mount it read‑only. Next, create a dedicated /var partition that contains logs, spool files, and package caches. Mount /var with the noexec and nosuid options to prevent execution of binaries from that area and to stop set‑UID programs from running there. For /tmp, a separate 2 GiB partition is often sufficient; enable the tmpfs or the nodev option to reduce device file exploitation.

The /usr hierarchy can benefit from a read‑only mount. Since /usr holds system binaries and libraries that rarely change after installation, mounting it with ro protects the core of the operating system from accidental overwrite or malicious tampering. A separate /home partition keeps user data isolated, and it can be encrypted with LUKS or mounted with nosuid and noexec to deter privilege escalation through user-owned binaries.

When planning space allocation, consider future growth. Over‑allocating to one partition while leaving another starved can force a repartition later, which is risky on a live system. Use tools like fdisk or parted to create partitions, then format them with mkfs.ext4 and apply the desired mount options in /etc/fstab. Example entries:

After mounting, check the integrity of the layout by rebooting and inspecting mount output. The partition scheme should be documented, and a backup strategy should reference the partition table to ensure restores target the correct volumes.

With a thoughtful partition strategy, you create a natural barrier against malware that attempts to traverse the filesystem. Each partition can enforce its own security policies, limiting the spread of a compromise. This approach also eases the application of read‑only or encrypted mounts without having to touch the rest of the system.

Remember that the goal of partitioning is not merely to segregate data but to enforce isolation. By controlling how each part of the filesystem is mounted, you reduce the number of vectors an attacker can exploit. A well‑partitioned Debian system becomes more resilient to accidental damage, deliberate tampering, and even some sophisticated rootkits that rely on writing to predictable locations.

Executing a Minimal, Service‑Focused Debian Installation

The Debian installer is intentionally lightweight, giving administrators the ability to choose exactly what to install. A minimal base system is the foundation of a secure environment: the fewer packages you have, the smaller the attack surface. Begin the installation in the text mode, selecting only the core components. Skip desktop environments, network tools, and unnecessary services that may expose open ports or create additional maintenance burdens.

During the package selection phase, pay close attention to the list of available services. Disable everything that is not essential for your use case – for example, if you plan to run a web server, you may not need the FTP daemon, print spooler, or mail server. Many of these packages install daemons that start automatically, adding to the number of listening sockets and increasing the potential for exploitation.

Once the base system is up, use the package manager to add only the components you truly require. Debian’s package manager, apt, resolves dependencies automatically, ensuring that libraries and runtime components are in place without unnecessary extras. After installation, audit the listening sockets with netstat -tulpn or ss -tulpn to verify that no unexpected services remain active.

It is also wise to configure unattended upgrades early. Debian offers a convenient package, unattended-upgrades, that keeps the system patched without manual intervention. Install it with apt install unattended-upgrades and edit /etc/apt/apt.conf.d/50unattended-upgrades to whitelist security updates. This ensures that critical patches reach the system promptly, reducing the window of vulnerability.

After the minimal install, consider hardening network access. Disable IPv6 if not required, or at least restrict it to a safe interface. Use firewall tools like iptables or ufw to create a default deny policy, allowing only specific ports for the services you intend to expose. The combination of a lean package set and strict firewall rules creates a robust baseline that is easy to maintain and audit.

During the initial setup, also configure the root password securely and create at least one non‑root user with sudo privileges. Use adduser and then add the user to the sudo group. Limit the number of users with administrative access to the minimum necessary. This practice curtails the risk of credential compromise and simplifies auditing of privileged actions.

By following a minimal, service‑focused approach, you eliminate many common vectors that attackers exploit. A smaller install means fewer packages to update, fewer potential bugs, and a simpler configuration to secure. Over time, as you add services, do so incrementally and review the system after each addition to ensure that no unintended ports or daemons appear. This disciplined process helps maintain a stable, secure Debian environment.

Scanning for Vulnerabilities with Nessus and Other Tools

Even a clean, minimal install is not immune to emerging vulnerabilities. A regular security assessment identifies weaknesses before attackers can exploit them. Nessus, a well‑established vulnerability scanner, is available for Debian and supports the full range of UNIX derivatives. It provides up‑to‑date plugin libraries that detect known exploits and misconfigurations, then suggests remediation steps.

Install the Nessus server component with apt install nessusd. The daemon listens on ports 1241 and 3001 for the client, and it requires root privileges to access privileged ports. After installation, run systemctl enable --now nessusd to start the service automatically on boot. Configure a Nessus user with nessus-adduser, supplying a strong password. This user will authenticate the Nessus client.

On the workstation where you will conduct scans, install the client with apt install nessus. Start the client and open the web interface by navigating to https://localhost:8834. The first run will prompt you to create an administrator account; use a distinct, complex password. Once logged in, you can create a new scan by selecting the “Basic Network Scan” template, specifying target IP ranges, and enabling plugins relevant to your environment.

When a scan completes, Nessus presents a detailed report. It lists discovered vulnerabilities, assigns CVSS scores, and, importantly, offers step‑by‑step remediation. For instance, if the scanner flags an outdated SSH daemon, it will suggest updating to the latest package via apt update && apt upgrade ssh. If the scanner finds weak file permissions, it will recommend adjusting chmod or chattr settings.

Besides Nessus, keep in mind other open‑source scanners such as OpenVAS or Lynis. These tools focus on specific areas – OpenVAS for network vulnerability assessment, Lynis for system hardening checks. Combining scans from multiple tools provides a broader view and reduces blind spots.

Schedule regular scans, ideally weekly or monthly, and integrate the findings into your patch management workflow. When a new CVE is discovered, promptly verify whether your system is affected and apply the necessary updates. Maintaining an up‑to‑date vulnerability database is a cornerstone of proactive security; the cost of an unpatched system far outweighs the effort of regular scanning.

Security scanners also serve as a training resource. By reviewing the scan reports, administrators learn which misconfigurations are most common and how to address them. Over time, the knowledge gained reduces the reliance on automated tools, allowing you to detect and fix issues manually with confidence.

In practice, Nessus provides a comprehensive, easy‑to‑use platform for vulnerability assessment on Debian. By integrating it into your security routine, you can keep your system resilient against known threats and maintain a clear record of remedial actions.

Securing File System Permissions, Attributes, and Sticky Bits

File permissions form the first line of defense for any Linux system. The traditional rwx model – read, write, execute – is applied separately to the file owner, the owning group, and all others. View the permission string with ls -l. The first character denotes the file type, followed by three triplets. For example, -rw-r--r-- means the owner can read and write, the group can only read, and others can read as well.

Altering permissions is done with chmod. Use the symbolic syntax to add or remove bits: chmod +x script.sh gives execute permission to all, while chmod g-w file removes write access from the group. For stricter control, use the octal form: chmod 750 file gives owner full access, the group read and execute, and others none. Apply these commands carefully; accidental permission changes can break service functionality or expose sensitive data.

Beyond basic permissions, Debian supports extended attributes via chattr. Marking a file as immutable with chattr +i filename prevents modifications, deletions, or renames, even by root, until the flag is removed. This is useful for critical configuration files like /etc/shadow or system binaries that should not be altered. List attributes with lsattr to verify the current state.

The sticky bit is another tool to protect shared directories. When set on a directory (e.g., chmod +t /tmp), it ensures that only the file owner or root can delete or rename files within that directory, even if others have write permission. This is essential for directories that allow multiple users to create files, preventing accidental or malicious removal of files belonging to other users.

When files or directories are created, the default permission mask – the umask – determines the starting permissions. A typical umask of 022 results in files with 644 and directories with 755. To tighten the default, set umask 077 in a user’s .profile or .bashrc; this will create files with 600 and directories with 700, ensuring that only the owner can read or write them.

Applying these controls consistently across the system reduces the risk of privilege escalation. For example, keeping the /usr directory read‑only prevents users from inserting malicious binaries into the system path. Similarly, securing log directories with noexec and nosuid stops an attacker from executing code from logs or inserting set‑UID wrappers.

Remember to audit permission changes regularly. Use find / -perm /222 to locate world‑writable files or find / -perm -4000 -type f to find set‑UID binaries that might have been added inadvertently. A regular check helps identify drift in configuration and keeps the system aligned with the security baseline.

By mastering permissions, attributes, and the sticky bit, you create a hardened file system. These mechanisms, when applied deliberately, create multiple layers of defense that protect against accidental disclosure and targeted attacks alike.

Implementing Disk Quotas, Resource Limits, and Activity Logging

In a multi‑user environment, the most powerful administrator often unintentionally consumes all disk space, jeopardizing service availability. Disk quotas prevent this by imposing hard limits on how much space a user or group can consume. To enable quotas on a partition, add the usrquota and grpquota options to its entry in /etc/fstab. For example: /dev/sda1 /var ext4 defaults,usrquota,grpquota 0 1. Remount the filesystem or reboot, then initialize the quota database with quotacheck -cum /var. Finally, enable the quota system with quotaon /var. Administrators can edit user limits with edquota -u username, setting soft and hard thresholds for blocks and inodes.

Resource limits complement disk quotas by restricting CPU time, file descriptors, and memory usage per process. The ulimit builtin in the shell configures these limits for the current session; to apply them system‑wide, place ulimit -u 2000 or ulimit -t 300 in /etc/profile so every login shell enforces the rule. For services managed by systemd, create a drop‑in file under /etc/systemd/system/.d/limit.conf and add LimitNOFILE=1024 or CPUQuota=50% to control resource consumption.

Monitoring user activity is vital for detecting compromise. The history file in each user’s home directory logs commands, but it can be tampered with. Tools like snoopy provide kernel‑level logging of executed commands; install it with apt install snoopy and configure the SNOOPY_LOG_FILE environment variable to point to a secure, owned‑by‑root file. This ensures that even if a user removes their shell history, the commands executed will still be recorded.

To find out which processes are using a particular file or socket, fuser or lsof are invaluable. For example, lsof -i :80 lists all processes listening on HTTP. If a port is unexpectedly open, investigate the corresponding PID and terminate the rogue process. Use fuser -k /var/log/syslog to kill all processes that have a file open, which is helpful when unmounting a filesystem that refuses to detach.

Log files themselves need protection. The /var/log/faillog and /var/log/lastlog files store authentication attempts and can reveal brute‑force attacks. Restrict access with chmod 660 /var/log/faillog and chmod 660 /var/log/lastlog, ensuring that only root and the syslog group read them. The /etc/lilo.conf file, which holds boot loader settings, must also be secured: chmod 600 /etc/lilo.conf prevents unauthorized modifications that could alter the boot sequence.

Unnecessary network services should be disabled early on. Use update-inetd -disable time to remove the time daemon from the inetd configuration, then restart the daemon with /etc/init.d/inetd restart. For systemd‑managed services, systemctl disable --now servicename stops and disables the unit. After removal, run ss -tulpn to confirm no lingering sockets remain.

By combining disk quotas, resource limits, meticulous logging, and active service management, you create an environment where abuse is detected, resources are controlled, and the system remains stable. Regular audits of quota usage, ulimit settings, and log integrity will keep the system secure without imposing unnecessary friction on legitimate users.