Web сервер. Определение нагрузки и от кого она идет - 9.8 Рубрика системного адміністратора - РОЗДІЛ ІХ: ІНТЕРНЕТ, МЕРЕЖІ, ХОСТІНГ

Web сервер. Определение нагрузки и от кого она идет

Дата: Пт, 20.03.2009, 16:52 | Повідомлення № 1

Тут живе...

Група: VIP-користувачі

Повідомлень: 111

Нагороди: 0

Автором публикации является Jokerz
Первая часть.

Web сервер. Определение нагрузки и от кого она идет?

И так, многие системные администраторы сталкиваются рано или поздно с проблемой связанной с нагрузкой на сервер. В этой статье я попытаюсь на примере реального веб сервера хостинг провайдера объяснить поэтапно как определять кто грузит сервер и как с этим бороться.
Для начала определимся с текущей машиной которую мы имеем, это Сервер а процессором AMD Opteron 2210, RAM – 1 Gb и HDD в рейде 1.0 (не 1 а именно 1.0). Конфигурация ПО: ось CentOS5, Apache 2, nginx 6, exim, dovecot, bind, ISPmanager Pro (панель управления) и конечно же консоль ssh.
Представим ситуацию когда начинаются жалобы клиентов что страницы грузятся долго. И иногда вываливается ошибка 502 Nginx. Разделим всю статью как бы на 2 части, это :
• Найти что именно дает нагрузку, какой сервис или чей сайт
• Найти конкретного виновника
• Решить проблемы с виновником
• По возможности не допускать повторной ситуации нагрузки
И так для того что бы снимать информацию которая нам необходима, нужно установить спец утилиты и модули.
Для апача это модуль mod_status который даст нам информацию кто именно юзает и какие запросы идут, сколько в данный момент обрабатывает коннектов апач, какой статус эти самые коннекты получили и прочее. Вот скрин уже подключенного модуля:

Вот на скрине конечно вместилось наверно где ? всех запросов? (виртуал хосты специально зарисованы).
И так как же подключить сам модуль:
Имес сюда:

Code

/etc/httpd/conf/httpd.conf

Ищем строки:

Code

LoadModule status_module modules/mod_status.so

Обратить внимание что бы строка была не заккоментирована, что бы модуль загружался апачем.
Дальше правим

Code

ExtendedStatus Off на ExtendedStatus On

Т.е. включаем работу модуля и отображение. Дальше необходимо отладить что бы он в браузере был доступен. Ищем дальше подобное:

Code

#
# Allow server status reports generated by mod_status,
# with the URL of http://servername/server-status
# Change the ".example.com" to match your domain to enable.
#
<Location /server-status >
     SetHandler server-status
     Order deny,allow
#    Deny from all
     Allow from s1.domains.net
</Location>

Если коротко то: по адресу /server-status будет доступен это сам модуль в действии. Но при это доступ будут иметь все кто захочет посмотреть. Потому я бы не заморачивался с паролями а просто сменил бы адрес на свой тип так:

Code

<Location /serverok-informations >
     SetHandler server-status
     Order deny,allow
#    Deny from all
     Allow from s1.domains.net
</Location>

Такс, теперь необходимо перезапустить апач что бы тот загрузил этот модуль и его настройки в память командой:

Code

Service httpd restart

И радуемся новой возможностью.
Так дальше нам понадобиться утилита top или что лучше установить htop он более информативный.
Top идет в комплекте к ОС а вот htop нужно поставить, благо он есть в репозитариях потому мы вбиваем волшебные команды: yum install htop и он ставиться на машину. Пример работы тулзы:

Я бы сказал объединили top и ps что получилось довольно не плохо.
Такс еще бы поставить mytop аналогично так же как и htop, mytop это то же самое что и top только показывает активность базы MySQL.
Так ну и пока достаточно. Все что дальше нужно уже есть в комплекте стандартной поставки.
И так представим разные ситуации:

[/b]Ситуация 1
Вы как толковый админ сидите и следите за общей нагрузкой т.е. мониторинг и тут обращаете внимание что среднее значение загрузки центрального процессора резко начало расти в гору, и составляет более той цифры что Вы привыкли наблюдать. К примеру load average: 9.24, 6.33, 3.40
Что означают эти цифры? Если смотреть то по порядку средние значения загрузки CPU а именно за 5, 10, 15 минут.
Когда у Вас среднее значение не превышает 2-3 % за эти периоды то ясное дело что почти 10 процентов должно обратить на себя внимание. Первой что смотрят это топ т.е. что именно дает нагрузку. Смотрим в консольке результат htop:
Глядим что как бы по 7-8 httpd процессов хватают проц и работают. Хм это апач,смотрим в результат mod_status:
Там у нас видно что ресурсы посещаются но не настолько что бы дать такую картину. Сразу думаете что может база грузит (это мод статус на выдаст) смотрим более пристально в топ, а именно на процесс mysqld:

Code

9809 mysql 1.39 20144 3:38 mysqld

3 колонка загрузка проца, ну 1.39% использования не дадут в среднем 10 процентов так что отпадает. Идем дальше по процессам:
И тут натыкаетесь на картину:

Code

root    20.01    1056  0:14    sshd
root    1.01    1056  0:02    sshd
root    14.01    1056  0:08    sshd
root    14.01    1056  0:12    sshd
root    10.01    1056  0:12    sshd
root    1.01    1056  0:03    sshd
root    1.01    1056  0:05    sshd
root    32.01    1056  0:07    sshd
root    2.01    1056  0:11    sshd

И куча процессов sshd, хм думаете вы, странно я ж один сижу в ssh, проверим как, и вводите коменду: w которая показывает:

Code

16:26:59 up 1 day, 19:49,  1 user,  load average: 12,34, 9,42, 8,40
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
root     pts/0    53-245-113-92.po 16:12    1.00s  0.03s  0.03s –bash

Что авторизированны Вы только один и все больше никого нету в системе. Тем более что все процессы от рута запущены, при авторизации юзеров процесс запущен от их имени, сразу наводит на мысль о бруте sshd демона. Идем в лог и смотрим что там щас твориться:
Cd /var/log/secure
И видим:
------------------------------------------------------------------------

Code

Mar 20 14:47:45 s1 sshd[7882]: Invalid user matematica from 78.111.78.69
Mar 20 12:47:45 s1 sshd[7796]: Received disconnect from 78.111.78.69: 11: Bye By
e
Mar 20 14:47:45 s1 sshd[7917]: Invalid user engleza from 78.111.78.69
Mar 20 12:47:47 s1 sshd[7893]: input_userauth_request: invalid user matematica
Mar 20 14:47:47 s1 sshd[7882]: pam_unix(sshd:auth): check pass; user unknown
Mar 20 14:47:47 s1 sshd[7882]: pam_unix(sshd:auth): authentication failure; logn
ame= uid=0 euid=0 tty=ssh ruser= rhost=inwow-bouncer.de
Mar 20 12:47:47 s1 sshd[7954]: input_userauth_request: invalid user engleza
Mar 20 14:47:47 s1 sshd[7917]: pam_unix(sshd:auth): check pass; user unknown
Mar 20 14:47:47 s1 sshd[7917]: pam_unix(sshd:auth): authentication failure; logn
ame= uid=0 euid=0 tty=ssh ruser= rhost=inwow-bouncer.de
Mar 20 14:47:47 s1 sshd[7687]: Failed password for invalid user engleza from 78.
111.78.69 port 57164 ssh2
Mar 20 12:47:47 s1 sshd[7716]: Received disconnect from 78.111.78.69: 11: Bye By
e
Mar 20 14:47:49 s1 sshd[8018]: Invalid user birou from 78.111.78.69
Mar 20 12:47:49 s1 sshd[8134]: input_userauth_request: invalid user birou
Mar 20 14:47:49 s1 sshd[8018]: pam_unix(sshd:auth): check pass; user unknown
------------------------------------------------------------------------

Это лог sshd на что стоит обратить внимание, это строки где invalid user и Failed password for invalid user с какой периодичностью это повторяется. В нашем случае идет подбор не только пароля к конкретному юзеру (к примеру к root)а пробует бот разные логины. Смотрим под каким IP этот бот работает, в нашем случае айпи один, причем обращения идут (глядя на время)штук 5 в секунду, человек такого не сотворит, потому это брут бота с сервера какого то. Первое что нужно сделать это оборвать коннект и запретить айпи конектиться к серверу, потому воспользуемся фарволом и заблочим все входящие коннекты с айпи который нас атакует.
Вбиваем такое:

Code

iptables -A INPUT -s 78.111.78.69 -j DROP

Теперь смотрим топ на наличие признаков брута. В результате нагрузка начала падать, и процессы перестали плодиться. Смотрим лог, последнее время которое зафиксировано атакой не совпадает с реальным что значит уже не брутят. Отлично, атаку отбили. Можем радоваться, но все таки душа не спокойна. Узнаем что за айпи. В консоль вбиваем

Code

whois 78.111.78.69

И получаем данные кто владелец подсети или айпи:
[

Code

root@s1 log]# whois 78.111.78.69
[Querying whois.arin.net]
[Redirected to whois.ripe.net:43]
[Querying whois.ripe.net]
[whois.ripe.net]
% This is the RIPE Whois query server #2.
% The objects are in RPSL format.
%
% Rights restricted by copyright.
% See http://www.ripe.net/db/copyright.html

% Note: This output has been filtered.
%       To receive output for a database update, use the "-B" flag

% Information related to '78.111.78.0 - 78.111.78.255'

inetnum:        78.111.78.0 - 78.111.78.255
netname:        UNITEDHOSTER_CGN_NET
descr:          Web/Mail/DB-Server/V-Server
country:        DE
admin-c:        AP1312-RIPE
tech-c:         AP1312-RIPE
status:         ASSIGNED PA
mnt-by:         Surfplanet-Mnt
source:         RIPE # Filtered

person:         Alexander Pelz
address:        Ernst-Heinkel-Str.2
address:        United-Hoster GmbH
address:        70734 Fellbach
abuse-mailbox:  abuse@united-hoster.com
phone:          +49.7114690661
fax-no:         +49.7114690662
mnt-by:         Surfplanet-MNT
nic-hdl:        AP1312-RIPE
source:         RIPE # Filtered

% Information related to '78.111.64.0/20AS33984'

route:          78.111.64.0/20
descr:          Surfplanet GmbH PA-Block
origin:         AS33984
mnt-by:         SURFPLANET-MNT
source:         RIPE # Filtered

И что мы видим IP принадлежит компании United-Hoster GmbH. Смотрим есть и мейл для абузы. Ну и терь тока наштопать письмо к ним нужно что мол такой и такой айпи совершлых гнусную попытку атаковать наш сервер. Вообщем то админ админу всегда поможет.
И так с этим разобрались.

Это только начало статьи, описана только одна сиутация. Еще описаны будут другие, которые реально сталкиваемся каждый день

Jokerz

Дата: Сб, 21.03.2009, 18:08 | Повідомлення № 2

Хостер

Група: Друзі форуму

Повідомлень: 698

Нагороди: 1

Ситуация 2
И так ситуация такая же как и Выше, сервер резко начинает потреблять ресурсы процессора, при этом посещаемость довольно скудная. Вариант перебора паролей к ssh вы уже откинули там все ок. Но при просмотре top замечаете что куча процессов dovecot и они юзают много ЦП. Снова повторяем то что было выше, открываем лог и смотрим что там твориться с нашим сервисом.
Лог мейла находиться тут

Code

/var/log/maillog

Обращайте внимание на авторизацию и ответ, если Вы видите что в ту же минуту проходит куча авторизаций с одним пользователем и ответы в логе что пароль неверный либо ситуация когда разные юзеры пробуют пройти авторизацию и при это получают ответ Access Denied то скорее всего это подбор паролей к мейлу. Аналогично смотрим IP и заносим в блек лист iptables. Такое может быть с многими сервисами где есть авторизация, потому брут нужно выявить и пресечь. Пароль скорее всего не подберут (толковые люди щас не ставят пароли типа 123456789 или qwerty), но вот дискомфорт и тормоза обеспечены. Главная работа админа это не сидеть и править ошибки, а следить что бы все работало отлично и без сбоев. Многие даже не вникают как эта работа трудна, и сколько зависит от нас. Ладно что то я уже заговариваюсь.