Capítulo 7 — Redes e protocolos
Mapa da aula
Aula 07 publicada. Mapa, exemplo, EX013.
flowchart TD
N0["7.1 Camadas, endereços e portas"]
N1["7.2 Protocolos industriais e as suas premissas"]
N2["7.3 Zonas, conduítes e allowlists"]
N3["7.5 Atividade prática"]
N4["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX013"]
Desenho lógico
flowchart LR
N0["7.1 Camadas, endereços e portas"]
N1["7.2 Protocolos industriais e as suas premissas"]
N2["7.3 Zonas, conduítes e allowlists"]
N3["7.5 Atividade prática"]
N4["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX013"]
[7.1 Camadas, endereços e portas]
|
v
[7.2 Protocolos industriais e as suas premissas]
|
v
[7.3 Zonas, conduítes e allowlists]
|
v
[7.5 Atividade prática]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX013]
Objetivos de aprendizagem e conexão
Depois deste capítulo, você consegue (1) explicar as camadas, o endereçamento, as portas e a diferença entre o cliente e o servidor de uma conexão; (2) descrever como protocolos industriais como o Modbus diferem dos protocolos modernos da internet nas suas premissas de segurança; (3) expressar uma política de segmentação de rede como zonas, conduítes e uma allowlist; e (4) conferir os fluxos observados contra essa política e interpretar as violações. O capítulo se apoia nos Capítulos 3 e 6 e prepara o Capítulo 16 (arquitetura) e o Capítulo 24 (controles).
7.1 Camadas, endereços e portas
As redes são construídas em camadas. A camada de enlace move quadros entre dispositivos vizinhos (Ethernet, Wi-Fi). A camada de internet move pacotes entre redes usando endereços IP. A camada de transporte fornece um fluxo de bytes confiável (TCP; ver RFC 9293) ou datagramas individuais (UDP) e usa números de porta para identificar o serviço num host. A camada de aplicação carrega o significado: HTTPS para a web, Modbus/TCP na porta 502 para a consulta industrial, OPC UA normalmente na porta 4840. Numa conexão TCP, o cliente abre a conexão para a porta de escuta do servidor; a resposta usa a mesma conexão. Quem inicia é relevante para a segurança: um controlador de campo que de repente abre conexões para a sala de controle está se comportando de modo diferente de um que só responde.
7.2 Protocolos industriais e as suas premissas
Muitos protocolos industriais foram projetados para enlaces seriais fechados entre as décadas de 1970 e 1990. O Modbus, por exemplo, define códigos de função para ler e escrever registradores e bobinas, e a sua forma clássica não tem autenticação: qualquer dispositivo que consiga enviar uma requisição bem formada a um controlador pode pedir que ele escreva (especificação do Modbus). Isso não é um bug de uma implementação; é a premissa de projeto de que só dispositivos confiáveis alcançam o fio. Quando esses protocolos passam a rodar sobre redes IP, essa premissa precisa ser imposta pela rede: segmentação, allowlists e monitoramento. Os protocolos modernos acrescentam segurança (o TLS 1.3 fornece canais autenticados e cifrados — RFC 8446), mas atualizar milhares de dispositivos de campo leva décadas.
7.3 Zonas, conduítes e allowlists
Uma zona é um grupo de ativos com requisitos de segurança semelhantes; um conduíte é o caminho de comunicação controlado entre zonas. A série ISA/IEC 62443 usa esses termos para sistemas industriais (visão geral da ISA/IEC 62443). Uma concessionária típica tem uma zona corporativa, uma zona desmilitarizada (DMZ) onde os dados são trocados, uma zona de controle (servidores SCADA, IHMs de operadores) e uma zona de campo (controladores, RTUs). Uma política de allowlist nomeia os fluxos permitidos — zona de origem, zona de destino, porta, finalidade — e nega todo o resto. A política é só metade do controle; a outra metade é conferir se o tráfego observado corresponde a ela.
7.4 Exemplo resolvido e Laboratório 4: conferir os fluxos da CW (sintético)
Este caso é sintético. A Calder Water permite três conduítes: os usuários corporativos veem o historiador na DMZ por HTTPS; um coletor na DMZ lê da zona de controle por OPC UA; o servidor SCADA consulta os controladores de campo por Modbus/TCP. Um resumo de fluxos de uma hora é conferido contra a política.
# Lab 4 - check observed flows against a zone-and-conduit allowlist (synthetic, offline)
ALLOW = { # (source zone, destination zone, destination port): purpose
("corporate", "dmz", 443): "historian web view",
("dmz", "control", 4840): "OPC UA read from historian replica collector",
("control", "field", 502): "Modbus/TCP polling of field controllers",
}
ZONE = {"10.1.": "corporate", "10.5.": "dmz", "10.20.": "control", "10.30.": "field"}
def zone(ip):
return next((z for p, z in ZONE.items() if ip.startswith(p)), "unknown")
FLOWS = [ # src, dst, dport (synthetic NetFlow-style summary)
("10.1.4.22", "10.5.0.10", 443), ("10.5.0.11", "10.20.0.5", 4840),
("10.20.0.5", "10.30.1.7", 502), ("10.1.4.80", "10.20.0.5", 3389),
("10.20.0.9", "198.51.100.23", 443), ("10.30.1.7", "10.20.0.5", 502),
]
for s, d, p in FLOWS:
key = (zone(s), zone(d), p)
verdict = ALLOW.get(key)
print(f"{s:>13} -> {d:<14} :{p:<5} {key[0]:>9}->{key[1]:<8} {'ALLOW ' + verdict if verdict else 'VIOLATION'}")
Saída esperada:
10.1.4.22 -> 10.5.0.10 :443 corporate->dmz ALLOW historian web view
10.5.0.11 -> 10.20.0.5 :4840 dmz->control ALLOW OPC UA read from historian replica collector
10.20.0.5 -> 10.30.1.7 :502 control->field ALLOW Modbus/TCP polling of field controllers
10.1.4.80 -> 10.20.0.5 :3389 corporate->control VIOLATION
10.20.0.9 -> 198.51.100.23 :443 control->unknown VIOLATION
10.30.1.7 -> 10.20.0.5 :502 field->control VIOLATION
Três violações, três significados diferentes. Uma conexão de área de trabalho remota (porta 3389) do corporativo direto para a zona de controle contorna a DMZ — talvez um atalho de um engenheiro, talvez um intruso. Um host da zona de controle alcançando um endereço da internet (198.51.100.23 é um endereço de documentação no lugar de um real) pode ser a verificação de atualizações de um fornecedor ou dados saindo. Um dispositivo de campo iniciando Modbus para o servidor SCADA inverte a direção normal. Nenhuma delas prova um ataque; cada uma precisa de um dono que a explique, e a explicação se torna evidência (Capítulo 15).
7.5 Atividade prática
Num computador que é seu, liste as suas próprias conexões ativas (por exemplo, com netstat ou ss) e classifique cinco como cliente ou servidor, local ou remota, e esperada ou inesperada. Não varra nenhum outro sistema.
Use a coluna de estado do ss ou do netstat: um endereço local com uma porta em escuta é um servidor; uma conexão para uma porta remota 443 é um cliente. Marque tudo o que você não conseguir explicar e encontre o programa por trás com as ferramentas do seu sistema operacional, na sua própria máquina.
7.6 Erros comuns e limites
- Escrever allowlists só por porta, ignorando as zonas de origem e de destino.
- Supor que "interno" significa "confiável".
- Confundir o tráfego de resposta com conexões iniciadas ao ler logs de fluxo.
- Tratar uma violação como prova de comprometimento, e não como uma pergunta.
O Laboratório 4 mostra por quê: uma regra só por porta que permitisse a 502 teria deixado passar o dispositivo de campo que iniciou Modbus para o servidor SCADA, uma inversão da direção normal. A conexão RDP corporativa para o controle é "interna" e mesmo assim é uma violação. Nos logs de fluxo, as respostas dos controladores de campo a partir da porta 502 para o servidor SCADA não são conexões novas e não devem ser lidas como tal. E cada uma das três violações vai primeiro para um dono como pergunta.
Exercícios — capítulo 7
EX013 — Explique as violações. Objetivo: raciocinar dos fluxos às hipóteses. Entradas: a saída do Laboratório 4. Etapas: para cada violação, dê uma explicação benigna e uma maliciosa e a evidência que as distinguiria. Evidência esperada: uma tabela de três linhas. Rubrica: 3 = pares plausíveis e evidência distintiva específica (tíquetes de mudança, logins de usuários, propriedade do destino, configuração do dispositivo); 2 = evidência genérica; 1 = só as explicações; 0 = nada.
EX014 — Fluxo mínimo. Objetivo: apertar uma política. Entradas: a tabela ALLOW. Etapas: proponha dois refinamentos que tornem a política mais estreita sem quebrar as suas finalidades (por exemplo, regras por host em vez de por zona, códigos de função só de leitura) e diga como cada um seria imposto e conferido. Evidência esperada: dois refinamentos com imposição e conferência. Rubrica: 3 = ambos mais estreitos, aplicáveis e verificáveis; 2 = um; 1 = vago; 0 = nada.
Síntese do capítulo
As redes carregam as premissas dos seus protocolos. Os protocolos industriais clássicos confiam em quem consegue alcançá-los, então os serviços críticos impõem a confiança com zonas, conduítes e allowlists — e depois conferem os fluxos observados contra a política. Uma violação é uma pergunta a um dono, e não um veredicto.
Continue estudando — capítulo 07 de 40
← Capítulo 06 · Índice de capítulos do curso · Capítulo 08 →
Siga para a próxima lição escrita.