Securing a dedicated Linux Debian 12 server — Complete post-incident guide

An ordinary Tuesday morning. I glance at Apache logs before starting work — a conditioned reflex, rarely useful. Except that morning. In error.log, hundreds of identical lines, all from the same IP: 13.37.248.113. HTTP Digest authentication attempts in a loop, combining common usernames with generic passwords.

The server held. HTTP Digest auth with a correct password is a solid barrier against brute force if the password is strong. But the incident still triggered a full audit I'd been putting off for too long.

This server hosts a private seedbox shared with about twenty users, a PHP website behind Apache with HTTP Digest authentication, SFTP access via ProFTPD, a wiki in Docker behind an Apache reverse proxy, and Jellyfin for streaming. A classic setup for a semi-professional personal server. Here is everything that was reviewed, fixed, and automated.

1. Detecting and responding to a brute force attack

Reading Apache logs to identify attempts

Apache's HTTP Digest authentication logs its failures in error.log, not access.log. The codes to look for are AH01790 and AH01794.

# Count failed attempts by IP over the last 24h
grep "AH0179" /var/log/apache2/error.log | grep -oP '\[client \K[0-9.]+' | sort | uniq -c | sort -rn | head -20

# See full lines for a specific IP
grep "13.37.248.113" /var/log/apache2/error.log | tail -30

Log lines look like this:

[Tue Feb 18 07:23:41.412893 2026] [auth_digest:error] [pid 1234] [client 13.37.248.113:58432] AH01790: user admin: password mismatch: /protected/
[Tue Feb 18 07:23:41.718204 2026] [auth_digest:error] [pid 1234] [client 13.37.248.113:58433] AH01794: user root in realm "Private Area" not found: /protected/
[Tue Feb 18 07:23:42.091337 2026] [auth_digest:error] [pid 1234] [client 13.37.248.113:58434] AH01790: user administrator: password mismatch: /protected/

Three distinct patterns in these logs: password mismatch (known user, wrong password), not found (non-existent user), and sometimes nonce mismatch (replay of expired challenge). The attacker was clearly testing a list of generic login/password pairs.

Identifying the attacker

# Quick whois
whois 13.37.248.113

# Geolocation without installing anything
curl -s https://ipinfo.io/13.37.248.113/json

Result: IP belonging to Amazon AWS eu-west-3 (Paris). Classic. Cheap AWS VPS instances are used en masse for this kind of operation because they're easy to create, difficult to trace back to a real person, and often poorly monitored. The IP has since been reported on AbuseIPDB with around sixty reports.

Verifying no intrusion occurred

Before doing anything else, verify that nothing actually got in. The brute force may have found something before it was noticed.

# Successful SSH connections (look for unexpected logins)
grep "Accepted" /var/log/auth.log | tail -50

# Failed SSH attempts from the same IP
grep "13.37.248.113" /var/log/auth.log

# SFTP activity (ProFTPD log)
grep "13.37.248.113" /var/log/proftpd/proftpd.log 2>/dev/null

# Check timestamps on sensitive files
stat /etc/passwd /etc/shadow /etc/sudoers
ls -la /root/.ssh/
ls -la /home/

# Look for files modified recently in /etc (last 24h)
find /etc -newer /tmp/ref_file -ls 2>/dev/null
# Create the reference file first: touch -d "24 hours ago" /tmp/ref_file

In this specific case, nothing. The attack was limited to HTTP Digest, without touching SSH. But that doesn't change the need to close the weak points that could have been exploited.

2. fail2ban — Protection against brute force

fail2ban analyzes logs and bans IPs that exceed an attempt threshold. The default config is a good starting point, but it has significant gaps for this specific setup.

apt install fail2ban
systemctl enable fail2ban

All customizations go in /etc/fail2ban/jail.local (never modify jail.conf directly — it will be overwritten during updates).

SSH jail

# /etc/fail2ban/jail.local
[DEFAULT]
bantime  = 86400    ; 24h
findtime = 600      ; detection window: 10 minutes
maxretry = 5
banaction = iptables-multiport

