Обеспечение безопасности модуля Apache mod_status и правильный анализ значений состояния

Что отображает mod_status

Модуль Apache mod_status предоставляет информацию о работающем веб-сервере. Он помогает, например, определить, сколько рабочих процессов в данный момент задействовано и какие запросы обрабатываются. Приведённые ниже пояснения относятся к Apache HTTP Server 2.4; документация по ветке разработки является отдельной и не может быть применена к этой версии без предварительной проверки.

A обработчик генерирует сообщение о статусе для настроенного URL-пути. Раздел «Location» может передать этот путь обработчику server-status ; для этого не требуется наличие файла с таким же именем в каталоге DocumentRoot. Таким образом, этот путь представляет собой доступ к диагностике сервера, а не обычную страницу, предоставляемую из файловой системы.

Для ручной диагностики подходит режим просмотра HTML. Вариант с ?auto предоставляет машиночитаемое представление, которое система мониторинга может регулярно запрашивать. Набор доступных сведений зависит, в частности, от конфигурации сервера. Этот параметр не превращает конечную точку в отдельную службу: его вывод также необходимо защитить от несанкционированного доступа.

Условием является то, что модуль mod_status загружен и у вас есть права на редактирование соответствующего файла конфигурации Apache. Для ограничения доступа также должны быть доступны необходимые модули авторизации. Порядок активации модуля и файлы, отвечающие за это, различаются в зависимости от дистрибутива и установки; поэтому указание одного конкретного пути к файлу не может служить универсальной отправной точкой.

Для Мониторинг Apache Этот вывод является источником диагностической информации, но не представляет собой полноценный мониторинг производительности приложения. Например, он показывает, что рабочие процессы заняты, но не объясняет, что именно — база данных, бэкэнд или медленный клиент — вызывает задержку обработки. Для выяснения таких причин вам потребуются дополнительные соответствующие данные о приложении, системе и журналах.

Данные о состоянии и их последствия для безопасности

На странице состояния, помимо прочего, отображаются занятые и свободные рабочие процессы, а также данные о времени запуска или перезапуска и времени работы. Занятые рабочие процессы на момент запроса не доступны в качестве свободных ресурсов. Насколько критичным является соотношение занятых и свободных рабочих процессов, можно оценить только с учетом динамики и фактически настроенного ограничения на количество рабочих процессов.

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

С Расширенный статус Apache собирает дополнительные данные, в том числе сводные показатели посещаемости и объемы данных, а также информацию о текущих хостах и запросах. При загрузке модуля mod_status этот сбор данных в Apache 2.4 включен по умолчанию. Тем не менее, явное указание в конфигурации позволяет четко определить, какой уровень детализации предусмотрен для конкретной эксплуатации.

Более точный сбор данных имеет свою цену: он требует дополнительных затрат и может замедлить работу сервера. Поэтому следует сопоставить диагностическую пользу с этими затратами, а не рассматривать больше деталей как бесплатное улучшение. С другой стороны, без ExtendedStatus отсутствует информация, которая может быть полезна для сопоставления текущих запросов.

Вывод может раскрыть текущие запросы и информацию о клиентах. Поэтому обращайтесь с ним как с конфиденциальные производственные данные а не в качестве общедоступной проверки работоспособности. HTML-представление и ?auto требуют одинаковой защиты доступа; даже трудноугадываемый путь не препятствует доступу со стороны того, кто его знает или обнаружил.

Проверить пути доступа и модель рабочих процессов

Перед внесением изменений определите версию Apache, установленную на сервере, и активный модуль многопроцессорной обработки (Multiprocessing Module, сокращенно MPM). Кроме того, проверьте, какие виртуальные хосты обслуживает данный прослушиватель, перенаправляют ли обратные прокси-серверы запросы и какие правила доступа уже действуют. Только имея такую общую картину, можно оценить, где будет действовать новое правило и на какие существующие настройки оно может повлиять.

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

Второй способ может реализоваться с помощью обратного прокси-сервера и другого виртуального хоста. В этом случае могут применяться другие правила перенаправления или доступа; кроме того, необходимо проверить, какой адрес клиента Apache фактически использует для авторизации. Рассмотрим Путь доступа поэтому, включая прокси, выбор хоста и правила Apache, вместо того, чтобы переносить результаты локального тестирования на всю топологию.

MPM определяет, как Apache использует процессы и, при необходимости, потоки для обработки запросов. Процесс — это единица операционной системы; потоки выполняются внутри процесса и могут обрабатывать там задачи. Таким образом, значение количества рабочих процессов зависит от используемой модели. Сравнение моделей рабочих процессов Apache объясняет различия между Prefork, Worker и Event.

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

Настройка локальной конечной точки состояния

Перед внесением изменений проверьте, работает ли HTTP-сервер Apache версии 2.4, mod_status загружен, и необходимые модули авторизации доступны. Кроме того, зафиксируйте существующие виртуальные хосты и правила доступа. Активация модулей и пути к конфигурационным файлам различаются в зависимости от дистрибутива; приведённый ниже пример следует поместить в соответствующий конфигурационный файл Apache, а не в файл, который предполагается использовать во всех случаях.

В этом примере происходит переключение Расширенный статус явно указывает и назначает этот путь обработчику состояния. Require local ограничивает доступ в соответствии с правилами Apache для локальных подключений. Директива, отвечающая за подробную регистрацию, находится вне раздела `Location`. Перед применением необходимо проверить, как этот раздел взаимодействует с вашей существующей конфигурацией.

