程序员入狱事件复盘报告

人无德不立,德才兼备,方堪大任。
本期话题是最近几年的程序员入狱事件。
对于这几件事儿,不管哪个运维经历了都得脊背发凉。
好吧,直接进入正题吧。
我尽量按时间线来完整描述故事的发展情节,
从上帝视角,看运维程序员是怎么把自己一步步送进监狱的。

互联网黑色五月

2015年的5月发生了中国互联网历史上最频繁的宕机事故。
陌陌、网易、支付宝、携程网、艺龙网、招商证券、
等等等,
那个月成了圈内人士的”黑色五月”。
5月11日 晚上9点网易新闻、游戏、考拉、公开课等全部宕机,
5月27日 支付宝大面积瘫痪,
5月28日 上午11点携程页面出现了404。
那几天可谓是互联网巨头玩起了萝卜蹲。
其中,携程网恢复时间最长,
当时所有技术人员全部扑上去,原本想分分搞定
可谁知道数据在恢复备份时,怎么越恢复越少!
回过头才发现并没有阻断删除的进程!
此时时间已过去了3个小时,404页面已经被刷了无数次,
360、猎豹、腾讯的安全专家纷纷喊话支招,
有的说:是高级管理员出内鬼了。
有的说:黑客拿数据一般用复制,不用剪切。
正值五月,还没有入夏,携程却打开了空调给运维送冷气……

上海市民陈小姐28日下午本来想上携程网预订下个月旅游的酒店,
发现携程网页根本打不开,还看到滚动提示:
“携程网站正在修复中,可以去艺龙预订服务。”
携程和艺龙秀起了恩爱,前脚才入股为艺龙的大股东,后脚就给他导流量。
艺龙ceo崔广福当时就懵了,因为流量太大,
以为是遇到黑客攻击了,来不急处理,很快也宕机了。
当时一生气,报案!没错,报案了。
360安全专家当时就乐了:小艺龙肯定接不住你大哥的流量啊。
阿里旅行的“去啊”官方微博当下补刀:来我这儿吧,我能接住!
8小时后携程APP能下单了,就是还不太稳定,
有可能下一单,出二单,甚至出四单的重复订单。
终于 快到晚上11点的时候,一切都恢复正常了。

网上资料有限,携程并没有透露更多的技术细节。
先是说,安全漏洞是技术人员未及时删除临时日志,被黑客利用了。
5月29日又发布官方情况说明称,
此次事件是由于员工错误删除了生产服务器,
没有信息泄露。可以看出,携程自己都是懵逼着的,
只知道数据没了,服务断了,是不是黑客所为则不得而知。
后续并没有看到案情的正面发展,想必也是想不了了之了。
还流传一个事故原因版本是这样的:
携程网被“乌云”曝光了一个安全漏洞,
漏洞涉及到了大部分服务器和数据库。
运维人员批量操作修复漏洞的脚本时,无差别的把所有系统文件删除了。
可是为什么恢复这么慢呢?实际上大型网站,看似一个简单的页面。
背后由成百上千个应用子系统组成,
每个子系统又包括若干应用和数据库服务器。
任何一处的事故都可能造成雪崩效应。
数据安全问题可能会拖垮一家互联网企业绝不是危言耸听。
而携程作为美股上市公司市值直接缩水1200万美元。
互联网行业律师认为,如果本次事故是内部人员所为,
说明携程网内部存在管理问题,没有尽到安全管理责任,
应该承担相应的民事责任,赔偿用户损失。
如果本次事故是外部攻击造成,那么携程还是没有尽到安全保障义务,
也是要负法律责任的。
这大概就是不再向外公告更多细节,不了了之的原因了吧。

百度服务器挖矿事件

2017年的安某入职百度运维,一年后,进入监狱。
这个安某想必工作比较清闲。
运维嘛,平时995,战时007。
尤其是百度这样的公司,毕竟业务已经非常稳定。
次年1月 晋升为高级运维工程师的安某,
发现了一个生财有道的好机会。
因为那一年比特币疯狂涨到了10万元一枚
这让很多没有投资比特币的网友痛悔不已,
错失了一夜暴富的机会。 投资比特币除了拿钱买,
还有一个办法就是挖矿,利用矿机进行大量运算获得比特币奖励。
挖矿需要买矿机,也就是服务器,大量耗费电力。
而现在靠自己购买服务器挖矿,简直就是天方夜谭,
电费就能赔死你。