[sshd]
enabled  = true
port     = ssh
logpath  = %(sshd_log)s
backend  = %(sshd_backend)s
maxretry = 5

apache-auth jail — the default filter trap

fail2ban includes a default apache-auth filter. It does not detect HTTP Digest authentication errors from Apache 2.4. The default filter looks for patterns like Authorization Required or Basic Auth errors — not the AH01790 / AH01794 from the auth_digest module.

A custom filter is required:

# /etc/fail2ban/filter.d/apache-auth.local
[Definition]
failregex = \[client <HOST>:.*\] AH01790: user .+: password mismatch
            \[client <HOST>:.*\] AH01794: user .+ in realm .+ not found
            \[client <HOST>:.*\] AH01788: .+nonce from .+ received on .+ - not found

Then the corresponding jail in jail.local:

[apache-auth]
enabled  = true
filter   = apache-auth
port     = http,https
logpath  = /var/log/apache2/error.log
maxretry = 8
bantime  = 86400
findtime = 300

To test the filter before enabling it in production:

# Test the filter against a real log excerpt
fail2ban-regex /var/log/apache2/error.log /etc/fail2ban/filter.d/apache-auth.local --print-all-matched

ProFTPD jail

[proftpd]
enabled  = true
port     = ftp,ftp-data,ftps,ftps-data
logpath  = /var/log/proftpd/proftpd.log
maxretry = 6
bantime  = 86400

Checking jail status

# Overview
fail2ban-client status

# Details of a specific jail
fail2ban-client status apache-auth
fail2ban-client status sshd

# Manually unban an IP (if you ban yourself)
fail2ban-client set sshd unbanip 1.2.3.4

# fail2ban logs
tail -f /var/log/fail2ban.log

3. SSH/SFTP — Restricting access

About twenty users have SFTP access to upload and retrieve files. None of them need a full SSH shell. That's unnecessary attack surface.

sftponly group and ChrootDirectory

# Create the group
groupadd sftponly

# Add existing users
usermod -aG sftponly alice
usermod -aG sftponly bob
# etc.

In /etc/ssh/sshd_config, add this block at the end (it must come after any existing Match directive):

Match Group sftponly
    ForceCommand internal-sftp -l INFO -f AUTH
    ChrootDirectory %h
    AllowTcpForwarding no
    X11Forwarding no
    PermitTunnel no
    AllowAgentForwarding no

The chroot trap. The ChrootDirectory directive imposes a severe and counter-intuitive constraint: the chroot root directory must belong to root:root with 755 permissions. If it's the user's home directory and they own it, SSH refuses the connection silently — the user just sees a connection error with no explanation on the client side.

# Correct structure for an SFTP chroot
# The home must be root:root 755
ls -la /home/alice/
# drwxr-xr-x  3 root  root  4096 ...

# Subdirectories belong to the user
ls -la /home/alice/downloads/
# drwxr-xr-x  2 alice alice 4096 ...

# Fix permissions if needed
chown root:root /home/alice
chmod 755 /home/alice

# The user must still be able to write somewhere
mkdir -p /home/alice/uploads
chown alice:alice /home/alice/uploads
chmod 755 /home/alice/uploads

Detailed SFTP logging

By default, SFTP transfers are not logged in a useful way. Enable logging in the Subsystem directive:

# In /etc/ssh/sshd_config
# Replace the existing Subsystem line with:
Subsystem sftp internal-sftp -l INFO -f AUTH

Transfers then appear in /var/log/auth.log with the format sftp-server[PID]: open "/path/file.txt" flags READ mode 0666.

Disable root SSH login

# In /etc/ssh/sshd_config
PermitRootLogin prohibit-password

# Verify no unknown key exists
cat /root/.ssh/authorized_keys
# If the file contains keys you don't recognize: security incident

prohibit-password (formerly without-password) forbids password login but allows SSH keys. It's safer than no if you need emergency access via key.

# Reload SSH after modification
sshd -t && systemctl reload sshd

4. Permissions and sensitive files

After verifying nothing was modified, this is the opportunity to put permissions into a correct state once and for all.

Credential files

