Requisições de entrada contínuas não provam que terceiros ainda podem usar o proxy. Pontos finais antigos podem permanecer nas listas de requisições depois de a política de acesso mudar. Verifique o reparo pelo que é encaminhado:

  1. Faça requisições autorizadas e não autorizadas para um destino controlado.
  2. Leia a decisão de acesso e, para o Squid, os campos de hierarquia no formato de log configurado.
  3. Determine se a requisição proibida realmente chegou ao destino. Aceitar TCP, rejeitar uma requisição HTTP e concluir uma requisição posterior são resultados diferentes.
  4. Verifique os demais ouvintes ativos e hosts virtuais, para que um bloco de política reparado não deixe outra entrada aberta.

Para Apache destinado apenas a mapeamentos reversos, confirme que o proxy direto não intencional está desativado. ProxyRequests Off pode coexistir com ProxyPass.

Uma página de erro sozinha é evidência mais fraca se você não sabe qual componente a produziu. Mantenha juntos o resultado do cliente, a decisão do proxy e a observação no destino.

Se o tráfego rejeitado ainda consome recursos, restrinja o acesso de rede e gerencie taxas e retenção de logs. Não existe um período de espera confiável após o qual as tentativas devam parar; decisões corretas de encaminhamento são o critério de aceitação.

Artigos relacionados