浅谈网络安全的经验

1 ） 一切以精准的监控为前提 （简介Prometheus）

我们提供的服务有：成都网站建设、网站建设、微信公众号开发、网站优化、网站认证、潼关ssl等。为上1000家企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务，是有科学管理、有技术的潼关网站制作公司

谈安全防护和***之前， 一切的前提 先以精准的监控为准 , 采集精度 1s

无论是 企业对***的监控和预警， 还是未雨绸缪的 压力测试模拟 都必须有一个详细的参照物

在这里 给大家推荐一款强力的开源监控工具， Prometheus 普罗米修斯

它是一款开源的，基于数学命令行 和 时间序列数据库的 精密监控工具

其采集精度 理论值可以达到每秒一次采集，结合浮点数的表达形式，非常适用于瞬时突发状况的分析/监控/ 以及报警

接下来 咱们来简单展示展示一下 prometheus的实际操作 （目前搭建在 生产教学的平台上）

实际操作：
无压力后 +压力测试 曲线的快速波动

prometheus如此的强大，但是国内并不普及 原因主要有三个

第一个 要求有一定的数学基础 数学命令行的使用难度较大

第二个 要求对Linux 系统底层工作原理 有一定的认知 不然无法准确添加监控

第三个 英文的问题（国内中文资料很少，中文完整教程就更几乎没有）绝大部分细节资料 都要取自官方站点

CPU时间片分布的理解， 时间片占用的累积

COUNTER类型数据的理解

微分+二分法 得出单位时间速率 ， 以比例的形式获取CPU使用率 （理解prometheus提供的数学函数）

2） 谈一谈 从运维的角度 看服务器资源

***的本质是什么？ 其实说到底 就是 对服务器现有资源的强力打击 或者说是消耗

那么从我们运维架构的角度出发， 企业中的服务器资源的又有哪些分类呢？

第一类：服务器物理层面的 资源

这个是最好理解的，无非就是 CPU / 内存 / 硬盘 /，这些都是作为计算机物理层面上的 有限资源

第二类：OS操作系统层面的 资源

我们就以运维的核心OS Linux为基准

那么操作系统的资源 简单举几个例子 ， 端口数量，连接数 , TCP列队数， 文件句柄数 ， 进程调度/优先级 ， 等等

第三类： 网络资源

这里主要指的是网络带宽，这是非常珍贵的资源，后面也会具体的讲解

上面提到的三种类型的资源 都是作为一个集群架构的有限资源 ***的本质其实就是对资源的消耗

资源的消耗殆尽 最终会致使服务器无法再响应用户的请求，这也就是 咱们常说的 Dos 拒绝服务***

另外，如上提到的三大类的资源 彼此并不是独立的 之间实际上都有着 大量的连带关系

现如今都是互联应用时代，一切都走网络，所以 网络资源的消耗 自然是不言而喻的

就算我们暂时忽略掉 IP包在路由途中的过程， 就算是直接到达了 我们的服务集群

在我们的集群中 也会发生一些列的 连带其他资源的消耗

如下图（01）所示， 比如 一个HTTP的请求到达之后，按照标准七层协议的框架 由下至上 从物理层一直到应用层 都会串联起来

网卡会进行IP包重组，TCP/UDP会进行传输层的连接建立，连接的建立必定又会继续向上 消耗系统的 CPU/RAM/IO , 端口，连接数，列队数 ， 文件句柄数 ，等等

任何一种资源 如果出现瓶颈 都会牵制其他的资源

3）谈一谈 随着年代时间的变迁 ***方和防守方的变化

从方来说， 逐渐由高难度的 4层， 逐渐转变为 傻瓜式的 7层
例如：后面要讲到的 基于4层的 系统漏洞（主要指的是TCP/IP 三层和四层协议）
这种 要求者 不但要精通TCP/IP协议，还要掌握系统底层知识，以及代码的功底

