OpenCyber Academy
Engenharia · Capítulo 11 · Português
Código do curso: OCA-130Capítulo 11: OCA-130-C011

Capítulo 11 — Redes e protocolos

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 11 publicada. Mapa, exemplo, EX031.

flowchart TD
  N0["11.1 Camadas"]
  N1["11.2 Endereços e redes"]
  N2["Laboratório — falhas por rede"]
  N3["11.3 Lendo o resultado"]
  N4["11.4 Visibilidade do HTTPS"]
  N5["11.6 Conhecimento de protocolo"]
  N6["DNS e tempo"]
  N7["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX031"]

Desenho lógico

flowchart LR
  N0["11.1 Camadas"]
  N1["11.2 Endereços e redes"]
  N2["Laboratório — falhas por rede"]
  N3["11.3 Lendo o resultado"]
  N4["11.4 Visibilidade do HTTPS"]
  N5["11.6 Conhecimento de protocolo"]
  N6["DNS e tempo"]
  N7["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]

[11.1 Camadas]
    |
    v
[11.2 Endereços e redes]
    |
    v
[Laboratório — falhas por rede]
    |
    v
[11.3 Lendo o resultado]
    |
    v
[11.4 Visibilidade do HTTPS]
    |
    v
[11.6 Conhecimento de protocolo]
    |
    v
[DNS e tempo]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX031]

Objetivos de aprendizagem

Você vai (1) explicar endereçamento, portas e protocolos comuns; (2) ler telemetria de rede, como fluxos e logs web; (3) agregar a atividade por rede; (4) reconhecer os limites da atribuição baseada em IP.

11.1 Camadas

As redes movem dados em camadas: enlaces físicos, endereçamento e roteamento IP, transporte TCP ou UDP e aplicações como o HTTPS. Existe telemetria em cada camada: estatísticas de enlace, registros de fluxo e logs de aplicação. Cada camada responde a perguntas diferentes. As estatísticas de enlace mostram se um cabo ou porta está saturado; os registros de fluxo mostram quem falou com quem, por quanto tempo e quantos bytes trafegaram; os logs de aplicação mostram o que foi pedido e o que voltou. Durante a rajada no portal, os fluxos revelam o volume vindo de uma rede, mas só os logs do servidor web mostram quais nomes de usuário foram tentados.

11.2 Endereços e redes

Os endereços IPv4 são agrupados em redes por prefixo. Uma rede /24 compartilha os três primeiros octetos. O tráfego de ataque vindo de um provedor de hospedagem muitas vezes se espalha por muitos endereços em poucas redes, então agregar por rede revela rajadas que as contagens por endereço escondem. Contar por endereço pode fazer um ataque distribuído parecer inofensivo: cinquenta endereços com duas tentativas cada nunca acionam um limiar de cinco por endereço. Agrupar por /24 os reúne numa única rede com cem tentativas. A escolha do comprimento do prefixo é uma troca, já que um prefixo mais largo pega atividades mais espalhadas, mas também junta clientes sem relação entre si atrás do mesmo provedor.

Laboratório — falhas por rede

"""Count failed portal logins by source /24 network and by distinct usernames (synthetic)."""
from collections import defaultdict
log = [("203.0.113.10","u1","fail"),("203.0.113.11","u2","fail"),("203.0.113.12","u3","fail"),
       ("203.0.113.13","u4","fail"),("203.0.113.14","u5","ok"),("198.51.100.20","u6","fail"),
       ("198.51.100.20","u6","fail"),("198.51.100.20","u6","ok"),("203.0.113.15","u7","fail"),
       ("203.0.113.16","u8","fail")]
fails = defaultdict(int); users = defaultdict(set)
for ip, user, res in log:
    net = ".".join(ip.split(".")[:3]) + ".0/24"
    users[net].add(user)
    if res == "fail": fails[net] += 1
for net in sorted(fails):
    print(f"{net:17} failures={fails[net]} distinct_users={len(users[net])}")

Execute com python3 lab_failed.py. Saída verificada:

198.51.100.0/24   failures=2 distinct_users=1
203.0.113.0/24    failures=6 distinct_users=7

11.3 Lendo o resultado

