MySQL max_allowed_packet 自動重置為 1024 之謎：原來是駭客入侵

前言：詭異的參數自動重置

在一台 CentOS 測試環境中，MySQL 不斷拋出 PacketTooBigException: Packet for query is too large (1354 > 1024) 錯誤。雖然透過 SET GLOBAL max_allowed_packet 或修改 my.cnf 可暫時解決，但過幾小時到幾天，數值就會神秘地自動重置回 1024。經過一番排查，真相令人驚心：這竟是駭客入侵的跡象。

排查思路：從參數修改到日誌分析

1. 常規修改無效

• Session 級別： SET max_allowed_packet = 20M; 僅影響當前連線，重連失效。
• Global 級別： SET GLOBAL max_allowed_packet = 20M; 重啟後恢復預設。
• 配置檔持久化： 修改 my.cnf 的 [mysqld] 區段設定 max_allowed_packet = 20M 並重啟，本以為大功告成，卻發現參數依然會自動變回 1024。

2. 開啟 General Log 還原真相

懷疑遭攻擊後，開啟 General Log 記錄所有 SQL 執行紀錄：

mysql> SET GLOBAL general_log = ON;

過濾關鍵字 max_allowed_packet：

tail -f /var/run/mysqld/mysqld.log | grep max_allowed_packet > 1.txt

日誌清晰記錄了惡意操作：

160804 8:59:41 172 Query SET GLOBAL max_allowed_packet=1024
172 Query SET GLOBAL max_allowed_packet=1024
173 Query SET GLOBAL max_allowed_packet=1024

3. 追蹤連線 ID 鎖定駭客行為

General Log 中的 172、173 為連線 ID。過濾該 ID 的完整操作發現：

connect root@someipaddress on ...
Query select 0x4D5A900..........(verylong)
Query select sys_exe('cmd /c c:/windows/nbvqc4.vbs') .........
set global max_allowed_packet 1024 ........

駭客從美國 IP 登入，利用 root/123456 弱密碼成功暴力破解，隨後下載並執行惡意腳本，修改安全參數。資料庫已確定被攻陷。

深度復盤：入侵路徑與安全漏洞

1. 內網資料庫為何暴露於公網？

早期為合作夥伴測試，網管將公網 IP 映射至該機器，導致 3306、22 等埠直接對外開放。

2. 駭客如何獲取帳密？

測試機使用極簡單密碼 root/123456，極易被字典撞庫破解。

3. 防火牆形同虛設

service iptables status 顯示 Firewall is not running，因測試不便曾關閉防火牆。

4. 入侵意圖分析

掃描開放埠 → 暴力破解 → 利用 MySQL 執行系統命令（下載腳本、提權執行） → 修改 max_allowed_packet=1024 導致業務報錯暴露蹤跡（推測為故意炫耀或測試控制權）。

登入失敗紀錄顯示大量嘗試：oracle, svn, apache, root 等常見帳號，來源 IP 為 217.76.78.35。

總結與防護建議

1. 網路隔離： 生產/測試環境嚴禁直接映射公網 IP，必須開啟防火牆，僅開放必要服務埠，其餘全部拒絕。
2. 最小權限原則： 避免使用 root 直連業務，建立專用業務帳號並授予最小權限；系統層面亦應限制 root 遠端登入。
3. 強密碼策略： 強制使用複雜密碼（大小寫、數字、特殊符號、長度），定期輪換。
4. 審計與監控： 開啟 General Log 或 Audit Plugin，定期分析登入紀錄（成功/失敗），設定異常登入告警（如短時間多次失敗自動封禁）。
5. 參數防篡改： 關鍵參數變更應納入變更管理，異常變更需觸發告警。

此次事件再次證實：Google 技術社區比百度更靠譜；日誌分析是溯源核心；資安意識不可鬆懈——駭客就在身邊，若非對方故意暴露，後果不堪設想。