![][image-2]

安全本质

任何应用最本质的东西都是数据，安全的本质就是保护数据被合法地使用

机密性（Confidentiality）、完整性（Integrity）、可用性（Availability），我们可以简称为 CIA 三元组，是安全的基本原则。

• 机密性，确保数据只被授权的主体访问，不被任何未授权的主体访问（不可见）
• 完整性，确保数据只被授权的主体进行授权的修改（不可改）
• 可用性，可用性就是确保数据能够被授权的主体访问到（可读）

安全原则

黄金法则主要包含三部分：认证（Authentication）、授权（Authorization）、审计（Audit）

串联的关系，它描述的其实是用户在使用应用过程中的生命周期：先进行登录、再进行操作、最后留下记录。大部分情况下，事前防御属于认证，事中防御属于授权，事后防御属于审计。 企业建立安全体系，挖掘安全问题，明确安全计划

密码学基础

对称加密算法

所谓对称加密，代表加密和解密使用的是同一个密钥。常见的经典对称加密算法有 DES、IDEA、AES、国密 SM1 和 SM4 ![][image-3] ![][image-4]

非对称加密算法

非对称加密代表加密和解密使用不同的密钥。具体的加解密过程就是，发送方使用公钥对信息进行加密，接收方收到密文后，使用私钥进行解密.RSA、ECC 和国密 SM2 ![][image-5] ![][image-6] ![][image-7]

散列算法

大量的应用都在使用 MD5 或者 SHA 算法计算一个唯一的 id。比如 Git 中的提交记录、文件的完整性校验、各种语言中字典或者 Map 的实现等等。另外，我们在使用散列算法的时候，有一点需要注意一下，一定要注意加“盐”。所谓“盐”，就是一串随机的字符，是可以公开的。将用户的密码“盐”进行拼接后，再进行散列计算，这样，即使两个用户设置了相同的密码，也会拥有不同的散列值。同时，黑客往往会提前计算一个彩虹表来提升暴力破解散列值的效率，而我们能够通过加“盐”进行对抗。“盐”值越长，安全性就越高 ![][image-8]

身份认证

对外认证和对内认证

对外认证是单一场景下的认证，对内认证是多场景下的认证。

• 对外认证，其实就是应用的登录注册模块，它面向用户进行认证。对外认证的入口比较集中，一个应用通常只有一个登录入口
• 除了应用本身需要有登录注册的模块，应用的各种内部系统同样需要涉及登录认证的功能，比如：服务器的登录、数据库的登录、Git 的登录、各种内部管理后台的登录等等

身份认证的威胁

• 没有认证环节
• 弱密码
• 认证信息泄露Have I Been Pwned: Check if your email has been compromised in a data breach

身份认证的安全保证

不只是在解决一个技术问题，还要培养外部用户和内部员工的安全意识

• 对密码的强度进行限制（如强制使用字母、数字、特殊字符的组合密码，并达到一定长度），强制用户定期修改密码，对关键操作设置第二密码（如微信、支付宝的支付密码）等等。
• 通过手机验证替代密码验证（因为丢失手机的几率比丢失密码的几率低）；通过人脸、指纹等生物特征替代密码。
• 通过加密信道（如 HTTPS）来防止窃听；也可以通过给下发的凭证设置一个有效期，来限制凭证在外暴露的时间，以此来减少重放攻击带来的影响

单点登录解决身份认证问题

CAS 流程、JWT、OAuth 和 OpenID

• CAS（Central Authentication Service，集中式认证服务）流程 ![][image-9]
• JWT（JSON Web Token） 在客户端保存一个凭证信息，之后在你每一次登录的请求中都带上这个凭证，将其作为登录状态的依据。JWT 的好处在于，不需要应用服务端去额外维护 Cookie 或者 Session 了。但是，正是因为它将登录状态落到了客户端，所以我们无法进行注销等操作了。
• OAuth（Open Authorization） 主要特点是授权
• OpenID（Open Identity Document） 和 OAuth 的功能基本一致。但是，OpenID 不提供授权的功能。最常见的，当我们需要在应用中使用微信支付的时候，应用只需要收集支付相关的信息即可，并不需要获取用户的微信头像。

JWT 适用范围广，在单点登录的选取上面，如果想要将用户信息做统一管理，选择它最为简单；如果认证中心只是被用来维护账号密码，由业务去维护用户所绑定的其他手机等信息，那么，采用 OAuth 更合适

访问控制

访问控制模型

一个主体请求一个客体，这个请求的授权由访问控制来完成 主体：请求的发起者。主体可以是用户，也可以是进程、应用、设备等任何发起访问请求的来源。 客体：请求的接收方，一般是某种资源。比如某个文件、数据库，也可以是进程、设备等接受指令的实体。 请求：主体对客体进行的操作。常规的是读、写和执行，也可以进一步细分为删除、追加等粒度更细的操作。

常见的访问控制机制

• DAC（Discretionary Access Control，自主访问控制） DAC 就是让客体的所有者来定义访问控制规则，DAC 的特性其实就是将安全交到了用户手中，因此，DAC 适合在面向用户的时候进行使用。当用户需要掌控自己的资源时，我们通常会采取 DAC，来完成访问控制。比方说，Linux 中采用的就是 DAC，用户可以控制自己的文件能够被谁访问
• role-BAC（role Based Access Control，基于角色的访问控制） Role-BAC 是防止权限泛滥，实现最小特权原则的经典解决方案 采用了 role-BAC，那么管理员只需要简单地将用户从一个角色转移到另一个角色，就可以完成权限的变更
• rule-BAC（rule Based Access Control，基于规则的访问控制） DAC 是所有者对客体制定的访问控制策略，role-BAC 是管理员对主体制定的访问控制策略，而 rule-BAC 可以说是针对请求本身制定的访问控制策略。rule-BAC 适合在复杂场景下提供访问控制保护，因此，rule-BAC 相关的设备和技术在安全中最为常见。一个典型的例子就是防火墙。防火墙通过将请求的源 IP 和端口、目标 IP 和端口、协议等特征获取到后，根据定义好的规则，来判定是否允许主体访问。比如，限制 22 端口，以拒绝 SSH 的访问。同样地，应用也往往会采取风控系统，对用户异常行为进行判定。
• MAC（Mandatory Access Control，强制访问控制） 在互联网中，主体和客体被划分为“秘密、私人、敏感、公开”这四个级别。MAC 要求对所有的主体和客体都打上对应的标签，然后根据标签来制定访问控制规则。 MAC 不允许低级别的主体读取高级别的客体、不允许高级别的主体写入低级别的客体；为了保证完整性，MAC 不允许高级别的主体读取低级别的客体，不允许低级别的主体写入高级别的客体 ![][image-10]

