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,也没看到出问题啊?
这个问题提的很好,请看上面的 第二张图

实际操作:

[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代码越多 消耗理论上也越多

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