服务器防渗透

去年秋天，服务我帮一个做跨境电商的器防朋友看服务器。他的渗透后台被人种了挖矿木马，CPU常年跑满，服务订单数据还被拖走了一份。器防查日志发现，渗透攻击者是服务从一个没改默认密码的Redis端口进来的。整个过程不到三分钟——扫描、器防尝试、渗透写入SSH公钥、服务提权。器防我问他为什么Redis会暴露在公网，渗透他说图方便，服务开发时直接连的器防。这种"图方便"三个字，渗透我听过太多次了。

服务器防渗透这件事，核心就一句话：假设所有暴露在公网的服务都会被盯上，然后逐个掐掉不必要的入口。 听起来简单，做起来全是细节。

端口不是越多越好

很多人拿到服务器第一件事是装面板、开端口、跑各种服务。宝塔面板装完默认开8888，MySQL开3306，Redis开6379，MongoDB开27017。这些端口一旦对公网开放，等于在门口挂了块牌子写"欢迎尝试"。

我自己的做法是：除了80和443，其他一律走SSH隧道或者内网。Redis绑127.0.0.1，MySQL只监听内网IP，面板改端口加IP白名单。有人觉得麻烦，但比起半夜被叫起来处理入侵，这点麻烦不算什么。

有个细节值得说：netstat -tlnp这个命令应该常跑。你会发现自己都不知道什么时候多开了几个监听端口。上次我在一台"干净"的测试机上跑了一下，发现Docker默认把容器端口映射到了0.0.0.0，而那个容器跑的是个有漏洞的旧版Nginx。

SSH是重灾区

SSH暴力破解每天都在发生。我自己的日志里，一台暴露22端口的机器平均每天收到三千多次尝试。换端口能挡掉大部分脚本小子，但挡不住有针对性的扫描。

密钥登录加禁用密码认证，这是底线。再配上fail2ban，五次失败直接封IP。我还会把root登录关掉，用普通用户加sudo。听起来是常识，但每次帮人排查，总能看到PermitRootLogin yes还开着密码认证的配置。

有个坑要注意：改SSH配置之前，先开一个保持连接的会话，改完测试新会话能登录再退出旧的。我吃过这个亏，改错了配置，把自己关在外面，最后只能走VNC救援。

Web应用才是真正的战场

端口和SSH是外围，真正的渗透入口往往在Web应用本身。SQL注入、文件上传、反序列化、SSRF——这些漏洞不需要你开多余端口，一个正常的80端口就够了。

我见过一个案例：某后台管理系统，登录接口没做频率限制，验证码形同虚设。攻击者用固定密码字典跑了两个小时，进了管理员账号，然后通过文件上传功能传了个WebShell。整个过程没有用到任何高级技巧。

防这类攻击，WAF能挡掉一部分，但别指望它万能。代码层面的输入过滤、参数化查询、上传文件类型白名单，这些才是根本。另外，后台路径别用/admin，改成随机字符串，能减少大量自动化扫描。

日志和备份

被入侵了不可怕，可怕的是不知道什么时候被入侵的。日志要集中收集，别只存在本机——攻击者进来第一件事往往是清日志。我习惯用rsyslog把关键日志实时推到另一台机器，成本不高，但事后追溯时能救命。

备份同理。本地备份和服务器一起被加密的案例太多了。异地备份加版本控制，定期做恢复演练。没演练过的备份，不能算备份。

最后说个观察：大部分被渗透的服务器，问题不在于攻击者多厉害，而在于管理员默认"没人会盯上我"。一台暴露在公网的机器，从上线那一刻起就在被扫描。防渗透不是一次性的配置，是持续的习惯——定期更新、定期审计、定期删掉不用的服务。做到这些，已经能挡住九成以上的麻烦。