Хакнат WordPress сайт – стъпки за почистване, диагностика и защита след пробив

Какво се случва при компрометиран WordPress

Зловреден код рядко изтрива данни. В 95% от случаите атакуващите искат трафик – пренасочват посетители, инжектират pharma спам или добавят скрити линкове за SEO манипулация. Базата данни с публикации, страници и потребители обикновено остава непокътната. Самият WordPress разделя съдържание (MySQL) от приложение (PHP файлове, плъгини, теми), което дава възможност за хирургично почистване без загуба на контент.

Хакерите оставят backdoor файлове, за да си гарантират повторен достъп дори след смяна на пароли.

Първи действия – изолация и достъп

Спрете публичния достъп до сайта още преди да започнете диагностика. Най-бързият начин е чрез .maintenance файл в root директорията или чрез .htaccess правило, което блокира всички IP адреси освен конкретния:

order deny,allow
deny from all
allow from 123.45.67.89

Сменете паролите на четири места едновременно – WordPress admin, FTP/SFTP, cPanel/Plesk и MySQL потребителя. Ако хостинг доставчикът предлага server-level backups за последните 7-30 дни, поискайте копие веднага – дори и да не го използвате за restore, то служи като референтна точка за сравнение.

SSH диагностика – намиране на заразени файлове

SSH достъпът превръща часове ръчна работа в минути. Следната команда показва всички PHP файлове, променени през последните 3 дни:

find /var/www/html -type f -name '*.php' -ctime -3

PHP файлове в wp-content/uploads са почти гарантирана индикация за backdoor. Тази директория съдържа само медийни файлове и не би трябвало да има нито един .php скрипт:

find wp-content/uploads -name "*.php" -print

За откриване на обфускиран зловреден код, който използва eval(base64_decode(...)), стартирайте grep рекурсивно:

grep -lr --include=*.php "eval(base64_decode" /var/www/html

Резултатът е списък с инфектирани файлове. Проверете ръчно първите 2-3, за да потвърдите шаблона. Ако зловредният ред стои в началото на PHP файла (преди легитимния код), правилната стратегия за защита включва автоматизирано почистване с sed:

grep -lr --include=*.php "eval(base64_decode" /var/www/html | xargs sed -i 's/<?php eval(base64_decode[^;]*;//g'

Почистване на WordPress core файловете

Заменете core файловете с чисти копия. WP-CLI прави процеса тривиален – свалете същата версия, презапишете всичко освен wp-content и wp-config.php:

wp core download --version=6.7 --skip-content --force

Плъгините и темите изискват индивидуален подход. Изтрийте напълно директорията на всеки плъгин и инсталирайте наново от WordPress.org или от оригиналния източник. Не се опитвайте да "поправяте" инфектиран плъгин файл по файл – в един ZIP архив от repository всичко е гарантирано чисто.

Неактивните теми са любимо скривалище за backdoor файлове. Изтрийте всяка тема, която не е в активна употреба, включително default темите twentytwentythree и twentytwentyfour, ако не ги използвате.

Инспекция и почистване на базата данни

Malware в базата понякога е по-опасен от файловите инфекции, защото скенерите на ниво файлова система го пропускат. Свържете се през phpMyAdmin или директно с MySQL CLI и търсете типични индикатори:

SELECT ID, post_title, post_date
FROM wp_posts
WHERE post_content LIKE '%<iframe%'
   OR post_content LIKE '%eval(%'
   OR post_content LIKE '%base64_decode%'
ORDER BY post_date DESC;

Проверете таблица wp_users за непознати администратори:

SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON u.ID = m.user_id
WHERE m.meta_key = 'wp_capabilities'
  AND m.meta_value LIKE '%administrator%'
ORDER BY u.user_registered DESC;

Ако откриете потребител, създаден след датата на предполагаемия пробив, изтрийте го. Съществува вариант на backdoor от 2025 г., който автоматично пресъздава изтрит admin акаунт чрез скрит PHP файл (обикновено wp-user.php или подобен в root директорията). Затова първо почистете файловете, после – базата.

Таблицата wp_options също заслужава внимание. Търсете модифицирани стойности в siteurl, home и active_plugins:

SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl', 'home', 'active_plugins');

Смяна на тайните ключове и salt стойностите

Файлът wp-config.php съдържа осем криптографски ключа (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY и т.н.). Смяната им анулира всички активни сесии – включително евентуална сесия на атакуващия. Генерирайте нови стойности от официалния API на WordPress:

curl -s https://api.wordpress.org/secret-key/1.1/salt/

Копирайте резултата и заменете съответния блок в wp-config.php. Тази стъпка принуждава всички потребители да влязат отново, което е желано поведение след пробив.

Сканиране с плъгин за потвърждение

Ръчното почистване покрива повечето случаи, но автоматизиран скенер засича patterns, които grep не разпознава. Wordfence сравнява всеки файл с оригинала от WordPress.org и маркира разликите. Стартирайте High Sensitivity сканиране – то отнема повече време, но открива обфускирани backdoor-и, скрити в легитимни cookie файлове или в mu-plugins директорията.

Sucuri SiteCheck пък работи отвън – проверява публично достъпния HTML за инжектирани script тагове и iframe елементи, без да се нуждае от достъп до сървъра.

Заявка за ревю пред Google

Google Search Console показва активни предупреждения в секция Security Issues. След пълно почистване подайте заявка за ревю директно оттам. Стандартното време за обработка е 24-72 часа. Ако сайтът попадне в категория Repeat Offender, влиянието върху класирането е по-тежко – Google налага 30-дневен период преди следващо ревю.

Междувременно проверете и Bing Webmaster Tools. Bing има собствена система за blacklisting и не синхронизира статуса с Google автоматично.

Hardening след почистването

Деактивирайте XML-RPC, ако не го използвате – той е вектор за brute-force атаки. Добавете в .htaccess:

order deny,allow
  deny from all

Задайте правилни файлови права – 644 за файлове, 755 за директории, 600 за wp-config.php. Тази конфигурация не позволява PHP процесът да модифицира файлове, които не му принадлежат:

find /var/www/html -type f -exec chmod 644 {} ;
find /var/www/html -type d -exec chmod 755 {} ;
chmod 600 /var/www/html/wp-config.php

Забранете изпълнението на PHP в wp-content/uploads чрез допълнителен .htaccess файл в тази директория:

deny from all

Активирайте двуфакторна автентикация за всички admin акаунти. Плъгините за контактни форми също се нуждаят от актуализация, тъй като остарели версии понякога съдържат уязвимости за file upload.

Автоматизирани бекъпи като застраховка

Без бекъп целият процес по-горе е единственият изход. С ежедневен бекъп – restore отнема 15 минути вместо 4 часа. Конфигурирайте автоматични бекъпи, които се съхраняват извън сървъра – на облачно хранилище (S3, Google Drive) или на отдалечен FTP. Плъгини като UpdraftPlus поддържат scheduled backups с off-site storage.

Винаги тествайте restore процеса поне веднъж. Бекъп, който не може да се възстанови, е безполезен. Ако сайтът работи на споделен хостинг, проверете дали доставчикът предлага cPanel Backup Wizard или JetBackup – тези инструменти генерират full account backups, включително бази данни, email акаунти и DNS зони.

Мониторинг за повторна инфекция

Следващите 14 дни след почистването са критични. Настройте Wordfence да изпраща email при промяна на core файлове или при логин от непознат IP. Добавете uptime мониторинг (UptimeRobot, Hetrix Tools) с проверка на HTTP status code – ако сайтът внезапно върне 302 redirect, това може да означава нова инжекция в .htaccess.

Cron job за периодична проверка на файлови промени е допълнителна мрежа за сигурност:

find /var/www/html -type f -name '*.php' -newer /tmp/last_check_marker -print
touch /tmp/last_check_marker

Скриптът записва timestamp и при следващото изпълнение показва само файловете, променени след последната проверка. Ако URL структурата на сайта е била манипулирана по време на пробива, направете 301 redirect от фалшивите URL-и към оригиналните страници, за да предотвратите 404 грешки и загуба на SEO стойност.

Често задавани въпроси