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程式碼越多 消耗理論上也越多

那麼今天的網路安全分享　就到這裡啦　^_^
更多的　還請關注大米的部落格後續哦　謝謝