Каждый сайт в той или иной степени, периодически или постоянно, подвергается различным атакам хакеров. Одной из наиболее распространенных атак является подбор паролей для входа на веб-ресурс — Brute Force (брутфорс) атаки. Атаки такого рода на страницы логинов сайтов были, есть и по видимому будут всегда. Бороться с ними можно и нужно, даже не взирая на то, что 100% защиты никто не сможет предоставить.
В данной заметке мы рассмотрим несколько рекомендаций с форума BulletProof Security Pro по защите блогов на WordPress от брутфорс-атак на страницы логина и регистраций. И хотя здесь будут рассмотрены примеры касательно WordPress, но те же методы с успехом могут применяться на любых других типах сайтов, для чего понадобится всего лишь внести соответствующие поправки в код.
Внимание!
Перед началом экспериментов убедитесь, что у Вас есть доступ (с возможностью редактировать) к корневому файлу сайта .htaccess и к файлам текущей темы блога WordPress как минимум по FTP или SSH, или из админ-панели хостинга.
Ограничение для логина или регистраций по IP-адресам
В предлагаемом примере защита страниц для логина/регистрации блога от Brute Force атак осуществляется с помощью .htaccess на основе IP-адресов.
Имейте ввиду, что даже легальные пользователи сайта, у которых IP адрес не будет соответствовать IP адресу (или диапазону адресов подсети), прописанному в коде, не смогут залогиниться на сайте.
Однако в код можно добавить (если это действительно нужно) дополнительные IP-адреса, как полные, так и по группам из 2-х или 3-х октетов.
####### # Защита wp-login.php от Brute Force (брутфорс) атак на основе IP-адресов #######Order Allow,Deny # Добавьте доменное имя своего блога, например yourdomain.ru Allow from yourdomain.ru # Добавьте IP-адрес своего сайта/сервера Allow from 69.200.95.111 # Добавьте свой внешний IP адрес, используя 2 или 3 октета так, что если # ваш внешний IP адрес может меняться, то он будет в пределах подсети. # Если у Вас статический IP, то можете использовать его полностью, т.е. все 4 октета. # Примеры: # 2 октета: 65.100. # 3 октета: 65.100.50. # 4 октета: 65.100.50.111 Allow from 65.100.50. #######
В соответствии с кодом файла .htaccess данного примера доступ к странице логина сайта будет доступен только для:
- домена «yourdomain.ru»;
- сервера, на котором находится сайт с IP 69.200.95.111;
- всех IP адресов подсети 65.100.50.xxx
Внимание!
Если после использования защиты от Brute Force атак предложенным методом на основе IP-адресов Вы не смогли залогиниться на свой сайт или блог, то вероятнее всего IP вашего сайта изменяется динамически, причем в широком диапазоне. Следовательно такой тип защиты Вам может не подойти, но можно воспользоваться другим методом, на основе протокола.
Запрет логина или регистраций для посторонних на основе протокола
Данный метод позволит заблокировать более 90% попыток автоматизированных Brute Force атак, так как именно протокол версии HTTP/1.0 является типичным для автоматизированных брутфорс-атак.
#######
# Защита wp-login.php от Brute Force атак на основе протокола.
# Все легальные пользователи и боты должны использовать протокол HTTP/1.1
#######
RewriteCond %{REQUEST_URI} ^/wp-login\.php$
RewriteCond %{THE_REQUEST} HTTP/1\.0
RewriteRule ^(.*)$ - [F,L]
#######
После добавления этого кода в файл .htaccess доступ к странице логина блога (wp-login.php) будет заблокирован для всех запросов, использующих протокол HTTP/1.0.
Если Вы не можете войти на сайт после ограничение по IP-адресам
1) Зайдите на свой сайт по FTP или SSH и скачайте себе на локальный компьютер файл .htaccess из корневой директории сайта.
2) Отредактируйте .htaccess с помощью редактора Notepad или Notepad++ (но только не используйте для редактирования файла .htaccess редакторы MS Word или WordPad, так как они могут повредить структуру .htaccess).
3) Замените код Ограничение для логина или регистраций по IP-адресам на код Запрет логина или регистраций для посторонних на основе протокола;
4) Загрузите измененный файл .htaccess снова в корневую директорию своего сайта.
Если все же Вы не смогли залогиниться на свой сайт и у Вас нет доступа к его файлам по FTP или SSH, то тогда уж придется обращаться за помощью к службе поддержки хостинга.
Комбинирование блокировки доступа по IP и протоколу
Если страница логина была запрошена по протоколу HTTP 1.0 (который часто используют брутфорс-боты) или IP-адрес не совпадает с вашим IP (конкретным IP или по маске подсети), то доступ к странице логина будет запрещен.
#######
# Защита wp-login.php от Brute Force атак на основе IP-адресов или протокола
# Все легальные пользователи и боты должны использовать протокол HTTP/1.1
#######
RewriteCond %{REQUEST_URI} ^/wp-login\.php$
RewriteCond %{THE_REQUEST} HTTP/1\.0 [OR]
RewriteCond %{REMOTE_ADDR} !^xxx\.xxx\.xxx\.$
RewriteRule ^(.*)$ - [F,L]
#######
Вместо xxx\.xxx\.xxx нужно будет прописать соответственно необходимые Вам октеты IP-адресов.
Разрешение доступа к странице логина только для себя
Этот метод основан на проверке дополнительного параметра (или нескольких параметров) в запросе. Например таком:
http://www.yourdomain.ru/wp-login.php?SecretKey=25637653269
Естественно, что кроме SecretKey=25637653269 Вы можете использовать другое имя параметра и его значения, по вашему усмотрению.
Для реализации предлагаемого метода нужно в файл functions.php активной темы вашего блога добавить код, подобный этому:
//
// Защита страницы логина на основе ключа в запросе
function query_key_protection_for_login_page() {
$QueryKey = '?SecretKey=25637653269';
$myRequest = 'http://' . $_SERVER['SERVER_NAME'] . '/' . 'wp-login.php' . '?'. $_SERVER['QUERY_STRING'];
if ( site_url('/wp-login.php').$QueryKey == $myRequest ) {
// echo 'Query string matches';
} else {
header( 'Location: http://' . $_SERVER['SERVER_NAME'] . '/' );
}
}
add_action('login_head', 'query_key_protection_for_login_page');
//
При использования этого кода все запросы к странице wp-login.php, в которых отсутствует или не совпадает SecretKey=25637653269, будут автоматически перенаправлены на главную страницу блога. Используя данный метод защиты страниц логина от Brute Force атак не забывайте на всякий случай почаще менять пары ключ-значение для запросов SecretKey=25637653269, и к тому же старайтесь использовать для них наиболее уникальные имена и значения.
Примечание:
Если при использовании защиты страницы логина на основе ключа в запросе Вы будете получать предупреждение типа «Warning: Cannot modify header information — headers already sent …», то можно закомментировать строку «header( ‘Location: http://’ . $_SERVER['SERVER_NAME'] . ‘/’ );» и вместо нее использовать конструкцию exit;.
Метки: Brute Force, атака, безопасность, брутфорс, защита
у меня например стоит плагин ограничения попыток авторизаций.
так вот у меня так в добавок к этому стоит что то типа капчи надо сделать арифметический пример а он в виде слов типа *** + пять = шесть.
вроде как никто пока не проломил защиту хотя заблокированных IP уже насобиралось 20704 — нормально так погоняли сайт думал нагрузка перейдет допустимый предел но вроде все нормально..)
«типа *** + пять = шесть» — это слабая капча, но все же прок от нее есть. Да и она в основном против коммент-ботов. Плагин ограничения попыток авторизаций тоже полезен, и поставьте в его настройках (если такие есть) максимум 2 попытки, а затем блокировка на полсуток минимум.
Если же сам случайно 2 раза ошибешься, то не проблема для админа — зайдя в панель управления сайтом (на хостинге) можно времено отключить плагин или подправить «блокировку» в базе данных.
Ну а самая «крутая» защита от попыток залогиниться — удалить, переименовать или сделать пустым (что-то вроде
) файл wp-login.php, хотя потом, для того, чтобы самому залогиниться, нужно опять же например через FTP-доступ переименовать или вернуть файл на место. Неудобно, но результативно, особенно когда знаешь, что очень долго не будешь заходить в панель управления WP.Владимир, Ваш способ интересен, но как защитить FTP-доступ?
Да и взлом чаще происходит не через тупой перебор, а с помощью SQL-injection.
Evgeny,
используйте FTP-доступ только для конкретных задач, то есть временно, а после выполнения каких-либо работ с сайтом, отключайте FTP через хостинг-панель управления сайтом. FTP-доступ должен защищать хостер, ну а от вас требуется очень надежный пароль и своевременное отключение FTP.
SQL-injection все же чуток другое, чем брутфорс, хотя и ими тоже нередко пробивают именно доступ к паролю админа.
Очень неплохую защиту от SQL-injection например предоставляет плагин BulletProof Security для WordPeress, записывая в .htaccess кучу очень надежных блокировок против инжекций. На их форуме можете найти кучу советов, или просто посмотреть в коде самого плагина.
Интересно, а что делать, если потерял или забыл пароль от хостинга?
Виталий, странный у Вас вопрос, но все же…
Если уж потеряли пароль доступа на свой хостинг-аккаунт и у Вас даже нет возможности запросить пароль или смену пароля по e-mail, то нужно связаться с администрацией хостинга, которая должна Вам помочь.
Правда иногда могут быть трудности с доказательством того, что конкретный аккаунт действительно Ваш. Это нередко бывает, если Вы использовали какой-то бесплатный хостинг и не предоставляли владельцу хостинга никаких персональных данных, удостоверяющих вашу личность.
Здравствуйте, Владимир!
Возникло два вопроса:
1. Что такое конструкция exit и как в этом случае будет выглядеть код в варианте «Разрешение доступа к странице логина только для себя»?
2. Как сделать, чтобы перенаправление было не на главную страницу, а выдавало какую-то ошибку сервера (которая не сильно бы загружала сервер)?
Спасибо.
Некоторые попросту называют конструкцию «exit» функцией, потому, что ее можно записывать как «exit()», а код в варианте «Разрешение доступа к странице логина только для себя» выглядел бы так:
function query_key_protection_for_login_page() { $QueryKey = '?SecretKey=25637653269'; $myRequest = 'http://' . $_SERVER['SERVER_NAME'] . '/' . 'wp-login.php' . '?'. $_SERVER['QUERY_STRING']; if ( site_url('/wp-login.php').$QueryKey == $myRequest ) { // echo 'Строка запроса совпадает'; } else { exit('Оба-на! Ну и зачем же ты сюда полез?'); } } add_action('login_head', 'query_key_protection_for_login_page');При этом перенаправления на главную не будет, просто будет выведено сообщение «Оба-на! Ну и зачем же ты сюда полез?».
А чтобы вообще никуда не перенаправлять и не выводить сообщений, можно просто использовать «exit» без параметров:
Кстати, можно использовать и функцию-синоним — «die()», которая будет делать то же самое:
die('Оба-на! Ну и зачем же ты сюда полез?');или
Каждый новый плагин — потенциальная «дырка» в системе. WP — открытая CMS, найденые дыры латаются быстро и выходят обновления. По этому — меньше плагинов и держите актуальную версию WP.
Напишите статью по оптимизации производительности без плагинов.
Возможно такую статью и напишу (не уверен когда).
Но пока для развития и интереса я порекомендовал бы Вам посмтреть видео-презентацию с WordCamp Russia 2013 — Константин Ковшенин: Как повысить скорость сайта на WordPress
Спасибо, Владимир, как всегда актуальная тема.
Прочитал вашу статью как раз тогда, когда мой хостинг два дня гнется под массированными атаками и периодически недоступны все сайты, которые на нем размещены. Теперь серьезно подумываю снести wp-admin. Скажите пожалуйста, а если авторизацию проходить через страницу типа pagebla-bla-bla.php которую сделать самому и перекопировать в нее содержимое wp-admin с исправлением всех упоминаний wp-admin внутри кода. Насколько это эффективно?
Это очень даже эффективно, но главное при внесении изменений в скрипты не допускать ошибок. Кроме того, еще можно повысить эффективность периодически, а не разово, меняя путь к скрипту, файлу авторизации. Однако есть одно неудобство — при каждом очередном обновлении WordPress скорее всего придется повторно проводить изменения, которые вы сделаете ранее.