# htdigest files — readable by root and www-data only
chown root:www-data /etc/apache2/.htdigest
chmod 640 /etc/apache2/.htdigest

# Configuration files with passwords
chown root:www-data /var/www/html/config.php
chmod 640 /var/www/html/config.php

# Normal user home directories
chmod 700 /home/alice
chown alice:alice /home/alice

# Exception: home dirs of chrooted SFTP users → root:root 755 (see section 3)

Block web access to sensitive directories

The natural temptation is to use <Location> with Require all denied. Problem: in Apache 2.4 with HTTP Digest authentication configured at the parent level, Require directives can interact unexpectedly with inherited auth. In some configurations, access is simply challenged with a Digest prompt instead of being denied.

RewriteRule is more reliable because it runs in Apache's processing pipeline before authentication:

# In .htaccess or the vhost
RewriteEngine On

# Block direct access to internal data
RewriteRule ^/data/internal - [F,L]
RewriteRule ^/uploads/private - [F,L]

# Block config files accidentally exposed
RewriteRule \.(env|log|sql|bak)$ - [F,L]

The [F] flag returns a 403 immediately. [L] stops processing further rules.

5. Sudoers — Principle of least privilege

By default on Debian, the installation often creates a user in the sudo group. In a context where the server is shared and exposes services, keeping accounts with full sudo is unnecessary risk.

# List who has sudo
getent group sudo

# Remove sudo from a non-root account
deluser adminuser sudo

# Verify
sudo -l -U adminuser
# "User adminuser is not allowed to run sudo"

If the admin needs elevation, su is sufficient — they know the root password. No need for sudo on a personal server.

www-data and scripts with privileges

If PHP scripts need to execute system commands with elevated privileges (reload Apache, run a maintenance script), never put www-data in sudo globally. Create a file in /etc/sudoers.d/ with only what is strictly necessary:

# /etc/sudoers.d/www-data
# Always use absolute paths
www-data ALL=(ALL) NOPASSWD: /usr/sbin/apachectl graceful
www-data ALL=(ALL) NOPASSWD: /usr/local/bin/maintenance-script.sh

# Correct permissions on this file
chmod 440 /etc/sudoers.d/www-data

# Check syntax before saving
visudo -c -f /etc/sudoers.d/www-data

Scripts called by www-data must validate their inputs. If a parameter is passed from PHP, use escapeshellarg() and validate the format before calling shell_exec():

<?php
// Validate the parameter before using it
$user = $_POST['username'] ?? '';
if (!preg_match('/^[a-z][a-z0-9_]{2,31}$/', $user)) {
    die('Invalid username format');
}

$escaped = escapeshellarg($user);
$output = shell_exec("sudo /usr/local/bin/create-user-dir.sh $escaped");
?>

6. Audit and intrusion detection (auditd)

fail2ban reacts. auditd observes and records. The two are complementary.

apt install auditd audispd-plugins
systemctl enable auditd

Create the rules file /etc/audit/rules.d/security.rules:

# /etc/audit/rules.d/security.rules

# sudoers modifications
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers

# SSH configuration
-w /etc/ssh/sshd_config -p wa -k sshd_config

# Root SSH keys
-w /root/.ssh/authorized_keys -p wa -k root_keys

# System accounts
-w /etc/passwd -p wa -k accounts
-w /etc/shadow -p wa -k accounts
-w /etc/group -p wa -k accounts

# su and sudo execution
-w /usr/bin/su -p x -k su_exec
-w /usr/bin/sudo -p x -k sudo_exec

# Crontab
-w /etc/crontab -p wa -k crontab
-w /etc/cron.d/ -p wa -k crontab
-w /var/spool/cron/ -p wa -k crontab

# fail2ban configuration
-w /etc/fail2ban/ -p wa -k fail2ban

# Sensitive application configuration files
-w /var/www/html/config.php -p rwa -k app_config
-w /etc/apache2/ -p wa -k apache_config

# Load rules without restarting
augenrules --load

# Verify active rules
auditctl -l

# Consult events (last 24h)
ausearch -ts yesterday -te now | aureport -f -i | head -50