威胁评估的步骤

威胁评估主要有三个步骤：识别数据、识别攻击、识别漏洞
近两年来由 MITRE 提出的ATTACK框架比较知名。在识别漏洞的时候，我们可以基于这些总结性框架去进行罗列。

web安全

XSS

XSS攻击产生

通过给定异常的输入，黑客可以在你的浏览器中，插入一段恶意的 JavaScript 脚本，从而窃取你的隐私信息或者仿冒你进行操作

• 反射型 XSS ![][image-12]

• 基于 DOM 的 XSS ![][image-13]
• 持久型 XSS ![][image-14]

XSS攻击危害

• 窃取 Cookie 受SOP（Same Origin Policy，同源策略）保护，我们在 server.com 中是无法直接向 hacker.com 发送 GET 或者 POST 请求的。这也是为什么，在上面的例子中，我们需要通过 window.location 来执行跳转操作，间接地将 Cookie 信息发送出去。除了 window.location 之外，我们还可以通过加载 JavaScript 文件、图片等方式，向 attacker.com 发送带有 Cookie 的 GET 请求。
• 未授权操作 利用 JavaScript 的特性，直接代替用户在 HTML 进行各类操作。
• 按键记录和钓鱼 JavaScript 的功能十分强大，它还能够记录用户在浏览器中的大部分操作。比如：鼠标的轨迹、键盘输入的信息等。也就是说，你输入的账号名和密码，都可以被 JavaScript 记录下来，从而被黑客获取到。另外，即使某个存在 XSS 漏洞的页面不具备任何输入框，黑客还可以通过修改 DOM，伪造一个登录框，来诱导用户在本不需要登录的页面，去输入自己的用户名和密码。这也是“钓鱼”的一种形式，在这个过程中用户访问的域名是完全正常的，只是页面被篡改了，所以具备更高的迷惑性。

XSS防护

• 验证输入 OR 验证输出 推荐在需要输出的时候去进行验证，即当需要展示的时候，我们再对内容进行验证，这样我们就能够根据不同的环境去采取不同的保护方案了 ![][image-15]

• 编码 ![][image-16]

• 检测和过滤 在检测中，更推荐使用白名单的规则。因为白名单的规则比较简单，并且十分有效。比如，在只输入一个分数的地方，规定只有整型变量是合法的。这样一来，你就能够检测出 99.99% 的攻击行为了。 应该采取白名单的形式（比如，除了 div 之外的标签全部删除）。

• CSP 面对 XSS 这样一个很普遍的问题，W3C 提出了 CSP（Content Security Policy，内容安全策略）来提升 Web 的安全性。所谓 CSP，就是在服务端返回的 HTTP header 里面添加一个 Content-Security-Policy 选项，然后定义资源的白名单域名。浏览器就会识别这个字段，并限制对非白名单资源的访问

Content-Security-Policy:default-src ‘none’; script-src ‘self’; 
connect-src ‘self’; img-src ‘self’; style-src ‘self’;

SQL 注入

产生

• 修改 WHERE 语句

SELECT * FROM Users WHERE Username ="" AND Password ="" or ""=""

• 执行任意语句 在 MySQL 中，实现任意语句执行最简单的方法，就是利用分号将原本的 SQL 语句进行分割。这样，我们就可以一次执行多个语句了。比如，下面这个语句在执行的时候会先插入一个行，然后再返回 Users 表中全部的数据。

INSERT INTO Users (Username, Password) VALUES("test","000000"); SELECT * FROM Users;

攻击

• 绕过验证 “ or “”=“ 作为万能密码，可以让黑客在不知道密码的情况下，通过登录认证。因此，SQL 注入最直接的利用方式，就是绕过验证，也就相当于身份认证被破解了。
• 任意篡改数据 通过插入 DML 类的 SQL 语句（INSERT、UPDATE、DELETE、TRUNCATE、DROP 等
• 窃取数据 通过类似 SQL 注入的手段，获取到数据库中的全部数据（如用户名、密码、手机号等隐私数据）。最简单的，黑客利用 UNION 关键词，将 SQL 语句拼接成下面这行代码之后，就可以直接获取全部的用户信息了。

SELECT * FROM Users WHERE UserId = 1 UNION SELECT * FROM Users

• 消耗资源 利用 WHILE 打造死循环操作，或者定义存储过程，触发一个无限迭代等等。在这些情况下，数据库服务器因为 CPU 被迅速打满，持续 100%，而无法及时响应其他请求。

防护

• 使用 PreparedStatement 使用 PreparedStatement，将 SQL 语句的解析和实际执行过程分开，只在执行的过程中代入用户的操作。这样一来，无论黑客提交的参数怎么变化，数据库都不会去执行额外的逻辑，也就避免了 SQL 注入的发生。
• 使用存储过程

delimiter $$　　#将语句的结束符号从分号;临时改为两个$$(可以是自定义)
CREATE PROCEDURE select_user(IN p_id INTEGER)
BEGIN
　 SELECT * FROM Users WHERE UserId = p_id;
END$$ 
delimiter;　　#将语句的结束符号恢复为分号

call select_user(1);

• 验证输入 对所有输入进行验证或者过滤操作，能够很大程度上避免 SQL 注入的出现。比如，在通过 userId 获取 Users 相关信息的示例中，我们可以确认 userId 必然是一个整数。因此，我们只需要对 userId 参数，进行一个整型转化（比如，Java 中的 Integer.parseInt，PHP 的 intval），就可以实现防护了。当然，部分场景下，用户输入的参数会比较复杂。我们以用户发出的评论为例，其内容完全由用户定义，应用无法预判它的格式。这种情况下，应用只能通过对部分关键字符进行过滤，来避免 SQL 注入的发生。比如，在 MySQL 中，需要注意的关键词有” % ’ \ _。 浅谈SQL盲注测试方法解析与技巧 - FreeBuf网络安全行业门户

