Самый выгодный отдых
Клиентам хостинга Spaceweb (sweb.ru) нередко приходят письма с предупреждением о том, что превышена нагрузка на сервер, при том, что никаких особых перегрузок сам сайт не создает и посещаемость может быть совсем небольшой. Что делать в этой ситуации?
Сам текст предупреждения звучит примерно так:
Вы являетесь клиентом SpaceWeb.
Ваш логин: xxx
Номер Вашего договора: xxx/xxx/xxxЗа последние сутки созданная Вашим аккаунтом нагрузка составила 279.98 процессорных минут. Это превышает допустимую на тарифах виртуального хостинга нагрузку в 60 процессорных минут и является нарушением п. 2.11
Правил предоставления услуг, указанных в Приложении 1 к Договору публичной
оферты (https://sweb.ru/docs/oferta.pdf).
Первоначально, многие думают, что это хостинг пытается развести их на деньги и требует перехода на более дорогой тариф, где будут выше лимиты по нагрузке. На самом деле, я сам прошел подобную ситуацию и спокойно решил ее, получив для своего сайта массу полезных плюшек не меняя тарифного плана и не бросаясь на поиски другого хостинга.
Такая политика контроля, наоборот, благо для вебмастеров:
- во-первых, ваш сайт не будет тормозить из-за того, что сосед по серверу забирает все ресурсы системы;
- во-вторых, вы сможете заранее обратить внимание на проблемы своего сайта (до того, как случится что-то непоправимое).
Давайте для начала разберемся в причинах проблемы.
Причины превышения нагрузки
Есть всего 3 причины, которые заставляют сервера хостинга напрягаться при обслуживании вашего сайта:
- Реально, очень высокая посещаемость;
- Дырки в сайте;
- Плохая оптимизация (медленные скрипты, большое их количество, тяжелые картинки и т.п.);
- DDoS атаки, боты, хакеры.
С первым пунктом все ясно — надо менять тариф хостинга — это объективная реальность, ваш проект вырос. Но, прежде чем к этому приступать проверьте 2 остальных пункта. Если про оптимизацию многие вебмастера знают (использую плагины, типа Hyper Cache, изображения сжимают), то п. 3 во внимание новичков попадает крайне редко.
Дырки (уязвимости) в сайте
Недавно я анализировал причины чрезмерной нагрузки на сайт компании, осуществляющей монтаж слаботочных систем и продажу соответствующего оборудования в Тюмени. Ниша не массовая и там не может быть посещаемости существенно влияющей на нагрузку. Между тем, она превышала максимально допустимую почти в 5 раз. Кроме того, место на хостинге стремительно уменьшалось, при том, что сайт почти статический и там материалы добавляются крайне редко.
При анализе логов выяснилось, что при настройке Joomla разработчики сайта оставили открытой возможность регистрации всем желающим. И при регистрации, каждый пользователь имел возможность заполнять поле описание (включая картинки и HTML разметку).
В итоге, боты это пронюхали и стал сайт оперативно наполняться с их помощью «полезным» контентом, изрядно сдобренным внешними ссылками, типа таких:
Обнаружилось все это при анализе логов доступа. О них подробнее я расскажу ниже, а именно эта проблема выглядит вот так:
Дырку закрыли, нагрузку снизили, сайт почистили — все хорошо. А вот не прислал бы хостинг письмо о превышении нагрузки, так и дождался бы сайт попадания под АГС от Яндекса. Кстати, если у вас сайт попал под этот фильтр, то здесь я рассказывал о том как вывести сайт из под АГС.
Медленный сайт
Проверяем в сервисе проверки скорости сайта от Гугл — developers.google.com/speed/pagespeed/insights/
Там по пунктам будут расписаны все замечания — скрипты, картинки, кэш и т.д. Если цифры для настольных ПК будут выше 70-75 из 100 то сайт более менее нормальный и причина повышенной нагрузки не в нем, хотя, всегда можно что-то улучшить — почитайте рекомендации и сделайте то, что написал Google.
Как-нибудь я сяду и напишу подробную статью про ускорение сайта, материалов есть уже много, только оформить надо. Сегодня основной упор на другое.
DDoS атаки, боты и хакеры
Это самая частая причина перегрузок. Так было у меня, так было у моих клиентов, которые обращались с подобной проблемой.
DDoS атаки — это, чаще всего происки конкурентов или личных недоброжелателей. Берется ваш сайт и на него начинают слать кучу всяких запросов с огромной частотой с разных компьютеров. Сервер вашего хостинга, как порядочный работник, все эти запросы обрабатывает, на что уходит немало ресурсов, вот и превышение нагрузки.
Боты — если у вас на сайте есть всякие формы, куда можно писать (комментарии, например), то находятся желающие запостить вам какую-нибудь ерунду со ссылками — так раскрутиться пытаются. Даже, если всю эту чушь фильтруют алгоритмы сайта или плагины типа Akismet, все равно нагрузка создается.
Хакеры — чаще всего? это попытка получить доступ к админке перебором паролей, реже поиск на сайте папок с открытыми правами доступа (для популярных CMS это часто бывает). Например, у меня в теме оформления была одна папка, которая изначально позволяла писать в нее кому угодно, что угодно — через нее я подхватывал несколько раз вирусы, пока не обнаружил и не закрыл дыру. Тут я писал как проверить сайт на вирусы и удалить вредоносный код.
Все эти атаки пресекаются одним способом — через блокировку IP адресов злоумышленников в файле .htaccess.
Как найти IP адреса хакеров
Для этой цели вам необходим лог файл, который ведет сервер хостинга на ваши ресурсы. Он может вестись по умолчанию, либо включаться через панель управления хостингом (как в случае со Spaceweb), либо просите его в тех поддержке хостинга.
Лог файл поможет вам не только снизить нагрузку на хостинг, но и залатать уязвимости своего сайта.
Дальше, файлы логов сервер выкладывает в корневую папку хостинга (рядом с public_html). Есть 2 типа логов — лог ошибок и логи доступа. Нам нужны логи доступа, называются они примерно так: access_log_20160331 — цифры означают дату. Имейте ввиду, дата означает момент создания файла, т.е. сегодня создан файл за вчера. Если вам нужны логи за 30 марта, то открываем файл от 31 марта.
Если вам известен точный день с зашкаливающей нагрузкой на аккаунт, то берете файл за этот день, если хотите сделать профилактический анализ, то выбирайте файл самого большого размера.
Есть специальные программы для анализа логов, я ими не пользовался, так как для обычных разовых анализов достаточно Microsoft Excel — открываем файл в нем.
Внутри файла построчно выведены все запросы, которые были направлены к вашему сайту, примерно так:
Информации здесь много, но на бытовом уровне надо знать лишь несколько столбцов:
- Адрес вашего сайта — biznessystem.ru
- IP адрес, с которого был совершен запрос — 93.116.122.106
- Дата и время запроса — 22/Mar/2016:00:21:56 +0300
- Тип и URL запроса — GET /2014/02/kak-razmestit-sajt-v-internete/ HTTP/1.1″
- Ответ сервера — 200
Шаг 1. Выявление взломщиков
Через функцию поиска в Excel ищем все IP адреса, которые пытаются попасть на административные страницы сайта (доступ к админке). В WordPress это «wp-admin», «wp-login», для других CMS укажите соответствующие страницы входа в админку.
Пример. Кликните для увеличения
Обратите внимание, что кто-то с IP 217.79.179.163 пытался открыть страницу /wp-admin/interface.php?password=&action=publish, на что получил ответ — ошибка 404 (страница не существует). С этого же IP с интервалом в секунду были попытки открыть еще кое-какие несуществующие страницы.
Чаще всего с одного адреса такая проверка на прочность проходит один раз, но если вы видите, что запросы периодически повторяются и их много (больше 100), то данный IP надо банить.
Шаг 2. Выявление спамеров
Аналогичным поисков отбираем строки содержащие директиву POST (GET — получение данных, POST — передача данных). Там где идет попытка постить что-то в неположенные места или запросов слишком много — видимо, это боты, также баним адреса.
Не забаньте себя и адрес своего хостинга!
Шаг 3. DDoS атаки
Для поиска таких проблем сортируете всю таблицу по алфавиту, в результате у вас все одинаковые IP адреса будут идти подряд. Пролистываете файл сверху вниз и как увидите много запросов с одного адреса (от нескольких сотен) смотрите, куда они ведут и каковы интервалы между ними — одинаковые запросы или маленькие интервалы признак атаки. Если запросов несколько тысяч, то это на 100% DDoS, можно не смотреть их остальные параметры. Заносите и такие адреса в черный список.
Какие адреса надо банить?
Есть 2 момента, на которые стоит обратить внимание:
- Часто используются динамические IP адреса, в этом случае атаки могут идти с соседних адресов, отличающихся только последними цифрами, так как компьютер получает новый адрес в рамках той же самой подсети — надо банить всю подсеть.
- Местонахождение IP адреса — если он принадлежит региону, в котором нет целевой аудитории вашего сайта, то блокируйте не раздумывая при малейших подозрениях.
Место и диапазон подсети выясняем здесь — 2ip.ru/whois/, если этот сайт не работает, то есть альтернативы.
Отдельно местонахождение IP — speed-tester.info/ip_location.php
Например, рассматриваемый мной выше адрес IP 217.79.179.163 находится в Германии, для моего блога это не целевой регион.
Отдельно масштабы подсети выясняем здесь — > whois-service.ru/lookup/
Этот германский адрес относится к подсети 217.79.178.0 — 217.79.179.255 и банить надо полностью все адреса начинающиеся на 217.79.178. и 217.79.179.
Как заблокировать IP адреса в htaccess
deny — это запрет, 4 строка запрещает конкретный адрес, а 5 подсеть.
Если закрываете подсеть полностью, то конкретные адреса из нее указывать не надо.
Рекомендую также заблокировать доступ к админке для всех адресов кроме своего. Как узнать свой IP адрес читайте тут.
Для WordPress
Для Joomla и других CMS
Если файл доступа находится не в корневой папке сайта, как это сделано в Joomla (там админка в папке /administrator/ располагается), то в той папке создаете свой отдельный htaccess и в нем прописываете следующее:
Ну, а если файлик доступа к панели администратора в корне и он известен, то действуем по аналогии с WordPress.
Это минимальные действия, которые позволят вам избавиться от превышения лимитов нагрузки, а за одним и защитить свой сайт от действий злоумышленников. В 99% случаев после таких настроек письма с предупреждениями от хостинга приходить перестанут.
Если Вам понравилась статья, пожалуйста, поставьте лайк! Следите за новой информацией на нашем сайте.
Благодарю! Кое-что добавил себе