Hardening DNP3 e IEC 104 em Redes de Utilidade

por União Geek · 13 de maio de 2026

Índice

1 Hardening DNP3 e IEC 104 em Redes de Utilidade

Hardening DNP3 e IEC 104 em Redes de Utilidade

Introdução: Em 2026, ataques a infraestruturas críticas continuaram a crescer em frequência e sofisticação, com agentes aproveitando protocolos legados na camada OT para movimentação lateral e sabotagem. Redes de utilidade – elétricas, de água e gás – frequentemente dependem de DNP3 e IEC 60870-5-104 (IEC 104) para supervisão e controle em tempo real. Este artigo técnico apresenta contexto estratégico, fundamentos dos protocolos, arquitetura e superfície de ataque, estudos de caso recentes, procedimentos práticos de implementação, regras de hardening, playbooks operacionais para Blue e Red Team, métricas de auditoria, erros comuns e FAQ técnico. O foco é prático: configuração, detecção, respostas e exemplos de código reutilizáveis para profissionais que operam SOCs, engenharias de controle e times de segurança OT.

Contexto Atual e Relevância Estratégica

O panorama de ameaças contra infraestruturas críticas evoluiu drasticamente entre 2024 e 2026. Relatórios de 2025-2026 indicam um aumento de ataques dirigidos a serviços públicos usando vetores que exploram protocolos industriais legados sem autenticação forte. Organizações continuam operando equipamentos e stacks com décadas de evolução funcional, mas sem mecanismos modernos de segurança. Essa combinação cria risco sistêmico significativo: interrupções de serviço, perda de integridade de comandos, e impactos regulatórios e financeiros severos.

Do ponto de vista de negócios, a dependência de DNP3 e IEC 104 é alta: controladores remotos, RTUs e servidores SCADA trocam telemetria, comandos e alarmes com latência baixa e disponibilidade máxima. Um ataque bem-sucedido pode levar a desligamentos, manipulação de medições e corrupção de histórico operacional. Em setores regulados, além do impacto operacional, há implicações legais e contratuais que aumentam o custo total de um incidente.

Relevância em 2026: três fatores tornam o hardening desses protocolos crítico agora. Primeiro, a maior disponibilidade de exploits e ferramentas de teste para protocolos OT, criadas por comunidades de pesquisa e por atores maliciosos; segundo, a crescente integração entre redes IT e OT via cloud, IIoT e telecoms 5G, eliminando isolamentos que antes mitigavam riscos; terceiro, novas exigências regulatórias em diversos países exigindo melhores controles para operadores de utilidade. Esses fatores exigem ação imediata e mensurável.

Este artigo endereça tanto a intenção informacional – explicar como DNP3 e IEC 104 funcionam e o que os torna vulneráveis – quanto a intenção prática – mostrar como mitigar, detectar e responder a abusos desses protocolos. Ao final, você terá roteiros operacionais, regras de detecção, exemplos de configuração de firewalls, TLS/TCP com IEC 62351, e scripts para validar hardening em ambientes de teste com Kali/Parrot e ferramentas open source.

Publicações recentes de 2026 sobre segurança OT reforçam a necessidade de priorizar controles específicos para esses protocolos. No contexto regulatório e operacional, adotar medidas de segrego de responsabilidades, autenticação forte e telemetria centralizada é agora imperativo para reduzir a probabilidade e o impacto de eventos adversos.

Fundamentos Técnicos do Tema

Para projetar controles eficazes, precisamos entender os fundamentos dos protocolos e como eles operam na prática. Abaixo, descrevo arquitetura, modelos de comunicação, tipos de mensagens, padrões de autenticação existentes, e limitações que influenciam o hardening.

DNP3 – Visão técnica: DNP3 (Distributed Network Protocol) nasceu nos anos 90 para atender utilities nos Estados Unidos e evoluiu para suportar comunicação entre masters (SCADA), outstations (RTUs) e subestações. Operando tipicamente sobre TCP/UDP na porta 20000, DNP3 tem camadas que tratam link, transporte e aplicação. Características importantes:

Mensagens de telemetria (binary inputs, analog inputs), eventos e comandos (control points).
Modelo mestre-escravo com polling e unsolicited responses.
Possibilidade de autenticação com DNP3 Secure Authentication (tratamento de assinaturas e sequência de autenticação), mas muitas instalações ainda usam DNP3 sem SA ou com SA parcialmente implementado.
Sem criptografia de payload por design antigo; integrações modernas recomendam encapsular em VPNs ou usar gateways com IEC 62351/TLS quando aplicável.

IEC 60870-5-104 (IEC 104) – Visão técnica: IEC 104 é a variante TCP/IP da família IEC 60870-5, muito usada fora dos EUA, em especial na Europa e Ásia. Opera sobre TCP na porta 2404. Características:

Comunicação orientada a conexão, com estrutura de mensagens ASDU (Application Service Data Unit).
Suporta diferentes tipos de informação: M_SP_NA_1 (status), M_ME_NC_1 (medidas), C_SC_NA_1 (comandos), entre outros.
Sem criptografia nativa; recomenda-se IEC 62351 para segurança, incluindo TLS e mecanismos de autenticação e controle de acesso.
Comportamento de estabelecimento de conexão e keep-alive que facilita fingerprinting e anomalias de timing como indicadores de ataque.

IEC 62351 – O padrão de segurança: IEC 62351 é a família de normas aplicadas para segurança de sistemas de energia. Inclui perfis para autenticação, gerenciamento de chaves, uso de TLS (transport profiles), e proteção de dados e mensagens. Em prática, IEC 62351-3 e 62351-5 são relevantes para proteger transporte e autenticação de protocolos como IEC 104. Para DNP3, a integração é mais por encapsulamento e por gateways que implementam IEC 62351 ou por adoção do Secure Authentication definido pela DNP Users Group.

Aspectos de baixo nível relevantes para hardening:

