rockballslab

2 เดือนที่ผ่านมาdiscuss

[flagged]

2 เดือนที่ผ่านมาdiscuss

SSH host key leak via ptrace, and why I almost nuked my prod patching it

---

Last week my automated security scanner flagged CVE-2026-46333, also known as ssh-keysign-pwn. The vulnerability is a ptrace race condition in the Linux kernel that lets any local unprivileged user read the SSH host private keys of the server, and as a bonus, /etc/shadow.

The mechanics are straightforward. When a suid or sgid process exits, there is a brief window during which ptrace() can attach and read its open file descriptors. ssh-keysign is suid. So is chage. An attacker with a local shell account, a tight loop, and a bit of patience can win that race and walk away with your server's SSH identity and your password hashes.

A public PoC dropped the same day as disclosure. The CVSS score is 5.5 (Medium), which badly undersells it. On a server where SSH is your only entry point, leaking the host private key means an attacker who later gets a network position can silently MITM every future connection. No warning. No changed fingerprint.

The kernel patch landed in Ubuntu's linux-generic 6.8.0-117 (USN-8278-1). But applying it requires a reboot. The interim mitigation is a single sysctl:

    echo "kernel.yama.ptrace_scope = 2" | sudo tee /etc/sysctl.d/99-ptrace.conf
    sudo sysctl -p /etc/sysctl.d/99-ptrace.conf

Value 2 means only processes with CAP_SYS_PTRACE can use ptrace. Debuggers stop working for regular users. On a production VPS that is an acceptable tradeoff.

Now for the embarrassing part.

My security report also recommended applying the kernel update and rebooting. I copy-pasted the commands into a terminal without thinking:

    sudo apt-get update && sudo apt-get dist-upgrade -y
    sudo reboot

I caught myself before hitting Enter. The server was running 45 Docker containers: three PostgreSQL databases, two Redis instances, a voice agent, n8n, Typebot, Traefik, Prometheus, Grafana, and several production SaaS apps with live users.

A blind dist-upgrade with -y on a server you have not reviewed in weeks is risky. Packages get added. Packages get removed. Things break in ways that are annoying at 2am. And a reboot without a maintenance window means downtime with zero preparation.

The thing is, the mitigation does not require a reboot at all. sysctl -w applies immediately. I was already protected the moment I ran that one-liner. The reboot could wait for a proper maintenance window.

Two lessons I am taking away.

One: CVSS scores describe the vulnerability, not your exposure. A 5.5 on a server where SSH is the perimeter is not a 5.5 in practice.

Two: "apply patch and reboot" is not a procedure. On a production server with stateful services it is a plan waiting to fail. The question is always: what is the fastest mitigation that requires zero downtime, and when is the maintenance window for the rest.

Check your ptrace_scope:

    sysctl kernel.yama.ptrace_scope

If it returns 0 or 1, you are exposed on any unpatched kernel. Two commands fix it with no reboot required.

rockballslab

2 เดือนที่ผ่านมาdiscuss

[flagged]

rockballslab

2 เดือนที่ผ่านมาdiscuss

if you prefer to setup it all alone

rockballslab

2 เดือนที่ผ่านมาdiscuss

[dead]

rockballslab

3 เดือนที่ผ่านมาdiscuss

sounds great, I'm having a look at your project

rockballslab

3 เดือนที่ผ่านมาdiscuss

[dead]

rockballslab

3 เดือนที่ผ่านมาdiscuss

[dead]

rockballslab

3 เดือนที่ผ่านมาdiscuss

A bare or default-configured server is an easy target — visible and attackable within minutes.

VPS-Secure is not just an install script: it's an ultra-robust security foundation, designed to turn a bare VPS into a production-ready server with significantly stronger protection against attackers.

15 minutes, one single command to turn your server into a Fortress — ready to host your services with complete peace of mind.

Hey, I'm Fabrice. Entrepreneur, founder of multiple SaaS products, and Zero Trust advocate.

I built VPS-SECURE out of necessity: I wanted a tool capable of turning any bare server into an impenetrable fortress in minutes — without sacrificing service stability.

"Eat your own dog food": This is exactly the configuration I use to harden my production servers and confidently run n8n stacks, microservices, and AI agents in production.

## What VPS-SECURE does

1 command — 15 automatic steps — zero technical expertise required.

| # | What | Why | |---|---|---|

| 1 | Creates `vpsadmin` user | No more root — impossible to make a fatal mistake |

| 2 | SSH on port 2222, key-only | Connection restricted to `vpsadmin` only. *GSSAPI disabled* (CVE-2026-3497) |

| 3 | System update + encrypted DNS + `/tmp`, `/var/tmp` and `/dev/shm` secured | Closes known vulnerabilities. DNS over TLS activated *before* any download — eliminates the DNS poisoning window. `/tmp`, `/var/tmp` and `/dev/shm` mounted `noexec` — malicious scripts cannot execute there |

| 4 | *CrowdSec* | Detects and bans malicious IPs. Installed via GPG-signed repository with hardcoded fingerprint verification — integrity guaranteed |

| 5 | *UFW* (firewall) | Everything blocked except ports 2222, 80 and 443. Docker forwarding is targeted — not global |

| 6 | *Docker* Engine + Compose v2 | Docker runs applications in isolated "boxes" (containers). Configured to *not* bypass UFW — exposed ports remain under firewall control. NAT rule added in UFW — containers have internet access |

| 7 | unattended-upgrades | Security patches installed automatically every night. *Docker CE* included in automatic updates. *snapd blacklisted* (CVE-2026-3888) |

| 8 | Kernel hardening | *35 parameters*: network (spoofing, SYN flood, ICMP...) + ASLR + ptrace + core dumps + perf events + *AppArmor userns restriction (CIS compliance)* |

| 9 | *auditd* | Logs everything: SSH, sudo, Docker, sensitive files, crontabs, `/etc/hosts`. *Anti-rootkit monitoring* — daily `voidlink-detect` scan at 02:30 |

| 10 | 2 GB Swap | Emergency virtual memory — prevents crashes |

| 11 | *rkhunter* | Scans for backdoors and rootkits. Daily automated scan at *00:00 UTC* — independent of Telegram |

| 12 | Unnecessary services disabled | avahi, cups, bluetooth, ModemManager disabled — every active service = attack surface (CIS 2.x). Ctrl-Alt-Delete masked (DISA STIG) | | 13 | *Telegram* alerts | Daily security report + instant alert on every SSH login |

| 14 | *Endlessh* (honeypot port 22) | SSH is on port 2222 — port 22 is free. Endlessh captures it and keeps bots connected for hours by sending an infinite SSH banner. They can't attack elsewhere during that time |

| 15 | *AIDE* (integrity monitoring) | SHA512 hash of all system binaries at install time. Daily scan at 03:00 — any modification (replaced binary, backdoor, rootkit) triggers an alert in the Telegram report. After an OS update, manually re-run the baseline (command provided) |

15 minutes, one single command to turn your server into a Fortress — ready to host your services with complete peace of mind.

rockballslab

Submissions

[untitled]

[untitled]

[untitled]

Your VPS Is a Sitting Duck

1597 bots blocked in 24h on a standard VPS – is yours protected?

Turn a bare VPS into an operational fortress in 15 minutes and 1 command

Turn a bare VPS into an operational fortress in 15 minutes and 1 command

comments