安全运维事件、启发与建议

国内外误操作案例：

韩国农协银行

时间：2011.4.12

影响时间：大于3天

详细介绍：位列韩国四大银行之一的韩国农协银行电脑网络出现故障，导致客户无法办理业务。系统故障一直持续了3天，直到4月15日才恢复部分服务，而有些服务直到4月18日仍然没有恢复，以至于银行不得不采用传统的手写交易单的方式进行服务。

事故原因：从第三方代维人员所持有的笔记本上对银行核心系统下达了一条rm.dd命令，该命令将服务器上所有的文件全部删除，连灾备服务器都未能幸免。

 

全国DNS污染

时间：2014.1.21

影响时间：12小时以内

详细介绍： 2014年1月21日下午15点中国境内发生DNS解析服务故障（主要原因是DNS污染或DNS劫持），导致百度等多家网站长达几个小时之内无法访问。其指向的IP地址为65.49.2.178，所以该IP又被冠名为65.49.2.178事件。有媒体称是国内组织或者是黑客攻击导致的，但历史没有一次根域名服务器被攻破。网络运营商出现故障可能性大些，但仍都无确切证据。

事故原因： 根据互联网上相关消息，并通过对DNS的TCP查询结果进行分析，怀疑是GreatFirewall管理员的误操作导致部分DNS被污染，导致国内的DNS服务器在同步时同步了被污染的A记录，从而导致国内部分网站不能正常访问。

 

PPS&爱奇艺员工安全意识不足，导致内网渗透

时间:2014.02

影响范围：PPS&爱奇艺内部网络

详细介绍：PPS某员工由于操作不当，在谷歌源码托管上设置未授权访问，导致该员工接手的所有项目代码以及相关帐户信息泄露导致攻击者直接获取到该企业的内网服务器权限。

事故原因：由于员工安全意识不足，导致企业内部的网络信息在公网上可以任意访问，为攻击者提供了可趁之机 。

国内外误操作案例综合分析：

在生产环境中凡是对业务产生影响的的操作，都应该现在测试环境中进行一次测，试之后方可在生产环境中执行，若环境不允许则需要经过谨慎思考之后方可进行操作。

对于一些删除、修改操作应该有权限限制，并应该增加提示信息。

加强员工安全意识普及，对于不同部门的员工，对于服务器应该有不同的权限，最坚固的堡垒往往在内部被攻破。

安全是一个整体，任何环节出了问题，其影响范围都是不可估量的，并且问题最容易出在没有注意到的点上面。

 

安全运维建议：

一、         变更要能回滚、先在同样的环境测试过

从某种意义上讲、运维是一门经验的学科、是一门试错的学科。没有做过的东西、总是会给你不期而遇的痛击，请保护现场，让变更有回头的机会。

 

二、对破坏性的操作谨慎小心

什么是破坏性的操作？

比如：对 Oracle 而言：truncate table_name、delete table_name、drop table_name，这些语句执行起来轻松简单也惬意极了、但记住！即便数据可被回滚、代价也是非常大！

对 Linux 而言：rm -r 所有当前及其子目录的所有数据都将被删除。经历过这种故障的人、大多会给 rm 上个别名

alias rm='rm -i'

同理、cp 和 mv 也可以有同样的选项：

alias cp='cp -i'

alias mv='mv -i'

 

三、设置好命令提示

在操作之前、先理清你所在的是主库、备库？当前目录？哪个 schema？session？时间？

比如：

对 Oracle 来讲：

[plain] view plaincopy

idle> set sqlprompt 'RAC-node1-primary@10g>>'

RAC-node1-primary@10g>>

当然、你也可以在 glogin.sql 里面设置。

•对于 Linux 而言、bash 环境的提醒可设置 PS1 来知道当前目录、登陆用户名和主机信息等；

•对 PS1 更多理解、请见：man PS1

 

四、备份并验证备份的有效性

人非圣贤、岂能无过？是机器总有计划内或计划外崩溃的一天。怎么办？备份！！！备份的学问很大、按照不同的维度可以分：冷备和热备；实时和非实时；物理和逻辑。OLTP 7*24 在线业务、DB 就需要有实时热备。这样就可以了吗？

如果开发人员的一个不带任何条件的 delete 误删所有数据，此时你除了实时、还需要有非实时的备份、把 DB 从逻辑错误中恢复出来。

备份有了可以高忱无忧了吗？不行！尚须验证备份的有效性。一个总有那么几次、备份无法保证 100% 恢复，简单的验证就是找个空库恢复出来。

 

五、对生产环境永保敬畏之心

会计人员在从业之前、都有个职业操守的训练。同理、这也应该是运维人员进入行业首先需要具备的素养。

比如：

•于 Oracle 而言、你可以跑一个 RDA 巡检 DB 的健康状况；

•于 Linux 而言、是否有 password aging、隔离外网等。

 

六、交接和休假最容易出故障、变更请谨慎

•接手别人的工作要一而再，再而三的确认变更方案。请教人并不见得就是能力不行的表现；

