漏洞心脏滴血怎么回事_这些运维安全问题,请注意_新手网安笔记

漏洞心脏滴血怎么回事_这些运维安全问题,请注意_新手网安笔记

漏洞心脏滴血怎么办_心脏滴血漏洞_漏洞心脏滴血怎么回事

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

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

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

一、什么是运维安全?

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

漏洞心脏滴血怎么回事_心脏滴血漏洞_漏洞心脏滴血怎么办

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

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

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

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

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

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

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

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

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

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

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

心脏滴血漏洞_漏洞心脏滴血怎么办_漏洞心脏滴血怎么回事

心脏滴血漏洞_漏洞心脏滴血怎么回事_漏洞心脏滴血怎么办

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

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

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

漏洞心脏滴血怎么办_心脏滴血漏洞_漏洞心脏滴血怎么回事

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

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

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

漏洞心脏滴血怎么回事_心脏滴血漏洞_漏洞心脏滴血怎么办

三、常见运维安全陋习

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

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

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

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

-F

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

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

rm -rf /$var1/$var2

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

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

bind- 0.0.0.0

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

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

chmod 777 $dir || chmod 666 $

5、用root启动服务

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

#nohup ./ &

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

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

# test

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

技术给我们带来的便利自不必言,但是带来的安全风险却一点也不少。而且, 默认是能控制宿主的,如果 使用tcp 或者启动的容器可被外部访问,则连宿主一同沦陷也不在话下。

8、sudo授权过大,导致自定义脚本提权

如果攻击者可修改脚本内容则提权易如反掌。

sudo .sh

参考链接:

.sh:

9、给开发或者QA授权root权限,他搞事你背锅?

一直以来我们强调RBAC,但是运维太忙,开发测试人员需求太多时,很多运维人员会直接授权他们root权限,而他们对系统级访问控制不甚了了,因此造成的漏洞非常“可观”。

dev@pro-app-01:/home/dev$su

root@pro-app-01:/home/dev#

root

10、key/token/ssh私钥保存在txt文件里,也有把个人ssh私钥放在服务器的

op@pro-app-01:/home/op$ls ~/.ssh

.pub

11、把工作上的代码对外发布

连着遇到实习生把项目代码提交了,回复的理由是git配错了。虽然不知真假,但我认为,至少他们是安全意识不足。

git add push

12、个人home目录那么敏感,也有人拿来直接托管服务,至少.泄露是跑不了

dev@pro-app-01:/home/dev$ -m

13、应用选型时没有考虑安全风险

: 2.5 - 2.5.12 #线上业务使用受S2-052影响的S2版本

14、对软件供应链安全没有概念

从xcode事件到pip官方发现恶意ssh库,都在向我们昭示一个道理:软件供应链安全风险极大。目前比较运维人员中比较常见问题有:

四、常见运维安全问题

前面我们谈到了运维操作上、思路上的一些陋习,或者安全意识不足的问题,下面结合漏洞分析和响应过的情况来看,常见的运维安全问题主要可分为下面几种:

1、敏感端口对外开放

db或者cache属于敏感应用,通常部署在内网,但是如果部署的机器有内外网ip,且默认监听地址为0.0.0.0的话,则敏感端口会对外开放。如 MySQL / / Redis / rsync / api 等端口对外开放。

2、敏感应用无认证、空口令或者弱口令

同上,如果敏感应用使用默认配置,则不会开启认证,MySQL / / Redis / rsync / rpc / 等应用无认证。有时贪图测试方便,配置了弱口令或空口令,则认证形同虚设。

3、敏感信息泄露,如代码备份、版本跟踪信息、认证信息泄露

web.tar.gz/.bak / .svn/.git / .inc.php / test.sql 等信息泄露随处可见,人人知道危险,但是始终时不时会有人会踩坑。

4、应用默认配置未清除

/ -等默认功能未清理,例如下图可直接执行命令:

心脏滴血漏洞_漏洞心脏滴血怎么回事_漏洞心脏滴血怎么办

5、应用系统打开debug模式

debug模式开启暴露uri路径,()暴露服务器信息甚至等,之后攻击者便可借此进一步渗透,很多白帽子应当有此同感,发现了sql注入但是写不了,如果能遇上个()那是再好不过的事情了。

6、应用漏洞未及时升级

越是通用的应用,就越经常爆出漏洞。有句话说的好:不是因为黑客这个世界才不安全,而是因为不安全才会有了黑客,黑客去揭开那层假象,我们才发现有那么多不安全。于是、、、Nginx、Flash等等CVE接踵而来。

7、权限管理松散

不遵循最小权限原则,给开发提供root权限或者给业务账号授权admin权限。

8、DDoS攻击

DDoS攻击对于运维人员而言,是再熟悉不过的安全问题了。我们都知道通过占满带宽、耗尽资源等方式可让服务器无法响应正常请求,说到底是资源对抗的一种攻击方式。如果仅依赖服务器资源去抗,去过滤,如下图,在大流量、高并发之下,只会引来雪崩:

漏洞心脏滴血怎么回事_漏洞心脏滴血怎么办_心脏滴血漏洞

加上DDoS攻击平台大量存在,而且价格低廉,这就让DDoS攻击成为打压竞争对手、报复、勒索等阴谋诡计者首选方式了。

9、流量劫持

还记得2015年小米、腾讯、微博、今日头条等六家共公司联合发表声明呼吁电信运营商打击流量劫持的报告吗?即便如此,现如今的互联网江湖仍是暗流滚滚。下面介绍三种常见的流量劫持方式,这也是困扰运维安全人员多年的痼疾:

那么,现在就该思考一个问题了:如何做好运维安全?结合专业的运维安全软件,进行全面智能防御,才是解决问题的出路。

云帮手通过辅助甚至部分替代人工决策,进一步提升运维质量和效率,力求实现“事前智能预警、事后快速定位、夜间无人值守、远程集中管理”等一系列的智能运维目标,以应对新环境下的三大运维挑战。

安全巡检,一键修复:提供7*24小时不间断健康巡检、全面体检、系统一键加固、 系统漏洞扫描一键修复,风险将无处可藏

资源监控,即时告警:全方位监控服务器CPU、内存、磁盘、 网络等资源,通过创建告警规则进行智能监控,帮助用户即时反应,处理告警信息,保证程序正常运行

批量管理,一键部署:化繁为简集中批量管理云服务器、一键部署Web、应用运行环境,让运维得心应手、事半功倍

站点管理,简化配置:轻松实现站点、数据库、FTP一站式管理,全面提高运维效率

多重防护,安全保障:全方位立体化纵深防御机制,保障服务器系统安全、应用安全

系统管理,杜绝漏洞:即时管理服务进程,监控安全隐患,提供运行效率,杜绝安全漏洞

日志审计,辅助排障:支持各种系统、应用日志采集汇聚云端,支持可视化运维管理,助力用户洞悉操作细节,辅助排障,提高运维效率

远程登录,文件管理:集成系统RDP远程桌面协议、Linux系统SSH远程登录协议,让远程登录如临其境;模拟文件浏览器,让远程文件管理触手可及

我们从运维安全的概念入手,强调了运维安全困境导致了我们的重视,也从安全意识和基础架构建设上剖析了导致该困境的原因,希望通过运维安全意识培养、运维安全规范以及运维安全技术体系的建设,来保障一套完整的运维安全体系的有效运转,为业务发展保驾护航。

​​​

~

网络安全学习,我们一起交流

~

  • 17
    点赞
  • 18
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值