Monitoramento de Anomalias no Tráfego Modbus SCADA

Quando Usar

• Monitorar redes OT/ICS em busca de comandos Modbus não autorizados direcionados a PLCs, RTUs ou HMIs
• Detectar atividades de reconhecimento, como enumeração de dispositivos Modbus (código de função 43, Read Device Identification)
• Identificar operações de escrita não autorizadas (códigos de função 05, 06, 15, 16) em coils e holding registers que podem alterar parâmetros físicos do processo
• Estabelecer uma linha de base de padrões normais de comunicação Modbus e alertar sobre desvios na distribuição de códigos de função, faixas de acesso a registradores ou intervalos de tempo
• Investigar suspeitas de sabotagem ou ameaças internas que manipulam valores de processo SCADA através de escritas em registradores Modbus

Não use em redes sem autorização do proprietário do ativo, para injeção ativa ou fuzzing contra sistemas SCADA de produção, ou como substituto para sistemas instrumentados de segurança (SIS) que fornecem proteção física do processo.

Pré-requisitos

• Um tap de rede ou porta SPAN no segmento de rede OT que transporta tráfego Modbus TCP (porta 502)
• Python 3.9+ com pymodbus (>=3.6), scapy (>=2.5) e pandas para análise de tráfego
• Zeek (anteriormente Bro) instalado com o analisador de protocolo Modbus habilitado para registro passivo de tráfego
• Wireshark ou tshark para captura inicial de pacotes e validação da estrutura de frames Modbus
• Um período de linha de base de operações normais (mínimo de 48-72 horas) para estabelecer perfis de comunicação por par de dispositivos
• Diagrama de rede identificando relacionamentos mestre-escravo Modbus, endereços IP dos dispositivos e uso esperado de códigos de função

Fluxo de Trabalho

Etapa 1: Capturar e Analisar Tráfego Modbus TCP

Estabeleça o monitoramento passivo no segmento de rede OT e comece a capturar frames Modbus TCP:

• Configurar tap de rede: Posicione a interface de monitoramento na porta SPAN que espelha a VLAN que transporta o tráfego Modbus TCP entre servidores HMI/SCADA e PLCs. Verifique a captura de tráfego bidirecional com tcpdump -i eth0 port 502 -c 100 -w modbus_capture.pcap.
• Analisar a estrutura do frame Modbus TCP: Cada frame Modbus TCP contém um cabeçalho MBAP (Modbus Application Protocol) de 7 bytes seguido pelo PDU. O cabeçalho MBAP inclui:
  • Transaction Identifier (2 bytes): Corresponde requisições a respostas
  • Protocol Identifier (2 bytes): Sempre 0x0000 para Modbus
  • Length (2 bytes): Número de bytes seguintes, incluindo Unit ID
  • Unit Identifier (1 byte): Endereço do dispositivo escravo (0-247)
• Extrair códigos de função com Scapy: Use o módulo Modbus contrib do Scapy para dissecar pacotes capturados e extrair códigos de função, endereços de registradores e valores:

  from scapy.all import rdpcap, TCP
  from scapy.contrib.modbus import ModbusADURequest, ModbusADUResponse
  
  packets = rdpcap("modbus_capture.pcap")
  for pkt in packets:
      if pkt.haslayer(ModbusADURequest):
          adu = pkt[ModbusADURequest]
          print(f"Src: {pkt['IP'].src} -> Dst: {pkt['IP'].dst} "
                f"Unit: {adu.unitId} FuncCode: {adu.funcCode}")
  

• Habilitar registro Modbus do Zeek: Configure o Zeek com @load policy/protocols/modbus/known-masters-slaves para gerar entradas modbus.log contendo timestamp, IPs de origem/destino, código de função e respostas de exceção. Isso fornece registro passivo contínuo sem scripts personalizados.
• Validar integridade do frame: Verifique frames Modbus malformados onde o campo de comprimento MBAP não corresponde ao comprimento real do PDU, o Protocol Identifier não é 0x0000, ou o Unit Identifier está fora da faixa esperada para a rede monitorada.

Etapa 2: Estabelecer Padrões de Comunicação Normais como Linha de Base

Construa um perfil comportamental do tráfego Modbus legítimo para distinguir operações normais de anomalias:

• Catalogar a distribuição de códigos de função: Registre a frequência de cada código de função por par origem-destino durante o período de linha de base. Em ambientes SCADA típicos, as operações de leitura (FC 01-04) superam em muito as operações de escrita (FC 05, 06, 15, 16), muitas vezes em proporções superiores a 100:1. Um aumento súbito nos códigos de função de escrita é um forte indicador de manipulação do processo.

  Normal baseline example (72-hour period):
  HMI (10.1.1.10) -> PLC (10.1.1.50):
    FC 03 (Read Holding Registers):  432,180 packets  (97.2%)
    FC 04 (Read Input Registers):     10,540 packets  (2.4%)
    FC 06 (Write Single Register):     1,780 packets  (0.4%)
    FC 16 (Write Multiple Registers):      0 packets  (0.0%)
    FC 43 (Read Device ID):               0 packets  (0.0%)
  

…