O documento discute a detecção de problemas em redes industriais através de monitoramento contínuo. Os principais pontos abordados são: 1) o que deve ser monitorado em redes de automação, como processos, controladoras e tráfego de dados; 2) a preparação do ambiente de monitoramento usando o software Zabbix; e 3) os resultados do monitoramento de ataques realizados, como negação de serviço e tráfego Modbus não autorizado.

1. Detectando problemas em redes industriais
através de monitoramento contínuo
Rio de Janeiro, Novembro de 2014
Marcelo Branquinho & Jan Seidl

2. Marcelo Branquinho
marcelo.branquinho@tisafe.com
• CEO da TI Safe.
• Membro sênior da ISA e integrante
do comitê da norma ANSI/ISA-99.
• Pesquisador de técnologias de
segurança para proteção de
infraestruturas críticas.
Apresentação
Jan Seidl
jan.seidl@tisafe.com
• CTO da TI Safe.
• Especialista em análise de riscos
em sistemas de automação.
• Pesquisador na área de engenharia
de malware.

3. • O que deve ser monitorado em uma rede de
automação?
• Preparação do ambiente de monitoramento.
• Os ataques realizados.
• Resultados do monitoramento dos ataques.
• Conclusão
#class2014
Agenda

4. O que deve sseerr mmoonniittoorraaddoo eemm
uummaa rreeddee ddee aauuttoommaaççããoo??

5. O que monitorar em uma rede
• A “Saúde” de servidores críticos
• Erros de execução nos sistemas operacionais
• Processos
• Alta Disponibilidade
• Tráfego de dados em protocolos industriais
• Controladoras (CLPs)
• Traps SNMP
• Pacotes ICMP (Ping)
de automação?

6. A “Saúde” de Servidores críticos
• Servidores críticos precisam ter sua estabilidade e continuidade de operações
assegurados.
• Monitorar a saúde permite prevenir determinadas falhas, assim como algum
comprometimento malicioso, de acordo com determinados sintomas.
• As principais características monitoradas em um servidor crítico são:
• Espaço livre em disco.
• CPU e Memória.
• Tentativas de login sem sucesso.
• Taxa de entrada e saída de pacotes.

7. Erros de Execução em S.O.
• Útil na antecipação de falhas de hardware.
• A antecipação das falhas, por sua vez, evita que tenhamos que fazer uma parada
não programada para reposição de componentes
• Os principais erros de execução em sistemas operacionais a serem monitorados
são:
• Comprometimento/alocação de memória.
• Leitura/escrita em disco.
• Temperatura de CPU.
• Velocidade da ventoinha.

8. • O monitoramento da estabilidade dos processos pode contribuir em duas
situações:
• Avisar a equipe responsável o mais rápido possível em caso de falhas na
execução de processos críticos.
• Reiniciar o processo automaticamente, caso seja possível.
• Recomenda-se também o monitoramento de nomes e portas de processos
conhecidamente explorados como por exemplo:
• RDP
• HTTP/HTTPS
• TeamViewer
• Cmd.exe
• Windows PowerShell
Processos

9. Alta Disponibilidade
• Visa minimizar o downtime do recurso monitorado, antecipando possíveis falhas.
• O estado dos links de comunicação pode ser verificado a fim de ver se a rede da
planta de automação entrou em estado de contingência.
• O agente de monitoramento pode executar tarefas automatizadas, se necessário.

10. • Para monitorar tráfego de dados em protocolos industriais é aconselhável um
espelhamento de porta.
• No caso do Modbus, por exemplo, é possível criar um sniffer de rede, através do
qual se possa monitorar diversos parâmetros.
• Os principais parâmetros a serem monitorados são:
• Códigos de função não permitidos.
• Valores de tags.
• Origem dos comandos.
• Comandos enviados e recebidos.
Tráfego de dados em
protocolos industriais

11. • Monitoramento SNMP
Controladoras (CLPs)
• Monitora E/S de rede, pacotes descartados, erros de rede, etc.
• Possui maior confiabilidade e, de acordo com os erros, diagnostica algo errado
que possa estar acontecendo.
• Monitoramento ICMP (Ping)
• Alternativa caso SNMP não seja suportado pela controladora.
• Usado para verificar conectividade e tempo de resposta.
• Poucas informações, portanto menor precisão e menor confiabilidade.

12. PPrreeppaarraaççããoo ddoo aammbbiieennttee ddee
mmoonniittoorraammeennttoo..

