Linux server security: hardening, patching and incident response

Securing a Linux server isn’t a product you install once - it’s a set of configuration choices maintained over time. We reduce the attack surface, apply hardening according to the CIS Benchmarks and keep systems patched, without hype or scaremongering. Documented configurations, no lock-in and a single point of contact: you always know what’s protected, how and why.

Overview

We work on internet-facing servers, internal machines and cloud environments with the same method: first we understand what’s running and how it’s configured, then we close down what isn’t needed and secure the rest. An initial audit takes a snapshot of active services, versions, permissions and access; from there we build a plan with concrete priorities, not an endless list of generic recommendations.

We don’t promise invulnerability, because it doesn’t exist: we raise the cost of an attack, make attempts visible and prepare recovery for when something goes wrong. Encrypted, tested backups, centralised logs and written procedures are worth more than any slogan.

We’re a technical consultancy, not a SOC with round-the-clock cover, and we say so plainly. We cover Monday to Friday, 10:00-18:00 , with urgency triage and, for those who need it, on-call retainers for emergencies: pickup times are described on the response times page.

Typical problems we solve

• SSH exposed and targeted by brute-force attempts → key-only access, a filtered port and fail2ban banning the attempts.
• A server that’s never been updated for fear of breaking something → patches scheduled in agreed windows, verified before production.
• A machine compromised by a cryptominer or webshell → isolation, log analysis, clean-up and restore from a clean backup.
• Backups nobody has ever tried to restore → encrypted off-site copies with periodic restore tests.
• Users and permissions piled up over the years → access audit, removal of orphaned accounts and the principle of least privilege.
• No firewall, or rules that are far too permissive → a minimal, documented and verifiable set of nftables rules.
• GDPR obligations on the infrastructure side discovered too late → encryption at rest and in transit, audit logs and backup retention.

What’s included

• System hardening: removing unused services, correct permissions and ownership, hardened kernel and sysctl, service accounts with no shell.
• Secure SSH: key-only access, disabled root login, restricted ports and networks, MFA where it makes sense.
• Firewalling and fail2ban: minimal nftables/iptables rules and automatic banning of brute-force attempts.
• Patch management: scheduled security updates, with agreed windows and verification before production.
• Encrypted backups: encrypted copies with retention and off-site storage, genuinely tested on restore.
• Logging and alerting: centralised logs, access auditing and notifications only for the events that matter.
• Incident response: isolation, entry-point analysis, malware and backdoor removal, restore and a final report.

Stack and technologies

We work mainly on Debian and Ubuntu; on request we also manage AlmaLinux, Rocky Linux, Arch Linux and other distributions. For the perimeter we use nftables or iptables with fail2ban; for access, hardened OpenSSH with key-based authentication and, where needed, MFA. We apply the CIS Benchmark controls and confine processes with AppArmor or SELinux, depending on the distribution. On the data side: TLS in transit, LUKS at rest and secret managers for credentials. Backups run on restic or BorgBackup, encrypted and verified. We secure mail servers on Exim and Dovecot, with SPF, DKIM and DMARC in order. In the cloud we work mainly on Google Cloud, with AWS and DigitalOcean as alternatives, using the provider’s network firewall and IAM. Logging and alerting build on the stack you already use: journald, rsyslog, Prometheus and Grafana.

A real-world example

An SME contacts us because the Ubuntu VPS hosting their site and back-office system has slowed down and the provider is flagging anomalous traffic. We find a cryptominer launched from a webshell, uploaded months earlier through an outdated CMS plugin. We isolate the machine, reconstruct the attack sequence from the logs and verify that the backups predating the compromise are clean. We restore onto a new instance, update the CMS and plugins, move SSH to key-only access with fail2ban, lock the firewall down to public services only, and turn on encrypted backups with restic and access alerting. The client receives a readable report with the root cause, the actions taken and a quarterly patch plan. Since then, intrusion attempts still show up in the logs - but they stay attempts.

Who it’s for

• SMEs and professional firms with exposed servers and no one looking after them methodically.
• Agencies and software houses that want to hand clients infrastructure that’s genuinely secured.
• E-commerce and SaaS handling personal data that must meet GDPR obligations on the infrastructure side.
• Anyone who’s had an incident and wants to understand what happened, clean up and not fall into it again.

How we work

We start with a security audit of what you have: an inventory of services, a review of configurations and patches, an analysis of access and permissions. From there we define a plan with clear priorities, agree on every maintenance window and apply the hardening, testing before we touch production. Quotes are always free, with a reply within one business day; for ongoing maintenance many clients use hour packages that never expire. We leave you standard, documented configurations, a readable report on what we changed and why, and guidance to keep the level up over time. No lock-in, no black boxes: security stays yours and verifiable, even if tomorrow you decide to manage it on your own.