凌晨被客戶**吵醒, 報故障說大量的vps延遲增大,丟包. 第一反應就是ros被內網攻擊了. 因為機房有防火牆,來自外部的攻擊不會到達ros. 為了避免內部攻擊, 我也在ros上做了諸多安全策略, 那麼這次故障到底是什麼情況呢?
開啟管理後台,看到ros cpu使用率 55%, 明顯不正常,因為平時cpu使用不會超過30%, 由於ros是軟路由, **不是靠硬體電路, 主要是靠cpu. 所以cpu一直是ros的效能瓶頸和薄弱環節. 但是這次看上行流量和下行流量都不高,在正常範圍之內. 看來不是常規的發包. 常規的發包上行流量達到達到幾百兆.
用winbox登陸ros檢視各個埠的流量資訊:
可以看到每個埠的流量確實沒有明顯增大, 但是注意9口的資料報卻比其他埠高出十幾倍,達到每秒3萬多個. 看來癥結是9口下聯的vps有異常. 9口下面有幾十個vps, 具體是哪個在搞鬼, 還要做進一步判斷: 抓包
可以看到大量偽造源位址(src. address列), 源mac為 00:50:56:ad:55:e9 的資料報在攻擊目的位址為218.98.34.154的80埠,而且size全部都是60, 是很小的資料報. 所以會在流量不明顯增大的情況下極大的影響ros**效能. 當然這樣的資料報也是出不去的, 我在ros做了源位址限制. 不是下屬網段的ip根本出不去.
剩下的就好辦了, 根據源mac揪出肇事的vps, 斷網,網路馬上恢復正常. 聯絡客戶清理系統的事情就交給技術支援工程師了.
這次問題是解決了,但是也導致了十幾分鐘的網路質量下降, 客戶體驗高於一切, 所以如何避免這樣的故障才是關鍵的. ros的api很好用,所以實現自動化處理也很簡單:
1. 寫個指令碼實時監控每個埠的資料報流量, 設定乙個閥值, 超過這個閥值的, 自動執行抓包分析, 根據抓到的資料報比例找出mac, 再根據mac找到對應的vps, 自動斷網, 然後自動發報警郵件.
2. 用指令碼每2秒抓包取樣, 凡是有偽造ip的mac, 不管資料報頻率大小, 找出對應的vps, 斷網, 因為偽造ip準沒好事
1.在處理發包問題的時候,不要嘗試用ip來定位肇事者, 因為一般都是偽造源ip的. 根據mac判斷比較靠譜.
2.自動化處理的時候要注意偽造mac的情況.避免誤殺. 如果在vmware esxi裡面配置不允許偽造mac, 則不需考慮這點.
3.在防火牆的filter rules 裡面配置源位址限制, 根據這條規則的計數器來判斷是不是有偽造源位址的發包, 可以配合查詢肇事者.
chain=forward action=drop src-address=!x.x.x.x-x.x.x.x in-inte***ce=lan官方方法 ROS源
一直不願意寫系統配置相關的blog，因為開源的東西，文件更新很快，以下文件很可能並不適用與你的情況。正文開始 不建議看這個，建議去看官方文件，這裡是記錄一下，避免我自己以後忘記了，好再次配置 sudo sh c etc lsb release echo deb distrib codename ma...
配置 ROS 的 apt 源
配置 ros 的 apt 源 ros的apt源有官方源 國內 ustc 源或新加坡源可供選擇，選擇其一就可以了，建議使用國內 ustc 源或新加坡源，安裝速度會快很多。sudo apt key adv keyserver hkp recv key 0xb01fa116 sudo apt get up...
堆疊查詢注入攻擊
stacked injections 堆疊注入。從名詞的含義就可以看到應該是一堆sql語句 多條 一起執行。而在真實的運用中也是這樣的，我們知道在mysql中，主要是命令列中，每一條語句結尾加 表示語句結束。這樣我們就想到了是不是可以多句一起使用。這個叫做stacked injection。在sql...