ExtendedStatus On

<Location "/server-status">
    SetHandler server-status
    Require local
</Location>

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

После запуска приложения ты можешь получить машиночитаемый вывод локально с помощью следующей команды чтения. Для этого необходимо, чтобы на выбранном адресе loopback и стандартном порте 80 был запущен прослушиватель. Также проверьте, доходит ли запрос до указанного виртуального хоста; при необходимости вам потребуется настроить порт и выбор хоста в соответствии с вашей средой.

curl --fail --silent --show-error 'http://127.0.0.1/server-status?auto'

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

Безопасное расширение доступа к системе мониторинга

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

На сайте Require ip Решающим фактором является не только тот адрес, который видит сервер мониторинга. При работе за обратным прокси установленная конфигурация должна предоставлять тот адрес, который Apache фактически использует для авторизации. Проверьте это сопоставление в реальных условиях, прежде чем открывать доступ к сети; предполагаемый адрес клиента не является надёжным средством контроля доступа.

Несколько Require-Директивы внутри одного раздела, если они не заключены в соответствующий контейнер, по сути действуют как Оператор «И»: Если запрос соответствует одному из условий, этого может быть достаточно. Если клиент должен находиться в разрешенной сети и дополнительно авторизоваться, четко сформулируйте эти условия в одном <RequireAll>-Объедините контейнеры и протестируйте оба требования по отдельности.

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

Правильно классифицировать значения состояния

Страница состояния предоставляет ответы на различные диагностические вопросы с помощью различных данных. Ознакомьтесь с Распределение рабочих поэтому не является изолированным: он описывает состояние на момент запроса. Дополнительные сведения о запросе зависят от конфигурации и, в частности, от параметра ExtendedStatus; набор отображаемых полей может различаться в зависимости от сервера и MPM.

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

На сайте event-MPM определённые состояния ожидания могут обслуживаться прослушивателем, а не постоянно привязанными рабочими потоками. Поэтому «Writing» и «Keep-alive» следует рассматривать как состояния соединений, а не как общее количество занятых потоков. На картину также могут влиять завершающиеся процессы и более старые поколения после плавного перезапуска; проверьте подробности для вашей установленной версии 2.4.

Для классификации архитектуры дополняет Сравнение MPM «Event» и MPM «Worker» индикатор состояния. Выбор MPM объясняет, как Apache организует соединения и работу; однако он не заменяет наблюдения за конкретным сервером и его приложением.

Наблюдение за данными о состоянии в динамике

Для Apache Monitoring отдельная страница состояния — это лишь часть общей картины. Выведи машиночитаемый вывод через ?auto регулярно запрашивай их у уполномоченного агента и сохраняй значения с отметкой времени. Так ты сможешь, например, определить, возникает ли небольшое количество свободных рабочих процессов лишь на короткое время или же они сохраняются на протяжении нескольких запросов.

Для Частота интервалов ты сравниваешь накопленное значение счетчика с его предыдущим значением и делишь разницу на прошедшее время. Например, если количество обращений за 60 секунд увеличивается на 120, это соответствует среднему показателю в два обращения в секунду за этот интервал. Это среднее значение пока ничего не говорит о распределении в пределах минуты.

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

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

Сохраненные данные о состоянии также подлежат защите: в зависимости от формата вывода они могут содержать информацию о запросах и клиентах. Ограничьте доступ к агенту, хранилищу и средствам анализа только уполномоченными лицами и системами. Кроме того, определите, в течение какого времени сырые данные и производные показатели должны храниться для соответствующих операционных целей.

Проверка доступа и сообщений об ошибках

После утверждения изменения сначала проверьте, что доступ к нему разрешен соответствующим пользователям, например, локальному агенту мониторинга. Затем с сетевого узла, доступ с которого явно запрещен, проверьте как HTML-страницу, так и её вариант ?auto. Оба не должны передавать туда данные о статусе. Тестирования только одного местоположения или только одного пути доступа недостаточно.

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

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

Проверьте существующие конфигурации на наличие устаревших директив доступа, таких как Order и Deny. Их необдуманное смешение с более поздними Require-Нарушение правил может привести к неожиданным результатам. Проверьте, какая комбинация действительно работает, вместо того чтобы делать выводы об окончательном доступе на основании одного-единственного разрешающего правила.

Кроме того, защищенное местоположение не обязательно является единственной возможной конечной точкой статуса. Если модуль mod_status загружен, его обработчик может также использоваться в настройках для отдельных каталогов, включая .htaccess могут быть доступны. Поэтому проверьте имеющиеся записи и разрешённые делегации, особенно на серверах общего доступа, чтобы исключить возможность настройки дополнительных незащищённых обработчиков.

От косвенных доказательств к производственным решениям

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

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

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

Для яркого Идентификатор процесса Кроме того, ты можешь проверить данные об операционной системе, такие как загрузка процессора и памяти. Эта сопоставленность является дополнительным ориентиром, но не заменяет сопоставления по времени с запросами и логами. В частности, при повторных наблюдениях следует учитывать, что процессы и обрабатываемые ими в данный момент запросы могут меняться.

В случае event-MPM также следует учитывать завершающиеся процессы и старые поколения после плавного перезапуска. Они могут повлиять на ситуацию во время переходного периода; при этом открытые соединения не всегда равнозначны постоянно занятым рабочим потокам. Ознакомьтесь с особенностями установленной версии Apache 2.4, прежде чем на основе результатов такого переходного периода принимать окончательное решение о необходимых ресурсах.