Рекорд 10000 и лежащий сервер

Рекорд 10000

Замечательное событие случилось 26 ноября 2013 года! Количество посетителей сайта впервые преодолело порог 10000 человек в день и составило 10144 человек! Наплыв посетителей сопровождался одновременным ростом глубины просмотра до 1,90, что в свою очередь вызвало ещё больший прирост числа просмотров - до 19248, что почти на 50% больше, нежели чем в последние дни. Сегодня, 27 ноября, посещаемость остаётся на достигнутом уровне, а глубина просмотра ещё немного подросла и сейчас составляет 1,95. 

Такая высокая посещаемость не прошла бесследно для сервера: огромного труда удавалось держать его в рабочем состоянии, а он постоянно стремился упасть и испустить дух. Ночью у него всё же случился приступ, названный техподдержкой Kernel Panic и с 6 до 8 утра по МСК сервер был в ауте. Ввиду таких трудностей были рассмотрены следующие варианты:

Вирусы на сервере, как найти и удалить?

 

Вирусы на сервере выглядят как .php файлы с разными именами, находящиеся в разных директориях и несущие вирусный код. Проникают они туда с зараженных компьютеров, с которых производится администрирование системы и посредством уязвимостей как в CMS сайта, так и в оболочке сервера. В моём случае попадались следующие типы вирусов:
Зараженные файлы .htaccess и phpinfo.php во всех стандартных папках joomla - в images/stories, в components/, в language/ru-RU  и т.д. Размер файла .htaccess  составлял 1642 байта и содержал процедуру вызова phpinfo.php любым зашедшим ботом, в том числе googlebot. Файл phpinfo.php весил 5108 байт и содержал код вируса, использующего уязвимости base64_decode. 

Зараженные файлы с произвольным именем типа 4sdgf5.php, содержащие код вируса.

Файлы mailer.php, содержащие, как ясно из названия, скрипт спамбота

Другие файлы с вирусами, спрятанные под мирные .png или .gif картинки. 

Найти и удалить вирусы на сервере удалось только вручную. При просмотре директорий была выявлена закономерность: некоторые файлы имели отличную от остальных дату создания, владельца и набор прав. Если все нормальные файлы были созданы в январе сего года, имели автора root и права 755, то вирусные файлы были созданы 6 ноября, автором имели apache и права носили 644. Файлы вирусов нещадно удалялись, так как не положено быть файлам .htaccess и .php в таких папках, как images !!!

Помогло и локальное сканирование сделанного ночью бэкапа данных антивирусом Avast Internet Sequrity 8. Он нашёл не все вирусы в бэкапе, но указал, что именно стоит искать на сервере.

После излечения сервера от вирусов и закрытия им дальнейшей дороги на него пришло некоторое облегчение, но длилось оно недолго и сервер снова начал подавать признаки хандры: 95-97% загрузку процессора, большое количество одновременно запущенных процессов httpd и общую вялость при открытии сайта, а в некоторые моменты и отказ в доступе по причине неготовности базы MySQL. Техподдержка высказала предположение, что это DDOS и силы были брошены на борьбу с ним

Как бороться с DDOS атакой и что такое DDOS вообще?

 

DDOS - это атака извне. Могут заказать ваш сайт и в его двери начнёт ломиться толпа роботов с кучей пустых запросов, которые мигом повесят сервер и не отпустят его, пока не закончится "оплаченный период". В этом случае предпринимать что-то бесполезно, сервер вы всё равно не поднимите. НО этот случай - один на миллион, тем более для такого сайта, как stevsky.ru. Какой к чёрту заказ? Кому нужно вешать сайт, посвящённый компьютерным играм и новеньким смартфонам, не имеющий коммерческих целей кроме как заработка на рекламе?

Поэтому я сел анализировать логи и пришёл к интересному выводу: всю эту нагрузку на сервер создают обычные пользователи, заглядывающие на сайт и читающие статьи. Да-да, просто посетители сайта! Никаких атак!

Как же так? Неужели мощный сервер не может справиться с потоком из 10000 посетителей в сутки? Оказывается, не может. Если не выполнен ряд действий по оптимизации отдачи контента.