•休假前最好各种可以做好的事情，最好能够准备一份文档，指明在什么情况下怎么做和联系哪些人；

•在别人放假的时候接手工作，“能拖则拖”，实在需要执行：必须不厌其烦的跟原运维者确认各个操作细节。

 

七、搭建报警、及时获取出错信息；搭建性能监控、预测趋势

运维人员赖于生存的工具就是报警和监控。

•报警可以让你及时知道系统出现了什么异常、以便及时跟进、把故障扼杀于摇篮；

•监控可以让你了解系统的历史性能信息、以历为鉴、可以知兴替嘛、早做优化。

报警和优化是衣宽带水的好兄弟、相铺相成、互相促进。

 

八、自动却换需谨慎

比如：Oracle 存储级的HA方案：Data Guard，主库提交了一笔订单，结果发生了 switchover，这笔订单没有同步到备库，那么卖家损失了一个销售单、对客户、对公司都是损失。

 

九、仔细一点，检查，检查，再检查

具体操作可参考：

① 在做一个变更的时候，会先提前一两周发送邮件并电话手机通知相关人

② 在测试机上写好脚本，召集大家 review 操作步骤和脚本

③ 测试完成以后拷贝到生产环境

④ 登录对应机器，“打开，关闭，打开，关闭”该脚本

⑤ 跟相关人员再次确认执行的操作，顺序，时间点，可能的影响和回滚是否都准备好了

⑥ 执行前还要退出这个机器，然后再登录进去，“打开，关闭”脚本

⑦ 最后才在后台运行脚本，同时在另外一个窗口登录着，随时ps和查看结果输出

 

十、尽量简单

•能够使用系统内置命令的话，就不用考虑其他要专门下载安装的软件了

•脚本本身就能完成的功能，就没有必要专门找一个功能丰富的软件来做

•Linux本身自带的字符界面比那些复杂的图形界面要简洁方便

 

十一、对用户账号使用行为进行日志记录及审计

系统服务器侧应根据账号，对用户的使用行为进行详细的日志记录和审计，通过上述因素的日志记录，进行阶段性的审计（时间间隔应该比较小），从而做到发现用户账号的盗用、恶意使用等问题，尽早进行处理。

 

十二、负载均衡及负载保护机制

系统面临着巨大的服务量，服务器端的设备基本上都需要有多台服务器进行业务分担，这样才能提高性能，避免处理瓶颈的出现，因此，需要采用合理的负载均衡和负载保护机制：

•对各服务器的业务流量进行有效地分担，可按照Round Robin、LRU等方式来进行负载均衡

•负载保护机制需要实时地对每台服务器的CPU资源、内存资源等进行评估，如果一旦超过设定的阈值（80%或者以上），将马上进行过载保护，从而保证服务器自身的安全

 

十三、管理规范化

系统功能复杂，业务数据敏感，保密级别比较高，并且对不同管理人员的权限、角色要求都不尽相同，为了保证安全管理，避免内部管理中出现安全问题，建议作如下要求：

•严格划分管理人员的角色及其对应的权限，避免一权独揽，引起安全隐患；

•作好服务器机房的物理条件管理，避免电子泄露、避免由于静电等引起的故障；

•应作好服务器管理员的帐号/口令管理，要求使用强口令，避免内部人员盗用；

•作好服务器的端口最小化管理，避免内部人员扫描得出服务器的不必要的开放端口及其漏洞，实行内部攻击；

•作好服务器系统软件、应用软件的日志管理和补丁管理工作，便于审计和避免由于安全漏洞而遭受到内部人员的攻击；

•根据业务和数据的机密等级需求，严格划分服务器的安全域，避免信息泄露。

 

十四、合理的子网划分及流量分割

系统服务器侧包括大量的服务器类型，包括数据库服务器、Web服务器、FTP服务器、邮件服务器等，为了避免由于恶意流量造成的某种服务器崩溃，而引起的攻击后果扩散，并最终导致其他服务器也发生“雪崩效应”，则需要通过子网隔离（比如VLAN划分）、DMZ区域的设定等方式来将这些服务器放置在不同的安全域当中，做到流量和数据的安全隔离，从而将服务器端在遭受攻击后对整个业务系统及其他内网资源和数据造成的影响尽量控制在最低的范围内。

 

十五、加强员工安全意识教育培训

经常开展多种形式（会议、视频、手册、宣传册等）的员工安全意识教育培训，汇哲科技皆可提供，并且是有赠送一系列产品如FLASH动画、视频教程、电子手册、海报、屏保、台历、便利贴、半月刊等，内容例如：

关于企业的信息应该只在企业内部或者部门内部流通，不应再互联网上存放，极端情况下需要使用互联网的情况下也需要对数据进行加密，或者设置访问权限；个人密码妥善保管，有时候我们设置了随机高强度密码，却因为难记忆写在一张纸条上，然后贴在电脑前或者压在键盘下，这种事情应该是需要被禁止的。