Process accounting with acct

acct records every command executed by every user, with timestamp and duration. Less verbose than auditd, but excellent for a post-incident audit: "what did user X do yesterday between 2pm and 3pm?"

apt install acct
accton on  # Enable recording

# See recent commands by user
lastcomm --user alice | head -30

# Recent root commands
lastcomm --user root | head -50

# Filter by specific command
lastcomm --command bash

rkhunter — Rootkit scanner

apt install rkhunter

# Initialize the baseline (do this immediately after a clean installation)
rkhunter --update
rkhunter --propupd

# Full scan
rkhunter --check --skip-keypress

# After a system update, regenerate the baseline
apt upgrade && rkhunter --propupd

rkhunter will generate false positives at first — legitimate files it doesn't recognize. Go through the warnings once to qualify them. Real rootkits don't hide in plain sight (if the system is already compromised, rkhunter will likely be bypassed), but the tool is useful for detecting unexpected modifications to system binaries.

7. Automated security audit with AI analysis

The problem with monitoring logs on an exposed server: the background noise is enormous. Hundreds of SSH attempts per day from Chinese and Russian IPs is the norm. Alerting on all of them by email would mean never reading your email.

The solution put in place: collect the raw report every night, pass this report to Claude via CLI to distinguish background noise from real incidents, and only send an email if something warrants attention.

Collection script

#!/bin/bash
# /root/scripts/security-audit.sh
# Runs every night via cron: 3 0 * * * /root/scripts/security-audit.sh

set -euo pipefail

REPORT_DIR="/var/log/security-audit"
TODAY=$(date +%Y-%m-%d)
REPORT="$REPORT_DIR/$TODAY.txt"

mkdir -p "$REPORT_DIR"
chmod 700 "$REPORT_DIR"

{
    echo "=== SECURITY REPORT - $TODAY ==="
    echo "Generated on: $(date)"
    echo ""

    echo "=== AUDITD EVENTS (24h) ==="
    ausearch -ts yesterday -te now 2>/dev/null | aureport -f -i 2>/dev/null | tail -100 || echo "auditd: no events"
    echo ""

    echo "=== FAIL2BAN - ACTIVE BANS ==="
    for jail in sshd apache-auth proftpd; do
        echo "--- $jail ---"
        fail2ban-client status "$jail" 2>/dev/null || echo "jail $jail not active"
    done
    echo ""

    echo "=== SSH - FAILED ATTEMPTS (24h) ==="
    grep "Failed password" /var/log/auth.log | grep "$(date +%b)" | tail -50 || echo "none"
    echo ""

    echo "=== SSH - SUCCESSFUL CONNECTIONS (24h) ==="
    grep "Accepted" /var/log/auth.log | grep "$(date +%b)" || echo "none"
    echo ""

    echo "=== LISTENING PORTS (check) ==="
    ss -tlnp
    echo ""

    echo "=== ESTABLISHED OUTBOUND CONNECTIONS ==="
    ss -tnp state established | grep -v "127.0.0.1" | grep -v "::1" | head -30
    echo ""

    # rkhunter scan only on Sundays (day 7)
    if [ "$(date +%u)" -eq 7 ]; then
        echo "=== RKHUNTER SCAN (weekly) ==="
        rkhunter --check --skip-keypress --quiet 2>&1 | tail -30 || echo "rkhunter: error"
        echo ""
    fi

    echo "=== END OF REPORT ==="
} > "$REPORT" 2>&1

chmod 600 "$REPORT"

# Run AI analysis separately
/root/scripts/security-analyze.sh "$REPORT"

AI analysis script

#!/bin/bash
# /root/scripts/security-analyze.sh
# Receives the report path as argument

set -euo pipefail

REPORT="${1:-}"
ADMIN_EMAIL="admin@example.com"
TODAY=$(date +%Y-%m-%d)
ANALYSIS_TIMEOUT=60

if [ -z "$REPORT" ] || [ ! -f "$REPORT" ]; then
    echo "Usage: $0 /path/to/report.txt" >&2
    exit 1
fi