Sequência e numeração de frames (aplicável a DNP3). Ataques de replay podem subverter estados se a autenticação/nonce não for usada.
Sem timestamps confiáveis, RTUs podem aceitar comandos fora de ordem. Hardening exige sincronização temporal (NTP/PTP com segurança) e validação de timestamp em comandos críticos.
Comandos comand-control do tipo select-operate (2-step) em DNP3 e confirmações em IEC 104 podem ser forjadas se a conexão TCP for comprometida; por isso, autenticação de comandos e registro de autorias são críticos.

Vulnerabilidades típicas: Falta de criptografia, autenticação fraca ou ausente, exposição direta à WAN, credenciais padrão, falta de separação de rede e telemetria insuficiente. Em muitos ambientes, dispositivos legados bloqueiam atualizações de firmware, impedindo a correção de vulnerabilidades conhecidas.

Ferramentas e bibliotecas relevantes: pydnp3 (bindings Python para DNP3), lib60870-C (implementação IEC 104), Wireshark (dissectors DNP3 e IEC 104), Scapy (com camadas customizáveis para manipular protocolos), Zeek/Bro com scripts ICS, Suricata/IDS com regras, Nmap com scripts NSE adaptados para ICS e ferramentas de vendors como Secure SCADA Gateways. No mundo open source há projetos ativos que mudam a paisagem de testes e defesa; incorporar essas ferramentas ao pipeline de segurança é parte do hardening moderno.

Entender este conjunto técnico permite desenhar controles que não apenas bloqueiam tráfego, mas detectam manipulações lógicas, validação de sequência de comandos, e correlações entre eventos físicos e digitais. Nas próximas seções mostrarei como traduzir esse conhecimento em arquitetura e regras concretas.

Arquitetura, Fluxos e Superfície de Ataque

Projetar uma arquitetura segura começa com mapear fluxos de dados e superfícies de ataque. A seguir detalho modelos arquiteturais típicos, zonas de confiança recomendadas, pontos de inspeção e exemplos de regras de filtragem para DNP3 e IEC 104.

Modelo de Zonas e conduítes de dados: Utilize a abordagem segmentada baseada em NIST SP 800-82 e ISO-27001 para dividir a rede OT em pelo menos quatro zonas: Perímetro, DMZ OT, Zona de Controle e Zona de Campo. Cada zona tem requisitos de confiança, controle de tráfego e telemetria diferentes.

Perímetro: onde roteadores e firewalls se conectam à WAN/IT. Só tráfego ingressante autorizado e encaminhado para DMZ OT.
DMZ OT: servidores históricos, historian, HMI redundantes e gateways. Aqui acontecem traduções de protocolo e validações. Este é o local onde TLS e autenticação forte são terminadas quando possível.
Zona de Controle: SCADA masters, engineering workstations, e servidores de comando. Acesso restrito por VLANs e controles MFA. Registros detalhados de comandos.
Zona de Campo: RTUs, PLCs e equipamentos de linha. Latência e disponibilidade críticas. Use listas de controle estritas e filtros de comando.

Fluxos típicos: Em operação normal, a telemetria flui do RTU (zona de campo) para o master SCADA (zona de controle) via gateways ou diretamente por TCP (DNP3 porta 20000, IEC 104 porta 2404). Comandos de controle seguem o caminho inverso. Em arquiteturas modernas, replicação de dados para historians e servidores analíticos na DMZ é comum via link dedicado ou VPN. Estabeleça canais de leitura e escrita distintos, onde operações de escrita (comandos) passem por passos de validação adicionais.

Superfície de ataque específica para DNP3 e IEC 104:

Portas expostas – hosts com 20000/tcp/udp ou 2404/tcp diretamente acessíveis aumentam risco. Scanners automatizados e port sweeps detectam essas portas.
Falsificação de sessões TCP – man-in-the-middle em redes sem proteção permite injetar comandos.
Replay de pacotes – ausência de nonce/sequence numbers permite ataques de replay em DNP3 não autenticado.
Comandos de controle sem MFA – comando operate/select sem autenticação forte permite alteração de setpoints e abertura de breakers.
Gateways e conversores – translators que convertem DNP3/IEC104 para outros protocolos podem introduzir vulnerabilidades e credenciais fracas.
Firmware e credenciais padrão em RTUs – portas web administrativas ou protocolos não seguros para manutenção remota.

Pontos de inspeção e defesa: Coloque inspeção profunda em gateways e DMZ OT. Firewalls stateful (ou dispositivos baseados em application proxy) entre zones, com regras específicas para DNP3/IEC 104. WAFs tradicionais não aplicam, porque protocolos são binários; por isso, use proxies ICS-aware ou IDS/IPS com decoders para DNP3 e IEC 104. Regras de firewall devem ser “allow-list” (apenas endereços e portas necessários) e usar inspeção de sessão para detectar resets, SYN floods e sequências de comando suspeitas.

Exemplo prático de arquitetura segura: RTU – Field VLAN – Control VLAN – DMZ (proxy TLS/IEC 62351) – SCADA. Neste fluxo, o proxy na DMZ termina TLS e aplica validação de certificados e políticas de quem pode efetuar comandos. O RTU pode se conectar ao proxy por VPN dedicada ou por circuitos MPLS com ACLs estritas. Logging centralizado em SIEM com parsers para DNP3/IEC 104 deve correlacionar comandos com eventos físicos (ex: medição de corrente indicando breaker aberto).

Regra de firewall exemplo (nftables/iptables): Faça regras por IP e porta e limite conexões por segundo para mitigar fuzzing e scans automatizados. Um exemplo básico com nftables:

nft add table inet ot
nft add chain inet ot input { type filter hook input priority 0 ; policy drop ; }
# Permitir DNP3 do Master SCADA
nft add rule inet ot input ip saddr 10.1.1.10 tcp dport 20000 ct state new,established counter accept
# Permitir IEC 104 do master
nft add rule inet ot input ip saddr 10.1.1.10 tcp dport 2404 ct state new,established counter accept
# Bloquear todo o resto para estas portas
nft add rule inet ot input tcp dport {20000,2404} counter drop

nft add table inet ot

