1 ） 一切以精準的監(jiān)控為前提 （簡介Prometheus）

我們提供的服務(wù)有：成都網(wǎng)站建設(shè)、網(wǎng)站建設(shè)、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認證、潼關(guān)ssl等。為上1000家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的潼關(guān)網(wǎng)站制作公司

談安全防護和***之前， 一切的前提 先以精準的監(jiān)控為準 , 采集精度 1s

無論是 企業(yè)對***的監(jiān)控和預(yù)警， 還是未雨綢繆的 壓力測試模擬 都必須有一個詳細的參照物

在這里 給大家推薦一款強力的開源監(jiān)控工具， Prometheus 普羅米修斯

它是一款開源的，基于數(shù)學(xué)命令行 和 時間序列數(shù)據(jù)庫的 精密監(jiān)控工具

其采集精度 理論值可以達到每秒一次采集，結(jié)合浮點數(shù)的表達形式，非常適用于瞬時突發(fā)狀況的分析/監(jiān)控/ 以及報警

接下來 咱們來簡單展示展示一下 prometheus的實際操作 （目前搭建在 生產(chǎn)教學(xué)的平臺上）

實際操作：
無壓力后 +壓力測試 曲線的快速波動

prometheus如此的強大，但是國內(nèi)并不普及 原因主要有三個

第一個 要求有一定的數(shù)學(xué)基礎(chǔ) 數(shù)學(xué)命令行的使用難度較大

第二個 要求對Linux 系統(tǒng)底層工作原理 有一定的認知 不然無法準確添加監(jiān)控

第三個 英文的問題（國內(nèi)中文資料很少，中文完整教程就更幾乎沒有）絕大部分細節(jié)資料 都要取自官方站點

CPU時間片分布的理解， 時間片占用的累積

COUNTER類型數(shù)據(jù)的理解

微分+二分法 得出單位時間速率 ， 以比例的形式獲取CPU使用率 （理解prometheus提供的數(shù)學(xué)函數(shù)）

---

2） 談一談 從運維的角度 看服務(wù)器資源

***的本質(zhì)是什么？ 其實說到底 就是 對服務(wù)器現(xiàn)有資源的強力打擊 或者說是消耗

那么從我們運維架構(gòu)的角度出發(fā)， 企業(yè)中的服務(wù)器資源的又有哪些分類呢？

第一類：服務(wù)器物理層面的 資源

這個是最好理解的，無非就是 CPU / 內(nèi)存 / 硬盤 /，這些都是作為計算機物理層面上的 有限資源

第二類：OS操作系統(tǒng)層面的 資源

我們就以運維的核心OS Linux為基準

那么操作系統(tǒng)的資源 簡單舉幾個例子 ， 端口數(shù)量，連接數(shù) , TCP列隊數(shù)， 文件句柄數(shù) ， 進程調(diào)度/優(yōu)先級 ， 等等

第三類： 網(wǎng)絡(luò)資源

這里主要指的是網(wǎng)絡(luò)帶寬，這是非常珍貴的資源，后面也會具體的講解

上面提到的三種類型的資源 都是作為一個集群架構(gòu)的有限資源 ***的本質(zhì)其實就是對資源的消耗

資源的消耗殆盡 最終會致使服務(wù)器無法再響應(yīng)用戶的請求，這也就是 咱們常說的 Dos 拒絕服務(wù)***

另外，如上提到的三大類的資源 彼此并不是獨立的 之間實際上都有著 大量的連帶關(guān)系

現(xiàn)如今都是互聯(lián)應(yīng)用時代，一切都走網(wǎng)絡(luò)，所以 網(wǎng)絡(luò)資源的消耗 自然是不言而喻的

就算我們暫時忽略掉 IP包在路由途中的過程， 就算是直接到達了 我們的服務(wù)集群

在我們的集群中 也會發(fā)生一些列的 連帶其他資源的消耗

如下圖（01）所示， 比如 一個HTTP的請求到達之后，按照標準七層協(xié)議的框架 由下至上 從物理層一直到應(yīng)用層 都會串聯(lián)起來

網(wǎng)卡會進行IP包重組，TCP/UDP會進行傳輸層的連接建立，連接的建立必定又會繼續(xù)向上 消耗系統(tǒng)的 CPU/RAM/IO , 端口，連接數(shù)，列隊數(shù) ， 文件句柄數(shù) ，等等

任何一種資源 如果出現(xiàn)瓶頸 都會牽制其他的資源

3）談一談 隨著年代時間的變遷 ***方和防守方的變化

從方來說， 逐漸由高難度的 4層， 逐漸轉(zhuǎn)變?yōu)?傻瓜式的 7層
例如：后面要講到的 基于4層的 系統(tǒng)漏洞（主要指的是TCP/IP 三層和四層協(xié)議）
這種 要求者 不但要精通TCP/IP協(xié)議，還要掌握系統(tǒng)底層知識，以及代碼的功底

