Защита сайта от брутфорса без правки кода

Если Ваш сайт, написанный на базе популярного движка (WordPress, Joomla, Magento и др.), стал сильно тормозить, а в логах доступа сервера Вы видите множество обращений к странице логина или к странице администрирования, знайте — ваш сайт «нашли» боты-брутфорсеры и пытаются подобрать пароль администратора.Если с Вашим паролем всё нормально (он длинный и набран цифрами и буквами в разных регистрах), то Вы можете быть уверены, что брутфорсер его не подберёт. Но сам факт того, что происходит подбор, а тем паче то, что при этом страшно грузится сервер и расходуется трафик (особенно если на вашем хостинге он платный) откровенно говоря, напрягает. Ниже я расскажу как избавиться от этой проблемки очень простым и бескровным способом. Сперва предыстория. Проблемой я озаботился спустя некоторое время после того, как перешёл с «самодельного» движка на WordPress (впрочем, это мог бы быть любой другой более-менее распространённый движок). Запилил первый сайт и уже через неделю увидел в логах огромное количество запросов к странице логина. Поиски в интернете выводили на множество «рецептов», подавляющее большинство которых заключается в переименовании файла wp-login.php и его правке (поскольку адрес самой страницы неоднократно встречается в самом файле wp-login.php и других файлах движка. Но этот способ означает правку ядра WordPress. А это влечёт за собой невозможность получать регулярные автоматические обновления ядра, а также несовместимость с некоторыми плагинами. К тому же способ абсолютно не спасает против тех роботов, которые ищут «дыры» в админке и плагинах, обращаясь с хитроумными параметрами по адресам вида /wp-admin/* В общем, этот способ сразу был отвергнут. А идея моя заключается вот в чём. Нужно завести специальную […]

Read more

Слетела сеть Linux Ubuntu 14.10

После длительной круглосуточной работы решил перезагрузить сервер. И как это часто бывает – он не захотел до конца запускаться. Выдалось сообщение при загрузке:

Запустился, выполняю команду:

В ответ вижу: start: Job failed to restart Файл /etc/network/interfaces заполнен корректно. Более того, раньше же все хорошо работало. Удалил данный файл. И запустил:

После этого, обновил операционную систему и восстановил содержимое файла /etc/network/interfaces:

 

Read more

ISPManager удаляет домены

Автор: Рудюк С . А. https://corp2.net E-Mail: rs@corp2.net Столкнулся с проблемой удаления доенов в админке ISPManager. При анализе ситуации, обнаружил, что домены исчезали не из конфигов Apache и Nginx, а только из списка админки ISPManager. Т.к. тех-поддержка разработичка ничем не помогла, пришлось бороться с ситуацией самому. Для начала, включил подробное логирование в ISPManager. Для этого, в конфиге /usr/local/ispmgr/etc/ispmgr.conf указал параметр: LogLevel 9 После  этого, сделал, чтоб постоянно выводилась информация из лога на экран: tail -n 1 -f /usr/local/ispmgr/var/ispmgr.log Далее – просматриваю все процессы ISPManager: ps aux | grep ispm Снимаем задачу  bin/ispmgr. Данный процесс автоматически запускается при вызове админки из командной строки браузера. После того, как перезарузил ISPManager – увидел куча сообщений о правах доступа. Как оказалось, ISPManager требует совпадения пользователя, который указан в Apache с владельцем каталога, где создан домен. Если это не так – не будет выводиться домен в списке админки… При этом, сообщение выдастся только в логе… Указав пользователя-владельца для папки домена, получаем решение проблемы… Правда, нужно не забывать после этого снять процесс ISPManager и заново войти в админку, тем самым перезагрузив админку… Автор: Рудюк С . А. https://corp2.net

Read more