Proteger o mod_status do Apache e interpretar corretamente os valores de estado

O que o mod_status torna visível

O módulo mod_status do Apache fornece informações sobre o servidor Web em funcionamento. Ajuda, por exemplo, a saber quantos workers estão ativos neste momento e quais as solicitações que estão a ser processadas. As explicações que se seguem referem-se ao Apache HTTP Server 2.4; a documentação da ramificação de desenvolvimento é independente desta e não pode ser aplicada a esta versão sem verificação prévia.

A manipulador gera a saída de estado para um caminho URL configurado. Uma secção «Location» pode passar esse caminho ao manipulador server-status atribuir; não é necessário que exista um ficheiro com o mesmo nome no DocumentRoot. O caminho constitui, assim, um acesso ao diagnóstico do servidor e não uma página normal fornecida a partir do sistema de ficheiros.

Para o diagnóstico manual, recomenda-se a visualização em HTML. A variante com ?auto fornece uma representação legível por máquina que um sistema de monitorização pode consultar regularmente. Os detalhes disponíveis dependem, entre outros fatores, da configuração do servidor. Este parâmetro não transforma o ponto final num serviço separado: a sua saída também deve ser protegida contra o acesso não autorizado.

É necessário que o mod_status esteja carregado e que tenhas permissão para editar a configuração adequada do Apache. Para restrições de acesso, é também necessário que os módulos de autorização necessários estejam disponíveis. A forma de ativar um módulo e os ficheiros responsáveis por isso variam consoante a distribuição e a instalação; por isso, um único caminho de ficheiro não constitui um ponto de partida universalmente válido.

Para Monitorização do Apache A saída constitui uma fonte de diagnóstico, mas não representa uma monitorização completa do desempenho da aplicação. Mostra, por exemplo, que os workers estão ocupados, mas não explica por si só se é uma base de dados, um backend ou um cliente lento que está a atrasar o processamento. Para identificar essas causas, é necessário dispor adicionalmente de dados adequados da aplicação, do sistema e dos registos.

Dados de estado e as suas implicações em termos de segurança

A página de estado apresenta, entre outros, os workers ocupados e os disponíveis, bem como informações sobre a hora de início ou reinício e o tempo de execução. Os workers ocupados não estão disponíveis como capacidade livre no momento da consulta. Só é possível avaliar o grau de criticidade da relação entre workers ocupados e disponíveis com base na evolução e no limite de workers efetivamente configurado.

O período de tempo ajuda a contextualizar os valores agregados no tempo: uma média desde o início pode ocultar picos de carga de curta duração. Da mesma forma, uma consulta com poucos trabalhadores disponíveis é, numa primeira fase, apenas um instantâneo. Consultas repetidas, juntamente com os tempos de resposta e os erros, fornecem uma base mais sólida para analisar uma possível escassez.

Com ExtendedStatus O Apache regista detalhes adicionais, incluindo acessos agregados e volumes de dados, bem como informações sobre os hosts e pedidos atuais. Ao carregar o mod_status, este registo está ativado por predefinição no Apache 2.4. No entanto, uma decisão de configuração explícita permite compreender qual o nível de detalhe previsto para cada operação específica.

Este registo mais detalhado tem o seu preço: implica um esforço adicional e pode tornar o servidor mais lento. Por isso, pondera a utilidade diagnóstica face a esse esforço, em vez de considerar automaticamente que mais detalhes constituem uma melhoria gratuita. Por outro lado, sem o ExtendedStatus, faltam informações que podem ser úteis para a identificação das solicitações em curso.

A saída pode revelar pedidos em curso e informações do cliente. Por isso, trate-a como dados operacionais confidenciais e não como uma verificação pública do estado de saúde. A visualização em HTML e ?auto requerem o mesmo nível de proteção de acesso; um caminho difícil de adivinhar não impede o acesso por parte de alguém que o conheça ou o descubra.

Verificar as vias de acesso e o modelo de workers