Например, ранее статья 4 фотки 1 слово содержала ВСЕ ответы на одной странице! То есть при заходе на неё пользователь сразу грузил все 410 картинок общим весом около 20 мегабайт, а посещалась статья очень даже часто! Пришлось разбивать статью на 8 частей, по 50 картинок в каждой, и заставлять посетителей рыскать по всем частям в поисках ответа на их вопрос. Это, правда, принесло столь желанное увеличение глубины просмотра и общего количества просмотров, а также снизило количество одновременных загрузок .jpg файлов из этой директории. В целях сокращения трафика картинки также были пережаты с незначительной потерей качества и суммарно похудели практически вдвое, до 10МБ.

Та же операция была проведена со статьёй Что за слово - ответы к игре на андроид, 302 картинки были разбиты на 6 статей. 

Серверу зримо полегчало, но всё же он ещё мог перегреться. И я перешёл к тяжёлой артиллерии

Поисковые боты нагружают сервер, что делать?

Логи - прекрасная вещь, когда умеешь их читать. Я ни черта не понимаю в логах, поэтому пришлось долго сидеть и разбираться. Оказывается, быстрая индексация сайта поисковиками имеет обратную сторону: поисковые роботы осуществляют чудовищную нагрузку на сервер! Их трафик составляет от 30% до 80% общего трафика сервера и именно они являются причиной медленной работы сайта, зависаний, падений и всяких там Kernel Panic. Кернель просто в панике от их наглости и прожорливости!

Ограничивать ботов необходимо и чем жёстче вы с ними будете, тем быстрее полегчает вашему серверу! 

Закрыть папки от поисковых ботов

Для этого нам нужно править файл robots.txt, но править его умно. Вот, например, что получилось у меня:

User-agent: *
Disallow: /administrator/
Disallow: /arhiv/
Disallow: /cache/
Disallow: /components/
Disallow: /images/
Disallow: /includes/
Disallow: /installation/
Disallow: /language/
Disallow: /libraries/
Disallow: /media/
Disallow: /modules/
Disallow: /plugins/
Disallow: /templates/
Disallow: /tmp/
Disallow: /xmlrpc/
Disallow: /cgi-bin/
Disallow: /ckeditor/
Disallow: /error/
Disallow: /logs/
Disallow: /music/
Disallow: /stats/
Disallow: /webstat/
Disallow: /index2.php?option=com_content&task=emailform
Disallow: /*?sl*
Disallow: *.pdf$
Disallow: /name.php?action=print
Disallow: /trackback
Disallow: /*rss.html
Disallow: /*atom.html
Crawl-delay: 5
Host: www.stevsky.ru
sitemap: /index.php?option=com_xmap&sitemap=2&view=xml

Я заблокировал ВСЕМ ботам ВСЕ папки моего сайта! Даже images, плюнув на то, что в этом случае сайт не будет участвовать в поиске по картинкам. Да кому он нахрен нужен, этот поиск по картинкам? У меня с него из 170тыс. посетителей в месяц пришло что-то около сотни! В следующем месяце я легко переживу и без них!

После того, как заблокировали все папки, заблокируем возможность отправки почты с сайта emailform, чтения pdf файлов напрямую, индексацию rss и atom фидов. 

Crawl-delay - это количество секунд между индексацией двух страниц. Бот заканчивает индексировать первую страницу, ждёт пять секунд и только потом начинает индексировать вторую. Да, индексация несколько замедлится и мои 3000 страниц (откуда яндекс столько набрал, уму не приложу!) теперь будут индексироваться на 15000 секунд (около 4 часов) дольше, но ведь не каждый же день яндексбот устраивает глобальную перепроверку моего сайта! Так что это вовсе некритично, а ресурсы сервера можно заметно сэкономить!

Запретить неугодных поисковых ботов

Не все боты хороши, не все они нужны. По большому счёту, для качественной индексации сайта достаточно всего четыре бота: yandex, googlebot, mailru и rambler. Причём последние два вносят лишь жалкие 2,5% в общий котёл, так что и от них можно отказаться. Остальных - закрыть, запретить, отключить и послать к чёртовой бабушке, потому как они могут как просто назойливо грузить сервер, так и закидывать его пачками ненужных запросов, увеличивая объём трафика и в критических ситуациях вешая напрочь. Вот такой список можно внести в ваш файл .htaccess:

########## Блокируем неугодных ботов
order allow,deny
allow from all
# Далее список ботов, которым мы запрещаем доступ
SetEnvIfNoCase User-Agent JS-Kit bad_bot
SetEnvIfNoCase User-Agent PostRank bad_bot
SetEnvIfNoCase User-Agent Python-urllib bad_bot
SetEnvIfNoCase User-Agent UnwindFetchor bad_bot
SetEnvIfNoCase User-Agent facebookexternalhit bad_bot
SetEnvIfNoCase User-Agent TweetmemeBot bad_bot
SetEnvIfNoCase User-Agent Butterfly bad_bot
SetEnvIfNoCase User-Agent MFE_expand bad_bot
SetEnvIfNoCase User-Agent Java bad_bot
SetEnvIfNoCase User-Agent Summify bad_bot
SetEnvIfNoCase User-Agent MetaURI bad_bot
SetEnvIfNoCase User-Agent FlipboardProxy bad_bot
SetEnvIfNoCase User-Agent ScribdReader bad_bot
SetEnvIfNoCase User-Agent RockMelt bad_bot
SetEnvIfNoCase User-Agent InAGist bad_bot
SetEnvIfNoCase User-Agent NING bad_bot
SetEnvIfNoCase User-Agent TweetedTimes bad_bot
SetEnvIfNoCase User-Agent PaperLiBot bad_bot
SetEnvIfNoCase User-Agent Library bad_bot
SetEnvIfNoCase User-Agent Ezooms bad_bot
SetEnvIfNoCase User-Agent strawberryj bad_bot
SetEnvIfNoCase User-Agent Scooper bad_bot
SetEnvIfNoCase User-Agent Ahrefs bad_bot
SetEnvIfNoCase User-Agent Spider bad_bot
SetEnvIfNoCase User-Agent None bad_bot
SetEnvIfNoCase User-Agent EventMachine bad_bot
SetEnvIfNoCase User-Agent aiHitBot bad_bot
SetEnvIfNoCase User-Agent SolomonoBot bad_bot
SetEnvIfNoCase User-Agent SearchBot bad_bot
SetEnvIfNoCase User-Agent Wget bad_bot
SetEnvIfNoCase User-Agent Crawler bad_bot
Order Allow,Deny
Allow from all
Deny from env=bad_bot

Правда, этот список блокирует лишь избранных "плохих ботов", чья зловредность была обнаружена и подтверждена, но оставляет лазейки новым и малоизвестным ботам, которые могут оказаться ещё более пакостными. Однако кардинальная мера "отказать всем, кроме [список]" может привести к проблемам индексирования в случае если разрешенный бот сменит название или появится какой-то новый качественный поисковик (что конечно вряд ли, но всё же), поэтому предлагаю остановиться на таком варианте. Список со временем можно пополнять, услышав имя очередного злопакостного бота, лютующего на просторах интернета, или отследив аномальную активность в логах. Да, читать логи придётся учиться в любом случае, так что можете приступать прямо сейчас...

Снижение нагрузки на сервер

 

Принятые меры привели к снижению нагрузки на сервер примерно на 50%, что позволило ему исправно фнкционировать и переваривать около 20000 просмотров страниц в сутки. Когда посещаемость вырастет ещё в 1,5-2 раза, придётся предпринимать дальнейшие меры. Может, переходить на более мощный сервер, а может открывать для себя тайны конфигурирования apache в связке с nginx. 

Пока что меня передёргивает от одной даже мысли, в какие дебри программирования мне придётся лезть, ведь я ни черта не соображаю в Linux, на котором работает сервер, с трудом отличаю Apache от Root и иногда путаю kernel с nginx. Но, как показывает практика, дорогу осилит идущий и часы упорного разбирательства и чтения мануалов даруют откровение!

< Предыдущая		Следующая >