:原理、參數(shù)與避坑指南)
簡介Hydra v9.1是一款面向Windows平臺的網(wǎng)絡登錄口令安全測試工具主要服務于滲透測試人員、安全運維工程師及協(xié)議安全研究者用于在獲得合法授權后對SSH、FTP、RDP、HTTP等常見服務進行弱口令檢測與認證強度評估。工具包共36個文件核心由可執(zhí)行主程序、密碼字典檢查輔助程序、Cygwin運行依賴庫、Markdown說明文檔及啟動配置腳本組成整體壓縮包僅8.43MB解壓至任意目錄即可運行顯著降低了Windows下的部署門檻。目前已有2906人學習下載在安全測試場景中具備較高參考價值。使用者可直接利用內(nèi)置的hydra與密碼檢查組件開展登錄爆破測試同時借助說明文檔快速掌握參數(shù)用法并可通過啟動腳本簡化環(huán)境配置適用于合規(guī)的安全測試項目、企業(yè)內(nèi)部風險評估及安全意識培訓中的實操演示。1. 為什么做安全測試的人手里都留著Hydra v9.1這把九頭蛇Hydra v9.1這個名字做安全測試的人幾乎都聽過因為它就是傳說中的九頭蛇。它不是端口掃描器也不負責找Web漏洞而是專門做網(wǎng)絡登錄口令驗證的工具拿字典里的用戶名和密碼去一個需要認證的服務上反復試登錄最后把能通過認證的組合撈出來。很多內(nèi)網(wǎng)系統(tǒng)上線幾年后管理員賬號密碼還停留在弱口令狀態(tài)人工一個個試效率太低Hydra這類工具就是為這種場景準備的。適合有授權范圍的滲透測試工程師、做安全基線的運維以及應急響應里需要快速驗證一批目標賬號是否可用的人。這篇文章從原理講到參數(shù)再講到最容易翻車的幾個坑。2. 拆開Hydra v9.1的前提多線程猜密碼背后每個協(xié)議模塊到底在做什么Hydra v9.1能支持幾十種協(xié)議是因為它把“怎樣跟服務對話”這件事拆成了獨立的模塊。理解這一點比背命令更重要。只有知道模塊和底層流程你才能解釋為什么同一個密碼在SSH上成功、在HTTP表單上卻報錯以及為什么調(diào)低并發(fā)比加高并發(fā)更有效。2.1 從socket到認證響應一次登錄嘗試在Hydra內(nèi)部怎么走可以把一次登錄嘗試想象成一個微型協(xié)議客戶端在跑只是它不和你交互。整個過程通常有四步。第一步是建立TCP連接必要時先讀取服務端Banner。第二步是按協(xié)議語法把用戶名和密碼拼進認證報文。第三步是等待響應并做匹配判斷這次嘗試是否成功。第四步是釋放連接從任務隊列里取下一條組合繼續(xù)。這個循環(huán)對每個線程都在重復。這個流程里最容易產(chǎn)生誤解的是第三步。不同協(xié)議對“成功”的定義完全不同。FTP返回230就算成功SSH返回“Permission denied”就算失敗HTTP表單則要你自己告訴Hydra“出現(xiàn)哪個字符串算失敗”。原因也很簡單Hydra不是通用漏洞掃描器它只能基于模塊內(nèi)置或你提供的成功特征做工。模塊內(nèi)置了特征的就直接判斷比如SSH模塊沒內(nèi)置的比如http-post-form就必須把特征寫在命令里。再來看線程模型。Hydra v9.1默認用并行任務模式工作主進程把字典組合派發(fā)給worker每個worker擁有獨立的socket。這樣設計的好處是一個連接超時不會阻塞其他任務壞處是目標服務如果限制單IP并發(fā)連接數(shù)你把-t開到64就相當于從同一IP同時發(fā)起64個真實登錄會話很容易立刻觸發(fā)防破解策略。所以-t參數(shù)本質(zhì)上是“同時打開的登錄會話數(shù)”不是機器上的CPU線程數(shù)不能想調(diào)多大調(diào)多大。還有一點要注意Hydra的每個模塊處理認證請求時不一定只用一次TCP連接。HTTP表單登錄通常要先跟著302跳轉(zhuǎn)再去拿成功頁面SMB要完成NTLM協(xié)商后再提交憑據(jù)。如果只看表面就會覺得“連接都建立了怎么還報錯”。實際上連接建立只是第一關后續(xù)的協(xié)議狀態(tài)碼和響應體才是判斷依據(jù)。2.2 模塊列表和三個關鍵參數(shù)用 -U 看清協(xié)議插件v9.1內(nèi)置的協(xié)議模塊接近50個常見的有ssh、ftp、http-post-form、smb、rdp、mysql等。不用硬記一條命令就能看到某個模塊的模板語法hydra -U http-post-form這條命令不發(fā)起連接只打印模塊幫助。輸出里通常會有一段SYNTAX示例把URL、POST體、成功失敗關鍵字的位置標清楚。我每次換一個協(xié)議或者換一個服務端版本都會先執(zhí)行一遍-U確認舊模板還能不能用。有三個全局參數(shù)幾乎每個場景都會碰到。-L和-P分別指定用戶名文件和密碼文件每行一個對應的-l和-p是只測一個賬號或一個密碼。-e nsr讓Hydra對每個用戶名額外附加空密碼、用戶名本身和用戶名反轉(zhuǎn)三種組合適合用來先摸一遍非常弱的默認口令。還有一個容易被忽略的是-s它用于指定非默認端口比如SSH跑在2222上時必須寫-s 2222否則Hydra會直接連22端口然后看到連接被拒。如果目標不止一臺可以把IP列表按行寫入文件用-M targets.txt指定。Hydra會依次處理列表里的每個目標-t繼續(xù)控制單個目標內(nèi)的并發(fā)數(shù)。我在多目標場景里會把-t調(diào)低到2不然每個目標都開8個會話整個網(wǎng)絡入口都會被告警刷滿。常用模塊和判斷特征可以這樣看服務協(xié)議模塊名認證報文特點成功判斷SSHsshSSH用戶認證握手服務端返回認證成功FTPftpUSER/PASS命令序列響應碼 230HTTP 表單http-post-form表單POST模板自定義 S/F 關鍵字SMBsmbNTLM 挑戰(zhàn)/響應會話建立成功這個表不是讓你背而是在排錯時有個基本方向。比如SMB模塊輸出STATUS_LOGON_FAILURE問題多半出在憑據(jù)本身如果輸出重試超時問題多半出在并發(fā)太高或網(wǎng)絡丟包。后面避坑章還會再展開。2.3 為什么不用自己寫腳本Hydra的邊界收益與限制作為工程師你可能會想登錄爆破不就是循環(huán)發(fā)請求嘛Python寫一個更可控。這種想法沒錯但有三個現(xiàn)實約束。第一多協(xié)議兼容。SSH、SMB、RDP這些協(xié)議不僅要構造數(shù)據(jù)報文還要處理加密握手、挑戰(zhàn)/響應、服務端版本差異用Python寫要引用一堆庫還要自己維護狀態(tài)。Hydra把這些都封裝在模塊里你只需要關注憑據(jù)和特征。第二多線程調(diào)度。自己寫腳本處理線程池、結果隊列、超時和重試很容易在異常條件下卡死Hydra的worker模型已經(jīng)跑了十幾年邊界情況更全。第三參數(shù)體系成熟。-e nsr、-f、-o這些參數(shù)直接對應滲透測試里常見的“找默認口令”“命中即?!薄奥浔P報告”拿過來就能拼接成工作流。但這不意味著Hydra萬能。它最大的邊界是只能做登錄嘗試不能處理頁面里復雜JavaScript生成的動態(tài)token也不能理解驗證碼。遇到這類場景還是要用Burp、Playwright或自研腳本做狀態(tài)保持。所以我的建議是Hydra適合做標準協(xié)議的口令批量驗證遇到需要上下文交互的Web登錄盡早換思路。這條邊界理解了你就不會在一個不合適的場景里跟參數(shù)較勁。3. 用Hydra v9.1跑通一次最小弱口令審計本地靶機、字典、命令與結果解析前面把原理講通了現(xiàn)在動手。下面所有操作都建議在你自己擁有或明確授權的機器上做比如本地虛擬機而不是拿線上IP直接試。最小閉環(huán)只需要一個SSH服務、兩個字典文件和一條Hydra命令。3.1 準備本地靶機和賬號字典先把實驗環(huán)境圈到內(nèi)網(wǎng)最常見的做法是準備一臺本地Linux虛擬機裝好SSH服務。如果你的開發(fā)機本來就是Linux也可以直接在本機做但要用一個測試賬號不要用自己日常登錄的賬號。安裝命令如下sudo apt update sudo apt install -y hydra openssh-server sudo systemctl enable ssh sudo systemctl start ssh安裝完先用ss -ltnp | grep :22確認端口在監(jiān)聽。這一步很重要很多Hydra失敗實際上是因為服務沒起來。然后創(chuàng)建測試賬號密碼故意設成弱口令方便驗證結果。比如sudo useradd -m -s /bin/bash admin echo admin:123456 | sudo chpasswd注意這只是實驗賬號測完應刪除。我一般會在審計記錄里寫清楚創(chuàng)建了哪些賬號避免清理遺漏。字典文件用最小集。不要一上來就掛大字典先確認鏈路通再慢慢擴大。生成命令printf admin\nroot\ntest\n users.txt printf 123456\npassword\ntest123\n pass.txt生成后最好用cat -A看一眼確認每行沒有多余的空格和^M。Windows格式的字典文件會讓Hydra把\r當成密碼的一部分后面避坑章會專門提。3.2 執(zhí)行SSH口令審計并保存報告最小命令的每個參數(shù)都有用途目標127.0.0.1模塊選ssh。命令如下hydra -L users.txt -P pass.txt 127.0.0.1 ssh \ -t 4 -w 5 -W 2 -f -o ssh_result.txt解釋一下參數(shù)。-L和-P讀取字典ssh是協(xié)議模塊名-t 4表示同時開4個登錄會話本地實驗用足夠-w 5表示一個連接等待服務端響應的超時時間為5秒-W 2表示兩個組合之間間隔2秒降低目標日志壓力-f是找到第一組有效口令就停止-o ssh_result.txt把結果寫入文件避免終端緩沖丟了記錄。跑完查看結果文件cat ssh_result.txt如果成功會有一行類似[22][ssh] host: 127.0.0.1 login: admin password: 123456的記錄。這一行的含義是完整的連接建立、SSH握手、密碼認證全部通過。單看這個就得記到報告里但更可靠的做法是去服務端日志里再確認一次后面第6章會講。如果命令報[ERROR] error: 10061說明端口連不上大概率是sshd沒啟動或端口不對。如果一直停在某個組合沒有輸出先按CtrlC中止然后檢查-W是否把間隔設得太大或者-w太小導致慢服務還沒響應就超時。3.3 讀懂輸出中的INT: 1和error: 10061跑Hydra時終端會不斷刷新進度信息。很多人看到[ERROR] missed reply就慌了其實要先區(qū)分這是單次連接問題還是整體失敗。[ERROR] error: 10061這類信息在Windows平臺代表連接被拒絕對應Linux下的Connection refused意思是目標端口沒有服務。解決辦法很簡單ss -ltnp確認監(jiān)聽或者檢查-s端口參數(shù)。另一個常見狀態(tài)是INT: 1。INT統(tǒng)計的是連接中斷次數(shù)不是成功次數(shù)。如果INT數(shù)字一直漲說明目標服務或中間設備在主動斷你的連接。此時不應該繼續(xù)加線程而應該把-t調(diào)低把-W調(diào)大或者換一個時間段再跑??吹絒STATUS] attack finished表示任務正常結束而不是崩潰。只有DONE配合結果文件里的成功記錄才代表審計閉環(huán)。我一般習慣在跑完后再執(zhí)行一次hydra -l admin -p 123456 127.0.0.1 ssh用它作為單次驗證。這樣能把多線程帶來的干擾排除掉確保成功記錄不是線程競爭產(chǎn)生的誤報。3.4 默認口令初篩用 -e nsr 判斷服務商默認憑據(jù)在投人投時間跑大字典之前我會先用默認口令掃一遍。-e nsr是Hydra內(nèi)置的三種附加嘗試。n代表空密碼s代表密碼和用戶名相同r代表密碼是用戶名的反寫。這個參數(shù)特別適合那種把admin/123456當標配的內(nèi)網(wǎng)設備。命令hydra -L users.txt -P pass.txt 127.0.0.1 ssh -e nsr -t 4執(zhí)行時Hydra會對users.txt里的每個用戶名按順序測試空密碼、用戶名本身、用戶名倒序然后再開始跑你提供的pass.txt。它的價值是能用極小代價覆蓋一類高頻弱口令代價是延長總嘗試次數(shù)。如果你只需要看附加嘗試不想跑pass.txt可以把-P臨時指向一個只含占位符的文件或者用-p指定一個單一密碼再疊加-e nsr。還有一點-e nsr產(chǎn)生的成功記錄同樣會寫入結果文件但賬號和密碼看起來是admin/admin這類容易讓不熟悉的人以為輸錯了字典其實這是工具自帶的組合。這個附加環(huán)節(jié)跑完后再決定是否擴大字典。很多時候默認口令就能覆蓋大部分風險大字典只是為了讓報告更完整。不要一開始就跑幾十GB的字典尤其是對外部防護嚴格的目標。4. 面對真實協(xié)議SSH/FTP/HTTP表單/SMB的Hydra v9.1參數(shù)組合實際工作中不會只碰SSH。FTP、Web登錄、Windows共享是高頻場景。這一章按協(xié)議給出參數(shù)組合也指出每個協(xié)議最需要小心的點。4.1 明文協(xié)議SSH/FTP端口、超時和重試是收斂速度的關鍵FTP和SSH一樣是標準認證流程Hydra用起來相對省心。FTP命令hydra -L users.txt -P pass.txt 192.168.1.10 ftp -s 21 -t 8 -w 5 -W 2-s 21顯示指定端口防止目標FTP跑在非標準口。-t 8對FTP來說已經(jīng)偏高因為很多FTP服務的MaxClients默認不超過10同時8個連接很容易占滿名額。如果報錯login:后面跟著空賬號通常就是連接數(shù)滿了。SSH也一樣但要注意OpenSSH的MaxAuthTries默認6意思是同一個TCP連接里最多試6次密碼。Hydra每次嘗試都是獨立連接所以這個限制攔不住它可是它會觸發(fā)系統(tǒng)的日志告警。我建議SSH命令里加-W 2給日志留出喘息空間。另外SSH和FTP都存在服務端Banner識別問題。如果目標前面的防火墻改了BannerHydra可能不認識服務版本這時要用-s和-m手動指定版本參數(shù)。大多數(shù)情況下直接寫協(xié)議名就夠了。排錯時我會在另一個終端用tcpdump看FTP控制通道確認USER/PASS是否按預期發(fā)送。比如sudo tcpdump -i eth0 port 21 -A。如果看到服務端返回530 Login incorrect說明認證失敗特征匹配正確如果看到連接在USER之前就被復位那就是并發(fā)問題。流量側能直接區(qū)分“認證不過”和“根本沒送進去”。4.2 HTTP表單登錄把POST模板寫進參數(shù)避開兩個響應模板誤區(qū)HTTP表單模塊是所有模塊里最靈活的也是最容易踩坑的。它的協(xié)議關鍵字是一整段用冒號分隔的模板hydra -l admin -P pass.txt 192.168.1.20 http-post-form \ /login.php:user^USER^pass^PASS^submitLogin:FInvalid credentials這段模板分三部分。第一部分是登錄URL必須寫到具體處理登錄的腳本路徑不是網(wǎng)站首頁。第二部分是POST體字段名要和真實表單完全一致^USER^和^PASS^是占位符登錄時被替換成字典內(nèi)容。第三部分是判斷關鍵字F開頭表示“響應里包含這個字符串就算失敗”S開頭表示“包含這個字符串就算成功”。這里最容易翻車的是把F和S用反。我見過有人把登錄成功后的歡迎語寫在F里結果所有嘗試都被判定為失敗。正確做法是先用瀏覽器或curl走一次錯誤密碼看返回什么再走一次正確密碼看返回什么然后選其中一個有區(qū)分度的字符串寫進模板。例如curl -s -d useradminpasswrongsubmitLogin http://192.168.1.20/login.php | grep -i invalid curl -s -d useradminpass123456submitLogin http://192.168.1.20/login.php | grep -i welcome看哪條命令有輸出就把對應的關鍵字放到F或S后面。第二個坑是動態(tài)token。如果登錄頁里有csrf_token并且每次刷新頁面都會變那么用固定POST體直接跑是幾乎必失敗的。服務端會把你提交的舊token判成無效請求。遇到這種場景Hydra外部的腳本預處理通常比硬改參數(shù)更靠譜。你要是堅持用Hydra就只能找一個不接受token的登錄接口或者先用腳本抓取token再公開到本地再讓Hydra讀取但這個鏈路已經(jīng)超出Hydra本身了。4.3 SMB與NTLM的附加選項低并發(fā)和二次驗證SMB登錄和上面的協(xié)議都不一樣。Hydra的smb模塊要完成NTLM挑戰(zhàn)/響應協(xié)商不是簡單發(fā)USER/PASS。所以它的命令看起來簡單實際上每次嘗試的開銷更大hydra -L users.txt -P pass.txt 192.168.1.20 smb -t 2 -w 5這里-t 2是必須的我?guī)缀鯊牟挥贸^4。SMB服務對單IP并發(fā)連接非常敏感開8個會話往往直接返回拒絕。如果輸出大量STATUS_LOGON_FAILURE先認真檢查賬號密碼因為SMB模塊不太會因網(wǎng)絡問題產(chǎn)生假失敗如果大量Connection refused多半是并發(fā)太高或端口不對。還有一個容易被忽略的點Hydra的SMB模塊判斷成功可能只是賬號能建立會話不代表能訪問業(yè)務共享。尤其在一個賬號被禁用但還殘留IPC$訪問權限的情況下Hydra可能把它標記為成功。拿到結果后務必用smbclient之類的客戶端手連一次確認共享列表。例如smbclient -L //192.168.1.20 -U admin%123456我把這個步驟叫“二次驗證”SMB場景下不做這步報告里的“已認證”就會被高估。5. Hydra v9.1避坑指南5個讓口令審計翻車的常見問題與排查這章直接給結論都是我在實際使用中遇到過的現(xiàn)象。每一條按“現(xiàn)象、原因、解決”三個角度拆開。5.1 服務端把重試當暴力破解連接被中途斷開現(xiàn)象任務跑到一半屏幕上連續(xù)出現(xiàn)[ERROR] missed reply緊接著一批嘗試返回Connection refused。再往后連目標IP都ping不通或者SSH直接連接失敗。原因目標服務或安全設備檢測到同一來源短時間大量認證失敗啟動了防爆破策略。最典型的是fail2ban它會在閾值觸發(fā)后臨時封禁來源IP。這時Hydra并不是壞了而是你自己把對方惹毛了。解決第一步降低-t改成2或1第二步加大-W給相鄰嘗試之間加延遲第三步控制字典規(guī)模不要在不知道賬號是否存在時就對全量字典跑。命令可以收斂成hydra -L users.txt -P pass.txt 192.168.1.10 ssh -t 2 -W 5如果服務器確實允許可以把來源IP加入白名單但這已經(jīng)不是Hydra參數(shù)問題了。記住一個原則更快不一定是好事能跑完才是。5.2 字典里的非ASCII密碼被終端或編碼吃掉現(xiàn)象密碼文件里包含bamboo這類非ASCII字符串Hydra要么全部返回錯誤要么結果文件里出現(xiàn)亂碼。甚至有些密碼看著少了一個字符。原因字典文件編碼不是UTF-8或者終端在生成文件時把字符轉(zhuǎn)成了本地編碼。服務端期望的字節(jié)序列和字典里實際傳出去的字節(jié)序列不一致認證自然失敗。解決生成字典統(tǒng)一用UTF-8無BOM編碼并且用腳本處理而不是手動復制??梢韵葓?zhí)行file pass.txt看編碼再用iconv轉(zhuǎn)換。如果目標服務是Windows體系常常需要GBK編碼那就反方向轉(zhuǎn)成GBK。例如iconv -f GBK -t UTF-8 pass_gbk.txt pass.txt最穩(wěn)妥的辦法是在字典里只保留可見ASCII字符除非你明確知道服務端編碼。血淚經(jīng)驗是為了一個帶特殊字符的密碼折騰一下午最后發(fā)現(xiàn)是編碼問題。5.3 HTTP表單帶動態(tài)token時永遠返回失敗現(xiàn)象字典里有正確的賬號密碼但http-post-form模塊全部命中F關鍵字導致沒有任何成功記錄。手動用瀏覽器登錄卻可以成功。原因登錄頁里存在CSRF token它每次GET都會更新。Hydra第一次加載頁面拿到的token在第二次POST時已經(jīng)失效服務端拒絕認證。解決先檢查登錄表單里有沒有csrf或token字段。如果有Hydra不是一個好選擇。可以選擇用腳本抓取token并復用寫成一個小循環(huán)也可以把登錄接口改成API形式繞開token。如果目標授權允許最徹底的做法是先關閉該接口的CSRF校驗再測但多數(shù)情況下不能這么做。腳本思路可以是這樣# 先用curl取login頁把csrf_token提出來 token$(curl -s http://192.168.1.20/login.php | grep -o namecsrf value[^]* | cut -d -f4) curl -d useradminpass123456csrf$token http://192.168.1.20/login.php不要浪費時間在Hydra參數(shù)上方向錯了。5.4 多線程下輸出亂序誤以為某個IP已經(jīng)全測完現(xiàn)象任務結束終端顯示1 of 1 target successfully completed結果文件里也只有一條成功記錄。但之后復核發(fā)現(xiàn)還有另一個賬號密碼也能登錄當時沒測出來。原因使用了-f參數(shù)讓Hydra在找到第一組有效口令后立即停止。多線程環(huán)境下其他線程還沒跑完的組合會被直接丟棄所以這個結果不是全量覆蓋。解決單點登錄測試需要快速拿一個口令時用-f沒問題但全量弱口令審計不能這么做。要去掉-f讓它跑完全部組合。如果想控制時長用-t限制并發(fā)比提前中斷更安全。拿到結果后檢查統(tǒng)計行里的嘗試次數(shù)是否等于用戶字典數(shù)量乘密碼字典數(shù)量。如果少了說明有組合被跳過??梢韵扔脀c -l users.txt pass.txt算一下預期數(shù)量再和Hydra的統(tǒng)計對照。5.5 結果文件里出現(xiàn)重復成功記錄日志審計對不上現(xiàn)象ssh_result.txt里同一組login: admin password: 123456出現(xiàn)兩三次但服務端auth.log里只有一次Accepted password。原因Hydra在連接中斷后會自動重試重試成功后也會寫一條結果。尤其是網(wǎng)絡抖動頻繁時同一個組合可能被發(fā)送了多次而服務端只成功認證了一次其余都斷在TCP層。解決先對結果文件去重sort -u ssh_result.txt再結合服務端日志確認真正成功的次數(shù)。更重要的是在命令里用-w 5 -W 2讓每次嘗試都建立在干凈連接上減少重試。還有一點不要用-o覆蓋模式重復跑同一個目標換個輸出文件名能避免舊記錄混淆。6. 把Hydra v9.1的驗證做干凈交叉核對日志與自定義成功特征前面的命令能拿到結果但結果要對得起審計報告。最后說兩個我常用的驗證技巧。6.1 用 -v -d 打開調(diào)試流先確認失敗長什么樣正式跑全量字典之前我會先制造一次必然失敗的嘗試再用調(diào)試模式觀察輸出。命令是hydra -l admin -p wrongpass 127.0.0.1 ssh -v -d-v會打印每次嘗試的完整過程-d會把模塊和服務端交互的原始內(nèi)容打出來。確認失敗特征穩(wěn)定后再換成正確密碼跑一次確認成功特征。這樣在正式結果里看到成功記錄你心里就有底了——它不是某個關鍵字偶然匹配出來的。6.2 交叉核對服務端日志別讓結果文件騙你Hydra的輸出只是客戶端視角。拿到成功記錄后去服務端查一次認證日志。SSH服務在Linux上通常記錄到/var/log/auth.loggrep Accepted password for admin /var/log/auth.log | tail -10如果結果文件里寫著admin / 123456而auth.log里沒有對應的Accepted行那這條結果大概率是假的可能來自調(diào)試狀態(tài)或誤匹配。HTTP服務就查訪問日志看有沒有對應的POST登錄請求和302跳轉(zhuǎn)。只有兩邊能對上我才會把結果寫進報告。6.3 一個血淚教訓并發(fā)參數(shù)不是越大越好我在一次內(nèi)網(wǎng)審計里把-t調(diào)成64去測FTP結果目標FTP服務直接崩潰最后客戶不但沒拿到報告還因為服務受影響被運維投訴。從那以后我給自己定了一個習慣所有協(xié)議先用-t 2驗證鏈路再按服務承載能力逐步往上調(diào)最多不超過16。安全測試本身就是在可控范圍內(nèi)做驗證沒授權不要測有授權也要輕拿輕放。Hydra v9.1是一把好用的九頭蛇但用它的前提是思路清楚、參數(shù)克制、結果可審計。希望幫到你。本文還有配套的精品資源點擊獲取