Figure 1: Captured on the reference server before the first change was made.

Before the first change, an inventory is worthwhile. It costs a minute and later answers the question of what the system came with and what has been added.

# What is reachable from outside?ss -tlnp# Are there users besides root?awk -F:'$3>=1000 && $7!~/nologin|false/ {print $1}' /etc/passwd# Does a firewall exist?command -v ufw||echo"ufw not installed"nft list ruleset# How many updates are pending?apt-get update&& apt-get -s upgrade| grep -c'^Inst'

On the server on which this series was written, it looked like this:

• exclusivelysshd on0.0.0.0:22 and[::]:22
• no user with a UID of 1000 or above — onlyroot
• no firewall, nonftables ruleset
• four pending package updates

That is a typical factory state: exactly one service is running, and it accepts password logins for the most powerful user of the system.

You are required to change your password immediately (administrator enforced).
WARNING: Your password has expired.
You must change your password now and log in again!
New password:
Retype new password:
passwd: password updated successfully
Connection to 198.51.100.10 closed.

Result. The fingerprint is verified, the initial state is noted, the connection stands. From here on, things change — starting with the system’s package state.

Updating the System

apt update andapt upgrade

The delivery state of an image is rarely the current package state. Weeks lie between the creation of the image and the provisioning of the server.

apt-get updateapt-get upgrade

On the reference server it was four packages — thepython3.13 stack. Not much, but among them was a security update.

Kernel Update and Reboot

Here lurks the first pitfall, and it is treacherous because nothing points to it.

apt upgrade installs a new kernelbut does not activate it. The server keeps running on the old one — including the vulnerabilities the update was supposed to close. Inapt, everything looks clean.

It can be checked with two commands:

uname -r# running kernells -1 /boot/vmlinuz-*| sort -V| tail -1# installed kernel

On the reference server:

Debian additionally reports the need via a file:

[ -f /var/run/reboot-required]&&echo"reboot required"

systemctl reboot

After booting:

uname -r# 6.12.107+deb13-cloud-amd64uptime -p# up 0 minutes

Automatic Security Updates

A server that is updated only when it is set up is open to attack after a few months. Debian shipsunattended-upgrades, and on most images it is already active:

systemctl is-enabled unattended-upgrades

With this, security updates are applied automatically. What does not happen automatically is what was the problem above: the reboot.

This is exactly where the circle closes. Automatic updateswithout an automatic reboot mean that kernel vulnerabilities are patched on disk but never become active. The server looks well maintained and runs on a kernel from half a year ago — the most unpleasant variant, because it feigns security.

nano /etc/apt/apt.conf.d/52-unattended-upgrades-local

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:30";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";

Check whether the settings take effect:

apt-config dump| grep -i'Automatic-Reboot'unattended-upgrade --dry-run

This Decision Has to Be Made

An automatic reboot at half past three in the morning terminates every running session of the application. With Vaadin this is more noticeable than with many other frameworks, because the UI state is held on the server — Part 1 covers this in detail.

Anyone who enables the reboot accepts a nightly maintenance window. Anyone who leaves it out accepts unpatched kernels. Both are defensible. Remaining undecided is not, because then the default applies — and it reads: patch, but do not reboot.

Creating an Administrative User

So far there is exactly one user on the system, and it may do everything. That is about to change: administrative work will from now on run through a dedicated account that obtains privileges when needed instead of holding them permanently.

The practical gain is less philosophical than it sounds. An administrative account without permanent privileges makes typos harmless that, asroot, would damage the system. And it is the precondition for completely disabling root access via SSH in the next chapter.

Creating the User

adduser --disabled-password --gecos"First Last" svenpasswd svenusermod -aG sudo sven

--disabled-password initially creates the account without a password;passwd then sets one deliberately. The detour seems cumbersome, but it avoids the interactive dialog ofadduser and can therefore also be used in a script.

The password is not needed for logging in — that runs via a key. It is needed forsudo.

Thesudo Group

On Debian, membership in the groupsudo is sufficient. A dedicated rule in/etc/sudoers is not necessary and would be an additional source of errors.

getent group sudo

sudo:x:27:sven

Anyone who wants to set upsudo without a password prompt should consider the decision carefully: it turns every compromised user account immediately into full access. On a server that runs a publicly reachable application, the password prompt is the right default.

