Bloqueio por IP: o que é collateral damage e como reduzir falsos positivos

Segundo o Sapo.pt, na “guerra contra a IPTV” na Espanha, a LaLiga acabou bloqueando por engano 500 mil sites legítimos entre janeiro e junho. E o mais importante aqui não é o drama político — é técnico: quando você combate pirataria com bloqueio baseado em IP, você cria “danos colaterais” inevitáveis, porque IPs não são exclusivos de um único serviço. Na minha experiência como dev, isso é o tipo de problema que só aparece em produção, bem depois do “funciona no laboratório”.

O que aconteceu de verdade: bloqueio dinâmico por IP e o efeito dominó

A LaLiga, para impedir transmissões ilegais, usa fornecedores de internet para bloquear endereços IP associados a servidores piratas. Pelo Sapo.pt, esse bloqueio é descrito como dinâmico: pode ser aplicado “em tempo real” à lista de IPs que estariam sendo usados para piratear jogos.

O problema é que alguns servidores ilegais compartilham o mesmo IP que sites legítimos. Isso acontece por vários motivos clássicos da internet moderna:

Hosting compartilhado (vários domínios na mesma infraestrutura).
CDNs (um mesmo IP de borda atende milhares de domínios/serviços).
NAT e alocação reusada em faixas de provedores.
Falhas de correspondência no mapeamento “IP X = conteúdo Y” (erro de detecção).

Quando o bloqueio é por IP, você não bloqueia “o conteúdo” — você bloqueia o host. E, em infraestrutura real, host quase nunca é “um único dono, um único serviço”.

Por que o método por IP colide com a arquitetura real da web

Na prática, o modelo mental “um IP serve para um site” é o que quebra.

1) SNI/TLS e virtual hosting: o IP sozinho não identifica o site

Hoje, muita coisa roda com virtual hosting. O IP identifica a máquina/endpoint de rede; quem identifica o “site” é a camada de aplicação — por exemplo, o hostname no TLS (SNI), ou o Host header no HTTP.

Se você bloqueia o IP, você mata todos os sites que usam aquele endpoint. Mesmo que o hostname legítimo esteja ali, o bloqueio acontece antes de chegar no nível onde o “site” seria resolvido.

2) CDNs: um IP pode ser “porta de entrada” para milhares de domínios

Quando um servidor pirata está atrás do mesmo pool/caminho que um site legítimo (por configurações, rotas, reuso de borda ou falha de categorização), bloquear “aquele IP” vira um bloqueio em massa. E CDNs são desenhados justamente para reusar infraestrutura e otimizar entrega.

3) IP dinâmico e “verdade operacional” vs “verdade documental”

Listas de IPs podem estar corretas em um intervalo curto. Mas o tráfego muda. Em seis meses (como o Sapo.pt menciona), a chance de o mapeamento “IP ↔ serviço” ficar errado cresce.

Eu já vi isso em sistemas de segurança e filtragem: você cria uma regra com base em amostra curta, e depois a regra vira um “martelo” que bate no que aparece — não no que deveria ser alvo.

OONI e o conceito de “collateral damage”: como medir o impacto de um bloqueio

O Sapo.pt cita que o Observatório Aberto de Interferência em Redes (OONI) avaliou o impacto do método e concluiu que houve bloqueio de uma quantidade enorme de sites legítimos. O que isso sugere (e aqui eu conecto com o que costuma aparecer em relatórios OONI) é: o bloqueio não foi apenas “falha de anúncio”. Ele atingiu o acesso real de usuários a domínios que não tinham relação com a IPTV ilegal.

Em termos de engenharia, isso é “danos colaterais” — a política captura o alvo, mas também captura o que está no mesmo conjunto de infraestrutura.

E quando você escala esse tipo de captura para centenas de milhares de destinos, você passa a ter dois problemas simultâneos:

Legítimos bloqueados (injustiça e quebra de serviço).
Operação frágil (qualquer mudança de infraestrutura do atacante/hosting aumenta falsos positivos).

Comparação técnica: bloquear por IP vs alternativas que reduzem falsos positivos

Vamos ser práticos. Existem abordagens alternativas — algumas mais caras, outras mais complexas — mas que geralmente reduzem o “efeito dominó”.

Bloqueio por IP (rápido, porém cego)

Prós: é simples de implementar, funciona em camada de rede, tem baixa latência.
Contras: alto risco de compartilhamento e reuso (um IP vira “um grupo”).

Bloqueio por domínio/hostname (mais preciso na camada certa)

Prós: reduz o escopo: você bloqueia “site X”, não “máquina Y”.
Contras: exige análise e controle de DNS/HTTP/TLS — e pode ser contornado via espelhamento, domínios novos e configurações.

Bloqueio por rota/assinatura de tráfego (mais trabalho, melhor precisão)

Prós: pode focar no comportamento (padrões de streaming, endpoints específicos, payload/flow characteristics).
Contras: custo operacional e risco de reagir errado se o comportamento mudar.

Notificação/ordem judicial e remoção de fonte (menos “engenharia de rede”, mais governança)

Prós: tende a remover a origem do conteúdo ilegal.
Contras: depende de processos legais e tempo.

Na Prática: como você monta (e testa) um bloqueio “cegamente por IP” sem cair em 500 mil falsos positivos

Eu não vou te ensinar “como burlar” bloqueios. Mas vou mostrar o lado de engenharia: como evitar que uma regra de bloqueio vire uma bomba.

Imagine que você está construindo um serviço de filtragem (antiabuso, anti-piracy, anti-fraude) e alguém propõe: “vamos bloquear os IPs suspeitos”. O passo a passo abaixo é como eu faria para reduzir colateral.

Monte uma tabela de mapeamento entre indicador e entidade bloqueada. Ex.: “domínio observado” → “IP de observação” → “evidence timestamp”.
Adicione uma camada de verificação antes de aplicar bloqueio. Se um IP aparece em múltiplos domínios legítimos (por resolução histórica), não bloqueie direto.
Use janela temporal curta. Bloqueio “instantâneo e permanente” é receita para capturar mudanças de infraestrutura.
Implemente supressão de falso positivo com base em sinais de camada 7 (hostname, rotas, fingerprints). Mesmo que não consiga “bloquear por hostname”, ao menos não decida por IP sozinho.
Faça canary/rollout: aplique bloqueio em uma porcentagem, monitore taxa de erro por domínio legítimo e só então expanda.
Instrumente métricas de impacto: bloqueios por IP devem ser correlacionados com falhas de DNS/HTTP/handshake por domínio. Se a métrica “erros do mundo legítimo” dispara, você recua.

Exemplo funcional: regra de bloqueio com “guardrail” por reputação de compartilhamento

Este exemplo é intencionalmente simples. A ideia é: não bloquear IP se ele está associado a muitos domínios observados historicamente (sinal de shared hosting/CDN). Isso reduz o risco do tipo “um IP serve a todo mundo”.

from collections import defaultdict
import time

# ip -> set(domains) que já vimos historicamente
ip_to_domains = defaultdict(set)

def should_block_ip(ip: str, suspected: bool, now: float,
                     max_domains_per_ip: int = 50,
                     min_evidence_age_seconds: int = 3600):
    """
    suspected: indicador de que o IP é candidato a bloqueio
    min_evidence_age_seconds: exige evidência recente o suficiente (ajuste para seu caso)
    """
    if not suspected:
        return False

    # Guardrail: se o IP parece ser "shared", reduz falsos positivos
    associated_domains = ip_to_domains[ip]
    if len(associated_domains) > max_domains_per_ip:
        # Em geral, isso aponta para CDN/hosting compartilhado.
        return False

    # Aqui você colocaria validação temporal e outros sinais
    # (em produção, combine com logs L7, fingerprints e contexto).
    return True