nft add chain inet ot input { type filter hook input priority 0 ; policy drop ; }

# Permitir DNP3 do Master SCADA

nft add rule inet ot input ip saddr 10.1.1.10 tcp dport 20000 ct state new,established counter accept

# Permitir IEC 104 do master

nft add rule inet ot input ip saddr 10.1.1.10 tcp dport 2404 ct state new,established counter accept

# Bloquear todo o resto para estas portas

nft add rule inet ot input tcp dport {20000,2404} counter drop

Essa configuração é um ponto de partida – regras devem incluir logging, rate limiting, e ações de bloqueio temporário para hosts que excedem thresholds.

Ferramentas de inspeção e monitoração: IDS com suporte a DNP3/IEC104 (Zeek, Suricata com decoders e regras ICS), collectors NetFlow/Zeek logs, e SIEM com dashboards para correlacionar telemetria SCADA. Importante: habilite dissectors para DNP3/IEC104 no Wireshark para análise forense e tune seus parsers Zeek para extrair métricas como contagens de comandos por IP, sequência de selects/operates e rates incomuns de unsolicited responses.

Nas próximas seções forneceremos cenários reais, exemplos de implementações passo a passo e regras de detecção para colocar em prática essa arquitetura.

Cenários Reais e Estudos de Caso

Estudos de caso ajudam a converter teoria em prática. Aqui apresento incidentes e análises aplicáveis a DNP3 e IEC 104, priorizando eventos e relatórios de 2025 e 2026 quando disponíveis. Cada caso inclui lições técnicas e recomendações de mitigação.

Caso 1 – Interrupção parcial em operadora regional (2026): Em março de 2026 uma operadora regional de distribuição elétrica reportou uma anomalia em múltiplos feeders durante um evento de manutenção. A investigação interna revelou que um scanner automatizado comprometeu uma interface de engenharia exposta, injetando comandos falsos via DNP3 para abrir setpoints em RTUs. O vetor primário foi uma VPN de manutenção com credenciais compartilhadas e sem autenticação multifator. Lessons learned:

Proteger conexões de manutenção com MFA e rotinas de expiração de credenciais;
Implementar proxies de protocolo na DMZ que exigem certificados para comandos de escrita;
Registrar e monitorar todas as operações de seleção/operar com correlação a operações humanas no ticketing system.

Caso 2 – Manipulação de telemetria em subestação (2025): Em um incidente documentado por um operador na Europa em 2025, um atacante falsificou valores de medidores reportados via IEC 104 para ocultar sobrecarga real durante um ataque físico subsequente. A falta de medidas de detecção de inconsistência entre sensores redundantes permitiu atraso na resposta. Recomendações:

Validar medidas por redundância física ou por regras de consistência no SIEM;
Habilitar verificação de intervalo e plausibilidade no historian;
Implementar alertas de correlação entre alarmes físicos (corrente/frequência) e comandos recebidos.

Caso 3 – Vulnerabilidade em gateway de vendor (CVE e advisories, 2026): Em 2026 diversos advisories de fornecedores relataram vulnerabilidades em gateways que realizavam tradução entre IEC 104 e DNP3, permitindo execução remota de código em modo root. Explorar gateways que fazem parsing de mensagens sem validação de tamanho é um vetor clássico. Mitigação técnica:

Aplicar patches do vendor imediatamente;
Segregar gateways em DMZ com acesso restrito e monitorado;
Submeter gateways a pentests regulares e revisão de firmware.

Análise técnica e ações defensivas: Esses casos destacam três falhas recorrentes: exposição de interfaces administrativas, autenticação fraca em caminhos de manutenção e confiança excessiva em um único fluxo de telemetria. Arquiteturas de defesa devem assumir que componentes podem falhar e, portanto, empregar multilayered controls: Authentication, Authorization, Non-repudiation, Logging, and Monitoring – integrados ao processo operacional e conformidade.

Estudo de caso real histórico para contexto: O incidente de Oldsmar (2021) onde acesso remoto permitiu alteração de químicos em planta de água mostrou fragilidade de sessões de manutenção remota. Usei esse histórico para enfatizar a importância de hardening de manutenção remota e segregação de funções, mesmo que seja anterior a 2025.

Casos de uso de deteção efetiva: Em 2026, vários SOCs mostraram sucesso ao detectar tentativas de manipulação de IEC 104 usando regras de anomalia de taxa no Zeek: conexões com padrão de keep-alive anormal, seguida de bursts de comandos C_SC_NA_1 são indicadores de scan+fuzz. Regras tunadas que correlacionam origem do comando e asset owner reduziram falsos positivos.

Para cada estudo de caso acima há um conjunto de ações concretas que discutiremos no playbook e seção de implementação passo a passo: mudanças de arquitetura, configurações de firewall, geração e rotação de certificados TLS, criação de regras de SIEM e runbooks de resposta.

Implementação Prática Step-by-Step

Esta seção fornece um roteiro operacional para validar e aplicar hardening em ambientes de teste antes do rollout em produção. Incluo comandos para Kali/Parrot, scripts Python de conexão e exemplos de configuração de proxy TLS e regras de IDS. Sempre confirme autorização e escopo antes de executar qualquer teste.

Pré-requisitos e ambiente de teste:

Máquina Kali Linux ou Parrot com Wireshark, Nmap, Scapy, pydnp3 e lib60870-C instalados;
Ambiente de laboratório isolado com RTU simulada (por exemplo, um container ou máquina virtual rodando simulador de RTU), master SCADA de teste e gateway;
Acesso a ferramentas de SIEM como Splunk ou Elastic Stack para ingestão de logs.

Passo 1 – Mapeamento inicial (reconhecimento passivo e ativo)

Reconhecimento passivo com Zeek ou tcpdump para identificar hosts que comunicam nas portas DNP3 e IEC104.
Scans leves com Nmap para identificar portas abertas e versões.

# Captura passiva com tcpdump
sudo tcpdump -i eth0 'tcp port 2404 or tcp port 20000' -w captura_ics.pcap

