联盟网站疑似遭黑客攻击，性能异常请求技术支援

Alright, let’s break this down step by step—you’ve got two intertwined issues here: potential malicious traffic targeting that product.php URL, and cascading performance problems that are breaking core site functionality. Let’s tackle them one by one, starting with the suspected attack since it’s likely driving many of your performance headaches.

The repeated hits to http://www.example.com/product.php?category=study-materials&id=S... are a red flag—this looks like either a vulnerability scan (looking for SQL injection, XSS, or other flaws) or a brute-force attempt. Here’s how to shut it down:

• Block the offending traffic immediately
  • Pull your server access logs (usually in /var/log/apache2/access.log or /var/log/nginx/access.log) to identify the IP(s) or user agents making these repeated requests.
  • Use .htaccess (for Apache) or Nginx config to block the malicious IPs:

    # Apache example: Block a specific IP from accessing the suspicious URL
    RewriteEngine On
    RewriteCond %{QUERY_STRING} category=study-materials&id=S [NC]
    RewriteCond %{REMOTE_ADDR} ^192\.168\.1\.100$ # Replace with the malicious IP
    RewriteRule ^ - [F,L]
    

  • For broader protection, enable rate limiting (e.g., Cloudflare’s rate limiting rules, or ModSecurity) to restrict how often any single IP can hit that URL.
• Audit the product.php script for vulnerabilities
  Those query parameters (category and id) are prime targets for SQL injection. Check if the script is properly sanitizing user input—always use prepared statements for database queries instead of concatenating user input directly into SQL strings. Fixing any vulnerabilities here will prevent attackers from exploiting the URL to wreak further havoc (like crashing your database).

Your load times, blank data tables, and failed Cron tasks are almost certainly side effects of the malicious traffic overwhelming your server or database. Let’s resolve each:

• Diagnose slow load times
  • Use htop or top to check server CPU/memory usage—if it’s maxed out, blocking the malicious traffic should immediately free up resources.
  • Check your database for stuck or slow queries: Run SHOW PROCESSLIST; in MySQL/MariaDB to spot long-running queries (often from malicious injection attempts). Add indexes to the tables used by product.php (e.g., on category and id columns) to speed up legitimate queries.
• Fix blank data tables
  • Check your PHP error log (usually /var/log/php/error.log) and server error log for clues—common issues include database connection failures, query errors, or PHP fatal errors that stop output.
  • If the database was overwhelmed, restart the database service and test if tables load again. If queries are returning empty, verify that the underlying data is intact and that your scripts aren’t filtering out results accidentally.
• Troubleshoot failed Cron tasks
  • Check your Cron logs (e.g., /var/log/cron or /var/log/syslog) to see why tasks are failing—common causes include insufficient server resources (Cron can’t spawn processes when CPU/memory is full), database connection issues, or file permission problems.
  • Once you’ve fixed the resource bottlenecks, re-run the failed Cron tasks manually to confirm they work, and adjust task timing if needed to avoid peak traffic periods.

To avoid repeating this mess:

• Set up a Web Application Firewall (WAF)：Tools like ModSecurity (self-hosted) or Cloudflare WAF will automatically block common attack patterns (SQL injection, XSS, etc.) before they reach your server.
• Enable continuous log monitoring：Use tools like Fail2ban to auto-block IPs that repeatedly trigger suspicious requests, or set up alerts for unusual traffic spikes.
• Keep your scripts updated：Patch any outdated PHP scripts, plugins, or dependencies to close known vulnerabilities.
• Regularly audit your database：Clean up old data, optimize tables, and ensure indexes are maintained to keep queries fast even under load.

内容的提问来源于stack exchange，提问作者user7011444