Поэтому я думаю, что мой сервер может пострадать от атаки отказа в обслуживании.
Pingdom (мониторинг веб-сайта) уведомил нас о том, что наш веб-сайт недоступен примерно с 3:00. Сегодня рано утром мы начали проверять журналы ошибок apache и увидели целую кучу этих ошибок:
AH00485: табло заполнено, не на MaxRequestWorkers
Мы также увидели, что нашему пулу процессов PHP-FPM часто требовалось создавать больше серверов:
[pool www] кажется занятым (вам может потребоваться увеличить pm.start_servers или pm.min / max_spare_servers), порождая 8 детей
Мы попытались увеличить MaxRequestWorkers в apache conf и некоторых других средствах, но они не избавили нас от ошибки табло в журнале ошибок apache, поэтому, вопреки моему здравому смыслу, я последовал совету в эта тема и установить MinSpareThreads и MaxSpareThreads равно MaxRequestWorkers. Эти изменения, кажется, устранили ошибку табло.
Я также значительно увеличил MaxRequestWorkers, потому что у нас много оперативной памяти, которая явно не используется. Наш сервер имеет 8 ядер и, несмотря на эти действительно высокие значения конфигурации, похоже, не использует большую часть своей оперативной памяти:
$ free -h
total used free shared buff/cache available
Mem: 7.8G 1.8G 2.0G 38M 4.0G 5.8G
Swap: 0B 0B 0B
Я очень нервничаю из-за этих высоких значений MaxRequestWorkers в apache conf и pm.max_children в конфигурации php-fpm.
Вот базовая конфигурация в mpm_event.conf
<IfModule mpm_event_module>
StartServers 2
MinSpareThreads 800
MaxSpareThreads 800
ThreadLimit 64
ThreadsPerChild 25
ServerLimit 800
MaxRequestWorkers 800
MaxConnectionsPerChild 0
</IfModule>
Вот некоторые настройки в файле конфигурации php-fpm:
pm.max_children = 256
pm.start_servers = 64
pm.min_spare_servers = 64
pm.max_spare_servers = 128
Вот основная информация о сервере:
Server version: Apache/2.4.18 (Ubuntu)
Server built: 2019-10-08T13:31:25
Server's Module Magic Number: 20120211:52
Server loaded: APR 1.5.2, APR-UTIL 1.5.4
Compiled using: APR 1.5.2, APR-UTIL 1.5.4
Architecture: 64-bit
Server MPM: event
threaded: yes (fixed thread count)
forked: yes (variable process count)
А вот некоторые данные из вывода статуса сервера apache:
Server Version: Apache/2.4.18 (Ubuntu) OpenSSL/1.0.2g
Server MPM: event
Server Built: 2019-10-08T13:31:25
Current Time: Friday, 10-Jan-2020 22:58:55 CST
Restart Time: Friday, 10-Jan-2020 22:26:32 CST
Parent Server Config. Generation: 1
Parent Server MPM Generation: 0
Server uptime: 32 minutes 22 seconds
Server load: 4.69 5.06 5.12
Total accesses: 78434 - Total Traffic: 1.5 GB
CPU Usage: u2970.53 s5037.34 cu0 cs0 - 412% CPU load
40.4 requests/sec - 0.8 MB/second - 19.7 kB/request
797 requests currently being processed, 3 idle workers
PID Connections Threads Async connections
total accepting busy idle writing keep-alive closing
6124 28 yes 25 0 0 0 3
6125 27 yes 25 0 0 0 2
6182 30 yes 25 0 0 1 4
6210 28 yes 25 0 0 0 3
6211 29 yes 25 0 0 0 5
6266 28 yes 25 0 0 2 1
6267 25 yes 25 0 0 0 1
6269 28 no 24 1 0 1 3
6276 28 yes 25 0 0 0 3
6378 28 yes 25 0 0 0 3
6379 31 no 24 1 0 4 3
6380 27 yes 25 0 0 0 3
6384 26 yes 25 0 0 0 2
6397 28 yes 25 0 0 2 1
6405 27 yes 25 0 0 0 2
6414 26 yes 25 0 0 1 0
6423 27 no 24 1 0 1 1
6602 27 yes 25 0 0 0 3
6603 28 yes 25 0 0 0 4
6604 26 yes 25 0 0 0 1
6617 30 yes 25 0 0 0 5
6646 26 yes 25 0 0 0 2
6676 27 yes 25 0 0 0 2
6694 30 yes 25 0 0 0 5
6705 28 yes 25 0 0 0 3
6730 29 yes 25 0 0 0 4
6765 29 yes 25 0 0 0 4
6781 27 yes 25 0 0 0 2
6805 28 yes 25 0 0 0 4
6836 28 yes 25 0 0 0 3
6858 27 yes 25 0 0 0 3
6859 27 no 25 0 0 1 1
Sum 888 797 3 0 13 86
Больше всего сбивает с толку часть рабочего режима. Почти все в режиме чтения:
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRR_RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
_RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRWRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR_RRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
И в конце вот это:
SSL/TLS Session Cache Status:
cache type: SHMCB, shared memory: 512000 bytes, current entries: 2176
subcaches: 32, indexes per subcache: 88
time left on oldest entries' objects: avg: 220 seconds, (range: 197...243)
index usage: 77%, cache usage: 99%
total entries stored since starting: 60122
total entries replaced since starting: 0
total entries expired since starting: 0
total (pre-expiry) entries scrolled out of the cache: 57946
total retrieves since starting: 3405 hit, 59594 miss
total removes since starting: 0 hit, 0 miss
Netstat показывает более 3000 подключений к портам 80 и 443:
$ netstat -n | egrep ":80|443" | wc -l
3715
Что, черт возьми, происходит? Сервер работает нормально несколько месяцев с гораздо более скромные настройки конфигурации. Кажется, что-то резко изменилось прошлой ночью около 3 часов ночи.
Любое руководство будет очень признательно. Я сначала искал здесь и нашел этот другой поток но это другая версия apache, работающая в режиме prefork вместо события, подобного моему. Я также не понимаю, как небольшая часть информации в этой теме привела к диагностике SlowLoris.
РЕДАКТИРОВАТЬ Похоже, мне нужно более точно сформулировать свои вопросы:
1) Как мне восстановить работоспособность моего сервера. Очевидно, что рабочие apache застревают в р режим - это симптом какой-то проблемы.
2) Есть ли какие-нибудь надежные шаги, которые я могу предпринять, чтобы более точно определить реальную проблему?
3) Есть ли способ подтвердить, что машина подверглась DoS-атаке?
Простой подсчет количества подключений на табло не является достаточным доказательством того, что клиенты грубят и не отслеживают свои подключения. Это резкое увеличение, так что либо веб-приложение стало очень популярным, либо кто-то делает глупые запросы.
Посмотрите, сколько запросов выполняется в секунду. Должно быть довольно много с таким количеством рабочих, если ваше веб-приложение работает адекватно. Проверьте все аспекты производительности веб-сервера, включая доступную для пользователей полосу пропускания, нагрузку на сервер и производительность связанных компонентов, таких как любые базы данных. Устраните любые проблемы с производительностью из-за нехватки ресурсов.
Проведите анализ распределения IP-адресов, подключенных к веб-портам. Один IP-адрес, выполняющий все сотни подключений, необычен, хотя NAT IPv4 усложняет это. Определите провайдеров исходных адресов. Проверьте оценки репутации IP-адресов, и может ли это быть огромный NAT.
Выполняйте захват пакетов для входящих запросов, продолжая при этом мониторинг. Вы должны увидеть по крайней мере несколько HTTP-запросов от клиентов с хорошим поведением. Если клиенты просто подключаются и сидят там, это немного похоже на исчерпание ресурсов в стиле SlowLoris.
Обратите внимание на рекомендации по настройке в связанном ответе. В Linux немного уменьшено время ожидания с помощью sysctl net.ipv4.tcp_fin_timeout = 10 или так есть что попробовать.
Рассмотрите возможность размещения этого веб-сервера за прокси-сервером, ориентированным на безопасность и балансирующим нагрузку. Функции брандмауэра веб-приложений могут позволить вам делать умные вещи для фильтрации запросов. Горизонтальное масштабирование может позволить вам обрабатывать больше запросов.
Есть ли способ подтвердить, что машина подверглась DoS-атаке?
DoS отказ в обслуживании.
Атака враждебные действия, совершенные с целью причинения вреда.
(Пассивная агрессия это оксюморон, используемый людьми, которые не понимают этого пассивный означает отсутствие действия - бездействие по определению и агрессия (тоже по определению) означает враждебные действия. Но это, конечно, совсем другая история.)
Между этими двумя есть промежуток, где это DoS, но это не атака с точки зрения враждебных действий. Скажем, F5, застрявшая на клавиатуре пользователя, может вызвать DoS, если не будут приняты контрмеры, но это не атака как враждебное действие, совершенное с намерением причинить вред. OTOH, это атака, если пользователь знает, что это вызовет DoS, и намеренно удерживает эту клавишу нажатой.
Итак, отвечая на ваш вопрос - очевидно, что невозможно сказать наверняка, если вы не докажете наличие намерения. Можно определить, является ли это DoS, если прерывание обслуживания происходит из-за нехватки ресурсов - перегрузка.