# Scan leve com Nmap para identificar serviços
sudo nmap -sT -Pn -p 2404,20000 --open -sV -oN scan_ics.txt 10.0.0.0/24

# Captura passiva com tcpdump

sudo tcpdump -i eth0 'tcp port 2404 or tcp port 20000' -w captura_ics.pcap

# Scan leve com Nmap para identificar serviços

sudo nmap -sT -Pn -p 2404,20000 --open -sV -oN scan_ics.txt 10.0.0.0/24

Validação: Verifique se algum host responde nas portas 2404 (IEC 104) ou 20000 (DNP3). No arquivo scan_ics.txt registros como “2404/tcp open modbus?” podem aparecer; use Wireshark para confirmar dissector correto.

Passo 2 – Análise de protocolo com Wireshark e dissectors

Abra a captura no Wireshark e filtre por dnp3 ou iec104.
Inspecione frames de controle, sequence numbers e comandos de operação.

# Exemplo de filtro Wireshark para DNP3
dnp3

# Filtro para IEC 104
iec104

# Exemplo de filtro Wireshark para DNP3

dnp3

# Filtro para IEC 104

iec104

Validação: Confirme se comunicações são em texto claro sem TLS e se há comandos write/select/operate. Anote IPs e horários para correlação com logs do historian.

Passo 3 – Testes controlados com pydnp3 e lib60870

Exemplo para DNP3 com pydnp3 (Python)

# Exemplo mínimo de leitura DNP3 com pydnp3
# Salve como read_dnp3.py
from pydnp3 import opendnp3, asiodnp3, asiopal
import time

# Endereço do outstation
remote = "10.0.0.50"
port = 20000

manager = asiodnp3.DNP3Manager(1)
channel = manager.AddTCPClient("client", opendnp3.ChannelRetry(5000), asiopal.default_logger(), remote, port)
stack = channel.AddMaster("master", DefaultMasterApplication(), opendnp3.MasterStackConfig())

# Função exemplo de leitura - adapte ao seu modelo de dados
stack.PerformIntegrityScan()

time.sleep(5)
manager.Shutdown()

# Exemplo mínimo de leitura DNP3 com pydnp3

# Salve como read_dnp3.py

from pydnp3 import opendnp3, asiodnp3, asiopal

import time

# Endereço do outstation

remote = "10.0.0.50"

port = 20000

manager = asiodnp3.DNP3Manager(1)

channel = manager.AddTCPClient("client", opendnp3.ChannelRetry(5000), asiopal.default_logger(), remote, port)

stack = channel.AddMaster("master", DefaultMasterApplication(), opendnp3.MasterStackConfig())

# Função exemplo de leitura - adapte ao seu modelo de dados

stack.PerformIntegrityScan()

time.sleep(5)

manager.Shutdown()

Validação: O script deve estabelecer conexão e obter uma leitura de integridade. Caso receba reset ou erro, examine logs e capture com tcpdump para analisar payload.

Exemplo para IEC 104 com lib60870 (uso de utilitário lib):

# Exemplo: usando ferramenta de linha lib60870 para leitura
# Assumindo que lib60870 tools estão instalados
# Conectar e ler ASDU
./iec104_client 10.0.0.50 2404

# Exemplo: usando ferramenta de linha lib60870 para leitura

# Assumindo que lib60870 tools estão instalados

# Conectar e ler ASDU

./iec104_client 10.0.0.50 2404

Validação: Observe respostas ASDU e confirme tipos de dados. Ferramentas podem oferecer flags verbose para debugging.

Passo 4 – Implementando TLS com proxy (IEC 62351)

Para IEC 104 uma estratégia prática é usar um TLS-terminating proxy na DMZ que exponha uma interface TLS para SCADA masters e uma interface TCP clara para RTUs, ou preferir TLS end-to-end se os equipamentos suportarem. Abaixo um exemplo de proxy com stunnel (cenário DMZ).

# Exemplo stunnel para encapsular IEC 104 em TLS
# Gerar certificado
openssl req -newkey rsa:2048 -nodes -keyout ot_proxy.key -x509 -days 365 -out ot_proxy.crt -subj "/CN=ot-proxy.local"

# Arquivo de configuração stunnel.conf
# cert = /path/ot_proxy.crt
# key = /path/ot_proxy.key
# [iec104-tls]
# accept = 24045
# connect = 10.0.0.50:2404
# client = no

# Start stunnel
stunnel stunnel.conf

# Exemplo stunnel para encapsular IEC 104 em TLS

# Gerar certificado

openssl req -newkey rsa:2048 -nodes -keyout ot_proxy.key -x509 -days 365 -out ot_proxy.crt -subj "/CN=ot-proxy.local"

# Arquivo de configuração stunnel.conf

# cert = /path/ot_proxy.crt

# key = /path/ot_proxy.key

# [iec104-tls]

# accept = 24045

# connect = 10.0.0.50:2404

# client = no

# Start stunnel

stunnel stunnel.conf

Validação: Conectar master SCADA à porta 24045 com TLS. No proxy, habilite logging e verifique a negociação TLS. Configure certificados de client para mutual TLS se possível.

Passo 5 – Criação de regras IDS/IPS e detecção:

Empregue Zeek para extrair métricas de DNP3/IEC104. Exemplo de regra Suricata para detectar tentativa de conexão IEC 104 e bursts de comandos:

# Exemplo simples Suricata YAML rule (mínimo)
alert tcp any any -> any 2404 (msg:"IEC104 connection attempt"; flow:established; sid:1000001; rev:1;)
# Regra para DNP3
alert tcp any any -> any 20000 (msg:"DNP3 connection attempt"; flow:established; sid:1000002; rev:1;)

# Exemplo simples Suricata YAML rule (mínimo)

alert tcp any any -> any 2404 (msg:"IEC104 connection attempt"; flow:established; sid:1000001; rev:1;)

# Regra para DNP3

alert tcp any any -> any 20000 (msg:"DNP3 connection attempt"; flow:established; sid:1000002; rev:1;)

