The previous five lessons have added security measures one at a time: a controlled network, SSH with keys, a firewall, intrusion detection, encrypted secrets and TLS. Each one solved a specific problem. This lesson does something different: it turns them into a security posture, which is a coherent set of decisions justified by an explicit threat model, with a written record of what is protected, what has been consciously accepted and what falls outside an administrator's remit.

The difference is not rhetorical. With no threat model, hardening degenerates into cargo cult: recipes found in guides get applied because they "sound secure", things break without anybody understanding why, and you end up with a fragile system and a false sense of control. With a threat model, every measure has a reason and every omission is a conscious decision.

You also close the third outstanding incident here — the services still using the vulnerable libssl loaded in memory — and settle the debt you left in 05-01: PAM, the subsystem that really decides how somebody authenticates on this system.

Warning up front. Two of the sections in this lesson — PAM and secure mounts — can leave you unable to log in to your own server if you get them wrong. In both cases the safe procedure is given. Do not skip it: the lab exists precisely so that you learn this where mistakes cost nothing.

1. The five principles that order everything so far
2. Tramontana's threat model
3. Reducing the attack surface
4. Hardening accounts and the password policy
5. PAM: how this system really authenticates
6. Mandatory access control with AppArmor
7. Kernel hardening with sysctl
8. Secure mounts
9. Vulnerability management and closing the openssl incident
10. systemd hardening revisited
11. Backups as the last control against ransomware
12. A hardening checklist and maintaining the posture

Everything you have done in this module answers, without our having said so, to five principles. Naming them lets you apply them to new situations instead of repeating recipes:

The hardest to apply in practice is the second, because it requires taking things away, and taking things away is frightening. The most forgotten is the fourth: a lot of "secure" configuration fails open, and that is worse than not having it, because nobody will notice.

A threat model answers three questions. Half a page is enough, and it is the half page that makes everything else make sense.

What are we protecting? Two things, in this order:

1. The guests' personal data (names, dates of stay, amounts in bookings.csv and in the database). Its compromise is harm to third parties, has legal consequences under the GDPR and is irreversible: once leaked, it cannot be "recovered".
2. The availability of the booking service. Its interruption has a direct economic cost, bounded in time.

From whom? Four realistic actors, ordered by likelihood:

Look at the third row. The most likely actor is you, and that observation explains why half a dozen of the course's conventions — copy before editing, verify with diff -u, run a dry run, netplan try with automatic rollback, mount -a before rebooting — are security controls in their own right, and not stylistic fussiness.

What do we assume is out of scope? Saying it is as important as the above, because it delimits what is not being protected:

• A state-resourced attacker or a compromised supply chain. That is beyond any measure an administrator can take on a small company's server.
• Physical access to the machine. LUKS encryption mitigates disk theft, but an attacker with prolonged physical access and the machine powered on owns the system.
• A vulnerability in the application itself (SQL injection, business logic). That is development's responsibility, not administration's, and system hardening only limits the subsequent damage.
• A compromise of the cloud provider or the hypervisor.

And now the underlying criterion: with this model, investing in a NIDS adds little (you already reasoned that in 06-04) and investing in change detection and authentication control adds a great deal. That is making decisions, not following a list.

What does not exist cannot be attacked, needs no patches and appears in no CVE. It is the principle with the best effort-to-result ratio.

Read each line asking "does it have to be there, and on that address?":

• systemd-resolve on 127.0.0.53 and 127.0.0.54: local, correct.
• sshd on 0.0.0.0:22: necessary, and already hardened.
• tramontana on 0.0.0.0:8080: listening on every interface. The firewall blocks it from outside, but that is defence in a single layer. The right thing is for the application to listen only on 127.0.0.1, because when the reverse proxy from 08-01 arrives it will be the one talking to it, and that way the firewall becomes the second line instead of the only one.
• postgres on 10.0.2.15:5432: already restricted to the internal interface. Correct.

The first fix, then:

That is defence in depth applied: it now takes two failures — a badly written firewall rule and a listener that is too broad — to expose 8080. Before, one was enough.