从流量要求很小的Dos， 逐渐变成并发量大的Ddos（Distributed dental of service）
原本 在操作系统（主要指的是Linux）内核较低时，服务器性能较低时 ， 少量的即可造成系统瘫痪
随着OS和服务器的提升， 流量 有着越来越高的要求

从早期的 物理层 系统层，造成第一类 第二类资源的消耗，逐渐过度到 网络带宽的消耗

另外就是费用问题，攻方和守方的费用 其实都是一直在增长的

4） 谈一谈老式的四层*** 以及简单的模拟实验 （以著名的 Death Ping 和 SYN Flood）

• OSI七层模型 简单介绍 图（02）
  

经典的OSI七层模型 ， 我在教学中 又把它称为 U型结构的七层模型

因为数据流的走势 是从右到左， 从上到下， 从下到上 ， 从打包 到 拆包的过程

我们后面要介绍的几种，主要是集中在 第三层，第四层 （统一称为四层）， 第七层（5 6 7可以合并为一层 统一为应用层***）

Distributed Dos

• PING***基本原理

一个ping命令也能发起？ 感觉有点不可思议， 其实在早期 这个并不稀奇 （早期的中美大战 主要就是采用这样的方法）

我们平时使用ping 不过就是为了检查网络通不通而已， 其实PING到了底层之后，有很多的细节 只不过没有看到而已

根据IP协议的规定，IP包在送出时会被分包，中间经过的路由器也会分包，但是包的重组需要由接收端完成

IP协议包头中 有对IP包大小的限制（65535 TL字段， 包头+数据实体） ，包的重组 又需要借助Linux的内核才能完成

早期的内核 是假设IP包的大小 不会超过最大限制， 当***者 发送一个超过TL最大限制的IP包后，在分片重组的时候，系统给包重组所分配的内存区域是固定的

且只有在所有包重组之后，才能识别其整个的大小，所以说中途在重组过程中 每一个包看上去 都很正常（分片包各自有包头，只标记这个分片的大小）

一旦超过最大分配，系统只能将多出来的分片 临时写入到 内存当中的其他正常区域， 这个就是所谓的 内存溢出方式的***， 这种溢出 并不是借用 而是一种病态的占用

会把正常区域内的数据 磨掉， 如果是关键的数据，就有很大可能性 会造成系统的崩溃

但是随着 Linux内核的不断更新，这种致命的漏洞已经被填补起来了， 现如今如果你想简单通过PING命令 或者基于IP/ICMP协议的程序 发起这样的*** 很难突破内核的保护

另外：有的朋友 曾经问过我 这样的一个问题， 你说 IP包超过最大限制 就会出问题，那么平时我们传一个文件 动不动就是几百兆上G，也没看到出问题啊？
这个问题提的很好，请看上面的 第二张图

实际操作：

[root@server01 ~]# ping server02 -A -s 65550

• SYN半连接***

TCP的三次握手 ， 这个我们都很熟悉， 所谓的SYN半连接***

就是当接收方 单方向确认了ACK后（接收方准备好数据传输了），发起方不再发送最后一次的确认 致使接收方无法继续推进握手的流程

接收方在收不到最后一次确认的情况下，会进行重试，进行等待 ，另外如果***方加上了IP欺骗，那接收方连接会阻塞

其实 不管是 接收方的 重试/等待/阻塞 这些其实都不是真正造成 Dos拒绝服务的本质

真正造成拒绝服务的，是接收方所能发起的 SYN连接数量的列队限制

在尚未进行内核调优的Linux系统中，默认能开启的SYN连接数 最大是256个

一旦超过了这个限制，就很难再开启SYN，而正常的用户HTTP请求（或者其他的四层请求）又必须建立在以SYN开头的连接之中

那么这个时候，***者的目的就达到了，正常用户的大量请求 接收端都不能再分配SYN 最终造成 拒绝服务

实际操作： （SYN被轻易打满了以后 也并不会出现 拒绝服务的状况）