Validação: Gere tráfego de teste e confirme alertas no Suricata. Para reduzir falsos positivos, correlacione com listas de masters permitidos e thresholds de comando.

Passo 6 – Rollback e validação de produção:

Antes do rollout em produção siga um plano de rollback documentado:

Aplicar mudanças em ambiente de teste com backlog de dados e simulação de cargas.
Deploy em segmento não-crítico e monitorar por 48-72h.
Se erros críticos ocorrerem, reverter configuração do proxy/firewall e restaurar a rede anterior usando snapshots ou scripts de configuração automatizados.

Validação: Critérios de sucesso incluem: latência dentro de SLAs, ausência de falsos positivos em alertas críticos e integridade de armazenamento histórico de medição.

Esse passo-a-passo é um roteiro mínimo. Em ambientes reais você terá processos de change control e janelas de manutenção. No próximo tópico entramos no hardening detalhado por componente e controles essenciais.

Hardening, Controles e Melhores Práticas

Hardening eficaz combina controles técnicos, processos e governança. Abaixo ofereço uma lista abrangente de controles categorizados por nível, com instruções práticas e considerações de operação.

Controles de rede

Segmentação por VLANs e ACLs – isole RTUs em segmentos mínimos com regras whitelist estritas para IPs masters conhecidos.
Firewalls stateful com inspeção de sessão e regras específicas para DNP3/IEC104 – bloquear tudo que não for permitido explicitamente.
Proxy ICS-aware / protocol gateway – terminar sessões, validar mensagens e aplicar políticas de segurança para comandos de escrita.
Rate limiting para prevenir scanning e fuzzing – use QoS e policers para limitar bursts de pacotes.

Autenticação e criptografia

Implementar DNP3 Secure Authentication onde suportado. Se não for possível, encapsular DNP3 em VPNs gerenciadas com autenticação forte e rotação de chaves.
Para IEC 104, adotar perfis IEC 62351 e TLS com certificados gerenciados por PKI dedicada OT. Use mutual TLS para canais críticos.
Gerenciamento de chaves e certificação: rotação regular, revogação e monitoramento de certificados expirados.

Controles de dispositivo

Firmware management e proteção de imagens – processos de atualização com assinaturas digitais e validação de integridade.
Desativar serviços não usados – portas web, Telnet, SNMP v1/v2 antigos.
Credenciais únicas por dispositivo, política de senhas fortes e desabilitar contas padrão.
Hardened TLS stacks e bibliotecas atualizadas; evitar bibliotecas obsoletas com CVEs conhecidos.

Monitoramento e detecção

Coleta centralizada de logs SCADA, gateway e dispositivos com parsing de DNP3/IEC104.
Detecção de anomalias baseadas em modelo: taxas de comandos, sequência de selects/operates, discrepância entre telemetria redundante.
Use Zeek/IDS com regras ICS e crie enriquecimento com asset context e roles.

Operações e governança

Processo de change management para todos os comandos que afetem operação crítica.
Treinamento e exercícios regulares de tabletop entre operação, segurança e gestão de risco.
Listas de acesso e justificativas para conexões de manutenção remota; expiração automática e logs audíveis.

Controles específicos e exemplos de configuração

Exemplo de política de firewall – permitir apenas os seguintes fluxos:

Master SCADA 10.1.1.10 -> RTU 10.2.2.10: TCP/20000 (DNP3) – somente established, com rate limit;
Master SCADA 10.1.1.10 -> RTU 10.2.2.10: TCP/2404 (IEC 104) – via proxy TLS na DMZ, com mTLS requerido;
Historian DMZ -> Master SCADA: replicação somente por canal de leitura autenticado e IPs permitidos.

Detecção de tampering e integridade:

Assinar logs críticos e armazenar em WORM/HSM quando necessário para assegurar não-repúdio.
Verificação periódica de integridade de firmware via checksums assinados; monitorar boot chains.

Resposta a incidentes e playbooks

Defina playbooks com passos claros: isolar dispositivo, coletar captura de tráfego, analisar comandos recentes, realizar rollback de configuração e acionar equipes de campo. Ensure chain of custody e preservação de evidências para investigações e auditorias.

Boas práticas de implementação:

Comece pelo perímetro e DMZ, depois avance para RTUs.
Priorize assets críticos com controles compensatórios enquanto atualizações permanentes são planificadas.
Faça testes de regressão com operadores para ver impacto em latência e confiabilidade.

Hardening não é apenas aplicar controles técnicos; envolve processos de auditoria, testes e validação contínua. Nas próximas seções veremos playbooks e KPIs que permitem medir eficácia operacional.

Playbooks Operacionais para Blue Team e Red Team

Playbooks transformam planos em ações durante rotina e crise. Abaixo listo playbooks separados e práticos, incluindo comandos, hipóteses, validações e evidências requisitadas.

Playbook Blue Team – Detecção, contenção e recuperação

Objetivo: Detectar e conter tentativas de manipulação DNP3/IEC104 e restaurar operação segura.
Pré-condições: Logging centralizado, IDS com regras ICS e lista de masters autorizados.

Passos operacionais:

Detecção: Alertas ICS: surge de alto número de selects/operates, conexões de IP não-autorizado em portas 2404/20000, ou discrepância telemetria vs leitura física. Validar com logs Zeek/Suricata e capturas pcap.
Identificação: Correlacionar IP fonte com asset inventory. Verifique usuário/conta de origem e justificativa de change ticket.
Contenção: Se host for malicioso, aplicar regras de firewall temporárias para bloquear IP, isolar segmento com ACL e ativar modo de leitura apenas no master, se aplicável.
Mitigação: Reverter comandos que alteraram setpoints, se possível. Notificar operação e, se necessário, solicitar intervenção física no equipamento.
Recuperação: Verificar integridade de dispositivos e restabelecer comunicações com controles reforçados. Aplicar patches e mudar credenciais.
Lessons learned: Atualizar playbook, ajustar regras de deteção e conduzir treinamento com equipe de operação.

