First, check the firewall. If the website has no special port requirements, just open 80. Like 3306, 22, etc., only the company's internal network can be accessed.
Second, change all passwords for database, backend, etc. (the password should be longer, uppercase and lowercase, and have special symbols).
Third, if the backend only needs to be accessible by the company, try to hide the URL as much as possible. Also do a test (i.e., only allow the company’s network to be accessed in the background)
Fourth, if there is a member registration at the front desk, make sure there is a verification code and security check (that is, for the same IP, there must be a gap in the time between member registrations)
Make sure that after completing the above, let the programmer check the system logs, database logs, program logs... and whether there are any loopholes in the program code
It may be a SQL injection attack. Even if you change the SQL password, you still need to configure the correct password in the production environment. If you don’t modify the SQL vulnerability, he can still inject some data and replace all SQL statements with PDO:: Write the prepare parameter binding method, and then observe whether the problem is solved. In addition, if the system is used internally, it should not be opened to the external network and accessed through internal IP.
Bind Baidu Cloud Observation. Then the database account must be bound to IP Sql injection and check to see if there is some form that has not been processed
It would be much better to add a verification, but some also do verification identification, then you can also do IP restrictions. If an IP operates too frequently, limit the operation of this IP! Of course, experts can also keep changing IP attacks, it depends on how valuable your website is!
We were also attacked. The SMS sending interface was constantly requested without verification before, which directly caused our SMS service to become unusable
First, check the firewall. If the website has no special port requirements, just open 80. Like 3306, 22, etc., only the company's internal network can be accessed.
Second, change all passwords for database, backend, etc. (the password should be longer, uppercase and lowercase, and have special symbols).
Third, if the backend only needs to be accessible by the company, try to hide the URL as much as possible. Also do a test (i.e., only allow the company’s network to be accessed in the background)
Fourth, if there is a member registration at the front desk, make sure there is a verification code and security check (that is, for the same IP, there must be a gap in the time between member registrations)
Make sure that after completing the above, let the programmer check the system logs, database logs, program logs... and whether there are any loopholes in the program code
Add a verification code when registering!
Get your database address + account number + password directly, and then directly operate your database. See, is it easier?
Check the operation log of mysql, if it is not enabled, enable it and wait.
It may be a SQL injection attack. Even if you change the SQL password, you still need to configure the correct password in the production environment. If you don’t modify the SQL vulnerability, he can still inject some data and replace all SQL statements with PDO:: Write the prepare parameter binding method, and then observe whether the problem is solved. In addition, if the system is used internally, it should not be opened to the external network and accessed through internal IP.
Bind Baidu Cloud Observation. Then the database account must be bound to IP
Sql injection and check to see if there is some form that has not been processed
It would be much better to add a verification, but some also do verification identification, then you can also do IP restrictions. If an IP operates too frequently, limit the operation of this IP! Of course, experts can also keep changing IP attacks, it depends on how valuable your website is!
Check the mysql log and see the operation records
Check the log first to determine where the writing point is.
Is your database isolated?
We were also attacked. The SMS sending interface was constantly requested without verification before, which directly caused our SMS service to become unusable