CSRF/SSRF

产生

带有恶意 JavaScript 脚本的网页，通过“钓鱼”的方式诱导你访问。然后，黑客会通过这些 JavaScript 脚本窃取你保存在网页中的身份信息，通过仿冒你，让你的浏览器发起伪造的请求，最终执行黑客定义的操作。而这一切对于你自己而言都是无感知的。这就是 CSRF（Cross-Site Request Forgery，跨站请求伪造）攻击。 ![][image-17]

防护

• 行业内标准的 CSRF 防护方法是 CSRFToken CSRF 是通过自动提交表单的形式来发起攻击的。所以，在前面转账的例子中，黑客可以通过抓包分析出 http://bank.com/transfer 这个接口所需要的参数，从而构造对应的 form 表单。因此，我们只需要在这个接口中，加入一个黑客无法猜到的参数，就可以有效防止 CSRF 了。这就是 CSRF Token 的工作原理 ![][image-18]
• 二次验证

SSRF

SSRF 攻击的实现过程，也就是我们常说的“内网穿透”。 ![][image-19]

• 内网探测
• 文件读取

SSRF 防护

• 白名单的限制永远是最简单、最高效的防护措施

反序列化漏洞

产生

反序列化的过程其实就是一个数据到对象的过程。在这个过程中，应用必须根据数据源去调用一些默认方法（比如构造函数和 Getter/Setter）。

防护

• 认证和签名
• 限制序列化和反序列化的类
• RASP 检测 RASP（Runtime Application Self-Protection，实时程序自我保护）。RASP 通过 hook 等方式，在这些关键函数的调用中，增加一道规则的检测。这个规则会判断应用是否执行了非应用本身的逻辑，能够在不修改代码的情况下对反序列化漏洞攻击实现拦截

信息泄露

错误信息泄露属于一种间接的信息泄露方式。间接的信息泄露方式主要是通过拼凑各种零散信息，还原出代码整体的面貌，然后有针对性地发起攻击。

常见的直接泄露方式

• 与版本管理工具中的隐藏文件有关
• 上传代码到 GitHub 上 对 GitHub 发起巡检（比较知名的工具有 https://github.com/0xbug/Hawkeye ），通过定期检索公司代码的关键字（比如常用的包名、域名等）来进行检测。通过这些方式匹配到的结果，很可能就是员工私自公开的代码。

防护手段

• 屏蔽信息：通过技术手段，将不该被访问的资源进行屏蔽，从而避免信息泄露的产生；
• 代码检测：从“白盒”和“黑盒”两个方向，对代码、应用等进行检测，对可能的泄露进行预警；
• 人工审计：对于非技术原因造成的泄露，加强人工审计的工作。同时从公司制度上，去提高员工的安全意识。

插件漏洞

“0 day”，即在插件发布修复漏洞的安全补丁之前，黑客就已经知道漏洞细节的漏洞。换一句话说，“0 day”就是只有黑客知晓的未公开漏洞

建立插件漏洞的防护体系

• 第一步：整理插件，剔除无用插件 首先，你可以通过Maven Dependency Plugin帮助自己自动分析插件依赖树。除了展示出当前 Maven 工程中所有的使用插件，Maven Dependency Plugin 还会对插件的使用情况做进一步的分析，帮你找出在 POM 中却没在代码中使用的插件。这样，你就可以对这一类无用的插件引用及时剔除，自然也就能够减少插件漏洞出现的可能性。
• 第二步：管理插件补丁更新 Version Maven Plugin就是用来检查版本更新的一个工具
• 第三步：使用公开漏洞库
• CVE（Common Vulnerabilities & Exposures，公共漏洞和暴露）CVE -CVE这个公开漏洞库中，你可以根据漏洞的唯一编号，在 CVE 中快速地找到这个漏洞相关的信息，包括：受影响的版本、可能造成的影响、修复的方法及补丁等。除了 CVE 之外，公开的漏洞库还包括CWE（Common Weakness Enumeration，通用缺陷列表）、CVSS（Common Vulnerability Scoring System，通用漏洞评分系统）、NVD（National Vulnerability Database，国家信息安全漏洞库）以及CNVD(China National Vulnerability Database，中国国家信息安全漏洞库） 自动化地完成匹配公开漏洞库的工作。OWASP Dependency-Checkdependency-check – About是一款专门进行插件漏洞检测的工具。它会将工程内的插件和公开的漏洞库进行比对。最终，会生成一个网页形式的报告，使你对工程中的插件漏洞一目了然了。 JavaScript 中的插件，我们可以使用Retire.jsGitHub - RetireJS/retire.js: scanner detecting the use of JavaScript libraries with known vulnerabilities进行整理。 Node项目可通过depcheck检查未使用的依赖项，通过npm audit检查依赖项中的已知漏洞 统计你的应用中引用了哪些插件 管理这些插件中是否有版本更新 检测这些插件是否存在已知的漏洞

执行mvn org.owasp:dependency-check-maven:check会以当前时间下载最新的CVE漏洞库，现在新年刚过，会报“Unable to download meta file: https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-2020.meta; received 404 -- resource not found”错误。解决办法：1. 调整当前日期为2019年12月31日，2. 等待网站的新漏洞文件发布

权限提升和持久化

在应用或系统中，黑客或者被黑客控制的用户，通常会通过漏洞攻击或者利用弱密码，获取到其他用户的权限。在获取了新的用户权限之后，黑客就能够以新用户的身份去窃取和篡改数据，进行非法的操作了。这就是权限提升（Privilege Escalation）。也就是说，黑客可以通过不断获取新的身份，来不断扩大（或者叫提升）自己的权限，不断扩大攻击影响，最终实现控制整个系统。 ![][image-20] “后门”的关键意义就在于，为黑客长时间保持高权限的通道，使得黑客能够进行长时间的潜伏和攻击 不依附于应用，直接隐藏自己，“后门”就发展成了 Rootkit。通常来说，Rootkit 会驻扎于内核中，通过修改内核的逻辑来完成“后门”的功能。因为内核具备较高的权限，所以 Rootkit 就能破坏杀毒软件这样的安全进程，而不被轻易发现。同样地，因为 Rootkit 驻扎在内核中，理论上，除了重装系统以外，没有其他更好的方式来根除“后门”。 以隐藏进程的形式运行“后门”，黑客也可以把“后门”留在正常的 Web 服务中，这就变成了 WebShell。在 PHP 中，最简单的一句 WebShell 如下：

<?php @eval($_POST['shell']);?>)