ModemManager manages modems and mobile broadband. On a server virtual machine it makes no sense at all. And here it is worth understanding the difference between the two ways of switching something off, because they are not equivalent:

mask for what must never start; disable for what you might want to start by hand one day. And the next step, when you are sure, is to uninstall the package: a binary that is not on the disk has no vulnerabilities.

On the desktop, to close the section: a graphical environment adds hundreds of packages, an X or Wayland server, a session manager and a browser — each with its own surface and its own patching calendar. srv-tramontana not having one is not austerity, it is the biggest surface reduction you can make on a server, and that is why the Ubuntu Server installer does not offer it by default.

Three audits worth keeping in a script, because they catch serious mistakes and are one line each:

All three results are correct: a single UID 0, no account without a password, and the only two system accounts with a shell are root — needed for recovery — and sync, which is a harmless historical case. The fact that svc-tramontana does not appear in the third list confirms that the -s /usr/sbin/nologin from 05-01 did its job.

The default policy lives in /etc/login.defs, and it affects the accounts created from now on:

PASS_MIN_DAYS 1 is less obvious than the rest: without it, somebody who is required to change their password can change it five times in a row to exhaust the history and go back to the original. It is an old trick and it still works wherever this is not set.

And for the accounts that already exist, chage:

chage -E deserves attention: it is the correct way to manage a temporary account. It expires on its own on the expected date, without depending on somebody remembering to close it — and forgotten leavers are one of the most common routes to compromise there is.

In 05-01 we deferred PAM. Now is the moment, because it is the piece that really decides who gets into this system and on what conditions.

PAM (Pluggable Authentication Modules) is a layer of indirection: the programs that need to authenticate — login, sshd, sudo, su, passwd — do not implement the logic themselves, they ask PAM. That makes it possible to change the policy (demand strong passwords, lock out after failures, add a second factor) without modifying or recompiling any program. It is the reason it exists.

Each service has its file in /etc/pam.d/, and there are common files that the rest include:

Each line has three parts: type, control and module.

The four types, which are four different questions answered at different moments:

Confusing auth with account is the most common misunderstanding: a correct password on an expired account passes auth and fails account.

The controls determine what happens according to the module's result:

required versus requisite has a rationale that is not obvious: required goes on running the stack so as not to reveal at which step it failed. If an attacker could tell "no such user" from "wrong password" by the response time or the message, they would have an oracle for enumerating users.

The modern, more precise syntax uses square brackets: [success=ok default=die] lets you specify the action for each return code. It is what you will see in Ubuntu's files.

Before you touch a single line. A syntax error in common-auth can prevent every login, the local console included, and then the only way out is recovery mode:

1. Leave a root session open in another terminal, and do not close it until you have finished:

   $ sudo -i
   # (do not close this session)
   

2. Copy the file before editing it, following the course's convention:

   $ sudo cp -p /etc/pam.d/common-password /etc/pam.d/common-password.bak-$(date +%F)
   

3. Test in a third terminal, never in the one holding the root session.
4. Keep the VM console to hand and know how to enter recovery mode (covered in depth in 07-01).

It is exactly the same discipline as netplan try and the second SSH session: never close the door you are coming in through.

Two underlying comments. The first: minlen = 12 with minclass = 3 is more sensible than the "8 characters with an upper-case letter, a number and a symbol" policies that produce Passw0rd! — length contributes far more than forced complexity, and that is what current guidance says (NIST SP 800-63B). The second: enforce_for_root = 1 is easy to forget, and without it the most important account on the system is the only one exempt from the policy.

It complements fail2ban, which acts on the IP; faillock acts on the account, so it also covers attempts from the console or from different IPs.

The order matters and it is not intuitive: preauth checks whether the account is already locked before asking for credentials, authfail counts the failure, and authsucc clears the counter after a successful login. Missing out authsucc produces a slow but inevitable lockout, because the counter is never reset.

And the combination of even_deny_root with root_unlock_time = 60 is deliberate: protecting root without creating the possibility of a total system lockout.