Antes de efetuar qualquer alteração, identifique a versão do Apache instalada e o Módulo de Multiprocessamento (MPM) ativo. Verifique também quais os hosts virtuais que servem o listener em questão, se os proxies inversos reencaminham os pedidos e quais as regras de acesso já em vigor. Só com esta visão geral é possível avaliar onde uma nova regra terá efeito e quais as configurações existentes que esta poderá afetar.

Um agente de monitorização local poderia consultar o estado através de um endereço de loopback. No entanto, uma consulta local bem-sucedida apenas demonstra que esse caminho específico, com o endereço, a porta e o host virtual selecionados, funciona. Não prova, nem que outros hosts estejam protegidos, nem que o acesso externo falhe.

Uma segunda opção pode passar por um proxy reverso e outro host virtual. Nesse caso, podem aplicar-se outros redirecionamentos ou regras de acesso; além disso, é necessário verificar qual é, de facto, o endereço do cliente que o Apache utiliza para a autorização. Considera o Via de acesso por isso, incluindo o proxy, a seleção do host e as regras do Apache, em vez de transferir o teste local para toda a topologia.

O MPM determina a forma como o Apache utiliza processos e, se for o caso, threads para o processamento. Um processo é uma unidade do sistema operativo; as threads executam-se no interior de um processo e podem lá processar tarefas. A importância do número de workers depende, portanto, do modelo utilizado. O Comparação dos modelos de workers do Apache explica as diferenças entre Prefork, Worker e Event.

Sobretudo no caso do event-MPM As ligações abertas não são automaticamente sinónimo de threads de trabalho ocupados de forma permanente. Certos estados de espera podem ser tratados de forma diferente do processamento ativo de um pedido. Por isso, anota o MPM ativo antes de tomares uma decisão sobre a capacidade com base nos números de ligações e de threads de trabalho.

Configurar o ponto final de estado local

Antes de efetuar a alteração, verifica se o Apache HTTP Server 2.4 está a funcionar, mod_status esteja carregado e os módulos de autorização necessários estejam disponíveis. Registe também os hosts virtuais e as regras de acesso existentes. A ativação dos módulos e os caminhos de configuração variam consoante a distribuição; o exemplo seguinte deve ser inserido no ficheiro de configuração do Apache adequado, e não num ficheiro genérico pressuposto.

O exemplo ativa ExtendedStatus aceita-o expressamente e atribui o caminho ao gestor de estado. Require local limita o acesso de acordo com as regras do Apache para ligações locais. A diretiva para o registo detalhado encontra-se fora da secção «Location». Antes de a aplicar, deves verificar como esta secção interage com a tua configuração atual.

ExtendedStatus On

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

Manda verificar e aprovar a alteração de acordo com o teu processo operacional antes de a aplicares. O exemplo serve apenas como ponto de partida e não constitui uma garantia para todos os hosts virtuais ou percursos de proxy. Em particular, as secções de autorização existentes podem influenciar qual a regra que se aplica a um pedido específico.

Após a execução, podes obter localmente a saída legível por máquina através do seguinte comando de leitura. Este comando pressupõe a existência de um listener na morada de loopback selecionada e na porta padrão 80. Verifica também se o pedido chega ao host virtual previsto; se for caso disso, terás de ajustar a porta e a seleção do host ao teu ambiente.

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

Uma tentativa de acesso falhada é, numa primeira fase, apenas uma indicação, não um diagnóstico claro do erro. Para além da autorização, podem estar em causa, por exemplo, outro listener, uma atribuição de host diferente ou um redirecionamento. Por outro lado, um acesso local bem-sucedido não garante, por si só, que outras vias de acesso estejam protegidas.

Ampliar de forma segura o acesso à monitorização

Escolha a via de acesso consoante o local onde o monitorização está a ser executada e quem necessita dos resultados. Um agente no mesmo anfitrião pode utilizar a restrição local. Caso seja necessário o acesso de um sistema externo, a autorização deve ser limitada às fontes efetivamente necessárias e, posteriormente, verificada através da via de rede prevista.

