保护好你的远程卡

远程卡的好处不要多说,已经成为众多厂商的标配了,但是很多公司不乏很多上规模(比如这个)的公司,忽略了远程卡的安全,然后,然后就被搞了。
我们在很早期的时候也遇到过类似的情况。两年前我们上的某批机器,当时为了途方便(那时候我还没有部署 vpn ),远程卡都是放的是公网 IP,再加上当时的自动化做得不是很好,有一台疏忽了修改其默认的用户名密码,导致了这台机器被一个小 cracker 搞了一把。回顾下当时的情景,大致是这样的:
那天晚上正准备睡觉,突然收到短信说服务器被重启了,后续连续收到几条类似的报警。立马登陆到远程卡上 launch console,发现需要发送共享的请求。当时除了我有权限登陆到远程卡之外,没有人可以登陆,当时只是觉得很奇怪,但是没有意识到已经被入侵了。再请求了几次之后竟然可以 launch 了,打开控制界面发现服务器又在重启。后来反应过来,遭入侵了。通过控制卡的回放功能,确认果真被入侵了。那个小哥尽管进了远程卡,但是没有办法登陆,只能通过重启的办法,重置了我们的 root 密码。刚重置完发现发现了,然后,然后就跑了。
接着就是吸取教训写 post-mortem,快速的加固系统,远程卡出问题,当然是从远程卡入手。最容易入手的包括如下的几点:
1. 远程卡全部隐藏到内网里,回收所有不需要公网机器的 IP
2. 修改其用户名密码,登陆端口
当时机器的数量还在两位数,再加上当时对自动化方面没有太大的需求,尤其是这类不涉及系统层面的自动化,花了一天不到的时间,一台台人肉修改完了所有的机器(想象当年多无知)。后来所有新上架的机器都按照这个标准继续执行,当然不再是人肉执行了。

对于这台被入侵的机器,本来是打算直接重装的,经过再三的权衡,再加这是台 db server,上面有很重要的数据,最终并没有选择重装,把能检查的地方都检查了一遍,后续的几天密切的关注这台机器的所有进出口的流量、涉及的进程等等。
后来经过对入侵机器以及几台相关机器的追踪观察,确认没有造成更大的损失,事件到此为止。

接下来的几天,还做了以下的几件事:
1. 所有的机器实行 ssh 的公私钥登陆,取消默认的密码登陆
2. 对服务器的访问权限所了一个比较粗的控制,尤其是开放了公网机器的,基本就是 iptables + tcpwrappers

针对这次远程卡入侵做的事情基本就是这样,后面还陆陆续续的做了些其他的事情,不过我觉得,也只能防住八成的小黑客,或许连八成都没有,即使有专职的安全工程师,这个比例也不会高到哪儿去。有点需要注意的是,绝对不可能做到 100%,只要不是 100%,就有乘虚而入的机会。
老板不重视安全是一回事,被搞了以后重视安全是另外一回事,在平时就很注重安全的更是粉毛麟角了。很不幸的是大部分的老板都属于前两者。为此带来的结果就是安全工程师在公司的地位相对比较低,见过不少公司都是把安全工程师划分到 IT support 部门,而非主流的运维、基础架构甚至单独成立一个安全部门,这个在非互联网公司更明显。尽管我个人很尊敬做安全,并且我也很清楚做安全的其实很有技术含量,但是大陆的整体环境就那样,这个近期好像无解。