談安全防護和***之前， 一切的前提 先以精準的監控為準 , 采集精度 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代碼越多 消耗理論上也越多

那麽今天的網絡安全分享　就到這裏啦　^_^
更多的　還請關註大米的博客後續哦　謝謝

淺談網絡安全的經驗