Em Require ip Não é apenas determinante o endereço que o servidor de monitorização possui do seu ponto de vista. Atrás de um proxy reverso, a configuração instalada tem de fornecer o endereço que o Apache utiliza efetivamente para a autorização. Verifica esta correspondência no percurso real antes de autorizar o acesso a uma rede; um endereço de cliente presumido não constitui um controlo de acesso fiável.

Vários Require- As diretivas dentro de uma secção funcionam, na regra geral, como uma Operador «ou»: Se um pedido cumprir uma das condições, isso pode já ser suficiente. Caso um cliente provenha da rede autorizada e, além disso, tenha de se autenticar, indique expressamente as condições num <RequireAll>-Reúne os contentores e testa cada um dos requisitos separadamente.

Na autenticação básica, só um protocolo de transporte adequado, como o TLS, protege os dados de acesso durante a transmissão. Uma rede de gestão separada pode limitar ainda mais a acessibilidade, mas não substitui uma autorização eficaz do Apache. Também nesse caso, apenas os sistemas autorizados devem poder aceder à saída em HTML e à saída legível por máquina.

Classificar corretamente os valores de estado

A página de estado responde a diferentes perguntas de diagnóstico com dados diferentes. Lê a Atribuição de trabalhadores Por isso, não é isolada: descreve o estado no momento da consulta. Os detalhes adicionais do pedido dependem da configuração e, em particular, do ExtendedStatus; os campos que aparecem podem variar consoante o servidor e o MPM.

Suponhamos que uma consulta revele muitos workers ocupados e apenas alguns disponíveis. Isso pode ser um pico de carga de curta duração ou indicar uma pressão mais prolongada. Repete a consulta e compara a evolução com os tempos de resposta, os erros e o limite de trabalhadores efetivamente em vigor, antes de considerares uma alteração na capacidade.

Em event-MPM Certos estados de espera podem ser geridos pelo listener, em vez de por threads de trabalho permanentemente associadas. Por conseguinte, «Writing» e «Keep-alive» devem ser interpretados como estados de ligação e não, de forma generalizada, como um número de threads ocupadas. Os processos em fase de encerramento e as gerações mais antigas após um reinício suave também podem influenciar o panorama; verifica os detalhes relativos à tua versão 2.4 instalada.

Para a classificação da arquitetura, o Comparação entre o MPM de eventos e o MPM de trabalhadores a exibição do estado. A escolha do MPM explica como o Apache organiza as ligações e o trabalho; no entanto, não substitui a observação do servidor específico e da sua aplicação.

Acompanhar os dados de estado ao longo do tempo

No caso do Apache Monitoring, uma única página de estado é apenas uma amostra. Obtém a saída legível por máquina através de ?auto Recupera regularmente esses valores através de um agente autorizado e guarda-os com um carimbo de data/hora. Desta forma, podes verificar, por exemplo, se o número reduzido de workers disponíveis é apenas temporário ou se se mantém ao longo de várias consultas.

Para um Frequência de intervalo Comparas um contador acumulado com o seu valor anterior e divides a diferença pelo tempo decorrido. Se, por exemplo, o número de acessos aumentar em 120 no espaço de 60 segundos, isso corresponde a uma média de dois acessos por segundo nesse intervalo. Este valor médio ainda não diz nada sobre a distribuição ao longo do minuto.

Antes de calcular a diferença, verifica as informações de arranque ou reinício e o valor do contador. Se o servidor tiver sido reiniciado ou se um contador tiver diminuído em relação à consulta anterior, trata isso como um reinício e inicia uma nova série de comparações. Uma taxa de tráfego negativa resultante de duas leituras do contador seria, neste caso, enganadora; as consultas falhadas também devem permanecer identificáveis ao longo do histórico.

As médias apresentadas pelo mod_status ao longo do tempo de funcionamento do servidor suavizam os picos de carga de curta duração. Uma série temporal com um intervalo de consulta adequadamente selecionado mostra as alterações com maior precisão, mas também pode deixar escapar eventos que ocorram entre duas consultas. Por isso, escolha o intervalo de acordo com a questão de diagnóstico e tenha em conta o esforço necessário para a recolha e o armazenamento dos dados.

