Um painel PHP que transforma logs brutos do WAF em inteligência acionável: avaliação de risco em tempo real, enriquecimento geográfico e bloqueio automático de IPs via firewalld — sem nenhuma infraestrutura externa.

Toda aplicação web exposta à internet pública recebe, em poucos minutos após entrar no ar, um fluxo constante de requisições automatizadas: scanners de vulnerabilidades procurando exploits conhecidos, bots coletando conteúdo, tentativas de força bruta contra formulários de login e requisições de reconhecimento mapeando a estrutura do site. A resposta padrão a essa realidade é implantar um Web Application FirewallUm WAF (Web Application Firewall) é uma camada de segurança entre a internet e a aplicação web, inspecionando o tráfego HTTP e bloqueando requisições maliciosas com base em regras configuráveis. — um WAF — que filtra o tráfego segundo regras predefinidas. Mas um WAF sozinho gera dados, não compreensão. Os logs se acumulam, o armazenamento cresce e, na maioria dos casos, ninguém os examina até que algo já tenha dado errado.

Este é o problema que me propus a resolver. SecureLog é um painel WAF que projetei e construí para transformar dados brutos de logs HTTP em inteligência operacional: um sistema que não apenas exibe o que está acontecendo na sua infraestrutura web, mas analisa, avalia e — quando as evidências justificam — age autonomamente bloqueando endereços IP maliciosos no nível do firewall.

Neste artigo, descrevo a arquitetura, o raciocínio por trás das escolhas de design e como cada componente trabalha em conjunto para criar um sistema de monitoramento de segurança em ciclo fechado.

O problema: logs sem contexto

Um servidor web LAMP/LEMPLAMP significa Linux, Apache, MySQL, PHP. LEMP substitui o Apache pelo Nginx. Ambos são pilhas de servidor padrão para hospedagem de aplicações web. típico gera logs de acesso no Combined Log FormatUm formato de log padrão usado pelo Apache e Nginx. Cada linha registra o IP do cliente, timestamp, método HTTP, URI, código de status, tamanho da resposta, referrer e string de user agent.: uma linha por requisição, contendo o IP do cliente, timestamp, método HTTP, URI solicitado, código de status, referrer e user agent. Em um site com tráfego moderado, isso significa dezenas de milhares de linhas por dia.

Os dados brutos estão lá, mas extrair significado deles é um desafio completamente diferente. Quais dessas 30.000 requisições diárias são visitantes legítimos? Quais são crawlers de mecanismos de busca? Quais estão procurando /wp-login.php em um site que não usa WordPress? Quais estão tentando injeção SQLUma técnica de ataque em que instruções SQL maliciosas são inseridas em campos de entrada ou URLs, na tentativa de manipular ou extrair dados do banco de dados da aplicação. através dos parâmetros da query? E, crucialmente — quais endereços IP estão fazendo isso de forma persistente o suficiente para justificar o bloqueio no nível do firewall?

Responder a essas perguntas manualmente não é sustentável. Eu precisava de um pipeline automatizado capaz de ingerir logs, enriquecê-los com análise de ameaças e dados de geolocalização, apresentar os resultados através de uma interface intuitiva e fornecer capacidades de resposta tanto manuais quanto automatizadas.

Visão geral da arquitetura

O SecureLog é construído sobre um backend PHP com um frontend JavaScript, projetado para funcionar ao lado do servidor web que monitora. A arquitetura segue uma clara separação de responsabilidades em seis componentes, cada um implementado como um arquivo distinto com uma função específica.

