Background:
1 centOS machine in the test environment, recently reported "
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
”, record the idea of solving the problem, and finally find the root cause of the problem: Hacking, sum up experience.
Ideas:
View max_allowed_packet:
show global VARIABLES like '%max_allowed_packet%'; (Note: mysql system parameters are divided into session and global, session only takes effect on the current connection, and global global connection takes effect)
1). Through the mysql client, set global max_allowed_packet = 2*1024*1024*10; (after modification, restarting the database will return to the default)
2). Modify my.cnf and modify it in the [mysqld] section or the server configuration section of mysql. (Ultimate modification, restart the database after modification, it will take effect permanently)
As follows: max_allowed_packet = 20M
After the modification is completed through method 2, it will take effect through the client. But found that after a period of time (sometimes a few hours, sometimes 1~2 days), it will automatically change to 1024.
Thinking: Google found out that it was hacked, but I didn't believe it because it was an intranet environment. Unfortunately, the situation became more and more frequent. After the change, it became 1024 after a while. The following post gave inspiration:
http://stackoverflow.com/questions/28979660/why-mysql-max-allowed-packet-reset-to-1m-automatically
mysql has general_log, which will record all executed sql commands, because it costs performance , the default is off.
Copy code
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 |
Copy code
Open general_log:
mysql> set global general_log = ON;
view general_log:
tail -f /var/run/mysqld/mysqld.log |grep max_allowed_packet (look at the log, but print a lot of real-time sql operations)
tail -f /var/run/mysqld/mysqld.log |grep max_allowed_packet >1.txt (filter max_allowed_packet, and output to file 1.txt)
Sure enough, the following modifications were found:
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
It is understood that in the general_log log, 172 is the user connection id (mysql will assign a unique id to each connection). The operation of filtering the id of 172 in the full general log is as follows:
(Unfortunately, because the machine was attacked, the director asked for a system restore of the machine. When writing the log, the log was deleted), which is roughly as follows:
connect root@someipaddress on
Query select 0x4D5A900……….(verylong)
Query select sys_exe('cmd /cc:/windows/nbvqc4.vbs')
…………
set global max_allowed_packet 1024
…….. The
time from the login ip query to the United States The main operations are: download the script from a certain website, and execute it; open the mysql related security parameters, and set the related variables.
At this point, it is very sure that the mysql database has been hacked.
Questions:
1. MySQL is deployed on the intranet, how can I access it from the extranet?
It turned out that other partners had provided an external network test environment before, so that the network administrator could map the external network IP to this machine. This leads to direct access to this machine through the public IP.
verify:
1). Through the external network IP, using the mysql client, you can directly connect to the mysql service.
2). Through the external network IP, use xshell to log in successfully.
- How did the hacker know the username/password?
Since it is a test machine, mysql uses a simple password (root/123456), which is guessed and too easy to crack.
What about the firewall?
Due to the opening of the firewall, various troubles occurred during the system test. just closed. service iptables status;
[root@bo bryant]# service iptables status;
iptables: Firewall is not running.
[root@bo bryant]#
4. How did the hacker find the loophole, and what was the purpose of the intrusion?
Guess the approximate process: Scan the public network ip through the scanning software, test that the machine port is not closed, such as 22, 3306 (response 1: open the firewall, only open the service port, disable other ports for external network access), try brute force password login (response strategy 2: Complex password policy, whitelist can be established, logging and early warning for multiple connection failures). Through the log, it was found that the main operation of the hacker is: calling the system command in mysql (downloading the remote file, increasing the execution authority, and executing), and opening the relevant security parameters.
Check the login history and login failure history of the machine, and find that there have been a lot of failures to log in to the external network in the recent period, such as the oracle, svn, and apache users in the following figure.
复制代码
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
)
- Why do hackers modify max_allowed_packet 1024 ?
Modified max_allowed_packet = 1024, which will cause all data operations. If the return result > 1024, an error will be reported. By modifying this parameter, it is easy for users to find data problems. It is speculated that the hacker exposed himself deliberately, perhaps just to show off.
Summary:
1. It proves once again that Google is more reliable than Baidu when encountering complex technical problems
Log analysis is a necessary way to solve the problem
Increase the awareness of information security. It turns out that hackers are not far away from us. If we did not deliberately expose ourselves, we would not find that this machine was hacked. After hackers control this machine, they can easily use this machine to carry out related illegal activities.
specific:
For external network machines, be sure to open the firewall, only open service ports, and disable other ports. Formulate relevant security policies, such as recording the login user ip, regularly checking the login user history and login failure records, and denying login for repeated logins.
System user name, you should determine whether to use the root user according to your needs. It is best to use ordinary user rights for specific services. Because the root user has all the permissions of the system system.
3. Password: The user password must not use a simple password, it is best to use a password generator to generate a responsible password (case, special characters, length)
- Data Security:
MySQL should create different users for different businesses, and grant limited functional permissions, prohibiting root users from doing business operations