Os dados de estado armazenados também devem ser protegidos: dependendo da saída, podem conter informações sobre o pedido e o cliente. Limite o acesso ao agente, ao armazenamento e à análise a pessoas e sistemas autorizados. Defina ainda por quanto tempo os dados brutos e os indicadores derivados devem ser conservados para o respetivo fim operacional.

Verificar o acesso e as mensagens de erro

Após a aprovação de uma alteração, verifique primeiro o acesso autorizado previsto, por exemplo, pelo agente de monitorização local. Em seguida, a partir de um local da rede expressamente não autorizado, verifique tanto a página HTML como a variante ?auto. Nenhum dos dois pode fornecer dados de estado nesse local. Não basta realizar um teste num único local ou numa única via de acesso.

Repete o teste para os hosts virtuais efetivamente acessíveis e, se for o caso, para ligações diretas e aquelas encaminhadas através de um proxy reverso. O sucesso a nível local não comprova que o proxy aplique a mesma proteção. Preste também atenção aos redirecionamentos: o que é decisivo é se, no final de um caminho de acesso, são divulgados dados de estado sensíveis.

Se uma consulta autorizada falhar, verifique, além da Autorização bem como o listener, o endereço e a porta, e a seleção do host virtual. As regras de proxy e de redirecionamento também podem encaminhar o pedido de forma diferente do esperado. Por isso, um único erro não permite concluir com certeza que se trata de uma regra de acesso incorreta nem de um handler defeituoso.

Verifique se as configurações existentes contêm diretivas de acesso desatualizadas, tais como Order e Deny. A sua mistura imprudente com os mais recentes Require-As regras podem conduzir a resultados inesperados. Verifica a combinação que está efetivamente em vigor, em vez de deduzir o acesso final a partir de uma única regra que o permita.

Além disso, uma localização protegida não é necessariamente o único ponto final de estado possível. Se o mod_status estiver carregado, o seu manipulador também pode ser definido em configurações específicas por diretório, incluindo .htaccess estar disponível. Por isso, verifica as entradas existentes e as delegações permitidas, especialmente em servidores partilhados, para que não seja possível configurar mais nenhum handler desprotegido.

Das pistas às decisões operacionais

Se, repetidamente, houver muitos trabalhadores ocupados e apenas alguns disponíveis, isso é um indício de uma possível pressão sobre a capacidade, mas ainda não constitui uma prova da causa. Compare a evolução com os tempos de resposta, as taxas de erro e o limite de trabalhadores efetivamente em vigor. Só o panorama global revela se a ocupação coincide com problemas percetíveis e qual é a sua durabilidade.

Antes de aumentar um limite, verifique a memória disponível e as necessidades adicionais dos processos ou threads em questão. Ao mesmo tempo, analise por que razão os processamentos demoram tanto: um maior paralelismo pode não resolver a causa real do problema e consumir ainda mais recursos. Por isso, as alterações devem ser integradas num processo operacional controlado, seguido de monitorização.

No caso de pedidos lentos, as consultas repetidas ao estado ajudam a identificar os pedidos atuais e os processos associados. Compara os horários com os registos de acesso e de erros, bem como com os dados da aplicação e dos seus back-ends. Uma solicitação efémera pode desaparecer entre duas verificações; uma única indicação não identifica de forma fiável uma determinada aplicação como causa, nem comprova a existência de um ataque.

Para um visual marcante ID do processo Podes verificar, adicionalmente, dados do sistema operativo, como a utilização da CPU e da memória. Esta correspondência constitui mais uma pista, não substituindo a comparação temporal com os pedidos e os registos. Especialmente no caso de observações repetidas, deves ter em conta que os processos e os pedidos que estão a ser processados nesse momento podem variar.

No caso do event-MPM, tenha também em atenção os processos em fase de encerramento e as gerações antigas após um reinício suave. Estes podem influenciar o panorama durante a transição; as ligações abertas não devem ser, de forma generalizada, equiparadas a threads de trabalho permanentemente ocupadas. Verifique as particularidades da versão do Apache 2.4 instalada antes de tirar conclusões sobre a capacidade a longo prazo com base numa fase de transição como esta.