Атаката от 12.04 – изводите една седмица по-късно
Както в българското блог пространство вече стана известно, в началото на миналата седмица бяхме свидетели на необичайно голяма за българския интернет мрежова атака. Атаката беше насочена към логин формата на WordPress, а нейната цел – налучкване (bruteforce) на административния или други акаунти за популярната блог платформа и последващо инжектиране на зловредни скриптове. Източници на атаката бяха както обичайните: САЩ и Китай, така и множество по-рядко срещани дестинации.
Атаката, както показа направеният анализ, беше доста разнопосочна. Една голяма част от злонамерения трафик беше по UDP протокол, който се използва за DNS услугата или иначе казано за връзка между имената на сайтовете и техните машинни (IP) адреси.
От останалача част, поне половината трафик беше насочен към сайтове, които физически не се намират на сървърите на Host.bg, нито изобщо в България. Фактът, че на нашите сървъри се атакуват несъществуващи сайтове свидетелства по-скоро за грубата подготовка на тази атака. Това обаче, не я прави по-малко опасна, защото увеличеният трафик също рефлектира върху качеството на услугите.
Последната, около една трета от трафика беше насочена наистина към логин фората на WordPress главно, но също така и към други CMS-и. По информация на наши партньори в САЩ, това всъщност е основната цел на атаката. На пръв поглед изглежда доста неефективно бот-мрежа от хиляди или десетки хиляди комппютри, които вече са заразени, да бъдат използвани за хакването на доста по-малък брой CMS платформи. Крайната цел в случая обаче са финансови институции в САЩ, които вече са регистрирали и обявили масова атака от страна на хостинги от цял свят.
В момента все още продължава да е налице макар и доста по-слаб хакерски трафик от този тип. Макар и типична DDOS атака, нейната изключителна мощност в този кокретен случай се оказа едновременно с това и ахилесовата и пета. На практика, от всяка отдалечена заразена машина се правят огромен брой еднакви заявки за много къс период от време, което позволява създаването на филтриращи правила, които да ограничат нейния ефект.
Потребителите от своя страна могат да се защитят като вземат следните мерки:
– Ъпдейт на версията на WordPress и на инсталираните плъгини.
– Инсталиране на плъгин за сигурност.
– Използване на високо-защитетна парола на административния акаунт.
– Повече информация може да откриете тук.
Ето и няколко допълнителни стъпки за защита на един WordPress сайт:
– Деактивиране на DROP коамандата за DB_USER. Тази команда всъщност никога не се използва от блог платформата.
– Премахване на README и лицензните файлове, който съдържат информация за версията на платформата.
– Преместване на файла wp-config.php в „по-горна“ директория и защита с на директорията с права „400“.
– Преустановяване на достъпа на WordPress до htaccess конфигурационния файл за хостинга.
– Ограничаване на достъпа до wp-config.php файла само до определени машинни (IP) адреси.
– Ето и няколко плъгина за защита:
wp-security-scan
wordpress-firewall
ms-user-management
wp-maintenance-mode
ultimate-security-scanner
wordfence,
Още информация може да бъде намерена на този адрес.