“后门”通常会以木马、Rootkit 或者 WebShell 等比较隐蔽的形式运行在系统中。而黑客可以通过和“后门”的直接通信，来获得服务器的操控权限

如何将“后门”植入到系统

文件上传漏洞向服务器上传一个程序。在使用应用的时候，用户经常需要上传一些文件，比如：头像的图片、邮件附件和简历等。很多时候，开发人员为了方便，会直接将上传的文件存储到当前目录，也就是 Web 服务的目录中。这个时候，如果黑客上传的是一个 PHP 文件，那么这个 PHP 文件就会被放入到 Web 服务的目录中。因此，黑客只需要上传一个包含 WebShell 的 PHP 文件，就成功了植入了一个“后门”。 通过权限提升或者文件上传漏洞成功植入“后门”之后，黑客还需要保证“后门”的持久化。因此，“后门”需要常驻于系统的后台，并能够随着系统的开关机而启动。为了实现这个目的，黑客通常会在定时任务（crontab）或者开机启动项（inittab、rc.local）的配置中，加上“后门”的执行命令。 除此之外，黑客还可以利用伴随于系统的常驻进程来保证“后门”的持久化。对于 WebShell 来说，只要 Web 服务保持可用，那么 WebShell 也一直可用。对于 Rootkit 来说，它们会直接篡改内核的初始函数来进行自启动，也就更难被发现和去除。总之，持久化要么是通过定时任务、开机启动等方式来实现，要么就是通过伴随于系统的常驻进程来实现。

防护

• 最小权限原则
• IDS（Intrusion Detection System，入侵检测系统） 安全中纵深防御的一种思想：对不同的层级进行不同的防御，即使前面层漏过了，下一层还能够接着进行防护

linux系统和应用安全

Linux系统安全

Linux 中的安全模型

对于 Linux 内核层的安全，我们只需要按照插件漏洞的防护方法，确保使用官方的镜像并保持更新就足够了 ![][image-21]

• Linux 中的认证机制 使用 John the Ripper 检测弱密码

unshadow /etc/passwd /etc/shadow > mypasswd
john mypasswd
john --show mypassw

• Linux 中的授权机制 ![][image-22] Linux 系统面临的安全威胁其实就是权限问题,要解决权限问题，我们就要实践最小权限原则 Linux 系统安全中最普遍的问题：滥用 ROOT Nobody 通常拥有整个操作系统中最小的权限，对于不提供最小权限切换功能的工具，我们就可以使用 nobody 的用户身份，来进行主动切换了 以 nobody 的身份执行redis-server了（前提是，我们需要对日志和 PID 等目录进行适当配置，确保能够以 nobody 身份写入）：

su -s /bin/redis-server nobody

• Linux 中的审计机制 系统日志主要分为 3 类，用户登录日志、特殊事件日志和进程日志 用户登录日志主要是/var/log/wtmp和/var/run/utmp，用来保存用户登录相关的信息。用户登录日志本身为二进制文件，我们无法直接通过文本方式查看，但是可以配合who/users/ac/last/lastlog这样的命令来获取。 特殊事件日志主要包括/var/log/secure和/var/log/message。其中，/var/log/secure主要记录认证和授权相关的记录，如果有人试图爆破 SSH，我们就可以从这个日志中观察出来。/var/log/message由 syslogd 来维护，syslogd 这个守护进程提供了一个记录特殊事件和消息的标准机制，其他应用可以通过这个守护进程来报告特殊的事件。 进程日志：当通过 accton 来进行系统进程管理时，会生成记录用户执行命令的 pacct 文件。 可以通过在这些分析平台配置恰当的规则（如 SSH 登录尝试失败 3 次以上），来及时发现黑客的部分入侵尝试，迅速产生报警。然后，我们就可以针对具体的问题，进行人工复查了。

网络安全

内网中的“最小权限原则”

• 对内网进行水平划分
• 对内网进行垂直划分 内网可以访问外网的资源，外网却不能够直接访问内网的资源。要实现这种隔离，就需要用到路由器了。路由器会将连入的所有内网设备打包在一起。所以，对外网来说，内网变成了一个整体，也就无法访问到某个具体的设备了。 ![][image-23]

有线网络和无线网络安全

DDoS 攻击

DDoS 攻击（Distributed Denial Of Service Attack，分布式拒绝服务攻击） DoS（Denail f Service，拒绝服务）攻击 DoS 攻击主要有两种类型。一种是通过漏洞进行攻击，使得服务或设备因为程序报错而宕机。比如针对 ICMP 协议的“死亡之 PING”，就是因为旧版本的 Windows 系统在处理超长的 ICMP 包时会报错死机。另一种则是通过巨量的垃圾流量挤占网络带宽，使得网络设备无法接收或者发送合法的流量。

Docker安全

Docker 服务安全

Namespace 机制、Capabilities 机制和 CGroups 机制防止“Docker 逃逸”

• Namespace 机制 基于 Namespace 的隔离我一般叫它“伪隔离”，部分的进程目录 /proc/…、内存映像 /dev/mem、系统设备 /dev/sd*、Linux 内核模块上面的这些目录和模块，对于容器和宿主机来说，其实是共享的。从理论上来说，如果你在 Docker 容器中修改了这些目录，那么宿主机当中也会同步相应的修改结果。
• Capabilities 机制 Capabilities 提供了更细粒度的授权机制，它定义了主体能够进行的某一类操作，在默认情况下，Docker 会采用白名单机制（白名单列表你可以在 Docker 源码中查看）进行限制，即只允许 Docker 容器拥有几个默认的能力
• CGroups 机制 通过 CGroups，给每一个容器弹性地分配 CPU 资源。同样地，这个限制既不能过松，过松会导致某一个 Docker 容器耗尽宿主机资源，也不能过严，过严会使得容器内的服务得不到足够的资源支持 ![][image-24]