Depositing the SSH Key

From the workstation, not on the server:

ssh-copy-id -i ~/.ssh/id_ed25519.pub sven@198.51.100.10

ssh-copy-id creates the directory with the correct permissions and appends the key. It can be done by hand as well, just with more opportunities for mistakes:

install -d -m700 -o sven -g sven /home/sven/.sshnano /home/sven/.ssh/authorized_keyschmod600 /home/sven/.ssh/authorized_keyschown sven:sven /home/sven/.ssh/authorized_keys

The permissions are not optional.sshd refuses service ifauthorized_keys is readable by others — a frequent reason for a key login that fails for no apparent reason.

To check which keys are actually deposited:

ssh-keygen -lf /home/sven/.ssh/authorized_keys

Verifying Access Before Hardening

This is the most important step of this chapter, and it is regularly skipped.

In the next chapter, root access is disabled. Anyone who discovers at that point that the new user does not work has locked themselves out and needs the provider’s emergency console.

So beforehand, in asecond session — the existing one stays open:

ssh -i ~/.ssh/id_ed25519 sven@198.51.100.10'id'ssh -i ~/.ssh/id_ed25519 sven@198.51.100.10'sudo whoami'

The first command must print the user identity, the secondroot. Only when both are correct does it go on.

The open session asroot is not a blemish but the safety rope: as long as it exists, any faulty change to the SSH configuration can be rolled back, even if no new login succeeds anymore.

Hardening SSH

SSH is the only service on this server that is reachable from outside, and it currently accepts passwords forroot. Both change now.

Where Debian Reads the Configuration

Debian 13 splits the SSH configuration into a main file and a directory of drop-in files. A look at both is worthwhile before changing anything:

grep -n -i'^include' /etc/ssh/sshd_configgrep -nvE'^\s*(#|$)' /etc/ssh/sshd_config| grep -i permitrootls -1 /etc/ssh/sshd_config.d/