A rede 203.0.113.0/24 produziu 6 falhas, uma contra cada um de seis nomes de usuário, e tocou 7 nomes de usuário distintos ao todo quando se conta o sucesso de u5 — muitas contas, poucas tentativas cada, o padrão do credential stuffing. A 198.51.100.0/24 mostra 2 falhas e um sucesso para um único usuário: um cliente digitando a senha errada. O padrão importa mais do que os totais. Muitos nomes de usuário com uma tentativa cada sugerem alguém percorrendo uma lista de credenciais vazadas, na esperança de que alguns clientes tenham reutilizado senhas. Um único nome de usuário com algumas falhas e depois um sucesso parece uma pessoa comum que esqueceu qual senha usou. Uma regra que só contasse falhas trataria as duas redes da mesma forma e perderia essa distinção.

11.4 Visibilidade do HTTPS

O tráfego web cifrado esconde o conteúdo dos sensores de rede; os próprios logs do servidor web mostram caminhos, códigos de status e nomes de usuário. Escolher onde observar é uma decisão de engenharia. Quebrar a cifragem na rede para inspecionar o conteúdo é possível com proxies de interceptação, mas acrescenta risco, custo e preocupações de privacidade. No portal, o servidor já vê as requisições decifradas, então seus logs são o lugar natural para observar os logins. Os sensores de rede ainda ajudam com volume e tempo, enquanto os logs do servidor fornecem o significado de cada requisição.

11.5 Limites da atribuição

Um endereço identifica um ponto de conexão, não uma pessoa. Proxies compartilhados, faixas de nuvem e reutilização de endereços tornam imprecisos o bloqueio e a atribuição. Muitos clientes podem compartilhar um endereço atrás do gateway de uma operadora de telefonia móvel, então bloqueá-lo pode impedir o acesso de usuários inocentes. Os atacantes alugam servidores na nuvem e os abandonam em poucas horas, de modo que um endereço hostil ontem pode pertencer a outra pessoa amanhã. Por isso, os relatórios do SOC descrevem os endereços como fontes de atividade, em vez de nomear quem estava por trás deles. Os bloqueios de endereços recebem datas de expiração.

11.6 Conhecimento de protocolo

Saber que o login usa POST para /login e devolve 401 em caso de falha permite a Amara escrever uma análise sintática precisa. Sem esse conhecimento, um analisador poderia contar como tentativa toda requisição à página de login, inclusive de pessoas que apenas carregam o formulário. Conhecer o método, o caminho e os códigos de status permite a Amara contar apenas as credenciais enviadas e separar falhas de sucessos. Ela confirma os detalhes com os desenvolvedores do portal em vez de adivinhá-los a partir de uma amostra, já que um redirecionamento depois do login poderia esconder o resultado real.

DNS e tempo

Os logs de DNS mostram quais nomes os hosts consultam, muitas vezes revelando contatos antes que as conexões aconteçam. Os dispositivos de rede precisam compartilhar um horário sincronizado para que fluxos, DNS e logs web se alinhem; sem isso, a correlação entre camadas vira adivinhação.

Exemplo resolvido

Amara nota que um endereço, 203.0.113.14, produziu o sucesso de u5. Ela confere o log web: a mesma sessão depois requisitou /account/address, com uma alteração às 10:07. Ela acrescenta isso ao chamado como uma possível ação de tomada de conta.

Caso sintético. Os endereços usam faixas de documentação; os eventos são sintéticos.

Erros e limites

Agregar por /24 pode juntar usuários sem relação entre si de grandes provedores; confirme com outros sinais.

Exercícios

Síntese

A telemetria de rede ganha significado com a agregação e o conhecimento de protocolo, dentro dos limites da atribuição por IP.

Continue estudando — capítulo 11 de 50

← Capítulo 10 (rascunho) · Índice de capítulos do curso · Capítulo 12 (rascunho) →

Respostas comentadas

EX031. Os atacantes espalham as tentativas por muitos endereços nas mesmas redes, então agrupar revela rajadas que as contagens por endereço escondem.

EX032. 203.0.113.0/24, porque suas seis falhas atingiram seis nomes de usuário diferentes, uma tentativa cada, e sete nomes de usuário aparecem ali ao todo.

EX033. Requisitou uma alteração de endereço às 10:07, o que sugere que a conta foi tomada.