由此次阿里云事件谈粗暴的安全防护手段

昨天阿里连续爆出了两个有意思的事件，一是阿里云服务器出现故障，导致误删除了大量用户文件（ http://www.weibo.com/1747505067/CyvEkrxPS ）；二是阿里承认明年校招名额将会缩减，可能导致很多已经拿到意向书的同学拿不到 offer 。

我不针对任何公司的对错发表评论，单论技术上的问题。

阿里云故障的原因，在各方说明下我也大概了解了，是云盾升级，将用户合法的可执行文件给当做恶意文件，直接给删掉了。

po 主的语气和遭遇，听起来感觉挺逗的：

这段话我看着笑了一下午，我斗胆猜一下云盾是怎么工作的：

为了防止服务器被入侵，并执行恶意软件（如提权程序），拥有 root 权限的 AliyunDun 英勇地负责干掉这些可恶的恶意程序。不知道为什么，最后眼瞎把正常程序也杀掉了。不，是删掉了……

直接删掉了啊尼玛！

这让我想起了很久以前刚入道时候我检测过一个网站，传上去的 webshell 总是莫名其妙地 404 了。当时感觉就是被安全软件做了手脚，后来进去一看果然，我传上去的不免杀的 webshell.asp 全被重命名成了 webshell.asp.20xx-xx-xx_xxxxxx.hws

当时感觉，这样的防御手段真是很黄很暴力啊。

因为当时的 asp 网站拿 shell ，无非是几个常见方法：一是数据库插马，二是配置文件插马，三是上传漏洞利用各种解析漏洞等。前两种方法，都是将一句话插入到其他正常文件里。这时候如果正常文件也被直接改名了，将导致整个网站都运行不了了（配置文件和数据库文件都是网站运行必不可少的文件呀）。

还好当时检测的时候是找的上传漏洞，否则网站搞挂了就悲剧了。
后来知道这个防御软件叫护卫神，好一个护卫神，真是好呵护呀。现在谷歌“护卫神 重命名”，还能找到一堆恢复误杀文件的软件：

当然，护卫神比起这次的阿里云盾事件来说，还是小巫见大巫了。怎么说它也没把正常文件当木马删掉，只是重命名了，还有无限恢复的可能。

说起粗暴，我还能想到的是很多开源应用。他们对于安全漏洞的惧怕与修复手段，如果不做代码审计或二次开发，大多数开发者你们可能根本不会想到。我见过无数应用，防御 SQL 注入的手段如此粗暴：

上图某个版本的 cmseasy 源码。光看图可能体会不深，看到具体代码：

居然在 codition 这种函数里直接用这么粗暴的手段处理 SQL 注入，任意 SQL 语句的 key 和 value 都不能出现 select 、 if 、 sleep 、 from 这种英语中常见的单词，那这个系统还怎么正常使用？

这就是国内很多开发者对待安全漏洞的态度：惧怕、痛恨、无能。他们用最原始最粗暴的手段去处理安全问题，根本原因是他们对安全问题处理方法一无所知，不知道怎样正确地处理漏洞。

这样的开发者我觉得还是趁早辞退了的好。

所以，这里就不得不说到，粗暴的安全防护手段造成的问题。注重安全固然是一个优点，但我们怎样去科学地注重安全？

这里涉及到几个问题：

1. 以安全为目的的监控是否合法？
2. 安全权限大，还是业务权限大？
3. 发现安全问题，是告警还是自动处理？
4. 如何科学地，而非利用原始手段去解决问题？

第一个问题，以安全为目的的监控是否合法？
我看到 V2EX 上很多朋友诟病阿里云盾的原因是，作为一个 IaaS ，云盾却一直驻于内存监控与干预系统。那么，云盾这个进程究竟在用户的 ECS 上做了些什么？

据各种不靠谱小道消息，我了解到云盾在用户的机器上权限是很大的，几乎可以做任何事情，包括监视用户的文件系统、 SQL 语句、进程等，我不以最坏的恶意揣测任何人，单只认为云盾监视这些东西的原因是防止恶意程序。但这样的监视已经让很多用户不安了。

就像美国棱镜门， NSA 一直强调自己监视民众是出自反恐等目的，但并不是说有人都逆来顺受，你的监控已经触犯到人们的隐私了。

那么，阿里云是否可以提供给用户取消云盾的选项？用户选择取消云盾后是否真的再也没有类似进程监控系统了？看下图：

从售后工程师处了解到，你希望的都是不可能的，呵呵~

第二个问题，安全权限大，还是业务权限大？

首先，权力不管在现实世界中，还是网络世界中，都是一个很可怕的东西。一旦高权限被用在不当的地方，带来将是灾难。

这次的事件实际上是一个错误，并不是权限被“滥用”了。但实际造成的结果是灾难性的。犯错误不可怕，可怕的是在我犯错误的同时居然刚好有高的权限，结果造成不可挽回的损失。

相信很多同学曾经都有做过 rm -rf /这类的傻事，多半是笔误手癌造成的。笔误通常是无法避免的，但试想，如果你当时并不是 root 用户，那么很多麻烦其实都不会发生。