# Exemplo: preenchemos histórico
ip_to_domains["203.0.113.10"].update({"site-a.com", "site-b.org", "coolearth.org"})

# Se esse IP for suspeito, ele não deveria bloquear se for compartilhado demais
print(should_block_ip("203.0.113.10", suspected=True))  # False se exceder limiar

Por que isso rankeia e funciona: você troca “bloquear com base em IP” por “bloquear quando o IP tem baixa probabilidade de ser compartilhado”. É uma defesa de engenharia baseada em distribuição, não em suposição.

Por que isso ainda não é perfeito: atacantes podem variar infraestrutura para “parecer não compartilhado”. Mas pelo menos você evita o pior caso do mundo real: bloquear o endpoint de um grupo inteiro.

Erros Comuns (o que evitar) quando você decide bloquear “por IP”

Dev experiente detecta conteúdo raso rápido. Aqui vai onde normalmente dá ruim — e por quê.

Tratar IP como identificador único de aplicação. IP é endpoint; hostname/L7 é identidade real.
Atualizar listas sem expirar regras. Bloqueio sem TTL vira “permanente por acidente”.
Não medir collateral. Se você não rastreia impacto por domínio e por tipo de cliente, você só vê “pirações caíram” e nunca “legítimos caíram junto”.
Fazer bloqueio “antes” de validar evidence. Coleta de evidência e decisão precisam ser separadas, com canary.
Ignorar que CDNs mudam comportamento. Um IP hoje pode ser legítimo; amanhã pode virar outra rota/reatribuição.
Assumir que “o atacante está onde eu vi ontem”. Infra muda; sua regra também tem que mudar ou morrer.

Implicações práticas para quem programa (e projeta políticas técnicas)

O caso do Sapo.pt é um ótimo lembrete de que “segurança por lista” sem contexto vira um mecanismo de censura incidental. Mas, do ponto de vista de engenharia, os impactos práticos aparecem em quatro frentes:

Operação: seu sistema vai gerar tickets e reclamações em massa quando o escopo estiver errado.
Confiabilidade: falsos positivos derrubam serviços e afetam usuários que nada têm a ver com o objetivo original.
Manutenibilidade: você passa a caçar exceções em vez de ajustar a estratégia.
Reputação do sistema: quando o bloqueio é percebido como “cegueira”, qualquer melhora vira “tentativa de justificar erro”.

Se eu estivesse implementando isso em um produto real (antiabuso, firewall, segurança), eu trataria IP blocking como último recurso e sempre com guardrails e validação L7.

FAQ

Bloquear por IP é sempre errado?

Não. Pode ser útil em cenários onde o IP tem baixa chance de compartilhamento e a evidência é forte. O erro está em assumir que IP = aplicação única. Na web real, isso quase nunca é verdade.

Como reduzir falsos positivos sem abandonar bloqueio rápido?

Use bloqueio rápido só após guardrails: TTL, canary rollout, expiração automática, e validação por sinais adicionais (hostname, métricas de L7, reputação de compartilhamento).

O que “500 mil sites” sugere tecnicamente?

Sugere que a regra de bloqueio atingiu um conjunto grande de domínios por causa de reuso de infraestrutura (hosting compartilhado/CDN) ou erro no mapeamento IP ↔ serviço. Sem L7, você não consegue separar com precisão.

Como um dev mede “danos colaterais” em um sistema de bloqueio?

Instrumentando taxas de falha por domínio e comparando antes/depois do bloqueio. Se domínios legítimos começam a cair junto, você tem evidência operacional de collateral.

Qual alternativa é mais “correta” em teoria?

Bloquear por identidade de aplicação (domínio/hostname) ou por sinais de tráfego que representem o serviço alvo. Em compensação, isso exige mais dados e integração na camada 7.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.