所以,那两年出现很多黑客入侵事件,渗透服务器之后,
放一个小程序,远程挖矿。
但是这种方法很快就会被发现,
因为挖矿对CPU的资源占用非常高。
话说回安某,就做了一个木马小脚本,
用工作账号把脚本上传到了中控服务器。
然后远程控制,把挖矿程序自动下载到155台生产服务器上。

4个月过去了,小安的 ”矿机“ 一共挖了价值10万的比特币。
发家致富指日可待,可谓是神不知鬼不觉,
可是,离年入百万还差点。
于是在小安部署挖矿脚本后,稍微的调高了CPU资源限制。
常在河边走,哪能不湿鞋。
百度内部其实是有安全管理监控系统的,
只是没有越过资源警戒线的情况下不会发出警报。
系统一般会对CPU资源和网络资源承载量进行监控,
就在6月份,系统警报拉响了,
后台发现大量服务器运行异常,运算资源一度枯竭,
经过一番排查,进程中的挖矿程序资源占用非常高,
最终通过系统日志确定了幕后的操盘手……

程序很快被清理,日志被迅速备份锁档。
百度内部成立了一个组织叫 职业道德委员会。
因为掌握确切证据,最终直接将小安交给了警察
7月,百度正式起诉小安,认为其犯有非法控制计算机信息系统罪
法院介于百度损失较小,小安认罪态度良好,
决定从轻处罚 最终判处10年刑期
百度的损失到底有多大呢?
理性分析下来,百度不仅没有损失,反而还赚了。
一、不用花钱找人进行安全培训了,生动的例子可以一直讲下去。
二、对所有员工的警示作用非常明显,提高了员工的自我安全意识,
划清了工作与私活的界线,工作就是工作不要再动歪脑筋了。
百度听到这话肯定也不乐意,
毕竟还花费 2.7 万元请外包提供了应急服务呢,
不错,百度的调查取证是请的第三方,包括样本提取、分析、
服务器日志追踪溯源、报告编写等。
这起挖矿事件虽然告一段落了,但对于企业来说,
这也是一个提醒,企业需要正视长期存在的IT运维权限风险问题。
如果说安某占用公司资源,是损人利己的行为。
那下面这位就着实有点亏了。

郑大一附院数据库锁表事件

2018年12月24日上午八点多,
郑州大学第一附属医院门诊缴费和叫号系统全部出了问题,
数据加载异常缓慢,系统一直请求超时。
所属三个院区门诊的全部业务中断。
技术人员发现数据库延迟非常高,甚至无响应。
院内排起了长龙,各种人工疏导。
就在技术人员排查服务器日志的时候,
发现有多条 Lock(锁定)指令,赫然在列!
于是立即逐条把锁定指令终止,
在终止了6条指令后,终于恢复正常。
这6条锁表指令的总共执行时间是1个半小时
在此期间,三个院区的15000多个门诊业务量无法工作,
24号当天的业务量是25000多个。

HIS系统也叫《医院信息系统》。
这套智慧系统一直稳定运行,一年可能会出现一两次故障,
都是由北京中科某公司的人处理和解决。
而此次中断时间长,影响范围广,
自系统上线以来的第一次出现。
原来,当天早上,北京中科公司的夏某跟平时一样正常工作,
看到微信群里反应河医门诊系统卡顿,
于是远程登录到HIS的数据库和服务器,查看系统运行日志。
并打开了《数据库性能监控软件》,
说是软件,其实就是他一年前为方便监控数据库而编写的测试脚本工具。
启动软件时一直报错,调试了五六次也没成功打开,
但实际上已经创建与HIS系统数据库的连接,并进行了6次尝试独占表资源
也就是说命令已经发送到了服务器。
lock table +表名 in exclusive mode;
是Oracle数据库的锁表命令,这个锁定模式级别最高,
并发度最小,且只允许查询,无法创建及修改表中的任何数据。
也就是我们常说的悲观锁,并且这个命令是表级的悲观锁。
整个操作过程大概持续了20分钟。因为加锁后,如果会话不断开,
或是没有强制终止会话,则会一直锁定。
这也就造成了门诊挂号全面瘫痪的事故。