Evidências a coletar: captures pcap, logs de IDS, comandos registrados no historian, snapshots de configuração do gateway e imagens de dispositivos suspeitos.

Playbook Red Team – Testes autorizados e validação dos controles

Objetivo: Testar resiliência dos controles implementados contra ameaças realistas sem comprometer operação.
Pré-condições: Escopo e autorização documentados, janela de testes, rollback plan e comunicação com operadores.

Passos operacionais:

Reconhecimento: Passivo com Zeek, ativo com Nmap mínimo. Registrar descoberta de hosts e portas.
Enumerar serviços: Wireshark e scripts específicos para identificar versões e comportamento.
Testes de fuzzing controlado: Enviar sequências anômalas de comandos com limites de taxa e monitorar impactos. Use ferramentas como Scapy e scripts customizados.
Testes de autenticação e crypto: Validar se DNP3 Secure Authentication está habilitado, testar rotação de chaves e rejeição de replays.
Exfiltração simulada: Verificar se telemetria extra sensível pode ser obtida via canais não-autorizados.
Relato e remediação: Documentar evidências, impacto potencial e recomendações concretas prioritárias.

Práticas éticas: Sempre opere com escopo e autorização. Prepare um fail-safe para interrupções e conduza testes em horários de baixa criticidade quando possível.

Playbooks acima devem ser integrados ao processo de gestão de incidentes e auditados regularmente. Nos próximos blocos veremos métricas e KPIs para provar eficácia.

Métricas, KPIs e Auditoria Técnica

Métricas bem definidas permitem mensurar maturidade do hardening e justificar investimentos. Abaixo proponho métricas de segurança OT, KPIs operacionais e métodos de auditoria técnica para DNP3 e IEC 104.

KPI de segurança recomendado:

Tempo médio de detecção (MTTD) para atividades em DNP3/IEC104 – objetivo: <24 horas, meta operativo: <1 hora para sinais críticos;
Tempo médio de resposta (MTTR) para bloqueio/isolamento de conexão ICS – objetivo: <2 horas para eventos críticos;
Porcentagem de devices com autenticação forte habilitada – objetivo: 90%+;
Percentual de tráfego DNP3/IEC104 encapsulado em TLS ou VPN – objetivo: 100% para comms sensíveis;
Taxa de falsos positivos nas regras de IDS – objetivo: reduzir a níveis operacionais administráveis, por exemplo <5%;
Número de patches críticos aplicados em gateways em 30 dias – meta: 100%.

Métricas técnicas específicas:

Contagem diária de comandos de escrita por dispositivo;
Contagem de eventos de sequence number resets ou out-of-order packets;
Eventos de conexão por IPs não autorizados para portas 20000/2404;
Latência média de resposta após aplicação de TLS/proxy;
Porcentagem de logs SCADA integrados ao SIEM com parsing correto.

Métodos de auditoria técnica:

Auditoria passiva de tráfego por 30 dias para estabelecer baseline;
Testes de penetração focados em gateways e pontos de manutenção;
Validação de configuração de firewalls e ACLs com scripts (ansible/terraform) para garantir consistência e possibilidade de rollback;
Auditoria de quem tem acesso de manutenção e análise de tickets de autorização.

Ferramentas e queries úteis (SIEM – Splunk/Elastic):

Exemplo de query Splunk para detectar comandos DNP3 a partir de IPs não autorizados:

index=ics_logs sourcetype=dnp3 | search NOT src_ip IN (10.1.1.10,10.1.1.11) | stats count by src_ip, dst_ip, command_type

1	index=ics_logs sourcetype=dnp3 \| search NOT src_ip IN (10.1.1.10,10.1.1.11) \| stats count by src_ip, dst_ip, command_type

Validação: Ajuste a lista de IPs autorizados conforme inventário e crie alertas automáticos com playbooks anexos.

Auditoria de conformidade: Realize revisões trimestrais dos controles com evidências: logs, screenshots de config, e relatórios de patch. Conecte auditoria técnica com requisitos regulatórios locais e frameworks como NIST CSF, IEC 62443 e ISO 27001.

Essas métricas e auditorias permitem justificar melhorias e demonstrar redução de risco. Agora, vejamos erros comuns e armadilhas que frequentemente impedem progresso.

Erros Comuns, Armadilhas e Correções

Mesmo boas iniciativas podem falhar por erros práticos. A seguir, os erros mais frequentes observados em projetos de hardening DNP3/IEC104 e como corrigir.

Erro 1 – Suporte parcial a autenticação

Problema: Implementar apenas autenticação unilateral ou apenas VPNs pontuais que não cobrem todos os fluxos. Impacto: falsa sensação de segurança e janelas de vulnerabilidade em rotas não cobertas. Correção: Fazer inventário completo de fluxos, aplicar solução coerente – preferivelmente mTLS com PKI para caminhos críticos ou DNP3 Secure Authentication end-to-end quando disponível.

Erro 2 – Configuração de proxy sem testes de latência

Problema: Inserir proxies de TLS sem avaliar impacto em tempo real, levando a timeouts. Correção: Medir latência e jitter em ambiente controlado; aplicar QoS e priorização; usar proxies com performance adequada ou hardware acelerado quando necessário.

Erro 3 – Falha em rotacionar chaves e credenciais

Problema: Certificados e chaves com prazo longo ou senhas hard-coded. Correção: Implementar PKI OT com ciclos de rotação, automação de renew e auditoria. Para dispositivos sem PKI, aplicar controle de acesso físico e compensar com monitoramento rigoroso.

Erro 4 – Excessiva confiança em IDS signature-based

Problema: Assumir que assinaturas cobrem todos os ataques. Correção: Combinar assinaturas com detecção comportamental; use modelos de anomalia e correlacione eventos físicos com comandos SCADA.

Erro 5 – Falta de integração com processos operacionais

Problema: Segurança aplicada sem envolver engenheiros de operação, gerando resistência e workarounds inseguros. Correção: Treinamento cruzado, inclusão de operadores nos testes e criação de procedimentos de exceção claros e auditáveis.