这次云盾事件也一样，如果云盾没有删除用户文件的权限，也就不会发生这种悲剧。

所以，在做不到万无一失的情况下，就不要给自己高权限。高处不胜寒，古人的话还是很有道理。

那么，安全软件究竟要不要给予其高权限？

我个人比较喜欢的做法是，给予 WAF 进程 www 权限（附着于 web 容器中），让它作为一个语言扩展或者服务中间件扩展的形式进行流量监测与过滤。

当然你会说这样的方式监测效果不佳，或者说云盾担任的角色并不是 WAF ，而是类似 windows 操作系统中“杀毒软件”的角色，所以一定要拥有像 windows 中“ ring0 ”的权限才行。

既然你选择了 linux ，那就得接受 linux 严格的权限划分，接受它作为“服务器”的角色而不是 PC 机。 windows 下的杀毒软件在 PC 机上胡作非为，虽也是人人喊打，但影响再大也只是个人的。但服务器上如果也放任杀毒软件胡作非为，那将影响到整个生产环境的健壮性，服务的稳定，甚至整个企业的业务。

所以我认为生产环境下，不应给安全软件过高的权限，保证业务才是王道。

第三个问题，发现安全问题，是告警还是自动处理？
我曾经在某网内见过一个简单粗暴的安全检测脚本：

也是直接拿下关键词就报警。但这个脚本只是将具体文件、关键信息用 mutt 命令发送邮件到技术人员手中。

这就体现出一个“告警”的概念。技术人员即使自己对自己的服务十分熟悉，也不敢直接用自动化手段处理安全问题，而是选择将问题“告诉”自己。我觉得这虽然加大了人的工作量，但在你的技术还没达到 100%识别恶意脚本的情况下，人工识别仍然是最有效的办法。

阿里在国内我觉得是安全最好的企业之一，但就这次的事件来看，完全不能满足自动化解决安全问题的条件。云盾在不了解用户业务的情况下，更不应该自动化处理用户的文件和数据。

所以，相比于发现问题直接杀掉，还是告警用户，让用户自己处理更好。

这一点上，国外的 IDC 厂商做的就更好，比如 linode ：

第四个问题，如何科学地，而非利用原始手段去解决问题？
这也是最难的一个问题了。包括我自己，还经常使用原始手段解决问题，我举个例子。

运行 wiki.leavesongs.com 的 wsgi 服务器是 gunicorn ，我早期自己写了一个原始的脚本来进行重启操作：


一个多么简单明了的脚本。

结果后期出了各种错误：一出错就导致服务挂掉，还经常要运行两次才能重启服务。

所以系统服务通常是不会用这类原始方法去控制的，老的 linux 上是 sysvinit ， debian8 将服务管理方式从较简单的 sysvinit 替换到成 systemd ，更加体现出“科学”这个概念。

新的事物总有诞生的道理，所以我也不能去抗拒它，只有科学的工作方法才能提升生产力。

但科学的事物也有不可避免的问题，学习成本大，对人的要求很高。有些人对所谓的“学术派”嗤之以鼻，殊不知实际上是一种吃不到葡萄说葡萄酸的心理，说这些话的人大多是“野路子”。

我也是半个野路子，所以干很多事情还是用最简单的方法，当我真正在课堂上认真学习过“软件工程”、“编译原理”之类的课程以后，再用课上学过的思想去思考你做过的很多项目，发现我的很多做法有多幼稚。

现在互联网行业对人才的需求，处在一种很微妙的状态。各大企业都缺乏人才，做这块的人也很多，但实际上称得上“人才”的人不多。

我觉得人才的最低标准，也得是能够用科学的方法去处理问题。而不是你会写几个 app ，会写个网站，套用几个第三方库开发一个软件，就是人才了。（但实际上很多互联网公司招到的人多半是这一类）

这一点上我很惭愧，自己也够不到最低标准。

左耳朵耗子曾经在微博上分享过一个趣事：

也是一个粗暴的安全软件造成的问题。我猜这个脚本原始到只用一行代码即可写好，一个 crontab ，一个 ps ，一个 gerp 。

这样的脚本是否符合软件工程的设计理念，我不敢妄言。但就这样欠考虑的处理方式，我就觉得迟早会出大事。

一个公司使用的原始手段越少，说明这个公司的技术水平越高。“懒人创造奇迹”的懒人不是懒得学习知识的人，而是对繁杂的现状不满而选择去改变的人，如果我们连现状是怎样，原理都没了解清楚，总想用最简单的方法解决问题，那只能背下出事后的锅了。

安全越来越受到重视的同时，要科学地去面对安全，我想这个事情也是任重而道远的。阿里这种安全很强的公司都会出现这样的 BUG ，更别说很多企业可能安全团队是从零一下子出现的，人才、技术的良莠不齐也是正常现象，所以才会出现各式各样粗暴的安全防护手段。

另外，也希望的是领导者都能清晰地明白怎样真正注重安全，不逼员工去做一些“看似使业务安全”的工作，这也是减少很多荒唐安全措施的方法。

这些愿景，希望都能实现。

原文：https://www.leavesongs.com/PENETRATION/talking-about-violence-security-defense.html