Detectando problemas em redes industriais

através de monitoramento contínuo

Rio de Janeiro, Novembro de 2014Marcelo Branquinho & Jan Seidl

Marcelo Branquinhomarcelo.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.

Jan Seidljan.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.

Apresentação

• 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

O que deve ser monitorado em O que deve ser monitorado em uma rede de automauma rede de automaçção?ão?

• 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)

O que monitorar em uma rede

de automação?

• 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.

A “Saúde” de Servidores críticos

• Ú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.

Erros de Execução em S.O.

• 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

• 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.

Alta Disponibilidade

• 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

• Monitoramento SNMP

• 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.

Controladoras (CLPs)

PreparaPreparaçção do ambiente de ão do ambiente de monitoramento.monitoramento.

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)

O Ambiente de Testes

• 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

O Ambiente de Monitoramento

• 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

• 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

Os ataques realizados.Os ataques realizados.

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

• 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.

Abaixo está a lista dos softwares utilizados nos ataques:

A Máquina do Atacante

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

Ataques realizados

Resultado do monitoramento Resultado do monitoramento dos ataques.dos ataques.

• $ nmap –sV 192.168.1.1

• Interceptação de comunicação

Resultado dos Ataques

• Negação de serviço

• Infecção por malware

Resultado dos Ataques

• Tráfego Modbus não autorizado

Resultado dos Ataques

Conclusão.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.

Conclusão

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