Как выяснилось, та атака, которая прошла 2-го августа на мой сайт, и который в ее результате прилег на 15 минут, была описана и на Хабре, и на searchengines, причем на последней – настрочили уже больше 50 страниц. Как обсуждали корифеи, такой мощной атаки не было с апреля этого года. Заодно на форумах описано, как можно было бороться с этой напастью – поскольку это все-таки не DDOS, и тупо атакуется всего лишь один файл. В целом, все ожидаемо, и в отличном согласовании с тем, что я и сделал. А именно – я для себя избрал следующую стратегию:
1. С помощью .htaccess в корневой директории защитил wp-login.php, вписав внутри .htaccess после # END WordPress следующие строки:
1 2 3 4 5 6 |
<files wp-login.php> Order Deny,Allow Deny from all Allow from 127.0.0.1 Allow from 111.111.111.111 </files> |
Где 111.111.111.111 – подставил свой IP, с которого обычно захожу, поскольку он в данны момент у меня статический.
Allow from 127.0.0.1 – для вордпресса можно вообще не указывать, но и хуже от этого не будет.
2. После этого закрыл доступ к папке wp-admin, разместив там тоже файл .htaccess со следующим содержанием:
1 2 3 4 |
Order deny,allow Deny from all Allow from 127.0.0.1 Allow from 111.111.111.111 |
Аналогично, 111.111.111.111 – подставляем свой IP.
3. Ну и в обязательном порядке сгенерировал 403-ю страницу в виде простого html файла 403.shtml со строчным содержимым типа “403 Permission Denied – You don’t have permission to access here”, и разместил его в корневой директории. Это сделать необходимо, и в обязательном порядке, иначе запрос 403-ей ошибки с запретом к доступу будет перехватывать wordpress, и выдавать 404-ую страницу “не найдено” и в таком случае нагрузка на сайт не уменьшится, а наоборот – увеличится.
Это все отлично работает, если у сайта всего один автор, и у него – постоянный IP.
А что делать, если IP – не постоянный? Тут все сложнее. Понятно, что если поставить пароль на wp-admin еще можно, то на wp-login, лежащий в корне – уже не выйдет.
Таким образом, самый напрашивающийся вариант – либо каждый раз заходить по фтп, и прописывать новый IP, либо закрыть доступ к вп-логину большинству IP, кроме подсетей провайдеров, от которых вы выходите – их не так уж и много, и записав в маске IP, которым разрешен доступ что-то типа 213.87.136.0/21 – это собьет атаку до приемлемых значений.
Либо – использовать какой-либо плагин, скрывающий файл залогинивания, типа Lockdown WP Admin.
Ну, а если к тому, что IP автора постоянно меняются, прибавляется еще и необходимость регистрации пользователей, либо нежелание устанавливать плагины и разбираться с подсетями своих провайдеров – то неплохим вариантом будет установка скрипта, срабатывающего еще до того, как Вордпресс будет пытаться обработать запрос. Но скажу честно – я его не пробовал, за работоспособность не ручаюсь, все вопросы если что – к автору.
Я с помощью своего способа отделался всего 15-ю минутами в дауне – но это объясняется тем, что в момент, когда началась атака, я как раз находился на сайте, и я оперативно все закрыл.
Добавить комментарий