UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO
CENTRO TECNOLÓGICO
DEPARTAMENTO DE INFORMÁTICA
CURSO DE PÓS-GRADUAÇÃO EM REDES DE COMPUTADORES
HEBER ALMEIDA BARBOSA
DETECÇÃO DE INTRUSÃO EM
REDES DE AUTOMAÇÃO
INDUSTRIAL
VITÓRIA
2006
HEBER ALMEIDA BARBOSA
DETECÇÃO DE INTRUSÃO EM
REDES DE AUTOMAÇÃO
INDUSTRIAL
Projeto Final de curso apresentado ao
Programa de Pós-Graduação em Informática
da Universidade Federal do Espírito Santo,
como requisito parcial para obtenção do
Grau de Especialista em Redes de
Computadores.
Orientador: Prof. Dr. Sérgio Antônio
Andrade de Freitas.
VITÓRIA
2006
HEBER ALMEIDA BARBOSA
DETECÇÃO DE INTRUSÃO EM
REDES DE AUTOMAÇÃO
INDUSTRIAL
COMISSÃO EXAMINADORA
Prof. Dr. Sérgio Antônio Andrade de Freitas
(Orientador)
Departamento de Informática – UFES
Prof. Dr. José Gonçalves Pereira Filho
Departamento de Informática - UFES
Prof. Rostan Piccoli
Departamento de Informática - UFES
Vitória, 02 de junho de 2006
SUMÁRIO
LISTA DE FIGURAS
LISTA DE TABELAS
RESUMO
ABSTRACT
1 INTRODUÇÃO
1
1.1 CONTEXTO
1
1.2 MOTIVAÇÃO
1
1.3 OBJETIVO
2
1.4 METODOLOGIA
2
1.5 ESTRUTURA DA MONOGRAFIA
3
2 SEGURANÇA DA INFORMAÇÃO EM AMBIENTES DE AUTOMAÇÃO INDUSTRIAL
4
2.1 INTRODUÇÃO
4
2.2 SISTEMAS DE AUTOMAÇÃO INDUSTRIAL
4
2.2.1 HISTÓRICO DA AUTOMAÇÃO INDUSTRIAL
5
2.2.2 CONTROLADOR LÓGICO PROGRAMÁVEL
7
2.2.3 SISTEMAS SCADA
9
2.2.4 SISTEMA DIGITAL DE CONTROLE DISTRIBUÍDO (SDCD)
11
2.2.5 UMA NOVA CONCEPÇÃO
13
2.2.6 REDES DE COMUNICAÇÃO
14
2.3 SEGURANÇA DA INFORMAÇÃO EM AMBIENTES INDUSTRIAIS
2.3.1 CONCEITOS DE SEGURANÇA DA INFORMAÇÃO
17
18
2.3.1.1 VULNERABILIDADES
18
2.3.1.2 INVASÃO OU INTRUSÃO
19
2.3.1.3 INCIDENTES DE SEGURANÇA
20
2.3.1.4 VÍRUS E WORMS
21
2.3.1.5 CAVALO DE TRÓIA
21
2.3.1.6 “BACKDOOR”
22
2.3.1.7 NEGAÇÃO DE SERVIÇO
22
2.3.1.8 SPOOFING
23
2.3.2 NOVO CONTEXTO NA INDÚSTRIA
23
2.3.3 AMEAÇAS AO AMBIENTE DE AUTOMAÇÃO INDUSTRIAL
27
2.3.4 CONTRAMEDIDAS
29
2.4 CONSIDERAÇÕES FINAIS
30
3 - SISTEMAS DE DETECÇÃO DE INVASÃO
31
3.1 INTRODUÇÃO
31
3.2 DEFINIÇÃO DE SISTEMA DE DETECÇÃO DE INVASÃO
31
3.3 SISTEMA DE DETECÇÃO DE INVASÃO BASEADO EM REDE
35
3.4 “SNORT”
38
3.4.1 FUNCIONAMENTO DO “SNORT”
39
3.4.1.1 MODO FAREJADOR
40
3.4.1.2 MODO DE REGISTRO DE PACOTES
41
3.4.1.3 MODO DE DETECÇÃO DE INTRUSÃO
42
3.4.1.4 MODO EM LINHA
46
3.5 O USO DE UM SISTEMA DE DETECÇÃO DE INVASÃO NO AMBIENTE
INDUSTRIAL
4 MODBUS/TCP
47
52
4.1 INTRODUÇÃO
52
4.2 PROTOCOLO DE APLICAÇÃO MODBUS
53
4.2.1 DESCRIÇÃO
53
4.2.2 BASE DE DADOS MODBUS
57
4.2.3 DESCRIÇÃO DOS CÓDIGOS DE FUNÇÃO DO MODBUS
57
4.2.4 RESPOSTA DE EXCEÇÃO MODBUS
59
4.3 MODBUS SERIAL (RTU)
61
4.4 MODBUS/TCP
63
4.4.1 MODELO CLIENTE X SERVIDOR
63
4.4.2 MODELO DA ARQUITETURA MODBUS/TCP
65
5 SNORT APLICADO A UMA REDE MODBUS/TCP
77
5.1 INTRODUÇÃO
77
5.2 AMBIENTE DE SIMULAÇÃO
78
5.2.1 INSTALAÇÃO E CONFIGURAÇÃO DO SNORT
80
5.2.2 INSTALAÇÃO E CONFIGURAÇÃO DOS SIMULADORES
89
5.3 TESTE DO AMBIENTE
91
5.4 ANÁLISE DOS TESTES
99
6 CONCLUSÃO
100
REFERÊNCIAS BIBLIOGRÁFICAS
102
LISTA DE FIGURAS
FIGURA 01 – MODELO DE ARQUITETURA UTILIZANDO UM SCADA.
09
FIGURA 02 – EXEMPLO DE UTILIZAÇÃO DE DRIVERS DE COMUNICAÇÃO.
10
FIGURA 03 – ARQUITETURA DOS COMPONENTES DE UM SDCD.
13
FIGURA 04 – SISTEMA DE CONTROLE UTILIZANDO O MODELO DE
REFERÊNCIA GERAL [DRAFT].
15
FIGURA 05 – COMPARAÇÃO DAS PRIORIDADES.
26
FIGURA 06 – ARQUITETURA REDUNDANTE.
27
FIGURA 07 – IDS BASEADO EM REDE.
32
FIGURA 08 – IDS BASEADO EM “HOST”.
33
FIGURA 09 – IDS DISTRIBUÍDO.
34
FIGURA 10 - RELACIONAMENTO ENTRE OS COMPONENTES CIDF.
37
FIGURA 11 – ARQUITETURA DO “SNORT”.
40
FIGURA 12 – CABEÇALHO DA REGRA.
43
FIGURA 13 – ARQUITETURA DE REDE INTEGRADA.
48
FIGURA 14 - IDSR NUM SEGMENTO DO NÍVEL DE CONTROLE E SUPERVISÃO.
50
FIGURA 15– IMPLEMENTAÇÃO DO PROTOCOLO MODBUS.
52
FIGURA 16 – PACOTE MODBUS GENÉRICO.
54
FIGURA 17 – MODELO DE TRANSAÇÃO MODBUS ENTRE CLIENTE E
SERVIDOR.
55
FIGURA 18 – MODELO DE TRANSAÇÃO MODBUS ENTRE CLIENTE E SERVIDOR
COM CÓDIGO DE EXCEÇÃO RETORNADO.
55
FIGURA 19 – MODELO EM CAMADAS.
61
FIGURA 20 – MODO DE COMUNICAÇÃO UNICAST.
62
FIGURA 21 – MODO DE COMUNICAÇÃO BROADCAST.
62
FIGURA 22 – ENDEREÇAMENTO MODBUS RTU.
62
FIGURA 23 – SERVIÇO DE MENSAGEM MODBUS.
63
FIGURA 24 – EXEMPLO DE APLICAÇÕES MODBUS.
64
FIGURA 25 – PACOTE MODBUS/TCP.
64
FIGURA 26 – MODELO DE ARQUITETURA MODBUS.
65
FIGURA 27 - DIAGRAMA DE ATIVIDADE DO GERENCIAMENTO DE
CONEXÃO TCP.
67
FIGURA 28 – ESTABELECIMENTO DE CONEXÃO MODBUS TCP.
67
FIGURA 29 - TROCA DE DADOS MODBUS.
68
FIGURA 30 - DIAGRAMA DE ATIVIDADES CLIENTE MODBUS.
69
FIGURA 31 - DIAGRAMA DE ATIVIDADES DE PREPARO DE UMA REQUISIÇÃO.
71
FIGURA 32 - DIAGRAMA DE ATIVIDADES DO PROCESSO DE CONFIRMAÇÃO.
73
FIGURA 33 - DIAGRAMA DE TRATAMENTO DE REQUISIÇÃO.
75
FIGURA 34 – MODELO DE COMUNICAÇÃO CLIENTE X SERVIDOR MODBUS.
78
FIGURA 35 – AMBIENTE DE SIMULAÇÃO.
79
FIGURA 36 – SIMULADOR CLIENTE MODBUS.
89
FIGURA 37 – POOLING DE DADOS.
90
FIGURA 38 – SIMULAÇÃO DE ATAQUE.
96
FIGURA 39 – ESCRITA DE DADOS NO SERVIDOR.
98
LISTA DE TABELAS
TABELA 01 – EXEMPLOS DE POSSÍVEIS INVASORES.
19
TABELA 02 – MODELO DE DADOS.
57
TABELA 03 – CÓDIGOS E SUB-CÓDIGOS DE FUNÇÃO.
58
TABELA 04 – CÓDIGO DE EXCEÇÃO.
60
TABELA 05 – CAMPOS DO CABEÇALHO MBAP.
72
TABELA 06 – DESCRIÇÃO DOS DADOS MODBUS/TCP.
93
TABELA 07 – DESCRIÇÃO DOS DADOS MODBUS/TCP.
94
RESUMO
O ambiente da automação industrial tem presenciado uma grande revolução tecnológica
nos últimos dez anos. De um ambiente totalmente isolado, onde imperava os sistemas
proprietários, redes determinísticas e tecnologias dedicadas, a um ambiente integrado e
compartilhado com os demais sistemas de uma corporação. Se há dez anos atrás TI e
Automação eram um mundo à parte, hoje a integração destes dois mundos é uma
necessidade. Este trabalho tem o objetivo de levantar as principais questões de
segurança que surgem com este novo cenário e suas implicações para o ambiente
industrial. E, como uma das medidas a serem tomadas para eliminar ou mitigar as
ameaças a este ambiente, demonstrar a utilização de Sistemas de Detecção de Intrusão
em redes de automação industrial. Esta demonstração é feita utilizando um Sistema de
Detecção de Intrusão em uma rede de automação com o protocolo Modbus/TCP.
ABSTRACT
In the last tem years, the industrial automation environment has witnessed a big
technological revolution. From an environment totally isolated, where the owners
systems, deterministic networks and dedicated technology were the majority, to an
integrated environment and shared with the other corporation systems. If in ten years
ago, IT and Automation were two different worlds, today, the integration of theses two
worlds it’s a necessity. The object of this work is standing the main security questions
that emerge with this new scenario, its implications to the industrial environment and
demonstrate the profits of using an Intrusion Detection System in automation networks,
an important way to eliminate and mitigate the treats in this environment. A
demonstration of that is done using an Intrusion Detection System in an automation
network with the Modbus/TCP protocol.
1
1 Introdução
1.1 Contexto
Há cerca de dez anos atrás o ambiente da automação industrial era um ambiente
totalmente isolado do ambiente corporativo de uma empresa. Hoje, porém, estes dois
ambientes precisam estar integrados e compartilhando informações por diversas razões.
Uma destas razões é a necessidade de levar os dados de processo a um nível hierárquico
mais elevado, alimentando sistemas de otimização de processo, planejamento,
manutenção e gerenciamento da produção. Esta integração traz ao ambiente de
automação industrial uma série de questões de segurança que antes eram particulares ao
ambiente corporativo da empresa. Questões como a possibilidade de contaminação dos
sistemas de controle e supervisão por vírus de computador, exploração de falhas de
programação, tráfego de informações em texto pleno, ataques de negação de serviço,
acesso não autorizado e outros tipos de vulnerabilidades e ameaças passam a fazer parte
do ambiente industrial. Outra importante questão, é que a maioria dos protocolos de
automação industrial não foi projetada para atender aos requisitos de segurança das
redes corporativas.
1.2 Motivação
A grande motivação para este trabalho é a implantação de um Sistema de Detecção de
Intrusão ou IDS [10] (do inglês, “Intrusion Detection System”) com capacidade de
analisar e monitorar o tráfego e detectar ataques em uma rede de automação industrial,
de forma a eliminar ou mitigar as ameaças a este ambiente.
Uma das dificuldades atuais para implementação desta tecnologia em redes industriais é
a carência de ferramentas de detecção desenvolvidas para protocolos específicos deste
ambiente, como o Foudation FieldBus [32], Profibus [24], Modbus [18] e OPC [17].
É interessante observar que a maioria dos protocolos das redes de automação industrial
não foi projetada contemplando os requisitos de segurança da informação. O IDS então
seria uma importante ferramenta para compensar estas deficiências.
2
1.3 Objetivo
Este trabalho tem os objetivos de levantar as principais questões de segurança que
surgem com o novo cenário tecnológico da automação industrial e demonstrar a
utilização de IDS’s nos segmentos de rede de automação industrial nível dois, entre os
dispositivos de controle e as IHM’s (Interface Homem Máquina), assinalando as
vantagens de sua utilização como uma das medidas a serem tomadas para eliminar ou
mitigar as ameaças e vulnerabilidades deste ambiente. Esta tecnologia provê segurança
através da monitoração do acesso aos sistemas, registro de informações para análise de
vulnerabilidades e monitoração do tráfego da rede e detecção de ataques.
1.4 Metodologia
Para o desenvolvimento deste trabalho foi realizada revisão de bibliografias atualizadas
dos anos de 2004 a 2006 abrangendo os seguintes temas: redes industriais, segurança de
dados em ambientes industriais, protocolos de automação industrial, sistemas de
detecção de intrusão e as respectivas normas técnicas das áreas de segurança da
informação e segurança industrial.
Visando demonstrar o uso de IDS em redes de automação industrial, foi definida uma
arquitetura de rede para simulação de um ambiente industrial. A simulação foi
necessária por dois motivos: dificuldades em realizar testes em um ambiente de
automação industrial que esteja em produção e a dificuldade em alocar recursos
necessários para os testes, como CLP [8] (Controlador Lógico Programável) e sistemas
SCADA [8] (do inglês “Supervisory Control and Data Aquisition”).
Na execução da simulação foi selecionado o protocolo Modbus/TCP, por ser um
protocolo de padrão aberto e utilizado na comunicação de dispositivos cliente/servidor
em redes de automação industrial nas indústrias de óleo e gás, siderúrgicas e de celulose
do estado do Espírito Santo. E como IDS foi selecionado o Snort [5], por ser um IDS de
rede de “código fonte aberto” e por permitir o desenvolvimento de regras específicas ao
protocolo Modbus/TCP. Como descrito acima, este é um importante requisito, pois a
maioria dos atuais IDS’s não tem regras para protocolos como o Modbus/TCP.
3
No ambiente implantado, a comunicação Modbus TCP se estabelece entre um sistema
SCADA e o aplicativo servidor, um Controlador Lógico Programável. O IDS é
responsável por capturar os pacotes do segmento de rede e os comparar a partir de um
padrão, na busca por assinaturas que indiquem um ataque. Estas assinaturas são
definidas em conjuntos de regras, que além das informações de assinatura de um ataque,
contêm informações que permitem definir a metodologia do ataque em termos de
identificação do invasor.
1.5 Estrutura da monografia
Esta monografia está estruturada da seguinte forma:
No capítulo 2, é apresentado um histórico da evolução tecnológica dos sistemas de
controle de automação industrial, bem como uma definição dos principais conceitos
desta área. Além disso, são apresentados: conceitos de segurança da informação que se
aplicam ao ambiente industrial, o novo contexto tecnológico das indústrias, as ameaças
advindas com este novo contexto e as possíveis contramedidas para combater estas
ameaças.
No capítulo 3, é definido um sistema de detecção de invasão, com um foco maior no
sistema de detecção de invasão de rede e é feita a apresentação do Snort, IDS de rede
utilizado nos testes.
No capítulo 4, é apresentado o protocolo Modbus, sendo descrito o protocolo de
aplicação, seu modelo de dados, códigos de função e códigos de respostas de exceção. É
feita uma breve apresentação do Modbus Serial e uma apresentação mais detalhada do
Modbus/TCP, descrevendo o modelo cliente servidor e o modelo da arquitetura do
protocolo.
O capítulo 5 é destinado a descrever o ambiente de simulação e a execução dos testes
realizados. São apresentadas as regras desenvolvidas no Snort específicas para o
Modbus e a análise dos resultados dos testes realizados.
Finalmente, no capítulo 6, são apresentadas as conclusões sobre o trabalho realizado e
as possibilidades de desenvolvimento de futuros trabalhos.
4
2 Segurança da Informação em ambientes de
Automação Industrial
2.1 Introdução
Este capítulo apresenta os conceitos relativos à segurança da informação aplicados ao
ambiente de automação industrial.
Inicialmente é feito uma descrição dos sistemas de automação industrial e o histórico de
evolução tecnológica destes durante os anos. Entender este histórico apresentado é
importante para um melhor entendimento da importância do tema de segurança em
processos industriais. Após, é abordado o tema de segurança especificamente aplicado
ao ambiente industrial. São apresentados: os principais conceitos de segurança da
informação, o novo contexto tecnológico da indústria, as novas ameaças e
vulnerabilidades deste ambiente e as contra medidas possíveis para mitigar ou eliminar
estas ameaças e vulnerabilidades.
2.2 Sistemas de Automação Industrial
Especificamente, os sistemas de controle industriais são responsáveis pelo controle do
processo industrial e incluem todos os sistemas que podem afetar ou influenciar a
segurança do processo (“safe”), o controle e a segurança dos dados (“security”) e a
operação de um processo industrial. Estes sistemas incluem (não se limitando a estes):
•
Sistemas de controle de processo, incluindo SDCD's, CLP's, UTR's,
Dispositivos Inteligentes Eletrônicos, SCADA, sensores e controles
eletrônicos de rede e sistemas de diagnóstico e monitoração.
•
Sistemas de informações associadas assim como controle avançado e multivariáveis, otimizadores on-line, equipamentos de monitoração dedicados,
interfaces gráficas, historiadores de processo e sistemas de gerenciamento
das informações da planta.
5
Assim como o mundo da informática, o mundo da automação industrial tem passado por
uma grande e acelerada revolução tecnológica. Esta revolução acontece por vários
motivos: necessidade de otimizar os processos industriais, redução custos de
investimentos, aumento da segurança operacional e agilização dos processos de tomada
de decisão. O escopo das atividades da automação também mudou consideravelmente
nos últimos. “A automação rompeu os grilhões do chão de fábrica e buscou fronteiras
mais amplas, se abrangendo a automação do negócio ao invés da simples automação dos
processos equipamentos” [6]. E esta mudança, alterando paradigmas e conceitos, traz
uma série de novas questões aos responsáveis por esta área nas indústrias.
Os sistemas de automação industrial são um dos principais pontos críticos de um
processo de produção e manufatura de uma corporação. Por isso, o tema “Segurança da
Informação”, que também tem sido chamado de “Cyber Security”, deve ser tratado
como prioridade pelos responsáveis por estes processos. E para se entender o porquê da
inclusão e da importância deste tema nestes ambientes, é importante entender, de uma
forma genérica, o contexto desta área, dando uma rápida olhada na história e evolução
dos sistemas de automação industrial através dos tempos.
2.2.1 Histórico da automação industrial
Até o final da década de 50, imperava nas indústrias os sistemas de medição e controle
pneumáticos, que ofereciam pouca precisão e confiabilidade. O sinal padrão adotado no
Brasil para estas aplicações era a variação da pressão de ar na faixa de 0,2 a 1,0
Kgf/cm2 ou de 0,2 a 1,0 bar. Este tipo de sinal continua sendo utilizado na atuação de
válvulas de controle e ainda é utilizado em algumas malhas de controle em processos
industriais antigos que não foram automatizados.
A partir da década de 70, impulsionados pela crescente competitividade na indústria,
surgem os primeiros transmissores eletrônicos. Os primeiros equipamentos eletrônicos
medidores de campo, se interligavam aos controladores através de sinais analógicos de
tensão ou corrente (0-10V e 0-20mA). A parte de lógica discreta (liga/desliga) e
intertravamento, era implementada pela combinação de relés e chaves eletromecânicas.
6
Na década de 80 o padrão de comunicação analógica (4 a 20 mA) se estabelece como
principal forma de conectar os equipamentos de campo, como os transmissores,
válvulas de controle e motores, aos equipamentos de controle do processo. Estes
equipamentos de controle geralmente eram instalados em enormes painéis em salas
conhecidas como Centro de Controle, onde os operadores tinham acesso de leitura e
ajuste nos controladores. Os registros históricos das variáveis de processo em função do
tempo eram feitos por registradores, pneumáticos ou eletrônicos, em cartas graduadas
com escalas diversificadas. As funções de integração ou totalização dos dados de
processo, anúncio de alarmes, indicação e outros, eram realizadas por equipamentos
dedicados a cada função específica. O operador, em muitos casos, ficava à mercê de
uma centena de pontos de leitura.
Ainda na década de 80, surge o protocolo digital de comunicação HART [27], que se
utilizava do meio de transmissão analógico utilizado (4 a 20 mA) para a
disponibilização de informações entre um equipamento medidor micro processado e o
sistema de controle da planta. O protocolo HART introduziu no ambiente de automação
a possibilidade de visualização das informações do instrumento, como dados de
configuração e calibração, e do processo medido de forma “on-line”, disponibilizando
estas informações para os sistemas de gerenciamento de manutenção e outros tipos de
interfaces. A comunicação pode ser feita por meio de computadores de mão,
microcomputadores com o programa específico instalado ou por sistemas digitais de
controle que suportem o protocolo. A partir do HART, inicia-se o movimento dos
protocolos digitais de comunicação, de onde surgiram protocolos tais como: Foudation
FieldBus, Profibus, Modbus e OPC.
O primeiro Controlador Lógico Programável (CLP), equipamento de controle micro
processado, surgiu em 1968, devido à sofisticação dos processos industriais, que
requeriam sistemas mais rápidos e confiáveis. O CLP foi originalmente concebido para
substituir os incontáveis relés de circuitos lógicos de controle discreto, porém, hoje é
utilizado para praticamente todos os tipos de controle, como será abordado mais adiante
neste capítulo.
A tecnologia da informação começa a entrar neste ambiente industrial na década de 80,
com o surgimento dos Sistemas Digitais de Controle Distribuídos (SDCD's). “Através
7
do uso de cartões de Entrada e Saída (E/S) dedicados, a automação experimentou uma
evolução jamais vista” [26]. Surgem também os primeiros sistemas supervisórios, que
possibilitavam ao operador o controle em um único console, de todas as variáveis de
processo da planta industrial. Estes sistemas tinham o propósito de substituir os antigos
equipamentos de painel, como os controladores, anunciadores de alarmes, registradores
e muitos outros, e centralizá-los em uma única interface, que possibilitasse o acesso a
todas as informações do processo, de maneira ágil, rápida e efetiva.
No princípio, os sistemas operacionais utilizados pelos sistemas de automação industrial
eram sistemas robustos como o RSX-11, QNX e VMS, que requeriam um alto nível de
conhecimento técnico. Em todos os casos a interoperabilidade de sistemas era algo
inimaginável. Atualmente, estes sistemas operacionais estão dando lugar aos sistemas
operacionais de mercado, como o Windows, que está sendo utilizado pela maioria de
fornecedores de sistema SCADA.
2.2.2 Controlador Lógico Programável
O Controlador Lógico Programável (CLP) surgiu, basicamente, para substituir os relés
eletromecânicos utilizados nos controles discretos, ou lógicos. Sua concepção surgiu a
partir da necessidade de um sistema mais confiável (em termos operacionais), mais
flexível (em termos de programação) e menor que os relés então utilizados. O primeiro
CLP foi desenvolvido como o nome de “MOdular DIgital CONtroller”, donde derivou
o nome MODICON. Sua primeira aplicação foi na GM, em uma linha de fabricação de
automóveis.
Atualmente, o CLP assumiu várias funções além das funções para as quais ele fora
projetado. Funções como o controle de variáveis analógicas, tráfego de informações do
“chão de fábrica” às linhas de comunicação de alta velocidade, disponibilizando os
dados de produção para outras unidades de produção, geração de relatórios e preparação
de dados para Interfaces Homem Máquina (IHM).
O hardware de um CLP pode ser dividido em dois grupos: os do tipo caixa única, que
contém em um único invólucro a fonte de alimentação, a CPU e os cartões de entrada e
8
saída; e os modulares, onde os módulos de CPU, módulos de entrada e saída, módulos
de comunicação e fonte de alimentação são montados em um rack.
O CLP tem vários tipos de linguagens de programação próprias e bem diferentes das
tradicionalmente utilizadas no meio da informática. Atualmente, as linguagens mais
utilizadas são o “Ladder” (Histograma de Contatos), primeira linguagem desenvolvida
e a mais popular, o diagrama de blocos funcionais, a lista de instruções lógicas, a
linguagem estruturada Grafcet e suas derivadas.
A arquitetura de um CLP consiste na CPU (que em muitos casos é redundante), nas
interfaces de entradas e saídas, e na memória.
O CLP, apesar de permitir a implementação de quase todo tipo de função, ainda é
basicamente utilizado para o controle de processo. As funções de interface com os
operadores, aquisição de dados, geração de históricos e relatórios, atualmente ainda fica
com os sistemas supervisórios, ou sistemas SCADA, instalados em microcomputadores.
Existem vários tipos de comunicação com os equipamentos de “chão de fábrica”
(instrumentação, válvulas de controles, motores elétricos, conversores de freqüência e
outros), sendo as principais, a comunicação analógica (4 a 20mA, 1 a 5 Vcc), a
comunicação discreta (ponto a ponto) e a comunicação via rede de comunicação
(FieldBus H1, Profibus-PA e DeviceNet). Para a interface com outros sistemas micro
processados, como outros CLP’s, SDCD’s, microcomputadores de interface-homemmáquina (sistemas supervisórios) e instrumentos micro processados, existem também
vários protocolos disponíveis para os meios de comunicação serial (RS-232/485),
ethernet, wireless e vários outros. A maioria dos fabricantes apresenta pelo menos uma
opção de protocolo proprietário, que permite a comunicação com CLP’s do mesmo
fabricante. Para a comunicação com CLP’s de outros fabricantes, é necessária a
utilização de drivers de comunicação, ou “gateways”, que fazem a tradução do
protocolo proprietário para outro protocolo proprietário de outro fabricante, ou para um
protocolo de padrão aberto, como o Modbus. Apesar das várias iniciativas de
desenvolvimento de padrões de comunicação, este é ainda um grande problema em
ambientes industriais, se tornando um campo de batalha entre os fabricantes.
Existem algumas aplicações onde o CLP está sendo substituído por um
microcomputador usando as mesmas linguagens de programação. Esta é uma questão
9
que gera várias discussões entre os engenheiros e técnicos da área, devido à questão da
confiabilidade tanto do “software” como do “hardware”.
2.2.3 Sistemas SCADA
Os sistemas SCADA (“Supervisory Control and Data Aquisition”), que em algumas
aplicações são referidos como sistemas supervisórios, são responsáveis por coletar os
dados de processo disponibilizados pelos equipamentos de controle (CLP's, remotas
industriais e outros) e os apresentar em tempo real, através de uma interface (gráfica)
homem máquina, aos operadores. Como demonstrado na figura 01, estes sistemas são
implantados, na maioria das aplicações, em conjunto com os CLP's, constituindo o
sistema de automação da planta.
Figura 01 – Modelo de arquitetura utilizando um SCADA.
As principais funções destes sistemas são: representar de forma gráfica a planta
industrial, exibir os status das variáveis de processo dinamicamente, prover meio para
operação de equipamentos, gerenciar os alarmes, registrar os dados de tendência da
variável, armazenar valores históricos, gerar relatórios, permitir a construção de
estratégias de controle, gerar “logs” de eventos e outros.
Um sistema SCADA se comunica com um CLP através de uma interface de
comunicação convencionada, que estabelece a forma como os dados são ordenados na
memória do CLP. Estas interfaces, que também são conhecidas como drivers de
10
comunicação, devem ser capazes de ler e escrever na memória de um CLP, executando
o protocolo particular daquele equipamento. Num nível hierárquico mais elevado, ou
para se comunicar com outros sistemas SCADA no mesmo nível operacional, também
são utilizados os drivers de comunicação. Na figura 02 é demonstrado um exemplo de
aplicação de comunicação, onde o sistema SCADA iFix, da Intelution, se comunica
com o CLP da Modicon através de uma interface Modbus MBE, e com a aplicação
PIMS através das interfaces do padrão OPC (“OLE Process for Control”).
Figura 02 – Exemplo de utilização de drivers de comunicação.
A aplicação SCADA deve ser capaz de enviar mensagens de leitura e escrita para o
CLP, que deve ser capaz de receber as mensagens, processá-las, atualizar as saídas e, se
necessário, retornar o dado requerido. Por exemplo, se o operador executa um comando
de desligamento de um motor, via aplicação SCADA, este comando será traduzido
numa mensagem de escrita que será enviada ao CLP. Este recebe a mensagem com um
bit com valor 1 e o escreve na memória. O “scan” do programa atualiza as entradas,
realiza o processamento lógico e um comando de saída é enviado ao elemento de
controle do motor para desligá-lo.
11
Os comandos que um sistema SCADA deve prover são os comandos de leitura e escrita
de palavra (variáveis analógicas), leitura e escrita de blocos de palavras, leitura e escrita
de variável discreta e escrita de variável digital.
Atualmente, a grande maioria dos sistemas SCADA é desenvolvida para rodar em
plataformas com sistema operacional Windows. No início, estes sistemas eram
utilizados pelos operadores apenas para funções de monitoração de processos, daí a
denominação de supervisório. Porém, após uma evolução tecnológica, estes sistemas
incorporaram as funções de controle do processo, função que eram concentradas apenas
nos SDCD's.
2.2.4 Sistema Digital de Controle Distribuído (SDCD)
O Sistema Digital de Controle Distribuído (SDCD ou DCS, do inglês “Distributed
Control System”) surgiu no final da década de 70, como resultado de um estudo sobre
as rotinas de uso das salas de controle centralizado e chamava-se TDC-2000. Podemos
definir um SDCD como “um sistema de controle industrial micro processado, criado
inicialmente para efetuar especificamente o controle das variáveis analógicas, e foi
sendo expandido em suas aplicações até abranger praticamente todas as aplicações de
controle usuais, incluindo-se aí as variáveis discretas, o controle de bateladas, controle
estatístico de processo, geração de relatórios etc” [8].
O SDCD, do ponto de vista do controle, acumula várias funções, fazendo tudo que os
computadores tradicionais faziam:
•
Aquisição de dados;
•
Controle estatístico de processo;
•
Troca de receitas em processos para produção em bateladas;
•
Otimização de dados;
•
Interface com outros sistemas;
•
Dispor telas que simulam um painel de operação e telas de representação do
processo;
12
•
Registro histórico e de tendência de variáveis de processo;
•
Geração de relatórios;
•
Funções de alarme (sonorização, visualização e reconhecimento).
O SDCD é composto de quatro componentes: a interface com o processo (aquisição de
dados), o controlador, a interface homem máquina e a via de comunicação de dados.
•
A interface com o processo é responsável por coletar os dados de produção,
através de vários meios de comunicação e disponibilizá-los ao controlador.
Outras funções como isolamento elétrico dos sinais de campo, conversão de
protocolos e outros mais, são acumuladas por este componente.
•
O controlador (ou estações de controle), é responsável pela modelagem
matemática, processamento dos algoritmos de controle, otimização, cálculos e
controles estatísticos e outros. Ele recebe os dados de processo, realiza o
processamento e gera um sinal que é enviado de volta ao processo para realizar o
controle da malha.
•
A via de comunicação de dados, disponibiliza os dados do controlador para a
interface homem máquina através de um meio de comunicação, que geralmente
é proprietário. Este componente é também responsável por interligar o SDCD
aos sistemas de nível hierárquicos mais elevados, como os sistemas gerenciais
da empresa.
•
A interface homem máquina (estações de operação), é responsável por
disponibilizar para o operador, a partir dos dados do controlador, uma
visualização dos alarmes gerados, registros de tendência e históricos, telas de
processo, geração de relatórios e outros.
13
Figura 03 – Arquitetura dos componentes de um SDCD.
Os primeiros SDCD’s eram sistemas proprietários, não sendo possível uma
intercambialidade ou interoperabilidade com outros equipamentos de outros fabricantes.
O primeiro passo na quebra desta estrutura, foi a utilização de máquinas da linha
MicroVax da Digital nas estações de operação. A seguir, devido a fatores econômicos,
as máquinas VAX com VMX, deram lugar a micros PC’s compatíveis utilizando
sistemas operacionais como o UNIX. Atualmente, a maioria dos SDCD’s são projetados
utilizando o sistema operacional Microsoft Windows na plataforma Intel.
2.2.5 Uma nova concepção
Apesar de terem sido concebidos com propósitos distintos, com o avanço tecnológico,
CLP's e SDCD's estão evoluindo e convergindo em termos de funcionalidade a cada dia.
Os CLP’s ficaram mais versáteis e incorporaram as interfaces gráficas do operador, e os
SDCD’s ganharam em flexibilidade e se tornaram mais abertos, vindo a poder utilizar
14
outros padrões de comunicação, além de terem baixado seu custo significativamente.
Porém, é importante ressaltar que ainda existe uma série de funcionalidades que
distingue um sistema do outro. Estas funcionalidades estão desde o objetivo principal
para os quais eles foram criados, como diferenças de tipo de processamento da CPU,
tempo de varredura, desempenho, bibliotecas de funções, robustez e outros.
Ainda com a evolução da tecnologia digital e informática, vários sistemas estão
incorporando as várias características que compreendem funções de SDCD, de CLP, de
SCADA e outros [8]. Estes sistemas são conhecidos como sistemas híbridos, dedicados
às aplicações com mais de 1000 pontos analógicos, limite aceito para aplicação SCADA
+ CLP.
2.2.6 Redes de comunicação
O advento das redes de comunicação no ambiente industrial permitiu uma grande
interação funcional entre os vários dispositivos que compõem este ambiente,
aumentando
a
produtividade
e
o
surgimento
de
novas
oportunidades
de
desenvolvimento de novas funcionalidades. Com este novo cenário, houve um
considerável aumento na quantidade e qualidade das informações dos equipamentos de
campo e do próprio processo, disponibilizadas para um melhor gerenciamento da
manutenção, produção, inspeção e outros. Além do fato de que, para se realizar uma
programação remota, não é mais necessário o acesso físico ao dispositivo de campo.
Outra grande vantagem, foi a melhora da eficiência e rapidez da aquisição de dados.
A ISA propõe um modelo de referência geral, que é baseado no “Purdue Reference
Model” (PRM) do “Computer Integrated Manufactoring” e no Modelo Funcional
Hierárquico da ANSI/ISA-95.00.00.01-2000, que descreve as funções e atividades em
seis níveis, do nível processo (nível 0) ao nível corporativo (nível 5).
15
Figura 04 – Sistema de controle utilizando o Modelo de referência geral [DRAFT].
Os seis níveis de referência do modelo, como demonstrado na figura 04, são descritos a
seguir:
a. Nível 5 – Corporativo.
Inclui os sistemas corporativos da empresa, como sistemas financeiros, sistemas
de correio eletrônico, intranet e outros.
b. Nível 4 – Administração (Planejamento de negócios e logística).
Este nível inclui sistemas de planejamento da produção, gerenciamento
operacional, gerenciamento de manutenção e inspeção, sistemas MES
(“Manufactoring Execution System”) e outros.
c. Nível 3 – Operações de manufatura e controle.
16
Este nível inclui sistemas de planejamento detalhado de produção, geração de
dados históricos (PIMS) com longo período de armazenamento, análise off-line
dos dados para funções de suporte de engenharia, otimização de custos para
áreas de produção específicas, consolidação de relatórios de produção e outros.
d. Nível 2 – Operação, controle e supervisão.
Neste nível são realizadas as funções de operação da planta de produção. Os
sistemas deste nível são responsáveis por prover uma interface homem-máquina
para o operador, gerar alarmes e alertas para o operador, funções de controle e
supervisão e gerar dados históricos com curto período de armazenamento.
Exemplos de protocolo de redes nível 2: FieldBus HSE, PROFInet, EtherNet/IP,
Modbus/TCP, OPC.
e. Nível 1 – Controle básico de processo.
Este nível inclui os equipamentos de controle e monitoração, que estão
diretamente ligados aos sensores (instrumentos de medição de variáveis de
processo) e elementos finais de controle do processo (válvulas de controle,
motores elétricos e outros). Equipamentos de monitoração são responsáveis por
ler os dados dos sensores, em alguns casos executar um algoritmo e manter um
histórico de processo. E os equipamentos de controle são responsáveis por ler os
dados dos sensores, executar um algoritmo, enviar uma saída para o elemento
final de controle e manter um histórico de processo. Alguns exemplos de
equipamentos deste nível são os SDCD’s, CLP’s e RTU's (“Remote Terminal
Unit”).
Exemplos de protocolo de redes nível 1: DH+ (“Data Highway”), DeviceNet,
Modbus/TCP.
f. Nível 0 – Rede de campo.
Este nível é também conhecido como chão de fábrica e inclui os vários tipos de
sensores e elementos finais de controle que são diretamente conectados ao
processo ou aos equipamentos de um processo industrial. Os sensores são
responsáveis por medir a variável do processo (pressão, temperatura, nível, fluxo
e outros) e convertê-la em um sinal padrão a ser enviado ao equipamento de
17
controle. Os transmissores, os analisadores e os transdutores, são exemplos de
sensores. E os elementos finais de controle, são responsáveis por receber o sinal
de correção do controlador, e atuar no processo, de modo a manter o equilíbrio
desejado do processo. As válvulas de controle e os motores elétricos são
exemplos deste tipo de equipamento.
Exemplos de protocolos de redes nível 0: FieldBus H1, Profibus PA, Profibus
DP, AS-i, Modbus/TCP.
É importante mencionar a existência de um outro nível, chamado de nível de Segurança
Crítica, que seria acrescentado antes do nível 0. Este nível inclui sistemas de segurança
de processo que tomam ações automáticas em casos de falhas para manter a segurança
da planta, como por exemplo, as PSV's (válvulas de segurança). Porém, neste trabalho,
este nível será considerado como parte do nível 0.
A classificação em níveis é muito importante não apenas para se obter uma visão macro
da infra-estrutura da arquitetura de um sistema de automação industrial, mas também
para segregar os tipos de serviços e características específicas de cada um.
De acordo com o modelo de referência, o escopo de controle dos níveis 3 e 4 devem
abranger toda a empresa (petrolífera, celulose e papel, farmacêutica e outros), e o
escopo dos níveis 2 e 1, deve abranger apenas uma planta específica (eletroquímica,
geração de vapor, enfardamento, reator e outros), ou mesmo uma parte da planta.
A velocidade de resposta da ação de controle diminui na proporção que se desce na
hierarquia do nível mais alto para o nível mais baixo. No nível 0, os tempos de resposta
são tipicamente em mili segundos, no nível 1, os tempos de resposta são tipicamente em
segundos, nível 2, em minutos, e nos níveis 4 e 5 em horas ou dias. Os sistemas nos
níveis 1 e 2 geralmente são redundantes pela necessidade de garantir a disponibilidade
operacional do processo.
2.3 Segurança da Informação em ambientes industriais
A norma ISO/IEC 17799:2005 define segurança da informação como sendo “a proteção
da informação de vários tipos de ameaças para garantir a continuidade do negócio,
minimizar o risco ao negócio, maximizar o retorno sobre os investimentos e as
18
oportunidades de negócio”. Como será discutido mais adiante, esta definição vale para o
ambiente industrial, porém é necessário entender que o negócio em questão é o processo
industrial, onde a segurança humana, da planta e do meio ambiente deve ser priorizada.
Quando se trata de segurança de redes industriais, o que está em discussão é como
manter estas redes livre de danos, físicos ou lógicos. Ou seja, manter seguras as pessoas,
processos e equipamentos inseridos no contexto industrial.
2.3.1 Conceitos de Segurança da Informação
Entender a importância do tema “segurança da informação” em ambientes industriais,
como será abordado adiante, é fundamental para que uma empresa consiga manter a
continuidade de seus negócios. É muito importante que os executivos da área
reconheçam a necessidade de investimento nesta área e que os riscos sejam bem
avaliados. Alguns importantes conceitos de segurança da informação serão definidos
neste item, visando uma melhor compreensão do assunto abordado.
2.3.1.1 Vulnerabilidades
Vulnerabilidade pode ser definida como sendo “uma falha no projeto ou implementação
de um software ou sistema operacional, que quando explorada por um atacante resulta
na violação da segurança de um computador” [3]. Em outras palavras, pode-se dizer que
vulnerabilidade é qualquer brecha de segurança de um sistema, de uma rede de
computadores ou de qualquer outro ativo da empresa. E é importante ressaltar que isto
também inclui os sistemas do ambiente industrial da empresa.
A maioria dos projetos de automação, durante sua concepção, não teve os requisitos de
segurança
contemplados.
Portanto,
os
sistemas
instalados
podem
conter
vulnerabilidades que podem ser exploradas por qualquer pessoa que conheça as brechas
e que tenha acesso aos mesmos. Um exemplo claro é o projeto Modbus, protocolo de
comunicação para redes de automação que será abordado com mais detalhes no capítulo
4. Este protocolo foi projetado para funcionar em um ambiente dedicado e totalmente
19
isolado de outros sistemas, e não foram levados em conta as questões como acesso não
autorizado aos dispositivos de controle, leitura de dados indevida e outras.
2.3.1.2 Invasão ou intrusão
Muitos dos problemas das corporações, quando se trata de segurança da informação, são
causados por invasões a sistemas ou redes de computadores. Estas invasões ocorrem de
forma intencional por pessoas com certos benefícios ou privilégios adquiridos em
sistemas ou serviços de rede. Estes benefícios e privilégios permitem que o invasor use
os serviços da rede e os sistemas para o fim desejado. Em alguns casos o invasor tem a
intenção de causar prejuízos à corporação, mas muitas vezes é apenas uma forma de
demonstrar seus conhecimentos técnicos. Como se pode observar na Tabela 01, são
vários os tipos de invasores que ameaçam as instituições, desde os mais experientes
“hackers” aos adolescentes que utilizam os programas prontos na internet para
realizarem suas invasões.
Adversário
Objetivo
Estudante
Divertir-se bisbilhotando as mensagens de correio eletrônico
de outras pessoas. Também conhecidos como “script
kiddies”, por utilizarem scripts desenvolvidos por usuários
mais experientes.
“Cracker”
Representante
Testar o sistema de segurança de alguém; roubar dados.
de Tentar representar toda Europa e não apenas Andorra.
vendas
Executivo
Descobrir a estratégia de marketing do concorrente.
Ex-funcionário
Vingar-se por ter sido demitido.
Contador
Desviar dinheiro de uma empresa.
Corretor de valores
Negar uma promessa feita a um ciente através de uma
20
mensagem de correio eletrônico.
Vigarista
Roubar números de cartão de crédito e vendê-los.
Espião
Descobrir segredos militares ou industriais de um inimigo.
Terrorista
Roubar segredos de armas bacteriológicas ou promover um
atentado contra vidas humanas ou indústrias.
Tabela 01 – Exemplos de possíveis invasores [1].
Como se pode observar na Tabela 01, implementar um ambiente seguro é muito mais do
que implantar um sistema ou projeto sem erros de programação. Os registros de
incidentes de segurança da informação causados por invasões crescem a cada ano, e é
preciso se proteger também contra este tipo de ameaça.
2.3.1.3 Incidentes de Segurança
Todo evento, indesejado e inesperado, que venha a comprometer a confidencialidade, a
integridade e a disponibilidade da informação, causando prejuízos ao negócio da
empresa, ou mesmo comprometer a segurança de um processo industrial, pode ser
considerado como um incidente de segurança.
Os incidentes de segurança ocorrem através da exploração de vulnerabilidades
conhecidas de um sistema ou de uma rede de computadores. São exemplos de incidentes
de segurança da informação [4]:
ƒ
Tentativas de ganhar acesso não autorizado a dados, sistemas ou redes de
computadores;
ƒ
Uso ou acesso não autorizado a um sistema;
ƒ
Ataques de negação de serviços (DoS);
ƒ
Modificações em um sistema, sem o conhecimento ou consentimento prévio do
proprietário do sistema;
21
ƒ
Desrespeito à Política de Segurança de uma empresa 1 .
2.3.1.4 Vírus e worms
Vírus são programas que são capazes de infectar outros programas, arquivos e ou
sistemas de informática [3]. Através de uma série de instruções, estes programas podem
causar sérios danos ao hardware ou software de um ambiente de informática. Ele se
anexa a um programa hospedeiro, que ao ser executado pode contaminar vários
programas ou computadores.
No ambiente industrial, muitos sistemas utilizam macros para automatizarem
determinadas tarefas. Um tipo comum é o vírus de macro, que é facilmente criado e que
pode facilmente infectar os sistemas que utilizam macros, como os sistemas
supervisórios e SCADA. É necessário que os programadores destes sistemas levem em
conta os requisitos de segurança no momento da concepção e execução dos projetos.
O “worm” é um programa capaz de se propagar automaticamente através de redes,
enviando cópias de si mesmo de computador para computador. Ele se diferencia de um
vírus, pela sua capacidade de se propagar sem a necessidade de ser executado e sem a
necessidade do hospedeiro.
2.3.1.5 Cavalo de Tróia
Um cavalo de tróia é um programa que alega ter uma funcionalidade, mas na verdade
foi projetado para executar ações maliciosas ou danosas sem o conhecimento do
usuário. Ele sempre faz algo inesperado e indesejável, como copiar arquivos sem
autorização, roubar senhas e dados do usuário. Seu nome vem da mitologia, onde os
Gregos, em guerra contra os Troianos, lhes enviam um cavalo gigantesco como
presente. Porém, dentro do cavalo estavam centenas de soldados gregos que, passando
pelas muralhas dos troianos, conseguem dominar a cidade.
1
Política de Segurança é um documento que provê orientação e apoio da direção da empresa para segurança da
informação de acordo com os requisitos do negócio e com as leis e regulamentações relevantes.
22
Um cavalo de tróia pode ser um programa legítimo que teve seu código alterado para
realizar as funções maliciosas ou mesmo um programa desenvolvido com o próprio
intuito de enganar o usuário.
2.3.1.6 “Backdoor”
Uma “backdoor” consiste num programa ou serviço que é incluído ou alterado por um
atacante que tem a intenção de retornar ao computador ou sistema invadido, sem ser
notado. É importante ressaltar que uma “backdoor” pode ser ou não maliciosa. Alguns
desenvolvedores de programas incluem “backdoors” em seus produtos, alegando
necessidades administrativas [3]. Porém, mesmo estas “backdoors” que foram incluídas
com este propósito, podem ser descobertas por pessoas mal intencionadas, se tornando
alvos de ataques.
2.3.1.7 Negação de Serviço
Entende-se por negação de serviço, ou DoS (“denial of service”), como uma atividade
maliciosa que tem por finalidade a retirada de operação de um serviço em uma rede de
computadores.
Geralmente um ataque DoS é implementado através de um computador, controlado
através de backdoors, que enviam requisições a um computador alvo. Este computador
alvo, que pode ser um servidor, devido ao grande número de requisições, maior que sua
capacidade de processamento, ficará sobrecarregado e não conseguirá mais atender
outras requisições da rede, tornando o serviço indisponível. Outra maneira de se
implementar este ataque é gerando um grande tráfego na rede, fazendo com que toda a
banda disponível seja ocupada. Um exemplo simples de um DoS é um ataque chamado
“ping da morte”.
Um tipo avançado de ataque de negação de serviço é o DDoS (“Distributed Denial of
Service”), ou negação de serviço distribuído, onde vários computadores são utilizados
para implementação do ataque. A implementação deste ataque pode causar um grande
23
impacto a uma rede de automação industrial, devido à sua capacidade de tirar do ar os
serviços e sistemas de controle de uma planta industrial.
2.3.1.8 Spoofing
A técnica de “spoofing” [2] é a autenticação de uma máquina, se fazendo passar por
outra, forjando pacotes de um endereço de origem confiável. É um ataque com alto grau
de complexidade, pois o atacante, além de forjar o endereço de origem, deve manter um
diálogo de seqüência com o alvo do ataque. A manutenção deste diálogo é complexa,
pois o valor do número de seqüência não é arbitrário. O alvo estabelece um número
inicial de seqüência e o atacante deve acertar na resposta correta da seqüência. O
complicador é que o atacante nunca recebeu pacotes do alvo.
Estes são os passos que um atacante segue para realizar este tipo de ataque:
1. O atacante identifica o alvo e solicita a conexão;
2. O atacante coloca a máquina alvo temporariamente “fora do ar”, ou seja, ela fica
incapaz de processar solicitações de conexões recebidas num certo intervalo de
tempo. Isto pode ser implementado através de um ataque de inundação
sincronizada [2];
3. O endereço do host é forjado, utilizando um endereço de host que é confiável ao
alvo;
4. O atacante se conecta ao alvo, disfarçando-se do host confiável;
5. O número de seqüência é identificado;
6. O ataque é realizado.
Qualquer serviço de rede que utilize autenticação de endereçamento de IP pode sofrer
ataques de “spoof”.
2.3.2 Novo contexto na indústria
A evolução tecnológica da automação industrial trouxe consigo várias novas questões
que precisam ser tratadas com bastante cuidado pelos engenheiros e técnicos da área.
24
Este novo contexto industrial, onde a integração do ambiente industrial ao ambiente
corporativo, pode trazer vários ganhos para a empresa, porém, se não for dada uma
devida atenção a esta integração, os danos podem ser muito maiores que os benefícios.
É importante ressaltar que até a década de 90 o ambiente de automação industrial era
totalmente à parte do ambiente corporativo de uma indústria, onde estão disponíveis os
serviços de rede, como os serviços de correio eletrônico, intranet, e os sistemas de uso
corporativo (RH, contabilidade, jurídico e outros). As redes de automação tinham uma
característica diferente: eram determinísticas ao contrário das redes corporativas, que na
maioria das vezes, eram baseadas no padrão IEEE 802.3 (Ethernet), por sua vez, os
ambientes de automação possuíam sistemas operacionais de tempo real (RTOS),
computadores industriais exclusivos e geradores de relatórios especiais.
Hoje, os sistemas “fechados” estão dando lugar aos sistemas disponíveis no mercado. A
maioria dos projetos de automação já prevê os computadores dos sistemas supervisórios
rodando com o sistema operacional Windows, interligados com rede Ethernet e os
relatórios sendo extraídos em planilhas Excel. A maioria dos protocolos de
comunicação já possui uma versão Ethernet, onde seus pacotes são encapsulados em
pacotes TCP, como é o caso do Modbus/TCP (estudado no capítulo 4). Existem
inclusive vários CLP’s com “web service” embutido, permitindo que o operador, em
qualquer lugar da rede, tenha acesso de leitura e escrita no controle do processo, através
de um “browser”, como, o Internet Explorer, o Firefox e o Mozilla.
Pode-se dizer que a rede de automação industrial, já não é mais uma ilha, na qual apenas
os engenheiros e técnicos de automação tinham acesso. Na maioria das empresas, esta
rede se interliga à rede corporativa, para permitir que os dados e informações de
processo sejam acessíveis por qualquer ponto da empresa, para os sistemas gerenciais e
estatísticos.
Esta integração dos dois ambientes não aconteceu apenas pelo avanço das tecnologias
de mercado, mas também porque as empresas começaram a perceber que coletavam
muitos dados do processo, mas não faziam um uso adequado e otimizado destes dados.
Era necessário levar estes dados de processo além do nível operacional, para um nível
gerencial, onde eles pudessem ser analisados e serem tratados como informações,
permitindo uma ação não apenas corretiva e reativa, mas preditiva e pró-ativa,
25
aumentando-se assim a eficiência, a competitividade e a produtividade da empresa.
Neste cenário, surgiram os sistemas historiadores de processo ou PIMS (“Plant
Information Management Systems”), capazes de coletar os dados por meio de várias
interfaces de comunicação e disponibilizá-las em um banco de dados temporal
centralizado. A partir daí, com o processo e os dados que descrevem seu
comportamento sob controle num banco de dados centralizado, surgem os sistemas que
trabalham para transformar dados em informações úteis aos negócios. Sistemas com
estas funcionalidades são caracterizados como sistemas de gerenciamento da produção
ou EPS (“Enterprise Production Systems”), que incluem os sistemas de
acompanhamento da produção ou MES (“Manufactoring Execution System”),
manutenção, gerenciamento de laboratórios ou LIMS (“Lab Information Management
Systems”) e outros.
A integração destes dois mundos é um fato e uma tendência globalizada sem retorno.
Porém, os dois ambientes continuam, e continuarão sendo e tendo características,
objetivos e restrições particulares. Enquanto o ambiente industrial prioriza a produção e
a segurança humana, ambiental e operacional da planta, o ambiente corporativo prioriza
o desempenho e a integridade da informação.
A segurança da informação inclui três propriedades básicas: confidencialidade,
integridade e disponibilidade. Em um sistema de tecnologia da informação típico, a
estratégia de segurança tem como principal foco a confidencialidade da informação. A
integridade e disponibilidade da informação vêm em seguida na ordem de prioridade
estratégica.
Para os processos de segurança da informação em ambientes industrial, as prioridades
são inversas. Os procedimentos de segurança para este ambiente devem garantir a
disponibilidade dos componentes dos sistemas, que são responsáveis pelo controle do
processo. Estes componentes, por atuarem diretamente nos processos, são responsáveis
pela segurança humana, ambiental e operacional da planta. Um simples comando
indevido de abrir uma válvula de controle pode causar um grave acidente ou uma série
de outros transtornos. A integridade e a confidencialidade da informação, na ordem de
prioridade, vêm em seguida.
26
Figura 05 – Comparação das prioridades.
Para que um projeto de arquitetura de um sistema de segurança de dados para o
ambiente industrial seja bem implementado e eficaz, é preciso ter estas particularidades
em mente. Um exemplo da importância desta questão é uma situação citada pelo
professor Constantino Seixas [7], onde um operador ao tentar entrar no sistema digita
sua senha errada e o sistema bloqueia sua entrada, conforme procedimento estabelecido.
Após a terceira tentativa sua senha é cancelada para averiguação do caso, porém vários
alarmes estão soando e ele precisa urgentemente acessar o sistema para reconhecimento
destes. Nesse caso, a continuidade operacional é muito mais importante do que qualquer
outro requisito de segurança da informação.
Este é apenas um exemplo entre vários que podem ser citados. Mas o importante é
entender as particularidades e se analisar cada caso, de maneira a priorizar a segurança
humana, do processo e ambiental.
Em sistemas críticos, para garantir a disponibilidade no nível operacional, as estações de
operação, redes e controladores são redundantes. Na figura 06 tem-se um exemplo de
arquitetura de automação redundante, onde o CLP primário realiza as operações
normais de um controlador, leitura das entradas, processamento e atualização das saídas,
e comunica-se com o secundário através de uma rede, para atualização e sincronismo
dos dados de processo. Em caso de falha do CLP primário, o CLP secundário assume a
comunicação com as entradas e saídas, mantendo assim, a continuidade do processo
27
industrial. Este tipo de arquitetura com redundância é frequentemente chamada de
arquitetura "Hot-stand-by-backup"..
Figura 06 – Arquitetura redundante.
2.3.3 Ameaças ao ambiente de automação industrial
A diferença de objetivos e restrições entre os dois ambientes, se não for tratada com a
devida atenção pode se tornar uma grande ameaça à integridade do processo. Porém, é
importante ressaltar que existem outras ameaças tão graves como esta. O avanço
tecnológico e a utilização de tecnologias disponíveis em mercado aumentaram
consideravelmente
a
exposição
dos
sistemas
de
automação
industrial
às
vulnerabilidades existentes. A quantidade de pessoas que têm conhecimento e que
dominam os recursos do Windows e do TCP/IP é muito maior do que a quantidade de
pessoas que conhecem os sistemas utilizados pela automação industrial. Hoje, é
tranqüilamente
possível
encontrar
na
Internet
vários
programas
maliciosos
desenvolvidos especificamente para explorar vulnerabilidades dos sistemas e serem
28
utilizados em ataques a redes de computadores. E muitos destes programas podem ser
utilizados por qualquer usuário de computador sem qualquer conhecimento específico
de informática.
A exposição dos sistemas SCADA às ameaças aumenta à medida que estes são
conectados a um número cada vez maior de redes e sistemas para compartilhar dados e
fornecer serviços on-line [11]. Segundo Howard Schmidt, ex-presidente do “President’s
Critical Infrastructure Protection Board”, computadores apreendidos de grupos
terroristas revelaram que estes grupos têm estudado as vulnerabilidades dos sistemas de
automação industrial, considerando-os como possíveis alvos de ataques diretos. Muitos
podem afirmar que esta é uma realidade longe da realidade brasileira. Mas aqueles que
não se protegerem, além de estarem desguarnecidos frente às vulnerabilidades
existentes, podem acabar se tornando alvos fáceis de “testes e simulações de ataques
terroristas”.
Diversas são as formas de se implementar um ataque a um sistema de automação
industrial, seja explorando falhas de segurança ou degradando os serviços da rede [23]:
•
A propagação de códigos maliciosos;
•
A negação de serviços;
•
A exploração de vulnerabilidades no sistema operacional ou em outras
aplicações;
•
A má configuração de serviços.
Muitas empresas têm relutância em aplicar as medidas de segurança tradicionais em
seus sistemas, tais como aplicação de atualização do sistema operacional, verificação de
vírus, bem com as aplicações das atualizações das assinaturas de vírus, autenticação e
gerenciamento de senha. E isto só aumenta a vulnerabilidade dos sistemas de automação
atuais. Em 2003, por exemplo, o “worm Slammer” parou toda a operação de uma Usina
Nuclear nos Estados Unidos após conseguir penetrar em seu sistema de controle.
Além dos vírus, os ataques diretos também são ameaças que devem ser levadas em
contas. Gary Sevounts [11] cita o exemplo do hacker que manipulou mais de 23 vezes,
antes de ser preso, os sistemas SCADA que controlavam o sistema de saneamento na
29
Austrália. O atacante conhecia profundamente a rede e o software SCADA utilizado, e
por meio de "spoof" conseguiu invadir a rede.
Um relatório publicado pelo “British Columbia Institute of Tecnhology” atesta que, de
1982 a 2000, 38% dos incidentes de violação de segurança em sistemas de automação
eram de origem interna, ou seja, eram originados por agentes de dentro do ambiente da
própria empresa. Este valor saltou para 70% entre os anos de 2001 a 2003. É necessário
que sejam implementadas medidas de segurança que protejam as redes de automação
destas ameaças internas. O “firewall” é uma importante medida, mas controla apenas a
entrada e saída de dados da rede. As contramedidas necessárias vão muito mais além do
que a implantação de um firewall na entrada da rede, como será abordado na próxima
seção.
2.3.4 Contramedidas
Apesar de pouco se falar no assunto, muitas empresas têm buscado tomar providências
para eliminar ou mitigar os efeitos que as vulnerabilidades e ameaças aos sistemas de
automação industrial podem causar em um processo industrial, ou mesmo para os
negócios de uma empresa. A iniciativa da ISA [9] de elaborar uma norma específica
para este tema é um ótimo exemplo de que este assunto é crítico e tem sido priorizado
por alguns segmentos da comunidade de automação industrial.
Várias são as providências que precisam ser tomadas em contra ataque às
vulnerabilidades aos quais os sistemas estão expostos. A relação abaixo aponta para
algumas iniciativas importantes [11, 23, 28]:
•
O desenvolvimento e implementação de uma política de segurança específica
para o ambiente de automação industrial, baseada em padrões, normas e práticas
recomendadas da indústria;
•
A instalação, em locais estratégicos, de mecanismos contra códigos maliciosos;
•
O controle e o gerenciamento do serviço de acesso remoto, permitindo, se
necessário, apenas sessões criptografadas;
30
•
A instalação sistemática de atualizações de sistemas operacionais, softwares
aplicativos e sistemas antivírus;
•
A realização de treinamentos e eventos de conscientização;
•
A manutenção do sincronismo de tempo entre todos os equipamentos de rede;
•
O estabelecimento de políticas consistentes de “backups”, que especifiquem o
acesso aos arquivos gerados, agendamento adequado das rotinas do serviço,
tempo de retenção dos arquivos, testes de restauração e outros;
•
Segmentação física e lógica das redes;
•
A geração de “logs”, com configurações corretas de armazenamento (“online”
e “offline”) e análise;
•
Habilitação apenas dos serviços necessários;
•
A utilização de tecnologias de autenticação e autorização;
•
A utilização de “firewalls” em vários pontos internos e externos da infraestrutura da rede industrial;
•
A utilização de sistemas de detecção de invasão;
•
A criação de uma equipe de análise e resposta a incidentes de segurança.
2.4 Considerações finais
Em 2004, o Departamento de Energia dos Estados Unidos (DOE) publicou 21 ações que
podem ser aplicadas em um ambiente industrial como forma de reforçar a segurança das
redes industriais. Uma das ações propostas é “implementar Sistemas de Detecção de
Intrusão interna e externa e estabelecer monitoração de incidentes 24 horas por dia”
[22]. Um sistema de detecção de intrusão pode ser uma ferramenta muito útil para
ajudar na identificação de ataques e no reconhecimento das vulnerabilidades do sistema.
O capítulo seguinte abordará este sistema com mais detalhes de modo a demonstrar sua
aplicação e os ganhos desta em uma rede de automação industrial.
31
3 - Sistemas de detecção de invasão
3.1 Introdução
Como descrito no capítulo anterior, um sistema de detecção de intrusão pode ser uma
ferramenta útil na identificação de ataques e no reconhecimento das vulnerabilidades de
um sistema de automação industrial. Neste capítulo é descrito o funcionamento de um
sistema de detecção de invasão (IDS, do inglês “Instrusion Detection System”) e seus
tipos disponíveis: baseado em rede, baseado em “host” e distribuído e entender como
estes sistemas podem ser aplicados em uma rede de automação industrial.
Também é descrito o funcionamento do “Snort” [13], sistema de detecção de invasão
baseado em rede, de código-fonte-aberto, que possui vários recursos de configuração,
flexibilidade e simplicidade no uso. Este trabalho é utilizado para descrever um sistema
de detecção de invasão para redes de automação industrial utilizando o protocolo de
comunicação Modbus/TCP.
3.2 Definição de sistema de detecção de invasão
Podemos definir a detecção de invasão, como o ato de detectar uma entrada não
autorizada de um computador em uma rede [13]. Este acesso não autorizado pode vir a
comprometer a informação de uma empresa, ou seja, a confidencialidade, a integridade
e a disponibilidade de arquivos e/ou sistemas.
Um IDS monitora todo o tráfego em um segmento de rede a partir de um padrão,
buscando detectar comportamentos que indiquem um possível ataque ou invasão, com o
objetivo de causar danos ao funcionamento do sistema.
Existem três tipos de sistema de detecção de invasão: IDS baseado em rede [29] (NIDS,
do inglês “Network Instrusion Detection System”), IDS baseado em host [14] (HIDS,
do inglês “Host Instrusion Detection System”) e IDS distribuído.
O primeiro, como demonstrado na figura 07, monitora o tráfego de um segmento de
rede com o objetivo de gerar registros, alertas e permitir que ações sejam tomadas
quando um comportamento fora do padrão é detectado. Já o segundo, como
32
demonstrado na figura 08, monitora o “log” do sistema operacional e de aplicações em
um computador, alertando contra a tentativa de ganho de acesso não autorizado a
arquivos, dados ou serviços. O uso combinado dos dois tipos de sistemas de detecção é
recomendado, pois o uso de um não elimina a necessidade do uso do outro.
O terceiro tipo, demonstrado na figura 09, funciona em uma arquitetura
gerenciador/investigação. A proposta desta implementação é a distribuição dos sistemas
de detecção de invasão pela rede em locais distantes que se reportam a um servidor
central. Os alertas podem ser enviados periodicamente para a estação de gerenciamento
e utilizados para notificar o administrador da rede. Da mesma forma, os “downloads”
de atualizações de assinaturas de ataque podem ser periodicamente enviados aos
sistemas de detecção, de acordo com a necessidade de cada segmento. Os sensores
podem ser tanto NIDS como HIDS, ou um combinação de ambos.
Figura 07 – IDS baseado em rede.
33
Figura 08 – IDS baseado em “host”.
34
Figura 09 – IDS distribuído.
Uma evolução dos tradicionais sistemas de detecção de invasão são os sistemas de
prevenção de invasão (IPS, do inglês “Intrusion Prevention System”) [13]. Estes
sistemas são similares ao IDS's, porém são programados para atuarem preventivamente
de maneira a detectar e bloquear um ataque antes que danos sejam causados. Os dados
reunidos durante a detecção de um ataque servem como base de informações para uma
35
ação automatizada contra o ataque. A idéia é agilizar o processo de tomada decisão do
administrador da rede ao perceber a suposta invasão.
Quando se fala em um sistema tomar decisões automáticas em uma rede de automação
industrial, como no caso de um IPS, todo cuidado é pouco. Existe um receio muito
grande pela comunidade de automação industrial quando se trata deste assunto, pois
qualquer ação errada (falsos positivos e falsos negativos) que venha a ser tomada por
um IPS pode causar sérios danos à integridade e segurança de um processo industrial.
Mesmo o processo de tomada de decisão do operador, de parar ou não o processo
industrial ao se receber uma mensagem de alerta do IDS, não é algo tão simples. O
operador precisa estar convicto de sua decisão e das conseqüências da mesma, e para
isto ele necessita que sua ação esteja fundamentada em uma informação correta. O IDS
poderia ajudar neste processo de tomada de decisão do operador, gerando informações
de fácil entendimento sobre a forma como o alerta foi detectado.
Uma das grandes limitações das soluções atuais de IDS é que não conhecem a
inteligência dos protocolos e aplicações SCADA. Futuras soluções deverão ser
implementadas para atender estes requisitos. Os responsáveis pela segurança da
informação nas empresas, deverão aprender as implicações dos protocolos e aplicações
SCADA. Isto permitirá que muitos ataques no mundo industrial possam ser
identificados. Ao invés de se implantar um IPS, atualmente é mais viável a implantação
de um forte esquema de análise de “logs” com monitoria 24x7.
Este trabalho aborda um IDS baseado em rede, especificamente com o objetivo de
monitorar e analisar o tráfego de dados Modbus em um segmento de rede de Automação
Industrial.
3.3 Sistema de detecção de invasão baseado em rede
Um sistema de detecção de invasão monitora e analisa todo o tráfego de um segmento
de rede. Para isto a placa de rede do equipamento deve operar no modo promíscuo,
permitindo que todos os pacotes trafegados no segmento sejam capturados, incluindo os
destinados a outros equipamentos.
36
Em se tratando do “hardware”, o IDS pode ser um equipamento dedicado ao serviço de
detecção de invasão, com um sistema dedicado embutido e conectado à rede. Ou
também pode ser um “software” para este fim instalado em um computador também
conectado à rede, como por exemplo, o “Snort” [5].
Um IDS utiliza um mecanismo de comparação de assinaturas e padrões para identificar
um ataque. O modo mais simples de se definir um IDS é descrevendo-o como uma
ferramenta especializada que sabe ler e interpretar o conteúdo de arquivos de “log” de
roteadores, “firewalls”, servidores e outros dispositivos de rede. Todos os pacotes
capturados na sua interface de rede são comparados a partir de uma série de assinaturas
de ataques conhecidos, o que permite identificar comportamentos e atividades que
podem ser identificadas como um ataque. Pode ser comparado a um sistema de
vigilância através de câmeras de vídeo ou guardas. Uma analogia deste uso das
assinaturas para reconhecer e impedir ataques, pode ser feita com o funcionamento de
um programa antivírus.
O uso desta tecnologia permite que sejam implementadas proteções de segurança no
ambiente de automação industrial, como por exemplo [9]:
•
Monitoramento do tráfego de dados de entrada e de saída no segmento de rede;
•
Registro de informações para o estudo do comportamento da rede e análise de
ameaças, e;
•
Detecção, alarme, resposta ou prevenção contra ataques.
Uma outra maneira de análise de eventos é chamada de detecção de anomalia [13]. Ela
usa regras ou conceitos predefinidos sobre atividade de sistema “normal” e “anormal”
para distinguir anomalias do comportamento normal do sistema e monitorar, relatar ou
bloquear anomalias, quando elas ocorrem.
Com o objetivo de prover um modelo de sistema de detecção de invasão que servisse de
referência para os desenvolvedores da área, o CIDF [30] (“Common Intrusion Detection
Framework”) definiu uma série de componentes que juntos definem um sistema de
detecção de invasão. Estes componentes incluem um gerador de eventos (“E-boxes”),
um analisador de eventos (“A-boxes”), um mecanismo de armazenagem (“D-boxes”) e
37
um mecanismo de contramedidas (“C-boxes”).A figura 10 demonstra a interação destes
componentes.
Ethernet
E-box
A-box
D-box
C-box
Analisador
passivo de
protocolo
Analisador de
assinaturas e
padrões
Mecanismo de
armazenagem
Mecanismo de
contramedidas
Figura 10 - Relacionamento entre os componentes CIDF.
O gerador de eventos (“E-boxes”) é o responsável por fornecer as informações sobre os
eventos da rede para o sistema. Um evento pode ter uma grande complexidade ou pode
ser uma ocorrência de protocolo de rede de baixo nível. Geradores de eventos são os
órgãos sensoriais de um IDS. Sem um gerador de eventos, um IDS não tem como
avaliar se uma porção de informações pode ser um ataque ou não.
O analisador de eventos (“A-boxes”) recebe as informações do gerador de eventos,
analisa-as e faz um tratamento, gerando uma saída mais compreensível aos outros
componentes do sistema. As técnicas de análise de eventos são baseadas em detecção de
anomalia, análise de assinaturas, análise gráfica e até um modelo de sistema de
imunidade biológica tem sido proposto [30].
O mecanismo de armazenagem (“D-boxes”), é responsável por gravar a grande
quantidade de informações geradas pelo gerador e analisador de eventos. Estas
informações devem ser armazenadas de forma segura e de maneira tal que seja fácil o
acesso a elas quando necessário.
E por último, o mecanismo de contramedidas (“C-boxes”), responsável pelas ações que
o sistema poderá tomar após analisar os eventos. Este mecanismo seria utilizado pelos
Sistemas de Prevenção de Instrução (SPI), permitindo desde a quebra de uma conexão
TCP até a modificação do filtro de um roteador. A funcionalidade deste mecanismo
permite que ataques sejam identificados antes do ataque ocorrer.
38
Análise de assinaturas
A maioria dos IDS’s utilizam uma técnica chamada de análise de assinaturas para
identificar um ataque [30]. O termo assinatura se refere às informações sobre padrões de
tráfego ou atividades da rede e seus serviços. A análise de assinatura consiste em
interpretar uma série de pacotes, ou certa parte de dados contidos nestes pacotes, como
um ataque.
A maioria dos mecanismos de análise de assinaturas utiliza um algoritmo simples de
comparação de padrões. Na maioria das vezes, o IDS simplesmente procura por uma
“substring” que pode ser reconhecida nos pacotes capturados da rede. Quando estas
“substrings” são encontradas em um pacote, um ataque é então identificado.
Estes padrões de assinaturas são definidos em conjuntos de regras que são a base do
funcionamento de um IDS. As regras, além das informações de assinatura de um ataque,
contêm informações que permitem definir a metodologia do ataque em termos de
identificação do invasor, como endereço de origem e destino do pacote transmitido,
informações do protocolo e outros. Outras funcionalidades, como possíveis ações a
serem tomadas na identificação do ataque, também são características das regras.
Alguns exemplos de IDS com mecanismo de detecção de invasão baseado em
assinaturas são o “Snort”, NFR 2 , “RealSecure” 3 , “Dragon”
4
e “Cisco Secure” 5 . O
“Snort”, utilizado neste trabalho, é estudado com mais detalhes a seguir.
Outros exemplos de metodologia de detecção de invasão utilizados são “Imune System”
[12], “Control Loop Measurement” [15], “Data Mining” [31], “Statistical” [16] e
Detecção de Anomalia.
3.4 “Snort”
O “Snort” é um sistema de detecção de invasão de rede, de código-fonte aberto, que
possui um conjunto de recursos, agrupados em um único aplicativo. Estes recursos
2
http://www.nfr.com/products/NID/
3
http://www.checkpoint.com/products/firewall-l/realsecure.html
4
http://www.portcullis-security.com/products/index.htm
5
http://www.cisco.com/warp/public/cc/pd/sqsw/sqidsz/
39
incluem a captura e registro de pacotes, análise de pacotes, detecção de invasão e
módulos de entrada e saída. Quando o “Snort” captura um pacote que corresponde à
assinatura definida em uma regra estabelecida, ele sinaliza a identificação de um ataque.
Como visto adiante, várias ações podem ser configuradas após a identificação de um
ataque.
Originalmente, o “Snort” foi desenvolvido por Marty Roesch, em novembro de 1998,
para ser um simples farejador de pacotes para seu próprio uso. O “Snort” foi
desenvolvido como um aplicativo de “libcap”, o que permitia a filtragem e farejamento
da rede.
O “Snort” foi utilizado no início por Marty, para monitoramento de sua conexão de
modem a cabo e para depuração de aplicativos de rede que ele próprio codificava. Sua
primeira análise baseada em regras foi em janeiro de 1999 e em dezembro do mesmo
ano foi lançada sua versão 1.5.
O projeto “Snort” só foi alavancado, após um insucesso de Marty no desenvolvimento
de um Sistema de Detecção de Invasão comercial. Após ficar desempregado, Marty
investiu pesado no “Snort” para torná-lo mais usual e adaptável ao ambiente
empresarial, e assim surge a “Sourcefire”, que viria a contratar uma equipe de
desenvolvimento para desenvolver a versão 2.0 do “Snort” (sua versão atual).
Em uma comparação feita com outros sistemas de detecção de invasão [25], o “Snort”
apresentou vantagens: ser baseado em código-fonte aberto, requer baixo custo de
implantação, ser compatível com plataforma UNIX, possuir bom desempenho, ter um
grande suporte SNMP e possuir suporte para “plug-ins” de módulos de gerenciamento
centralizados.
3.4.1 Funcionamento do “Snort”
O “Snort” possui recursos que o tornam uma poderosa ferramenta na detecção de
intrusão. Sua arquitetura é composta por quatro componentes: o farejador de pacotes, o
pré-processador, o mecanismo de detecção e a saída.
40
Figura 11 – Arquitetura do “Snort”
O “Snort”, pode trabalhar simplesmente como um farejador de pacotes, porém ele pode,
após capturar estes pacotes, processá-los e depois fazer uma análise desses pacotes em
busca de padrões que caracterizem um ataque.
O funcionamento do “Snort” pode ser classificado em três modos:
•
Modo farejador;
•
Modo de registro de pacotes;
•
Modo de detecção de invasão;
•
Modo em linha.
3.4.1.1 Modo farejador
Neste modo o “Snort” funciona como um farejador (“sniffer”) de pacotes, onde todo o
tráfego capturado na interface de rede é exibido na tela do computador. Para isto é
necessário que a interface de rede do computador, onde o “Snort” está instalado, esteja
em modo promíscuo.
O pacote capturado é enxergado pela interface de rede que o disponibiliza para a
camada de enlace de dados, camada dois do modelo OSI. Os pacotes de dados então são
disponibilizados para o mecanismo de decodificação do “Snort”, que decodificará os
dados brutos recebidos. Este procedimento é realizado pela biblioteca chamada
“libcap”.
41
A biblioteca “libcap” foi desenvolvida inicialmente como parte do “TCPDump”,
programa que futuramente seria substituído pelo “Snort”. Esta biblioteca captura os
pacotes diretamente da placa de rede, permitindo que os mesmos sejam decodificados,
exibidos e registrados.
O seguinte comando permite que sejam exibidos os cabeçalhos da camada de transporte
(TCP, UDP e ICMP), da camada de rede (IP) e da camada de enlace de dados:
# Snort -vde
Os farejadores de pacote têm vários usos [13]:
•
Análise, diagnóstico e solução de problemas de rede;
•
Análise e comparativo de desempenho;
•
Intromissão para obter senhas em texto puro e outros dados interessantes.
3.4.1.2 Modo de registro de pacotes
Um outro modo de funcionamento do “Snort” é o de registro de pacotes, que consiste
em gravar os pacotes no disco rígido. Este modo de funcionamento é bastante similar ao
modo de farejamento, porém todo tráfego capturado na interface de rede, ao invés de ser
exibido na tela do computador, é enviado a um arquivo de “log” para uma posterior
análise.
O seguinte comando permite que os dados capturados sejam gravados no arquivo de
“log” chamado ‘log_Snort’ do diretório corrente:
# Snort -de -l ./log_Snort
Assim como no modo de farejamento, o modo de registro permite que, através das
informações capturadas da rede, sejam feitas análises e diagnósticos para resolução de
problemas de rede e análise e comparativo de desempenho. Este modo também permite
que as informações capturadas sejam utilizadas para fins maliciosos, como por exemplo
a intromissão para obter senhas em texto puro ou obtenção de dados da rede.
42
3.4.1.3 Modo de detecção de intrusão
Este modo é o principal modo de funcionamento do “Snort”. Ele recebe os dados
provenientes do pré-processador e os verifica baseado num conjunto de regras.
O pré-processador é um importante recurso do “Snort” que permite que funcionalidades
como a detecção de anomalia e a manutenção de estado de uma conexão sejam
implementadas, e não apenas a simples correspondência de número e string com relação
a padrões simples, mantendo o desempenho do sistema.
Os pré-processadores manipulam os dados do pacote após o decodificador do “Snort”
ter analisado os campos do pacote, mas antes que o mecanismo de detecção de intrusão
comece a fazer comparação de regras. Eles podem aumentar muito a funcionalidade da
base de correspondência de regra do “Snort” [13].
Os principais objetivos dos pré-processadores são: a remontagem de pacotes, a
decodificação de protocolos e a detecção não baseada em regra ou baseada em
anomalia.
O mecanismo de detecção recebe os dados provenientes do pré-processador. Estes
dados, após serem decodificados, são comparados com um conjunto de regras definidas.
Se esta comparação encontrar uma correspondência dos dados recebidos com as regras,
o pacote é então enviado para ser registrado ou para uma ação de alerta. Se não houver
correspondência, o mesmo é ignorado.
As regras são baseadas em texto e, geralmente, são armazenadas em um diretório do
“Snort”, sendo classificadas em diferentes grupos. O “Snort” lê os arquivos de regras e
gera uma lista tridimensional, que é utilizada para comparar pacotes para detecção. Esta
lista tridimensional pode ser definida como sendo um algoritmo de armazenamento das
regras e suas opções, a partir de onde o “Snort” procura por uma correspondência de
cabeçalho e padrão.
As regras são compostas de duas partes:
•
O cabeçalho da regra, que contém as seguintes informações:
o a ação de executar (“log” ou alerta);
o o tipo de protocolo (TCP, UDP, ICMP e etc);
43
o informações de origem e destino.
•
A opção ou miolo da regra, que contém os dados que serão utilizados na
comparação para que ele corresponda à regra.
Cabeçalho da regra
Os cabeçalhos identificam qual ação deverá ser tomada quando uma correspondência de
regra for encontrada, qual o tipo de protocolo deve ser usado e as informações de
origem e destino, incluindo endereço IP, endereços de redes CIDR (“Classless Inter
Domain Routing”) e portas de comunicação.
Figura 12 – Cabeçalho da regra.
Durante a análise dos dados do pacote, uma correspondência de regra pode ser
encontrada. O “Snort” tem então cinco opções de ações que podem ser tomadas e
também permite que o usuário crie suas próprias regras. Estas opções devem ser
especificadas na montagem da regra, são elas:
•
Pass - o pacote é ignorado;
•
Log - o pacote é registrado conforme especificado;
•
Alert - o pacote é registrado e uma mensagem de alerta é enviada;
•
Activate - gera um alerta e depois inicia uma regra dinâmica especificada;
•
Dynamic - é disparado pela ação “activate” para o registro de um número
determinado de pacotes. Esta opção é útil quando se deseja que o “Snort”
registre os pacotes após um ataque ser detectado.
44
O modo alerta precisa ser bem configurado para que não seja um incômodo para o
administrador da rede. As mensagens devem ser otimizadas ao máximo. Existem vários
modos de alerta que o “Snort” utiliza. Os principais são [5]:
•
Modo de alerta “Fast” - O alerta é registrado no formato simples com uma
indicação de tempo, a mensagem de alerta, portas e IP's de origem e destino.
Comando: -A fast.
•
Modo de alerta “Full alert mode” - Modo de alerta padrão com as mensagens de
alertas e os cabeçalhos dos pacotes. Comando: -A full.
•
Modo de envio de alerta para soquetes UNIX que outros programas podem.
Comando: -A unsock.
•
Modo de alerta desligado. Comando: -A none.
•
Modo de alerta que envia alertas para a tela do computador. Comando: -A
console.
•
Modo que gera alertas “cmg style”. Comando: -A cmg.
Abaixo, tem-se o exemplo de uma linha de comando do “Snort” , no modo de detecção.
Os dados serão registrados no diretório padrão ‘/var/log/Snort’, porém um outro local
poderia ser especificado. O arquivo ‘Snort.conf’ é o arquivo que contém as regras
configuradas que serão utilizadas para a comparação com os dados capturados.
# Snort -d -l -h 164.23.1.0/24 -c Snort.conf
Já na linha de comando abaixo, o “Snort” registrará as ocorrências no diretório
‘/var/log/Snort’ e enviará os alertas para um arquivo de alerta do tipo “fast”.
# Snort –c Snort.conf –A fast –h 192.50.128.33/24
A segunda parte da regra especifica qual o tipo de protocolo será suportado pela regra
(ICMP, TCP, IP, UDP, HTTP, ARP e 802.11). Apenas um protocolo pode ser definido
por regra.
A terceira e última parte da regra especificam as informações de origem e destino, ou
seja, a atribuição de endereço IP e portas de comunicação. A atribuição de endereços IP
pode ser feita utilizando endereços IP individuais ou endereços CIDR.
45
O operador “!” deve ser utilizado associado a um endereço IP ou endereço CIDR para
negar um determinado valor.
No exemplo abaixo se pode observar uma aplicação das opções do cabeçalho de uma
regra. Neste exemplo a regra é definida para que sejam registrados todos os pacotes
TCP de qualquer porta de origem de uma rede de origem diferente da definida tendo
como destino o endereço IP 192.168.100.34 502 e porta 502.
log tcp !192.168.50.0/24 any -> 192.168.100.34 502
O “Snort” permite também que sejam definidos mais endereços IP e portas de origem
ou destino em uma mesma regra. Para isto é necessário incluir os endereços IP ou portas
entre colchetes e separados por vírgula. Outra funcionalidade é a definição de intervalos
de portas, onde se especifica o número de porta mínimo e máximo.
alert
tcp
[192.168.50.2,
192.168.50.3,
192.168.50.4]
any
->
192.168.100.34 502:1000
Miolo da regra
O miolo da regra é o recurso do “Snort” que contém as informações utilizadas na
comparação com o pacote capturado na identificação do ataque. Ele é dividido em
seções separadas por ponto-e-vírgulas, sendo que cada seção define uma opção, que
possui um valor. No exemplo a seguir, pode ser observado, em parênteses, o miolo de
uma regra com suas opções.
alert tcp any any -> 192.168.1.0/24 111 (content:”|00 01 86 a5|”:
msg “mountd acces”;)
Existem várias opções que podem ser definidas em uma mesma regra. A seguir serão
listadas as principais opções, que serão utilizadas na construção das regras [13].
•
Controle de fluxo (“flow”) – permite que seja definida a direção do pacote em
relação aos fluxos de comunicação cliente-servidor. Funciona coordenada com o
módulo de remontagem de TCP e permite que a regra distinga conteúdo e
direção de pacote em relação à arquitetura cliente-servidor. Esta opção aumenta
a funcionalidade do IDS, pois não é necessário definir direção de pacotes na
camada IP. Existem aproximadamente oito opções de controle de fluxo:
to_server, from_server, to_cliente, from_client, only_stream, no_stream,
established e stateless. O formato desta opção é: flow :<opção>.
46
•
Conteúdo (“content”) – esta é a opção mais poderosa e importante do “Snort”,
pois é onde é feita a análise da matriz de choque do pacote para identificar um
conteúdo potencialmente danoso. As matrizes de choque podem ser analisadas
através de valores binários, ASCII ou uma combinação dos dois. O formato
desta opção é: “content”: “string”. Para conteúdos binários, os dados
hexadecimal devem ser escritos entres caracteres de “pipe” ( | ).
•
“Offset” – esta opção diz ao mecanismo do “Snort” para começar a procurar a
string de conteúdo a partir do valor de “offset” definido. O formato desta opção
é: “offset”: <número_de_bytes>.
•
“Depth” – este modificador define o número de bytes que o mecanismo do
“Snort” deve analisar. O formato desta opção é: “depth”: <número_de_bytes>.
•
Mensagens (“msg”) – esta opção é utilizada para informar ao administrador da
rede sobre o tipo de vulnerabilidade, ameaça ou ataque que foi identificado. O
formato desta opção é: “msg”: “descrição_da_ocorrência”.
•
Comprimento ou intervalo (“dsize”) – esta opção especifica o comprimento ou o
intervalo de comprimento da matriz de choque de um pacote. Os sinais de < e >
são utilizados para especificar os intervalos para comprimento da matriz de
choque maior ou menor que o valor especificado e o sinal <> para especificar
um intervalo entre valores especificados. O formato desta opção é: “dsize”:(<,>
ou nada) comprimento (<> comprimento).
3.4.1.4 Modo em linha
Para a versão 2.3.0, ou superior, do “Snort” foi adicionada a funcionalidade de o sistema
trabalhar como um Sistema de Prevenção de Intrusão (IPS). Esta funcionalidade permite
ao “Snort” atuar integrado com o “Iptables” [21], permitindo que este possa rejeitar
pacotes indesejáveis.
Um “Snort” no modo em linha atua de maneira bastante semelhante a um “firewall”
ativo, porém, com algumas vantagens adicionais. Um IPS pode não apenas bloquear
uma comunicação de um endereço IP ou uma porta de comunicação específica, mas
47
também descartar pacotes que contenham a assinatura de um ataque. Estas são as três
regras utilizadas com o “Snort” em modo em linha [5]:
•
“Drop” – esta regra solicitará ao “iptables” descarte o pacote e registrará a
ocorrência de acordo com os próprios recursos do “Snort”.
•
“Reject” – esta regra solicitará ao iptables para descartar o pacote, registrará a
ocorrência de acordo com os próprios recursos do “Snort” e enviará um TCP
“reset” se for uma conexão TCP ou uma mensagem icmp de porta inalcançável
se o protocolo for UDP.
•
“Sdrop” – esta regra solicitará ao iptables apenas para descartar o pacote.
Nenhum registro será feito.
Neste trabalho, não será estudado o “Snort” no modo em linha.
3.5 O uso de um sistema de detecção de invasão no ambiente industrial
A seção anterior abordou as maneiras seguras de se projetar uma rede utilizando um
IDS. No ambiente de automação industrial, esta ferramenta tem basicamente duas
importantes aplicações, que são demonstradas nas figuras 13 e 14.
48
Figura 13 – Arquitetura de rede integrada.
Na primeira aplicação, o IDS é instalado no segmento de rede entre a rede corporativa e
a rede de nível de controle e supervisão da rede de automação industrial, em conjunto
com um “firewall”. Esta aplicação monitora o tráfego de pacotes de dados entre a rede
corporativa e a rede de automação. O “firewall” tem o papel do filtro de pacotes,
bloqueando uma comunicação IP ou porta específica não autorizada. A grosso modo,
pode-se dizer que o “firewall” bloqueia ou permite a passagem do pacote sem saber o
dado que está dentro. Já o IDS fornece condições para detecção de comportamentos e
conteúdos anormais dos pacotes de dados. Esta detecção é baseada na análise
comparativa destes dados com suas regras ou assinaturas definidas. O IDS após a
49
liberação do pacote pelo “firewall”, verifica o pacote em busca de assinaturas que se
enquadrem como um ataque.
Para esta primeira aplicação, a maioria dos IDS’s encontrados no mercado atendem às
necessidades deste trabalho, pois todos os protocolos a serem analisados são os mesmos
de uma rede corporativa. É extremamente importante que o tráfego entre as duas redes
sejam rigorosamente monitorados e controlados.
Em uma segunda aplicação, um IDS é utilizado num segmento de rede nível 2 do
ambiente de automação industrial, ou seja, entre os dispositivos de controle e as
estações de operação e supervisão. Esta é uma área pouco explorada atualmente pelos
responsáveis pelas áreas de automação industrial por várias razões, mas não deixa de ser
crucial para o negócio de uma empresa. Muitas redes industriais estão hoje vulneráveis
pelo simples fato de não se ter conhecimento do tipo de dados que trafegam em sua
infra-estrutura.
50
Figura 14 - IDSR num segmento do nível de controle e supervisão
Os protocolos específicos de automação industrial foram concebidos para ambientes
fechados e isolados. Porém, hoje a maioria dos sistemas vive em ambientes
compartilhados e integrados. Os ambientes fechados, com softwares proprietários,
migraram para os ambientes compartilhados, onde impera os softwares de protocolo
aberto, que permitem a integração de várias plataformas e ambientes diversos. É
verdade que, no mundo de automação, ainda existam muitos softwares baseados em
protocolos proprietários, mas cada vez mais, os padrões abertos, como OPC e Modbus
ganham força.
Alguns motivos para se utilizar um IDS num segmento do nível de controle e supervisão
de um ambiente de automação industrial:
51
•
Convivência de vários padrões em uma mesma rede;
•
Em muitos casos, existe o compartilhamento do meio físico de uma infraestrutura de rede pelos ambientes corporativos e de automação industrial;
•
Possibilidade crescente de ataques contra as instalações industriais sejam eles de
origem externa ou interna, intencionais ou não intencionais;
•
Atualmente a quase totalidade dos novos sistemas de automação estão sendo
desenvolvidos na plataforma Windows, o qual possui uma grande gama de
pessoas “especializadas” em seus recursos e possui uma série de
vulnerabilidades que são a todo instante exploradas;
•
A maioria dos protocolos de automação industrial foi desenvolvida sem levar em
conta os requisitos de segurança da informação. É importante ressaltar que os
requisitos de segurança para um ambiente corporativo são diferentes dos
requisitos para um ambiente de automação industrial.
A implantação de um IDS neste segmento de um ambiente industrial, ainda tem uma
série de limitações que precisam ser tratadas, como:
•
A falta de IDS’s desenvolvidos e disponíveis em mercado para protocolos não IP
específicos da área de automação industrial, como: FieldBus, Profibus,
DeviceNet e muito outros;
•
A falta de IDS’s desenvolvidos e disponíveis em mercado para protocolos IP
específicos da área de automação industrial, como: Modbus/TCP, OPC,
Ethernet/IP, ProfiNet e outros;
•
O grande consumo de recurso para gerenciar as informações disponibilizadas
por um IDS nos vários segmentos de um típico ambiente de automação
industrial. Existem uma grande variedade de protocolos proprietários e
protocolos abertos, e uma grande variedade de aplicações nas indústrias;
•
A falta de conhecimento e experiência no suporte e configuração de IDS’s pelo
pessoal de automação industrial.
52
4 MODBUS/TCP
4.1 Introdução
O Modbus é um protocolo de comunicação entre dispositivos cliente e servidores em
redes de automação industrial. Criado em 1979, quando foi lançado o Modbus serial. O
Modbus sobre TCP/IP, segundo o “ARC Advisory”, apesar de apenas 9 anos desde sua
criação, é considerado o protocolo com mais pontos de rede vendidos por ano. Há a
tendência destes números crescerem cada vez mais, pois a cada ano que passa, mais e
mais equipamentos “Ethernet” são comercializados no mundo inteiro.
O Modbus consiste de um protocolo da camada de aplicação, posicionado na camada 7
do modelo OSI, que provê uma comunicação entre vários dispositivos cliente e servidor
conectados em diferentes barramentos ou redes de automação industrial. [18]
Este protocolo pode ser implementado sobre: um meio de transmissão serial assíncrona,
Ethernet e outros, como demonstrado na figura 15.
Camada de Aplicação Modbus
Modbus/TCP
TCP
IP
Outro
Modbus+ / HDLC
Mestre/Escravo
Ethernet – 802.3
Outro
Camada Física
EIA/TIA – 232
EIA/TIA-485
Ethernet
Camada física
Figura 15– Implementação do protocolo Modbus.
53
O padrão de comunicação é um simples mecanismo de requisição e resposta, muito
similar ao http ou SNMP, onde o mestre (cliente) inicia a comunicação enviando uma
requisição a um ou mais escravos (servidores). Dispositivos mestres podem ser CLP’s,
estações de trabalho, mainframes, IHM's ou outros equipamentos de E/S (entrada e
saída).
O protocolo Modbus serial usa tipicamente o meio de transmissão serial RS-232/485 e
tem duas implementações primárias: Modbus ASCII e Modbus RTU. Modbus/TCP é o
terceiro protocolo Modbus o qual trouxe Modbus para o mundo IP. Modbus/TCP é
comumente utilizado por controles Active X ou Java Applets, onde um usuário pode se
conectar ao servidor “web” embutido no CLP, ou outro dispositivo de campo, e acessar
os dados de processo via um “browser” qualquer.
Uma rápida descrição do protocolo sobre um meio de transmissão serial será feita,
porém o propósito deste capítulo é descrever a especificação do protocolo de aplicação
Modbus/TCP.
Por se tratar um protocolo de padrão aberto, vários fornecedores de equipamentos têm
desenvolvido drivers de comunicação para Modbus. Um exemplo comum de aplicações
deste protocolo é na integração de sistemas de fornecedores distintos, como uma
aplicação onde se faz necessário interligar um dispositivo de campo, como um CLP
SLC500 (Rockwell), a um sistema SCADA iFix (Intelution), na sala de controle.
4.2 Protocolo de Aplicação Modbus
4.2.1 Descrição
O protocolo Modbus, na camada de aplicação (tendo o modelo OSI como referência),
define uma simples PDU (do inglês, “Protocol Data Unit”), cujo conteúdo é
transparente para a camada inferior. Esta PDU é enviada para a camada inferior, onde
serão acrescidas novas informações ou campos na ADU (do inglês, “Application Data
Unit”), dependendo do meio físico em questão (Ethernet, serial e outros).
54
Figura 16 – Pacote Modbus Genérico.
A PDU do protocolo de aplicação Modbus é composta pelo campo de dados e pelo
campo código de função. Esta PDU é definida pela aplicação cliente, que inicia uma
transação com o servidor através de uma requisição. O campo de código de função
especifica qual o tipo de requisição está sendo feita pelo cliente e qual ação deve ser
tomada pelo servidor. O tamanho da PDU de um protocolo de aplicação Modbus é
limitado pela primeira implementação Modbus sobre um meio de transmissão serial
RS485, que é de 256 bytes.
O campo código de função é definido em um byte, tendo uma faixa decimal de 1 a 255.
Esta campo é divido em três categorias: código de função públicos, código de função
definidos pelo usuário e códigos de função reservados. Cada uma destas categorias será
abordada com mais detalhe no item 4.2.3.
O campo de dados, enviado pelo cliente ao servidor, contém as informações
complementares ao código de função que são utilizadas pelo servidor para processar a
requisição. Em alguns casos, o campo de dados pode ser nulo. Isto porque apenas o
código da função é suficiente para o servidor entender e processar a requisição.
Ao receber a requisição enviada pelo cliente, o servidor processa a requisição e, se
nenhum erro ocorrer, prepara um quadro de resposta com os dados requisitados. Este
quadro tem a mesma estrutura do quadro de requisição: campo código de função e
campo de dados. Em caso de erro, o servidor prepara e retorna um quadro contendo uma
resposta de exceção indicando ao cliente o tipo de erro ocorrido.
55
Figura 17 – Modelo de transação Modbus entre Cliente e Servidor.
Figura 18 – Modelo de transação Modbus entre Cliente e Servidor com código de
exceção retornado.
56
De acordo com a Especificação do Protocolo de aplicação Modbus V 1.1a, três PDU’s
são definidas, sendo elas:
1. Requisição Modbus PDU, mb_req_pdu
2. Resposta Modbus PDU, mb_rsp_pdu
3. Resposta de Exceção Modbus PDU, mb_excep_rsp_pdu
A PDU mb_req_pdu é definida desta maneira:
mb_req_pdu = {function_code, request_data}, onde:
function_code = [1 byte] código de função Modbus especificado pelo
cliente
request_data = [n bytes] Este campo está relacionado ao campo de
função e geralmente contém informações como referências de variáveis,
contadores, “offsets” de dados, códigos de sub-função e outros.
A PDU mb_rsp_pdu é definida desta maneira:
mb_rsp_pdu = {function_code, response_data}, onde:
function_code = [1 byte] código de função Modbus
response_data = [n bytes] Este campo, como na requisição, está
relacionado ao campo de função e geralmente contém informações como
referências de variáveis, contadores, “offsets” de dados, códigos de sub-função e
outros.
A PDU mb_excep_req_pdu é definida desta maneira:
mb_excep _rsp_pdu = {function_code, request_data}, onde:
function_code = [1 byte] código de função Modbus + 0x80
request_data = [n bytes] Este campo contém o código da exceção
retornada pelo servidor ao cliente.
57
4.2.2 Base de dados Modbus
O modelo da base de dados Modbus é baseada numa série de tabelas com características
diferentes. As quatro tabelas primárias são:
Tabelas primárias
Tipo de objeto
Tipo
Comentários
Entradas discretas
Bit simples
Leitura apenas
Este tipo de dado é
geralmente provido por um
dispositivo de entrada e
saída (E/S).
Saídas discretas
(Bobinas)
Bit simples
Leitura e escrita
Este tipo de dado pode ser
alterado por uma aplicação.
Registros de entrada
Palavra de 16 bits
Leitura apenas
Este tipo de dado é
geralmente provido por um
dispositivo de entrada e
saída (E/S).
Registros de saída
Palavra de 16 bits
Leitura e escrita
Este tipo de dado pode ser
alterado por uma aplicação.
Tabela 02 – Modelo de dados.
4.2.3 Descrição dos códigos de função do Modbus
Como descrito no item 4.2.1, o campo de código de função é responsável por identificar
o tipo de requisição que está sendo feita pelo cliente e qual ação deve ser tomada pelo
servidor.
Este campo é divido em três categorias: ‘códigos de função públicos’, ‘códigos de
função definidos pelo usuário’ e ‘códigos de função reservados’.
Todos os códigos de função da categoria ‘códigos de função públicos’ são validados e
documentados pela comunidade MODBUS-IDA.org. Torna-se um padrão para todos os
fornecedores e fabricantes de equipamentos Modbus, tendo a garantia de cada código
ser único. Esta categoria compreende os códigos já especificados e um range de códigos
disponíveis para especificação.
58
Já a categoria ‘código de função definidos pelo usuário’, como o próprio nome diz, é
um espaço reservado para a necessidade dos usuários de definirem códigos de função
conforme suas necessidades. Neste caso, cada usuário define o seu padrão e não há a
garantia da unicidade dos códigos. Fornecedores diferentes podem utilizar um mesmo
código, porém com funções totalmente distintas.
Existe uma categoria de código, chamada de ‘códigos de função reservados’, que são
utilizados por empresas para especificação de produtos e que não estão disponíveis para
o uso público.
A tabela abaixo descreve os ‘códigos de função públicos’ mais comumente utilizados
pelos fornecedores e fabricantes. Como se pode observar, alguns códigos definem
dentro de sua faixa códigos de sub-função.
Código de função
Código
Entrada discreta física
Bit de
acesso
Bits internos ou Bobinas
físicas
16 bits de
acesso
Registros internos ou
Registros de saídas físicas
Acesso a arquivos
Diagnósticos
Outros
(hex)
Leitura de entradas discretas
02
02
Leituras de status de bobinas
01
01
Bits de escrita simples
05
05
Bits de múltipla escrita
15
0F
04
04
Leitura de registros Holding
03
03
Escrita de registro de saída
06
06
Escrita de registro múltiplos
16
10
Leitura/escrita de registro
múltiplos
23
17
Escrita de registros de máscara
22
16
Leitura de fila FIFO
24
Leitura de arquivo
20
6
14
Escrita de arquivo
21
6
15
Leitura de status de exceção
07
Diagnóstico (Modbus serial)
08
Obtenção de contador de evento
COM
11
0B
Obtenção de contador de evento
“log”
12
0C
Retorna o ID do escravo
17
11
Leitura de identificação do
dispositivo
43
14
2B
Interface encapsulada de
transporte
43
13, 14
2B
Referência geral CANopen
43
13
2B
Registros de entrada físicos Leitura de registros de entrada
Dados de
acesso
Subcódigo
Tabela 03 – Códigos e sub-códigos de função.
18
07
00-18,20
08
59
4.2.4 Resposta de exceção Modbus
Como visto anteriormente, a comunicação entre um dispositivo cliente e um dispositivo
servidor se dá através de requisições e respostas. As requisições são enviadas pelo
cliente ao servidor, que esperam uma resposta do servidor com os dados solicitados.
Esta resposta esperada é enviada se o servidor receber a requisição e executá-la
normalmente. Porém, alguns problemas podem ocorrer e o servidor pode ou não enviar
a resposta.
Um problema de comunicação pode ocorrer e o servidor não receber a requisição
enviada pelo cliente. Deste modo ele não retornará nenhuma resposta, e o cliente
provavelmente processará um erro por tempo expirado.
Se o servidor recebe a requisição, porém detecta um problema de comunicação (erro de
paridade, CRC e outros) não retorna nenhuma resposta. O mesmo erro por tempo
expirado provavelmente será detectado pelo cliente.
E por último, se o servidor recebe a requisição sem problema de comunicação, porém
não consegue executá-la, é preparada uma resposta de exceção, informando o tipo de
erro ocorrido, que é enviada ao cliente.
Quando uma mensagem de exceção é preparada, o campo de código de função e o
campo de dados são alterados. No campo de código de função, o bit mais significativo
do código é alterado para 1. O valor do código então é acrescido, em relação ao valor
original, de um valor hexadecimal igual a 80. Com o bit mais significativo do código
habilitado, o cliente pode entender que a resposta se trata de uma exceção e pode
analisar o campo de dados, que contém o código da exceção, conforme tabela 04.
Código
Exceção
Comentários
01
Função ilegal
O código de função é desconhecido
pelo servidor.
02
Endereço de dados ilegal
O endereço do dado recebido não é um
endereço válido para o servidor.
60
03
Valor de dados ilegal
O valor contido no campo de dados não
é um valor válido para o servidor.
04
05
Falha no dispositivo escravo
O servidor falhou durante a execução
(servidor)
de uma requisição.
Reconhecimento
O servidor aceitou a invocação do
serviço, mas tomará um longo tempo
para executá-lo. É retornado um
reconhecimento de aceite do serviço.
06
Dispositivo escravo (servidor)
O servidor estava impossibilitado de
ocupado
aceitar a requisição. A decisão de se a
mensagem será enviada e quando, cabe
ao cliente.
08
Erro de paridade da memória
O servidor detectou um erro de
paridade nos dados em memória.
0A
Caminho do “gateway”
O “gateway” não conseguiu
indisponível
estabelecer uma comunicação interna
entre a porta de entrada e a porta de
saída no processo da requisição.
0B
Falha de resposta do dispositivo
Indica que não foi possível obter
“gateway” de destino
resposta do “gateway” para qual a
requisição foi enviada.
Tabela 04 – Código de exceção.
61
4.3 Modbus serial (RTU)
Inicialmente o protocolo Modbus foi desenvolvido para os meios físicos seriais:
EIA/TIA-232 ou EIA/TIA-485, posicionando-se, no seu equivalente do modelo OSI, na
camada dois (camada de enlace).
Camada
7
6
5
4
3
2
1
Modelo OSI
Aplicação
Apresentação
Sessão
Transporte
Rede
Enlace
Física
Protocolo de aplicação
MODBUS
Vazio
Vazio
Vazio
Vazio
MODBUS Serial
EIA/TIA-485 ou EIA/TIA232
Figura 19 – Modelo em camadas.
O protocolo Modbus serial line é um protocolo mestre x escravo. Numa rede Modbus
apenas um mestre é conectado ao barramento. Este mestre é responsável por iniciar a
comunicação com o nó escravo e enviar as requisições aos nós escravos do barramento.
Apenas uma comunicação é inicializada no intervalo de tempo. Um nó escravo nunca
pode transmitir dados sem receber uma requisição de um nó mestre. Esta comunicação é
definida como sendo determinística.
O número máximo de dispositivos escravos que podem ser conectados em um
barramento é de 247 escravos. Isto é causado pela limitação do campo de
endereçamento do protocolo.
O dispositivo mestre, em uma rede Modbus, faz requisições aos nós escravos de dois
modos: unicast e no modo broadcast. No primeiro, o mestre endereça uma requisição a
um determinado nó escravo da rede. O escravo recebe a requisição, processa e retorna
ao mestre. No segundo modo, o mestre endereça a requisição a todos os nós escravos da
rede. O endereço “0” é utilizado para indicar este modo de requisição. Neste modo os
escravos recebem a requisição, mas não enviam uma resposta. Requisições deste modo
são usadas para comandos de escrita.
62
Figura 20 – Modo de comunicação unicast.
Figura 21 – Modo de comunicação broadcast.
0
Endereço de
broadcast
De 1 a 247
Endereçamento de dispositivos escravos
Figura 22 – Endereçamento Modbus RTU.
De 248 a 255
Reservado
63
4.4 Modbus/TCP
4.4.1 Modelo Cliente x Servidor
Uma comunicação Modbus/TCP requer o estabelecimento de uma conexão TCP entre
um cliente e um servidor. Através desta conexão, o Modbus/TCP provê um serviço de
comunicação cliente / servidor entre dispositivos conectados em uma rede Ethernet
TCP/IP. Este modelo é baseado em quatro tipos de mensagens [19] (figura 23):
•
Requisição Modbus - é a mensagem de requisição enviada pelo cliente ao
servidor, iniciando a transação.
•
Confirmação Modbus - é a mensagem de resposta recebida pelo cliente.
•
Indicação Modbus - é a mensagem de requisição recebida pelo servidor.
•
Resposta Modbus - é a mensagem de resposta enviada pelo servidor.
Figura 23 – Serviço de mensagem Modbus.
Este serviço de comunicação é usado para troca de informação em tempo real em redes
de automação industrial entre: duas aplicações de dispositivos diferentes; uma aplicação
de um dispositivo e outro dispositivo; uma aplicação SCADA e um dispositivo; e um
computador e um programa de um dispositivo provendo serviços, como pode ser
observado na figura 24.
64
Figura 24 – Exemplo de aplicações Modbus.
Da mesma forma que no modo serial, no Modbus/TCP o cliente é quem inicia a
comunicação com o servidor através de uma requisição. Esta requisição é composta de
uma PDU contendo um campo com o código da função e um campo com os dados
(figura 25).
Existem significativas diferenças entre o protocolo Modbus serial e o protocolo
Modbus/TCP. No Modbus/TCP, um cabeçalho é adicionado à PDU da camada de
aplicação, que é usado com o objetivo de identificar a ADU Modbus. Este cabeçalho é
chamado de MBAP (do inglês, “Modbus Application Protocol Header”). As diferenças
existentes entre a ADU do Modbus serial e a ADU do Modbus/TCP são necessárias
para adaptar o protocolo Modbus ao TCP.
Figura 25 –Pacote Modbus/TCP.
65
A responsabilidade pelo endereçamento dos dispositivos da rede, que antes era do
Modbus serial, através do campo Endereço, agora fica com a camada de transporte e
com a camada de rede do TCP/IP. Na camada de transporte TCP é padrão a utilização
da porta de comunicação 502. E na camada de rede, um endereço IP é definido. No
cabeçalho MBAP é adicionado um campo ‘Identificador de unidade’ para o caso de
comunicação de dispositivos numa rede Ethernet com dispositivos numa rede serial,
através de dispositivos como pontes, roteadores ou “gateways”.
O cabeçalho MBAP contém, além do campo ‘Identificador de unidade’ mencionado no
parágrafo acima, outros três campos. São eles: ‘Identificador da transação’,
‘Identificador de protocolo’ e ‘tamanho’.
4.4.2 Modelo da arquitetura Modbus/TCP
Figura 26 – Modelo de arquitetura Modbus.
Este modelo de arquitetura apresentado é um modelo geral proposto pela comunidade
Modbus-IDA. Este modelo inclui componentes de Modbus clientes e servidores que são
aplicáveis em qualquer dispositivo.
66
Como aplicação do usuário, podemos definir como qualquer programa de um
dispositivo de controle e ou monitoração. Podemos citar como exemplos: CLP’s,
sistemas SCADA, SDCD’s, IHM's, dispositivos simples de entrada e saída e outros.
A seguir são descritas os componentes desta arquitetura.
Componente de gerenciamento da conexão TCP
O estabelecimento de uma conexão TCP pode ser implementado pela aplicação usuário
ou automaticamente pelo módulo de gerência de conexão TCP (figura 27).
No primeiro caso, todas as conexões TCP são gerenciadas pela aplicação usuário:
estabelecimento ativo e passivo, encerramento de conexão, etc. Esta solução provê uma
maior flexibilidade e liberdade de programação. É necessária porém, uma atenção ao
número de conexões que podem ser estabelecidas entre clientes e servidores. Este
número deve levar em conta a capacidade do sistema.
Já no segundo caso, o gerenciamento da conexão é totalmente transparente para a
aplicação usuário, que apenas tem a incumbência de enviar e receber mensagens. O
gerenciador de conexão TCP é responsável por abrir e encerrar as conexões sob
demanda.
67
Figura 27 - Diagrama de atividade do gerenciamento de conexão TCP [19].
Como pode ser observado na figura 28, o serviço de mensagens Modbus utiliza a porta
de comunicação 502, que permite o estabelecimento de conexões e troca de dados com
outros dispositivos. Quando um dispositivo precisa trocar dados com um dispositivo
remoto, é aberta uma conexão com este dispositivo na porta 502. A porta local do
dispositivo remoto deve ser maior que 1024 e deve e ser diferente para cada conexão.
Figura 28 – Estabelecimento de conexão Modbus TCP.
Uma requisição Modbus é enviada pelo dispositivo cliente após o estabelecimento da
conexão TCP. Várias conexões TCP entre um cliente e um servidor podem ser
estabelecidas. Se o número de conexões TCP ativas alcança o número limite, a conexão
68
mais velha é encerrada. Um cliente pode iniciar uma transação Modbus com um
servidor sem esperar o fim de uma transação anterior.
Figura 29 - Troca de dados Modbus.
69
Camada de comunicação da aplicação
Um dispositivo Modbus pode prover uma interface Modbus cliente e ou servidor e uma
interface Modbus “Backend”. Quatro áreas compõem esta interface: entrada discreta,
saída discreta (bobina), registros de entrada e registros de saída.
Modbus Cliente
O seguinte diagrama de atividade, definido pela comunidade Modbus-IDA, descreve o
comportamento esperado por um Cliente Modbus.
Figura 30 - Diagrama de atividades Cliente Modbus [19].
Um cliente Modbus deve ser capaz de tratar três tipos de eventos:
1. Uma nova demanda oriunda da aplicação usuário de enviar uma requisição de
dados ao servidor. A requisição é entregue à camada inferior, ou seja, a camada
de transporte TCP, que é responsável por entregá-la ao servidor de origem. Um
suporte a erros de conexão é suportado pelo protocolo TCP. Esta transação é
transparente para a camada de aplicação Modbus.
70
2. Uma resposta do gerenciamento TCP, que requer uma análise do conteúdo da
resposta pelo cliente. Uma confirmação, positiva ou negativa, deve ser enviada a
aplicação usuário.
3. A espera por uma resposta do servidor. Se o tempo determinado de espera
expirar, o cliente pode retransmitir a requisição ‘n’ vezes. Quando este número
de tentativas esgotar, uma confirmação negativa deve ser enviada a aplicação
usuário. Algumas tentativas de retransmissão da mensagem podem ser feitas
pela camada de reconhecimento TCP.
A construção de uma requisição Modbus pode ser dividida em quatro fases (figura 31):
instanciação da transação Modbus, codificação da PDU, codificação do cabeçalho
MBAP e envio da requisição para o gerenciador TCP.
A instanciação de uma transação Modbus permite ao cliente memorizar todas as
informações requeridas pela aplicação usuário. Assim ele é capaz de receber a resposta
com os dados enviados pelo servidor e enviar a resposta à aplicação usuário.
A requisição é preparada pelo cliente de acordo com as informações repassadas pela
aplicação usuário. A PDU é codificada e preenchida conforme vimos no item 4.4.1. E a
ADU é o resultado da adição do cabeçalho MBAP à PDU.
71
Figura 31 - Diagrama de atividades de preparo de uma requisição [19].
O cabeçalho MBAP contém, os campos: ‘Identificador de unidade’, ‘Identificador da
transação’, ‘Identificador de protocolo’ e ‘tamanho’.
O campo ‘Identificador de unidade’ é utilizado para fins de roteamento entre um
dispositivo Modbus/TCP e um Modbus serial. Este campo leva o valor do endereço do
dispositivo escravo de uma rede Modbus serial. Quando um dispositivo Modbus/TCP
precisa se conectar com um dispositivo Modbus serial através de uma ponte
(“gateway”), o endereço IP de destino é o endereço da ponte. E a ponte utiliza o
endereço descrito no campo ‘Identificador de unidade’ para encaminhar a requisição ao
dispositivo escravo da rede Modbus serial. Se em uma rede, utiliza-se apenas
endereçamento IP, é recomendado se utilizar um endereçamento sem valor significativo
(0xFF), ou então o valor zero (0).
O campo ‘Identificador da transação’ é utilizado para identificar uma comunicação
entre um cliente e um servidor. O servidor copia em sua resposta o identificador
72
recebido na requisição. Em uma conexão TCP, espera-se que o valor deste campo seja
único.
E o campo ‘tamanho’ é utilizado para indicar a quantidade de bytes seguintes do pacote,
incluindo o ‘Identificador de unidade’ e o ‘Campo de dados’.
Campos
Tamanho Cliente
Servidor
Identificador de
2 Bytes
Define o valor do
Copia o valor da requisição
campo.
recebida em sua resposta.
Define o valor do
Copia o valor da requisição
campo.
recebida em sua resposta.
Define o valor do
Define o valor do campo
campo (requisição).
(resposta).
Define o valor do
Copia o valor da requisição
campo.
recebida em sua resposta.
Transação
Identificador de
2 Bytes
protocolo
Tamanho
Identificador de
2 Bytes
1 Byte
Unidade
Tabela 05 – Campos do cabeçalho MBAP.
Como mostrado na tabela acima, o valor total de um cabeçalho MBAP é de 7 bytes.
Quando um quadro de resposta é recebido em uma conexão TCP, o campo
‘Identificador da transação’ é utilizado para associar a resposta com a requisição
enviada. Se nenhum valor de resposta é associado a uma requisição, o quadro é
descartado. E se o valor do campo é associado a uma requisição, a resposta é processada
para que uma confirmação, negativa ou positiva, seja encaminhada a aplicação usuário.
Após a verificação do campo ‘Identificador da transação’, o campo tamanho fornece o
tamanho da resposta Modbus.
Então o código de função e o campo de dados devem ser analisados. Três situações
podem ocorrer. Se o código de função verificado é o mesmo da requisição e o formato
da resposta está correto, então uma mensagem de confirmação positiva é retornada a
aplicação usuário. Se o código de função verificado é uma exceção (código de função +
73
80H), uma resposta de exceção é repassada a aplicação usuário como uma confirmação
positiva. Se o código de função verificado é o diferente do usado na requisição ou o
campo de dados contém inconsistências, uma mensagem de confirmação negativa é
retornada a aplicação usuário.
Figura 32 - Diagrama de atividades do processo de confirmação [19].
Uma confirmação positiva repassada a aplicação usuário, não implica que o servidor foi
capaz de processar a requisição adequadamente, mas sim que uma requisição foi
enviada a um servidor e uma resposta foi recebida.
Servidor Modbus
Um servidor Modbus é responsável por prover acesso a objetos e serviços de uma
aplicação para um cliente Modbus remoto. Esta aplicação pode ser uma aplicação de um
dispositivo como um CLP, uma IHM, um instrumento de medição de campo, um
dispositivo simples de E/S e outros. A função do servidor Modbus é mapear os objetos
74
desta aplicação em objetos Modbus de leitura e escrita, para disponibilizar ou alterar
seus atributos.
O servidor Modbus deve, em tempo real, processar a requisição recebida pelo cliente
Modbus e enviar uma resposta com os dados solicitados ou com uma mensagem de
exceção.
O servidor Modbus pode prover dois tipos de acessos aos objetos das aplicações: um
acesso simples aos seus objetos ou um acesso avançado aos serviços. Alguns serviços
podem ser processados pelo servidor Modbus sem a necessidade de interação com a
aplicação usuário, por outro lado, alguns serviços necessitam desta interação para serem
processados.
Entre o servidor Modbus e a aplicação usuário, podem existir dois tipos de interação:
síncrona e assíncrona.
Um servidor Modbus pode aceitar mais de uma requisição simultaneamente. A
quantidade máxima de requisições simultâneas que um servidor pode aceitar depende de
sua implementação: projeto, capacidade de memória e processamento.
O diagrama abaixo descreve como se dá o processo de tratamento de uma requisição
recebida de um cliente Modbus, a verificação da PDU, o processamento do serviço e o
preparo da resposta.
75
Figura 33 - Diagrama de tratamento de requisição [19].
A primeira função do servidor Modbus, como é demonstrado no diagrama anterior, é
verificar o cabeçalho MBAP recebido no pacote enviado pelo cliente Modbus. O campo
‘Identificador de protocolo’ deve ser ter o valor 0x00, indicando o protocolo Modbus.
Se o valor deste campo for diferente deste, a indicação é recusada. E se o valor confere,
uma transação é instanciada.
O número máximo de transações que podem ser instanciadas, dependem do parâmetro
“NumberMaxOfTransaction”. Se o valor deste parâmetro for excedido, uma resposta de
exceção é preparada com o campo ‘código de exceção’ com valor igual a seis (6):
servidor ocupado.
Após a validação do campo ‘Identificador de protocolo’, o servidor deve verificar: o
‘identificador da conexão TCP’, fornecido pelo gerenciador TCP; o campo
‘identificador da transação’; e o ‘identificador de unidade’.
76
Se estes campos forem validados, o servidor passa a verificar a PDU recebida. Sendo o
campo ‘código de função’ o primeiro a ser verificado. Se o valor deste for inválido, uma
resposta de exceção é preparada com o campo ‘código de exceção’ com valor igual a
um (1): função inválida. E se o valor for validado, o servidor passa a processar a
requisição.
Após o processamento da requisição, o servidor deve preparar uma resposta à aplicação
usuário. A resposta depende do resultado do processamento da requisição e pode ser
uma resposta positiva ou uma resposta de exceção.
Se nenhum erro foi detectado durante o processamento da requisição, o servidor
retornará uma resposta positiva com as informações preenchidas no ‘campo de dados’
da PDU. No campo ‘código de função’ da PDU deve ser copiado o mesmo valor
encontrado no campo ‘código de função’ da requisição recebida. Um cabeçalho MBAP
deve ser anexado a PDU com os campos devidamente preenchidos. O valor do campo
‘identificador de unidade’ deve ser o mesmo do mesmo campo da requisição. O valor
do campo ‘tamanho’ deve conter o valor calculado da PDU mais o valor do campo
‘identificador de unidade’ em bytes. O campo ‘Identificador de protocolo’ também deve
ter o mesmo valor do mesmo campo da requisição, ou seja, 0x0000. E o valor do campo
‘identificador da transação’ deve ser associado à requisição recebida.
77
5 Snort aplicado a uma rede MODBUS/TCP
5.1 Introdução
Neste capítulo, são apresentados os testes realizados para demonstrar as funcionalidades
e os ganhos na utilização de um Sistema de Detecção de Intrusão em redes de
automação industrial. A arquitetura do ambiente de rede utilizado nos testes foi
composta por um dispositivo cliente, um dispositivo servidor de dados, se comunicando
através do protocolo Modbus/TCP, e do Snort como IDS de rede.
Em ambientes de automação industrial, os sistemas de controle e supervisão
desempenham um papel de suma importância para a garantia da continuidade e da
segurança operacional do processo industrial. Qualquer alteração ou novas
implementações desenvolvidas nestes sistemas requerem um exaustivo processo de
testes e validação. A implementação de um Sistema de Detecção de Intrusão em redes
de automação também precisa ser submetida a este processo, uma vez que pode
interferir diretamente nos sistemas de controle e supervisão da planta industrial.
Levando estes requisitos em conta e também devido ao pouco tempo disponível para o
desenvolvimento deste trabalho, optou-se por realizar os testes em um ambiente de
simulação.
78
Figura 34 – Modelo de comunicação cliente x servidor Modbus.
Em sistemas de controle e supervisão, o dispositivo cliente (mestre) pode ser um
sistema SCADA, Supervisório ou SDCD, enquanto o dispositivo servidor (escravo), em
boa parte das aplicações, é um CLP.
O desenvolvimento dos testes descritos neste capítulo foi dividido em duas etapas. A
primeira etapa consistiu na instalação e configuração dos programas Modbus cliente,
Modbus servidor e do IDS Snort, com uma série de regras elaboradas especificamente
para o Modbus TCP. A segunda etapa consistiu na execução dos testes em questão, ou
seja, a geração de ataques e análise dos alertas e registros gerados pelo Snort.
5.2 Ambiente de simulação
Como já mecionado, em uma rede Modbus/TCP, o dispositivo escravo é responsável
por colher os dados do processo industrial, realizar as tarefas de controle lógico e
disponibilizar informações de tempo real ao dispositivo mestre. A aquisição destes
dados pelo dispositivo cliente (mestre) é feita através de requisições enviadas ao
dispositivo servidor (escravo). O servidor, após receber e processar a requisição, envia
79
uma mensagem de resposta ao cliente, contendo os dados solicitados ou uma mensagem
de exceção, caso um erro ocorra.
Para o desenvolvimento dos testes, foram utilizados dois programas de simulação
Modbus/TCP:
•
Modpoll – Um programa de simulação de dispositivo cliente (mestre), e o;
•
Mod_rssim - Um programa de simulação servidor (escravo).
Figura 35 – Ambiente de simulação.
O principal objetivo do Snort é, através de regras definidas especificamente para o
protocolo Modbus/TCP, detectar a ocorrência de ataques a uma rede de automação
industrial. Para isto ele fará a inspeção dos pacotes de dados, contendo as requisições e
respostas trocadas entre o cliente Modbus e o servidor Modbus.
80
Como visto anteriormente, a necessidade de integração do ambiente corporativo ao
ambiente de automação industrial, trouxe uma série de questões de segurança que antes
eram particulares ao ambiente corporativo da empresa. Questões como a possibilidade
de contaminação dos sistemas de controle e supervisão por vírus de computador,
exploração de falhas de programação, tráfego de informações em texto pleno, ataques
de negação de serviço, acesso não autorizado e outros tipos de vulnerabilidades e
ameaças que passam a fazer parte do ambiente industrial. Vale lembrar outra importante
questão: a maioria dos protocolos de automação industrial não foi projetada para atender
aos requisitos de segurança das redes corporativas. Este também é o caso do Modbus,
que originalmente foi projetado para comunicação “mestre x escravo” em redes seriais
dedicadas e totalmente segregadas de outras redes da empresa.
A utilização do Snort, com uma série de regras desenvolvidas especificamente para o
protocolo Modbus/TCP, é uma importante ação para eliminar ou mitigar os efeitos que
estas vulnerabilidades e ameaças podem causar ao processo industrial. Outro ganho,
gerado pela flexibilidade de desenvolvimento de regras personalizadas, é o de suprir a
carência de ferramentas de detecção de intrusão em redes de automação industrial,
devido a grande variedade e particularidade dos protocolos existentes.
As regras definidas no Snort são úteis na detecção de vários tipos de ataques, como por
exemplo:
1 – Tentativa de estabelecimento de comunicação não autorizada por atacantes
se fazendo passar por dispositivo mestre ou escravo;
2 – Requisições que podem ser associadas a ataques de reconhecimento
(engenharia social) ou Negação de Serviço (DoS);
3 – Tráfego de pacotes Modbus/TCP mal formados que poderiam ser utilizados
num ataque de “buffer overflow” ou Negação de Serviço (DoS).
5.2.1 Instalação e configuração do Snort
O Snort tem uma série de características que permitem a definição e utilização de
recursos que facilitam seu uso em ambientes grandes ou distribuídos, através dos
arquivos de configuração. Os arquivos de configuração do Snort permitem que o
81
mecanismo inclua variáveis, arquivos de configuração adicionais e arquivos “include”
vinculados adicionais. A seguir serão descritos os passos seguidos na configuração dos
recursos do Snort.
Definição das variáveis
O Snort permite que sejam definidas variáveis personalizadas para uso dentro de um
conjunto de regras. Estas variáveis devem ser incluídas no arquivo de configuração
‘/etc/snort/snort.conf’ e podem ser usadas no lugar de endereços IP e redes. A sintaxe
do comando é:
var <desired_variable_name> < variable_name >
Na
simulação
foram
adicionadas
as
variáveis
“MODBUS_CLIENT”
e
“MODBUS_SERVER” no arquivo de configuração com os respectivos endereços IP das
máquinas utilizadas como mestre (clientes) e escravo (servidoras).
O conteúdo do arquivo ‘/etc/snort/snort.conf’ ficou o seguinte:
var MODBUS_CLIENT 192.123.198.100
var MODBUS_SERVER 192.68.71.50
include /etc/snort/modbus_tcp.rules
Geralmente a quantidade de estações escravas (CLP’s, RTU’s, Dispositivo de I/O) é
grande, enquanto o número de estações mestre (Supervisórios, SDCD’s) é bem
reduzido. Isto se explica pelo fato de que um sistema SCADA acessa vários dispositivos
de campo.
É importante que seja definida uma política de segurança da rede de automação que
estabeleça um controle na adição e remoção de dispositivos com endereço IP na rede.
Antes da instalação de um equipamento na rede, é necessário que seja incluído no
arquivo de configuração o endereço IP, para evitar a ocorrência de falsos positivos na
rede. Um endereço IP adicionado sem este cuidado, pode ser entendido pelo IDS como
uma tentativa de acesso não autorizado à rede. Esta questão será abordada com mais
detalhes no próximo item.
82
Inclusão do arquivo de regras
Outra funcionalidade do Snort é que ele permite que sejam especificados arquivos do
tipo “include” contendo conjuntos de regras que podem ser utilizados na
implementação das regras. As variáveis e tipos de regras definidos dentro dos arquivos
“include” substituirão os valores predefinidos para essas variáveis.
Para a simulação, foi adicionada no arquivo de configuração a linha “include
/etc/Snort/modbus_tcp.rules”, como pode ser observado no item anterior. Esta opção
indicará o arquivo com as regras que foram definidas para o protocolo Modbus/TCP e
que foram utilizadas neste trabalho.
Definição das Regras
O Snort permite a cada usuário criar suas próprias regras, aplicadas ao seu ambiente
específico. Esta funcionalidade do sistema permite que sejam criadas regras específicas
para protocolos de automação sobre Ethernet, como é o caso do Modbus/TCP. As regras
para este protocolo foram descritas em um arquivo chamado ‘modbus_tcp.rules’.
Para o desenvolvimento deste trabalho, foram utilizadas as seguintes regras
desenvolvidas e disponibilizadas pela “Digital Bond Inc.” 6 .
a) Modo de escuta forçado
Esta regra gera um alerta para cada requisição enviada por máquinas clientes forçando o
dispositivo servidor a ficar unicamente no modo de escuta. Isto isola este dispositivo
dos demais da rede e todos os controles de comunicação ativos são desligados. Para o
processo ser normalizado é necessário que seja enviada uma requisição de reinício da
comunicação para o servidor em questão (código de função 8 e sub-função 1).
alert
tcp
$MODBUS_CLIENT
(flow:from_client,established;
any
->
content:"|08
$MODBUS_SERVER
00
04|";
502
offset:7;
depth:3; msg:"Modbus TCP - Force Listen Only Mode"; priority:1;)
6
http://www.digitalbond.com
83
Este ataque pode ser conduzido por qualquer atacante que tenha um IP válido na rede e
que tenha um programa simulador de cliente Modbus, que pode ser obtido facilmente na
Internet.
Este ataque pode ser considerado um ataque de negação de serviço, pois o dispositivo
servidor, que como vimos pode ser um CLP, não responderá mais a nenhuma requisição
de outro dispositivo cliente da rede. Um ataque como este pode ser direcionado a todos
os CLP’s de uma rede.
Podem ocorrer falsos positivos, pois este comando pode ser usado pelos técnicos para
testes ou análise de problemas, mas isto é raro. É necessário que seja identificada a
origem dos comandos para se evitar futuros ataques.
b) Opção de reinício de comunicação
Esta regra identificará todas as requisições enviadas por um dispositivo cliente para
reiniciar os dispositivos servidores. Este comando faz com que a porta remota do
servidor seja reinicializada, ficando momentaneamente sem comunicação com os
demais dispositivos.
alert
tcp
$MODBUS_CLIENT
any
->
$MODBUS_SERVER
(flow:from_client,established;
content:"|08
depth:3;
Restart
msg:"Modbus
TCP
-
00
01|";
Communications
502
offset:7;
Option";
priority:1;)
Esta também é uma ação simples de ser implementada por qualquer pessoa que tenha
acesso à rede alvo. E, pelo mesmo motivo descrito no item anterior, alguns falsos
positivos podem ser gerados. Eventualmente este comando pode ser utilizado por
técnicos da rede para análise e resolução de problemas.
c) Limpeza dos contadores e registros de diagnóstico
Esta regra identificará todas as requisições enviadas de um dispositivo cliente para
qualquer dispositivo servidor com código de função 08 e código de sub-função 0A. Este
comando tem o propósito de limpar todos contadores e registros de diagnóstico e
poderia ser utilizado por um atacante na tentativa de limpar seus rastros no sistema ou
dificultar a análise de um problema.
84
alert
tcp
$MODBUS_CLIENT
(flow:from_client,established;
depth:3;
msg:"Modbus
TCP
-
any
->
content:"|08
Clear
$MODBUS_SERVER
00
Counters
502
0A|";
offset:7;
and
Diagnostic
Registers"; priority:3;)
Falsos positivos também podem ser gerados, pois ocasionalmente pode existir a
necessidade de que seja feita uma limpeza nos contadores e registros de diagnóstico do
sistema.
d) Leitura de dados do dispositivo
O código de função 2B é utilizado por dispositivo cliente para obter informações do
dispositivo servidor. Podem ser obtidas várias informações, como: fabricante, código do
dispositivo, versão do software, modelo e outros mais que estejam disponíveis.
Este é um recurso de engenharia social que pode ser utilizado por atacantes na obtenção
de informações que serão úteis em um subseqüente ataque ao sistema ou até mesmo na
obtenção de vantagens comerciais.
alert
tcp
$MODBUS_CLIENT
any
->
$MODBUS_SERVER
502
(flow:from_client,established; content:"|2B|"; offset:7; depth:1;
msg:"Modbus TCP - Read Device Identification"; priority:3;)
Ao se detectar uma transação como esta, deve ser verificada e validada a origem da
requisição. Pois, ocasionalmente estas informações podem ser requisitadas, gerando
falsos positivos.
e) Solicitação de informação do servidor
Uma requisição feita com o código 0x11, permite que um dispositivo cliente receba a
descrição do tipo, o corrente estado e outras informações específicas de um dispositivo
servidor.
alert
tcp
$MODBUS_CLIENT
any
->
$MODBUS_SERVER
502
(flow:from_client,established; content:"|11|"; offset:7; depth:1;
msg:"Modbus TCP - Report Server Information"; priority:3;)
Este, da mesma maneira que o anterior, é um ataque de engenharia social. Pode ser
utilizado para a coleta de informações dos dispositivos e da rede para um subseqüente
ataque ou obtenção de vantagens comerciais.
85
f) Requisição de leitura no CLP não autorizada
O protocolo Modbus não possui um sistema de autenticação da origem de uma
requisição. Em outras palavras, qualquer dispositivo de uma rede pode requisitar dados
de um dispositivo servidor sem problemas. Esta também é uma grande arma nas mãos
de uma pessoa mal intencionada, como um engenheiro social.
Este alerta permite que seja identificada qualquer tentativa de comunicação de um
dispositivo não autorizado, ou seja, com IP diferente do que está registrado na variável
MODBUS_SERVER, tentar se comunicar com os dispositivos servidores da rede.
alert
tcp
!$MODBUS_CLIENT
(flow:from_client,established;
any
->
$MODBUS_SERVER
content:"|00
00|";
502
offset:2;
depth:2;
pcre:"/[\S\s]{3}(\x01|\x02|\x03|\x04|\x07|\x0B|\x0C|\x11|\x14|\x17
|\x18|\x2B)/iAR"; msg:"Modbus TCP - Unauthorized Read Request to a
PLC"; priority:2;)
Se algum novo dispositivo é adicionado à rede, falsos positivos serão gerados até que
seja incluído o seu IP na variável do arquivo de configuração do Snort.
g) Requisição de escrita não autorizada no servidor
Este caso é bem semelhante ao anterior, com o agravante de que aqui se trata não
apenas de leitura de dados, mas de escrita de dados no dispositivo servidor. Tendo
acesso de escrita nos dispositivos de controle de uma planta industrial, o atacante
poderia alterar a configuração de um CLP, tornando-o inoperável, ou mesmo ter ao seu
alcance o controle de vários equipamentos de campo, como válvulas de controle,
bombas, acionadores e muitos outros. E isto seria um grande risco à integridade do
sistema e à segurança operacional de uma planta industrial, pois qualquer comando feito
de maneira inadequada, poderia causar um acidente de proporções catastróficas.
alert
tcp
!$MODBUS_CLIENT
(flow:from_client,established;
any
->
$MODBUS_SERVER
content:"|00
00|";
502
offset:2;
depth:2;
pcre:"/[\S\s]{3}(\x05|\x06|\x0F|\x10|\x15|\x16)/iAR";
msg:"Modbus
TCP
priority:1;)
-
Unauthorized
Write
Request
to
a
PLC";
86
Este também é um ataque simples, pois da mesma forma que os anteriores, qualquer
pessoa com acesso à rede e com um simulador disponível na Internet, poderia
implementá-lo.
Como no item anterior, se algum novo dispositivo é adicionado à rede, falsos positivos
serão gerados até que seja incluído o seu IP na variável do arquivo de configuração do
Snort.
h) Tamanho de pacote ilegal, possível ataque de negação de serviço
O tamanho de uma PDU no protocolo Modbus é limitado pelo tamanho da “constraint”
herdada da primeira implementação Modbus na rede serial. O tamanho máximo de uma
Unidade de Dados de Aplicação (UDA) para RS485 é 256 bytes.
No Modbus/TCP é adicionado um Cabeçalho (MBPA) a PDU da aplicação Modbus,
como visto no capítulo anterior, e este pacote é encapsulado em um pacote TCP.
Porém, não existe uma proteção do protocolo contra o envio de pacotes que excedam
este tamanho. Um atacante, com intenção de implementar um ataque de “buffer
overflow” ou Negação de Serviço (DoS), pode criar pacotes maiores que 256 bytes e
enviá-los, podendo causar mal funcionamento nos dispositivos servidores.
alert
tcp
$MODBUS_CLIENT
any
<>
$MODBUS_SERVER
502
(flow:established; dsize:>300; msg:"Modbus TCP - Illegal Packet
Size, Possible DOS Attack"; priority:1;)
Para este caso, não existem falsos positivos conhecidos e sua implementação não é tão
simples. A criação e envio de um pacote com tamanho maior do que esperado é simples,
porém implementar um pacote que gere um ataque de “buffer overflow” não é tão
simples e bem específico da aplicação.
i) Dispositivo escravo ocupado
Um servidor pode estar processando um comando ou programa que consuma muito
recurso e que tenha conseqüentemente uma longa duração. Neste caso, quando um
cliente envia uma requisição estando o servidor ocupado, é enviada uma resposta pelo
servidor com código de exceção informando que ele está ocupado. O cliente deve então
enviar a requisição mais tarde, quando o servidor estiver desocupado.
87
Um atacante, com acesso físico ou lógico a um dispositivo servidor, pode interceptar
uma requisição de um cliente e responder com este código de exceção. Isto permite que
o atacante ganhe mais tempo numa modificação no programa de um CLP ou outro
dispositivo de campo.
alert
tcp
$MODBUS_SERVER
502
->
$MODBUS_CLIENT
any
(flow:established; content:"|06|"; offset:8; depth:1; byte_test:
1, >, 0x80, 7; msg:"Modbus TCP - Slave Device Busy Exception Code
Delay"; threshold: type threshold, track by_src, count 3, seconds
60; priority:2;)
Este alerta pode ajudar na identificação deste ataque, porém falsos positivos podem ser
comuns, pois um CLP ou outro dispositivo Modbus servidor, podem realmente estar
num processamento de longa duração.
j) Reconhecimento de exceção de código de atraso
O servidor, ao receber uma requisição de um cliente, que tomará um tempo de
processamento maior do que determinado, ou esperado, deverá enviar uma resposta com
código de exceção de atraso de valor igual a 05 para prevenir um erro de tempo
expirado, ou “time out”, no cliente.
Um atacante pode interceptar uma requisição de um cliente a um servidor e retornar ao
cliente uma mensagem com código de exceção de atraso. Esta é outra maneira do
atacante ganhar tempo para uma intervenção maldosa num dispositivo de campo.
alert
tcp
$MODBUS_SERVER
502
->
$MODBUS_CLIENT
any
(flow:established; content:"|05|"; offset:8; depth:1; byte_test:
1,
>,
0x80,
7;
msg:"Modbus
TCP
-
Acknowledge
Exception
Code
Delay"; threshold: type threshold, track by_src, count 3, seconds
60; priority:2;)
k) Tamanho de pacote incorreto, possível ataque de negação de serviço
Os quinto e sexto bytes de um cabeçalho MBAP informam o tamanho do pacote
Modbus/TCP. Um atacante pode inserir ou remover código malicioso em um pacote
Modbus/TCP e esquecer de alterar ou alterar incorretamente estes dois campos do
cabeçalho. Este alerta permite então identificar este possível ataque.
88
alert
tcp
$MODBUS_SERVER
502
<>
$MODBUS_CLIENT
any
(flow:established; byte_jump:2,4; isdataat:0,relative; msg:"Modbus
TCP - Incorrect Packet Length, Possible DOS Attack"; priority:2;)
A implementação deste ataque não é tão simples pela necessidade de interceptação dos
pacotes e remontagem em tempo real.
Analisando estes alertas, pode-se notar facilmente, que os maiores perigos para uma
rede industrial, estão localizados internamente à rede, ao contrário do que se imagina
atualmente. A maioria destes ataques são simples de serem implementados, pois é
possível encontrar vários programas de simulação de um cliente Modbus na Internet.
Uma pessoa que tenha acesso físico ou lógico à rede, de posse de um programa como
este, poderia facilmente executar a maioria dos ataques descritos acima. Um “firewall”
nestes casos, pouco poderia fazer para evitá-los.
Outra importante questão que se deve levar em conta, quando se trata de um ambiente
de automação industrial, são os falsos positivos gerados na maioria dos casos. Alguns
comandos realmente podem ser utilizados por aplicações ou por técnicos em algumas
ocasiões. Por isso é importante que se tenha um profundo conhecimento da rede e do
conteúdo de seu tráfego, para que, ao se receber uma mensagem de alerta do Snort,
tenha-se condições de se verificar a mensagem e identificar rapidamente que se trata de
um falso positivo ou não.
É importante também, que os vários procedimentos que interferem no funcionamento
dos dispositivos e da própria rede de automação, estejam bem explicitados e definidos
numa política de segurança específica para o ambiente de automação industrial. Estes
procedimentos, estando bem definidos, irão inibir a maioria dos falsos positivos e dar
maior credibilidade aos alertas gerados pelo Snort. Um exemplo claro seria um item
definindo que para a adição de qualquer novo dispositivo à rede, seja necessário que o
gerente da rede inclua o endereço IP do dispositivo na variável do arquivo de
configuração do Snort antes que o mesmo fosse posto em operação. Isso evitaria a
geração de alertas de leitura e escrita de dispositivo não autorizado aos dispositivos
servidores.
89
5.2.2 Instalação e configuração dos simuladores
Instalação e configuração do simulador servidor
Para a simulação do dispositivo servidor foi utilizado o software mod_rssim
desenvolvido e disponibilizado por Conrad Braam. Este simulador suporta os protocolos
Modbus RTU (ou Modbus serial), Modbus TCP e também Allen-Bradley serial DF1.
Este software simula o funcionamento de um CLP, disponibilizando registros de saída e
de entrada a um dispositivo cliente. Estes registros são classificados em: entradas
discretas, bobinas, registros de saída e registros de entrada.
Figura 36 – Simulador Cliente Modbus.
90
Instalação e configuração do simulador cliente
Para a simulação do dispositivo cliente, foi utilizado o programa “modpoll” (versão
para Windows).
Para executar o programa, é necessário passar algumas informações inseridas no próprio
“prompt” do “cmd”, como o tipo de transação (TCP ou serial) e o número IP do
dispositivo remoto. O comando para execução do programa é:
# modpoll –m tcp <número do ip>
No comando acima, ‘-m tcp’ indica uma transação com o protocolo Modbus/TCP.
Algumas outras opções podem ser passadas na linha de comando, como o número de
valores a serem coletados, o endereço do dispositivo escravo, a porta de comunicação (o
padrão é a 502) e outros mais.
# modpoll –m tcp –a 2 –c 100 –p 1024 <número do ip>
Figura 37 – “Pooling” de dados.
91
5.3 Teste do ambiente
Como descrito anteriormente, o Modbus é um protocolo que provê a comunicação entre
um dispositivo cliente e um dispositivo servidor, baseado na troca de mensagens entre
eles. O primeiro passo na execução dos testes é iniciar o serviço de captura de dados
pelo Snort. Isto permitirá que seja possível analisar o estabelecimento da comunicação
entre os dispositivos cliente e servidor, através do modo de registro de pacotes do Snort.
O Snort é inicializado com o seguinte comando:
# Snort -d -l -h 192.123.198.100 -c Snort.conf
O Segundo passo na execução dos testes é o estabelecimento da comunicação entre os
dois dispositivos, que neste trabalho são os programas Mod_rssim e Modpoll, servidor e
cliente respectivamente. O programa Mod_rssim é simplesmente iniciado pela execução
do arquivo mod_rssim.exe, disponibilizado para este trabalho. Após da inicialização do
servidor é inicializado o cliente, pela execução do comando abaixo:
# modpoll –m tcp 192.123.198.100
A execução deste comando faz com que uma série de requisições sejam enviadas ao
dispositivo servidor de um em um segundo. Este procedimento também é referido como
“pooling” de dados. O tipo de dados padrão requisitados neste caso são registros de
saída de 16-bits, porém, outros tipos de dados poderiam ser requisitados.
Como vimos no Capítulo 3, o Snort tem recursos que o permite funcionar como um
“farejador” de pacotes, registrador de pacotes e detector de intrusão. Os recursos de
registro de pacotes podem ser utilizados para: análise, diagnóstico e solução de
problemas de rede; análise e comparativo de desempenho; e para fins não tão nobres,
como a intromissão para obtenção de senhas e outros dados importantes. A seguir,
temos um exemplo de registro dos pacotes trocados entre os programas cliente e
servidor. Pode-se observar como se dá o estabelecimento de uma conexão TCP, a troca
de dados entre cliente e servidor Modbus e o encerramento da conexão TCP. Este
procedimento é demonstrado na figura 29 do Capítulo 4.
92
1 - Estabelecimento da conexão TCP/IP:
1.1 - O cliente, com IP 192.123.198.50, solicita uma conexão ao servidor, com o IP de
destino 192.123.198.100 na porta 502, através do gerenciador TCP. Um pacote SYN é
enviado para estabelecer a conexão.
12/02-14:25:17.405819
0:D0:C9:93:2F:38
->
0:4:38:5B:22:7
type:0x800 len:0x4A
192.123.198.50:33148
->
10.23.198.100:9191
TCP
TTL:64
TOS:0x0
ID:30003 IpLen:20 DgmLen:60 DF
******S* Seq: 0x12D90815
Ack: 0x0
Win: 0x16D0
TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 4357414 0 NOP WS: 2
Observe o valor do campo SYN J = 316213269 (0x12D90815).
1.2 - O servidor recebe o pedido de conexão e envia um pacote ACK ao cliente, para
confirmar o pacote SYN. É somado 1 (um) ao valor do campo SYN.
SYN K = 4102610487 , ACK (J + 1) = 316213270
12/02-14:25:17.406247
0:4:38:5B:22:7
->
0:D0:C9:93:2F:38
type:0x800 len:0x4E
10.23.198.100:9191
->
192.123.198.50:33148
TCP
TTL:127
TOS:0x0
ID:31244 IpLen:20 DgmLen:64 DF
***A**S* Seq: 0xF488DE37
Ack: 0x12D90816
Win: 0xFC00
TcpLen: 44
TCP Options (9) => MSS: 1460 NOP WS: 0 NOP NOP TS: 0 0 NOP NOP
TCP Options => SackOK
1.3 - Envio da confirmação de estabelecimento da conexão.
12/02-14:25:17.406268
0:D0:C9:93:2F:38
->
0:4:38:5B:22:7
type:0x800 len:0x42
192.123.198.50:33148
->
10.23.198.100:9191
TCP
TTL:64
TOS:0x0
ID:30005 IpLen:20 DgmLen:52 DF
***A**** Seq: 0x12D90816
Ack: 0xF488DE38
TCP Options (3) => NOP NOP TS: 4357414 0
Win: 0x5B4
TcpLen: 32
93
Observe o valor do campo ACK (K + 1) = 4102610487 (0xF488DE38)
2 - Envio da requisição Modbus para o servidor:
12/02-14:25:17.406685
0:D0:C9:93:2F:38
->
0:4:38:5B:22:7
type:0x800 len:0x4E
192.123.198.50:33148
->
10.23.198.100:9191
TCP
TTL:64
TOS:0x0
ID:30007 IpLen:20 DgmLen:64 DF
***AP*** Seq: 0x12D90816
Ack: 0xF488DE38
Win: 0x5B4
TcpLen: 32
TCP Options (3) => NOP NOP TS: 4357415 0
00 00 00 00 00 06 01 03 00 63 00 05
Campo
Tamanho
(bytes)
Valor
.........c..
Observação
Cabeçalho MBAP
Identificador da
transação
02
00 00
Identificador do
protocolo
02
00 00
Tamanho
02
00 06
Identificador de
unidade
01
01
Quantidade de bytes de campos
seguintes a este campo.
PDU
Código
função
de
01
03
Leitura de registros “Holding”
Sub-código
função
de
02
00 63
Endereço inicial de leitura
Quantidade
registros
requisitados
de
02
00 05
Tabela 06 – Descrição dos dados Modbus/TCP.
94
3 - Envio da resposta Modbus para o cliente:
12/02-14:25:17.408663
0:4:38:5B:22:7
->
0:D0:C9:93:2F:38
type:0x800 len:0x55
10.23.198.100:9191
->
192.123.198.50:33148
TCP
TTL:127
TOS:0x0
ID:31245 IpLen:20 DgmLen:71 DF
***AP*** Seq: 0xF488DE38
Ack: 0x12D90822
Win: 0xFBF4
TcpLen: 32
TCP Options (3) => NOP NOP TS: 1992111 4357415
00 00 00 00 00 0D 01 03 0A 00 00 00 00 00 00 00
................
00 00 00
Descrição dos dados Modbus/TCP da requisição enviada. O cabeçalho não é exibido
pois apenas o campo ‘tamanho’ é modificado:
Campo
Tamanho
(bytes)
Valor
Observação
PDU
Código
função
de
01
03
Leitura de registros “Holding”
Número de bytes
01
0A
Endereço inicial de leitura
Valor do registro
N* x 2
bytes
N* = quantidade de registros.
Tabela 07 – Descrição dos dados Modbus/TCP.
4 - Encerramento de uma conexão TCP:
4.1 - Solicitação de encerramento pelo cliente, feita pelo gerenciador TCP (FIN =
0xF6ACCD40).
12/02-15:25:31.446936
0:D0:C9:93:2F:38
->
0:4:38:5B:22:7
type:0x800 len:0x42
192.123.198.50:33295
->
10.23.198.100:9191
TCP
TTL:64
TOS:0x0
ID:16826 IpLen:20 DgmLen:52 DF
***A***F Seq: 0xF6ACCD40
Ack: 0xF8ECD843
Win: 0x597
TCP Options (3) => NOP NOP TS: 7972004 2028240
TcpLen: 32
95
4.2 - Confirmação do encerramento da conexão (ACK of FIN = 0xF6ACCD40).
12/02-15:25:31.447358
0:4:38:5B:22:7
->
0:D0:C9:93:2F:38
type:0x800 len:0x42
10.23.198.100:9191
->
192.123.198.50:33295
TCP
TTL:127
TOS:0x0
ID:1207 IpLen:20 DgmLen:52 DF
***A**** Seq: 0xF8ECD843
Ack: 0xF6ACCD41
Win: 0xFBB8
TcpLen: 32
TCP Options (3) => NOP NOP TS: 2028249 7972004
Na simulação, o Snort foi configurado de maneira que os alertas fossem enviados para o
arquivo ‘/var/log/snort/alert’ na máquina local. Estes alertas também poderiam ser
enviados, através de “sockets” ou de interrupções, para arquivos de “log” em um
servidor central de “logs”, ou mesmo armazenados em um banco de dados. Existem
também vários “plug-ins” que permitem a exibição dos alertas em uma interface gráfica
ou em uma interface “web”. Alguns programas permitem uma integração do sistema de
detecção de intrusão do Snort com uma reconfiguração do firewall para, por exemplo,
barrar um endereço de origem. Porém, como tratado no Capítulo 3, esta opção não é
muito aceita na comunidade de automação.
A seguir são demonstradas três simulações de ataques ao ambiente e os respectivos
alertas gerados pelo Snort. Os alertas gerados foram armazenados no arquivo
‘/var/log/snort/alert’. Para a realização dos ataques foi adicionada uma terceira máquina
ao ambiente de simulação (figura 38) com endereço IP 192.123.198.150 e também com
o software Modpoll instalado.
96
Figura 38 – Simulação de ataque.
1 – Requisição de leitura no servidor não autorizada:
Através do programa Modpoll foram, enviadas as requisições de leitura de dados para o
servidor Modbus. Como este endereço não estava previamente cadastrado na variável
‘MODBUS_CLIENT’, definida no arquivo ‘snort.conf’, o Snort, utilizando a regra
‘Requisição de leitura no CLP não autorizada’, identificou uma tentativa de leitura de
dados do servidor não autorizada. Esta poderia ser uma tentativa de obtenção de
informações sobre os sistemas de controle e outros dispositivos da planta industrial,
para um futuro ataque a estes sistemas.
O registro de alerta gerado, como pode ser observado a seguir, possui as informações
necessárias para a identificação do tipo do ataque e sua origem.
97
[**] [1:0:0] Modbus TCP - Unauthorized Read Request to a PLC [**]
[Priority: 0]
12/06-14:44:22.932906
0:D0:C9:77:2F:43
->
0:4:38:5B:22:7
type:0x800 len:0x4E
192.123.198.150:33044
->
10.23.198.100:502
TCP
TTL:64
TOS:0x0
ID:3377 IpLen:20 DgmLen:64 DF
***AP*** Seq: 0xCE99BD08
Ack: 0x7B39199F
Win: 0x5AA
TcpLen:
32
TCP Options (3) => NOP NOP TS: 4306908 1149471
2 – Alteração do modo de funcionamento do servidor para modo de escuta:
No segundo exemplo, a mesma máquina do exemplo anterior, enviou uma requisição de
alteração do modo de funcionamento do dispositivo servidor para o modo de escuta
apenas. Esta requisição foi comparada com a regra ‘Modo de escuta forçado’ e
identificada como um ataque.
[**] [1:0:0] Modbus TCP – Force Listen Only Mode [**]
[Priority: 1]
12/06-14:47:22.692576
0:D0:C9:77:2F:43
->
0:4:38:5B:22:7
type:0x800 len:0x4E
192.123.198.150:33045
->
10.23.198.100:502
TCP
TTL:64
TOS:0x0
ID:57389 IpLen:20 DgmLen:64 DF
***AP*** Seq: 0xD924E147
Ack: 0x5DAED502
Win: 0x571
TcpLen:
32
TCP Options (3) => NOP NOP TS: 4486695 1151268
Como descrito anteriormente, este ataque pode ser conduzido por qualquer atacante que
tenha um IP válido na rede e que tenha um programa simulador de cliente Modbus a
todos os CLP’s desta rede. Pode-se considerar este ataque como um ataque de negação
de serviço. O CLP não responderá mais a nenhuma requisição de outro dispositivo
cliente da rede.
98
3 – Requisição de escrita não autorizada no servidor:
Para este ataque, foi necessário instalar na máquina de origem dos ataques uma versão
de demonstração do software SCADA iFIX7 . Esta versão do software possui a limitação
de funcionar apenas durante o período de duas horas. Neste software foi desenvolvida
uma aplicação com um campo de entrada de dados (figura 39) que permite escrever um
valor decimal e solicitar sua escrita na área de memória do dispositivo servidor.
Figura 39 – Escrita de dados no servidor.
Como vimos no Capítulo 2, as aplicações SCADA, bem como os SDCD’s e
Supervisórios, são capazes de enviar requisições de escrita aos dispositivos de controle
como forma de intervir no controle do processo industrial, como alterar o set-point de
um controlador, o valor de abertura de uma válvula de controle ou o status de
funcionamento de um motor elétrico, ligado ou desligado.
Este ataque é detectado pelo IDS devido ao IP de origem da requisição não estar
cadastrado na variável MODBUS_CLIENT e possuir um conteúdo que indica o código
de função para requisição de escrita no servidor.
7
- http://www.gefanuc.com/en/ProductServices/AutomationSoftware/Hmi_Scada/iFIX/index.html
99
Registro de alerta gerado pelo Snort:
[**] [1:0:0] Modbus TCP – Unauthorized Write Request to a PLC
[**]
[Priority: 1]
10/07-11:33:16.542689
0:D0:C9:77:2F:43
->
0:4:38:5B:22:7
type:0x800 len:0x4E
192.123.198.150:33045
->
10.23.198.100:502
TCP
TTL:64
TOS:0x0
ID:33485 IpLen:20 DgmLen:64 DF
***AP*** Seq: 0xE934A127
Ack: 0x5FEDD301
Win: 0x571
TcpLen:
32
TCP Options (3) => NOP NOP TS: 6686773 3254376
5.4 Análise dos testes
Os testes realizados com o Snort em uma rede utilizando o Modbus/TCP permitiram
verificar a geração dos registros e “logs” de alerta, com informações úteis na detecção
dos ataques e no reconhecimento das vulnerabilidades existentes nos sistemas de
automação. As três tentativas de ataques identificadas: requisição de leitura no CLP não
autorizada, tentativa de alteração do modo de funcionamento do dispositivo servidor e
requisição de escrita não autorizada no servidor, são apenas exemplos de uma série de
ações maliciosas que podem ser detectadas utilizando IDS’s em redes de automação
industrial. Devido às limitações do software Modpoll, que possui apenas a
funcionalidade requisitar leitura de dados do dispositovo servidor, não foi possível a
simulação de outros ataques para verificação das demais regras demonstradas neste
capítulo.
Outras regras específicas para o Modbus/TCP, ou para o protocolo industrial em
questão, deverão ser desenvolvidas durante o ciclo de vida de um sistema de controle
industrial. Isto à medida que novos serviços ou funcionalidades sejam acrescidos à rede.
Um IDS deve prover esta funcionalidade de adaptação ao sistema de controle.
Este trabalho foi desenvolvido utilizando o Snort como IDS , porém, outros sistemas de
detecção podem ser utilizados, desde que tenham a funcionalidade de adaptar suas
regras, para os protocolos específicos de automação industrial.
100
6 Conclusão
Este trabalho permitiu demonstrar os ganhos com a implantação de um IDS num
segmento nível 2 de uma rede de automação industrial, com regras específicas para
protocolos desta rede, como é o caso do Modbus/TCP, sendo uma importante ação para
aumentar a segurança dos processos industriais.
Através dos testes realizados, foi possível verificar a geração dos registros e “logs” de
alerta, informações úteis na detecção dos ataques e no reconhecimento das
vulnerabilidades existentes nos sistemas de automação. Isto permitiu, por exemplo, a
identificação de acessos não autorizados ao PLC, a tentativa de forçar a atualização das
entradas e saídas para o modo de escuta apenas e a tentativa de escrita não autorizada no
CLP. Ataques que seriam críticos à segurança dos processos industriais. Devido ao
curto período de tempo para desenvolvimento deste trabalho não foi possível a geração
de mais ataques. Como abordado no Capítulo 5, o software Modpoll tem a limitação de
apenas enviar requisições de leitura ao servidor. Novos testes poderão ser realizados
através de aplicativos clientes desenvolvidos com a funcionalidade de permitir gerar
pacotes de dados com conteúdos que sejam identificados como ataques.
Observou-se durante os testes o funcionamento do protocolo Modbus: como se dá o
estabelecimento de uma conexão TCP, a troca de dados entre cliente e servidor Modbus
e o encerramento da conexão TCP. Esta funcionalidade da ferramenta IDS pode ser
utilizada pelos administradores da rede industrial em auditorias, para análises de
problemas e no estudo dos protocolos trafegados.
Esta é uma recente área de estudo que pode ser bastante explorada, uma vez que as
empresas de segurança da informação do mercado ainda não têm o domínio necessário
sobre os protocolos de rede de automação industrial. Do mesmo modo que foram
desenvolvidas regras específicas para o Modbus/TCP, podem ser desenvolvidas regras
para todos os protocolos de redes industriais Ethernet, bem como para os protocolos
industriais de redes não IP.
Outra possibilidade de trabalho futuro seria o desenvolvimento de um sistema
centralizado de gerenciamento das informações disponibilizadas nos IDS’s dos vários
101
segmentos de rede. Isto permitiria uma redução nos recursos de gerenciamento da rede,
devido a grande variedade de protocolos industriais e de aplicações nas indústrias.
Trabalhos futuros podem abordar o desenvolvimento de módulos que forneçam
informações da origem do ataque, de como ele foi detectado e das possíveis ações a
serem tomadas, para auxiliar o operador no processo de tomada de decisão a partir de
uma informação fornecida por um IDS.
102
Referências Bibliográficas
[1]
ANDREW S. TANENBAUN. Redes de Computadores. Rio de Janeiro: Editora
Campus, 2003.
[2]
SEGURANÇA Máxima: o guia de um hacker para proteger seu site na
internet e sua rede. Rio de Janeiro: Editora Campus, 2000.
[3]
CARTILHA de Segurança para Internet – Parte I: Conceitos de Segurança.
NIC BR Security Office. Disponível em: <http://www.nbso.nic.br/docs/cartilha/>.
Acesso em: 20 out. 2004.
[4]
CARTILHA de Segurança para Internet – Parte VII: Incidentes de Segurança
e Uso abusivo da Rede. NIC BR Security Office. Disponível em:
<http://www.nbso.nic.br/docs/cartilha/>. Acesso em: 20 out. 2004.
[5]
CHRIS GREEN, MARTIN ROESCH. Snort user manual 2.3.3. Disponível em:
<www.snort.org/docs/snort_manual/> , 2005. Acesso em: 15 set. 2005.
[6]
CONSTANTINO SEIXAS FILHO. A automação nos anos 2000: uma análise das
novas
fronteiras
da
automação.
Disponível
em:
<http://www.las.pucpr.br/mcfmello/ias2/ArtigosLivros/AutomacaoAnos2000ConstantinoUFMG.pdf >. Acesso em: 11 mar. 2004.
[7]
CONSTANTINO SEIXAS FILHO. Tutorial ISA S-99 – Segurança da
Informação. Revista InTech, São Paulo, n. 71, p. 14-18, 2005.
[8]
EGÍDIO ALBERTO BEGA et al. Instrumentação Industrial. Rio de Janeiro:
Editora Interciência, 2003.
[9]
ENTERPRISE-Control System Integration Part I: Models and Terminology.
Technical Report, ISA-TR99.00.01-2004.
[10]
FRANK
NED.
Ferramentas
de
IDS.
Disponível
<www.rnp.br/newsgen/9909/ids.html>. Acesso em: 12 nov. 2005.
[11]
GARY SEVOUNTS. Preocupações crescentes quanto à segurança de rede.
Disponível
em:
<www.symantec.com/region/br/enterprisesecurity/content/government/>. Acesso
em: 23 dez. 2004.
[12]
J. KIM. An artificial immune system for network intrusion detection.
Disponível
em:
<http://www.cs.ucl.ac.uk/staff/J.Kim/GECCO_WS99.html>.
Acesso em: 12 nov. 2005.
[13]
JAY BEALE; JAMES C. FOSTER; JEFFREY POSLUNS. Snort 2.0 Sistema de
Detecção de Intrusão. Rio de Janeiro: Editora Campus, 2003.
em:
103
[14]
LAURIE ZIRKLE; VIRGINIA TECH. What is host-based intrusion detection?
Disponível em: <http://www.sans.org/resources/idfaq/host_based.php>>. Acesso
em: 12 nov. 2005.
[15]
M. CRAYMER; J. CANNADY; J. HARREL. New Methods of Intrusion
Detection using Control-Loop Measurement. In: Fourth Technology for
Information Security Conference. Maio, 1996.
[16]
M.
PRABHACKER.
Intrusion
Detection.
Disponível
em:
<http://www.cs,wright.edu/~pmateti/Courses/499/IntrusionDetection/>. Acesso em:
12 nov. 2005.
[17]
MARCOS DE OLIVEIRA FONSECA. Comunicação OPC – Uma abordagem
prática. In: VI Seminário de Automação de Processos, Associação Brasileira de
Metalurgia e Materiais, 2002, Vitória.
[18]
MODBUS application protocol specification
<www.modbus.ogr>. Acesso em: 17 out. 2005.
[19]
MODBUS Messaging on TCP/IP implementation guide V1.0a. Disponível em:
<www.modbus.ogr>. Acesso em: 17 out. 2005.
[20]
MODBUS over serial line specification and implementation guide V1.0.
Disponível em: <www.modbus.ogr>. Acesso em: 17 out. 2005.
[21]
OSKAR ANDREASSON. Iptables Tutorial 1.2.0. Disponível em: <http://iptablestutorial.frozentux.net/iptables-tutorial.html>. Acesso em: 03 jul. 2005.
[22]
PAUL ZONNEVELD. DOE tackles security for petroleum industry SCADA
networks. Upstream CIO, Setembro, 2004.
[23]
PAULO SÉRGIO MOTTA PIRES; LUIZ AFFONSO GUEDES DE OLIVEIRA;
DIOGO NASCIMENTO BARROS. Aspectos de segurança em sistemas SCADA
uma visão geral. 4°. Congresso Internacional de Automação, Sistemas e
Instrumentação. São Paulo, 2004.
[24]
Profibus – Technology and Application. Disponível em:
<http://www.profibus.com/pall/meta/downloads/article/00454/>. Acesso em: 10
jan. 2006.
[25]
RICKY M. MAGALHAES. “Host-Based vs Network-Based IDS”. Disponível
em: <http://www.windowsecurity.com/articles>. Acesso em: 02 dez. 2005.
[26]
ROGÉRIO DE SOUZA DA MATA. Uma visão atual sobre sistemas
heterogêneos na Automação Industrial. Revista Mecatrônica Atual, São Paulo,
ano 04, num. 21, p. 14, 2005.
[27]
ROMILLY BOWDEN. Hart Technical Overview. Disponível em:
<http://www.romilly.co.uk/booklet.htm>. Acesso em: 11 jan. 2006.
V1.1a.
Disponível
em:
104
[28]
SÉRGIO FREITAS. Apostila do Curso de Segurança em Redes. Disponível em:
<http://sergio.inf.ufes.br/cursos/Seguranca/2005>. Acesso em: 12 nov. 2005.
[29]
STEPHEN NORTHCUTT. What is network based intrusion detection?
Disponível em: <http://www.sans.org/resources/idfaq/network_based.php>. Acesso
em:12 nov. 2005.
[30]
THOMAS H. PTACEK; TIMOTHY N. NEWSHAM. Insertion, Evasion, and
Denial
of
Service:
Eluding
Network
Intrusion
Detection.
<http://www.snort.org/docs/idspaper/>. Acesso em: 17 nov. 2005.
[31]
W. LEE; S. SOLFO. “Data Mining Approaches for Intrusion Detection”. In:
Proceeding of the 7th USENIX Security Symposium. 1998.
[32]
FIELDBUS Tutorial. Disponível em: <http://www.smar.com/brasil/fieldbus.asp>.
Acesso em: 20 mar. 2006.