從流量要求很小的Dos， 逐漸變成并發(fā)量大的Ddos（Distributed dental of service）
原本 在操作系統(tǒng)（主要指的是Linux）內(nèi)核較低時，服務(wù)器性能較低時 ， 少量的即可造成系統(tǒng)癱瘓
隨著OS和服務(wù)器的提升， 流量 有著越來越高的要求

從早期的 物理層 系統(tǒng)層，造成第一類 第二類資源的消耗，逐漸過度到 網(wǎng)絡(luò)帶寬的消耗

另外就是費用問題，攻方和守方的費用 其實都是一直在增長的

---

4） 談一談老式的四層*** 以及簡單的模擬實驗 （以著名的 Death Ping 和 SYN Flood）

• OSI七層模型 簡單介紹 圖（02）
  

經(jīng)典的OSI七層模型 ， 我在教學(xué)中 又把它稱為 U型結(jié)構(gòu)的七層模型

因為數(shù)據(jù)流的走勢 是從右到左， 從上到下， 從下到上 ， 從打包 到 拆包的過程

我們后面要介紹的幾種，主要是集中在 第三層，第四層 （統(tǒng)一稱為四層）， 第七層（5 6 7可以合并為一層 統(tǒng)一為應(yīng)用層***）

Distributed Dos

• PING***基本原理

一個ping命令也能發(fā)起？ 感覺有點不可思議， 其實在早期 這個并不稀奇 （早期的中美大戰(zhàn) 主要就是采用這樣的方法）

我們平時使用ping 不過就是為了檢查網(wǎng)絡(luò)通不通而已， 其實PING到了底層之后，有很多的細節(jié) 只不過沒有看到而已

根據(jù)IP協(xié)議的規(guī)定，IP包在送出時會被分包，中間經(jīng)過的路由器也會分包，但是包的重組需要由接收端完成

IP協(xié)議包頭中 有對IP包大小的限制（65535 TL字段， 包頭+數(shù)據(jù)實體） ，包的重組 又需要借助Linux的內(nèi)核才能完成

早期的內(nèi)核 是假設(shè)IP包的大小 不會超過最大限制， 當(dāng)***者 發(fā)送一個超過TL最大限制的IP包后，在分片重組的時候，系統(tǒng)給包重組所分配的內(nèi)存區(qū)域是固定的

且只有在所有包重組之后，才能識別其整個的大小，所以說中途在重組過程中 每一個包看上去 都很正常（分片包各自有包頭，只標記這個分片的大?。?/p>

一旦超過最大分配，系統(tǒng)只能將多出來的分片 臨時寫入到 內(nèi)存當(dāng)中的其他正常區(qū)域， 這個就是所謂的 內(nèi)存溢出方式的***， 這種溢出 并不是借用 而是一種病態(tài)的占用

會把正常區(qū)域內(nèi)的數(shù)據(jù) 磨掉， 如果是關(guān)鍵的數(shù)據(jù)，就有很大可能性 會造成系統(tǒng)的崩潰

但是隨著 Linux內(nèi)核的不斷更新，這種致命的漏洞已經(jīng)被填補起來了， 現(xiàn)如今如果你想簡單通過PING命令 或者基于IP/ICMP協(xié)議的程序 發(fā)起這樣的*** 很難突破內(nèi)核的保護

另外：有的朋友 曾經(jīng)問過我 這樣的一個問題， 你說 IP包超過最大限制 就會出問題，那么平時我們傳一個文件 動不動就是幾百兆上G，也沒看到出問題啊？
這個問題提的很好，請看上面的 第二張圖

實際操作：

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

• SYN半連接***

TCP的三次握手 ， 這個我們都很熟悉， 所謂的SYN半連接***

就是當(dāng)接收方 單方向確認了ACK后（接收方準備好數(shù)據(jù)傳輸了），發(fā)起方不再發(fā)送最后一次的確認 致使接收方無法繼續(xù)推進握手的流程

接收方在收不到最后一次確認的情況下，會進行重試，進行等待 ，另外如果***方加上了IP欺騙，那接收方連接會阻塞

其實 不管是 接收方的 重試/等待/阻塞 這些其實都不是真正造成 Dos拒絕服務(wù)的本質(zhì)

真正造成拒絕服務(wù)的，是接收方所能發(fā)起的 SYN連接數(shù)量的列隊限制

在尚未進行內(nèi)核調(diào)優(yōu)的Linux系統(tǒng)中，默認能開啟的SYN連接數(shù) 最大是256個

一旦超過了這個限制，就很難再開啟SYN，而正常的用戶HTTP請求（或者其他的四層請求）又必須建立在以SYN開頭的連接之中

那么這個時候，***者的目的就達到了，正常用戶的大量請求 接收端都不能再分配SYN 最終造成 拒絕服務(wù)

實際操作： （SYN被輕易打滿了以后 也并不會出現(xiàn) 拒絕服務(wù)的狀況）

5） 談一談現(xiàn)如今的七層*** Ddos

我們之前說過了， 高難度的抓系統(tǒng)漏洞的四層， 效果越來越不明顯了，因為對者本身有著很高的要求