O frontend (index.php) é uma aplicação de página única com uma estrutura de navegação por barra lateral, construída com JavaScript puro e Chart.jsUma biblioteca JavaScript open-source para criação de gráficos responsivos e animados. O SecureLog a utiliza para linhas de tendência de tráfego e visualizações da distribuição de códigos de status HTTP.. Comunica-se de forma assíncrona com o backend através de um gateway de API unificado (api.php) que roteia todas as requisições AJAXAsynchronous JavaScript and XML — uma técnica para fazer requisições HTTP a partir do navegador sem recarregar a página, permitindo atualizações de dados em tempo real no painel. para a função handler apropriada. A autenticação e o gerenciamento de sessões são tratados por um módulo de segurança dedicado (auth.php e login.php), que impõe HTTPS, parâmetros seguros de cookies e validação de token CSRFCross-Site Request Forgery: um ataque que induz o navegador do usuário a fazer requisições indesejadas. O SecureLog previne isso gerando e validando um token único para cada sessão..

No lado do processamento backend, um processador de logs CLI (LogProcessor.php) é executado como tarefa agendada, lendo os logs de acesso brutos de forma incremental e passando cada linha pelo motor de análise de risco (RiskAnalyzer.php). Por fim, um script de sincronização do firewall (SynchronizeFirewall.sh) faz a ponte entre as decisões da aplicação e a configuração do firewalldA ferramenta padrão de gerenciamento de firewall em sistemas RHEL/CentOS/AlmaLinux. Suporta ipsets — coleções nomeadas de endereços IP que podem ser usadas em regras de firewall para bloqueio em massa eficiente. do sistema operacional, aplicando bloqueios e desbloqueios em tempo real.

O motor de análise de risco

No coração do SecureLog está a classe RiskAnalyzer — o componente que transforma uma linha de log bruta em uma avaliação quantificada da ameaça. A filosofia de design é direta: cada requisição recebe uma pontuação de risco numérica, calculada avaliando múltiplos sinais independentes e somando suas contribuições ponderadas.

A análise procede através de seis verificações sequenciais:

Detecção de scanners agressivos. A string de user agent é comparada com uma biblioteca configurável de assinaturas de scanners maliciosos conhecidos — ferramentas como Nikto, sqlmap, DirBuster e utilitários de reconhecimento similares. Uma correspondência positiva contribui com um componente de pontuação elevado, pois a mera presença dessas ferramentas indica atividade de sondagem deliberada.

Reconhecimento de padrões de ataque. O URI completo da requisição é escaneado em busca de assinaturas de vetores de ataque comuns: fragmentos de injeção SQL (UNION SELECT, OR 1=1), sequências de travessia de diretóriosUm ataque que usa sequências como ../../ em URLs para escapar do diretório raiz web e acessar arquivos arbitrários no servidor, como /etc/passwd., payloads XSSCross-Site Scripting: um ataque em que JavaScript malicioso é injetado em páginas web visualizadas por outros usuários, tipicamente através de parâmetros de URL ou campos de formulário. e tentativas de injeção de comandos. A biblioteca de assinaturas é carregada de um arquivo de configuração centralizado e compilada em expressões regularesExpressões de correspondência de padrões usadas para identificar strings que correspondem a uma estrutura específica. O RiskAnalyzer compila todas as assinaturas de cada categoria em uma única regex para performance, usando preg_quote() para escaping seguro. otimizadas na inicialização.

Sondagem de arquivos sensíveis. Requisições direcionadas a arquivos que nunca deveriam ser acessíveis externamente — arquivos de configuração, arquivos de backup, diretórios de controle de versão, dumps de banco de dados — são sinalizadas com uma pontuação dedicada. Isso intercepta a fase de reconhecimento que tipicamente precede um ataque direcionado.

Análise de anomalias do user agent. Strings de user agent ausentes ou suspeitamente curtas recebem uma penalidade de pontuação. Navegadores legítimos sempre enviam um user agent substancial; sua ausência é um forte indicador de ferramentas automatizadas. Bots passivos conhecidos — crawlers de mecanismos de busca, serviços de monitoramento — são identificados separadamente e avaliados em um nível inferior.

Análise do comprimento do URI. Requisições com URIs superiores a 200 caracteres recebem um componente de pontuação adicional. URIs anormalmente longos são característicos de ataques de injeção, onde o payload está embutido na query string.

Avaliação do código de status HTTP. Respostas 404 repetidas do mesmo IP sugerem sondagem sistemática de caminhos inexistentes — uma técnica clássica de enumeração.

