1 ） 一切以精准的监控为前提 （简介Prometheus）
谈安全防护和***之前， 一切的前提 先以精准的监控为准 , 采集精度 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，也没看到出问题啊？
这个问题提的很好，请看上面的 第二张图
实际操作：
[[email protected] ~]# 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代码越多 消耗理论上也越多
那么今天的网络安全分享 就到这里啦 ^_^
更多的 还请关注大米的博客后续哦 谢谢
原文地址：http://blog.51cto.com/13529208/2331907