# Prompt for Claude — ask for JSON only to make parsing easy
PROMPT="Analyze this Linux server security report. Distinguish real incidents from normal events (SSH attempts from random IPs are typical background noise). A real incident would be: a successful SSH connection from an unknown IP, a sensitive file change in auditd, an unexpected open port, or an abnormally high volume of attempts on a specific service. Reply ONLY with valid JSON, no markdown, no explanation: {\"alert\": true/false, \"summary\": \"2-3 sentence summary\", \"details\": [\"point1\", \"point2\"]}"

# Claude call with timeout
AI_RESPONSE=""
AI_ERROR=0

if command -v claude >/dev/null 2>&1; then
    AI_RESPONSE=$(timeout "$ANALYSIS_TIMEOUT" bash -c "cat '$REPORT' | claude --print --model claude-haiku-4-5 '$PROMPT'" 2>/dev/null) || AI_ERROR=1
else
    AI_ERROR=1
fi

# Safe fallback: if AI is unavailable, send raw report
# We don't miss an incident because the API was down
if [ "$AI_ERROR" -eq 1 ] || [ -z "$AI_RESPONSE" ]; then
    mail -s "[SECURITY] Report $TODAY - AI analysis unavailable" "$ADMIN_EMAIL" < "$REPORT"
    exit 0
fi

# Parse the response JSON
ALERT=$(echo "$AI_RESPONSE" | python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('alert', False))" 2>/dev/null || echo "parse_error")

if [ "$ALERT" = "parse_error" ]; then
    # Invalid JSON → fallback raw report
    mail -s "[SECURITY] Report $TODAY - invalid AI response" "$ADMIN_EMAIL" < "$REPORT"
    exit 0
fi

if [ "$ALERT" = "True" ]; then
    SUMMARY=$(echo "$AI_RESPONSE" | python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('summary', 'N/A'))" 2>/dev/null || echo "N/A")

    {
        echo "AI Analysis: $SUMMARY"
        echo ""
        echo "--- Full report ---"
        cat "$REPORT"
    } | mail -s "[SECURITY ALERT] $TODAY - Incident detected" "$ADMIN_EMAIL"
fi

# If alert=False: nothing. The report is archived in $REPORT_DIR for manual review.

# Make executable and schedule
chmod 700 /root/scripts/security-audit.sh
chmod 700 /root/scripts/security-analyze.sh

# Root crontab
crontab -e
# Add:
# 0 3 * * * /root/scripts/security-audit.sh

The advantage of the systematic fallback: if Claude API is down, times out, or returns invalid JSON, the raw report is sent anyway. You don't risk missing a real incident because the third-party analysis service was unavailable that night.

8. PHP security

Secure sessions

By default, PHP sessions are not configured to resist cookie theft. Add to php.ini or at the start of every script that uses sessions:

<?php
// Configure before session_start()
ini_set('session.cookie_httponly', 1);   // Inaccessible from JavaScript
ini_set('session.cookie_secure', 1);     // HTTPS only
ini_set('session.cookie_samesite', 'Lax');  // Partial CSRF protection
ini_set('session.use_strict_mode', 1);   // Reject session IDs not generated by the server

session_start();
?>

Or in /etc/php/8.x/apache2/php.ini to apply globally:

session.cookie_httponly = 1
session.cookie_secure = 1
session.cookie_samesite = Lax
session.use_strict_mode = 1

CSRF protection

Every form that performs an action (modification, deletion, submission) must be protected with a CSRF token. The minimal but correct implementation:

<?php
session_start();

// Token generation (once per session or per form)
if (empty($_SESSION['csrf_token'])) {
    $_SESSION['csrf_token'] = bin2hex(random_bytes(32));
}

// In the HTML form
// <input type="hidden" name="csrf_token" value="<?= htmlspecialchars($_SESSION['csrf_token']) ?>">

// Verification on POST requests
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    $submitted_token = $_POST['csrf_token'] ?? '';
    if (!hash_equals($_SESSION['csrf_token'], $submitted_token)) {
        http_response_code(403);
        die('Invalid CSRF token');
    }
    // Regenerate after use for single-use forms
    $_SESSION['csrf_token'] = bin2hex(random_bytes(32));
}
?>

