Capítulo 2 — Redes e serviços de internet

Mapa da aula

Aula 02 publicada. Mapa, exemplo, EX004.

flowchart TD
  N0["2.1 De endereços a zonas"]
  N1["2.2 Serviços, portas e o que eles implicam"]
  N2["2.3 Declarado versus observado"]
  N3["2.5 Atividade prática: fluxos versus conduítes"]
  N4["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX004"]

Desenho lógico

flowchart LR
  N0["2.1 De endereços a zonas"]
  N1["2.2 Serviços, portas e o que eles implicam"]
  N2["2.3 Declarado versus observado"]
  N3["2.5 Atividade prática: fluxos versus conduítes"]
  N4["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX004"]

[2.1 De endereços a zonas]
    |
    v
[2.2 Serviços, portas e o que eles implicam]
    |
    v
[2.3 Declarado versus observado]
    |
    v
[2.5 Atividade prática: fluxos versus conduítes]
    |
    v
[Síntese do capítulo]
    |
    v
[Exemplo resolvido] --> [Exercício EX004]

Objetivos de aprendizagem e conexão

Depois deste capítulo, você deve ser capaz de:

• descrever uma rede em termos de zonas (grupos de sistemas com confiança e função semelhantes) e conduítes (os caminhos permitidos entre elas);
• ler um registro de fluxo e mapeá-lo para zonas, protocolos e portas;
• comparar o que a rede de fato transporta com o que foi declarado, e classificar cada diferença;
• explicar por que um fluxo declarado que não transporta tráfego também é uma constatação.

O Capítulo 1 olhou para um host. Um serviço é feito de muitos hosts conversando entre si. Na infraestrutura crítica, a rede é onde se espera que a maior parte da separação entre sistemas de negócio, sistemas de controle e o mundo externo seja aplicada — e onde ela mais se desgasta, uma regra "temporária" de cada vez.

2.1 De endereços a zonas

Um endereço IP diz para onde um pacote vai; não diz para que serve o destino. Por isso, os operadores agrupam os sistemas em zonas: no projeto do LANTERN, a zona de estações (CLPs e RTUs nas estações de bombeamento), a zona de relay (hosts RLY), a zona corporativa (sistemas de negócio da FSTS e os usuários de relatórios do historiador) e a externa (tudo o que está fora, incluindo os fornecedores). A ideia de zonas e conduítes vem da prática de segurança em automação industrial: a série ISA/IEC 62443 usa exatamente esses termos (visão geral da ISA), e o guia de TO do NIST recomenda segmentar as redes de controle das redes de negócio (NIST SP 800-82 Rev. 3).

Um conduíte é um caminho declarado e justificado entre duas zonas: zona de origem, zona de destino, protocolo, porta e finalidade. O LANTERN declara quatro: as estações enviam Modbus/TCP (tcp/502) ao relay; o relay envia HTTPS (tcp/443) ao historiador na zona corporativa; os administradores na zona corporativa alcançam o relay por SSH (tcp/22); e o relay fornece hora (udp/123, NTP) às estações.

2.2 Serviços, portas e o que eles implicam

Um número de porta é uma convenção, não uma garantia: a tcp/443 costuma transportar TLS, mas qualquer coisa pode escutar ali. Ainda assim, a convenção diz o que esperar e o que questionar. Protocolos industriais como o Modbus/TCP foram projetados para redes fechadas e não têm autenticação embutida; um dispositivo que aceita escritas Modbus as aceitará de qualquer um que consiga alcançá-lo. É por isso que o caminho importa tanto: se um laptop corporativo consegue alcançar um CLP na tcp/502, a única coisa entre um erro (ou um atacante) e uma bomba é a ausência de alguém tentando.

Os serviços de internet — DNS, NTP, HTTPS, SSH — são o encanamento de todo serviço moderno. Cada um tem um modo de falha que importa operacionalmente: a falha do DNS torna os nomes irresolvíveis, embora os hosts estejam bem; a falha do NTP deixa os relógios derivarem; a falha do TLS (um certificado expirado) transforma um serviço que funciona num serviço inalcançável; o SSH exposto à internet atrai tentativas constantes de adivinhar senhas.

2.3 Declarado versus observado

Uma base de regras de firewall ou um diagrama de projeto diz o que deveria acontecer. Os registros de fluxo — resumos de conversas coletados por firewalls, switches ou sensores — dizem o que de fato aconteceu. Comparar os dois é uma das tarefas de rotina de maior valor que um tecnólogo pode fazer, e não exige ferramentas de ataque: é ler os seus próprios registros. Cada diferença cai numa de quatro classes:

1. Observado e declarado — esperado; ainda assim, confira se os volumes parecem normais.
2. Observado, mas não declarado — existe um caminho que ninguém justificou. Ou a declaração está incompleta (atualize-a, com um responsável e uma finalidade), ou a base de regras é permissiva demais (corrija-a).
3. Declarado, mas não observado — ou o serviço não está funcionando (uma estação está em silêncio), ou o conduíte declarado está obsoleto e deve ser removido.
4. Observado para uma zona desconhecida — um endereço que você não consegue situar; o seu inventário está incompleto.

2.4 Exemplo resolvido: os fluxos de uma noite (sintético)

B. Lind lhe entrega uma exportação de fluxos do firewall central referente a uma noite. A maioria dos fluxos corresponde a conduítes. Três não: uma estação de trabalho corporativa, 10.40.3.7, conversou em Modbus diretamente com o CLP da PS-04 (12 conversas); um endereço externo, 192.0.2.44, alcançou o relay por SSH (3 conversas); e o relay fez uma conexão HTTPS para um endereço externo, 192.0.2.80. Uma origem declarada, a RTU da PS-09 em 10.20.0.13, não enviou nada.

Nada disso é prova de ataque. O fluxo corporativo-para-CLP pode ser um engenheiro usando uma ferramenta de configuração a partir da rede errada; o SSH externo pode ser ruído de fundo da internet alcançando uma porta exposta; o HTTPS de saída do relay pode ser uma atualização de pacotes. Cada um ainda é uma constatação, porque cada um é um caminho que o projeto não permite. A estação silenciosa é antes de tudo um problema operacional: a operação de Água pode estar operando a PS-09 às cegas.

2.5 Atividade prática: fluxos versus conduítes

Execute o Laboratório 2. Ele atribui cada endereço a uma zona com o módulo ipaddress, compara cada fluxo com os conduítes declarados e relata os fluxos declarados com tráfego zero.

Laboratório 2 (salve como lab02.py, execute com python3 lab02.py):

# Lab 2 - observed flows versus the declared conduit list (offline, standard library only)
# Synthetic: Fallowmere Water pumping-station network. Addresses are documentation/private ranges.
import ipaddress
zones = {
    "station": ipaddress.ip_network("10.20.0.0/24"),
    "relay":   ipaddress.ip_network("10.30.0.0/28"),
    "corp":    ipaddress.ip_network("10.40.0.0/16"),
    "vendor":  ipaddress.ip_network("192.0.2.0/24"),   # TEST-NET-1, stands in for internet
}
declared = {("station", "relay", "tcp", 502), ("relay", "corp", "tcp", 443),
            ("corp", "relay", "tcp", 22), ("relay", "station", "udp", 123)}
flows = """10.20.0.11,10.30.0.5,tcp,502,1840
10.20.0.12,10.30.0.5,tcp,502,1790
10.30.0.5,10.40.8.20,tcp,443,3600
10.40.3.7,10.30.0.5,tcp,22,4
10.30.0.5,10.20.0.11,udp,123,96
10.40.3.7,10.20.0.11,tcp,502,12
192.0.2.44,10.30.0.5,tcp,22,3
10.30.0.5,192.0.2.80,tcp,443,1
10.20.0.13,10.30.0.5,tcp,502,0"""
def zone(a):
    ip = ipaddress.ip_address(a)
    return next((z for z, net in zones.items() if ip in net), "unknown")
seen = set()
for line in flows.splitlines():
    s, d, p, port, count = line.split(",")
    key = (zone(s), zone(d), p, int(port))
    if int(count) == 0:
        print(f"SILENT  {s:>12} -> {d:<12} {p}/{port}  (declared flow with no traffic)")
        continue
    seen.add(key)
    tag = "OK     " if key in declared else "UNDECL "
    print(f"{tag} {s:>12} -> {d:<12} {p}/{port} {key[0]}->{key[1]} n={count}")
for k in sorted(declared - seen):
    print("NOT SEEN", k)

Saída esperada (Python 3.13.5):

OK        10.20.0.11 -> 10.30.0.5    tcp/502 station->relay n=1840
OK        10.20.0.12 -> 10.30.0.5    tcp/502 station->relay n=1790
OK         10.30.0.5 -> 10.40.8.20   tcp/443 relay->corp n=3600
OK         10.40.3.7 -> 10.30.0.5    tcp/22 corp->relay n=4
OK         10.30.0.5 -> 10.20.0.11   udp/123 relay->station n=96
UNDECL     10.40.3.7 -> 10.20.0.11   tcp/502 corp->station n=12
UNDECL    192.0.2.44 -> 10.30.0.5    tcp/22 vendor->relay n=3
UNDECL     10.30.0.5 -> 192.0.2.80   tcp/443 relay->vendor n=1
SILENT    10.20.0.13 -> 10.30.0.5    tcp/502  (declared flow with no traffic)