As seis pontuações individuais são somadas em uma pontuação de risco composta, que é então classificada em cinco níveis de gravidade: CLEAN, LOW, MEDIUM, HIGH e CRITICAL. Os limiares para cada nível são definidos na configuração centralizada, tornando o sistema ajustável sem alterações no código.

O pipeline de processamento de logs

O script LogProcessor.php é a espinha dorsal operacional do sistema. Ele é executado como processo CLICommand Line Interface — o script é projetado para ser executado a partir do terminal do servidor ou por um agendador cron, não através de um navegador web. Ele recusa explicitamente a execução HTTP por segurança., tipicamente acionado pelo cronUm agendador de tarefas baseado em tempo no Unix/Linux. O processador de logs do SecureLog é tipicamente agendado para ser executado a cada poucos minutos, garantindo análise quase em tempo real sem consumo constante de recursos. em intervalos regulares, e executa três fases distintas em sequência.

Fase 1: Importação incremental dos logs. O processador lê os arquivos de log de acesso para cada site monitorado, partindo da última posição de offset conhecida. Esta é uma escolha de design crítica — o sistema nunca reprocessa dados já vistos, o que mantém os tempos de execução previsíveis independentemente do tamanho do arquivo de log. Cada linha é analisada usando uma abordagem híbrida: o script tenta primeiro um parser regex padrão para o Combined Log Format, e recorre a um parser delimitado por tabulação quando o formato diverge. Os dados analisados são normalizados: endereços IP, user agents e referrers são resolvidos em IDs internos através de um cache em memóriaUm array associativo PHP que armazena pesquisas de banco de dados previamente resolvidas (sites, IPs, user agents, referrers) pela duração do lote. Isso elimina consultas SELECT redundantes quando o mesmo IP ou user agent aparece milhares de vezes em um único arquivo de log. apoiado por consultas ao banco de dados, minimizando queries redundantes. Cada linha é então passada pelo RiskAnalyzer, e tanto o registro de acesso quanto sua avaliação de risco são inseridos no banco de dados usando operações em loteEm vez de executar um INSERT por linha de log, o processador acumula registros e os executa em lotes configuráveis. Isso reduz drasticamente o número de idas e voltas ao banco de dados e melhora a vazão em arquivos de log grandes. para eficiência.

Fase 2: Resolução de geolocalização. Após a conclusão da fase de importação, o processador identifica todos os endereços IP sem dados geográficos e os resolve através de chamadas API concorrentes a um serviço de geolocalização. Os resultados — país, cidade, ISP e número de sistema autônomoUm ASN (Autonomous System Number) identifica o operador de rede responsável por um bloco de endereços IP. Conhecer o ASN ajuda a distinguir o tráfego proveniente de provedores de hospedagem legítimos, serviços de nuvem e redes reconhecidamente maliciosas. — são armazenados junto ao registro do IP. Esse enriquecimento é essencial para as capacidades de análise geográfica do painel e para identificar padrões como tráfego de ataque concentrado de regiões específicas.

Fase 3: Processamento automatizado de bloqueios. A fase final é onde a análise se torna ação. A classe BanProcessor consulta o banco de dados de eventos de risco em busca de endereços IP cuja atividade cumulativa de ameaça ultrapassa limiares configuráveis. Os limiares são diferenciados por gravidade: um único evento CRITICAL pode ser suficiente para acionar um bloqueio, enquanto eventos de gravidade LOW requerem uma contagem mais alta dentro de uma janela de retrospecçãoUma janela temporal configurável (padrão: 24 horas) dentro da qual os eventos de risco são contabilizados. Eventos anteriores à janela de retrospecção são excluídos do cálculo de limiares, impedindo que dados obsoletos acionem bloqueios em IPs cujo comportamento mudou. definida — tipicamente 24 horas. Quando um IP ultrapassa o limiar, o processador atualiza seu status para BANNED e define a flag de sincronização do firewall como PENDING, sinalizando que a alteração ainda não foi aplicada no nível do sistema operacional.

