前一陣做內(nèi)網(wǎng)口令安全評估我寫了個(gè)批量口令噴灑腳本對著三十幾臺新到的網(wǎng)絡(luò)設(shè)備跑。跑到半程結(jié)果讓我一下子清醒A設(shè)備的admin賬號密碼明明是對的系統(tǒng)卻返回認(rèn)證失敗B設(shè)備根本沒測過幾次guest日志里卻顯示guest因?yàn)檫B續(xù)錯(cuò)誤被鎖定。我第一反應(yīng)是腳本的線程把結(jié)果寫串了于是翻代碼、看日志、加鎖、重跑折騰到凌晨發(fā)現(xiàn)每條輸出對應(yīng)的IP都對得上。腳本是好的問題出在測試鏈路本身。那段時(shí)間我滿腦子就四個(gè)字共享狀態(tài)。后面發(fā)生的事情讓我把隔離這件事從網(wǎng)絡(luò)到容器再到電路完整走了一遍最后還揭開了一個(gè)黑盒設(shè)備的一角。這篇文章就是完整的過程復(fù)盤對剛?cè)胄凶霭踩珳y試、負(fù)責(zé)環(huán)境搭建或者寫并發(fā)腳本的工程師應(yīng)該都能找到點(diǎn)有用的東西。1. 口令實(shí)驗(yàn)撞上的串號事故測試結(jié)果為什么會互相污染1.1 實(shí)驗(yàn)場景35臺設(shè)備一套集中認(rèn)證這次任務(wù)是給公司新購入的一批網(wǎng)絡(luò)設(shè)備做口令安全評估。設(shè)備共35臺都是同一個(gè)廠商同一個(gè)型號管理端統(tǒng)一接入一臺用了很多年的認(rèn)證服務(wù)器走RADIUS做AAA認(rèn)證。所謂AAA就是認(rèn)證、授權(quán)、計(jì)費(fèi)簡單說就是設(shè)備自己不做密碼判斷把用戶名和密碼轉(zhuǎn)發(fā)給認(rèn)證服務(wù)器認(rèn)證服務(wù)器說通過設(shè)備才放行。為了不干擾正常業(yè)務(wù)網(wǎng)段管理員要求所有測試流量經(jīng)過跳板機(jī)進(jìn)出。跳板機(jī)做了源NAT所有從測試機(jī)發(fā)過去的請求源IP都會被改寫成同一個(gè)地址。這一步本來是為了管理方便誰也想不到它成了后續(xù)所有怪象的伏筆。測試腳本用Python寫的線程池開8個(gè)worker每個(gè)worker負(fù)責(zé)若干臺設(shè)備的Web登錄頁往登錄接口提交用戶名和口令組合再根據(jù)HTTP響應(yīng)判斷是否成功。腳本本身很普通扔到任何一臺機(jī)器上都能跑。問題也正出在這個(gè)普通上它太依賴一個(gè)假設(shè)——每個(gè)請求都是獨(dú)立的。1.2 三種詭異現(xiàn)象誤報(bào)、虛放、誤鎖事故的現(xiàn)象有三類我很清楚地列在文檔里。第一是誤報(bào)。A設(shè)備用正確的admin口令登錄Web頁面明確提示用戶名或密碼錯(cuò)誤。手動用瀏覽器登錄同一臺設(shè)備同樣的口令一登就進(jìn)。設(shè)備和口令都沒問題。第二是虛放。B設(shè)備用錯(cuò)誤的guest口令登錄居然偶爾能跳轉(zhuǎn)到管理主界面。這意味著有些錯(cuò)誤的嘗試被認(rèn)證服務(wù)器判定為通過這是比誤報(bào)更嚴(yán)重的事。第三是誤鎖。C設(shè)備的admin賬號腳本只提交過兩次錯(cuò)誤口令但設(shè)備日志顯示它已經(jīng)觸發(fā)了連續(xù)失敗鎖定策略賬號直接被鎖。奇怪的是三種現(xiàn)象不是同時(shí)出現(xiàn)在每臺設(shè)備上而是隨機(jī)分布在不同設(shè)備和不同時(shí)間點(diǎn)。這讓我最初完全沒有規(guī)律可循。1.3 三條排查路線程、單臺、并發(fā)驗(yàn)證排查第一步審查腳本。我把所有并發(fā)線程改成串行執(zhí)行一次只跑一臺設(shè)備。結(jié)果很干凈所有正確口令全通過錯(cuò)誤口令全被拒鎖定策略不再誤觸發(fā)。這一步說明設(shè)備和口令庫本身沒有毛病。第二步恢復(fù)并發(fā)但只保留一臺設(shè)備。結(jié)果同樣正常。說明單純的高并發(fā)也不會導(dǎo)致問題。第三步恢復(fù)并發(fā)且保留全部35臺設(shè)備同時(shí)把線程數(shù)提升到16個(gè)。問題立刻回來了。于是我的懷疑范圍縮小到一個(gè)很具體的條件并發(fā)加多臺設(shè)備同時(shí)向同一臺認(rèn)證服務(wù)器發(fā)起認(rèn)證。為了確認(rèn)網(wǎng)絡(luò)層的因素我在跳板機(jī)上抓包。抓包結(jié)果很有趣RADIUS請求正常發(fā)出響應(yīng)也正常返回但對不上的不是報(bào)文本身而是請求和響應(yīng)之間的事務(wù)對應(yīng)關(guān)系。簡單說A設(shè)備發(fā)出的認(rèn)證請求拿到的是B設(shè)備認(rèn)證請求的響應(yīng)。到這里我已經(jīng)非常確定問題出在某種共享狀態(tài)上只是不知道它藏在哪一層。2. 共享狀態(tài)的三種藏身之處連接池、全局變量與設(shè)備固件2.1 共享狀態(tài)到底是什么共享狀態(tài)說得直白一點(diǎn)就是多個(gè)執(zhí)行單元共同讀寫同一份數(shù)據(jù)。寫單線程程序時(shí)這份數(shù)據(jù)是你的私有變量一旦開了多線程、多進(jìn)程或者多臺設(shè)備同時(shí)往同一個(gè)服務(wù)發(fā)請求這份數(shù)據(jù)就變成了公共資源誰都能碰誰都會改它。我習(xí)慣拿公寓水電表打比方如果每家每戶有獨(dú)立分表誰用了多少電一清二楚但整棟樓只有一塊總表某一戶開了個(gè)大功率空調(diào)整棟樓的賬單都會跳。認(rèn)證服務(wù)器里那張會話表就是那塊總表。2.2 藏身點(diǎn)之一客戶端連接池和會話對象第一類常見的共享狀態(tài)在客戶端。很多剛寫并發(fā)腳本的工程師第一反應(yīng)是共享requests.Session因?yàn)镾ession里帶著Cookie和連接池多線程共用同一個(gè)Session時(shí)如果服務(wù)端按Keep-Alive連接緩存認(rèn)證上下文線程A的請求就可能被線程B繼承了狀態(tài)。這種問題在單純訪問公開接口時(shí)不容易暴露因?yàn)闊o狀態(tài)接口不依賴上下文。但在口令實(shí)驗(yàn)里登錄接口天然依賴會話一旦服務(wù)端針對連接而不是針對用戶維護(hù)狀態(tài)串號就來了。我早年被這種問題坑過所以這次一開始也懷疑過它但很快被排除了就算把腳本改成每個(gè)線程獨(dú)立Session問題依然在。2.3 藏身點(diǎn)之二服務(wù)端全局注冊表第二類在服務(wù)端。很多老系統(tǒng)為了節(jié)省內(nèi)存會把會話注冊表做成一個(gè)全局的單例對象用哈希表保存所有在線會話。如果Key設(shè)計(jì)不合理比如只按源IP區(qū)分那么來自同一源IP的并發(fā)請求就會共享同一個(gè)會話槽。偽代碼大致是這樣# 錯(cuò)誤示范會話Key只按源IP區(qū)分 session_table[source_ip] session_context更合理的Key應(yīng)該組合源IP、目標(biāo)設(shè)備IP、用戶名甚至隨機(jī)序列號。這也是我在排查過程中最懷疑的地方因?yàn)槲覀兊膱鼍袄锼姓埱蠖紒碜酝粋€(gè)源IP和這種錯(cuò)誤Key的特征完全吻合。2.4 藏身點(diǎn)之三設(shè)備固件里看不見的全局會話表最后就是這次真正的主角。那臺認(rèn)證服務(wù)器是閉源的文檔只寫了支持并發(fā)認(rèn)證請求但沒有說明內(nèi)部如何管理會話。它的固件里極大概率維護(hù)了一個(gè)當(dāng)前活動會話的全局變量或者一張以源IP為索引的會話表。新請求到達(dá)時(shí)如果源IP已經(jīng)有一個(gè)活動會話新請求會直接把舊會話頂?shù)?。認(rèn)證響應(yīng)生成時(shí)固件讀取當(dāng)前會話槽自然把對應(yīng)另一個(gè)請求的結(jié)果返回回去。這樣一來任何來自同一IP的并發(fā)請求響應(yīng)都可能被裝到別的請求頭上。用一句話概括它把一個(gè)源IP當(dāng)成了一個(gè)客戶端并且默認(rèn)一個(gè)客戶端不會有并發(fā)認(rèn)證。2.5 為什么口令實(shí)驗(yàn)里共享狀態(tài)的殺傷力被放大如果只是普通接口的并發(fā)測試這種串號頂多讓返回?cái)?shù)據(jù)對不上重試兩次就完事。但口令實(shí)驗(yàn)里共享狀態(tài)帶來的后果嚴(yán)重得多正確口令被記錄為失敗你會誤判設(shè)備存在弱口令問題。錯(cuò)誤口令被判定為通過弱口令問題反而被掩蓋。多次錯(cuò)配會觸發(fā)服務(wù)端的賬號鎖定策略直接把合法賬號鎖死影響業(yè)務(wù)。如果共享會話中偶然殘留其他用戶的口令信息還可能在日志里留下敏感數(shù)據(jù)。所以當(dāng)確認(rèn)問題的性質(zhì)后我?guī)缀鯖]有猶豫就確定了解決辦法的方向隔離。把不該共享的狀態(tài)拆開把測試流量從一口鍋里分到獨(dú)立灶臺上。3. 隔離方案的四個(gè)工程層次從VLAN到光耦的取舍那晚之后我把隔離手段按層次梳理了一遍發(fā)現(xiàn)一個(gè)很清晰的分界線從網(wǎng)絡(luò)域做隔離到容器資源隔離再到內(nèi)核驅(qū)動清理最后是電路級的光耦隔離。每多走一層隔離更徹底成本也更高。下面把這四層詳細(xì)說一下。3.1 網(wǎng)絡(luò)域隔離VLAN劃分與ACL配置最便宜的隔離是網(wǎng)絡(luò)域隔離。把測試網(wǎng)段從生產(chǎn)網(wǎng)段中剝離開讓測試流量只可能到達(dá)目標(biāo)設(shè)備。在實(shí)驗(yàn)開始之前我就應(yīng)該先把測試區(qū)劃到獨(dú)立VLAN可惜當(dāng)時(shí)跳板機(jī)直接接入設(shè)備管理網(wǎng)省了這一步也就漏掉了第一層防護(hù)。配置VLAN和ACL的思路很簡單示例命令如下不同廠商語法有差異思路一致# 創(chuàng)建測試VLAN 100網(wǎng)段10.10.100.0/24 vlan 100 name test-net # 三層接口 interface vlanif 100 ip address 10.10.100.1 255.255.255.0 # ACL只允許測試網(wǎng)段訪問目標(biāo)設(shè)備網(wǎng)段10.10.20.0/24 acl number 3001 rule 5 permit ip source 10.10.100.0 0.0.0.255 destination 10.10.20.0 0.0.0.255 rule 10 deny ip # 接入端口 interface g0/0/1 port link-type access port default vlan 100 traffic-filter inbound acl 3001這樣配置之后生產(chǎn)網(wǎng)段的流量進(jìn)不到測試區(qū)測試區(qū)也訪問不到生產(chǎn)網(wǎng)段。代價(jià)是增加了網(wǎng)絡(luò)規(guī)劃工作量好處是萬一測試腳本失控爆炸半徑被限制在測試VLAN內(nèi)。但這里必須說清楚VLAN隔離解決的是域的問題它可解決不了認(rèn)證服務(wù)器內(nèi)部的會話表問題。兩臺設(shè)備哪怕不在一個(gè)VLAN只要它們把認(rèn)證請求發(fā)給同一個(gè)服務(wù)器且源IP相同會話照樣串。所以網(wǎng)絡(luò)域隔離只是第一步不是全部。3.2 容器資源隔離給每個(gè)測試進(jìn)程一個(gè)獨(dú)立網(wǎng)絡(luò)空間我們的核心需求從認(rèn)證服務(wù)器的視角看是讓35臺設(shè)備的并發(fā)請求看起來來自35個(gè)不同客戶端。最直接的實(shí)現(xiàn)方式就是用容器給每個(gè)測試進(jìn)程分配獨(dú)立的網(wǎng)絡(luò)命名空間和獨(dú)立IP。當(dāng)時(shí)我用的方案是Docker配合macvlan網(wǎng)絡(luò)# 創(chuàng)建基于VLAN 100的macvlan網(wǎng)絡(luò) docker network create -d macvlan \ --subnet10.10.100.0/24 \ --gateway10.10.100.1 \ -o parenteth0.100 test-macvlan # 每臺設(shè)備一個(gè)容器分配獨(dú)立IP for i in $(seq 1 35); do docker run -d --name spray-$i \ --network test-macvlan \ --ip 10.10.100.$((i10)) \ spray-image --target 10.10.20.$i done每個(gè)容器擁有自己獨(dú)立的協(xié)議棧、路由表、ARP表發(fā)出的請求都會帶上自己的源IP。認(rèn)證服務(wù)器看到的就不再是同一個(gè)IP下的高并發(fā)而是35個(gè)獨(dú)立IP的登錄請求。做完這一步之后串號現(xiàn)象立刻消失。容器隔離本質(zhì)上是Linux內(nèi)核的namespace機(jī)制在起作用。network namespace隔離了網(wǎng)絡(luò)棧PID namespace隔離了進(jìn)程視圖。它比虛擬機(jī)輕量但也有一個(gè)隱含代價(jià)容器共享宿主內(nèi)核。宿主機(jī)內(nèi)核一旦被某個(gè)不兼容驅(qū)動污染容器網(wǎng)絡(luò)就可能集體出問題。這就到了下一層。3.3 內(nèi)核與驅(qū)動隔離當(dāng)隔離工具本身不干活我在搭容器網(wǎng)絡(luò)的時(shí)候正好撞上了這個(gè)問題。宿主機(jī)之前裝過一版第三方網(wǎng)絡(luò)準(zhǔn)入客戶端它在內(nèi)核里注冊了網(wǎng)絡(luò)過濾鉤子。macvlan給容器分配虛擬網(wǎng)卡時(shí)這個(gè)過濾鉤子把所有非本地流量都給攔了導(dǎo)致容器能啟動但網(wǎng)絡(luò)完全不通。排查過程比較痛苦因?yàn)楝F(xiàn)象是幾乎所有網(wǎng)絡(luò)命令都正常但容器一個(gè)包都發(fā)不出去。最終定位到驅(qū)動層處理方式如下# 查看已加載的沖突模塊 lsmod | grep access # 停掉依賴該驅(qū)動的服務(wù) systemctl stop access-client # 從內(nèi)核卸載模塊 rmmod access_driver # 永久禁用把模塊加入黑名單 echo blacklist access_driver /etc/modprobe.d/blacklist-test.conf update-initramfs -u reboot注意一點(diǎn)rmmod的時(shí)候如果模塊正被進(jìn)程引用內(nèi)核會拒絕卸載并提示Module in use。這時(shí)候強(qiáng)來不行得先停服務(wù)再卸載模塊。生產(chǎn)環(huán)境的服務(wù)器千萬別隨手執(zhí)行這些命令最好先確認(rèn)模塊用途再在維護(hù)窗口操作。內(nèi)核對驅(qū)動的不兼容很難從日志里直接看出來搭建實(shí)驗(yàn)環(huán)境時(shí)最好從一開始就用干凈的宿主機(jī)尤其是做網(wǎng)絡(luò)實(shí)驗(yàn)時(shí)。所謂內(nèi)核隔離在實(shí)驗(yàn)場景里其實(shí)就是要保證宿主內(nèi)核沒有因?yàn)槟硞€(gè)驅(qū)動被額外共享到影響所有容器。這是很多人容易忽略的一層。3.4 電路級隔離9600波特率下的光耦隔離選型隔離的最后一層在物理電路上。這次實(shí)驗(yàn)里有一臺老設(shè)備網(wǎng)絡(luò)管理口已經(jīng)失效只能靠串口調(diào)試。我把USB轉(zhuǎn)串口接到筆記本上數(shù)據(jù)時(shí)斷時(shí)續(xù)偶爾還冒出亂碼。一測設(shè)備電源地和筆記本地之間存在將近2伏的壓差。地環(huán)路引起的漏電問題靠的就是電氣隔離來解決。光耦隔離的原理很直接輸入端把電平信號轉(zhuǎn)換成紅外光輸出端檢測到光之后再轉(zhuǎn)換成電平信號。輸入和輸出之間沒有電氣連接地環(huán)路被直接切斷。需要注意光耦隔離通信中波特率與器件延遲的關(guān)系至關(guān)重要選型時(shí)一定要算清楚。9600波特率是串口最常用的低速檔。按8N1格式一個(gè)bit的時(shí)長是1除以9600秒約104.17微秒。普通光耦PC817的傳播延遲典型值在4到10微秒加上上升下降時(shí)間一個(gè)bit周期內(nèi)還有足夠的裕量完成翻轉(zhuǎn)所以隔離9600波特率的串口信號PC817勉強(qiáng)能用但邊沿質(zhì)量比較差。我當(dāng)時(shí)用的是PC817把光耦做成了一個(gè)很小的轉(zhuǎn)接板插在串口線上實(shí)驗(yàn)數(shù)據(jù)湊合能用但如果要求信號波形更干凈我會換高速光耦。如果波特率提到115200一個(gè)bit只剩8.68微秒PC817的延遲就明顯不夠了必須上6N137這類高速光耦。6N137的傳播延遲小于100納秒適合幾Mbps到10Mbps的速率。我整理了一個(gè)簡單的選型表型號傳播延遲推薦速率典型用途PC8174-10微秒不超過9600波特率低速IO隔離、簡單串口隔離6N137小于100納秒最高10Mbps高速串口、RS232/RS485隔離TLP2361小于100納秒數(shù)十Mbps緊湊型高速隔離順帶提一句如果去看電源設(shè)計(jì)會發(fā)現(xiàn)還有非隔離高效率LCC拓?fù)?、非隔離式Buck-Boost電路這類方案。它們的優(yōu)點(diǎn)是效率高、體積小、成本低壞處就是沒有電氣隔離調(diào)試時(shí)人和設(shè)備都直接暴露在危險(xiǎn)電位下。隔離型方案加了一個(gè)變壓器或光耦成本高一點(diǎn)但故障時(shí)能切斷危險(xiǎn)傳導(dǎo)路徑。這個(gè)取舍邏輯和軟件層隔離是一樣的多一層隔離多一點(diǎn)安全邊際代價(jià)是更多一點(diǎn)成本和復(fù)雜度。4. 黑盒一角會話串號背后的固件會話管理機(jī)制4.1 控制變量法鎖定元兇隔離方案上線之后我把完整測試流程重新跑了一遍。結(jié)果非常干凈所有正確口令全部一次通過錯(cuò)誤口令全部被拒鎖定策略只在賬號真正連續(xù)多次失敗后才觸發(fā)。與之前唯一的差別就是源IP從1個(gè)變成了35個(gè)。我還沒敢直接下結(jié)論又做了一組對照實(shí)驗(yàn)。這次故意把全部容器的源IP統(tǒng)一改成一個(gè)地址跑5分鐘后串號現(xiàn)象立刻復(fù)活。改回獨(dú)立IP現(xiàn)象消失。來來回回三次每次結(jié)果一致。到這里元兇被徹底鎖定認(rèn)證服務(wù)器內(nèi)部維護(hù)著一份以源IP為索引的共享會話表。4.2 抓包還原請求與響應(yīng)的錯(cuò)位過程為了把機(jī)制還原得更精確我在認(rèn)證服務(wù)器的RADIUS端口和其中兩臺設(shè)備的網(wǎng)口上同時(shí)抓包。時(shí)間線是這樣的T1時(shí)刻源IP 10.10.100.11上的管理員用戶A發(fā)起認(rèn)證請求認(rèn)證服務(wù)器為它創(chuàng)建會話S1。 T2時(shí)刻源IP 10.10.100.11上的管理員用戶B發(fā)起認(rèn)證請求。固件發(fā)現(xiàn)該源IP已有活動會話用新會話S2覆蓋了S1。 T3時(shí)刻認(rèn)證結(jié)果返回。響應(yīng)頭里帶的會話標(biāo)識是S2對應(yīng)的用戶B的認(rèn)證結(jié)果。于是用戶A拿到的回執(zhí)其實(shí)是用戶B的結(jié)果。用文字表達(dá)就是這樣請求A正確口令 → 會話S1 → 被請求B覆蓋 請求B錯(cuò)誤口令 → 會話S2 → 響應(yīng)返回到請求A的位置S1的結(jié)果被S2覆蓋丟失S2的結(jié)果被A設(shè)備讀取。于是A設(shè)備的正確口令失敗了B設(shè)備的錯(cuò)誤口令卻通過了。鎖定策略的誤觸發(fā)也是一樣的邏輯某次認(rèn)證請求明明沒失敗但被錯(cuò)誤響應(yīng)標(biāo)記為失敗計(jì)數(shù)累加最終鎖賬號。4.3 為什么說這只是黑盒的一角說它是黑盒是因?yàn)檫@臺AAA服務(wù)器是閉源的老設(shè)備官方文檔只寫了支持并發(fā)認(rèn)證請求完全沒提內(nèi)部的會話管理方式。從外部只能看到請求和響應(yīng)的報(bào)文內(nèi)部固件怎么組織狀態(tài)是看不見的。我所有排查本質(zhì)上都是在黑盒外部做行為推斷如果不是隔離實(shí)驗(yàn)把變量砍干凈了我可能到現(xiàn)在還在懷疑腳本?，F(xiàn)在我能確切知道一個(gè)內(nèi)部行為它把一個(gè)源IP當(dāng)成了一個(gè)活動客戶端同一源IP的活動會話只有一份。但我不知道它內(nèi)部是用全局變量、單向鏈表還是某種哈希表來實(shí)現(xiàn)的也不知道它還藏著多少類似限制。盒子里只露出了一條縫看到了一根線但這一根線足以解釋所有奇怪現(xiàn)象。4.4 發(fā)現(xiàn)帶來的直接改變這個(gè)黑盒行為顛覆了我對這類老認(rèn)證服務(wù)器并發(fā)支持的信任。之后的測試環(huán)境規(guī)范里我加了一條硬性要求任何涉及AAA認(rèn)證的口令實(shí)驗(yàn)都必須為并發(fā)請求分配多個(gè)源IP禁止用單一跳板源IP做高并發(fā)噴灑。能走獨(dú)立管理口的目標(biāo)設(shè)備盡量分開管理不能分開的就用容器或者虛擬網(wǎng)絡(luò)把源IP拆散。我也給廠商提了問題單附上了對照實(shí)驗(yàn)記錄和抓包時(shí)間線。對方后來回復(fù)產(chǎn)品固件的確為簡化會話管理做了這個(gè)設(shè)計(jì)同一來源IP只維護(hù)一個(gè)活動會話且官網(wǎng)文檔沒有明確寫出該限制。這個(gè)回復(fù)讓我挺感慨你以為在測試一個(gè)黑盒最后發(fā)現(xiàn)黑盒里裝的是人家當(dāng)初一拍腦袋做的簡化方案。5. 可復(fù)現(xiàn)的口令隔離實(shí)驗(yàn)三步走與環(huán)境清單5.1 第零步畫一張共享點(diǎn)拓?fù)鋱D動手之前先把拓?fù)洚嬊宄?。別嫌麻煩排查時(shí)這張圖能幫你快速鎖定變量。拓?fù)鋱D上至少要標(biāo)出三類信息流量路徑測試機(jī)到跳板、跳板到設(shè)備網(wǎng)段、設(shè)備到認(rèn)證服務(wù)器的完整路徑。NAT點(diǎn)哪里做了源地址轉(zhuǎn)換改成了什么地址。狀態(tài)存儲點(diǎn)認(rèn)證服務(wù)器、會話管理組件、連接池等可能保存狀態(tài)的位置。我當(dāng)時(shí)就是因?yàn)樘鍣C(jī)上那個(gè)源NAT沒標(biāo)出來排查時(shí)多繞了一大圈。如果一開始就知道所有請求從認(rèn)證服務(wù)器視角看都同源可能第一輪就能想到共享會話表。5.2 環(huán)境搭建VLAN、容器與測試工具按下面的清單準(zhǔn)備環(huán)境基本可以覆蓋大多數(shù)口令評估實(shí)驗(yàn)準(zhǔn)備項(xiàng)配置說明測試機(jī)獨(dú)立Linux服務(wù)器建議有2個(gè)以上網(wǎng)口網(wǎng)絡(luò)隔離獨(dú)立VLAN 100測試網(wǎng)段10.10.100.0/24目標(biāo)接入設(shè)備網(wǎng)段10.10.20.0/24與測試VLAN可互通容器網(wǎng)絡(luò)Docker加macvlan每個(gè)容器獨(dú)立IP測試腳本Python并發(fā)腳本每個(gè)線程或進(jìn)程綁定獨(dú)立源IP抓包工具tcpdump或Wireshark客戶端與服務(wù)端同時(shí)抓容器網(wǎng)絡(luò)創(chuàng)建方式在3.2節(jié)給過直接抄作業(yè)即可。5.3 分階段執(zhí)行冒煙、基線、并發(fā)、驗(yàn)證執(zhí)行流程我建議分成五個(gè)階段順序不要亂冒煙單線程、單容器只測一臺設(shè)備確認(rèn)工具本身沒問題。基線串行跑完所有設(shè)備記下每臺設(shè)備的正確口令和弱口令基線。這一步是后續(xù)判斷并發(fā)是否串號的參照物。并發(fā)測試所有容器同時(shí)啟動每個(gè)容器獨(dú)立源IP按計(jì)劃做口令噴灑。復(fù)現(xiàn)實(shí)驗(yàn)有意把所有容器源IP改成一個(gè)復(fù)跑一小段確認(rèn)黑盒行為可復(fù)現(xiàn)為問題單留證據(jù)。回歸驗(yàn)證恢復(fù)獨(dú)立源IP再跑一遍確認(rèn)修復(fù)有效。每一步做完把結(jié)果文件按設(shè)備IP命名歸檔避免后面混淆。5.4 踩坑清單這次實(shí)驗(yàn)最大的五個(gè)坑癥狀根因解決辦法正確口令被拒絕認(rèn)證服務(wù)器共享會話表被并發(fā)請求覆蓋多源IP并發(fā)不做單源高并發(fā)錯(cuò)誤口令偶爾通過響應(yīng)錯(cuò)配到另一個(gè)請求抓包比對事務(wù)ID或會話ID賬號莫名鎖定鎖定策略被并發(fā)誤判觸發(fā)評估鎖定閾值控制測試頻率容器網(wǎng)卡反復(fù)掉線內(nèi)核驅(qū)動與macvlan沖突卸載沖突模塊并加入黑名單串口數(shù)據(jù)亂碼設(shè)備地與筆記本地存在壓差串口線加光耦隔離這張表里的前四條在普通業(yè)務(wù)系統(tǒng)測試?yán)镆部赡苡龅?。尤其是第五條看似是硬件問題本質(zhì)還是共享地導(dǎo)致的隔離缺失。5.5 善后數(shù)據(jù)歸檔與問題反饋實(shí)驗(yàn)結(jié)束后抓包文件、腳本版本、容器配置、結(jié)果數(shù)據(jù)全部歸檔命名按日期和實(shí)驗(yàn)批次來?？诹钤u估的結(jié)果數(shù)據(jù)非常敏感不要散落在臨時(shí)目錄測試結(jié)束后一并將容器銷毀、VLAN清理。如果需要向廠商反饋黑盒行為附上對照實(shí)驗(yàn)時(shí)間線和抓包會話比任何文字描述都有說服力。那次實(shí)驗(yàn)之后我把隔離狀態(tài)寫進(jìn)了自己的測試環(huán)境設(shè)計(jì)清單。共享狀態(tài)本身不是壞事很多并發(fā)框架恰恰靠它才獲得高性能但在口令實(shí)驗(yàn)里一旦狀態(tài)串了輕則測試結(jié)論報(bào)廢重則賬號被鎖、業(yè)務(wù)受損。我現(xiàn)在動手做任何測試之前第一件事都是盯著拓?fù)鋱D問自己哪些狀態(tài)是共享的哪些是可以在開始之前就先隔開的把源IP拆開、網(wǎng)絡(luò)域分開、驅(qū)動清理干凈、串口做物理隔離很多坑其實(shí)是可以在踩進(jìn)去之前就繞開的。這比事后抓包省心太多了也順便把黑盒的一角看得更清楚了。