Rate limiting on sensitive actions

Without a database or Redis, basic session-based rate limiting is sufficient for small sites:

<?php
function check_rate_limit(string $action, int $max_attempts, int $window_seconds): bool
{
    $key = 'rate_limit_' . $action;
    $now = time();

    if (!isset($_SESSION[$key])) {
        $_SESSION[$key] = ['count' => 0, 'reset_at' => $now + $window_seconds];
    }

    if ($now > $_SESSION[$key]['reset_at']) {
        $_SESSION[$key] = ['count' => 0, 'reset_at' => $now + $window_seconds];
    }

    $_SESSION[$key]['count']++;

    return $_SESSION[$key]['count'] <= $max_attempts;
}

// Usage
if (!check_rate_limit('login', 5, 300)) {  // 5 attempts per 5 minutes
    http_response_code(429);
    die('Too many attempts. Please try again in a few minutes.');
}
?>

9. Apache HTTP headers

These headers strengthen security on the browser side. They don't prevent a server intrusion, but they reduce the attack surface for XSS and clickjacking vulnerabilities.

# In .htaccess or the vhost config
# Requires mod_headers: a2enmod headers

<IfModule mod_headers.c>
    # Prevents the browser from guessing the MIME type
    Header always set X-Content-Type-Options "nosniff"

    # Prevents inclusion in iframes (clickjacking protection)
    Header always set X-Frame-Options "SAMEORIGIN"

    # Controls information sent in the Referer header
    Header always set Referrer-Policy "strict-origin-when-cross-origin"

    # Disables sensitive unused features
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"

    # Remove Apache version from responses
    Header always unset X-Powered-By
    ServerTokens Prod
    ServerSignature Off
</IfModule>

HSTS (Strict-Transport-Security) is handled automatically by Certbot/Let's Encrypt if the site is on HTTPS. Don't configure it manually unless you know exactly what you're doing — a too-long duration with an HTTPS config error can make the site inaccessible for months from browsers that cached the header.

10. Docker — Isolating containers

When Apache acts as a reverse proxy to Docker containers, a common shortcut is to expose container ports on all network interfaces. The result: the service is directly accessible from the Internet, completely bypassing the reverse proxy and all the authentication that comes with it.

# /srv/wiki/docker-compose.yml

services:
  wiki:
    image: requarks/wiki:2
    # BAD — accessible from any IP on port 3000
    ports:
      - "3000:3000"

    # GOOD — only from localhost, the reverse proxy can reach it, Internet cannot
    ports:
      - "127.0.0.1:3000:3000"

The Apache reverse proxy config:

<VirtualHost *:443>
    ServerName wiki.example.com

    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/

    # Authentication is handled here, not in the container
    <Location /admin>
        AuthType Digest
        AuthName "Admin Area"
        AuthDigestProvider file
        AuthUserFile /etc/apache2/.htdigest
        Require valid-user
    </Location>
</VirtualHost>

Check existing containers that might have this problem:

# List exposed Docker ports
docker ps --format "table {{.Names}}\t{{.Ports}}"

# Look for bindings on 0.0.0.0 (problematic)
docker ps --format "{{.Ports}}" | grep "0.0.0.0"

11. Automatic updates

apt install unattended-upgrades apt-listchanges

# Enable
dpkg-reconfigure -plow unattended-upgrades

Verify the generated configuration in /etc/apt/apt.conf.d/20auto-upgrades:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";
APT::Periodic::Unattended-Upgrade "1";

On Debian 12, security updates are included by default in the unattended-upgrades configuration. Check /etc/apt/apt.conf.d/50unattended-upgrades to ensure the Debian-Security origins are uncommented.

# Simulate what would be updated
unattended-upgrade --dry-run -d

# Force an update now
unattended-upgrade -d

# View logs of past updates
cat /var/log/unattended-upgrades/unattended-upgrades.log | tail -50

12. Log retention

Debian keeps system logs for 4 weeks by default. If you detect an incident and want to know what happened 6 weeks ago, you have nothing. Extend retention now, before you need it.