Toda a execução é protegida por um mecanismo de arquivo de bloqueioUma técnica de exclusão mútua: o script cria um arquivo temporário na inicialização e o remove ao concluir. Se o arquivo de bloqueio já existe, o script é interrompido, impedindo que duas instâncias processem os mesmos dados simultaneamente. que impede a sobreposição de instâncias concorrentes — uma salvaguarda essencial quando o processamento é agendado em intervalos frequentes.

Sincronização do firewall

A ponte entre as decisões do SecureLog e a aplicação efetiva no nível de rede é o SynchronizeFirewall.sh — um script Bash que lê o estado do banco de dados e aplica alterações na configuração do firewalld do servidor através de ipsetsColeções nomeadas de endereços IP gerenciadas pelo firewalld. O SecureLog mantém dois ipsets: bad_ips para endereços IPv4 e bad_ipv6s para endereços IPv6. A associação a esses conjuntos aciona regras de firewall que bloqueiam todo o tráfego dos IPs listados..

A sincronização opera em quatro fases, tratando IPv4 e IPv6 separadamente para acomodar as diferentes famílias de ipset exigidas pelo firewalld. Para cada versão do protocolo, o script processa duas operações: adição (aplicação de novos bloqueios) e remoção (suspensão de bloqueios para IPs cujo status mudou para ALLOWED ou WHITELISTED). Em todos os casos, o script consulta exclusivamente registros onde firewall_status = 'PENDING', processa apenas essas alterações e atualiza o status para APPLIED após a execução bem-sucedida.

Esse design — separar a decisão (o que bloquear) da aplicação (como bloquear) — oferece diversas vantagens. A aplicação PHP nunca precisa de privilégios root; ela apenas escreve no banco de dados. O script Bash, que requer permissões elevadas para modificar o firewalld, opera sobre uma interface mínima e bem definida: uma única coluna do banco de dados que funciona como fila de mensagens. Um mecanismo de segurança garante que um “IP seguro” predefinido — tipicamente o endereço do administrador — nunca seja adicionado a uma lista de bloqueio, independentemente do que a análise de risco produza.

Após processar todas as alterações pendentes, o script aciona um firewall-cmd --reload apenas se pelo menos uma modificação foi feita, e produz um relatório resumido de todas as operações realizadas.

A interface do painel

O frontend é uma aplicação de página única estruturada em torno de cinco abas funcionais, acessíveis através de uma barra de navegação lateral escura. Todo o fluxo de dados é assíncrono: cada visualização se popula através de chamadas API ao api.php, e a interface suporta deep linking e navegação no histórico do navegador através de um sistema de roteamento de URLO painel utiliza a API HTML5 History (pushState/popState) para manter URLs salváveis para cada aba e estado de filtro. Navegar para /dashboard/?tab=logs&ip=1.2.3.4 restaura a visualização exata. personalizado.

Visão geral. A aba principal apresenta oito indicadores-chave de desempenho em uma grade de cartões: total de requisições, eventos críticos nos últimos sete dias, IPs bloqueados, IPs únicos, países únicos, tráfego útil (sete dias e total) e ameaças totais. Abaixo dos KPIs, três painéis de visualização mostram a tendência de tráfego da última semana como gráfico de linha, a distribuição dos códigos de status HTTP como gráfico de rosca, e um ranking das dez páginas mais visitadas. Um quarto painel — a tabela de decomposição de risco — exibe a contagem de eventos por categoria de ameaça (scanners agressivos, padrões de ataque, sondagem de arquivos sensíveis), proporcionando uma visão direta da natureza das ameaças detectadas.

Tráfego & Logs. Uma tabela paginada e filtrável mostrando registros individuais do log de acesso com suas pontuações de risco associadas. Cada linha pode ser expandida para exibir detalhes completos, e os endereços IP são clicáveis: selecionar um filtra toda a visualização para mostrar todas as requisições daquele endereço. A partir desta aba, IPs individuais podem ser bloqueados ou desbloqueados com uma única ação, e operações em massa permitem bloquear ou desbloquear todos os IPs visíveis na página atual ou em todo o conjunto de resultados filtrados.

