Автором публикации является 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
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. Смотрим есть и мейл для абузы. Ну и терь тока наштопать письмо к ним нужно что мол такой и такой айпи совершлых гнусную попытку атаковать наш сервер. Вообщем то админ админу всегда поможет.
И так с этим разобрались.
Это только начало статьи, описана только одна сиутация. Еще описаны будут другие, которые реально сталкиваемся каждый день