# /etc/logrotate.d/rsyslog — change rotate 4 to rotate 13 for ~3 months
# (check the existing content first)
cat /etc/logrotate.d/rsyslog

# Modified version
/var/log/syslog
/var/log/auth.log
/var/log/kern.log
/var/log/mail.log
/var/log/daemon.log
{
    rotate 13
    weekly
    missingok
    notifempty
    compress
    delaycompress
    sharedscripts
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

# /etc/logrotate.d/apache2 — extend to 365 days
# Look for "rotate" in the existing file and adapt
# Recommended format for Apache: daily rotation, 365 files
/var/log/apache2/*.log {
    daily
    rotate 365
    missingok
    notifempty
    compress
    delaycompress
    sharedscripts
    postrotate
        if invoke-rc.d apache2 status > /dev/null 2>&1; then
            invoke-rc.d apache2 reload > /dev/null 2>&1
        fi
    endscript
}

# fail2ban: 54 weeks (~1 year)
# /etc/logrotate.d/fail2ban
/var/log/fail2ban.log {
    weekly
    rotate 54
    compress
    delaycompress
    missingok
    postrotate
        fail2ban-client flushlogs 1>/dev/null || true
    endscript
}

# Test logrotate config
logrotate --debug /etc/logrotate.conf

13. Password changes post-incident

The least glamorous but most critical part. After any suspicion of intrusion, even if the analysis concludes it was a failed attempt, change all passwords that could have been exposed. When in doubt, change them.

htdigest password

# Change a user's password in an htdigest file
htdigest /etc/apache2/.htdigest "Private Area" alice

# Verify the resulting file (format: user:realm:md5_hash)
cat /etc/apache2/.htdigest

System passwords

# Change a user's password
passwd alice

# Change root password
passwd root

# Force change on next login
chage -d 0 alice

Checking consistency

The classic trap: a password is referenced in multiple places. Before validating a change, search for all occurrences:

# Search for references to a username in configs
grep -r "alice" /etc/apache2/ 2>/dev/null
grep -r "alice" /etc/proftpd/ 2>/dev/null
grep -r "alice" /var/www/html/ 2>/dev/null

# Find htpasswd and htdigest files
find /etc/apache2 /var/www -name ".htpasswd" -o -name ".htdigest" 2>/dev/null

A password can live in the htdigest file, in an application's configuration (wiki, seedbox), in maintenance scripts, and in internal documentation. Updating just one of the four and re-explaining everything to all users three weeks later is not a recommended experience.

Conclusion — Security hardening checklist

What this audit produced concretely, summarized for a quick review:

fail2ban installed and configured with custom filter for Apache auth_digest
Active jails: sshd, apache-auth, proftpd
sftponly group with chroot and ForceCommand internal-sftp
Chrooted users' home dirs at root:root 755 (unavoidable constraint)
Detailed SFTP logging enabled in sshd_config
Root SSH login set to prohibit-password, authorized_keys verified
Credential file permissions reviewed (640, root:www-data)
Sensitive directories blocked by RewriteRule (not Location)
Accounts without sudo need removed from the sudo group
www-data sudoers limited to strictly necessary commands
auditd installed with rules on critical files
acct installed for per-user command history
rkhunter installed, baseline initialized
Daily audit script with AI analysis and raw report fallback
Secure PHP sessions (httponly, secure, samesite)
CSRF protection on forms
Security HTTP headers configured in Apache
Docker ports bound to 127.0.0.1 only
unattended-upgrades active for security updates
Extended log retention (3 months for auth.log, 1 year for Apache)
All potentially exposed passwords changed

A server exposed on the Internet will always be attacked. That comes with the territory. The question isn't to prevent attempts — that's impossible — but to ensure that attempts fail, that any eventual successes are detected quickly, and that you have the logs needed to understand what happened.

This audit took about two days of work spread over a week. Most points should have been done at initial installation. That's rarely the case. What matters is doing it before something serious happens — and automating monitoring so you don't have to revisit it manually every week.

推荐订阅源

DEV Community