Gerenciamento de bloqueios. Uma visualização dedicada ao monitoramento e gerenciamento do inventário completo de IPs. Cada entrada mostra o endereço IP, sua origem geográfica, a pontuação média de risco calculada a partir da tabela risk_analysis_events, e o status atual (BANNED, ALLOWED ou WHITELISTED). Filtros permitem isolar IPs por status, país ou nível de risco. A partir de qualquer entrada, o administrador pode navegar diretamente para o histórico completo de logs daquele IP.

Lista negra. Uma interface de bloqueio manual para adicionar endereços IP à lista de bloqueio de forma proativa — antes que a análise automatizada os detecte. Útil para integrar inteligência de ameaças de fontes externas ou bloquear imediatamente atores maliciosos conhecidos.

Lista branca. O inverso: um mecanismo de proteção que garante que endereços IP específicos — serviços de monitoramento, sistemas parceiros, endereços do administrador — nunca estejam sujeitos ao bloqueio automatizado, independentemente de seus padrões de tráfego.

Toda a interface suporta filtragem multi-site: um seletor dropdown no topo da página permite alternar entre dados agregados de todos os sites monitorados e visualizações filtradas para domínios individuais. Isso torna o SecureLog adequado para ambientes que hospedam múltiplas propriedades web na mesma infraestrutura.

Design de segurança

Uma ferramenta de monitoramento de segurança que fosse ela mesma insegura seria pior do que inútil — seria um risco. A camada de autenticação do SecureLog implementa diversas medidas defensivas que refletem essa consciência.

Os cookies de sessão são configurados com as flags secure, httponly e SameSite=Lax. O atributo httponlyUm atributo de cookie que impede o JavaScript do lado do cliente de ler o valor do cookie via document.cookie. É uma defesa crítica contra o sequestro de sessão através de vulnerabilidades XSS. impede que o JavaScript leia o cookie de sessão, mitigando o sequestro de sessão via XSS. O atributo SameSite fornece proteção básica contra CSRF. Todo o tráfego é forçado para HTTPS através de redirecionamento do lado do servidor, e o formulário de login valida um token CSRF em cada envio. Tentativas de autenticação mal-sucedidas são registradas com o IP do cliente para fins de auditoria, e um atraso deliberado é introduzido após tentativas falhas para desacelerar ataques de força bruta.

No lado da API, cada requisição é validada para autenticação antes de qualquer operação com dados. O gateway de API retorna respostas JSONJavaScript Object Notation — um formato leve de intercâmbio de dados. Toda a comunicação entre o frontend do painel e o backend api.php utiliza JSON, tanto para corpos de requisição (via POST) quanto para respostas. estruturadas com códigos de status HTTP apropriados, e erros de banco de dados em produção são registrados no lado do servidor sem expor detalhes internos ao cliente.

Os componentes CLI impõem um contexto de execução rigoroso: LogProcessor.php recusa a execução se acessado via HTTP, e RiskAnalyzer.php bloqueia o acesso direto ao arquivo pelo navegador. São proteções simples, mas essenciais contra a exposição acidental.

O modelo de dados

O design do banco de dados do SecureLog segue uma estrutura normalizada centrada em algumas tabelas principais. A tabela ip_addresses armazena IPs únicos com seus metadados geográficos. A tabela ip_management rastreia o status de segurança de cada IP (BANNED, ALLOWED, WHITELISTED) junto com a flag firewall_status (PENDING ou APPLIED) — a coluna crucial que aciona o ciclo de sincronização. Os logs de acesso são armazenados com chaves estrangeiras para tabelas de consulta normalizadas para sites, endereços IP, referrers e user agents, mantendo a tabela principal de logs compacta e eficiente em consultas. Eventos de análise de risco são registrados em uma tabela separada vinculada ao log de acesso, habilitando consultas agregadas por gravidade, intervalo temporal e IP sem escanear o log inteiro.