Two of these lines are security measures rather than performance ones. nproc limits the damage of a loop that creates processes without control — accidental or otherwise. And core 0 avoids memory dumps, which contain everything the process had in RAM at that moment: including the password you went to such lengths to encrypt in 06-05.

Careful with the scope: pam_limits applies to sessions that go through PAM. For a systemd service, the limits go in the unit (LimitNOFILE, LimitNPROC), as you saw in 05-07.

libpam-google-authenticator adds a TOTP code to SSH authentication. It is effective against credential theft, and on a server with key-based access the marginal benefit is smaller than on one with passwords. If it is adopted, there are two things you cannot forget: keeping the recovery codes off the server, and deciding what happens if the TOTP device is lost. Without that, it is an elegant way of locking yourself out.

In 06-04 the logs showed that luis logged in with password, even though you disabled it in 06-02. Time to track it down, starting with the authoritative source:

The global configuration is correct. But sshd -T with no arguments shows the global configuration; Match blocks are conditional and do not appear there. You have to ask about the specific case:

There it is. A Match User luis block with the exception, put in place "temporarily" while Luis generated his key, and never withdrawn. It is the most likely actor in the threat model — your own mistake — in its most characteristic form.

Note sshd -T -C: the -C option evaluates the configuration for a specific context of user, host and address, resolving the Match blocks. It is the only reliable way to know what configuration applies to somebody, and it deserves a place in your memory: half of the baffling SSH problems are a forgotten Match.

Before reloading, the usual discipline: sshd -t validates, the second session is open, and reload is used instead of restart.

The permissions you have known since 02-07 are DAC (Discretionary Access Control): discretionary because the owner of a resource decides who gets access. They have a structural limit: a process can do everything its user can do. If Tramontana's application is compromised, the attacker can read anything readable by svc-tramontana and write anywhere that user can write.

MAC (Mandatory Access Control) adds a layer the owner cannot relax: a policy, defined by the administrator and enforced by the kernel, that says what this program can do, regardless of who runs it.

The two modes are the key to the working method:

• complain: it does not block, it only records what it would have blocked. It is the learning mode.
• enforce: it blocks. It is the production mode.

And the professional procedure is always the same: write the profile, put it in complain, exercise the application for real, collect the denials and extend the profile, and only then switch to enforce. Starting in enforce means breaking the service and discovering the missing accesses in the worst possible way.

That last comment is what makes the profile valuable. An attacker running code in the application's context cannot launch a shell, cannot read the backups, cannot touch the home directories and cannot modify its own configuration — things DAC would partly allow them to do, and which are precisely the first steps of any post-exploitation.

In complain mode the marker is ALLOWED with a denied_mask: it means "this would have been blocked". Here a legitimate access the profile did not contemplate has turned up — the templates — so it is added and the cycle repeats:

From here on, a real denial appears as apparmor="DENIED", and it is the first thing to look at when the service starts failing after a deployment that changes paths:

SELinux, for anybody heading to RHEL:

The path-versus-label difference has a practical consequence: in SELinux, moving a file can change its context and break access (hence restorecon); in AppArmor, a symbolic link or a bind mount can bypass a path-based rule. Each model has its weak spot.

In 06-03 you applied the network sysctl settings. These are the kernel's own, and they are purely about security: the performance ones are covered in 07-03.

Two warnings to note down, because they are the two ways this can bite you later:

• kernel.yama.ptrace_scope = 1 can break debuggers. strace or gdb against a process that is already running and is not your child will stop working without sudo. In 07-02 you are going to use exactly those tools; remember that this parameter is the explanation if you get Operation not permitted.
• kernel.unprivileged_userns_clone = 0 breaks unprivileged containers, and in 07-05 you are going to set up Docker. That is why it is left commented out with the reason written beside it. A hardening parameter with a note explaining why it is not enabled is quality documentation; deleting it and forgetting the reason is not.

And the general criterion: every line in this file carries its comment. A sysctl.d with fifteen values and no explanation is impossible to maintain, because nobody — you included, in six months — will know whether any of them can be removed.

Three mount options that limit the damage in the directories where anybody can write:

