淺談網絡安全的經驗-創(chuàng)新互聯

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

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

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

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

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

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

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

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

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

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

第一個 要求有一定的數學基礎 數學命令行的使用難度較大

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

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

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

COUNTER類型數據的理解

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

---

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

***的本質是什么？ 其實說到底 就是 對服務器現有資源的強力打擊 或者說是消耗

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

第一類：服務器物理層面的 資源

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

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

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

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

第三類： 網絡資源

這里主要指的是網絡帶寬，這是非常珍貴的資源，后面也會具體的講解

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

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

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

現如今都是互聯應用時代，一切都走網絡，所以 網絡資源的消耗 自然是不言而喻的

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

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

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

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

任何一種資源 如果出現瓶頸 都會牽制其他的資源

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

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

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

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

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

---

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

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

經典的OSI七層模型 ， 我在教學中 又把它稱為 U型結構的七層模型

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

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

Distributed Dos

• PING***基本原理

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

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

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

IP協議包頭中 有對IP包大小的限制（65535 TL字段， 包頭+數據實體） ，包的重組 又需要借助Linux的內核才能完成

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

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

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

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

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

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

實際操作：

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

• SYN半連接***

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

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

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

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

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

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

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

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

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

5） 談一談現如今的七層*** Ddos

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

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

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

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

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

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

• 先從線上架構說起

如上圖所示 這就是比較經典的 線上五層架構， 雖說不是所有互聯網企業(yè) 都是按照100%的方式搭建

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

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

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

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

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

• 反向代理的重要性

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

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

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

關鍵也就在于此處

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

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

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

盡可能切斷這種 關聯

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

• 如何甄別CC Ddos*** 值得我們去考慮

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

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

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

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

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

什么意思呢？

請參考如下這張圖

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

URL的參數在客戶端產生，而用戶其實是不知情的

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

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

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

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

一些優(yōu)化 ， 輪詢取值 適應大量API參數位置 也防止***者猜出參數
缺點： LUA代碼越多 消耗理論上也越多

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

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

當前文章：淺談網絡安全的經驗-創(chuàng)新互聯
文章轉載：http://muchs.cn/article10/dgcgdo.html

成都網站建設公司_創(chuàng)新互聯，為您提供全網營銷推廣、網站營銷、網站設計、電子商務、靜態(tài)網站、網站導航

廣告

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