99%的人会中招的运维安全陋习，请规避！

随着IT技术和业务的发展及各式各样安全漏洞的涌现，运维与安全这两个专业日渐交融，人们对运维安全的重视程度越来越高，于是逐渐出现了一个新的交叉领域叫“运维安全”。

黑客、白帽子忙于挖掘运维安全漏洞，企业忙于构建运维安全体系，一时间无数漏洞纷至沓来，座座堡垒拔地而起。

作者立足自身多年运维安全实践，也来探讨一二。

本文将按照提出问题到回应答案的思路，先抛出作者对运维安全的理解，并解释重视运维安全的原因;接着根据在运维安全一线发现的工作陋习及企业面临的常见问题，整理出通用运维安全问题分类;之后的下篇还将对症下药，提出一个好的运维安全形态：不仅在于工程师们的安全意识，更在于一套相对完整的运维安全体系，从流程到技术，点线面多位一体共同缔造。

一、什么是运维安全?

我们先看一张维恩图，现实中的业务、运维、安全的关系是互相关联、彼此依赖的：

从这张图中，衍生出三个不同与安全相关的子专业：“运维+安全”、“安全+运维”、“业务+运维+安全”。在互联网公司招聘岗位里，我们经常看到的是运维安全工程师、安全运维工程师，这两个岗位比较好对号入座。而“业务+运维+安全”，通常被包含在安全工程师的岗位中，近年出现的应用运维安全工程师，相比之下更符合“业务+运维+安全”的定位。

1、运维安全 = 运维 + 安全

运维安全研究的是与运维相关的安全问题的发现、分析与阻断，比如操作系统或应用版本漏洞、访问控制漏洞、DDoS攻击等。显然，运维安全立足于运维，从企业架构上讲通常属于运维部门或基础架构部门，运维安全工程师的专业序列一般属于运维工程师。

2、安全运维 = 安全 + 运维

安全运维研究的是安全系统或设备的运维，比如防火墙、漏洞扫描器维护、漏洞挖掘与应急响应等。这个也很明显，安全运维属于安全部门旗下，安全运维工程师的专业序列也属于安全工程师。

3、应用运维安全 = 业务 + 运维 + 安全

应用运维安全研究的是业务上的运维与安全，主要包括安全风险评估与安全方案规划设计及其落地。组织架构上该岗位有属于安全部门的，也有属于业务部门的，对应的专业序列有属于安全工程师的，也有属于开发工程师。

通过对比“运维+安全”、“安全+运维”、“业务+运维+安全”三个子专业的不同，我们明确了运维安全的研究领域和岗位职责。看到这里，可能大家会有疑问，是什么导致运维安全现在这么“风光”?

二、为什么我们重视运维安全?

可以说，2013-2014年是运维安全发展的一个分水岭。这两年特别之处在于作为互联网基础设施的几大应用相继被爆漏洞或被攻击，例如Struts2远程代码执行漏洞、Openssl心脏滴血、Bash破壳漏洞，以及当时“史上规模最大的DDoS攻击”导致大量.cn和.com.cn域名无法解析。在这之后，企业对运维安全投入迅速加大，各种运维安全问题也引起广泛关注。直到今天，运维安全已经成为企业安全建设的重中之重。

1、漏洞百出的软件供应链

• struts2远程代码执行漏洞

当年S2漏洞一出，整个互联网一片哀嚎。下面是受影响的企业，大家应该几乎没有不认识的吧?

• openssl心脏滴血

跟S2漏洞一样，杀伤力极强。

• xcode开发的ios app感染木马

研究者发现AppStore上的TOP5000应用有76款被感染。后来发现罪魁祸首是开发人员从非苹果官方渠道下载xcode开发环境。

2、运维安全漏洞占比明显

自从某云离去以后，不得不说国内互联网安全态势的共享逐步走向了封闭，不过借此机缘，也涌现了很多商业公司。

即便是现在留下的某天某法某眼，能查询到的统计分析数据其实也很有限。即便是某旦，其用户体验也不够好，统计分析功能无法差强人意。剩下的，各种研究报告也从来没有把运维安全问题列入单独的统计范畴，所以这里借用2016年CNVD的统计，可以发现明显属于运维安全问题的网络设备漏洞和操作系统漏洞，占比已超过20%，加上应用程序漏洞中包括的各种应用版本漏洞，相信归属于运维安全领域的漏洞比例将极其可观。

3、运维安全漏洞利用性价比高

针对运维安全漏洞的攻击属于典型的“一两拨千金”，其ROI非常高：投入小、容易发现与利用、造成危害特别大。

根据微软的DREAD模型来衡量运维安全漏洞风险如下：

三、常见运维安全陋习

运维安全事件频发，一方面固然是因为运维或安全规范空白或者没有落地，另一方面也在于运维人员缺乏强烈的运维安全意识，在日常工作中存在这样那样的安全陋习导致。

下面列出了14种坑，大家可以试试对号入座，仔细想想曾几何时自己是否也踩过同样的坑?

1、修改iptables后没有还原配置，甚至清空关闭iptables

出于测试需要临时清空iptables可以理解，但是很多人会忘记还原，也没有设置自动还原机制。

iptables -F 

2、脚本没有检查“*”、空格、变量

如果我们认可“不光用户的输入是不可信的，自己的输入也是不可信”，这样的坑就会少踩。

rm -rf /$var1/$var2 

3、服务启动默认监听全部地址

绝大部分应用默认配置便是如此，在没有有效访问控制的清空下开启监听所有地址，离危险也就不远了。

bind-address 0.0.0.0 

4、给文件开放过大的权限时，任何人都能读写

这个跟phpinfo有点像，能给入侵者推一把。

chmod 777 $dir || chmod 666 $script 

5、用root启动服务

对于大多数运维人员而言，一上机器就切到root，后面用root启动服务仿佛一气呵成。

#nohup ./server & 

6、嫌麻烦不配认证，也不配访问控制

这个跟监听任意地址比较像，通常也是默认配置使然，使用者也没有意识去加固。

#requirepass test 

7、单机安装docker之后忽略检查iptables，导致docker修改iptables开放外网

（编辑：揭阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!