这是「把自己部署到互联网上」系列的第 15 篇。
前几篇一直在写服务器安全：不要急着部署项目，不要长期用 root 登录，分清安全组和防火墙，也不要随便开放数据库端口。这些看起来感觉有点水文章的嫌疑:dog:
查看日志
直到我真的去看服务器日志，看到陌生 IP、异常请求和登录尝试，才有了更直接的感受：公网服务器不是等你部署项目的安静机器。只要它有公网 IP，就已经进入了一个会被扫描、探测和尝试访问的环境。
在看日志之前，我也有过一种侥幸：我这只是个人博客，没有访问量，也没有什么值钱业务，肯定没人专门盯上。我们平时说安全、后门等，一想到就是大公司、核心业务、支付接口和用户数据。个人项目听起来太小了，Hacker 瞧不上。
但是公网扫描可区分不出来的。大多数情况下是通过自动化脚本在扫 IP 段、端口、服务指纹、常见路径、默认配置和弱口令。它不关心你是谁，也不知道网站有没有名气。只要服务器在公网，只要有端口开放，就可能进入扫描范围。这也是我看到日志后最大的变化：安全风险不一定来自“我很重要”，而是“我暴露在公网”。
触发动机
事情的触发点很普通。我在做服务器初始化时，查看基础日志和访问记录，原本只是想确认 SSH 登录、服务访问有没有异常。结果发现，日志里并不只有我自己的操作。
有些来源在访问不存在的路径，有些像是在探测常见后台入口，有些在尝试 SSH 登录，还有一些请求明显不是正常用户行为。值得重视的是现象本身：服务器刚暴露在公网，就已经开始被自动化流量扫到。
查看的当时记录统计，4个多小时，类似访问和尝试超过了 517 次。
# 换算下
(4.5 * 3600) / 517 ≈ 31.3
也就是说，平均大约每31秒就被扫描一次。
博客现在还没经过推广，服务器已经被互联网半分钟“宠幸”一次。
之前写不要用 root、不要开放数据库端口、要理解安全组和防火墙，多少还是预防性的判断。在看到日志之后，这些预防变成了现实问题。
如果一直允许 root 密码登录，会怎样？
如果 SSH 密码很弱，会怎样？
如果数据库端口开放给全网，会怎样？
如果安全组里放行了所有 IP，会怎样？
如果我根本不看日志，会怎样？
这些问题一下子变得具体。也正因为这样，更加确定：买完服务器后先处理基础安全，而不是立刻部署项目。服务器不是业务上线才面对公网，实例从它创建成功并获得公网 IP 的那一刻起，就已经进入公共网络环境。
扫描不等于攻破
再说清楚一点，不贩卖蕉绿：服务器被扫描，不等于已经被攻破。公网服务器被扫描很常见，很多请求只是自动化探测，可能会尝试常见路径、弱口令或已知漏洞。看到扫描日志，不必要恐慌。
但也不能无视。扫描本身是在提醒你：服务器已经处在一个不友好的网络环境里。如果基础配置太随意，扫描就可能变成真正风险。比如 root 允许密码登录，SSH 使用弱密码，数据库端口暴露公网，Redis 没有密码还对外开放，Docker 服务端口误暴露，Nginx 默认页面泄露信息，系统长期不更新。
扫描不可怕，可怕的是服务器刚好有这些缺口。
应对方案
看到这些记录后，我没有急着装复杂工具，而是先回到基础检查。
- 检查
SSH登录策略。root是否允许直接登录，普通用户是否可用，是否使用强密码或密钥，登录失败日志是否异常。 - 检查安全组规则。哪些端口对公网开放，来源是不是
0.0.0.0/0，有没有临时开放后忘记关闭的端口。 - 检查系统防火墙。除了
SSH、80、443，是否还有多余端口开放。 - 确认数据库没有暴露公网。
MySQL、PostgreSQL、Redis这类端口有没有监听在公网地址，Docker Compose里有没有不必要的ports映射。 - 确认日志记录。开始没必要就搭完整监控，但至少要知道
SSH日志、系统日志、Nginx日志和容器日志在哪里。没有日志记录，就无法判断你的服务器正在经历什么。
这些检查都很基础，但能先把明显风险降下来。
看到登录尝试后，我也更理解 fail2ban 的作用。它不是万能安全工具，不能替代强密码、密钥登录、安全组和防火墙。但它能根据日志识别异常登录尝试，并在一定时间内封禁来源 IP。对个人服务器来说，它的价值主要是减少低级爆破带来的噪音和风险。
但 fail2ban 只能作为补充，不是根基。根基依然是：不用弱密码，不长期开放 root 登录，不乱开端口，不暴露数据库，不忽视日志。
服务器安全不是大项目才需要考虑的事。个人服务器与企业级安全体系还是有很大的差距的，但至少要做到：权限有边界，端口有控制，数据库不裸奔，日志能查看，异常能发现，配置能解释。
下一篇，我会把这些基础动作整理成一份更具体的清单：个人服务器基础安全清单，包括 fail2ban、SSH 和健康检查。
本文由 楸木 原创，转载请注明出处。