淺談網(wǎng)絡(luò)安全的經(jīng)驗(yàn)-創(chuàng)新互聯(lián)

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

10年積累的成都做網(wǎng)站、成都網(wǎng)站制作經(jīng)驗(yàn)，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識你，你也不認(rèn)識我。但先網(wǎng)站設(shè)計(jì)后付款的網(wǎng)站建設(shè)流程，更有臺兒免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

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

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

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

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

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

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

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

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

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

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

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

CPU時(shí)間片分布的理解， 時(shí)間片占用的累積

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

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

---

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

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

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

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

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

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

我們就以運(yùn)維的核心OS Linux為基準(zhǔn)

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

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

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

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

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

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

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

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

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

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

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

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

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

從方來說， 逐漸由高難度的 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)核較低時(shí)，服務(wù)器性能較低時(shí) ， 少量的即可造成系統(tǒng)癱瘓
隨著OS和服務(wù)器的提升，流量 有著越來越高的要求

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

另外就是費(fèi)用問題，攻方和守方的費(fèi)用 其實(shí)都是一直在增長的

---

4） 談一談老式的四層*** 以及簡單的模擬實(shí)驗(yàn) （以著名的 Death Ping 和 SYN Flood）

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

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

因?yàn)閿?shù)據(jù)流的走勢 是從右到左， 從上到下， 從下到上 ， 從打包 到 拆包的過程

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

Distributed Dos

• PING***基本原理

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

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

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

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

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

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

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

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

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

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

實(shí)際操作：

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

• SYN半連接***

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

不管是正常請求，還是***請求， 都是從左至右進(jìn)入

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

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

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

• 反向代理的重要性

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

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

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

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

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

反向代理的資源消耗 要遠(yuǎn)遠(yuǎn)小于 PHP代碼層的資源消耗 （Nginx高并發(fā)處理，資源開銷很?。?/p>

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

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

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

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

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

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

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

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

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

什么意思呢？

請參考如下這張圖

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

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

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

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

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

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

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

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

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

當(dāng)前文章：淺談網(wǎng)絡(luò)安全的經(jīng)驗(yàn)-創(chuàng)新互聯(lián)
文章轉(zhuǎn)載：http://www.bm7419.com/article10/dgcgdo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供全網(wǎng)營銷推廣、網(wǎng)站營銷、網(wǎng)站設(shè)計(jì)、電子商務(wù)、靜態(tài)網(wǎng)站、網(wǎng)站導(dǎo)航

廣告

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