Docker 守护进程

API 接口证书的方式来进行认证

dockerd --tlsverify --tlscacert=ca.pem --tlscert=server-cert.pem --tlskey=server-key.pem -H=0.0.0.0:2376

curl https://127.0.0.1:2376/images/json --cert cert.pem --key key.pem --cacert ca.pem

Docker 镜像安全

• 使用最精简的镜像
• Docker 中的最小权限原则

FROM ubuntu
RUN groupadd -r node && useradd -r -s /bin/false -g node node
...
USER node
CMD node index.js

工具

镜像进行静态的扫描分析，并和漏洞库进行比对，从而发现镜像中可能存在的安全漏洞https://github.com/quay/clair

数据库安全

Redis 安全

• 加上密码之后，Redis 的整体性能会下降 20% 左右
• 通过“重命名”来间接地实现授权功能。我们可以在 Redis 的配置文件中加入 rename-command CONFIG pUVEYEvdaGH2eAHmNFcDh8Qf9vOej4Ho，就可以将 CONFIG 功能的关键词，变成一个随机的字符串，黑客不知道这个字符串，就无法执行 CONFIG 功能了。而且，你仍然可以通过新的命令，来正常地使用 CONFIG 功能，不会对你的正常操作产生任何影响。
• 避免使用 ROOT 权限去启动 Redis

MySQL 安全

MySQL 的功能十分强大，自身就提供了和本地文件交互的功能。所以，通过 LOAD DATA INFILE，MySQL 可以读取服务器的本地文件；通过 SELECT … INTO DUMPFILE，MySQL 也能够将数据写入到本地文件中。因此，在黑客连入 MySQL 之后，通过读文件的功能，黑客就能够对服务器的任意文件进行读取，比如敏感的 /etc/passwd 或者应用的源代码等；通过写文件的功能，则可以仿照 Redis 修改 Crontab 的原理，实现命令执行的功能。 MySQL 提供了多用户的认证体系，它将用户的相关信息（认证信息、权限信息）都存储在了 mysql.user 这个系统表中。利用这个系统表，MySQL 可以通过增删改查操作，来定义和管理用户的认证信息、权限列表等

GRANT ALL PRIVILEGES ON db.table TO user@"127.0.0.1" IDENTIFIED BY "password"

虽然和 Redis 一样，MySQL 本身也不提供审计功能。但是，MySQL 可以通过第三方插件，来提供审计的服务。比如 McAfee 提供的mysql-audit以及MariaDB Audit Plugin。这些插件能够自动收集必要的 MySQL 操作信息，并推送到你的 ELK 等日志集群中，方便你进行持续的审计操作。 在加密方面，MySQL 既提供传输过程中 SSL（Security Socket Layer）加密，也提供存储过程中硬盘加密。 开启 SSL 功能，需要在配置文件中配置如下命令:

[mysqld]
ssl-ca=ca.pem
ssl-cert=server-cert.pem
ssl-key=server-key.pem

这些配置并不能强制客户端使用 SSL 连接。想要杜绝全部非安全连接的话，我们可以在配置文件中添加 require_secure_transport=ON，来进行强制限制。 MySQL 中提供的硬盘加密功能。硬盘加密过程主要涉及两个密钥，一个主密钥和一个表密钥。表密钥由 MySQL 随机生成，通过主密钥进行加密后，存储在表头信息中。因此，每一个表格都拥有不同的密钥 MySQL 的加密功能是由 keyring_file 这个插件来提供的。需要注意的是，当 keyring_file 第一次启动的时候，它会生成一个主密钥文件在当前的系统中。你一定要备份这个密钥文件，因为它一旦丢失，数据库中的全部数据，都将因为无法解密而丢失

分布式安全

针对 Hadoop 的攻击方式

• Hadoop 没有集成认证和授权功能，任何人都可以通过客户端的形式连入到 Hadoop 集群中。所以，黑客可以任意地增删改查 HDFS 中的数据，也可以任意地提交 Hadoop 任务，来进行自己想要的数据操作
• Hadoop 节点间的数据传输默认都是明文的。因此，即使黑客无法连入到 Hadoop 集群中，它们也可以通过控制交换机等网络设备，同样能够获得很多的数据信息
• 因为 Hadoop 能够很好地支持节点的增加和删除操作。所以，黑客可以以一个节点的身份加入到 Hadoop 集群中。这样一来，数据就会自动流转到黑客的节点中。如果伪装的是具备调度功能的 NameNode，黑客还能够对整个 Hadoop 集群的资源调度进行干预和影响

Hadoop 自带的安全功能

安全防御工具

安全标准和框架

