游客发表
| 巡检项 | 结果 | 备注 |
|---|---|---|
| 防火墙规则变更 | 异常 | 凌晨3点新增了一条放行TCP 3389的网络规则，来源IP段为203.0.113.0/24。安全没人提交过变更单。巡检 |
| 核心交换机日志 | 告警 | 昨晚22:47，记录某台服务器向外部IP 198.51.100.7发起了大量SSH重试，网络持续了11分钟。安全源端口随机，巡检目标端口固定22。记录 |
| Web应用防火墙 | 正常 | 拦截了两次SQL注入尝试，网络均来自同一个巴西IP。安全攻击payload是巡检常见的union select，没有变种。记录 |
| 终端杀毒软件 | 正常 | 全公司300台终端，网络有12台超过72小时未更新病毒库。安全IT部说其中7台是巡检会议室长期不关机的展示机。 |
| 数据库审计 | 可疑 | 财务库的只读账号在今天下午14:02-14:05之间，连续查询了员工薪资表，每次只取一行。正常业务不会这么干。 |
巡检是凌晨两点做的，因为我刚被电话叫醒——那台防火墙的规则变更触发了告警。值班同事说他在睡梦中听到短信提示音，爬起来看了一眼，差点把手机摔了。新增规则的时间是凌晨3点，但告警延迟了23小时才推送，这本身就是个问题。 我盯着那条规则看了十分钟。放行3389端口不稀奇，但来源IP段是203.0.113.0/24，这是文档保留地址，正常业务根本不会用。更蹊跷的是，规则描述栏写着“临时测试”，连个工单编号都没有。我们公司有明文规定，任何防火墙变更必须走ITIL流程，哪怕改一条端口都得附上审批人名字。这条规则像凭空长出来的。 顺手翻了翻核心交换机的日志。果然，昨晚22:47就有动静了——一台内部服务器在向198.51.100.7疯狂做SSH重试。那个IP我认得，上个月威胁情报平台标记过它，关联了一个挖矿木马的C2节点。重试了11分钟就停了，像是脚本自动跑的，没成功就放弃了。但问题是，这台服务器是跑CRM系统的，平时根本不该主动外连SSH。 我截图发到运维群里，没人回复。过了半小时，负责数据库的小张冒了句：“财务库的只读账号今天下午查了薪资表，连续三次，每次只取一行。” 这话让我后背发凉。只读账号是给报表系统用的，查询模式固定，每次都是批量拉全量数据。单行查询？那更像是有人在试某个特定员工的工资。 我泡了杯浓茶，把巡检表上的每一项重新过了一遍。Web防火墙那边倒是干净，拦了两次SQL注入，都是老掉牙的payload，估计是扫描器在瞎撞。终端杀毒有12台机器过期，全是会议室那几台常年不关的展示机，这个我懒得计较——它们连外网都访问不了，风险可控。 真正让我睡不着的是那条防火墙规则和数据库查询之间的关联。时间上不挨着，一个凌晨，一个下午，但手法都透着股“懂行”的味道——知道用保留IP段藏来源，知道用只读账号规避权限告警。我怀疑是内部人干的，但没证据，只能先把规则回滚，把那个服务器的外连权限掐了，再给财务库的只读账号加了个行级访问限制。 填完这张表，天已经蒙蒙亮了。我看了眼表尾的“处理意见”栏，写了句“持续观察三天，重点盯SSH外连和财务库的异常查询模式”。巡检这种事，大部分时候是走形式，但偶尔，你得相信那些凌晨三点的告警——它们不会无缘无故响。