Erro 6 – Implementar controles sem testes de rollback

Problema: Mudanças que afetam operação crítica sem plano de reversão testado. Correção: Automação de infraestrutura com versão, snapshots e procedimentos de rollback verificados em laboratório.

Cada correção exige documentação e ciclos curtos de feedback. Nas próximas seções responderemos perguntas frequentes que profissionais fazem ao implantar essas medidas.

FAQ Técnico para Busca Orgânica

Esta seção responde 10 perguntas técnicas comuns sobre hardening de DNP3 e IEC 104, formuladas para ocupar featured snippets e fornecer respostas objetivas e acionáveis.

Pergunta 1: O que é DNP3 Secure Authentication e por que usar?

Resposta: DNP3 Secure Authentication adiciona autenticação de mensagens e proteção contra replay usando chaves e sequência de autenticação. Use para garantir que comandos e eventos venham de masters autorizados e não tenham sido forjados ou repetidos. Implementá-lo reduz risco de comando não autorizado e fornece evidência de autoria.

Pergunta 2: IEC 104 pode usar TLS? Como aplicar?

Resposta: Sim. IEC 104 pode ser protegido por TLS seguindo perfis definidos na IEC 62351. Implementação prática consiste em inserir um TLS-terminating proxy na DMZ ou habilitar TLS end-to-end se dispositivos suportarem. Use PKI, mTLS e rotação de chaves.

Pergunta 3: Qual porta padrão e como detectá-la?

Resposta: DNP3 usa tipicamente TCP/UDP 20000. IEC 104 usa TCP 2404. Detecte com nmap e tcpdump, e confirme com dissectors do Wireshark e signatures IDS.

Pergunta 4: Como prevenir replay attacks em RTUs?

Resposta: Ative Secure Authentication (DNP3) ou encapsule transporte em canais que forneçam integridade e anti-replay (TLS com nonce). Além disso, valide timestamps e sequence numbers e sincronize relógios com NTP/PTP seguro.

Pergunta 5: O que monitorar para detectar manipulação de telemetria?

Resposta: Monitore variações bruscas em leituras sem alteração física correspondente, discrepância entre sensores redundantes, e bursts de comandos de escrita. Crie dashboards no SIEM que correlacionem telemetria e eventos físicos.

Pergunta 6: Quais ferramentas open source para analisar DNP3/IEC104?

Resposta: Wireshark (dissectors), Zeek (scripts ICS), Suricata/IDS, pydnp3, lib60870-C, Scapy para criação de pacotes customizados, e nmap para reconhecimento. Use também ferramentas de vendor para validar compatibilidade.

Pergunta 7: É possível encapsular DNP3 em TLS diretamente?

Resposta: Em geral, DNP3 não define TLS nativamente; encapsulamento via VPN ou TLS-terminating gateway é prática comum. Alternativamente, adotar DNP3 Secure Authentication é a forma mais padronizada para proteger aplicação.

Pergunta 8: Como reduzir falsos positivos ao detectar IEC 104?

Resposta: Enriquecer alertas com contexto de asset, whitelist de masters, e thresholds adaptativos. Use machine learning supervisionado para separar padrões operacionais legítimos de anomalias.

Pergunta 9: Quais logs são essenciais para auditoria?

Resposta: Logs de gateway/proxy (conexões TLS, certificados), logs do master SCADA (quem executou comandos), historian, IDS/Zeek e captures pcap de eventos críticos. Armazene por prazos compatíveis com regulamentos e processos forenses.

Pergunta 10: Onde começar se minha frota é heterogênea e legada?

Resposta: Comece pelo inventário de ativos e mapeamento de fluxos. Priorize proteção de gateways e caminhos de comando por serem pontos de agregação. Aplique controls compensatórios (VPNs, proxies) antes de atualizar firmware em massa.

Considerações Finais

Hardening de DNP3 e IEC 104 não é um trabalho pontual – é um processo contínuo que mistura engenharia de rede, segurança de protocolos e operação. Em 2026, com maior conectividade e novas regulamentações, operadores de utilidade precisam mover-se rapidamente: aplicar autenticação forte, segmentação, proxies TLS, monitoramento e processos de resposta. As medidas técnicas aqui descritas são práticas e implementáveis com ferramentas existentes; no entanto, o sucesso depende de governança, testes e colaboração interdisciplinar entre OT, IT e times de segurança.

Minha recomendação final: trate cada alteração como experimento com hipóteses mensuráveis. Meça MTTD e MTTR, reduza exposição de portas, e faça testes regulares de penetração autorizados. Segurança em infraestruturas críticas é sobre reduzir o número de maneiras pelas quais algo ruim pode acontecer. Se você construir sistemas que assumem erro e erro humano, o resto se torna administrável.

Segurança não é um destino. É a disciplina de manter vigilância, aprender com cada incidente e melhorar a operação. Em redes onde cada bit pode representar um ato físico, essa disciplina é obrigatória.

Recursos Visuais Sugeridos

Materiais públicos com diagramas, arquiteturas e visuais oficiais para apoiar o estudo do tema.

MITRE ATT&CK – matriz visual de táticas, técnicas e procedimentos.
CISA Resources – alertas, advisories e diagramas de arquitetura defensiva.
NIST Cybersecurity Framework – figuras oficiais e referências de controles.
ENISA – relatórios anuais com gráficos e mapas de ameaça.
Kali Linux – documentação oficial com fluxos práticos.
Parrot Security – documentação oficial com arquitetura modular.

Referências

https://www.cisa.gov/ics
https://attack.mitre.org/matrices/ics/
https://www.dnp.org/
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r2.pdf
https://www.iec.ch/
https://github.com/dnp3/pydnp3
https://github.com/mz-automation/lib60870
https://cert-portal.siemens.com/productcert/
https://www.enisa.europa.eu/
https://www.wireshark.org/