13. O Ambiente de Testes
O Ambiente de testes montado no Laboratório TI Safe inclui:
• Um CLP modelo Wago 741-800
• Um Simulador de uma planta de gás natural (Tofino Scada Security Simulator)
• Uma Estação Windows 7 (físico) para o sistema de supervisão
• Uma Máquina virtual atuando como o servidor de monitoramento (Debian Linux 6 com Zabbix)
• Uma Máquina virtual atuando como servidor de sniffer de tráfego Modbus (Debian Linux 6 com
script em python + scapy)

14. O Ambiente de Monitoramento
• O servidor de monitoramento é uma máquina virtual
executando sistema operacional Debian Linux.
• Neste servidor foi baixada e instalada rodando a solução open
source de monitoramento Zabbix 2.0.6 utilizando o MySQL 5.1
como backend de dados.
Figura: O Sniffer de rede e sua estrutura

15. • Dependendo da carga que a máquina executa, os itens podem ser
configurados para serem verificados num intervalo definido.
• Os servidores com carga mais leve pode ter checagens mais curtas (a cada
15 ou 30 segundos).
• Servidores com carga maior podem ter um controle com intervalo maior
(1 minuto ou superior).
• A idéia é preservar o poder computacional da máquina e a largura de
banda.
Freqüência de Verificação

16. • Destinados a alertar a equipe de resposta.
• Melhor usado quando disparado a partir de um conjunto de detecções,
diminuindo a possibilidade de falso positivo.
• Podem gerar avisos sonoros e exibir sinais visuais em um painel, como um
servidor piscando por exemplo.
• Os alertas recomendados são via:
• SMS
• Jabber
• E-mail
Alertas

17. Os aattaaqquueess rreeaalliizzaaddooss..

18. A Máquina do Atacante
• Laptop marca HP, que será conectado diretamente ao switch da rede de automação
• Executando Kali Linux 1.0 a partir de um Live-CD.
Software /
Ferramenta
Descrição Ataque Autor
Hping3 Ferramenta de ICMP
flood
Negação de serviço
em camada 3
http://www.hping.org/
T50 Ferramenta de Flood Negação de serviço
em camada 3
https://github.com/merces/t50
Meterpreter Shell de acesso remoto Comprometimento
remoto, infecção por
malware
http://www.metasploit.com/
Arpspoof Ferramenta de ARP
poison/spoofing
ARP poison http://arpspoof.sourceforge.net
/
Pymodbus Biblioteca python para
Modbus
Tráfego Modbus não
autorizado
https://github.com/bashwork/p
ymodbus
Abaixo está a lista dos softwares utilizados nos ataques:

19. Ataques realizados
Ataque Vetor de ataque Ativos afetados
Intercepção de comunicações ARP poison PLC, Estação Supervisória
Negação de Serviço em PLC 0-day, flood em camada 3 PLC
Infecção por malware na
Estação Supervisória
Modbus malware, Meterpreter
shell backdoor
Estação Supervisória, Rede
Comprometimento de Estação
Supervisória
Meterpreter shell backdoor Estação Supervisória
Logon remoto não autorizado Habilitando o remote desktop
na máquina, acessando uma
máquina a partir de outra
máquina na rede
Estação Supervisória
Tráfego Modbus não
autorizado
O envio de comandos a partir da
máquina atacante
PLC

20. Resultado ddoo mmoonniittoorraammeennttoo
ddooss aattaaqquueess..

21. • $ nmap –sV 192.168.1.1
• Interceptação de comunicação
Resultado dos Ataques

22. • Negação de serviço
• Infecção por malware
Resultado dos Ataques

23. • Tráfego Modbus não autorizado
Resultado dos Ataques

24. CCoonncclluussããoo..

25. Conclusão
• A homogeneidade do comportamento cíclico de redes e servidores industriais permite-nos
estabelecer os parâmetros 'saudáveis' da rede.
• Aplicações de análise e monitoramento de rede e servidores são fundamentais para a
detecção de tráfegos de rede incomuns.
• Ao realizar monitoramento por comportamento consegue-se obter resultados mais
tangíveis do que o monitoramento por keywords conhecidas, as 'assinaturas'.
• O estabelecimento de linhas de base de tráfego por meio de análise de pacotes na
rede de sistemas de controle é necessário para a detecção de tráfego anômalo através
da análise das diferenças.
• Gatilhos (triggers) podem ser configurados para indicar parâmetros fora destas faixas
que podem significar um comprometimento dos ativos em questão.
• Baseados em triggers, alarmes (inclusive sonoros) podem ser configurados.
• Para ambientes de automação industrial e controle, com seus protocolos não-usuais,
há poucas ferramentas comerciais disponíveis para a compra, e o ideal é customizar
uma ferramenta de código aberto para sua própria necessidade de monitoramento.

26. marcelo.branquinho@tisafe.com / jan.seidl@tisafe.com