网站遭恶意篡改：index.php被植入恶意代码、.htaccess被替换，求助攻击追踪及.htaccess防护优化方案

Sorry to hear your site’s been targeted by this persistent attack—let’s break down how to track the source and harden your defenses with a more robust .htaccess configuration.

First, let’s pinpoint where this is coming from:

• Check server access/error logs: Your Apache logs (usually at /var/log/apache2/access.log and /var/log/apache2/error.log) hold key clues. Look for:
  • Unusual POST requests to index.php around the time the file was modified (use stat index.php to get the modification timestamp, then grep logs for that time window).
  • Requests with suspicious user agents, query strings, or IP addresses. Try commands like:

    grep "index.php" /var/log/apache2/access.log | grep -i post
    grep "curl" /var/log/apache2/error.log
    

• Review PHP logs: If you have PHP error logging enabled, check for entries showing unexpected curl_setopt calls or script execution from unknown sources.
• Verify file permissions: Attackers often exploit overly permissive files (e.g., index.php set to 777). Run ls -l index.php to check—permissions should ideally be 644 for files, 755 for directories.
• Scan for backdoors: Look for unknown PHP files in your web root (especially upload directories) or modified core files beyond index.php. Tools like find . -name "*.php" -mtime -7 can help spot recently changed files.
• Check FTP/SFTP logs: If you use FTP to manage files, verify there are no unauthorized login attempts or file modification entries from unknown IPs.

Your existing rules are a good start, but let’s add more layers to block common attack vectors:

First: Clean Up and Secure Core Files #

Before adding new rules, restore your original index.php (remove the malicious curl code) and ensure your .htaccess isn’t writable by the web server user (set permissions to 644).

Add These Enhanced Rules #

a. Restrict PHP Execution to Trusted Directories

Prevent attackers from executing PHP in uploads or other non-essential folders:

# Deny PHP execution everywhere by default
<FilesMatch "\.php$">
    Order Deny,Allow
    Deny from all
</FilesMatch>

# Allow PHP only in your main web directory (adjust path if needed)
<Directory "/home/youruser/public_html">
    <FilesMatch "\.php$">
        Order Allow,Deny
        Allow from all
    </FilesMatch>
</Directory>

# Block PHP execution in uploads directory
<Directory "/home/youruser/public_html/uploads">
    <FilesMatch "\.(php|php5|phtml|php7)$">
        Order Deny,Allow
        Deny from all
    </FilesMatch>
    # Block double extensions like .php.jpg
    RewriteEngine On
    RewriteRule ^(.+)\.php$ - [F,L]
    RewriteRule ^(.+)\.php\.(.+)$ - [F,L]
</Directory>

b. Block Malicious Query Strings and Functions

Add to your existing rewrite rules to block requests containing PHP exploit functions:

<IfModule mod_rewrite.c>
    RewriteEngine On

    # Block requests with malicious PHP functions
    RewriteCond %{QUERY_STRING} (curl_exec|eval|base64_decode|passthru|exec|system|shell_exec|phpinfo) [NC]
    RewriteRule ^(.*)$ - [F,L]

    # Block more aggressive scraper/exploit user agents
    RewriteCond %{HTTP_USER_AGENT} (sqlmap|nmap|w3af|acunetix|nessus|scraper|harvester) [NC]
    RewriteRule ^(.*)$ - [F,L]

    # Block requests attempting to access sensitive system files
    RewriteCond %{QUERY_STRING} (/etc/passwd|/proc/self/environ|/dev/null) [NC]
    RewriteRule ^(.*)$ - [F,L]
</IfModule>

c. Strengthen HTTP Method Restrictions

Extend your existing rule to block PUT (often used to upload malicious files):

# Block all non-essential HTTP methods
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK|DEBUG|PUT) [NC]
RewriteRule ^(.*)$ - [F,L]

d. Limit Request Frequency

Prevent brute-force or automated attacks by restricting requests per IP (adjust limits based on your site’s traffic):

<IfModule mod_ratelimit.c>
    # Limit to 100 requests per hour per IP
    RATE_LIMIT 100/hour
</IfModule>

# Alternative with mod_rewrite if mod_ratelimit isn't available
<IfModule mod_rewrite.c>
    RewriteCond %{REMOTE_ADDR} ^(.*)$
    RewriteCond %{ENV:REDIRECT_STATUS} ^$
    RewriteRule ^(.*)$ - [E=IPCOUNT:%1]
    RewriteCond %{ENV:IPCOUNT} ^(.*)$
    RewriteCond %{TIME_HOUR} ^(.*)$
    RewriteRule ^(.*)$ - [E=IPCOUNT:%1:%{TIME_YEAR}%{TIME_MON}%{TIME_DAY}%1]
    RewriteCond %{ENV:IPCOUNT} ^(.*):(.*)$
    RewriteCond %{REQUEST_URI} !^/robots\.txt$
    RewriteRule ^(.*)$ - [E=COUNT:%{ENV:IPCOUNT}]
    # Block if more than 150 requests per hour
    RewriteCond %{ENV:COUNT} ^(.*):(.*)$
    RewriteCond %{REQUEST_URI} !^/status\.php$
    RewriteRule ^(.*)$ - [F,L]
</IfModule>

e. Secure Hidden Files and Directories

Add protection for version control directories and other sensitive hidden files:

# Protect .htaccess, .git, .svn, etc.
<FilesMatch "^\.(ht|git|svn|hg)$">
    Order Allow,Deny
    Deny from all
    Satisfy All
</FilesMatch>

Critical Additional Steps #

• Upgrade PHP: You’re using PHP 5.6, which is end-of-life and full of unpatched vulnerabilities. Upgrade to at least PHP 7.4 (or newer) immediately—this will eliminate most attack vectors targeting old PHP versions.
• Update all software: If you’re using a CMS (WordPress, Joomla, etc.), update the core, themes, and plugins to their latest versions.
• Change all passwords: Reset FTP/SFTP, database, and server control panel passwords with strong, unique combinations.
• Consider a WAF: A Web Application Firewall (like ModSecurity on your server or a cloud-based WAF) can block many attacks before they reach your site.

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