Abordagem	Risco mitigado	Custo operacional	Esforço de implementação	Maturidade
Whitelist de IPs + ACL	Exposição de portas e scans	Baixo	Baixo-médio	Alto
Proxy TLS na DMZ	Inspeção de comandos e autenticação	Médio	Médio	Médio-alto
DNP3 Secure Authentication	Autenticidade de mensagens	Médio	Médio-alto (depende de suporte do RTU)	Médio
Encapsulamento via VPN/MPLS	Confidencialidade do transporte	Médio	Médio	Alto
PKI e mTLS end-to-end	Autenticação forte e integridade	Alto	Alto	Alta
IDS/Behavioral Analytics	Detecção de anomalias e ataques complexos	Médio	Médio	Médio

Arquitetura simplificada de defesa para DNP3/IEC104

[Internet/IT] --- [Perímetro Firewall] --- [DMZ OT Proxy/TLS] --- [Zona de Controle Master SCADA]
                                    |                                   |
                                    |                                   |
                                [Historian]                         [Engineering WS]
                                    |
                              [Firewall interno]
                                    |
                              [Zona de Campo - VLANs]
                              |       |       |
                           RTU1    RTU2    RTUn
                         (IEC104) (DNP3)  (DNP3)
                         
Fluxos:
- Master SCADA <-> DMZ Proxy (mTLS) <-> RTU (TCP 2404 ou 20000)
- Historian replica via canal autenticado
- SIEM ingest logs via syslog/agents

Arquitetura simplificada de defesa para DNP3/IEC104

[Internet/IT] --- [Perímetro Firewall] --- [DMZ OT Proxy/TLS] --- [Zona de Controle Master SCADA]

| |

[Historian] [Engineering WS]

[Firewall interno]

[Zona de Campo - VLANs]

| | |

RTU1 RTU2 RTUn

(IEC104) (DNP3) (DNP3)

Fluxos:

- Master SCADA <-> DMZ Proxy (mTLS) <-> RTU (TCP 2404 ou 20000)

- Historian replica via canal autenticado

- SIEM ingest logs via syslog/agents

Objetivo: Implementar proxy TLS para IEC 104 e validar conectividade sem impacto.
1. Preparação: Ambiente de teste isolado com Master SCADA (10.1.1.10), DMZ proxy (10.1.2.10) e RTU simulado (10.2.2.10).
2. Comando – gerar certificados:
  
  openssl req -newkey rsa:2048 -nodes -keyout dmz.key -x509 -days 365 -out dmz.crt -subj "/CN=dmz-proxy.local"
  1
  openssl req -newkey rsa:2048 -nodes -keyout dmz.key -x509 -days 365 -out dmz.crt -subj "/CN=dmz-proxy.local"
3. Comando – configurar stunnel:
  
  # stunnel.conf cert = /path/dmz.crt key = /path/dmz.key [iec104-tls] accept = 24045 connect = 10.2.2.10:2404
  1
  2
  3
  4
  5
  6
  7
  # stunnel.conf
  cert = /path/dmz.crt
  key = /path/dmz.key
  [iec104-tls]
  accept = 24045
  connect = 10.2.2.10:2404
4. Execução: Start stunnel e conectar Master SCADA em 10.1.2.10:24045 com TLS. Monitorar logs do proxy e tcpdump no RTU.
5. Validação: Verificar no RTU recebimento de conexões na porta 2404 e no proxy a negociação TLS. Testar failover revertendo configuração para conexão direta e confirmando rollback.
6. Evidências: captura pcap do proxy, logs TLS com handshake, testes de latência e relatório de impacto.
Objetivo: Detectar comando forjado DNP3 em ambiente de teste
1. Preparação: Kali com pydnp3 instalado e Suricata configurado com regras para TCP 20000.
2. Comando – scan DNP3:
  
  sudo nmap -sT -p 20000 --open -sV 10.2.2.0/24
  1
  sudo nmap -sT -p 20000 --open -sV 10.2.2.0/24
3. Comando – enviar comando forjado (test only):
  
  # script python para enviar controle - hipotético e apenas em lab python3 send_dnp3_command.py --target 10.2.2.10 --port 20000 --point 1 --operate
  1
  2
  # script python para enviar controle - hipotético e apenas em lab
  python3 send_dnp3_command.py --target 10.2.2.10 --port 20000 --point 1 --operate
4. Validação: Suricata gerará alertas. Captura pcap e logs do RTU mostram tentativa de comando. Avaliar regras e ajustar assinaturas para minimizar falsos positivos.
5. Rollback: Remover scripts e restaurar configuração do RTU a partir de snapshot se necessário.

Checklist Blue Team:

Inventory completo de dispositivos e fluxos DNP3/IEC104.
Firewall com whitelist configurada para portas 20000/2404.
Proxy/TLS implementado para canais de comando críticos.
PKI e rotação de certificados em vigor.
IDS/Zeek com regras específicas e dashboards em SIEM.
Playbook de resposta testado e disponível.
Procedimentos de manutenção remota com MFA e sessões auditadas.
Testes regulares de penetração e avaliações de firmware.

Checklist Red Team (autorizado):

Autorização formal e escopo claro com stakeholders OT/IT.
Janela de teste acordada e plano de rollback.
Ferramentas preparadas: pydnp3, lib60870, Scapy, Nmap e Wireshark.
Hipóteses de ataque documentadas (ex: replay, spoofing, fuzzing).
Execução controlada com thresholds de segurança para evitar interrupções.
Coleta de evidências: pcap, logs, screenshots e notas de execução.
Relatório detalhado com recomendações priorizadas para mitigação.
Sessão de debrief com times de operação e segurança.

Recursos Visuais Sugeridos:

Wireshark DNP3 dissector documentation – https://www.wireshark.org/docs/
MITRE ATT&CK for ICS matrix – https://attack.mitre.org/matrices/ics/
DNP Users Group technical resources – https://www.dnp.org/
lib60870 GitHub (exemplos e diagramas de ASDU) – https://github.com/mz-automation/lib60870
NIST SP 800-82r2 (ICS Security Guide) – https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r2.pdf
CISA ICS resources and advisories – https://www.cisa.gov/ics