“ O ModSecurity vai ajudar você a dormir melhor à noite porque, acima de tudo, resolve o problema de visibilidade: ele permite que você veja seu tráfego da web. ”
Quando algo não está funcionando como você espera, os registros são sempre o primeiro lugar a ser procurado. Bons registros podem fornecer insights valiosos para ajudar você a solucionar os problemas que está enfrentando. Uma das razões pelas quais Ivan Ristić criou originalmente o ModSecurity é que ele estava frustrado com a falta de visibilidade nas ferramentas que estava usando. Não é nenhuma surpresa, então, que o ModSecurity tenha amplos recursos de registro e depuração.
O ModSecurity tem dois tipos de logs:
O log de auditoria é útil para saber não apenas por que um ataque individual foi bloqueado, mas para descobrir mais sobre os padrões gerais de ataque. Você pode se surpreender com a quantidade de tráfego de bots e scanners que obtém apenas expondo as portas 80 e/ou 443 à Internet.
Nesta postagem do blog, descreveremos os princípios básicos de registro e depuração com o ModSecurity.
O log principal no ModSecurity é o log de auditoria, que registra todos os ataques, incluindo ataques potenciais, que ocorrem. Se você seguiu nossas instruções de instalação para o ModSecurity (com NGINX Open Source ) ou o NGINX ModSecurity WAF (com NGINX Plus ), então, por padrão, o ModSecurity registrará todas as transações que acionaram um aviso ou erro, bem como todas as transações que resultaram em respostas 5xx
e 4xx
, exceto para404
. (Somente para um sistema Ubuntu 16.04, o log de auditoria está em /var/log/modsec_audit.log .)
O log de auditoria do ModSecurity é particionado em seções. Isso torna mais fácil escanear o log e encontrar as informações que você está procurando. A tabela abaixo descreve o que cada seção contém:
Seção | Descrição |
---|---|
A | Cabeçalho do log de auditoria (obrigatório) |
B | Cabeçalhos de solicitação |
C | Corpo da solicitação |
D | Reservado |
E | Corpo de resposta |
F | Cabeçalhos de resposta |
G | Reservado |
H | Trailer do log de auditoria, que contém dados adicionais |
I | Alternativa compacta do corpo da solicitação (para a parte C), que exclui arquivos |
J | Informações sobre arquivos enviados |
K | Contém uma lista de todas as regras que correspondem à transação |
Z | Limite final (obrigatório) |
Cada transação que aciona uma entrada de log de auditoria terá qualquer uma ou todas as seções acima registradas. Você pode configurar quais seções serão registradas.
Um exemplo de entrada de log de auditoria do ModSecurity pode ser parecido com este:
---ICmPEb5c---A--[04/Out/2017:21:45:15 +0000] 150715351558.929952 141.212.122.16 64384 141.212.122.16 80
---ICmPEb5c---B--
GET / HTTP/1.1
Host: 54.183.57.254
Agente do usuário: Mozilla/5.0 zgrab/0.x
Aceitar codificação: gzip
---ICmPEb5c---D--
---ICmPEb5c---F--
HTTP/1.1 200
Servidor: nginx/1.13.4
Data: Qua, 04 Out 2017 21:45:15 GMT
Tipo de conteúdo: text/html
Conexão: keep-alive
---ICmPEb5c---H--
ModSecurity: Aviso. Correspondeu "Operador `Rx' com parâmetro `^[d.:]+$' contra variável `REQUEST_HEADERS:Host' (Valor: `54.183.57.254' ) [arquivo "/root/owasp
-v3/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [linha "733"] [id "920350"] [rev "2"] [msg "O cabeçalho do host é um endereço IP numérico"] [dados "54.183.57.254"] [s
everidade "4"] [ver "OWASP_CRS/3.0.0"] [maturidade "9"] [precisão "9"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-prot
ocol"] [tag "OWASP_CRS/VIOLAÇÃO_DE_PROTOCOLO/IP_HOST"] [etiqueta "WASCTC/WASC-21"] [etiqueta "OWASP_TOP_10/A7"] [etiqueta "PCI/6.5.10"] [ref "o0,13v21,13"]
---ICmPEb5c---I--
---ICmPEb5c---J--
---ICmPEb5c---Z--
Embora não fique imediatamente aparente na tabela acima, a melhor seção para encontrar informações sobre o motivo pelo qual uma solicitação específica foi bloqueada é a seção H, não a seção K. No exemplo de log de auditoria acima, se examinarmos a seção H, podemos ver a mensagem "O cabeçalho do host é um endereço IP numérico"
, que indica que alguém tentou acessar nosso site pelo endereço IP e não pelo nome do host. Isso pode ser indicativo de um scanner.
Se você seguiu nossas instruções para instalar e configurar o ModSecurity, encontrará a configuração de registro de auditoria em /etc/nginx/modsec/modsecurity.conf . Nesse arquivo, você verá as três diretivas a seguir que controlam o que é colocado no log de auditoria:
SecAuditEngine RelevantOnlySecAuditLogRelevantStatus "^(?:5|4(?!04))"
SecAuditLogParts ABIJDEFHZ
onde
SecAuditEngine
– Controla o que deve ser registrado. As opções são:
Desligado
– Desabilita o log de auditoria.Ativado
– Registra todas as transações, o que pode ser útil na depuração.RelevantOnly
– Registre somente transações que acionaram um aviso/erro ou que tenham um código de status que corresponda ao que está na diretiva SecAuditLogRelevantStatus
.SecAuditLogRelevantStatus
– Se SecAuditEngine
estiver definido como RelevantOnly
, esta diretiva controlará quais códigos de status de resposta HTTP devem ser registrados. É baseado em expressões regulares. O valor acima registrará todas as respostas 5xx
e 4xx
, excluindo404
e.
SecAuditLogParts
– Controla quais seções devem ser incluídas no log de acesso. Remover seções nas quais você não está interessado reduz o tamanho do log de auditoria e facilita a verificação.
Para obter diretivas adicionais de configuração de registro de auditoria, consulte o wiki do ModSecurity .
Quando o log de depuração é ativado, ele fornece uma grande quantidade de informações sobre tudo o que o ModSecurity faz. Para solucionar problemas sobre por que algo não está funcionando como você espera, o log de depuração é seu recurso preferido. Também é ótimo se você está começando a usar o ModSecurity e quer observar por que ele faz as coisas de uma certa maneira.
O log de depuração se parece com o seguinte. Ele contém muitos detalhes sobre as ações que o ModSecurity realiza para toda e qualquer transação:
[4] (Regra: 1234) Executando o operador "Contém" com o parâmetro "teste" em ARGS:testparam.[9] Valor de destino: "teste" (Variável: ARGS:testparam)
[9] Variáveis correspondentes atualizadas.
[4] Executando ação [independente] (não disruptiva): log
[9] Salvando transação em logs
[4] Regra retornou 1.
[9] (SecDefaultAction) Executando ação: log
[9] Salvando transação em logs
[9] (SecDefaultAction) Executando ação: auditlog
[4] (SecDefaultAction) ignorando ação: pass (regra contém uma ação disruptiva)
[4] Executando ação (não disruptiva): auditlog
[4] Executando ação (disruptiva): deny
O log de depuração lista o número de ID da regra para facilitar a pesquisa. Neste exemplo, a saída é da nossa regra de teste com número de ID 1234.
Por padrão, o log de depuração está desabilitado, pois pode afetar negativamente o desempenho. Assim como no registro de auditoria, o registro de depuração é configurado em /etc/nginx/modsec/modsecurity.conf . Nesse arquivo, há duas diretivas de configuração comentadas. Para habilitar o registro de depuração, descomente-os e altere-os para o seguinte:
SecDebugLog /var/log/modsec_debug.logSecDebugLogNível 9
onde
0
–9
indica quanta informação registrar, com9
sendo o máximo. Se você estiver solucionando problemas, defina este valor como9
é o mais útil.Nesta postagem do blog, abordamos como começar a usar os amplos recursos de registro do ModSecurity. O ModSecurity tem logs de auditoria, que contêm informações sobre todas as transações bloqueadas, e um log de depuração para ajudar ainda mais você caso esteja tendo problemas ao usar o ModSecurity.
O ModSecurity 3.0 está disponível para NGINX Open Source e como NGINX ModSecurity WAF para NGINX Plus. O NGINX ModSecurity WAF é um módulo dinâmico pré-compilado que é mantido e totalmente suportado pela NGINX, Inc. Experimente gratuitamente por 30 dias .
[ Editor – O NGINX ModSecurity WAF foi oficialmente encerrado em 1º de abril de 2022 e está em transição para o fim da vida útil em 31 de março de 2024 . Para mais detalhes, veja F5 NGINX ModSecurity WAF está em transição para o fim da vida útil<.htmla> em nosso blog.]
"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."