A3 Toyota · Confiabilidade & Segurançav7
A3 Alicante — Quedas & Segurança
O site da Alicante saiu do ar 22 vezes em 3 semanas (≈7h30), sempre por poucos minutos e voltando sozinho. Não é invasão nem defeito do site: ele roda sem proteção na frente, então em picos de acesso a própria hospedagem bloqueia tudo por 15–40 min pra se defender — e é isso que derruba. Plano, em ordem: (1) um monitor que avisa na hora (antes do cliente reclamar), (2) o Cloudflare na frente (protege, acelera e esconde o servidor), (3) ajustes no site. Falta só confirmar que nenhum arquivo foi alterado indevidamente.
Quedas = throttle host-side (a hospedagem recusando ativamente), não crash e não invasão — provado. O UptimeRobot mostra 17 de 22 quedas como 403 Forbidden (recusa, não erro 5xx) e 5 delas iniciam 1,5–4,7 min depois de um MySQL Abuse Report (sobrecarga do banco): o mesmo evento. Como o site é servido direto, sem CDN/WAF, nada absorve o pico. Caminho, em ordem: monitor (C1) → Cloudflare → hardening WP → verificar integridade dos arquivos.
Background
Alicante é cliente de manutenção da Mukutu — site institucional/catálogo de pedras (Technistone, Basaltina, Onix, Quartzito) em WordPress · LiteSpeed · PHP 8.3.30, tecnicamente isolado da infra da agência (mukutu-mono / muki-vps).
| Camada | Onde | Nota |
|---|---|---|
| Domínio | registro.br | precisa de acesso p/ trocar nameservers |
| DNS + e-mail | Locaweb (ns1-3) | MX + SPF RDStation/SendGrid — não quebrar |
| Origin | 72.61.49.79 · LiteSpeed | exposto, sem CDN |
| Banco | Hostinger u235710689_micrao | br-asc-web890.main-hosting.eu — fonte dos abuse reports |
| Borda | nenhuma | RISCO ALTO |
Reconciliação: o blackbox rotulou a origem "Locaweb", mas a telemetria autoritativa (abuse reports de main-hosting.eu) indica host Hostinger; Locaweb é o provedor de DNS/e-mail. Não altera as recomendações — confirmar no painel.
Condição atual
22 quedas (06-19 → 07-10), 7.4 h de indisponibilidade, média 20 min (15–40 min). Distribuição por causa:
| Causa (UptimeRobot) | Qtd | Leitura |
|---|---|---|
| 403 Forbidden | 17 | servidor recusa ativamente — não é crash 5xx |
| 408 Request Timeout | 4 | servidor saturado, não responde a tempo |
| Connection Timeout | 1 | conexão nem completa |
Clusters: 07-01 (7×), 06-25 (5×), 06-30 e 07-10 (3× cada) — batem com os picos dos abuse reports (07-01 = 1611 ms). Baseline do monitor (cron 5 min): 200 em 0.08–0.32 s, x-litespeed-cache: hit — quando responde, responde bem; as quedas são intermitentes.
Correlação decisiva — 5 quedas 403 iniciam 1,5–4,7 min após o abuse report do mesmo instante:
| Queda 403 | Abuse Report | Δ |
|---|---|---|
06-23 23:59 | 23:57 | +2,8 min |
06-30 13:53 | 13:52 | +1,5 min |
07-01 16:51 | 16:49 | +1,9 min |
07-10 16:47 | 16:43 | +4,7 min |
Condição desejada
| Dimensão | Atual | Alvo |
|---|---|---|
| Borda | origin exposto, sem CDN | Cloudflare na frente, IP oculto |
| Disponibilidade | quedas em rajadas (7.4h) | uptime ≥ 99.9%, sem throttle |
| Carga de DB | picos 1.0–1.6s N+1 | queries < 200ms; 0 abuse reports |
| Superfície | user-enum, XML-RPC, headers, DMARC | endurecida |
| File-side | não verificada | integridade confirmada |
Análise de causa raiz
O 403 é o Hostinger/LiteSpeed cortando a requisição quando a cota de recurso do plano shared estoura — disparada pelo fan-out N+1 de Polylang + ACF + taxonomia de produtos, sem CDN/WAF na borda pra absorver o pico.
Árvore de 5-Porquês — brainstorm dos caminhos possíveis; o caminho colorido é o que a evidência confirma (hipóteses cinza/tracejadas foram exploradas e descartadas).
Contramedidas
C1 feito: o monitor está no ar em status.mukutu.cloud — enxergamos as quedas antes do cliente reclamar. C2 Cloudflare: conta/zone criada, mas aguardando a equipe trocar o nameserver no registro.br — enquanto o DNS não cortar, o Cloudflare ainda não está na frente e o site segue caindo pelo throttle do host (as quedas de hoje confirmam). Depois: o hardening (C3–C7).
Plano
A ordem é do mais barato pro mais caro, medida em caracteres a recuperar. Não é preciosismo: entregar as quatro pequenas primeiro devolve quatro eventos ao ar enquanto a Difusão Digital ainda estaria no meio.
A Difusão Digital não é uma página, é um catálogo. São 63 webinars com objetivo, palestrante, data e link do vídeo — 78.252 caracteres contra 2 a 7 mil das outras. Copiar 63 blocos à mão é ordem de magnitude diferente, e a frota pode extrair o conteúdo estruturado do portal antigo pra colar, em vez de garimpar bloco a bloco.
Follow-up
Gap aberto: integridade de arquivos (webshell) — só o scan de malware + comparar o public_html.zip com um WP limpo fecha; nem o blackbox nem os abuse reports provam isso. Ordem de ataque: C1 monitor (agora) → C2 Cloudflare → C3 verificação file-side — nenhuma depende de login vivo.
Painel ao vivo — o placar abaixo puxa ao vivo do Uptime Kuma (C1) em status.mukutu.cloud: mostra o estado real (no ar / fora do ar), o uptime 24h e conta desde a última transição, resetando quando cai. O gráfico abaixo é a série histórica (UptimeRobot, 06-19→07-10).
Fontes
- status.mukutu.cloud/status/alicante · widget ao vivo (C1) Uptime Kuma — painel público do monitor Alicante (403/latência/TLS + keyword)
- Ekyte · task 9890071 Investigação de quedas + análise de segurança — Jéssica Mariano
- Google Drive · logs & backups pasta ALICANTE (Jéssica) — 8× mysql_abuse_report, zips
- UptimeRobot · 22 incidentes (CSV) 06-19 → 07-10 · 17× 403
- public_html.zip 7.5 GB — captura forense do web root (integridade file-side)
- domains.zip 7.5 GB — backup de domínios
- Relatório de Proteção (blackbox 2026-07-07) anexo — KPIs, mapa de risco, plano 4 fases, alicante-monitor.log