Home › Case study

Real case · anonymised infrastructure

Protecting a Debian 12 VPS without interrupting administrative access.

A real deployment on an external application server: Sentinel was integrated alongside Fail2Ban, connected to the central service and verified through to the local firewall.

Debian 12Restricted SSHExisting Fail2BanVerified on 29 August 2026
183block indicators synchronised on first connectionPoint-in-time result, not a current total
9management addresses protected by the allowlistNo address is published
3SSH sessions remained active while rules were appliedNo operational interruption observed
0new errors after the final restart of the agentChecked against the system journal

The context

A machine already protected, but with separate tools and responsibilities.

The goal was not to replace what worked: it was to add central visibility and shared indicators without introducing a new blocking point for administrators.

Scenario

External application VPS

Debian 12 server with web application and SSH administration limited to a small group of authorised sources.

Existing protection

Fail2Ban already operating

Three active jails and firewall rules already present. Sentinel had to coexist with these defences while keeping rule ownership clearly separated.

Main constraint

No lockout

A false block on an administrative source could have made the machine unreachable. The allowlist was therefore a prerequisite, not a later addition.

The technical challenge

Debian 12 used journald, while the SSH watcher was waiting for an authentication file.

The preflight detected the absence of /var/log/auth.log: on this Debian installation, events were only available in journald. A running agent without a readable source would not have performed the expected SSH monitoring.

In parallel, the firewall already hosted the chains of Fail2Ban and several administrative sessions were open. Before applying any shared indicator it was necessary to protect the authorised sources.

Intervention

Five checks, ordered to reduce risk.

  1. 01

    Preflight

    Inventory, backup and verification of the channel

    We checked the distribution, existing configuration, signed repository, TLS endpoint and dedicated credential. The local file was saved before the changes.

    Outcome Verified package and recoverable previous configuration.
  2. 02

    Event source

    Preparing the authentication log

    We enabled the supported authpriv log path and generated an initial event, so the watcher did not have to wait for a future login attempt before finding the file.

    Outcome SSH watcher started with a real, readable source.
  3. 03

    Anti-lockout

    Alignment of allowlists

    The nine authorised management sources were added to the allowlists in both Sentinel and Fail2Ban. Established SSH sessions were also checked before synchronised blocks were applied.

    Outcome No authorised source in the Sentinel block chain.
  4. 04

    Firewall

    Separate Sentinel chain

    The agent created its own chain and address set. Fail2Ban remained active on its own chains, and no existing rules were overwritten.

    Outcome Clear rule ownership and a scoped rollback path.
  5. 05

    Validation

    Synchronisation, restart and log review

    On the first connection, 183 active indicators were synchronised. After the final restart, we verified the service, watcher, firewall, SSH sessions and log entries after the new timestamp.

    Outcome The agent remained stable and connected, with no new errors in the inspected journal window.

The result

More central visibility without removing local control.

Sentinel added telemetry and shared indicators while keeping firewall decisions local. Existing defences continued to work and authorised sessions were not interrupted.

Verification completedSnapshot of 29/08/2026
Agent service
active (running)
Central channel
TLS verified
SSH watcher
Active
Firewall
Dedicated chain
Fail2Ban
Operational, not replaced
Errors after restart
0 observed

What we learned

The checks that make the deployment repeatable.

01

Running is not enough

An active service can have an unusable watcher. Verification must reach the event source and confirm the resulting firewall action.

02

The allowlist comes first

Management networks should be collected and protected before block synchronisation, especially in automatic installations.

03

Each system maintains its own rules

Sentinel and Fail2Ban can coexist if chains, logs and ownership remain identifiable and the rollback does not remove unrelated rules.

04

Logs should be read in the appropriate time window

Errors prior to a correction do not describe the current state. The final check always starts from the timestamp of the last restart.

Transparency of the case study

Real data, identity removed and scope stated.

This case study is based on a technical validation performed on a single machine. For security we do not publish the customer identity, IP address, hostname, provider, API key, authorised networks or application content.

The numbers represent the state observed during that verification: they are not a benchmark, an average of the Sentinel network or a guarantee of identical results on other infrastructures.

Verification period: 29 August 2026 · Editorial review: 9 September 2026

Do you want to apply the same method to your infrastructure?

We start with existing access controls, logs, firewalls and tools, then define a verifiable, reversible deployment.

Request an evaluationRead the technical documentation