于是乎，一種傻瓜式的DDos方式應(yīng)運而生， 這就是基于七層（應(yīng)用層）的Ddos， 也就是現(xiàn)在 沸沸揚揚的CC***

CC 其實也是DDos的一個分支，其原理并不復(fù)雜，通過大量發(fā)送模擬正常用戶的請求（一般HTTP請求 居多） ***接收端的資源
帶寬資源嚴重被消耗，網(wǎng)站癱瘓，CPU、內(nèi)存利用率飆升，主機癱瘓 瞬間快速打擊，無法快速響應(yīng)

除此之外，我們也知道，對于的發(fā)起方，也有很高的資源要求，包括主機配置，網(wǎng)絡(luò)帶寬，系統(tǒng)優(yōu)化 等等
這些都是要錢的，所以 方如果自己建立集群發(fā)起*** 是賠本賺吆喝

所以，現(xiàn)如今的CC Ddos，更多的是尋找各種宿主機，侵入之后，以它們作為自己的跳板 對目標發(fā)動***
這也就是 俗稱的 肉雞

6） 從運維架構(gòu)師的角度 提出 埋點式七層握手 盡力免費防御DDOS***

• 先從線上架構(gòu)說起

如上圖所示 這就是比較經(jīng)典的 線上五層架構(gòu)， 雖說不是所有互聯(lián)網(wǎng)企業(yè) 都是按照100%的方式搭建

但是 基本的線上框架 現(xiàn)階段始終逃不出這種布局

不管是正常請求，還是***請求， 都是從左至右進入

圖中越向右 各種資源的開銷越大，連帶性也越多，反之則否

所以 我們需要盡可能的 不讓***流量 向右打過來，控制在第一層 第二層的范圍

這就是左推式 優(yōu)化方案（一樣適用于 安全防護）

• 反向代理的重要性

很多朋友 都知道反向代理的概念， 但是并不是十分清楚其實質(zhì)作用

我們就基于LNMP的環(huán)境進行講解， HTTP的請求道來后，需要先經(jīng)過 nginx 處理HTTP協(xié)議 以及靜態(tài)內(nèi)容

如果請求中有動態(tài)內(nèi)容，則反向代理到 PHP（代碼層）進行處理

關(guān)鍵也就在于此處

Nginx可以做七層負載均衡，其實負載均衡的基本功能 也是歸屬在反向代理之中

反向代理的資源消耗 要遠遠小于 PHP代碼層的資源消耗 （Nginx高并發(fā)處理，資源開銷很小）

所以，我們希望的就是 當(dāng)***請求到來時，最多控制在反向代理為止，不讓其連帶到 PHP代碼層

盡可能切斷這種 關(guān)聯(lián)

但是 這種切斷 需要判斷請求的真?zhèn)?這是一個疑難問題

• 如何甄別CC Ddos*** 值得我們?nèi)タ紤]

首先，之前也說過 CC Ddos*** 是模擬真實用戶請求

想通過很簡單的方法，例如 用防火墻加個 IP黑名單的做法 是行不通的

IP數(shù)量龐大，且動態(tài)改變 或者IP偽裝

既然CC***處在七層，那么我們應(yīng)對的方案 也需要在七層中 去想辦法

我這里分享的一種 甄別的方法 ，叫做 埋點七層摸手

什么意思呢？

請參考如下這張圖

我們在七層的基礎(chǔ)上(也就是HTTP) 訂制特定的URL參數(shù)來達到防御***的目的

URL的參數(shù)在客戶端產(chǎn)生，而用戶其實是不知情的

客戶端的開發(fā)人員 和 服務(wù)端的運維開發(fā)人員 是先商量好幾個參數(shù) 并且通過幾個參數(shù)之間的運算得到一個md5值

這個md5值 會在URL中附帶上，并在服務(wù)端檢驗

另外，參數(shù)需要實時變化，不可以一直使用一個死的固定的值（不然 一旦被***截取到一次 就無效了啦）

除此之外，還可以在URL參數(shù)中 額外再增加一項"暗扣"的參數(shù)， 這個參數(shù)不會直接出現(xiàn)在URL中，但是會加入到最終md5值得計算里
這個"暗扣" 客戶端開發(fā)人員 和運維開發(fā)可以事先商量好 放在自己的代碼里

一些優(yōu)化 ， 輪詢?nèi)≈? 適應(yīng)大量API參數(shù)位置 也防止***者猜出參數(shù)
缺點： LUA代碼越多 消耗理論上也越多

那么今天的網(wǎng)絡(luò)安全分享　就到這里啦　^_^
更多的　還請關(guān)注大米的博客后續(xù)哦　謝謝

文章名稱：淺談網(wǎng)絡(luò)安全的經(jīng)驗
文章出自：http://chinadenli.net/article26/pipgjg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站制作、外貿(mào)建站、網(wǎng)站設(shè)計、微信公眾號、手機網(wǎng)站建設(shè)、響應(yīng)式網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)