The use case is direct: an attacker who manages to write a file usually needs to run it, and /tmp is the place where they can almost always write. With noexec, that step fails.

And this is where the lesson insists on something the hardening guides tend to leave out: noexec on /tmp breaks real things. Several installers extract to /tmp and run from there; so do some language package managers. You have to check first:

That last block is the positive verification: it is not enough that nothing has broken, you have to check that the measure does something. With both checks done, it is made persistent:

mount -a before rebooting is still compulsory, for the reason you have known since 05-04: a badly written fstab stops the server booting.

A CVE is the unique identifier of one specific vulnerability. Its CVSS is a score from 0 to 10 accompanied by a vector describing how it is exploited:

And the point to internalise: the base score is not the real risk to you. A 9.8 in a component you do not have installed, or that is not exposed, or that is already mitigated by another layer, is less urgent than a 6.5 in the service facing the Internet. The vector is more informative than the number: AV:N (exploitable over the network) with no privileges and no user interaction is what forces you to act today.

On 18 August at 06:12, unattended-upgrades updated openssl and libssl3t64. The package is up to date on disk, but the processes that started earlier still have the old library loaded in memory. It is a vulnerability with paperwork: the report says it is patched and the service is still exposed.

Two services. The order matters, and for two different reasons:

An important nuance about ssh: reload re-reads the configuration, but it does not replace the library loaded in the master process. For that you have to restart the daemon — which does not cut sessions already established, because each one lives in its own child process. With the second session open as a safety net:

And the closing verification:

That 0 is the closure. The second incident is closed, and with it all three.

So that it does not happen again, needrestart is configured in list mode and integrated into the review:

The decision not to restart automatically is deliberate and consistent with the unattended-upgrades of 05-03: an unsupervised restart of the database at six in the morning is a service interruption Marta must know about, not a side effect.

In 05-05 you hardened tramontana.service. Now it gets measured and improved:

3.4 MEDIUM for a network service is not bad, and there is room. The missing directives, each with its reason:

SystemCallFilter deserves an explanation because it is the highest-value directive: it installs a seccomp filter in the kernel that rejects system calls outside the permitted set. An exploit that achieves code execution inside the process finds that mount, ptrace, init_module or setuid fail with EPERM — not because of missing user permissions, but because the kernel does not accept them from this process. That is real containment, not cosmetic configuration.

And the warning about MemoryDenyWriteExecute is the kind of detail that separates a useful guide from a copied list: it stops a memory page being writable and executable at the same time, which blocks many exploitation techniques, and it breaks any engine with just-in-time compilation. If Tramontana's application were Java or Node, this line would stop it starting at all.

From 3.4 MEDIUM to 1.6 OK, with the service running and verified. The order — apply, verify, measure — is the same as in credential rotation and in performance diagnosis. Applying without verifying is how you discover at three in the morning that the hardening took the service down.

When everything above fails, the backups remain. And against ransomware there is a detail that is often overlooked: a permanently mounted backup is reachable by the ransomware, because the process encrypting the system's files also encrypts those on the mounted volume. A backup encrypted by the attacker is not a backup.

The three properties that make a backup resistant:

The concrete improvement that follows: restic supports append-only mode on the remote destination, in which the client can write new backups but cannot delete existing ones. With that, an attacker with access to the server cannot destroy the history. It is the measure to ask the external storage provider for, and it goes on the checklist.

This is the table that gets handed over, aligned with the structure of the CIS Benchmarks and with what you have actually done in the course. The three columns are deliberate: without the evidence column, a checklist is a statement of intent.

Rows 25 to 27 are the genuinely important ones, because they are the ones an honest report does not hide. And rows 32 to 34 delimit what an administrator cannot resolve, which is information the management needs to have.

A hardened system degrades on its own: every change, every new package, every "temporary" rule moves it further from the state you documented. Four practices sustain it:

1. Periodic review with comparable metrics. Lynis monthly, with its hardening index as a time series alongside the performance baseline from 05-07:

   $ sudo lynis audit system --quiet | grep 'Hardening index'
     Hardening index : 82 [################    ]
   

   From the 68 in 06-04 to the current 82. What matters is not the number: it is that if it drops, there is an explanation to go and find.
2. Change management. Every configuration modification with its prior copy, its diff -u, its verification and its note in the record. It is the course's convention, and it is the control against the most likely actor in the threat model.
3. Living documentation in the runbook, off the server: the threat model, this checklist with dates, the inventory of secrets with their last rotation, and the incident response procedure.
4. A review of the threat model itself when reality changes: one more server, a new service, a new kind of data that starts being processed. A threat model from two years ago describes a system that no longer exists.

srv-tramontana processes guests' personal data. The GDPR requires technical and organisational measures appropriate to the risk (art. 32), and several of this lesson's decisions — log retention, the scope of auditing over working people's activity, the timescale for deploying encryption in transit in row 25 — have legal implications that are not an administrator's to decide. In a real environment:

• The security officer must review the threat model and the checklist, and validate the accepted controls.
• The data protection officer must validate the processing, the retention periods and the residual risk assessment.
• And this checklist does not replace a formal audit. It is an honest self-assessment, made by whoever administers the system, and by definition it has the blind spot of the person who built it.

• Hardening with no threat model. It is the cause of half the fragile systems out there: copied measures that break things and protect against nothing that was likely. Half a page of model changes every decision that follows.
• Touching PAM without a root session open. A syntax error in common-auth can prevent every login, the console included. A root session in another terminal, a prior copy, and a test in a third.
• Forgetting pam_faillock.so authsucc. Without that line the failure counter is never reset, and the lockout arrives days later with no apparent cause.
• Forgetting enforce_for_root = 1 in pwquality.conf: the most important account ends up exempt from the password policy.
• Putting an AppArmor profile straight into enforce. It breaks the service and forces you to discover the missing accesses under pressure. Always complain first, exercise it for real, then enforce.
• Applying noexec to /tmp without checking. Some installers extract and run there. Test with mount -o remount and exercise apt and your scripts before touching fstab.
• Editing fstab without mount -a. A broken fstab stops the server booting. It is the safety net from 05-04 and it is still compulsory.
• Confusing "the package is updated" with "the vulnerability is fixed". While the process has the old library in memory, it is still exposed. needrestart -r l after every update, and lsof | grep DEL as confirmation.
• Hardening and not verifying. systemd-analyze security improves the score even if you have left the service unable to start. Apply, verify with health_check.sh, and then measure.
• MemoryDenyWriteExecute on an application with a JIT. Java, Node and .NET will not start. Read what each directive does before copying it.
• A checklist with no evidence column. "Firewall configured" says nothing; ufw status verbose does. Without evidence, the checklist is a statement of intent.
• A tip on method. Turn this lesson's audits into audit_hardening.sh using lib/common.sh, with a monthly timer and the principle of silence if all is well. What depends on your memory is not a control.

After applying the hardening drop-in, tramontana.service stops starting:

Describe the diagnostic procedure, identify the most likely cause from the information in the message, and explain how you would narrow down which specific directive causes it without removing them all at once.

Write the AppArmor profile for the /home/operator/bin/deploy-safe wrapper, which is run via sudo and calls deploy.sh. Reason about what it must permit and — more importantly — what it must deny, and explain which specific attack that profile contains that neither DAC nor the sudoers rule contains.

Marta asks you for a one-page report for the management: "are we secure?". Write it, drawing on the threat model and the checklist, without unnecessary jargon, honestly saying what is protected, what is not and which decisions need budget or authorisation.

Solution 1

The clue is in the message itself: code=killed, signal=SYS. SIGSYS is the signal the kernel sends when a seccomp filter rejects a system call. That points directly at SystemCallFilter, and not at the other directives (which would typically produce EACCES, EPERM or a path failure).

The procedure, from the most informative to the most expensive:

getrandom is the call for obtaining randomness from the kernel — the application uses it for TLS and for session identifiers. It is in @system-service, but I excluded it by adding SystemCallFilter=~@privileged @resources @obsolete, and getrandom belongs to the @resources set in some versions of systemd. The second line, which looked like an improvement, is the one that breaks the service.

How to narrow it down without removing everything, which is the method part of the exercise. The key is that drop-ins can be stacked and overridden separately:

It starts. That confirms the problem was the exclusion, not the base set. Now you refine instead of giving up on the filter:

~@privileged @obsolete is kept — which is where nearly all the defensive value lies — @resources is abandoned, and getrandom is added explicitly. Exposure 1.7 instead of 1.6, with the service running: worse hardening on paper and infinitely better in practice, because the 1.6 one did not start.

A general method applicable to any hardening failure:

1. Read the signal or the error code: SIGSYS → seccomp; EPERM on a file → ProtectSystem/ReadWritePaths; EACCES with apparmor="DENIED" → AppArmor; a failure to map memory → MemoryDenyWriteExecute.
2. Find the concrete evidence in the journal (syscall=, denied_mask=, the path).
3. Neutralise one directive with a drop-in with a higher numeric prefix, never by editing the original.
4. Verify that it starts, refine towards the necessary minimum, and measure again.
5. Consolidate the drop-in with a definitive name and write down the reason for the exception — just like the commented-out unprivileged_userns_clone in the sysctl file.

Solution 2

What it permits: reading the release package, writing under releases/, changing the app link, writing its log and its lock, and talking to systemd to restart the service. Nothing else.

What it denies, and which attack each denial contains:

And now the substance of the exercise: what this profile contains that DAC and sudoers do not.

The sudoers rule lets operator run deploy-safe as root. From that moment on, DAC offers no protection at all: root can read /etc/shadow, can read the database credential, can delete the backups, can add itself an SSH key and can launch nc to open a shell outwards. The wrapper was written precisely to avoid granting full root, but the containment depends entirely on the content of the script being correct and staying correct.

That is where the gap is. If deploy.sh has a flaw — an unquoted variable that allows a command to be injected, a tar that extracts a file with ../ in its path — the attacker executes code as root through an authorised route. Neither sudo nor the Unix permissions stop it: from their point of view the execution is legitimate.

The AppArmor profile is the layer that does stop it, because the control does not depend on the user but on the program: whatever code ends up running inside this profile, it will not be able to read the secrets, will not be able to touch the backups, will not be able to write to authorized_keys and will not be able to launch an interpreter to escape. The damage stays confined to the deployment, which is exactly what was intended when the wrapper was written and what until now was only an intention.

That is defence in depth in its most concrete form: sudoers limits who and which command; AppArmor limits what that command can do, even when the command misbehaves.

Solution 3

Security report — srv-tramontana / Tramontana Bookings To: Management · From: Systems Operations · 18 August 2026

In one sentence. The server is reasonably protected against the threats that genuinely affect it, with three outstanding matters that I set out at the end, one of which requires a decision from management.

What we are protecting, in order of importance. First, our guests' personal data: names, dates of stay and amounts. A leak would be irreversible, would harm third parties and has legal consequences. Second, the availability of the booking service, whose cost is economic and bounded in time.

Who we are protecting ourselves from, and what we have done.

• Automated attacks from the Internet, which are constant. The server accepts connections through two doors only: the administration one — which no longer accepts passwords, only cryptographic keys — and the website's. Everything else is closed by default, and anybody who persists in trying passwords is blocked automatically. In the last month 47 attempts from a single source have been blocked.
• Theft or leakage of a password. The system's credentials are no longer written in any readable file: they are encrypted and only the program that needs them can use them. We also have a written procedure for changing them without interrupting the service.
• Our own mistakes, which statistically are the most likely risk. Every modification is made with a prior copy, is checked before being applied and is recorded. An independent system checks every day that no critical file has changed without explanation.
• Misuse of legitimate access. Each person has only the permissions their job requires, and accesses to the configuration are recorded.

What we do if something fails. We have encrypted backups, with the restore tested — not merely configured — capable of recovering the service in 8 hours with a maximum loss of 4 hours of bookings, timescales agreed with Operations. And a written incident response procedure, kept off the server.

The three outstanding matters.

1. Web traffic is not yet encrypted. The certificate has been issued and verified, but the component that will present it still has to be deployed, and that is scheduled for the next phase. In the meantime the service is not reachable from the Internet, so the exposure is limited to our internal network. No decision required: it is planned.
2. An unexplained finding. Our monitoring detected an access configuration file that nobody created. It is under investigation following the established procedure. I will report the outcome; if access to personal data were confirmed, there is a legal obligation to notify it within 72 hours.
3. An off-site backup protected against deletion. Today, anybody with control of the server could destroy the backups. There is a form of storage that does not allow what has already been stored to be deleted, and it is the best available defence against a data-hostage attack. Requires a management decision: it means contracting external storage.

What is not in our hands. Three things fall outside what systems administration can resolve, and it is worth putting them on record: the internal security of the application itself, which is development's responsibility; physical and infrastructure-provider security; and an attacker with resources far greater than those of a company of our size.

And a necessary caveat. This report is a self-assessment made by whoever administers the system, and it therefore has the blind spot of the person who built it. It does not replace an independent audit. I also recommend that the processing of guests' data and the retention periods for logs be reviewed by the data protection officer.

In summary: the work is done, measured and documented. The only decision I need from management is the one in point 3.

srv-tramontana now has a security posture, and that is qualitatively different from having security measures. There is a written threat model that says what we protect, from whom and what we assume to be out of scope, and every decision in this lesson is justified by it. The attack surface has been reduced: the application listens only locally, and what is not used is masked and purged. Authentication goes through PAM with a password policy, per-account lockout and resource limits — and you tracked down the Match User luis that had been contradicting your own configuration for weeks. AppArmor contains the application in enforce, with a profile that prevents launching a shell or reading the backups even if the process is compromised. The hardening sysctl settings are applied and commented, including the line you left disabled with the reason written beside it. /tmp has no execute permission, checked before it was made persistent. And systemd-analyze security has gone from 3.4 to 1.6 with the service verified and working, which is the only improvement that counts.

The three incidents are closed: the 47 attempts from 203.0.113.44 with fail2ban, the db_password in the clear with systemd-creds and pass, and today the vulnerable libssl that was still loaded in memory — because an updated package is not a fixed vulnerability until the processes know about it. What remains is a 34-row checklist with its evidence column, three open matters stated without decoration and a report for the management that does not promise what it cannot deliver. The Lynis index has risen from 68 to 82, and the important thing about that number is not its value but that it is now a time series somebody watches.

And with that, Module 6 closes: you configured the network persistently with netplan try's automatic rollback; you hardened SSH with ed25519 keys, no root and no passwords, and learned to read sshd -T -C to find out what configuration really applies to somebody; you raised an allowlist firewall over nftables and learned the order it is applied in so as not to lock yourself out; you set up intrusion detection with AIDE and auditd, with the database protected off the server, and an incident response procedure with its uncomfortable rule; you got the secrets out of the configuration files and prepared the TLS cryptographic material with renewal tested and expiry monitored; and today you have brought all of that together into a coherent, documented posture.

So far you have operated one server, and you have operated it by hand. You know how to use it, administer it and defend it, but there are two things you still cannot do: look inside and multiply it. In Module 7: Advanced Topics you do both. You will see the complete boot process — from UEFI to GRUB, to the initramfs and to systemd — and learn to recover a system that will not boot, which is the skill that separates the people who reinstall from the people who fix. You will learn advanced diagnosis with strace, perf and eBPF to answer "what exactly is this process doing?" when the counters are not enough (and you will discover that the ptrace_scope you have just set is part of the problem statement). You will tune the kernel with sysctl, this time for performance. And then the multiplication begins: virtualisation with KVM and libvirt, containers with Docker and why they are isolated processes and not small machines, automation with Ansible — which will turn all the manual work of modules 5 and 6 into versioned, reproducible code, and the 8-hour RTO into considerably less — and finally high availability and load balancing, where srv-tramontana stops being a single point of failure. Update your VM snapshot, keep the runbook off the machine, and I will see you in Module 7.