国内的安全标准和框架，就是我们常听到的等级保护制度。保护根据公司的安全性高低，划分了由一到五这五个等级。每个等级都有需要满足和达标的安全要求。等级越高说明公司的安全水平越高，越被政府认可。安全等级三级以上的公司，还会受到国家信息安全监管部门的监督和检查。 在国外，比较知名的安全标准和框架包括：ISO27000 系列、NIST、COBIT 和 ITIL 实际上，NIST 也被称为“美国版等保”。因为 NIST 是美国政府提出的，对公司的安全能力进行监督和管控的安全框架。但是，NIST 并未考虑公司在实施安全标准时需要付出的成本，所以除了美国政务之外，NIST 很少被使用。 而 ISO27000 系列和 COBIT 都是不包含具体实施细节的安全标准和框架。 其中，ISO27000 系列是国际上比较认可的安全标准之一。它提供了兼容性极高的安全体系和信息安全管理的最佳实践指导。但是，ISO27000 系列更关注于方向上的指导，没有覆盖具体的实施细节，所以无法作为技术手册来使用。 COBIT（ Control Objectives for Information and related Technology）则是给安全管理者提供了一个内控的框架，它本身更关注于内控和审计。 ITIL（ Information Technology Infrastructure Library ）。ITIL 是一个提升服务质量的标准框架，而安全只是影响服务质量的一个因子。因此，ITIL 会更多地考虑如何提高公司的研发和管理效率，在机密性、可用性和完整性上只给予了比较基本的关注。 等保对公司的安全要求划分为了十类，分别是：技术要求：安全物理环境、安全通信网络、安全区域边界、安全计算环境、安全管理中心；管理要求：安全管理制度、安全管理机构、安全管理人员、安全建设管理、安全运维管理。 ISO27001 是国内比较流行的安全评估认证之一。它提出了 14 个不同的安全方向，分别是：安全策略、信息安全组织、人力资源安全、资产管理、访问控制、密码学、物理和环境安全、操作安全、通信安全、系统获取开发和维护、供应关系、信息安全事件管理、业务连续性管理中的信息安全考虑、符合性 ISO 的一系列框架和标准其实都遵循 PDCA 流程，PDCA 也是项目管理上经常被提到的管理方法 Plan：计划，确定安全的目标并制定建设的规划 Do：执行，按照计划的内容和时间来执行 Check：检查，对执行的结果进行总结，看是否符合预期 Action：改进，如果执行不符合预期，或者计划出现纰漏，则进行分析和改进 NIST 所提出的 IPDRR 方法，是解决各类安全问题的一种通用思路 第一步是 Identify（识别）。我们需要掌握公司有哪些 Web 应用，并对 Web 应用做威胁评估。 第二步是 Protect（保护）。我们要在安全事件发生之前，对数据和资产采取适当的保护措施。（比如：通过访问控制机制来避免越权访问、通过加密来保护数据的 CIA、通过防火墙保护内网隔离等）。在开发上，我们需要采用安全的方法，尽量避免漏洞出现。同时，我们可以部署 WAF 等安全工具，统一对 Web 攻击进行防护检测。 第三步是 Detect（检测）。在安全事件发生之中或者之后，我们要能及时发现和检测出安全事件或者攻击行为。这就需要对请求的日志和返回的结果进行分析，评估是否产生攻击行为和数据泄露 第四步是 Respond（响应）。当检测到安全事件后，我们需要采取有效的措施，来阻止攻击的持续进行，尽可能地降低事件所带来的影响。我认为最可行的操作，就是对出现漏洞的 Web 业务进行下线，对已经受到影响的数据进行隔离。这也要求我们制定好详细的应急预案，避免攻击发生时公司陷入手忙脚乱的无序状态。 第五步是 Recover（恢复）。当事件响应完成后，我们要将应用或者服务恢复到攻击前的状态，也就是对应用和数据进行修复和重新上线。同时，也要对事件的原因进行复盘分析，然后进一步完善安全机制 针对 Web 安全体系建设，我们可以根据 IPDRR 方法 采取多重安全策略进行保护。这也符合安全防护的一个原则：纵深防御，即任何单点的安全策略都存在纰漏和被绕过的可能。因此，我们需要采取多重相互独立的安全策略，使得这些策略相互补充，降低安全策略被绕过的可能性。

防火墙

防火墙是部署在网络边界上的一种安全设备，其概念比较宽泛，根据需求不同可以工作在 OSI（Open System Interconnection，开放式系统互联） 网络模型的一层或多层上。防火墙可以分为三种类型：包过滤防火墙、应用网关防火墙和状态检测防火墙。

• 包过滤防火墙 包过滤防火墙是通过检测并拦截所有流经防火墙的 TCP 和 UDP 数据包，来对系统提供保护。它能够获取到的信息包括：源 IP 和端口、目标 IP 和端口、协议号等。由于大部分的路由器甚至 Linux 系统本身（Iptables）也具备类似的功能 包过滤防火墙的过滤规则基本都是静态的 包过滤防火墙只能够通过匹配 IP 地址和端口号，判断这些信息是否命中特定的规则来进行过滤。比如，禁止外网 IP 访问 80 和 443 以外的公司 IP 端口。
• 应用网关防火墙 应用网关防火墙以代理的模式工作在应用层。所谓“代理”，即接收客户端发出的请求，然后以客户端的身份将请求再发往服务端。大部分的系统和应用都是工作在应用层的，因此，应用网关防火墙能够获取到系统和应用的全部信息，从而实现更复杂的功能，如：内容监控、认证、协议限制甚至缓存。
• 状态检测防火墙 状态检测防火墙是包过滤防火墙的一种升级，它同样工作在网络层和传输层之上。状态检测和包过滤防火墙最大的不同在于，它会以连接的形式来“看待”低层级的 TCP 和 UDP 数据包。 当客户端发起一次完整的 HTTP 请求时，会需要进行“TCP 三次握手”建立连接（SYN+ACK 数据包），HTTP 请求和响应的数据往往也是通过多个数据包才能完整发送。传统的包过滤防火墙只能基于每一个数据包进行判断，比如在“握手”的过程中，包过滤防火墙会分别看到 SYN、SYN+ACK、ACK 这三个数据包，并对每一个数据包进行判断。而事实上，这三个数据包（SYN、SYN+ACK、ACK）代表的是一次握手请求。所以，状态检测防火墙会尝试将这一连串的数据包组成一次完整的连接请求，从而获得一个更全面的视角，大大提高其安全性

防火墙的保护

• 保护操作系统的漏洞
• 阻止非法的信息流动
• 限制可访问的服务和审计

防火墙防御盲区

• 防火墙不能防御已授权服务中的恶意攻击
• 防火墙不能防御不通过防火墙的访问
• 防火墙自身的操作系统存在缺陷

WAF

WAF 的分析和策略都工作于应用层

IDS

IDS（Intrusion Detection System，入侵检测系统） 根据检测内容的不同，IDS 可以分成两种类型：NIDS（Network Intrusion Detection System，网络入侵检测系统）和 HIDS（Host-based Intrusion Detection System，基于主机型入侵检测系统）

