经历的安全故障两则

安全有感

最近 B 站 UP 主的 NAS 被黑事件在网上被炒的很火，恰恰我早些年也经历过一两次安全事件，再此记录下，也告诫下后来者，安全无小事，没事别瞎关防火墙～

Memcached 放大攻击

有一段时间IDC机房进行搬迁，从电信机房搬迁到联通机房，网络设备要重新调试，当时为了省事就直接操作的齐治堡垒机，调试的过程中无法多人并发连接进来，所以当时简单粗暴的停了防火墙开始调试，调试完毕之后，防火墙忘了关了，尴尬了，齐治堡垒机用到了 Memcached, 正好那段时间 Memcached 放大攻击风头正紧，中招了，现象就是入口带宽被打满，原先200M的出口带宽，加到500M依旧是瞬间被打满，最后采取的措施是堡垒机器断网，OPS 采用预留的备用方案登陆机器维护，联系厂家重做系统～

至于如何定位到是 Memcached 的问题，是因为当时监控做的都比较全面，首先发现入口带宽被打满，然后具体到设备的话就是堡垒机带宽占用比较大，而且处于不可用状态，再然后联系 IDC 的人帮忙把堡垒机的外网断开流量立马下来了，结合安全大佬的帮忙验证，这才得出结论，PS: 齐治堡垒机也是基于 Linux 的，只是定制化关闭了很多其他功能～

PS: 齐治的管理账号密码分两套，一套是交付给用户，一套是他们售后人员知道(不知道现在是不是有改动)

关于 Memcached的相关信息: https://www.freebuf.com/news/...

DDG 僵尸网络(挖矿的一种)

再一次就是 DDG 挖矿僵尸网络，而且是变异的，事情的起因是由于和要三方联调，对方要求我司提供独立的公网IP进行测试操作，我组小伙伴就和网络同事进行的联调服务对应的机器的外网端口映射操作, 入口是 F5，不曾想直接把这台服务器直接映射出去了，导致22端口暴露出去，机器上安装有 Zabbix, Zabbix 对应的账号是 /bin/bash, 而且是弱密码，事后根据日志回溯发现对方使用字典进行爆破，共计耗时23小时爆破成功 Zabbix的密码，然后进入内网，不幸的是当时安装 Zabbix 的时候是批量安装的，so~ 密码基本雷同，几乎是瞬间内网沦陷(主要是同网段的机器)～

主要的症状是机器 CPU 被打满，当时接到预警还感觉很诧异，有两台并没有跑什么重量级业务的机器 CPU 竟然 200%，这不合乎常理啊，上去排查一圈并么有发现特别的异常，对比正常机器发现 /var/log/secure 日志里有同一个内网机器的 IP 一直在尝试使用 zabbix 账号登陆当前来看正常的机器，然后再去这个机器上执行 last 命令发现有公网 IP 登陆的痕迹，这就很诡异了，我们 OPS 操作的时候也是经过 VPN + 堡垒机的，为啥会出现公网 IP 登陆的情况呢，咨询了安全大佬建议排查下定时任务，隐藏文件，开机启动文件，进程和用户等等...

随后写了个脚本在内网批量跑了一遍，发现在 zabbix 用户目录下和 /tmp 目录下确实是有隐藏文件，这些文件名里有明显的 ddgs 字眼～，拿到了这些信息，那就再来个脚本进行清理，清理，一顿操作猛如虎，随后在观察整个渐渐内网趋于平静，后怕啊～

DDG 相关文档: https://blog.netlab.360.com/d...

反思

虽然这两件事过去了这么多年，但是结合两次的安全故障描述，大家不难发现这都是人为造成的，第一个是因为防火墙关了没有及时开启，第二个是因为外网映射出去之后没有review，所幸都没有造成很坏的影响，不得不说的是安全意识还是不够，没吃过亏就永远不会提取老年人的建议或意见～

SSH 防护

• fail2ban
• denyhosts
• 自己写脚本
• 安全加固等等

---

回头专门写排障的细节出来～