内容摘要：上周二凌晨两点，我收到一条告警：某台对外提供API服务的机器在十分钟内出现了四百多次SSH登录失败。这不是演习。我爬起来连上VPN，翻了眼日志，发现攻击源来自三个不同国家的IP，用的都是常见弱口令字典

上周二凌晨两点，网络我收到一条告警：某台对外提供API服务的安全机器在十分钟内出现了四百多次SSH登录失败。这不是定期演习。我爬起来连上VPN，检查记录翻了眼日志，网络发现攻击源来自三个不同国家的安全IP，用的定期都是常见弱口令字典。这台机器上个月刚做过检查，检查记录但当时没人注意到sshd配置里还开着密码登录——大家都以为密钥认证已经覆盖了全部账户。网络

这就是安全为什么我坚持每三十天做一次手动巡检。自动扫描工具能发现已知漏洞，定期但配置漂移、检查记录临时开的网络端口、半年前离职员工留下的安全测试账号，这些东西不会自己蹦到报告里。定期下面这张表是我上个月实际记录的内容，脱敏后贴出来。

一、边界与暴露面

先看外网能碰到什么。用nmap对公网IP段做一次全端口扫描，重点不是看开放了哪些端口，而是看哪些端口不该开。我遇到过一台数据库服务器，27017端口对着公网开放了八个月，运维说“防火墙策略里限制了源IP”，但实际规则写的是0.0.0.0/0。这种错误在纸面检查里查不出来，必须实际从外部发起连接测试。

这次扫出来三个非预期端口：8080、8443、9090。8080是开发临时起的调试服务，8443是某中间件管理后台，9090是监控系统的Prometheus接口。后两个有认证，但8080那个连登录都没有，返回了一个JSON格式的堆栈信息。已通知对应负责人关闭，并在防火墙上加了临时拒绝规则。

二、认证与权限

弱口令这事，工具扫是一回事，人工翻是另一回事。我习惯直接去翻/etc/passwd和数据库的user表，看有没有“test”“temp”“admin2”这类账号。这次在MySQL里找到一个叫“report_user”的账号，密码是八位纯数字，权限是ALL PRIVILEGES。问了一圈，是去年做报表系统时外包团队留下的，项目结束后没人清理。

SSH密钥也要看。检查authorized_keys文件里有没有陌生指纹。我见过最离谱的情况是，某台跳板机的root账户下挂了十七个公钥，其中三个属于已经离职的员工。删除这些密钥不需要重启任何服务，但如果不查，它们会一直有效。

三、日志与异常行为

日志这块，重点看三个地方：登录失败记录、sudo操作、以及计划任务。CentOS上直接grep "Failed password" /var/log/secure | awk '{ print $(NF-3)}' | sort | uniq -c | sort -rn | head -20，能快速看出哪些IP在暴力破解。如果某个IP失败次数超过一百，直接封掉，不用犹豫。

计划任务里藏后门是常见手法。检查/var/spool/cron/下所有用户的crontab，以及/etc/cron.d/目录。这次发现一个每五分钟执行一次的脚本，内容是从某个境外IP下载文件并执行。问下来是之前做压力测试时留下的，但脚本里的域名已经过期，被别人注册了。这种就是典型的供应链隐患。

四、补丁与配置基线

补丁不用追求最新，但要确保没有已知的高危漏洞未修复。用yum update --security或apt list --upgradable看安全更新列表。这次有三台机器还跑着OpenSSL 1.0.2，虽然业务没直接暴露，但内部横向移动时这就是跳板。

配置基线我只看几个关键项：SSH是否禁止root登录、是否关闭密码认证、防火墙默认策略是否为DROP、SELinux或AppArmor是否处于enforcing状态。这些配置一旦被改回去，通常意味着有人图方便，或者有自动化脚本覆盖了配置。

五、记录与跟进

检查完不是写个报告就完了。我会把每个问题拆成三个字段：风险描述、临时缓解措施、长期修复方案。临时措施必须当天完成，长期方案给两周窗口期。比如上面那个8080端口，临时措施是防火墙拒绝，长期方案是开发团队把调试接口改成仅内网访问并加认证。

下次检查时第一件事就是翻上次的记录，看哪些“长期方案”还没落地。经验告诉我，超过三成的问题会拖到第二次检查还没修。这不是技术问题，是排期问题。所以记录里要写清楚责任人，不写“开发团队”，写具体的人名。

这台机器的事最后处理完了。攻击者没进来，但那个8080端口如果再多开两周，结果不好说。网络安全检查不是走形式，是跟攻击者抢时间。你漏掉一个细节，对方就可能多一条路径。