Escreva cada constatação numa linha: o que foi observado, a qual classe pertence, a explicação benigna mais provável, a explicação mais preocupante e a próxima verificação. Não "teste" nenhum caminho você mesmo; pergunte ao responsável.

Aplicadas à exportação da noite, as quatro linhas ficam assim. Corporativo 10.40.3.7 para Modbus da PS-04, 12 conversas: caminho não declarado; benigna, a ferramenta de configuração de um engenheiro na rede errada; preocupante, uma estação de trabalho comprometida alcançando um CLP; próxima verificação, perguntar à engenharia de Água quem usa esse host. Externo 192.0.2.44 para o relay por SSH: exposição; próxima verificação, por que a porta 22 responde a partir de fora. Relay para 192.0.2.80 HTTPS: saída não declarada. PS-09 em silêncio: fluxo declarado com tráfego zero, levado primeiro à operação de Água.

2.6 Erros comuns e limites

• Ler uma base de regras e acreditar que ela descreve o tráfego; as regras são intenções, os fluxos são fatos.
• Tratar "não declarado" como "malicioso" — ou como "inofensivo porque é interno".
• Ignorar fluxos declarados silenciosos; uma estação que para de falar é uma interrupção de serviço antes de ser uma questão de segurança.
• Presumir que uma porta identifica uma aplicação.
• Coletar fluxos apenas na borda com a internet, onde os caminhos de maior consequência (corporativo para controle) são invisíveis.

Os registros de fluxo mostram quem conversou com quem, em qual porta, quanto; não mostram conteúdo nem intenção, e podem ser amostrados. São excelentes para conferir a arquitetura e fracos para provar o que foi feito.

Exercícios — capítulo 2

EX004 — Classifique e priorize. Objetivo: classificar as diferenças de fluxo e ordenar o acompanhamento. Entradas: a saída do Laboratório 2. Restrições: quatro constatações; no máximo uma frase de explicação cada. Etapas: (1) ponha cada constatação numa classe do Capítulo 2 ("Declarado versus observado"); (2) ordene-as para acompanhamento pela consequência potencial para o serviço de água; (3) nomeie o responsável que você contataria primeiro para cada uma. Evidência esperada: tabela. Rubrica: 3 = Modbus corporativo→estação em primeiro lugar porque alcança o processo físico, PS-09 silenciosa tratada como prioridade operacional, SSH externo e saída do relay ordenados com sensatez, responsáveis nomeados; 2 = classes certas, ordenação mal justificada; 1 = ordena pelo número de conversas; 0 = nada.

EX005 — Atualize a declaração. Objetivo: decidir entre mudar o projeto e mudar a rede. Entradas: a operação de Água confirma que o HTTPS de saída do relay foi uma atualização do sistema operacional a partir de um espelho do fornecedor; o tráfego corporativo→CLP foi o laptop de um engenheiro. Restrições: todo conduíte precisa de origem, destino, protocolo/porta, finalidade e responsável. Etapas: (1) decida, para cada um, se acrescenta um conduíte ou remove o caminho; (2) para qualquer conduíte acrescentado, escreva a sua entrada completa; (3) para o acesso do engenheiro, proponha o caminho declarado que deve substituí-lo. Evidência esperada: lista de conduítes atualizada e justificativa. Rubrica: 3 = caminho de atualização acrescentado de forma estreita (espelho específico, via proxy ou servidor de atualização, responsável nomeado) ou substituído por uma fonte interna de atualizações; acesso de engenharia movido para um caminho de salto declarado e autenticado, e não corporativo→CLP; 2 = entradas sensatas, mas incompletas; 1 = simplesmente permite tudo o que foi observado; 0 = nada.

EX006 — Estenda o laboratório. Objetivo: tornar a ferramenta de comparação mais útil. Entradas: Laboratório 2. Restrições: apenas a biblioteca padrão; não altere os dados sintéticos, exceto como indicado. Etapas: (1) acrescente um fluxo de 10.50.1.9 para o relay na tcp/443; (2) modifique o script para que endereços fora de todas as zonas sejam relatados como "UNKNOWN ZONE", em vez de casados; (3) mostre a nova saída. Evidência esperada: diff do código e saída. Rubrica: 3 = endereço desconhecido relatado de forma distinta e a execução o mostra; 2 = funciona, mas a mensagem é pouco clara; 1 = não executado; 0 = nada.

Síntese do capítulo

Pense na rede como zonas unidas por conduítes declarados, cada um com uma finalidade e um responsável. As regras declaram intenções; os registros de fluxo declaram fatos. Comparar os dois com regularidade — observado e declarado, observado mas não declarado, declarado mas silencioso, desconhecido — é barato, seguro e está entre as coisas mais valiosas que um implementador faz. Na infraestrutura crítica, o caminho não declarado de maior consequência é o que alcança o processo físico.