• NIDS NIDS 主要检测网络流量中的攻击行为。区别于部署在网络边界的防火墙，NIDS 一般部署在内网的网络节点（路由器或交换机）中，所有的网络请求都会流经这些网络节点，所以，NIDS 基本可以获取到对应网络节点下全部的网络行为。 和防火墙不同的是，NIDS 一般不具备拦截网络请求的能力 开源工具，比如：SnortSnort - Network Intrusion Detection & Prevention System、SuricataHome - Suricata等 NIDS 的检测逻辑就是对请求的内容进行正则匹配，不具备分析上下文的能力。因此，NIDS 一般只能够对单次的攻击请求进行检测
• HIDS HIDS 主要检测服务器系统中的攻击行为。NIDS 运行在某个网络节点之上，相当于集中式地对网络流量进行检测，但是 HIDS 运行于每一个服务器中，也就相当于对系统行为进行分布式检测。 HIDS 一般以 ROOT 权限运行在操作系统中，HIDS 能够监控的行为，执行的系统命令、发起和接受的网络请求、运行的进程、监听的端口号等、系统关键文件的完整性、其他黑客可能留下痕迹的地方 很多公司都会基于Osquery 来开发 HIDS
• IPS 在 NIDS 和 HIDS 中加入了拦截的能力，就成了 NIPS 和 HIPS，统称为 IPS（Intrusion Prevention System，入侵防御系统） IDS 强调的是检测，IPS 强调的是拦截 ![][image-25]

蜜罐

“蜜罐”，就是一台部署在内网的服务器。这个服务器没有任何保护措施，并且提供带有漏洞的服务，就是为了吸引黑客来攻击它。蜜罐由安全人员部署在网络的各个节点中，理论上，其他开发人员都不会知道蜜罐的存在，也就不会向蜜罐发起任何请求。而黑客入侵内网后，需要对内网进行探测，如果发现蜜罐中的服务有漏洞，自然就会针对蜜罐发起攻击。因此，蜜罐内的一切行为，都是黑客产生的。基于蜜罐的报警和日志，我们就能够及时发现黑客的存在，并且还原出黑客的攻击行为。 蜜罐的类型主要分为两种：低交互蜜罐和高交互蜜罐 低交互蜜罐，就是蜜罐内的所有服务都是模拟的，不能提供真实的服务功能。比如，低交互蜜罐为了模拟一个弱密码的 SSH 服务，它会监听 22 端口。而黑客一旦向这个 22 端口发起 SSH 登录请求，蜜罐就会返回登录成功的响应。但是，蜜罐并没有提供真实的 SSH 服务，只是模拟了一个登录成功的响应而已，所以黑客并不能通过 SSH 连接上服务器。 高交互蜜罐会提供一个真实的服务，而且不施加任何限制，只是用来做详细的记录而已。还是以上面 SSH 登录为例，在高交互蜜罐中，蜜罐会开启一个真实的 SSH 服务，黑客能够通过 SSH 连入并且控制蜜罐。但是，黑客连入蜜罐后的所有行为都会被记录下来，并产生报警。而我们只需要及时处理报警赶走黑客，就可以降低蜜罐被控制后所产生的影响。 优势：蜜罐几乎不会产生误报，蜜罐内的所有行为都是真实的黑客攻击行为，因此数据量小、价值高，不需要已知的攻击样本，根据黑客的行为我们甚至能够发现新的攻击方式 开源蜜罐：开源蜜罐测评报告 - FreeBuf网络安全行业门户

构建入侵检测体系

首先，蜜罐具备较高的准确率，并且能够发现未知的攻击。因此，我们可以将蜜罐中黑客的行为特征作为攻击样本的特征，输入到 IDS 和 IPS 中去。这样一来，IDS 和 IPS 就具备了根据黑客行为自动学习和升级的能力。 其次，IPS 通常是直接拦截黑客的攻击行为，来及时止损。但这样一来，黑客也会察觉到入侵检测系统的存在。因此，我们可以将 IPS 的检测拦截行为，调整为一旦检测到攻击行为，就将行为转发到蜜罐中。对于黑客来说，攻击行为看起来仍然是成功的，但实际上不会对系统产生任何影响，且攻击行为都被记录下来了。 最后，为了提升黑客发现蜜罐的概率，我们通常需要在内网中广泛地部署蜜罐。但是，这又增加了很多额外的硬件部署成本。因此，有的 HIDS 中会嵌入“微蜜罐”，就是利用服务器本身的资源实现一个小型的蜜罐服务。比如，某个部署 HIDS 的服务器中本来没有 MySQL 服务，也没有监听 3306 端口，我们可以通过设置服务器，让 HIDS 监听 3306 端口并模拟一个 MySQL 服务出来。这个 MySQL 服务是 HIDS 模拟的，开发人员不会感知到，所以发起 MySQL 连接的一定是黑客。这就是“微蜜罐”。 一个系统化的入侵检测系统需要依靠各个安全产品之间的相互协作，才能够实现防护能力的最大化。 入侵检测系统的组织结构图 ![][image-26] NIDS 负责对网络节点进行检测，网络中会包含部署了 HIDS 的系统和蜜罐系统。最终，我们需要通过 ELK 来统一收集各个安全产品的检测日志，实现信息同步。所有 IDS 或者 IPS 的信息都是相互关联的，我们就能够基于这个完整的信息进行全盘的综合分析了。

RASP

2012 年，Gartner 提出了 RASP（Runtime Application Self Protection）的概念，就是希望将安全产品部署在应用的底层，完全站在应用的视角去发现攻击行为，从而实现更加完善的安全防护。 RASP 的设计思路是通过监控应用的底层，来从根本上发现攻击行为的产生 RASP 产品开源应用运行时自我保护解决方案 - OpenRASP - 百度安全 RASP 对比于 WAF 最大的优势在于 RASP 运行在应用的底层，从而能够知道应用运行时的上下文（比如：用户、代码逻辑、SQL 语句等）。在 Web 安全中，我们针对 Web 安全的攻击原理进行过总结：SQL 注入、反序列化等漏洞其实都是通过输入数据，篡改应用的正常逻辑实现的攻击。 对于 WAF 来说，它只能够判断出输入的数据“可能”会篡改应用的正常逻辑，因此 WAF 的拦截决策都来源于这个可能性。而对于 RASP 来说，它知道应用的正常逻辑是什么，也知道应用接收输入后实际的逻辑是什么，如果实际逻辑和正常逻辑不一致，就必然发生了攻击。基于这种检测方式，RASP 基本不会产生误报或者漏报。 对于 RASP 来说，它实际上不关注具体的攻击点和攻击方式是什么，因为 SQL 注入攻击，最终都会使 SQL 语句 Token 化后的长度发生改变。因此，RASP 只需要判断执行的 SQL 语句 Token 化后的长度即可。所以我才说，RASP 能够有效地防御未知的攻击。 RASP 还有一个比较特别的好处，就是基本不用维护规则。 劣势在于推广难度上。尽管我们一直在提安全，但是事实上，大部分的开发人员并不认可安全，他们也不接受任何可能对应用产生影响的安全产品。这是因为，这些安全产品增加了检测的逻辑，就必然会影响应用的正常运行。而且，WAF 等拦截性安全产品产生的误报，会让正常的业务请求受到影响。

