Блог о SEO оптимизация и поисковое продвижение
22 Авг
Сайты в Рунете растут как грибы после дождя. Для хакеров каждый сайт потенциально полезен: если получить к нему доступ, то можно как минимум сапо-ссылок разместить. Доступ хакер получает обычно из-за «дыр» в движке сайта или по причине установки простого пароля для стандартной учётной записи (например, «admin»). Чем выше SEO-показатели сайта, тем интересней он хакеру, тем активнее атака на сайт. Скажем, подбор пароля может идти сутками, при этом на сайт каждую секунду будет поступать несколько запросов с проверкой разных паролей, и хостинг при этом будет жутко нагружен. Даже если атака не будет успешной — хакеров тьма, и покупать ради них дорогущие сервера смысла нет. Значит, надо свести к минимуму воздействие таких атак на работу сайтов. Предлагаю это сделать через htaccess.
Предложенный способ подходит конкретно для движка WordPress, но в принципе может быть заточен под любой движок. Для использования способа на другой CMS надо знать некоторые технические особенности движка. Если вы вообще впервые сталкиваетесь с понятием «движок», можете здесь [1] почитать о разных CMS и различиях между ними. Я для защиты через htaccess конкретно использую особенность WP логинить пользователей по адресу /wp-login.php
, атаки на который производятся в 99,9% случаев.
Для начала придумайте какой-нибудь секретный адрес на вашем сайте. Например: /vasya-007.php
— создайте соответствующий файл в корне сайта и впишите в него такие простые строки:
<? SetCookie("vasya_007_x_data","1"); header('Location: /wp-login.php'); ?>
Особое внимание на vasya_007_x_data
— это тоже секретная информация, впишите вместо этой строки свою (использовать можно английские буквы, цифры, знак подчёркивания). Как вы поняли, при посещении секретного адреса в ваш браузер будет установлена секретная кука и произойдёт редирект на страницу входа WP. Теперь правим файл .htaccess
:
# Блокировка wp-login.php RewriteCond %{REQUEST_URI} ^/wp-login.php$ RewriteCond %{HTTP_COOKIE} !^.*vasya_007_x_data RewriteRule . - [L,F]
Где-то вначале файла пропишем эти строки (не забываем исправить свою секретную строчку). Теперь запросы к wp-login.php
просто не будут обрабатываться, если клиент обратиться без секретной куки. А чтобы вам получить секретную куку, надо обратиться по адресу ваш-сайт/vasya-007.php
(это в моём примере: надеюсь, вы придумаете свой), который вас отправит на страницу входа в WP. Тем самым, мы избавили хостинг от лишней нагрузки и сделали админку сайта более защищённой.
Для WP можно вообще заблокировать все POST запросы, которые исходят не от вас, не от вашего сервера и не от комментаторов. добавляем для этого такие строки в .htaccess
:
# Блокировка POST-запросов RewriteCond %{THE_REQUEST} ^POST RewriteCond %{REMOTE_ADDR} !^0.1.2.3$ RewriteCond %{HTTP_COOKIE} !^.*vasya_007_x_data RewriteCond %{REQUEST_URI} !^/wp-comments-post.php$ RewriteRule . - [L,F]
Где 0.1.2.3
— адрес вашего сервера. И помните, что правка файла .htaccess
неумелыми руками может стать причиной неработоспособности сайта.
Запись опубликована 22 августа 2013 года. Пост окончен, но в рубрике «Web-кодинг» есть не менее интересные посты:
RSS подписка (как это?) поможет вам не пропустить ничего интересного на этом блоге.
На «Директивы htaccess для защиты хостинга от перегрузок» получено 17 отзывов
Нифигасе ты озадачился 🙂 Решение хорошее, я таких еще не видел.
Сделал все по инструкции. Почему-то все равно загружается форма входа на сайт по ссылке , даже если все куки удалил из браузера.
Пардон, по невнимательности ошибся. Все работает. Спасибо, друг. 🙂
Пожалуйста! Рад, что этот пост помогает обезопасить сайты и сберечь ресурсы хостинга для целевого посетителя. 😉
А как в этом случае сделать так, чтобы по разным ссылкам открывать страницу регистрации и страницу входа? Например, у меня на сайте две ссылки — «войти» и «зарегистрироваться». С «войти» все понятно, сделал так, как описано в статье. Но как сделать так, чтобы по ссылке «зарегистрироваться» пользователь переходил сразу на страницу регистрации, и при этом записывались нужные куки?
Сейчас я вынужден объединить две ссылки в одну «войти/зарегистрироваться». При переходе по этой ссылке пользователь попадает на стандартную страницу входа WordPress (где нужно ввести логин и пароль), и уже под полями логина и пароля есть ссылка на страницу регистрации, куда нужно будет щелкнуть незарегистрированному пользователю. Слишком много телодвижений для пользователя.
В твоём случае, Евгений, можно создать ещё один «секретный адрес»
my-secret-register.php
или немного поправитьmy-secret-login.php
(можно использовать любые другие имена). Проще объяснить 1-й вариант: создаём файлsecret-register.php
(с любым своим именем) следующего содержания:SetCookie("my_secret_cookie","1"); header('Location: /wp-login.php?action=register');
Имя куки (my_secret_cookie) также может быть произвольное, но должно быть точно таким же, которое использовалось в файле
my-secret-login.php
и.htaccess
ранее. Теперь ссылка для регистраций будет:/my-secret-register.php
. Но и ссылка/wp-login.php?action=register
сработает, если юзер перейдёт по ней в форме входа на странице/wp-login.php
.Вот и всё. Правда, эта защита максимально эффективна на блогах, не подразумевающих регистрацию посетителей (коих большинство). А когда любой посетитель может узнать «секретный адрес», эффективность немного ниже. Конечно, 99.99% атак имеют массовый характер: тупо выявляют движок и обращаются к стандартной странице входа. Но если твой сайт имеет десятки тысяч посещений в сутки, кто-нибудь рано или поздно захочет получить доступ именно к нему или хотя бы попытаться «положить» сайт. Потому такой популярный сайт обязан располагаться на мошном сервере и иметь защиту от DDoS-атак (желательно, на уровне сервера).
Действительно, работает. Я почему-то думал, что в этом случае нужно менять .htaccess, и совсем запутался, как директиву оформить.
Согласен, защита снижается. Но в данное время наблюдаются массовые атаки на блоги на движке wordpress. После применения механизма, описанного в статье, нагрузка на CPU хостера упала со 121 «попугаев» до 17. Еще раз, огромное спасибо.
Нужно было бы менять .htaccess, но WP использует один и тот же адрес скрипта для входа и регистрации. Кстати, я ни разу не обращал внимание, есть ли у WP подтверждение e-mail при регистрации — с ним иногда могут возникнуть проблемы, если e-mail подтверждается на том же адресе wp-login.php (доступ к которому может быть заблокирован, если нет куки).
Огромное пожалуйста. 🙂
Да, WP может использовать e-mail для подтвержения регистрации. И как раз подтверждается по адресу wp-login.php. В принципе, проблем с подтверждением нет, если все делать на одной машине — регистрацию и подтверждение. Если на разных, то да, на второй машине кук нет, при подтверждении выдаст ошибку 404.
Кстати, а сколько куки хранятся в данном случае? Заметил, что через некоторое время куки пропадают.
Разобрался. Оказывается, если не указано время действия куки, они хранятся только на время сессии, т.е. пока не закроешь браузер. Немного модифицировал строчку из статьи.
Было:
SetCookie("my_secret_cookie", "1");
Стало:
SetCookie("my_secret_cookie", "1", time()+3600*24*30);
Теперь куки хранятся 30 дней.
Спасибо, я учту этот совет — хочу немного дописать статью. Ещё думал на счёт подтверждения регистрации и восстановления пароля (в этом случае ссылка тоже высылается по почте). Считаю, в случае с публичной регистрацией имеет смысл запретить только POST-запросы на wp-login.php во избежание проблем у пользователей. Либо при блокировке не просто выдавать заголовок 403 Forbidden, но и статическую страницу с возможностью оперативной связи с администрацией в случае проблем.
С блокировкой POST-запроса мне не совсем понятно. После регистрации пользователю высылается на почту ссылка для подтверждения. При переходе по ссылке какой тип запроса передается серверу? Не заблокирует ли сервер пользователя при этом?
И еще, в статье я недопонял вот это место:
«Для WP можно вообще заблокировать все POST запросы, которые исходят не от вас, не от вашего сервера...»
А что значит «исходят не от вас»? Имеется виду IP администратора или что? А как определяется, что запрос отправлен от сервера, а не от пользователя?
1) при переходе по ссылке осуществляется GET запрос. POST-запросы могут быть реализованы, например, при отправке форм. Так форма комментирования постов отправляет POST-запрос, для его разрешения я и добавил правило:
RewriteCond %{REQUEST_URI} !^/wp-comments-post.php$
А вот форма поиска по блогу формирует запрос GET.
2) Если у администратора постоянный IP, то можно прописать его. Кроме того, у тебя есть «секретная» кука, и вот это правило:
RewriteCond %{HTTP_COOKIE} !^.*vasya_007_x_data
в контексте предложенного к конце статьи кода разрешает администратору любые POST-запросы. Конечно, если он получил куку. Но, кроме этого, надо в этой строке инструкций:
RewriteCond %{REMOTE_ADDR} !^0.1.2.3$
указать IP сервера, если решился запретить все возможные POST-запросы, кроме комментариев. Иначе сервер тоже не сможет слать POST-запросы на сайт. И, например, не будет работать автосохранение постов.
На блокировку всех POST-запросов, кроме явно разрешённых, меня сподвиг один странный, но имевший повторение случай. В очередной раз, когда я заметил значительный рост нагрузки, я обнаружил множество POST-запросов на несуществующий адрес
site.ru/edit/
— запросов было не то чтобы много (не больше 100 запросов в минуту), но нагрузку они создавали значительную. Видимо, это слабое место WP. Вот я и подумал, что если явно запрещу адресsite.ru/edit/
, то в другой раз могу получить атаку наsite.ru/edit-shmedit/
и т.д.Спасибо, вроде все понятно. Буду иметь ввиду при следующей подобной атаке.
Обращение к несуществующим страницам (страница 404) на моем сайте блокируется настройкой плагина Better WP Security. Пять обращений — блокировка на час, 3 повтора блокировок — бан.
Большое спасибо за статью. Давно пыталась защитить сайты — плагины Login Lock Down Wordfence Security не помогали. Даже в файл .htaccess вписала пару сотен ip адресов, чтобы запретить им вход, но помогало только на время.
Ваш метод интересен тем, что при обновлении движка WordPress ничего менять снова не нужно. Как говорится раз — и сделал надолго.
Причем сразу сократилась нагрузка на cpu, из-за чего иногда сайты долго открывались!
Хайпер, большущее спасибо за статью!
Удалось разблокировать сайт enem.25, внес все изменения, описанные выше. Сразу обновился до 4.3.1, смог войти в админку.
Едиственное- появилась проблема — не возможно перейти к другим разделам сайта (меню), сервер отдает:
Not Found
The requested URL /category/pozdravleniya/ was not found on this server.
Я вот гадаю — то ли тех.поддержка хостинга разблокировала только главную, то ли сервис забугорный, обеспечивающий безопасность от DDoS неправильно работает (cloudflare.com), то ли внесенные в .htaccess изменения конфликтуют с плагинами, коих активных 27 (сайт администрировался не мной).
Подскажите — кто что знает, пож-та.
Олег, если надпись «was not found on this server» написана чёрным на белом фоне, без всякого намёка на дизайн вашего сайта, то проблема скорее всего в настройке веб-сервера, который пытается открыть папку «/category/pozdravleniya/», не находит её, и затем даже не пытается передать управление в index.php, а сразу выдаёт ошибку. Хотя, в htaccess тоже может быть причина, но вам в любом случае надо душить тех.поддержку
Ваше SEO-мнение
Я прошу высказать своё мнение, а не оставить ссылку на раскручиваемый сайт. В любом случае, ссылки в комментариях у меня закрыты от индексации, если интересует качественный обмен ссылками -обращайтесь