BK-255 - Hardening de borda: PHP-FPM, Nginx, headers e WAF

Objetivo

Registrar e arbitrar com calma as recomendações externas de segurança recebidas após o incidente de abuso automatizado em 2026-04-11, separando:

• o que é válido
• o que é parcialmente válido
• o que é perigoso aplicar cru no ambiente real do RNT

Estado real confirmado do ambiente

• stack atual: aaPanel + Nginx + PHP 5.6
• o tráfego atual mostra socket php-cgi-56.sock nos logs do Nginx
• HSTS já aparece no curl -I https://rionoteatro.com.br
• X-Powered-By não apareceu no curl -I atual
• o projeto usa:
• shell_exec
• ffmpeg
• rotinas de browser automation
• scrapers/bots
• integrações de login e pagamento

Logo, snippets genéricos de “hardening PHP” e “vhost seguro” não podem ser aplicados literalmente sem arbitragem.

Revisão do snippet de PHP recebido

Válido

• display_errors = Off
• display_startup_errors = Off
• log_errors = On
• error_reporting = E_ALL
• expose_php = Off
• session.cookie_httponly = On
• session.cookie_secure = On
• session.use_strict_mode = On

Parcialmente válido

• error_log = /www/wwwroot/rionoteatro.com.br/logs/php_errors.log

Observação:

• registrar erros em arquivo próprio é bom
• mas log dentro do webroot só é aceitável se o caminho estiver realmente inacessível pela web
• melhor ainda seria log fora do docroot ou negar o diretório explicitamente no Nginx

Potencialmente ruim para o RNT

• session.cookie_samesite = Strict

Risco:

• pode quebrar fluxos legítimos de retorno vindos de:
• login social
• gateways
• outras navegações cross-site esperadas

Leitura atual:

• para o RNT, Lax tende a ser mais seguro operacionalmente do que Strict

• upload_max_filesize = 5M
• post_max_size = 8M

Risco:

• o RNT trabalha com mídia, imagens, PDFs e arquivos maiores
• aplicar esses limites crus tem grande chance de quebrar uploads legítimos

• disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_multi_exec,parse_ini_file,show_source

Risco:

• isso quebra recursos atuais do próprio projeto
• hoje o RNT usa shell_exec em fluxos reais de:
• scrapers
• bot
• automação social
• geração de mídia
• integração com ffmpeg/chrome/node

Conclusão:

• a parte de display_errors/log_errors/expose_php é boa
• a parte de SameSite, limites de upload e disable_functions precisa ser decidida com base no comportamento real do produto, não por snippet genérico

Revisão do vhost Nginx recebido

Válido

• X-Frame-Options
• X-Content-Type-Options
• Referrer-Policy
• server_tokens off
• negar acesso a .env, .git, .user.ini, .log, .sql, .bak
• limit_req_zone e limit_req como camada de borda
• bloquear scanners óbvios por user-agent com lista conservadora

Parcialmente válido

• bloqueios por querystring para padrões como:
• dbms_pipe
• waitfor delay
• sleep(
• union select

Leitura:

• útil como filtro de ruído
• não substitui correção do app
• precisa ser conservador para não gerar falso positivo em querystrings legítimas

Problemático se aplicado cru

• o snippet redefine fastcgi_pass manualmente em vários location

Risco:

• o RNT já usa include enable-php-56.conf
• sobrescrever partes do roteamento PHP sem reconciliar com o vhost atual do aaPanel pode quebrar o site

• o snippet usa rotas genéricas como:
• /cadastre-se.php
• /comentario.php
• /avaliacao.php

Problema:

• isso não cobre os endpoints reais confirmados no incidente, por exemplo:
• /action.php
• /includes/ajax_palcofan.php
• /painel/action.php
• /painel/modulos/profile/action.php
• /produtor/modulos/profile/action.php
• /produtor/modulos/eventos/action.php

• X-XSS-Protection

Leitura:

• header legado/obsoleto
• pode até ficar, mas não deve ser tratado como defesa relevante

• bloquear user-agent amplo demais

Exemplo de risco:

• listas como curl ou clientes genéricos podem atingir tráfego legítimo de healthcheck ou integração

Decisão operacional

Não aplicar cegamente

Não substituir o vhost inteiro por esse arquivo “completo” sem:

1. diff contra o vhost atual real
2. reconciliação manual
3. validação de nginx -t
4. teste de rotas críticas

Caminho correto

1. levantar o vhost atual real do RNT
2. enxertar apenas:

• headers úteis
• deny rules úteis
• rate limit bem calibrado
• filtros conservadores de querystring

1. aplicar rate limit nas rotas reais
2. preservar includes e sockets já usados pelo aaPanel

Rotas reais candidatas para rate limit de borda

Públicas

• /action.php
• /includes/ajax_palcofan.php

Painel cliente

• /painel/action.php
• /painel/modulos/profile/action.php

Painel produtor

• /produtor/action.php
• /produtor/modulos/profile/action.php
• /produtor/modulos/eventos/action.php

Próximos passos

1. capturar o vhost atual real e revisar por diff/hunk
2. mapear quais location já existem e não podem ser sobrescritos cegamente
3. definir um pacote mínimo de headers
4. definir rate limit por endpoint real
5. decidir política de expose_php, error_log e SameSite
6. avaliar borda com Cloudflare/WAF depois da camada app