医疗领域提供公共服务的计算机信息系统故障,对生产生活造成严重影响。
而导致五十台以上的计算机不能正常运行,经济损失超过五万元以上,
都符合破坏计算机信息系统罪“后果特别严重”的规定,
最终夏某被处五年刑期。
夏某是公司的”资深“运维,工作经验已有五年以上。
一般高级运维会参与到核心业务的生产环境部署与维护。
夏某也不例外,
不管是新闻还是知乎,都在强调是夏某 私自 编写了“数据库性能观测程序”和锁表语句,
这其实并不客观,作为运维,有责任对系统进行状态监控。
而对于生产环境数据库的私自连接,则是违反一般安全制度的。
千不该、万不该用开发环境的测试工具直接连接生产库。
运维是有操作规范的,经过客户同意的操作,出点小毛病,问题不大。
过度自信必将导致墨菲定律的出现。
像这样的案例我身边也有发生过,
当时一名同事在开发IDE中连接了生产库,本应该在本地库执行的SQL脚本,
却直接连接到了生产库执行。万幸的是,当时被清空的表是一个监控看板数据。
30分钟后会自动更新数据看板,造成的影响可以控制。
如果是核心业务数据,那将不可想象!
所以身为运维千万不要给自己犯错的机会,
一日连上生产库,就像走在了悬崖边上,
可以欣赏至高的美景,也可以跌落万丈深渊。

微盟删库事件

微盟是一家互联网营销公司,帮人在网上运营公众号和小程序。
有300万家客户。简单来说,就是帮人网上开店的。
2020年2月,正值疫情高峰期,
国内互联网技术公司,多数采用远程办公的方式工作,
微盟也不例外,23日下午7点前后,
突然接到商户反应,后台打不开,操作非常卡。
紧接着,内部系统监控发出报警,出现大面积服务集群无法响应。
微盟平台所有小程序全部宕机。
技术人员立即查看服务器,发现业务数据库是空的!
高层领导马上成立了应急小组,想尽快把数据恢复。
但接下来的状况更糟糕,因为数据库备份文件也被清空了。
不过微盟并没有把鸡蛋放在一个篮子里,
系统底层架构采用的是混合云模式,本地的数据遭到删除破坏,
还有一部分数据是腾讯云数据库提供的服务,
虽然数据是被清空了,但云服务器一般会有系统自动备份,且无法直接删除的部分。
这也成了微盟活命的最后一根稻草。
随即与腾讯云相关的技术人员取得联系,
腾讯工程师们也没有让微盟失望,在得到肯定答复后,
终于可以向外界公布事故进展:
”我们还活着……已经恢复部分生产数据了,新用户的数据很快就能恢复。
老用户再晚几天。“
此时已过去了36个小时。
就在这36个小时里,网上舆论哗然。
吃瓜观众各种猜测,有说是公司内部核心运维的老婆被高管睡了,
有说是被其它员工欺凌了,
还有的说是高利贷无力偿还,删库跑路了。
通过系统日志,很容易就定位到删库员工的登录账号及IP地址。
在官方公告中,最终解释为深陷网络贷被经济压力压垮了,
导致精神奔溃做的过激举动。
同时微盟已向上海警方报案,该员工被刑事拘留。

疫情期间,对于微盟的客户,
本身正在经受门店歇业重创的商家来说,超过5天的系统故障。
则是双重致命打击,可谓是屋漏偏逢连夜雨。
中小商户叫苦连天,微盟自身也遭受了重创。
24日到25日,仅在这一天时间内,微盟集团蒸发的市值超过12亿港元!
为安抚用户情绪,微盟提出了一个赔偿方案:
准备了 1.5 亿元人民币赔付拨备金,
拨备金就是股东没同意前做的稳定局势的预算。
其中公司承担1亿元,管理层承担5000万元。

回顾整件事情,长久以来,技术岗位的重要性总是被低估。
从企业家的角度来说,风险意识不能仅关注市场环境,
也包括自身内部环境。
对于安全意识要更多以人性本恶的角度看待问题。
另外,运维可以删库,也说明企业并没有认真做到最小放权的原则。
像这样的隐患应该不只是微盟,也包括你我所在的公司。
一个有技术支撑的团队可以把死棋盘活,
如果是技术能力有限,那么公司则直接面临倒闭风险,
等事后再走法律程序也为时晚矣。
一个有着最高权限的运维,却没有拿公司股份,
就像身边有一个地雷,引线在别人手上。
他们拥有一定运维权限。掌管着企业至关重要的资产,
具备犯罪条件。
千言万语总结成一句话:对运维好点!

我是Adam 下期见!

评论未能加载 DISQUS被屏蔽 请检查网络