<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Incident on Wilson Wu</title><link>https://wilsonwu.me/tags/incident/</link><description>Recent content in Incident on Wilson Wu</description><generator>Hugo -- 0.127.0</generator><language>zh-CN</language><lastBuildDate>Fri, 14 Aug 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://wilsonwu.me/tags/incident/index.xml" rel="self" type="application/rss+xml"/><item><title>使用 Azure 托管 PostgreSQL 降低自建数据库的安全风险</title><link>https://wilsonwu.me/blog/2026/azure-managed-postgresql-vs-self-hosted-security/</link><pubDate>Fri, 14 Aug 2026 00:00:00 +0000</pubDate><guid>https://wilsonwu.me/blog/2026/azure-managed-postgresql-vs-self-hosted-security/</guid><description>问题的背景 最近，一台部署在 Azure 上的 Linux 服务器突然出现 CPU 持续 100% 的情况。排查后发现，服务器上存在一个以 postgres 用户身份运行的恶意程序，并通过 cron 定时任务维持运行。
这台服务器上的 PostgreSQL：
没有通过 Azure NSG 向公网开放 5432； 没有被当前业务使用； 业务实际使用的是本机 MySQL； 但 PostgreSQL 服务仍然安装并运行； 系统中保留了 postgres 用户、主目录、cron 和历史脚本。 这次事件说明：
PostgreSQL 没有向公网开放，并不代表服务器上与 PostgreSQL 相关的组件完全没有风险。
需要特别说明的是，目前的证据只能证明恶意程序利用了 postgres 操作系统用户及其目录进行持久化，不能证明攻击者一定是通过 PostgreSQL 的 5432 端口进入服务器的。初始入口也可能是历史配置、SSH、Web 应用、容器、旧镜像或其他漏洞。
如果生产环境确实需要 PostgreSQL，但没有必须自建数据库服务器的特殊要求，建议优先使用：
Azure Database for PostgreSQL，并通过私有网络访问，关闭公共网络入口。
这样可以减少自建数据库所带来的操作系统用户、SSH、cron、systemd、补丁、备份和主机入侵等风险。
发现问题：服务器 CPU 持续占满 最初是在服务器上执行 htop 时发现异常。
从截图中可以看到：
服务器共有 4 个 CPU 核心； 4 个核心全部达到 100%； Load Average 长期维持在 4 左右； 多个进程以 postgres 用户运行； 进程名称为随机字符串 dzZ7yVrxv7； 单个进程的 CPU 使用率超过 200%； 进程占用了大量内存。 进一步执行：</description></item></channel></rss>