在安全圈里，“肉鸡”指的是已经被远程控制、但表面上仍在正常运行的计算机或服务器。机器主人往往毫不知情，它的算力、带宽和公网地址却被别人拿去做别的事。云服务器尤其需要留意，因为它通常 24 小时在线、带宽充足，一旦被控制，危害比普通家用电脑大得多。
有不少人觉得“云厂商有安全保障，服务器就不会出事”。其实阿里云这类平台主要负责底层基础设施，比如机房、虚拟化层和网络隔离。操作系统上的账号、软件版本、服务配置和业务代码，仍然要由用户自己维护。这种责任划分在云安全领域通常被称为共担责任模型，搞清楚哪些归自己管，是做防护的第一步。
常见的入侵路径
云服务器被控制，多数情况下卡在几个基础环节上。
- 弱口令和密码复用。SSH、数据库、后台页面用了简单密码，或者和其他网站一样。自动化工具批量尝试时，这类机器最先中招。
- 组件长期不更新。Web 框架、中间件、插件的漏洞公开已久，服务器却一直没有升级。
- 端口开得太多。数据库、Redis、Docker API、远程桌面这类服务本不该对公网开放，但安全组规则里常常直接放行了。
- 遗留的测试环境。临时搭的测试站点、调试接口上线后没人记得关，往往是最薄弱的入口。
- 后门和计划任务。攻击者进来后，通常会留下定时任务、隐藏账号或自启动脚本，保证重启之后还能再次控制机器。
一个被遗忘的测试服务器示例
下面是一个为说明问题整理的示例，并非真实事件。某团队在阿里云上买了一台 ECS 用来做接口联调，装了开源数据库管理工具，为了图方便，把 22 端口和数据库端口都设成了全网开放。项目上线后，这台机器就被忘在了一边。
过了一段时间，运营同事发现带宽费用明显上涨，CPU 长时间占满。运维登录后看到一批陌生进程，计划任务里多了一条每隔几分钟执行一次的脚本。顺着线索查下去，数据库管理工具的旧版本有已知漏洞，默认管理员密码也没改，机器早就被别人控制，还被用来对外发出大量无关请求。
这类问题的根源其实很朴素。没有资产台账，没人对这台机器负责；端口和口令没有基线，软件更新也不在日常流程里。
怎么判断服务器是否已经中招
怀疑被控制时，先看几个能直接观察到的现象，别急着重装。
- 没有业务高峰的时段里，CPU、内存或网络流量持续偏高。
- 出现来路不明的进程，或者进程名和系统程序相似，但路径不对。
- 检查 crontab、systemd timer 和开机启动项，看有没有陌生命令。
- 查看账号列表，重点是新增用户、拥有 sudo 权限的账号，以及 authorized_keys 里不认识的 SSH 公钥。
- 到阿里云控制台看登录日志和安全中心的告警记录，再对照云监控里的流量曲线。
如果已经确认被入侵，先对磁盘和日志做快照，再动手清理。否则删掉的可能正是事后溯源需要的证据。
清理与恢复的基本思路
清理肉鸡，光杀掉几个进程远远不够。攻击者通常会留下多个持久化点，只删表面文件，过不了多久机器又会被控制。比较稳妥的顺序如下。
- 先隔离服务器。通过安全组限制外网访问，只保留运维人员的固定 IP。
- 保存日志，以及进程和网络连接的现场信息，方便分析入侵路径。
- 逐项排查定时任务、启动项、SSH 授权密钥、异常账号和隐藏文件，逐一清理。
- 修改系统账号、数据库账号和应用后台的密码，同时轮换 API 密钥。
- 修补已知漏洞，升级受影响的组件。如果无法确定机器是否干净，直接重建实例更省心，再从可信的代码和备份中恢复业务。
日常防护的几个动作
事后补救很耗时间。前期把下面几件事做好，大部分常见风险都能挡在门外。
- 收紧暴露面。安全组默认只开必要端口，数据库和缓存只允许内网访问。远程登录尽量改用密钥认证，并限制来源 IP。
- 统一口令管理。用密码管理工具生成强随机口令，不同系统之间不复用，定期轮换。
- 建立更新节奏。固定一个补丁窗口，关注云厂商和组件官方的安全公告，别等被攻击了才想起升级。
- 开启安全防护服务。阿里云安全中心可以做基线检查、异常登录提醒和木马检测。配置告警通知时，最好按业务的实际负责人来设置，免得消息没人看。
- 维护资产台账。每台服务器都要写明负责人、用途和计划下线时间。测试环境用完就释放，别让它一直挂着。
- 每月巡检一次。检查账号、端口、计划任务和流量趋势，把它变成固定动作，而不是出了事才想起来看。
如果你手上正有一台可疑的服务器，建议先从日志和计划任务查起。能确认干净再清理，拿不准的话就重建，并从可信的代码和备份恢复业务。
