mirror of
https://github.com/cheetahlou/CategoryResourceRepost.git
synced 2025-10-20 17:03:47 +08:00
mod
This commit is contained in:
111
极客时间专栏/安全攻防技能30讲/知识串讲/模块串讲(一) | Web安全:如何评估用户数据和资产数据面临的威胁?.md
Normal file
111
极客时间专栏/安全攻防技能30讲/知识串讲/模块串讲(一) | Web安全:如何评估用户数据和资产数据面临的威胁?.md
Normal file
@@ -0,0 +1,111 @@
|
||||
<audio id="audio" title="模块串讲(一) | Web安全:如何评估用户数据和资产数据面临的威胁?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a6/59/a66f948ea2f871445493f2db4d406059.mp3"></audio>
|
||||
|
||||
你好,我是何为舟。“Web安全”模块已经结束了,今天我会通过一篇串讲,带你回顾这一模块的知识,帮你复习巩固,更好地掌握和应用这些内容。
|
||||
|
||||
有同学留言说:“老师,讲了这么多漏洞的防护知识,有没有什么好的记忆方法呀?”首先,我们要明确一点,不管学什么知识,想要学好,在前期,一定需要时常复习来加深记忆。在此基础上,我们才能深刻理解和熟练应用这些知识。
|
||||
|
||||
那你可能要说了,怎么才能“记住”这些知识呢?我这里有一个我自己非常常用的、好的记忆方法,那就是“体系化地记忆”。怎么个体系化呢?说白了,就是每学完一块内容,通过自己的理解把相关的内容串联在一起。这也就是我们常说的,把知识变成自己的东西,长久下来,你就可以形成自己的知识体系了。
|
||||
|
||||
那放到我们这个“Web安全”模块中,我说过,安全落地的第一步是进行[威胁评估](https://time.geekbang.org/column/article/178528),而威胁评估又可以分为:识别数据、识别攻击和识别漏洞。所以,今天我就基于比较常见的两种应用场景,通过威胁评估的方式,带你系统地复习我们学过的Web安全知识。
|
||||
|
||||
## 用户数据的威胁评估
|
||||
|
||||
假设,你正在为公司设计安全体系,首先要对用户数据进行威胁评估。以微博的用户数据为例,这些数据就包括:个人信息、博文信息以及关注互动信息等等。正常情况下,用户需要登录之后才能获取并修改自己的用户数据。那为了获取这些用户数据,黑客常常会通过盗取用户身份来进行未授权的操作。
|
||||
|
||||
我们之前讲过,黑客可以通过尝试弱密码或者通过社工手段盗取用户的密码。这种攻击漏洞出现的原因,主要是用户在密码保管上的安全意识薄弱。因此,我们需要通过管理机制(比如安全培训)和技术手段(比如限制密码强度),提升用户的安全意识,教用户如何更好地保管密码。
|
||||
|
||||
除此之外,黑客还可以通过一些Web漏洞,在不知道用户密码的情况,模拟用户进行未授权的操作。可能的Web漏洞我们讲过3种。你可以先自己想想,看能想起来几种。如果想不起来,再看我下面的内容。
|
||||
|
||||
**第1个是XSS漏洞**。通过XSS漏洞,黑客可以在Web应用中嵌入自己的JavaScript脚本,从而篡改Web应用在用户浏览器上的行为。通过XSS,黑客一方面可以模拟用户,直接在Web应用中进行发博关注等互动行为;另一方面,也可以通过JavaScript脚本,窃取到用户的Cookie信息。窃取到Cookie之后,黑客就能够在不知道密码的情况下,**绕过登录认证环节,直接获得用户身份。**
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/7d/f5/7d77973b1623717cd519b0d3f8b7d4f5.jpg" alt="">](https://time.geekbang.org/column/article/179592)
|
||||
|
||||
>
|
||||
点击图片即可复习“XSS”章节
|
||||
|
||||
|
||||
**第二个是SQL注入漏洞**。通过SQL注入漏洞,黑客可以利用所谓的“万能密码”,直接对登录环节进行破解。通过“万能密码”,黑客可以将原本的登录认证SQL语句进行篡改,使其变成一个恒为真的表达式,让应用误以为黑客输入的是正确的用户名和密码。这样,黑客就能**破解登录认证环节,直接获得用户身份。**
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/dc/28/dca53475b9ec945b9bd3dd30f37b6328.jpg" alt="">](https://time.geekbang.org/column/article/181424)
|
||||
|
||||
>
|
||||
点击图片即可复习“SQL注入”章节
|
||||
|
||||
|
||||
**最后一个是CSRF漏洞**。通过CSRF漏洞,黑客能够直接对用户的浏览器进行控制。当黑客在自己的网页中,向其他网页发起跨域请求的时候,浏览器会自动带上对应网页的Cookie等信息。因此只要用户之前进行过认证,并且已经将登录凭证保存在浏览器中,黑客就能**以用户的身份发起未授权的操作请求。**
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/5c/70/5c0e68d5766befd701ab3f3fae3eea70.jpg" alt="">](https://time.geekbang.org/column/article/182074)
|
||||
|
||||
>
|
||||
点击图片即可复习“CSRF和SSRF”章节
|
||||
|
||||
|
||||
我们来总结一下这个过程。我们正在为公司设计安全体系进行威胁评估,首先关注的数据通常是用户数据,而为了破坏用户数据的CIA,黑客会盗取用户身份。盗取用户身份的安全漏洞,主要有用户自身的密码保管不当和Web应用的漏洞。这其中,Web应用的漏洞可能是XSS、SQL注入和CSRF。
|
||||
|
||||
## 资产数据的威胁评估
|
||||
|
||||
讲完了用户数据的威胁评估,我们再以银行为例,说一说资产数据的威胁评估。因为金融行业相对更关注金钱相关的数据,所以,在做威胁评估时,最可能识别到的数据就是资产数据。这些资产数据中包括余额和交易记录等。因为资产数据保存在内部的数据库中,所以,黑客会通过控制内网服务器这样的攻击手段,窃取数据库中的信息。你可以先想一想,我们讲过的攻击方式,哪些可以控制内网服务器。
|
||||
|
||||
**我们先来看第1种:利用SSRF漏洞攻击**。通过SSRF漏洞,黑客可以控制服务器,向内网发起任意的网络请求。因此,如果某个内网的Web服务没有做好认证,黑客就可以获取到Web服务内的数据。除此之外,通过对一些特定端口或者协议的访问,黑客还能够获取其他的数据。比如,通过访问MySQL的3306端口,黑客能够知道内网的整体网络结构;或者通过file://协议,黑客可以直接读取服务器本地的文件。
|
||||
|
||||
**第2种是利用反序列化漏洞攻击**。通过反序列化漏洞,黑客可以控制应用的服务端,使得服务端执行黑客所定义的逻辑。更进一步,比如在Java中,黑客指定应用执行Runtime.exec(),就能够让应用执行任意的系统命令了。这样一来,黑客就能够实现从控制应用到控制服务器的权限提升了。
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/31/cb/31c5f69c95170783b7b3a38fc94105cb.jpg" alt="">](https://time.geekbang.org/column/article/182421)
|
||||
|
||||
>
|
||||
点击图片即可复习“反序列化漏洞”章节
|
||||
|
||||
|
||||
**第3种是利用插件漏洞攻击**。除了应用开发的代码中可能出现漏洞,应用所依赖或者使用的插件本身,也有可能出现各种安全漏洞。比如,经典的Web框架Structs,就出现过命令执行的漏洞。不管你的代码如何安全,只要你使用了Structs,黑客就能通过Structs来控制你的服务器。
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/7f/6d/7f07e241ed3066fba2c190cb840f8f6d.jpg" alt="">](https://time.geekbang.org/column/article/184728)
|
||||
|
||||
>
|
||||
点击图片即可复习“插件漏洞”章节
|
||||
|
||||
|
||||
**我们还要注意的就是“后门”**。除了通过前面这3种漏洞攻击控制服务器之外,黑客为了能够对服务器实现长久的控制,会在服务器中留下“后门”。这样一来,黑客想要再次使用服务器的时候,只需要直接通过“后门”进入即可。“后门”通常会以木马、Rootkit和WebShell的形式出现在服务器中,并伴随定时任务、开机启动或者利用常驻进程在服务器中持续运行。
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/96/62/963a79368db3dbe99ace71f060a61762.jpg" alt="">](https://time.geekbang.org/column/article/185307)
|
||||
|
||||
>
|
||||
点击图片即可复习“权限提升和持久化”章节
|
||||
|
||||
|
||||
通过威胁评估我们知道,银行的关键数据为资产数据,而为了破坏资产数据的CIA,黑客会通过控制内网服务器的方式来发起攻击。接着,我们分析出在Web安全中,黑客可以利用的漏洞有SSRF、反序列化漏洞和插件漏洞,以及黑客还会在服务器中留下一个“后门”,实现对服务器的长期掌控。
|
||||
|
||||
## 认证和授权的安全防护
|
||||
|
||||
在进行完威胁评估之后,我们知道了应用可能会面临的风险和漏洞有哪些。下一步,我们就要针对这些漏洞进行防护了。
|
||||
|
||||
实际上,上面这些Web漏洞都是针对认证这一个环节发起的攻击,也就是说,通过各种漏洞,黑客可以直接绕过认证环节,或者通过异常的输入破解认证,再或是以操控他人的形式来窃取身份信息。因此,对于这些漏洞的防护,我们最有效的防护手段还是加强检测,避免这些漏洞的出现,以此来保障认证环节的安全性。你可以回忆一下,我们讲过的检测手段都有哪些。
|
||||
|
||||
主要的防护手段可以分为3种。
|
||||
|
||||
**第1种是检测和过滤**。对于应用来说,一切由用户生成的信息,都是不可信的。因此,我们要对这些信息进行检测和过滤。比如,在页面渲染输出的时候,对信息进行编码;在用户输入的时候,对关键词进行过滤;对用户的输入进行白名单的限制等。通过这些方法,我们就能够对基于XSS、SQL注入和SSRF等漏洞的攻击进行一定的防护。
|
||||
|
||||
**第2种是加强认证。**大多数情况下,为了用户体验,应用会在用户进行一次登录后,在前端对用户的身份信息进行保存。这样,用户在进行后续操作时就不需要再次登录认证了。但是,这种设计,会对应用的安全性造成一定的影响。因为黑客可能控制用户的前端,来仿冒用户进行操作。为此,对于某些关键性的操作(比如转账等),应用需要通过一次性Token和安全性更高的支付密码等手段进行二次认证,来保障操作的可信。
|
||||
|
||||
**第3种是补丁管理。**我们之前讲过“0 Day”漏洞,黑客通过这个漏洞能够造成的危害更大,而且黑客会比你更早地知道漏洞的存在。那像这样的插件漏洞,其实具备和应用一样甚至更高的权限,但是插件本身又不受开发控制。所以,一旦插件出现漏洞,就极容易成为黑客的目标。为了避免应用受到各类插件漏洞的影响,我们需要使用各种自动化的插件管理工具,对公开的插件漏洞进行监控,及时更新补丁。
|
||||
|
||||
我们可以通过这3种防护手段加强认证环节的安全性。除此之外,我们还要在授权和审计阶段加入检测,来识别异常的身份认证,尽可能地提高应用的安全性。比较典型的方式有3种。
|
||||
|
||||
**第1种最小权限原则。**在任何时候,最小权限原则一定是提升系统安全性的最佳实践方案。通过给各类应用和插件配置最小的权限,虽然不能够对异常的身份认证进行识别。但是,通过最小权限原则,我们能够在最大程度上,减少黑客在窃取到用户身份后产生的危害,也就保护了数据的安全性。
|
||||
|
||||
**第2种是WAF(Web Application Firewall,网站应用级入侵防御系统)。**WAF的主要作用,就是对用户的输入进行检测,拦截可疑地输入。检测原理就是,普通用户在应用中的输入可预测,基本不会去输入类似单引号这样可能对应用功能产生影响的输入。因此,我们只要对各类攻击类型的输入进行分析,提取出来其特征,就可以准确地识别出黑客的攻击行为并进行拦截了。关于WAF,我会在后面的课程中详细讲解,这里就不再深入了。
|
||||
|
||||
**第3种是IDS(Intrusion Detection System,入侵检测系统)。**当黑客进入内网或者控制了服务器之后,其行为往往也会区别于内部员工。比如,黑客可能会对内网发起探测扫描,而内部员工只会按照工作需要访问特定的地址。因此,我们可以对内网和服务器中的各类行为进行收集,对异常的行为进行“挖掘”,从而对已发生的入侵进行检测和告警。这就是IDS。
|
||||
|
||||
## 总结
|
||||
|
||||
今天,我从互联网应用的用户数据的威胁评估,讲到金融行业的资产数据的威胁评估,最后讲到在威胁评估完成后,我们要从认证、授权和审计上有针对性地进行防护。只要你真正用好这几种防护,就能避免大部分的Web安全问题了。
|
||||
|
||||
最后,我把“Web安全”涉及的主要内容梳理成了一张表格,你可以利用它来及时回顾。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/50/65/50986ac4c0b3cbffa4e698921b5d7865.jpg" alt="">
|
||||
|
||||
## 思考题
|
||||
|
||||
在文章开头,我提到了“体系化地记忆”这样一种学习方法。今天,我用我的思路带着你复习了一遍Web安全这一模块的核心知识,不知道你掌握得怎么样?你可以尝试用自己的思路,总结串联一下这一模块的内容,相信你一定会非常有收获。
|
||||
|
||||
欢迎留言和我分享你的思考和疑惑,也欢迎你把文章分享给你的朋友。我们下一讲再见!
|
98
极客时间专栏/安全攻防技能30讲/知识串讲/模块串讲(三)| 安全防御工具:如何选择和规划公司的安全防御体系?.md
Normal file
98
极客时间专栏/安全攻防技能30讲/知识串讲/模块串讲(三)| 安全防御工具:如何选择和规划公司的安全防御体系?.md
Normal file
@@ -0,0 +1,98 @@
|
||||
<audio id="audio" title="模块串讲(三)| 安全防御工具:如何选择和规划公司的安全防御体系?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/56/bd/56a2581b9e1813f27ee8a613f25f36bd.mp3"></audio>
|
||||
|
||||
你好,我是何为舟。“安全防御工具”模块讲完了,今天,我还是通过一篇串讲,带你复习巩固这一模块的内容。
|
||||
|
||||
在这个模块中,我们重点讲解了常见的安全防御工具和手段。这些工具和手段包括:安全标准和框架、防火墙、WAF、IDS、RASP、SIEM和SDL等。它们分别从不同的方面,为公司提供了防御攻击和发现漏洞的能力,也是公司安全防御体系的重要组成部分。
|
||||
|
||||
既然这些工具和手段已经这么成熟了,是不是直接使用它们在公司的环境中“跑一跑”就万事大吉了呢?据我了解,确实有部分公司是这么做的,而且这么做下来之后,还能够通过等保测评。
|
||||
|
||||
但是,这种做法并不可取。因为安全防御工具只是工具,最终好不好用,还是取决于人。只有对安全工具进行合理的选择和规划,我们才能搭建出最符合公司实际情况的防御体系。
|
||||
|
||||
接下来,我就结合几个典型的安全场景来和你聊一聊,在不同安全场景下,我们应该如何做好公司的安全防御体系。
|
||||
|
||||
## 场景一:公司发展初期,没有真实的攻击发生
|
||||
|
||||
我们先来看第一个安全场景:公司刚刚成立,业务还在发展初期。这时,黑客还没有注意到业务的存在,没有真实的攻击发生。
|
||||
|
||||
这种情况下,如果公司领导仍然有安全意识,愿意投入一定精力去发展安全,那在这样的公司做安全就十分幸运了。
|
||||
|
||||
在这个场景中,安全的发展有五个明显的优势。
|
||||
|
||||
- 业务体量小:业务在发展初期,不论是功能逻辑、代码量还是服务器环境都不复杂。这时,开展威胁评估工作十分简单。同时,由于对外的入口少,安全防御也很容易做到全面覆盖。
|
||||
- 用户量少:我们在使用业务的用户还比较少的时候,做出安全改动,那公司要考虑的用户影响也比较小。这个时候,我们推动安全工作面临的阻力也就小很多。
|
||||
- 开发人员少:业务初期可能只有不超过十个人的开发团队。在这样一个小的团队中,我们可以通过深度沟通的方式,来推动安全培训和安全制度的落地。
|
||||
- 领导支持:业务初期就考虑安全,也反映了领导对安全的认可和重视。从一开始就是自上而下进行安全发展,也就更容易为安全争取到各类资源投入。
|
||||
- 安全需求不急迫:业务知名度不高,还没有黑客注意,所以严格来说,是不存在真实的安全威胁的。我们完全可以按部就班,从基础开始一步步搭建安全防御体系。
|
||||
|
||||
在这样不紧迫且有足够推动力的情况下,安全建设的最优方案,一定是从基础开始做起。那么,安全的基础工作是什么呢?
|
||||
|
||||
我认为是安全制度。因为一切安全问题的根源其实都是人。比如,由于员工缺乏安全意识导致的安全漏洞,懒惰疏忽导致的安全误操作等。所以,安全建设的第一步,是通过规章制度规范化人的操作行为,避免安全漏洞的产生。
|
||||
|
||||
对于开发工作来说,SDL就是一个不错的参考。先进行深度的安全培训,然后在开发的各个环节中嵌入安全需求和工作,最终保持安全监控和应急响应;对于管理工作来说,等保中的5类安全管理内容,ISO27001中的安全策略、安全组织等,都是非常值得借鉴的。我们可以从这些标准中选取合适的细则(如安全机构的组成和职责等),来组成自身的安全管理制度。
|
||||
|
||||
另一方面,因为人员较少且领导支持,所以落地安全制度也相对容易。我们可以在落实安全制度的过程中,根据需求引用各种安全防御工具。比如:在安全制度中,如果要求对网络和设备进行隔离,那我们就使用防火墙;如果要求有集中的安全管控,那我们就使用SIEM;如果对数据安全作要求,那我们就使用DLP等。
|
||||
|
||||
最终,随着公司的发展,安全制度也会随之调整,公司的安全防御体系,也会根据安全制度逐渐完善。
|
||||
|
||||
## 场景二:公司发展中后期,没有真实的攻击发生
|
||||
|
||||
接下来,我们要讨论第二个安全场景:公司经过一段时间的发展,业务已经逐渐成熟,并且积累了一定的用户量。这个时候,可能业务中数据的价值还不是很高,所以仍然没有受到黑客的攻击,或者,只有初级的黑客在练手,没有对公司造成真实的影响。
|
||||
|
||||
如果公司因为发展有了安全的合规需求(比如,公司想要上市、或者客户有安全考虑等),就要开始考虑投入资源发展安全了。
|
||||
|
||||
那么我们是否可以继续利用上一个场景中的方法,基于安全制度来建设安全防御体系呢?当然是不可以的。
|
||||
|
||||
事实上,这个场景中的安全条件和上一个场景完全相反:业务大、用户多、开发多、领导不完全支持和有紧迫的安全需求。所以,这些条件就成为了安全发展的阻力。也就是说,我们仍然可以制定安全制度,但是,安全制度还是会因为阻力过大而无法落地。
|
||||
|
||||
为了更好地落地安全制度,我们可以从可见收益最大的方向入手,表明安全工作的有效性,说服领导和同事支持安全的发展。那么,可见收益最大的安全工作有哪些呢?
|
||||
|
||||
一般来说,**发现安全问题最直接的方法就是安全测试**。没有安全介入和培训的开发工作,必然会存在各种安全漏洞。如果我们能通过加入安全测试环节,检测出这些安全漏洞,就非常有说服力了。
|
||||
|
||||
**另一种发现安全问题的直接方法是安全演练**。如果我们想要测试员工的安全意识,就可以发送内部钓鱼邮件;如果我们想要找出线上应用的缺陷,就可以发起一次安全渗透攻击;如果我们想要找出管理或运维上的不足,就可以模拟一次内鬼入侵事件。
|
||||
|
||||
这些演练的最终结果,往往会让领导意识到安全问题的严重性。这样一来,你再针对这些发现的问题,引用各种安全防御工具或者手段就顺利很多了。
|
||||
|
||||
除了安全测试和安全演练,**满足合规需求是很多公司领导唯一关心的指标**。在这种情况下,我们就必须依据法律法规开展安全工作了。比如说:
|
||||
|
||||
- 网络安全法要求网络和系统日志留存大于6个月
|
||||
- 数据安全审查时要求对密码、隐私信息等关键数据进行分类、加密存储
|
||||
- 为了通过等级保护的评测,引入各类安全防御工具
|
||||
|
||||
有了这些有规可依的强需求,我们推动公司投入资源进行对应的安全建设也就底气十足了。
|
||||
|
||||
这些可见收益最大的安全工作,可以让安全部门在公司站住脚,让安全得到公司领导的认可。但需要注意的是,它们还不足以实现一个成熟的公司安全防御体系。所以,当安全部门在公司立住脚跟之后,我们还是要根据具体的安全问题,逐渐完善公司的安全防御体系,以点带面推动公司的安全发展。
|
||||
|
||||
## 场景三:有真实攻击发生
|
||||
|
||||
最后,我们来看一个比较常见的安全场景:公司已经因为黑客的攻击,造成了重大的经济损失。这时,公司就不得已要开始投入资源,建设安全防御体系了。
|
||||
|
||||
在这个场景中,安全工作是以一种“救火”的状态开始的。一般来说,”救火“的过程是这样的:出现了黑客的攻击,安全人员去分析攻击路径,发现安全漏洞,采用最简单、直接的方式进行修复。比如说,在发现黑客是利用了某个应用的Web漏洞发起攻击之后,安全人员就会直接修复相应的漏洞。
|
||||
|
||||
持续救火对安全的发展没有任何帮助。因此,我们需要在“救火”的过程中,逐步升级我们的工具。
|
||||
|
||||
我们还是以Web攻击为例。最开始修复这个Web漏洞的时候,我们可能是直接找到对应的开发人员,告诉他们怎么修改。但我们很快意识到,可能还有很多Web漏洞没有被发现。为了快速填补大部分的Web漏洞,我们就需要考虑投入精力去做一个WAF了。
|
||||
|
||||
随着WAF的落地,针对Web的攻击大大减少,会转而出现更深层次的攻击。这个时候,我们可以考虑推广RASP,从更底层的地方拦截黑客的攻击。如果有合适的契机,我更建议你推广SDL,更进一步避免漏洞的产生。
|
||||
|
||||
总之,在这个场景中,最常见的安全防御体系的发展方式就是:先快再好。也就是先选择最容易部署落地的防御工具和手段(比如,防火墙、WAF和IDS等),快速填补完大规模的漏洞之后,再在已有的基础之上,逐步完善和深入,最终形成成熟的公司安全防御体系。
|
||||
|
||||
## 总结
|
||||
|
||||
在不同的安全场景下,想要做好安全防御体系,离不开合理地落地安全制度、使用安全防御工具和手段。
|
||||
|
||||
1.在最理想的情况下,我们应当以安全制度为基础规范人的行为,避免安全问题的出现。
|
||||
|
||||
2.在公司对安全需求不明确的时候,我们需要找出显著的安全问题,表现出安全工作能够产出的收益。
|
||||
|
||||
3.当有真实的攻击发生时,我们要先快速阻断攻击,再逐步深入、彻底解决安全问题。
|
||||
|
||||
另外,虽然每一个安全防御工具都有成熟的商业产品和使用模式,但在实际建设安全防御体系的时候,我们还是要根据公司的实际情况和领导需求,来选择和规划不同的安全防御工具。而能否设计出适合公司发展的安全体系,其实也是对每一位安全人员的最大考验。<br>
|
||||
<img src="https://static001.geekbang.org/resource/image/71/6c/71c104c68448a3d4380cfe51655bdc6c.jpg" alt="">
|
||||
|
||||
## 思考题
|
||||
|
||||
最后,我们还是来看一道思考题。
|
||||
|
||||
我们今天讲了三种典型的安全场景,你们公司属于哪种场景呢?你可以试着思考一下,如果让你来推动公司的安全发展,你首先要解决的问题是什么呢?
|
||||
|
||||
欢迎留言和我分享你的思考和疑惑,也欢迎你把文章分享给你的朋友。我们下一讲再见!
|
94
极客时间专栏/安全攻防技能30讲/知识串讲/模块串讲(二)| Linux系统和应用安全:如何大范围提高平台安全性?.md
Normal file
94
极客时间专栏/安全攻防技能30讲/知识串讲/模块串讲(二)| Linux系统和应用安全:如何大范围提高平台安全性?.md
Normal file
@@ -0,0 +1,94 @@
|
||||
<audio id="audio" title="模块串讲(二)| Linux系统和应用安全:如何大范围提高平台安全性?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/b3/f1/b3ebdab00eaecff243e3df8ed01229f1.mp3"></audio>
|
||||
|
||||
你好,我是何为舟。“Linux系统和应用安全”模块讲完了,今天我通过一篇串讲,带你复习巩固一下这一模块的内容。
|
||||
|
||||
在这一模块中,我们重点讲解了,在开发过程中经常要接触或使用的平台、工具的安全功能。这些平台和工具包括:Linux系统、网络、容器、数据库和分布式平台。
|
||||
|
||||
那通过对这些平台和工具的安全功能分析,相信你已经知道了,应该如何正确配置和使用这些工具,来避免底层应用出现安全隐患,以防影响整个应用的安全性。
|
||||
|
||||
公司中有很多研发和运维人员,他们都在使用和维护自己的系统和应用,那要怎么保证他们都能够去采用最安全的配置呢?
|
||||
|
||||
## 重点知识回顾
|
||||
|
||||
在解决这个问题之前,我们先来回顾一下,Linux系统、网络、容器、数据库和分布式平台这些平台、工具的安全功能有哪些。
|
||||
|
||||
专栏一开始,我说过:安全的本质是数据的CIA,而保护数据CIA的办法就是黄金法则和密码学。因此,在讲解各个平台和工具的安全功能时,我都是以黄金法则和密码学为线索来探讨的。
|
||||
|
||||
所以,今天我还是以黄金法则和密码学为线索,带你系统梳理一下本模块的重点内容。希望通过今天的讲解,你能在此基础上总结出自己的学习经验和知识框架。
|
||||
|
||||
在之前的课程中,我都详细讲过这些安全功能了,你可以根据我梳理的知识脑图进一步复习巩固。在这里,我就挑一些重点内容着重强调一下。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/12/35/12d23b6cfa9f6813fef65a447a15cd35.jpg" alt="">
|
||||
|
||||
### 1.认证
|
||||
|
||||
认证的目的在于明确用户的身份标识。在各个平台和工具中,基本都会提供各类形式的认证功能,包括:账号密码、公私钥、证书和单点登录等形式。对于认证来说,最大的问题在于弱密码导致的登录凭证丢失。对于这个问题的防护,主要的解决办法是强化密码管理策略,比如:限制最低密码强度、定期修改密码。
|
||||
|
||||
### 2.授权
|
||||
|
||||
授权的目的在于限定用户的行为,但是授权的形式多种多样,在不同平台中都有不同的体现形式。**授权最核心的原则就是最小权限原则,**所以对于任何平台来说,落实最小权限原则,都是在加强授权安全性中最直接、有效的一步。
|
||||
|
||||
### 3.审计
|
||||
|
||||
审计的基础是日志。对于各个平台的审计功能,我们主要需要关注它们会产生哪些日志,以及日志的信息是否充足。
|
||||
|
||||
这里,我要强调一下**Docker容器的审计。**Docker日志可以分为Docker容器产生的日志和Docker容器内应用产生的日志。
|
||||
|
||||
Docker容器日志由Docker守护进程统一管理,通过docker-compose的logging选项,我们可以定义日志的管理策略。
|
||||
|
||||
Docker容器内应用的日志和Linux系统日志一致,但是Docker容器是一个临时的环境,无法持久保存日志。因此,我们可以通过文件共享功能,将宿主机目录挂载到容器内,从而实现日志的持久化保存。
|
||||
|
||||
### 4.加密
|
||||
|
||||
事实上,黄金法则只能起到保护的作用,也就是保证用户在正常使用应用的时候,不会破坏数据的CIA。但是,很多时候,黑客也会通过非正常的方式去窃取和篡改数据(比如窃听网络流量、物理盗取硬盘等)。这个时候,我们就需要依靠密码学来对数据进行保护了,确保只在正确使用应用的情况下,才能解密数据。
|
||||
|
||||
那我们来看一下Linux系统中的加解密。Linux是底层的操作系统,它不负责对应用数据进行加密。但是,Linux系统本身仍然需要提供一些应用层的功能(比如最基础的登录),而这些功能往往需要用到加解密。比如,在/etc/shadow中,密码的存储形式如下所示:
|
||||
|
||||
```
|
||||
root:$6$d9k5nMkuTqDf7dET$C8qwu4q2a96BItyIMhI8oNVpEzztvG/8P6BdEjmAZJS5s4Ad66MI9HxKDtImz7m.QSvVZgk7BhCLM5pFnro1U0::0:99999:7:::
|
||||
|
||||
```
|
||||
|
||||
对这行数据按冒号进行分隔,第二部分就是密码部分。密码部分按$进行分隔,第一个“6”是散列算法,第二个“d9k5nMkuTqDf7dET”是盐,第三个是最终的散列值。所以,在Linux中,用户登录进行密码匹配的过程,其实就是判定密码加盐后的散列值是否一致的过程。
|
||||
|
||||
## 如何大范围提高平台安全性?
|
||||
|
||||
回顾完这些重点内容之后,我们来看文章开头提到的问题:怎么保证公司内的研发和运维人员都能够去采用最安全的配置,也就是如何大范围提高平台的安全性。
|
||||
|
||||
首先,最简单、直接的一个方案就是安全培训。但是,如果你做过培训或者参加过培训,一定能够感受到,强制性培训的效果其实很不理想。因此,我们必须要采用有效的技术手段,提升研发和运维人员的安全意识。基于这个目的,行业内提出了“安全基线”的概念。
|
||||
|
||||
所谓“安全基线”,就是由安全人员制定的一系列安全规范,这些规范可以通过技术手段进行检测。比如,在Linux的密码管理中,我们可以将密码管理规范定义为:一个用户60天内必须修改密码,并且必须开启强制修改密码配置。
|
||||
|
||||
如果我们想要检测这个规范也很容易。我们可以通过下面的脚本,来检查一下/etc/shadow中ROOT用户的最后修改密码时间。
|
||||
|
||||
```
|
||||
last=$(grep root /etc/shadow | awk -F ":" '{print $3}')
|
||||
date -u -d "1970-01-01 $last days" "+%Y-%m-%d"
|
||||
|
||||
```
|
||||
|
||||
然后,我们只需要将这个脚本,放到所有的Linux系统中执行一遍,就能够知道在公司环境中,有多少root用户已经长期没有修改密码了。对于这些不符合要求、存在安全风险的Linux系统。发现之后,我们只需要点对点的要求对应系统的管理员去完善就可以了。
|
||||
|
||||
一个好的安全基线,需要事无巨细地覆盖到黄金法则的方方面面,所以需要专业的安全人员来制定。不过,很多公司的安全基线是可以共用的,因此,有一些安全公司把常见的系统和应用的安全基线进行了总结,比如知名的[CIS Benchmarks](https://www.cisecurity.org/cis-benchmarks/)。有了CIS的标准安全基线,我们就可以实现通用的基线检查工具了,比如Docker中比较知名的[Docker Bench for Security](https://github.com/docker/docker-bench-security),就是基于CIS的Docker安全基线开发出来的。
|
||||
|
||||
那有了安全基线的检测,是不是就“万事大吉”了呢?其实不是。在我们实际检测的过程中,很容易出现系统不符合安全基线,我们也告知了开发人员存在的风险,但开发人员不买账的情况。
|
||||
|
||||
比如说,CIS中关于Centos的基线要求/tmp目录必须挂载在单独的分区,并且设置/tmp中的文件全部不可执行。这当然是合理的,因为黑客通常会将木马、后门等文件下载到/tmp目录中再执行。但是,想要完成这个操作,你必须下载一个工具LVM来进行配置。而安全基线只是一个预防针,它并不会产生实际的收益。所以,你没有足够的理由去强制要求开发人员,花费这个精力来满足你想要实施的安全基线。这个时候,我们应该怎么办呢?
|
||||
|
||||
目前,最优的解决方案就是在一开始,我们就分配给开发人员一个符合安全基线的系统。这样一来,只要开发人员不去修改配置,就不会违背安全基线了。要实现这个功能,我们首先需要自己配置出一个符合安全基线的系统,然后将这个系统打包成镜像,应用到后续的系统安装过程中,按照我们刚才说的[CIS Benchmarks](https://www.cisecurity.org/cis-benchmarks/)配置就可以了。
|
||||
|
||||
简单总结一下,通过定义安全基线、配置安全镜像,我们就能够提供整个公司的系统和平台工具安全性。在这之后,我们只要配合基线检查工具进行定期的检测,并提醒开发、运维人员不要去修改安全配置,就能够将安全性保持在一个较高的水平了。
|
||||
|
||||
## 总结
|
||||
|
||||
好了,通过对Linux系统、网络、容器、数据库和分布式平台的安全功能分析,我们发现,黄金法则和加密始终贯穿于安全防护体系之中。每一个工具,甚至每一个单独的功能,都可以根据黄金法则去思考需要提供的安全能力和基本的加解密功能,来防止黑客非正常手段的攻击。
|
||||
|
||||
除此之外,公司是一个整体,只有你个人系统和工具的安全性提升了,并不会有太大效果。因此,我们需要利用安全基线,来提升公司整体的安全水平避免出现短板。
|
||||
|
||||
## 思考题
|
||||
|
||||
通过今天的串讲梳理,相信你已经对Linux系统和应用的安全有一个全面的认知了。
|
||||
|
||||
你可以思考一下,你接触过的其他平台或者工具,它们在黄金法则和加解密上,又分别提供了哪些功能呢?
|
||||
|
||||
欢迎留言和我分享你的思考和疑惑,也欢迎你把文章分享给你的朋友。我们下一讲再见!
|
Reference in New Issue
Block a user