測試環境1台centOS機器，最近一段頻繁報“
Caused by: com.mysql.jdbc.PacketTooBigException: Packet for query is too large (1354 > 1024). You can change this value on the server by setting the max_allowed_packet' variable
”， 記錄解決問題的思路，最終找到問題根源：黑客入侵，總結經驗。
查看max_allowed_packet ：
show global VARIABLES like '%max_allowed_packet%'; (注意：mysql 系統參數分為session和global 之分， session只當前連接生效，global 全局連接生效）
1）.通過mysql客戶端，set global max_allowed_packet = 2*1024*1024*10; （修改後，重啟數據庫會恢復為默認）
2）. 修改my.cnf 在[mysqld]段或者mysql的server配置段進行修改。（終極修改, 修改後重啟數據庫，永久生效）
如下: max_allowed_packet = 20M 通過方法2修改完成後，通過客戶端生效。 但發現，過一段時間（有時幾個小時，有時1~2天），自動變為1024。 思考：google 發現有說被黑客攻擊，本來不相信，因為是內網環境。無奈出現情況，越來越頻繁，剛更改後，過一會就變為1024。以下帖子給了啟發： http://stackoverflow.com/questions/28979660/why-mysql-max-allowed-packet-reset-to-1m-automatically mysql 有general_log, 會記錄所有執行的sql命令，因為耗費性能，默認是關閉。mysql> show variables like '%log%'; +-----------------------------------------+---------------------------------+ | Variable_name | Value | +-----------------------------------------+---------------------------------+ | back_log | 50 | | binlog_cache_size | 32768 | | binlog_direct_non_transactional_updates | OFF | | binlog_format | STATEMENT | | expire_logs_days | 0 | | general_log | OFF | | general_log_file | /var/run/mysqld/mysqld.log |
打開general_log:
mysql> set global general_log = ON;
查看general_log：
tail -f /var/run/mysqld/mysqld.log |grep max_allowed_packet （查看log，但打印大量實時sql操作）
tail -f /var/run/mysqld/mysqld.log |grep max_allowed_packet >1.txt （過濾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
160804 8:59:49 173 Query SET GLOBAL max_allowed_packet=1024
172 Query SET GLOBAL max_allowed_packet=1024
了解到general_log 日志中，172 為用戶連接Id（mysql 會對每一個連接分配唯一id），在全量general log中過濾id為172的操作如下：
（很遺憾，由於機器被攻擊，總監要求對機器進行系統還原，在寫日志時，log被刪除了），大概如下：
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 查詢到時美國的一個IP， 操作主要有：從某一網站，下載腳本，並執行；打開mysql相關安全參數，設置相關變量。
至此，非常確定mysql 數據庫被黑客攻擊了。
1. mysql部署在內網，外網如何訪問？
原來，之前便其它合作伙伴提供外網測試環境，讓網管把外網IP，影射到了此機器。導致通過公網IP直接訪問到了此台機器。
驗證：
1）. 通過外網IP, 使用mysql客戶端，可以直接連接到mysql服務。
2). 通過外網IP, 使用xshell 登陸成功。
2. 黑客怎麼知道了用戶名/密碼？
由於是測試機器，mysql使用了簡單了密碼（root/123456) , 被猜到，破解太容易了。
3. 防火牆呢？
由於開啟防火牆，在系統測試時，出現各種麻煩。就關閉了。service iptables status;
[root@bo bryant]# service iptables status; iptables: Firewall is not running. [root@bo bryant]#
4. 黑客是怎麼發現漏洞的，為什麼入侵目的？
猜測大概流程： 通過掃描軟件掃描公網ip， 測試到機器端口未關閉，如22，3306（應對1： 開啟防火牆，只開放服務端口，禁用其它端口外網訪問），嘗試暴力密碼登陸（應對策略2： 復雜密碼策略，可建立白名單，對於多次連接失敗，進行日志記錄和預警）。通過日志發現了，黑客主要操作為：在mysql中調用了系統命令（下載遠程文件，增加執行權限，並執行），打開相關安全參數。
查看機器登陸歷史及登陸失敗歷史，發現近段時間，有大量外網登陸失敗情況，如下圖中oracle, svn ,apache 用戶，黑客通過常用應用的用戶名/密碼在不停的嘗試登陸系統：
producti ssh:notty 217.76.78.35 Mon Aug 1 10:49 - 10:49 (00:00) producti ssh:notty 217.76.78.35 Mon Aug 1 10:49 - 10:49 (00:00) swsoft ssh:notty 217.76.78.35 Mon Aug 1 10:49 - 10:49 (00:00) swsoft ssh:notty 217.76.78.35 Mon Aug 1 10:49 - 10:49 (00:00) iraf ssh:notty 217.76.78.35 Mon Aug 1 10:49 - 10:49 (00:00) iraf ssh:notty 217.76.78.35 Mon Aug 1 10:49 - 10:49 (00:00) svn ssh:notty 217.76.78.35 Mon Aug 1 10:49 - 10:49 (00:00) svn ssh:notty 217.76.78.35 Mon Aug 1 10:49 - 10:49 (00:00) oracle ssh:notty 217.76.78.35 Mon Aug 1 10:49 - 10:49 (00:00) oracle ssh:notty 217.76.78.35 Mon Aug 1 10:49 - 10:49 (00:00) root ssh:notty 217.76.78.35 Mon Aug 1 10:49 - 10:49 (00:00) lab ssh:notty 217.76.78.35 Mon Aug 1 10:48 - 10:48 (00:00) lab ssh:notty 217.76.78.35 Mon Aug 1 10:48 - 10:48 (00:00) root ssh:notty 217.76.78.35 Mon Aug 1 10:48 - 10:48 (00:00) root ssh:notty 217.76.78.35 Mon Aug 1 10:48 - 10:48 (00:00) apache ssh:notty 217.76.78.35 Mon Aug 1 10:48 - 10:48 (00:00) apache ssh:notty 217.76.78.35 Mon Aug 1 10:48 - 10:48 (00:00) root ssh:notty 217.76.78.35 Mon Aug 1 10:48 - 10:48 (00:00) root ssh:notty 217.76.78.35 Mon Aug 1 10:48 - 10:48 (00:00) root ssh:notty 217.76.78.35 Mon Aug 1 10:48 - 10:48 (00:00)
5. 黑客為什麼要修改 max_allowed_packet 1024 ?
修改了max_allowed_packet =1024，將導致所有數據操作，如果返回結果>1024，將報錯。 修改此參數，很容易讓用戶發現數據問題，推測是駭客是故意暴露自己，也許只為了炫耀一下。
1. 再次證明在遇到復雜技術問題google 比百度要靠譜多
2. 日志分析是解決問題的必須途徑
3. 增加信息安全意識，原來黑客離我們並不遠，如果不是故意暴露自己，我們也不會發現此機器被黑，黑客控制此機器後，可以輕易使用此機器，進行相關非法活動。
具體：
1. 外網機器，一定要開啟防火牆，只開放提供服務端口，禁用其它端口。 制定相關安全策略，如記錄登陸用戶ip，定期查看登陸用戶歷史及登陸失敗記錄，對於反復登陸能拒絕登陸。
2. 系統用戶名，應該根據需要確定是否使用root用戶，具體業務最好使用普通用戶權限。因為root用戶，擁有系統系統的全部權限。
3.密碼：用戶密碼一定不要使用簡單密碼，最好使用密碼生成器生成負責密碼（大小寫，特殊字符，長度）
4. 數據安全：
mysql應該給不同業務創建不同用戶，並賦予有限功能權限，禁止root 用戶做業務操作。