A separação entre status (o estado desejado) e firewall_status (o estado aplicado) é a pedra angular arquitetônica de todo o sistema. Todas as operações de escrita na aplicação PHP — sejam acionadas pelo processador automatizado de bloqueio, por ações manuais através do painel, ou pelo gerenciamento de listas brancas e negras — definem firewall_status como PENDING. O script Bash de sincronização então consome esses registros pendentes e os aplica ao firewalld. Esse padrão é essencialmente uma arquitetura orientada a eventosUm padrão de design em que mudanças de estado são registradas como eventos em um armazenamento compartilhado, e consumidores downstream os processam independentemente. No SecureLog, a coluna do banco de dados funciona como fila de eventos, a aplicação PHP como produtor e o script Bash como consumidor. leve, implementada sem a sobrecarga de uma fila de mensagens dedicada.

Por que construí este sistema

No meu trabalho gerenciando infraestrutura web, me encontrei repetidamente na mesma situação: o WAF fazia seu trabalho filtrando o tráfego, os logs se acumulavam, mas a lacuna entre dados brutos e tomada de decisão informada permanecia ampla. Soluções SIEMSecurity Information and Event Management — plataformas empresariais (como Splunk, IBM QRadar ou Microsoft Sentinel) que agregam dados de segurança de múltiplas fontes, correlacionam eventos e fornecem alertas. Eficazes, mas tipicamente caras e complexas de implantar. comerciais existem, mas são tipicamente projetadas para ambientes de escala empresarial e acarretam custos de licença desproporcionais para implantações de pequeno e médio porte. Alternativas open-source como a pilha ELKElasticsearch, Logstash e Kibana — uma plataforma open-source de agregação e visualização de logs. Poderosa e flexível, mas requer infraestrutura dedicada (tipicamente 8+ GB de RAM só para o Elasticsearch) e manutenção contínua. são poderosas, mas exigem infraestrutura significativa e expertise operacional para manutenção.

Eu queria algo construído sob medida: uma ferramenta que pudesse ser implantada ao lado de um servidor web existente, que não exigisse nenhuma infraestrutura adicional além de um banco de dados MySQL, e que pudesse fechar o ciclo da análise de logs à aplicação de regras do firewall sem intervenção manual. O SecureLog é o resultado — não um agregador de logs genérico, mas um sistema especializado projetado para uma única missão bem definida: compreender o panorama de ameaças das suas aplicações web e responder a elas automaticamente.

O código é estruturado para ser mantido por um único desenvolvedor ou uma pequena equipe. Cada arquivo inclui documentação inline extensa — não apenas comentários explicando o que o código faz, mas por que determinadas escolhas foram feitas, incluindo notas datadas sobre correções de bugs e revisões de design. Isso reflete um princípio que aplico em todo o meu trabalho: código que não pode ser compreendido seis meses depois por alguém diferente de seu autor é uma dívida técnica, não um ativo.

Conclusões

O SecureLog demonstra que o monitoramento eficaz de segurança web não requer uma pilha empresarial complexa e multicamadas. Uma aplicação PHP bem projetada, um script Bash com os privilégios corretos, um banco de dados atuando como camada de coordenação e uma clara separação entre análise, decisão e aplicação podem produzir um sistema que é simultaneamente transparente, responsivo e de fácil manutenção.

O insight arquitetônico fundamental é o ciclo fechado: os logs entram no sistema, são analisados e avaliados, as avaliações conduzem decisões automatizadas, as decisões são sincronizadas com o firewall, e os resultados são visíveis em tempo real através do painel. Em cada etapa, o administrador mantém controle total — bloqueios automatizados podem ser revertidos, listas brancas protegem endereços confiáveis, e o histórico completo de cada decisão é auditável.

Se você gerencia infraestrutura web e enfrenta desafios semelhantes — ou se está interessado em discutir os detalhes técnicos da implementação — não hesite em entrar em contato.