12:Include /etc/ssh/sshd_config.d/*.conf
33:PermitRootLogin yes
50-cloud-init.conf

And in this drop-in file it says:

PasswordAuthentication yes

The Pitfall That Trips Up Most People

From these three observations follows something that contradicts intuition:

sshd uses the first value found per parameter, not the last.

Two consequences follow from this, and both lead to a change remaining without effect, with no error message appearing.

First: TheInclude line is on line 12, thePermitRootLogin yes on line 33. Everything from the drop-in directory is therefore readbefore the main file and wins. Anyone who changesPermitRootLogin in/etc/ssh/sshd_config changes a value that would never take effect anyway, as soon as a drop-in file sets the same parameter.

Second: The files in the drop-in directory are read in alphabetical order.cloud-init places50-cloud-init.conf there and setsPasswordAuthentication yes. A file of your own only takes effect if its name sortsbefore it. Hence10-hardening.conf — and not, as intuition suggests,99-hardening.conf.

Anyone who creates a99- file ends up with a file whose content is correct and which accomplishes nothing. The directory looks right; the configuration is not.

The Hardening

sudo nano /etc/ssh/sshd_config.d/10-hardening.conf

# sshd uses the FIRST value it finds per parameter.
# This file must sort lexically BEFORE 50-cloud-init.conf,
# which sets PasswordAuthentication back to "yes".
# Authentication
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
# Only explicitly named accounts may log in
AllowUsers sven
MaxAuthTries 3
LoginGraceTime 30
MaxSessions 4
# Forwarding is not needed on an application server
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no
GatewayPorts no
# Reduce host keys to ed25519
HostKey /etc/ssh/ssh_host_ed25519_key

Three entries deserve a justification.

AllowUsers is the most effective of them. Without this line, every account that at some point receives a key may log in — including a service account where nobody intended that. With it, the list of permitted accounts is explicit and readable.

AllowTcpForwarding no prevents the server from serving as a jump host. Without this setting, anyone who is allowed to log in can tunnel arbitrary connections through the server — including into networks that are not reachable from outside.

HostKey reduces the offered server keys to one. As soon as the parameter is set, the defaults no longer apply. The result is a single fingerprint instead of three — which is what makes the comparison from Chapter 3 unambiguous in the first place.

Checking Before Reloading

Two commands, and the second is the decisive one:

sudo sshd -tsudo sshd -T| grep -E'^(permitrootlogin|passwordauthentication|allowusers)'

sshd -t checks only the syntax and stays silent on success.sshd -T shows theeffective configuration after resolving all drop-in files:

permitrootlogin no
passwordauthentication no
allowusers sven

That is the only reliable answer. Reading the configuration file does not answer the question — that is exactly where the pitfall from above goes unnoticed. Anyone who usessshd -T habitually cannot miss the ordering problem.

sudo systemctl reload ssh

reload instead ofrestart: existing sessions are preserved. If the configuration renders access unusable, the open session from Chapter 5 is still there and the change can be rolled back.

Proof From Outside

Claiming is not enough. Three cases, all from the workstation:

# 1) The admin user by key - must succeedssh -i ~/.ssh/id_ed25519 sven@198.51.100.10'echo OK'# 2) root - must be rejectedssh root@198.51.100.10# root@198.51.100.10: Permission denied (publickey).# 3) Password login - must be rejectedssh -oPubkeyAuthentication=no -oPreferredAuthentications=password sven@198.51.100.10# sven@198.51.100.10: Permission denied (publickey).

The proof is in the third case, specifically in the wording of the error message. It sayspublickey — although a password login was explicitly requested. So the server no longer offers passwords at all. If it still had them on offer, it would saypassword.

For comparison, it is worth looking back at Chapter 3: there the answer was stillPermission denied (publickey,password).

What Is Offered Afterwards

ssh-keyscan 198.51.100.10 > /tmp/hk.txt&& ssh-keygen -lf /tmp/hk.txt

Instead of three lines, one now appears. The fingerprint that a new machine must confirm on the first connection is thus uniquely determined.

Configuring the Firewall

How Fast the First Attacks Arrive

Before it comes to rules, a look into the log is worthwhile — because it answers the question of whether the effort is worth it with numbers instead of assumptions.

The reference server was rebooted after the kernel update from Chapter 4 at08:01:25. The first foreign login attempt appears in the journal at08:01:48:

2026-09-04T08:01:48+00:00 sshd-session[1018]:
Failed password for root from 31.58.216.82 port 50496

Twenty-three seconds. At that point no service was published, no domain pointed to the address, and nobody had mentioned it anywhere. A public IPv4 address is enough: the entire address space is being swept permanently.

How permanently is shown by the evaluation over different time spans:

journalctl -u ssh| grep -cE'Failed password|Invalid user'

Over a million login attempts on a server that does nothing and that nobody knows. That is roughly 150 per hour, without interruption, day and night.

It is revealing which account names are being tried:

19739 admin 6311 test
15062 ubuntu 5558 debian
10225 user 5429 deploy
7153 solana 4960 sol

admin,ubuntu,user,debian,deploy — the usual suspects. Butsolana in fourth place andsol in eighth: there is a targeted search for crypto wallet nodes. The attempts are not blind; they are profit-oriented.

That is the reason why root access and password login were disabled in Chapter 6 — not as a formality, but because 150 attempts per hour run against them. With password login enabled, it is a question of time and password quality.

Defining the Rules

Debian does not shipufw:

sudo apt-get install ufw

sudo ufw default deny incomingsudo ufw default allow outgoingsudo ufw allow 22/tcp comment'SSH'sudo ufw allow 80/tcp comment'HTTP'sudo ufw allow 443/tcp comment'HTTPS'sudo ufw enable

Three ports, nothing more.The application port deliberately stays closed. In Part 1, a servlet container listens on port 8080 — but exclusively on the loopback address, reachable only through the reverse proxy. Blocking it in the firewall as well is the second line of defense; the first is not listening to the outside there in the first place.

Port 80 is needed even though the application is later supposed to be reachable exclusively via HTTPS: the automatic certificate issuance in Part 1 runs through a challenge on port 80.

Proof From Outside

From the workstation, not from the server:

for p in2280443 8080;do nc -z -w4 198.51.100.10$p&&echo"$p open"||echo"$p filtered"done

22 open
80 filtered
443 filtered
8080 filtered

80 and 443 are allowed inufw, but nothing is listening on them yet — they only become reachable with the reverse proxy in Part 1. That is the expected intermediate state and not an error.

Slowing Down Repeated Attempts

Given the numbers above, a plain port allowance is too little. Two measures complement each other.

Rate limiting directly inufw:

sudo ufw delete allow 22/tcpsudo ufw limit 22/tcp comment'SSH (rate-limited)'

limit instead ofallow drops connections when more than six arrive from the same source within 30 seconds.

fail2ban evaluates the logs and locks out conspicuous addresses for a while:

sudo apt-get install fail2bansudo nano /etc/fail2ban/jail.local

[DEFAULT]# Debian 13 logs to journald, not to /var/log/auth.logbackend=systemd# Apply bans through ufw so that only ONE rule set existsbanaction=ufwignoreip=127.0.0.1/8 ::1bantime=1hfindtime=10mmaxretry=5[sshd]enabled=true

Both lines in the header are Debian-13-specific and easily overlooked. Withoutbackend = systemd,fail2ban looks for a file that no longer exists. Withoutbanaction = ufw, it builds a second, competing ruleset next toufw — both then work, but nobody can see as a whole anymore what is blocked.

sudo systemctlenable --now fail2bansudo fail2ban-client status sshd

The effect is immediately visible:

Status for the jail: sshd
`- Actions
|- Currently banned: 2
`- Banned IP list: 104.248.160.169 173.244.60.241

fail2ban evaluates the existing journal at startup and immediately bans what was already conspicuous there. You do not have to wait to see an effect.

What This Achieves and What It Does Not

With key-only login, thesshd jail protects little — anyone without a matching key does not get through anyway, no matter how often they try. The gain lies elsewhere: less system load, a readable log, and a safety net for the case that someone later re-enables password login by accident.

As the only measure,fail2ban would be weak. As a complement to Chapter 6, it is right.

ssh: connect to host 198.51.100.10 port 22: Connection refused

Outbound Connections

So far, everything outbound is open. Restricting this limits what a compromised process can download and where it can exfiltrate data to:

sudo ufw default deny outgoingsudo ufw allow out53 comment'DNS'sudo ufw allow out 80/tcp comment'HTTP: apt, Zertifikate'sudo ufw allow out 443/tcp comment'HTTPS: apt, Zertifikate'sudo ufw allow out 123/udp comment'NTP'sudo ufw reload

Do not forget NTP. Without a synchronized clock, the verification of TLS certificates fails, and the automatic certificate renewal in Part 1 breaks. That is the error that only shows up weeks later.

Afterwards, check that what must work still works:

sudo apt-get updatetimedatectl show -p NTPSynchronized --value

An Honest Assessment

The effect of this restriction has limits. Port 443 must remain open, and via 443 practically every destination on the Internet is reachable. Anyone who wants to exfiltrate data chooses HTTPS for it, not an exotic port.

The gain lies with everything that does not follow this rule: a connection to some remote endpoint on port 4444, mail delivery over port 25, a tunnel on an arbitrary high port. That is real, but it is not a barrier — and it should not be described as one.

Hardening Kernel Parameters

The previous chapters secured the system towards the outside. This chapter turns the view inward: what may a process on this server find out about other processes and about the kernel?

Debian already sets most security-relevant kernel parameters sensibly. Two, however, are set to the least secure value.

The Parameter That Matters

sysctl -n kernel.yama.ptrace_scope

0

ptrace is the mechanism a debugger uses to read the memory of another process. At0, this access is allowed for every process on every other process of the same user.

The impact shows in the interplay with a topic from Part 1. There, the point is to keep credentials out of command-line arguments, because those are visible to every user of the system in the process list. The effort is justified — but it evaporates as long as another process may simply read the same value from memory.

kernel.yama.ptrace_scope = 1

With1, a process may only inspect its own child processes. A debugger still works if it starts the target program itself; attaching to a foreign process afterwards requires root privileges.

This is a pattern that recurs throughout this series:individual measures only work in combination. A carefully secured handover of credentials and openptrace access cancel each other out.

The Remaining Values

sudo nano /etc/sysctl.d/60-hardening.conf

# Make the memory of other processes unreadable
kernel.yama.ptrace_scope = 1
# Do not expose kernel pointers in /proc
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
net.core.bpf_jit_harden = 2
# Network
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.log_martians = 1
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_source_route = 0
# File system
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.protected_fifos = 2
fs.protected_regular = 2
fs.suid_dumpable = 0

sudo sysctl --system

kernel.kptr_restrict hides kernel memory addresses in/proc. They are needed for developing attacks, but by nothing in normal operation.

The network parameters reject redirects and source-routed packets — techniques from an era when trust on the network was the default. The file system parameters prevent a class of attacks in which an unprivileged user plants a link in a shared directory.

Verification

for k in kernel.yama.ptrace_scope kernel.kptr_restrict net.core.bpf_jit_harden;doprintf'%-32s %s\n'"$k""$(sysctl -n$k)"done

The values now read1,2, and2. Because the file lives under/etc/sysctl.d/, they also apply after a reboot.

User and Permission Concept

On this server, three kinds of accounts are distinguished from now on. The administrative account from Chapter 5 is one of them; this chapter adds the second and explains why the third must not exist.

What does not exist: an account that is both. Running an application under the administrative account saves one step and costs the entire separation — the application process would then have access to the SSH keys and, viasudo, to the whole system.

The Service Account

The later application is calledvaadinapp, and its account is called the same:

sudo adduser --system --group\ --home /var/lib/vaadinapp\ --shell /usr/sbin/nologin\ vaadinapp

id vaadinapp

uid=101(vaadinapp) gid=103(vaadinapp) groups=103(vaadinapp)

Three details are worth explaining.

--system assigns an ID below 1000. That is not a technical necessity, but a lived convention: tools that list “real” users hide this range. The command from Chapter 3 that searches for users with an ID of 1000 or above therefore does not find the service account — and that is intended.

--shell /usr/sbin/nologin prevents any interactive session. Even if someone were to set a password or deposit a key, no login would come about.

--home /var/lib/vaadinapp places the home directory where the application’s mutable data lives. Chapter 10 covers the layout as a whole.

One Account per Application

The obvious shortcut would be a shared account for all Java applications —jetty, say. It saves administrative effort and cancels exactly the property this is all about.

Two applications under the same account can read each other’s files, inspect each other’s credentials, and — with aptrace_scope of0, see Chapter 8 — read each other’s memory. Whoever compromises one of them has both.

One account per application costs one command. This calculation always works out.

The Service Must Not Be Able to Change Its Own Program

The most important principle of this chapter is at the same time the most rarely implemented one:the service account does not own its own program files.

Whoever compromises an application can do what the application may do — but they cannot replace the program on disk. A restart brings back the unmodified state. Without this separation, a manipulation survives every restart, and the cause is later almost impossible to find.

In practical terms: the program directory and the configuration belong toroot; the service account may read. Writable is exclusively the area for mutable data. Chapter 10 implements this.

A Note onDynamicUser

systemd can create service accounts itself at every start and discard them afterwards. That saves creating them by hand and leaves no stale accounts behind.

For this series it is not used. The reason is the section above: permanent ownership requires a permanent ID. With a changing ID, it cannot be determined which files belong to the service and which do not — and that is exactly what the protection rests on.

For stateless services without files of their own,DynamicUser is a good choice. An application with a data set is not such a service.

Directory Structure for Applications

An application consists of three kinds of files that have nothing to do with one another: the program, its configuration, and the data that accumulates during operation. They differ in who may change them, how often they change, and whether they belong in a backup.

A directory in which everything lies side by side is convenient and makes each of these questions unanswerable.

The Layout

The Filesystem Hierarchy Standard has answered the question for decades. For an application namedvaadinapp:

sudo install -d -m750 -o root -g vaadinapp /opt/vaadinappsudo install -d -m750 -o root -g vaadinapp /etc/vaadinappsudo install -d -m750 -o vaadinapp -g vaadinapp /var/lib/vaadinapp

install -d instead ofmkdir sets permissions and owner in one call. Withmkdir, two more commands follow, and the second is easily forgotten.

The permissions750 mean: the owner may do everything, the group may read and enter, everyone else may do nothing. Since the service account is in the group of the same name, it can read — and write only where it is itself the owner.

Logs

/var/log/vaadinapp is deliberately absent from the table. Services running undersystemd write their output tojournald; a separate log directory creates a second store with its own rotation and its own cleanup needs.

Applications that additionally keep an access log of their own — in Part 1 that will be the case — place it below/var/lib/vaadinapp. Writing happens there anyway, and it stays at one writable area instead of two.

Why This Separation Is More Than Tidiness

Here is the point at which this chapter goes beyond housekeeping.

In Part 1, the application service is set up so thatsystemd presents it the entire file system read-only. Released is only what is explicitly named. With clean separation, that isa single line: the area for mutable data.

If everything lay under one shared directory, exactly this directory would have to be released — and with it the program and the configuration. The measure would formally exist and would be practically ineffective.

These five minutes in Chapter 10 are the precondition for a security measure in Part 1 to take hold at all. Anyone who treats the structure as a matter of taste discovers later that the hardening does not work, and does not find the reason.

A Subtlety That Surprises

It is not enough to make the program directory belong toroot. What also matters is who owns theparent directory.

Whoever may write to a directory may rename the entries it contains — regardless of who owns them. A service with write access to its home directory can therefore push aside aroot-owned subdirectory inside it and put its own in its place. It never touched the files inside; yet it achieved exactly what was supposed to be prevented.

That is why the parent directory also belongs toroot, and writable are only the subdirectories in which writing actually happens:

sudo install -d -m750 -o root -g vaadinapp /var/lib/vaadinappsudo install -d -m750 -o vaadinapp -g vaadinapp /var/lib/vaadinapp/datasudo install -d -m750 -o vaadinapp -g vaadinapp /var/lib/vaadinapp/work

Verification

The test for it is simple — it checks what the service account is actually allowed to do:

for d in /opt/vaadinapp /etc/vaadinapp /var/lib/vaadinapp /var/lib/vaadinapp/data;do sudo -u vaadinapptest -w"$d"&&s="schreibbar"||s="read-only"printf'%-32s %-11s %s\n'"$d""$s""$(stat -c'%U:%G %a'$d)"done

/opt/vaadinapp read-only root:vaadinapp 750
/etc/vaadinapp read-only root:vaadinapp 750
/var/lib/vaadinapp read-only root:vaadinapp 750
/var/lib/vaadinapp/data schreibbar vaadinapp:vaadinapp 750

Exactly one writable path. That is the goal.

Initial State for Part 1

The server is prepared. This chapter records what has been achieved — as a list that can be checked off, and as a set of commands that prove the state instead of asserting it.

Anyone who skipped this part because their own server is already run in a hardened state can cross-check here and then move on to Part 1.

What Applies Now

The Proof

Figure 2: The access path after completing this part.

These commands answer the list above. They run in a few seconds and are worth it, because reading a configuration file is something different from checking the effective state.

bashCopy

# Is the installed kernel the one running?uname -rls -1 /boot/vmlinuz-*| sort -V| tail -1# Effective SSH configurationsudo sshd -T| grep -E'^(permitrootlogin|passwordauthentication|allowusers)'# Firewallsudo ufw status verbose# Ban mechanismsudo fail2ban-client status sshd# Kernel parameterssysctl -n kernel.yama.ptrace_scope kernel.kptr_restrict# Accountsgetent passwd vaadinappgetent group sudo# What is listening to the outside?ss -tlnp

The last command should still show onlysshd. No application is running on this server yet — that changes with Part 1.

And from another machine, because only that is real proof:

bashCopy

ssh root@198.51.100.10# Permission denied (publickey).for p in2280443 8080;do nc -z -w4 198.51.100.10$p&&echo"$p open"||echo"$p filtered"done# 22 open, everything else filtered

What Part 1 Finds in Place

Part 1 builds on exactly this state and does not repeat it. It installs a Java runtime and a servlet container, gets a Vaadin application running on it as a web archive, places it as asystemd service under the prepared service account, and makes it publicly reachable through a reverse proxy with an automatically issued certificate.

Two things from this part will resurface there. The directory separation from Chapter 10 becomes the basis for effectively confining the application service. And the numbers from Chapter 7 get a sequel: as soon as the application receives a certificate, it becomes publicly known — faster than you would think possible.

]]>JavaSecurity