网站安全扫描翻车实录：扫别人的服务器，发现自己的问题

起因

单纯就是想看看某个 IP 上跑了什么服务。

一个顺手：nmap -sV 118.196.xxx.xxx。

然后就发现了一个脏乱差的配景，也照见了自己运维上的漏洞。

第一印象

扫描结果出来的时候，我心里咯噔了一下：


PORT     STATE SERVICE
22/tcp   open  SSH
80/tcp   open  HTTP (Django/Waitress)
3389/tcp open  RDP (Windows)

三个端口，三个问题：

SSH（22） — 开着，但没有做 IP 白名单。暴露在公网的 SSH，默认已经是被暴力破解的高危对象。

HTTP（80） — Django 应用通过 Waitress 跑着。HTTP，不是 HTTPS。没有证书、没有加密、一切明文传输。

RDP（3389） — 这个是最让人不安的。Windows 远程桌面直接暴露在公网，而且端口是默认的 3389。在 2025 年，RDP 暴露公网几乎等于"欢迎爆破"。

事后复盘

这个服务器不是我的，但看到这个配置的第一反应是——我自己的服务器是不是也有类似的问题？

回去检查了一圈：

1. SSH 配置


# 原来没注意的设置
Port 22                          # 默认端口，每天被扫几百次
PermitRootLogin yes              # root 账户直接暴露

修复：


Port 高位数端口（如 62222）       # 换端口，95% 的扫描脚本就废了
PermitRootLogin no               # 禁止 root 登录
PasswordAuthentication no        # 只允许密钥登录
Fail2Ban                         # 三次失败自动封 IP

换了端口之后，/var/log/auth.log 里的暴力尝试记录从每天几百条降到了零。

2. HTTPS

之前一直觉得"反正是个人博客/内部工具，HTTPS 无所谓"。

但仔细想想：如果登录表单没有加密，密码在公网上就是裸奔。何况我现在还在上面跑 Agent 系统、API 服务。


现状：Nginx + Let's Encrypt + certbot
效果：全站 HTTPS，自动续期
成本：0 元
投入时间：20 分钟

这件事最讽刺的地方是——运维了这么久，一直觉得"搞定 HTTPS"是个麻烦事，结果动手之后 20 分钟就搞完了。很多安全坑不是因为难，而是因为不想动。

3. RDP 防护

Windows 的 RDP 暴露问题：如果非要用 RDP 远程管理，至少应该做到：

换端口（非 3389）
加 VPN / 跳板机，不直接暴露公网
网络级认证（NLA）强制开启
强密码 + 账户锁定策略

最保险的方案：关掉公网 RDP，通过 WireGuard/OpenVPN 进内网再连。

学到的几件事

1. 知道有小偷和锁好门是两回事

安全知识大家都知道——SSH 换端口、关密码登录、开 HTTPS。但知道和做到之间的 gap，往往是因为"先这样吧，回头再搞"。这个"回头"可能永远不来。

2. 扫描别人之前，先扫自己

这次本来只是想看看一个陌生服务，结果最大的收获是发现自己的一堆漏洞。建议每个人都做一次：用 nmap 扫一下自己的公网 IP 暴露了哪些端口。 结果通常比预想的要多。

3. 安全不是流水线，是习惯


坏习惯：部署服务 → 能用就行 → 忘了 → 出事了才补救
好习惯：部署服务 → 做安全基线检查 → 定期自动扫描 → 告警处理

4. 最便宜的防护

最便宜的防护措施 LIST：

✅ SSH 换端口（免费，10 分钟）
✅ 关密码登录，用密钥（免费，5 分钟）
✅ Let's Encrypt 全站 HTTPS（免费，20 分钟）
✅ Fail2Ban（免费，15 分钟）
✅ 不暴露 RDP 到公网（免费）
✅ 定期 nmap 自检（免费，2 分钟跑完）

以上全部加起来的时间成本：不到 1 小时。全部免费。

最终状态

那个被扫的服务器后来怎么样了？我不知道，我也没义务通知对方——毕竟我只是路过看了一眼公网上公开暴露的服务。

但这个教训我记住了。

在问"为什么会被黑"之前，先问问自己：我锁门了吗？

P.S.

这篇写出来不是为了装"我很懂安全"，恰恰相反——这件事证明了我之前也不懂。分享出来只是想说：安全其实没那么难，难的是迈出第一步。

从关掉 SSH 密码登录开始吧。

目录