“O ModSecurity ajudará você a dormir melhor à noite porque, acima de tudo, resolve o problema da visibilidade: ele permite que você veja o tráfego da sua aplicação web.”
– Ivan Ristić, criador do ModSecurity
Quando algo não está funcionando como esperado, os logs são sempre o primeiro lugar a verificar. Bons logs podem fornecer informações valiosas para ajudar você a solucionar os problemas que está enfrentando. Um dos motivos que levaram Ivan Ristić a criar o ModSecurity foi sua frustração com a falta de visibilidade das ferramentas que utilizava. Portanto, não é de surpreender que o ModSecurity tenha amplos recursos de registro em log e depuração.
O ModSecurity tem dois tipos de logs:
- Um log de auditoria. Para cada transação bloqueada, o ModSecurity fornece logs detalhados sobre a transação e o motivo pelo qual ela foi bloqueada.
- Um log de depuração. Quando ativado, esse log registra informações detalhadas sobre tudo o que o ModSecurity faz.
O log de auditoria é útil não apenas para entender por que um ataque específico foi bloqueado, mas também para saber mais sobre os padrões gerais de ataque. Você pode se surpreender com a quantidade de tráfego de bots e scanners que recebe simplesmente ao expor as portas 80 e/ou 443 à Internet.
Neste post do blog, descreveremos os conceitos básicos de registro de logs e depuração com o ModSecurity.
Log de auditoria
O principal log do ModSecurity é o log de auditoria, que registra todos os ataques ocorridos, inclusive possíveis ataques. Se você seguiu nossas instruções de instalação do ModSecurity (com NGINX Open Source) ou do NGINX ModSecurity WAF (com NGINX Plus), 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 404. (Somente em sistemas Ubuntu 16.04, o log de auditoria fica em /var/log/modsec_audit.log.)
O log de auditoria do ModSecurity é dividido em seções. Isso facilita a análise do log e a localização das informações que você procura. A tabela abaixo descreve o conteúdo de cada seção:
| Seção | Descrição |
|---|---|
| A | Cabeçalho do log de auditoria (obrigatório) |
| B | Cabeçalhos da solicitação |
| C | Corpo da solicitação |
| D | Reservado |
| E | Corpo da resposta |
| F | Cabeçalhos da resposta |
| G | Reservado |
| H | Rodapé do log de auditoria, que contém dados adicionais |
| I | Alternativa compacta ao corpo da solicitação (parte C), que exclui arquivos |
| J | Informações sobre os arquivos enviados |
| K | Contém uma lista de todas as regras que corresponderam à transação |
| Z | Delimitador final (obrigatório) |
Cada transação que acionar uma entrada no log de auditoria terá uma ou todas as seções acima registradas. Você pode configurar quais seções serão registradas.
Exemplo de log de auditoria
Uma entrada de exemplo do log de auditoria do ModSecurity pode ter a seguinte aparência:
---ICmPEb5c---A--[04/Oct/2017:21:45:15 +0000] 150715351558.929952 141.212.122.16 64384 141.212.122.16 80---ICmPEb5c---B--GET / HTTP/1.1Host: 54.183.57.254User-Agent: Mozilla/5.0 zgrab/0.xAccept-Encoding: gzip---ICmPEb5c---D-----ICmPEb5c---F--HTTP/1.1 200Server: nginx/1.13.4Date: Wed, 04 Oct 2017 21:45:15 GMTContent-Type: text/htmlConnection: keep-alive---ICmPEb5c---H--ModSecurity: Warning. Matched "Operator `Rx' with parameter `^[d.:]+$' against variable `REQUEST_HEADERS:Host' (Value: `54.183.57.254' ) [file "/root/owasp-v3/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "733"] [id "920350"] [rev "2"] [msg "Host header is a numeric IP address"] [data "54.183.57.254"] [severity "4"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "9"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/IP_HOST"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [ref "o0,13v21,13"]---ICmPEb5c---I-----ICmPEb5c---J-----ICmPEb5c---Z--Embora isso não fique imediatamente evidente na tabela acima, a melhor seção para encontrar informações sobre o motivo pelo qual uma determinada solicitação foi bloqueada é a seção H, e não a seção K. No exemplo de log de auditoria acima, ao examinarmos a seção H, podemos ver a mensagem "O cabeçalho Host é um endereço IP numérico" que indica que alguém tentou acessar nosso site pelo endereço IP, em vez de usar o nome do host. Isso pode indicar a ação de um scanner.
Configuração do registro de auditoria
Se você seguiu nossas instruções para instalar e configurar o ModSecurity, encontrará a configuração do registro de auditoria em /etc/nginx/modsec/modsecurity.conf. Nesse arquivo, você verá as três diretivas a seguir, que controlam o que é incluído no registro de auditoria:
SecAuditEngine RelevantOnlySecAuditLogRelevantStatus "^(?:5|4(?!04))"SecAuditLogParts ABIJDEFHZonde
SecAuditEngine– Controla o que deve ser registrado. As opções são:Desativado– Desativa o log de auditoria.Ativado– Registra todas as transações, o que pode ser útil durante a depuração.RelevantOnly– Registra apenas as transações que acionaram um aviso/erro ou que têm um código de status correspondente ao definido na diretivaSecAuditLogRelevantStatus.
SecAuditLogRelevantStatus–Se SecAuditEngineestiver definido comoRelevantOnly, esta diretiva controlará quais códigos de status de resposta HTTP deverão ser registrados. Ela é baseada em expressões regulares. O valor acima registrará todas as respostas5xxe4xx, exceto as404.SecAuditLogParts– Controla quais seções devem ser incluídas no log de acesso. Remover as seções que não são do seu interesse reduz o tamanho do log de auditoria e facilita sua análise.
Para obter mais diretivas de configuração de registro de auditoria, consulte a wiki do ModSecurity.
Log de depuração
Quando o log de depuração está ativado, ele fornece uma grande quantidade de informações sobre tudo o que o ModSecurity faz. Para solucionar problemas e entender por que algo não está funcionando como esperado, o log de depuração é o recurso ideal. Ele também é muito útil se você está começando a usar o ModSecurity e quer observar por que ele executa determinadas ações de uma certa maneira.
Exemplo de log de depuração
O log de depuração tem a aparência mostrada a seguir. Ele contém muitos detalhes sobre as ações que o ModSecurity executa em todas as transações:
[4] (Rule: 1234) Executing operator "Contains" with param "test" against ARGS:testparam.[9] Target value: "test" (Variable: ARGS:testparam)[9] Matched vars updated.[4] Running [independent] (non-disruptive) action: log[9] Saving transaction to logs[4] Rule returned 1.[9] (SecDefaultAction) Running action: log[9] Saving transaction to logs[9] (SecDefaultAction) Running action: auditlog[4] (SecDefaultAction) ignoring action: pass (rule contains a disruptive action)[4] Running (non-disruptive) action: auditlog[4] Running (disruptive) action: denyO 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 o número de ID 1234.
Configuração do log de depuração
Por padrão, o log de depuração fica desabilitado, pois pode afetar negativamente o desempenho. Assim como o log de auditoria, o log de depuração é configurado em /etc/nginx/modsec/modsecurity.conf. Nesse arquivo, há duas diretivas de configuração comentadas. Para habilitar o log de depuração, remova os comentários e altere-as para o seguinte:
SecDebugLog /var/log/modsec_debug.logSecDebugLogLevel 9onde
- SecDebugLog – Especifica o caminho para o arquivo de log de depuração.
- SecDebugLogLevel –
0–9indica a quantidade de informações a serem registradas, sendo9o nível mais detalhado. Se você estiver solucionando problemas, definir esse valor como9será mais útil.
Conclusão
Nesta publicação do blog, mostramos como começar a usar os amplos recursos de registro do ModSecurity. O ModSecurity oferece logs de auditoria, que contêm informações sobre todas as transações bloqueadas, e um log de depuração para ajudar ainda mais caso você tenha dificuldades ao usar o ModSecurity.
O ModSecurity 3.0 está disponível tanto para o NGINX Open Source quanto como o NGINX ModSecurity WAF para o NGINX Plus. O NGINX ModSecurity WAF é um módulo dinâmico pré-compilado, mantido e totalmente compatível com o suporte da NGINX, Inc. Experimente gratuitamente por 30 dias.
[Editor – O NGINX ModSecurity WAF saiu oficialmente de comercialização em 1º de abril de 2022 e está em transição para o fim da vida útil, que entrará em vigor em 31 de março de 2024. Para obter mais detalhes, consulte O F5 NGINX ModSecurity WAF está em transição para o fim da vida útil<.htmla> em nosso blog.]
Sobre o autor
Publicações relacionadas no blog
Como o F5 NGINX One aprimora o gerenciamento e a observabilidade
Descubra como o F5 NGINX One aprimora o gerenciamento e a observabilidade de ambientes híbridos e multicloud ao oferecer um console web centralizado baseado em SaaS, com insights em tempo real, conformidade automatizada e gerenciamento simplificado de configurações.
Do OpenAPI ao NGINX como gateway de API usando uma API declarativa
Descubra como transformar uma definição de esquema OpenAPI em uma configuração NGINX totalmente funcional, operando como um API Gateway com a segurança de um Web Application Firewall e um Portal do Desenvolvedor, usando uma abordagem declarativa de API.
Como gerenciar picos repentinos de tráfego e sobrecarga do servidor
Picos de tráfego e sobrecarga de servidores são preocupações sérias para varejistas online em qualquer época, mas especialmente durante a “Cyber Season” de compras de fim de ano. Detalhamos como você pode aproveitar as soluções de entrega de aplicações de nível de produção da NGINX para se preparar para aumentos repentinos de tráfego.
Distribuição segura de chaves privadas SSL com o NGINX
Descrevemos três maneiras progressivamente mais seguras de proteger chaves privadas SSL ao configurar o NGINX para processar tráfego HTTPS: permitir acesso de leitura apenas ao usuário root, criptografar as chaves com senhas armazenadas separadamente e distribuir as senhas a partir de um repositório central.
Agrupando solicitações de API em lotes com NGINX Plus e o módulo JavaScript do NGINX
O módulo JavaScript do NGINX lançado com o NGINX Plus R15 oferece suporte a subsolicitações, possibilitando uma classe totalmente nova de casos de uso para o NGINX Plus. Este exemplo completo também usa a API do NGINX Plus e os módulos de chave-valor para converter solicitações de API dos clientes em solicitações separadas para as APIs dos microsserviços que compõem um aplicativo.
Como superar o esgotamento de portas efêmeras no NGINX e no NGINX Plus
Confira dicas para evitar o esgotamento de portas efêmeras com ajustes no kernel do Linux, conexões keepalive e conexões vinculadas dinamicamente a endereços IP locais.