5） 谈一谈现如今的七层*** Ddos

我们之前说过了， 高难度的抓系统漏洞的四层， 效果越来越不明显了，因为对者本身有着很高的要求

于是乎，一种傻瓜式的DDos方式应运而生， 这就是基于七层（应用层）的Ddos， 也就是现在 沸沸扬扬的CC***

CC 其实也是DDos的一个分支，其原理并不复杂，通过大量发送模拟正常用户的请求（一般HTTP请求 居多） ***接收端的资源
带宽资源严重被消耗，网站瘫痪，CPU、内存利用率飙升，主机瘫痪 瞬间快速打击，无法快速响应

除此之外，我们也知道，对于的发起方，也有很高的资源要求，包括主机配置，网络带宽，系统优化 等等
这些都是要钱的，所以 方如果自己建立集群发起*** 是赔本赚吆喝

所以，现如今的CC Ddos，更多的是寻找各种宿主机，侵入之后，以它们作为自己的跳板 对目标发动***
这也就是 俗称的 肉鸡

6） 从运维架构师的角度 提出 埋点式七层握手 尽力免费防御DDOS***

• 先从线上架构说起

如上图所示 这就是比较经典的 线上五层架构， 虽说不是所有互联网企业 都是按照100%的方式搭建

但是 基本的线上框架 现阶段始终逃不出这种布局

不管是正常请求，还是***请求， 都是从左至右进入

图中越向右 各种资源的开销越大，连带性也越多，反之则否

所以 我们需要尽可能的 不让***流量 向右打过来，控制在第一层 第二层的范围

这就是左推式 优化方案（一样适用于 安全防护）

• 反向代理的重要性

很多朋友 都知道反向代理的概念， 但是并不是十分清楚其实质作用

我们就基于LNMP的环境进行讲解， HTTP的请求道来后，需要先经过 nginx 处理HTTP协议 以及静态内容

如果请求中有动态内容，则反向代理到 PHP（代码层）进行处理

关键也就在于此处

Nginx可以做七层负载均衡，其实负载均衡的基本功能 也是归属在反向代理之中

反向代理的资源消耗 要远远小于 PHP代码层的资源消耗 （Nginx高并发处理，资源开销很小）

所以，我们希望的就是 当***请求到来时，最多控制在反向代理为止，不让其连带到 PHP代码层

尽可能切断这种 关联

但是 这种切断 需要判断请求的真伪 这是一个疑难问题

• 如何甄别CC Ddos*** 值得我们去考虑

首先，之前也说过 CC Ddos*** 是模拟真实用户请求

想通过很简单的方法，例如 用防火墙加个 IP黑名单的做法 是行不通的

IP数量庞大，且动态改变 或者IP伪装

既然CC***处在七层，那么我们应对的方案 也需要在七层中 去想办法

我这里分享的一种 甄别的方法 ，叫做 埋点七层摸手

什么意思呢？

请参考如下这张图

我们在七层的基础上(也就是HTTP) 订制特定的URL参数来达到防御***的目的

URL的参数在客户端产生，而用户其实是不知情的

客户端的开发人员 和 服务端的运维开发人员 是先商量好几个参数 并且通过几个参数之间的运算得到一个md5值

这个md5值 会在URL中附带上，并在服务端检验

另外，参数需要实时变化，不可以一直使用一个死的固定的值（不然 一旦被***截取到一次 就无效了啦）

除此之外，还可以在URL参数中 额外再增加一项"暗扣"的参数， 这个参数不会直接出现在URL中，但是会加入到最终md5值得计算里
这个"暗扣" 客户端开发人员 和运维开发可以事先商量好 放在自己的代码里

一些优化 ， 轮询取值 适应大量API参数位置 也防止***者猜出参数
缺点： LUA代码越多 消耗理论上也越多

那么今天的网络安全分享　就到这里啦　^_^
更多的　还请关注大米的博客后续哦　谢谢