Над 40% от интернет работи на WordPress. Това го прави най-сканираната платформа в мрежата — ботове обхождат сайтове денонощно и търсят познати пропуски, без да ги интересува дали сте голям магазин или блог с двайсет посетителя на ден.
Самият WordPress рядко е проблемът. Ядрото се развива активно и получава редовни поправки. Пробивите идват от друго: остаряла версия на PHP, необновени плъгини и теми, слаби пароли, хостинг без изолация между акаунтите.
Тази статия минава през това как реално става пробивът, как да разберете, че вече сте засегнати, и какво да направите, за да не стигнете дотам.
Как става пробивът
Уязвими плъгини
Около 90% от компрометираните WordPress сайтове са пострадали заради плъгин, не заради ядрото.
Причините се повтарят: качване на файлове без проверка на типа, AJAX заявки без контрол на правата, липсваща nonce верификация, необработен вход от потребителя. Веднъж публикувана, една такава уязвимост става известна и автоматизирани ботове започват да я търсят из мрежата в рамките на часове.
Какво получава нападателят: възможност да качи файл, да инсталира web shell, да си създаде скрит администраторски акаунт. Оттам нататък сайтът е негов.
Brute force атаки
Най-простият метод и все още един от най-успешните. Ботът обстрелва /wp-login.php и /xmlrpc.php с хиляди комбинации в минута.
Ако няма ограничение на опитите и няма двуфакторна автентикация, рано или късно едно от предположенията ще е вярно. Резултатът е компрометиран акаунт, през който се внедрява зловреден код, изпращат се имейли от ваше име или се изнасят данни.
XML-RPC експлойти
XML-RPC е стар протокол за отдалечено управление на WordPress. Полезен е, ако ползвате мобилното приложение или свързвате външни услуги. В останалите случаи е отворена врата.
Позволява масови опити за вход в една заявка — тоест ускорява brute force атаката многократно. А функцията pingback може да се използва за DDoS усилване, при което вашият сайт става инструмент за атака срещу друг.
Ако не го използвате, изключете го.
Cross-Site Scripting (XSS)
Внедряване на зловреден JavaScript в страница, който се изпълнява в браузъра на посетителя. Оттам се крадат бисквитки и сесии, пренасочва се трафик, добива се криптовалута с чуждия процесор или се подменя съдържание.
По-опасният вариант е persistent XSS — кодът се записва в базата данни и се изпълнява при всяко зареждане, докато някой не го намери.
SQL Injection
Когато заявките към базата не са правилно филтрирани, нападателят може да вмъкне собствен SQL код. Оттам се извличат данни, променя се администраторски акаунт или се трие съдържание.
Рискът расте рязко при стара версия на PHP в комбинация с уязвим плъгин.
Защо старата версия на PHP влошава всичко
Остарялата PHP версия няма съвременните механизми за защита на паметта, липсват ѝ актуалните криптографски функции и — най-важното — вече не получава поправки за сигурност.
Тоест дори WordPress и всички плъгини да са обновени, средата отдолу остава уязвима. Всяка известна дупка в старата версия си стои отворена завинаги.
Проверете коя версия ползвате: в администрацията, Tools → Site Health. Повече за рисковете от старите PHP версии
Плъгините отблизо
Щом плъгините са причина за девет от всеки десет пробива, си струва да се разгледат отделно.
Всеки плъгин има достъп до файловата система, изпълнява PHP код, работи с базата данни и често разполага с администраторски права. Компрометиран плъгин означава компрометиран сайт — няма междинно състояние.
Как изглеждат опасните плъгини
Най-често се представят за безплатна версия на платен плъгин. Изтегляте „Pro” версия от сайт, който не е официалното хранилище, и получавате работеща функционалност плюс скрит код.
Втори вариант: клонинг на популярен плъгин с леко променено име. Един символ разлика, същата икона, същото описание.
Трети: истински плъгин, който отдавна не се поддържа, с публично известна уязвимост.
Скритият код обикновено създава задна врата, вкарва спам линкове, пренасочва трафик или добавя администраторски акаунт, за който не знаете.
Пет признака, че плъгинът е рисков
Обновяван е за последно преди месеци или години.
Има малко активни инсталации и никакви отзиви.
В отзивите се споменават инфекции, счупени сайтове или странно поведение.
Иска права, които нямат нищо общо с функцията му — плъгин за галерия, който настоява за достъп до потребителските акаунти.
Не се изтегля от официалното хранилище на WordPress или от сайта на утвърден разработчик.
Как да разберете, че сайтът вече е компрометиран
Пробивът рядко е шумен. Нападателят има интерес да остане незабелязан възможно най-дълго.
Шест сигнала, които си струва да приемете сериозно:
Сайтът се зарежда осезаемо по-бавно без обяснима причина.
Появяват се реклами, които не сте слагали.
В списъка с потребители има администраторски профил, който не познавате.
Google показва предупреждение за сигурност при отваряне.
Трафикът пада рязко за няколко дни.
Посетители съобщават, че сайтът ги пренасочва другаде — често само от мобилни устройства или само при идване от търсачка.
Какво се случва след пробива
Последствията са по-скъпи от самото почистване.
Най-често сайтът се използва за SEO спам — вкарват се скрити страници и линкове към казина, фалшиви аптеки или пиратски софтуер. Има и характерен вариант, при който в Google се появяват страници на японски, познат като japanese keyword hack.
Друг сценарий е фишинг: на вашия домейн се качва фалшива страница за вход в банка или пощенска услуга. Домейнът ви е този, който носи доверие, и това го прави ценен.
При всички варианти рискувате Google да маркира сайта като опасен. Възстановяването от такъв статус отнема седмици — първо чистене, после заявка за преразглеждане, после чакане. Междувременно органичният трафик е практически нула.
Как да защитите сайта
Няма една мярка, която да реши всичко. Има набор от мерки, всяка от които затваря по един път за влизане.
Обновете PHP до последна поддържана версия. Това е най-голямата печалба за най-малко усилие. Проверява се от Tools → Site Health, а смяната обикновено става с едно превключване в хостинг панела.
Силни пароли и двуфакторна автентикация. Дълга парола с малки и главни букви, цифри и знаци. Никакви admin потребители и никакви пароли, използвани и другаде. Двуфакторната автентикация прави откраднатата парола безполезна сама по себе си. Как се създава сигурна парола
Ограничете опитите за вход. След пет неуспешни опита адресът се блокира. Това само по себе си спира почти всички автоматизирани атаки.
Изключете XML-RPC, ако не го използвате. Прави се от хостинг панела.
Обновявайте ядрото, темите и плъгините редовно. Повечето обновления съдържат поправки за сигурност. Отлагането им е самото уязвимо състояние.
Изтривайте неизползваните плъгини и теми. Деактивираният плъгин остава на сървъра и остава уязвим. Деактивирането не е изтриване.
Правете редовни архиви и ги пазете извън сървъра. Архив на същата машина не е архив — ако компрометират сървъра, компрометират и него. Какво е backup и как се прави правилно
SSL сертификат. Криптира връзката между посетителя и сайта. Задължителен е и за доверието, и за класирането в Google. Как се активира безплатен SSL
Web Application Firewall. Филтрира зловредните заявки, преди да стигнат до приложението. Imunify360 в действие
Хостинг, който върши част от работата вместо вас. Изолация между акаунтите, автоматични обновления, наблюдение и реакция при инцидент. При споделен хостинг това е разликата между „съседът беше хакнат” и „аз бях хакнат”. WordPress хостинг със защита · Комплексна защита на сайта
Ако сайтът вече е хакнат
Редът има значение.
Първо свалете сайта офлайн или го сложете в режим на поддръжка. Всяка минута онлайн е още посетители, изложени на зловредния код, и още сигнали към Google.
Направете пълен архив — файлове и база данни. Дори заразени. Ще ви трябват, за да разберете какво се е случило, и за да имате към какво да се върнете, ако чистенето отиде в грешна посока.
Сканирайте за зловреден код с инструмент за сигурност. Търсете и в базата данни, не само във файловете.
Сменете всички пароли — администраторски акаунти, база данни, FTP, cPanel, хостинг акаунт. Всички, не само тези, които изглеждат засегнати.
Премахнете непознатите акаунти и проверете дали няма планирани задачи, които не сте създавали.
Обновете ядрото, темите и плъгините до последни версии. Изтрийте всичко, което не използвате.
Чак тогава пуснете сайта обратно и подайте заявка за преразглеждане в Search Console, ако Google го е маркирал.
Ако някоя от тези стъпки ви се струва рискована — по-добре потърсете помощ, отколкото да чистите наслуки. Непълното почистване връща проблема след седмица.
| Тип атака | Какво прави | Основна причина |
|---|---|---|
| Уязвими плъгини | Позволяват качване на злонамерен код или достъп до системата. | Неактуализирани версии на плъгини. |
| Brute Force | Позволява налучкване на потребителско име и парола чрез автоматизирани опити. | Слаби пароли или липса на защита при вход. |
| XML-RPC атаки | Използват XML-RPC за масови заявки или DDoS усилване. | Активирана XML-RPC функционалност без защита. |
| Cross-Site Scripting (XSS) | Инжектира злонамерен JavaScript код в страниците. | Липса на валидиране на потребителски вход. |
| SQL Injection | Манипулира базата данни чрез уязвими заявки. | Стара PHP версия или уязвим код в плъгини. |
Как старата PHP версия влошава ситуацията?
Старата PHP версия не е директна причина за всяка атака, но тя значително увеличава риска.
Причините включват:
- Липса на съвременни механизми за типова сигурност
- По-слаба защита срещу memory corruption уязвимости
- Остарели криптографски функции
- Липса на security пачове
С други думи, когато инфраструктурата е остаряла, експлоатирането на уязвимост става по-лесно и по-бързо.
Какво се случва след пробива?
След успешна атака последствията често са видими почти веднага:
- SEO spam и скрито съдържание
- Т.нар. “Japanese keyword hack”
- Създаване на фишинг страници
- Пренасочване към казино или malware сайтове
- Blacklist от Google и браузърите
Освен техническия проблем, започва и процес на възстановяване, който може да отнеме седмици.
WordPress сам по себе си не е проблемът. Проблемът е липсата на поддръжка, остарелите версии и пренебрегването на сигурността. В комбинация със стара PHP версия рискът нараства значително.
Свързани статии в блога
- Често срещани заплахи за сигурността на сайта — SQL инжекции, XSS, CSRF, DDoS и фишинг, обяснени за всеки сайт, не само за WordPress.
- Най-честите грешки при разработка на WordPress сайт — твърде много плъгини, липса на staging среда и още пет капана, в които се пада редовно.
- Защо старите PHP версии са реална заплаха — какво губите, когато средата под сайта спре да получава поправки.
Често задавани въпроси
Какво означава „хакнат WordPress сайт"?
Това, че някой е получил неоторизиран достъп и може да внедри зловреден код, да остави задна врата за по-късно или да променя съдържанието. Последствията варират от кражба на данни през разпространение на зловреден софтуер до сериозна загуба на позиции в Google.
От какво най-често се хаква WordPress сайт?
Необновено ядро, тема или плъгин. Слаби пароли и липса на двуфакторна автентикация. Плъгини от непроверени източници. Стара версия на PHP. Автоматизирани скенери обхождат мрежата постоянно и намират тези слабости без човешка намеса.
Как да разпозная опасен плъгин, преди да го инсталирам?
Проверете кога е обновяван за последно, колко активни инсталации има и какво пишат в отзивите. Изтегляйте само от официалното хранилище на WordPress или от сайта на разработчика. Бъдете особено внимателни с „безплатни” версии на платени плъгини — там рискът е най-висок.
Какви са първите стъпки, ако сайтът ми е хакнат?
Свалете го офлайн, направете архив включително на базата данни, сканирайте за зловреден код, сменете всички пароли, премахнете непознатите акаунти и обновете всичко до последни версии. Едва след това го пуснете обратно.
Достатъчен ли е плъгин за сигурност?
Не. Плъгинът покрива част от рисковете — ограничава опитите за вход, сканира за зловреден код, филтрира заявки. Но не може да компенсира стара PHP версия, слаба парола или хостинг без изолация между акаунтите. Работи като част от набор, не сам.
Малък сайт защо ще е мишена?
Защото никой не ви е избрал лично. Ботовете сканират по уязвимост, не по размер. Малкият сайт е еднакво полезен за спам, фишинг или разпращане на имейли — а често е и по-лесна цел, защото никой не го наблюдава.
Колко често трябва да проверявам сигурността?
Обновленията — седмично. Архивите — да са автоматични и ежедневни, за да не зависят от вас. Пълен преглед на потребители, плъгини и теми — веднъж на няколко месеца, а задължително след всяка смяна на човек, който е имал достъп.