SIEM

使用 SIEM（Security Information and Event Management，安全信息和事件管理），来帮助我们运营一个安全体系。通过 SIEM，我们可以将散落于各个系统、设备和安全产品中的日志进行汇总和梳理，快速串联出黑客的完整攻击路径，更高效地完成安全体系运营的工作。 SIEM 就是一个基于各类日志，提供安全运营和管理能力的统一平台。

SIEM 功能

• 收集日志。对 SIEM 来说，需要收集的日志来源于操作系统、路由器、数据库等业务设备，防火墙、WAF、IDS 等安全产品，以及业务前后端本身
• 对数据进行分析统计，将海量的日志进行筛选和总结，给予安全运营人员最精简的结果，提高分析效率。经过数据分析之后，安全运营人员就能够快速发现并处理各类安全事件了。
• 提供完整的运营流程。比如，通过工单功能完成安全事件的管理，通过报表追踪各安全产品产生的报警、发起的安全事件、数据的流动情况等，清晰地表现出公司的安全现状和能力。

SIEM 落地

![][image-27] 需求列表

• SIEM 需要管理哪些设备，收集哪些数据
• 安全运营目前遇到的痛点的典型场景是什么，预期的解决方案又是怎么样的
• 完整的安全运营流程是什么 安全的发展，前期在于技术建设，长期在于运营升级

SDL

2004 年，微软提出了 SDL（Security Development Lifecycle，安全开发生命周期） 因为对安全和隐私的考虑贯穿了整个软件的开发进程，SDL 能够帮助开发人员写出更“安全”的代码，在解决安全合规需求的同时，也能减少由安全问题带来的损失。 和安全标准一样，SDL 本质上是一个宏观指导性质的框架。但是，它确实成为了很多公司建设安全开发体系的参照标准。各个公司依据微软的 SDL 标准，结合自身的实际情况，衍生出了适合公司自身发展的 SDL。 软件开发生命周期 DLC（Software Development Life Cycle）（这个概念的英文缩写种类比较多，为了和 SDL 区分，我们用 DLC 代表软件开发生命周期）。SDL 是以软件开发生命周期为基础发展成的安全框架，所以，了解 DLC 能够帮助我们更好地认识 SDL DLC 将软件开发过程分为 5 个阶段：需求分析、设计、开发、测试和部署。DLC 对5 个阶段的具体描述，都是以业务功能为核心进行展开的，并没有涵盖安全的工作。这显然不安全。 SDL 的出现不是为了颠覆传统的 DLC 框架，而是希望在 DLC 中加入足够清晰的安全需求，以此来为软件开发的过程提供完整的安全防护。SDL 的标准执行流程有 7 个步骤：安全培训、需求分析、设计、开发、测试、部署和响应。流程如下图： ![][image-28]

推动 SDL 落地

• 我们要基于现有的制度拓展 SDL
• 在 SDL 的覆盖面上，我们也可以有所取舍 Dependecy-check工具检查cve漏洞，最好是将这个工具集成到devops pipeline中，这样可以做到自动化的定期检查预警

业务安全

黑产是基于正常的业务产品逻辑，采取非正常或者批量的操作，来获取利益的行为。业务安全就是通过各类产品策略，来对黑产进行识别和拦截，从而保障业务的正常运行。 在基础安全的攻击视角中，黑客会逆向前端代码，找到最终决定金额的逻辑，然后自己伪造一个大额的红包请求。这样一来，黑客就可以不用玩游戏，同时还能获得一个大额的红包。在业务安全的攻击视角中，黑产会开发一个自动玩游戏领红包的工具，操纵大量的账号来参与活动。最终，将各个账号的小额红包汇总到一个账号下，从而实现获利。 业务安全的本质就是资源对抗，业务安全的防护手段就是提高黑产的资源成本，并且针对不同的资源类型，我们需要采取不同的方法来进行对抗。 ![][image-29] 产品方案属于事前的防控，是从根本上提高黑产操作的成本；风控系统属于事中的防控，是在检测到黑产行为时才进行拦截。

系统和应用的安全基线

CIS 的标准安全基线，通用的基线检查工具https://www.cisecurity.org/cis-benchmarks/ Docker 安全基线https://github.com/docker/docker-bench-security

规划安全防御体系

1. 在安全制度中，如果要求对网络和设备进行隔离，那我们就使用防火墙；如果要求有集中的安全管控，那我们就使用 SIEM；如果对数据安全作要求，那我们就使用 DLP 等。
2. 发现安全问题最直接的方法就是安全测试
3. 发现安全问题的直接方法是安全演练
4. 满足合规需求是很多公司领导唯一关心的指标 网络安全法要求网络和系统日志留存大于 6 个月 数据安全审查时要求对密码、隐私信息等关键数据进行分类、加密存储 为了通过等级保护的评测，引入各类安全防御工具 在不同的安全场景下，想要做好安全防御体系，离不开合理地落地安全制度、使用安全防御工具和手段。
5. 在最理想的情况下，我们应当以安全制度为基础规范人的行为，避免安全问题的出现。
6. 在公司对安全需求不明确的时候，我们需要找出显著的安全问题，表现出安全工作能够产出的收益。
7. 当有真实的攻击发生时，我们要先快速阻断攻击，再逐步深入、彻底解决安全问题。 IPv6 对安全的影响 IPv6 和 IPv4 相比最大区别就是 IP 地址变得非常庞大了 网络扫描不再可能 目前，性能最优的扫描工具是MasscanGitHub - robertdavidgraham/masscan: TCP port scanner, spews SYN packets asynchronously, scanning entire Internet in under 5 minutes.，它能够在 5 分钟内扫遍全部 IPv4 的地址空间。