☰

DoS-атака? Подавляющее большинство рабочих Apache в режиме «Запрос на чтение», сайт не работал вчера вечером, сейчас работает медленно

tag-icon • tag-icon apache-2.4 performance php-fpm performance-tuning denial-of-service
DoS-атака? Подавляющее большинство рабочих Apache в режиме «Запрос на чтение», сайт не работал вчера вечером, сейчас работает медленно

Поэтому я думаю, что мой сервер может подвергаться атаке типа «отказ в обслуживании».

Мы получили уведомление от pingdom (мониторинг веб-сайтов), что наш веб-сайт был недоступен примерно с 3 утра. Сегодня утром мы начали проверять журналы ошибок Apache и увидели целую кучу этой ошибки:

AH00485: табло заполнено, не достигнув MaxRequestWorkers

Мы также увидели, что нашему пулу процессов PHP-FPM часто требовалось создавать больше серверов:

[pool www] кажется занятым (возможно, вам придется увеличить pm.start_servers или pm.min/max_spare_servers), порождая 8 потомков

Мы пробовали увеличить MaxRequestWorkers в конфигурации Apache и использовать некоторые другие средства, но они не избавили нас от ошибки табло в журнале ошибок Apache, поэтому, вопреки здравому смыслу, я последовал совету вэта темаи установитьMinSpareThreadsиМакс. кол-во свободных потоковравноМаксRequestWorkers. Судя по всему, эти изменения устранили ошибку на табло.

Я также значительно увеличил 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 и 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-Status:

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, а не event, как у меня. Я также не понимаю, как небольшая информация в этой теме привела к диагностике SlowLoris.

EDIT Похоже, мне придется сформулировать свои вопросы точнее:

1) Как мне восстановить отзывчивость моего сервера. Очевидно, что apache worker'ы застревают вррежим является симптомом какой-то проблемы.

2) Есть ли какая-то надежная последовательность шагов, которую я могу предпринять, чтобы более конкретно определить реальную проблему?

3) Есть ли способ подтвердить, что машина подверглась DoS-атаке?

решение1

Простого подсчета количества подключений на табло недостаточно, чтобы понять, что клиенты грубят и не следят за своими подключениями. Это резкий рост, так что либо веб-приложение стало очень популярным, либо кто-то делает глупые запросы.

Посмотрите на скорость выполнения запросов в секунду. Она должна быть довольно высокой при таком количестве рабочих процессов, если ваше веб-приложение работает адекватно. Проверьте все аспекты производительности веб-сервера, включая доступную полосу пропускания для пользователей, нагрузку на сервер и производительность связанных компонентов, таких как базы данных. Устраните любые проблемы с производительностью, вызванные нехваткой ресурсов.

Проведите анализ распределения IP-адресов, подключенных к веб-портам. Один IP, выполняющий все сотни подключений, необычен, хотя IPv4 NAT усложняют это. Определите интернет-провайдеров исходных адресов. Проверьте оценки репутации безопасности IP-адресов и может ли это быть огромным NAT.

Сделайте захват пакетов входящих запросов, продолжая при этом мониторинг. Вы должны увидеть по крайней мере несколько HTTP-запросов от хорошо себя ведущих клиентов. Если клиенты просто подключаются и сидят там, это немного похоже на истощение ресурсов в стиле SlowLoris.

Рассмотрите рекомендации по настройке в связанном ответе. В Linux можно попробовать немного уменьшить тайм-ауты с помощью sysctl net.ipv4.tcp_fin_timeout = 10или что-то в этом роде.

Рассмотрите возможность размещения этого веб-сервера за ориентированным на безопасность и балансировку нагрузки прокси-сервером. Функции брандмауэра веб-приложений могут позволить вам делать умные вещи для фильтрации запросов. Горизонтальное масштабирование может позволить вам обрабатывать больше запросов.

решение2

Есть ли способ подтвердить, что машина подверглась DoS-атаке?

DoSэто Отказ в обслуживании.

Атакаэто враждебное действие, совершаемое с целью причинения вреда.

(Пассивная агрессия.это оксюморон, используемый людьми, которые не понимают, чтопассивныйозначает отсутствие действия — бездействие, по определению, иагрессия(по определению тоже) означает враждебные действия. Но это уже другая история, конечно.)

Между этими двумя есть промежуток, где это DoS, но это не атака с точки зрения враждебных действий. Скажем, застрявшая клавиша F5 на клавиатуре пользователя может вызвать DoS, если не будут приняты контрмеры, но это не атака как враждебное действие, выполняемое с намерением причинить вред. С другой стороны, это атака, если пользователь знает, что это вызовет DoS, и намеренно удерживает эту клавишу нажатой.

Так что отвечая на ваш вопрос — очевидно, невозможно сказать наверняка, пока вы не докажете, что есть намерение. Можно сказать, что это DoS, если прерывание обслуживания происходит из-за нехватки ресурсов — перегрузки.

Связанный контент