UNIVERSIDADE DO RIO GRANDE DO NORTE FEDERAL

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

CENTRO DE TECNOLOGIA
PROGRAMA DE PS-GRADUAO EM ENGENHARIA ELTRICA E
DE COMPUTAO
Uma Ferramenta de Manipulao de Pacotes
para Anlise de Protocolos de Redes Industriais
Baseados em TCP/IP
Tiago Hiroshi Kobayashi
Orientador: Prof. Dr. Paulo Srgio da Motta Pires
Dissertao de Mestrado apresentada ao
Programa de Ps-Graduao em Engenharia
Eltrica e de Computao da UFRN (rea de
concentrao: Engenharia de Computao)
como parte dos requisitos para obteno do
ttulo de Mestre em Cincias.
Nmero de ordem PPgEE: M236
Natal, RN, julho de 2009
Uma Ferramenta de Manipulao de Pacotes
para Anlise de Protocolos de Redes Industriais
Baseados em TCP/IP
Tiago Hiroshi Kobayashi
Dissertao de Mestrado aprovada em 07 de julho de 2009 pela banca examinadora com-
posta pelos seguintes membros:
Prof. Dr. Paulo Srgio da Motta Pires (orientador) . . . . . . . . . . . . . . DCA/UFRN
Prof. Dr. Jos Srgio da Rocha Neto (examinador externo) . . . . . . . DEE/UFCG
Prof. Dr. Agostinho de Medeiros Brito Jnior . . . . . . . . . . . . . . . . . . DCA/UFRN
Prof. Dr. Jorge Dantas de Melo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DCA/UFRN
Diviso de Servios Tcnicos
Catalogao da publicao na fonte. UFRN / Biblioteca Central Zila Mamede
Kobayashi, Tiago Hiroshi.
Uma ferramenta de manipulao de pacotes para anlise de protocolos de
redes industriais baseados em TCP/IP / Tiago Hiroshi Kobayashi - Natal, RN,
2009
59 f. : il.
Orientador: Paulo Srgio da Motta Pires
Dissertao (Mestrado) - Universidade Federal do Rio Grande do Norte. Cen-
tro de Tecnologia. Programa de Ps-Graduao em Engenharia Eltrica e de
Computao.
1. Protocolos industriais - Dissertao. 2. Redes industriais - segurana -
Dissertao. 3. Modbus/TCP (Protocolo) - Dissertao. I. Pires, Paulo Srgio da
Motta. II. Universidade Federal do Rio Grande do Norte. III. Ttulo.
RN/UF/BCZM CDU 004.057.4:65(043.3)
Aos meus pais, Eliana e Osamu,
pela educao e apoio prestados
durante minha vida.
Agradecimentos
A minha namorada, agradeo o auxlio prestado no decorrer da dissertao e dos anos que
convivemos.
Aos amigos, que contriburam, direta ou indiretamente, para minha formao como pes-
soa e como prossional gostaria de ressaltar um agradecimento.
Ao Prof. Agostinho, que fez consideraes relevantes para o desenvolvimento dessa dis-
sertao.
Ao meu orientador, Prof. Paulo Motta, sou grato por contribuir e engrandecer essa disser-
tao.
Ao LabSIN(Laboratrio de Segurana da Informao), atravs do projeto Petrobrs-SERI
(Segurana de Redes Industriais), agradeo por fornecerem recursos essenciais ao desen-
volvimento desta dissertao.
Resumo
Neste trabalho apresentada uma ferramenta de manipulao de pacotes destinada
realizao de testes em dispositivos que implementam protocolos de comunicao basea-
dos em TCP/IP utilizados em redes industriais. A ferramenta foi desenvolvida em lingua-
gem de programao Python, como uma extenso ao Scapy. Esta ferramenta, denominada
IndPM - Industrial Packet Manipulator, permite testar os dispositivos presentes em re-
des industriais em relao a possveis vulnerabilidades, realizar testes de conformidade
de protocolos, coletar respostas de servidores existentes nas redes e utilizar os recursos
do interpretador Python para compor testes. Como prova de conceito, foi implementado
o protocolo Modbus/TCP. O protocolo DNP3 sobre TCP tambm foi implementado, mas
no foi testado por indisponibilidade de recursos. Os resultados dos testes obtidos com a
manipulao de pacotes Modbus/TCP mostram falhas de implementao em um mdulo
de comunicao para um Controlador Lgico Programvel bastante utilizado na indstria.
Palavras-chave: Segurana em Redes Industriais, Segurana em Infraestrutura Cr-
tica, Testes de Conformidade de Protocolos Industriais, Modbus/TCP, DNP3 sobre TCP.
Abstract
This work presents a packet manipulation tool developed to realize tests in industrial
devices that implements TCP/IP-based communication protocols. The tool was developed
in Python programming language, as a Scapy extension. This tool, named IndPM- Indus-
trial Packet Manipulator, can realize vulnerability tests in devices of industrial networks,
industrial protocol compliance tests, receive server replies and utilize the Python interpre-
ter to build tests. The Modbus/TCP protocol was implemented as proof-of-concept. The
DNP3 over TCP protocol was also implemented but tests could not be realized because of
the lack of resources. The IndPM results with Modbus/TCP protocol show some imple-
mentation faults in a Programmable Logic Controller communication module frequently
utilized in automation companies.
Keywords: Industrial Network Security, Critical Infrastructure Security, Industrial
Protocols Compliance Tests, Modbus/TCP, DNP3 over TCP.
Sumrio
Sumrio i
Lista de Figuras iii
Lista de Tabelas v
Lista de Smbolos e Abreviaturas vii
1 Introduo 1
1.1 Manipulao de Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Organizao da Dissertao . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 O Protocolo Modbus 5
2.1 Modbus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Modos de Comunicao Serial e Formato dos Pacotes . . . . . . 5
2.1.2 Funes do Modbus . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3 Modbus/TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Implementao 11
3.1 Descrio do Scapy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Arquitetura do IndPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1 Mdulo Modbus/TCP . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.2 Interface Grca . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4 Testes Realizados 17
4.1 Ambientes de Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Metodologia e Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.1 Testes de Conformidades . . . . . . . . . . . . . . . . . . . . . . 18
4.2.2 Teste de Segurana . . . . . . . . . . . . . . . . . . . . . . . . . 28
5 Concluses 31
Referncias Bibliogrcas 32
A DNP3 sobre TCP 35
A.1 DNP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
A.2 Mdulo DNP3 sobre TCP do IndPM . . . . . . . . . . . . . . . . . . . . 36
i
B Publicaes 39
Lista de Figuras
1.1 Modelo de quatro camadas TCP/IP. . . . . . . . . . . . . . . . . . . . . . 1
1.2 Exemplo de uma rede de automao. . . . . . . . . . . . . . . . . . . . . 2
1.3 Exemplo de manipulao de pacotes utilizando o Scapy. . . . . . . . . . 4
2.1 Formato do Pacote RTU. . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Formato do pacote ASCII. . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Fluxograma para pacotes Modbus com cdigo de funo igual a 1. . . . . 8
2.4 Pacote Modbus/TCP e encapsulamento dentro de um segmento TCP. . . . 9
2.5 Contedo de um pacote Modbus/TCP. . . . . . . . . . . . . . . . . . . . 9
3.1 Arquitetura do IndPM. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Exemplo de utilizao do Mdulo Modbus/TCP do IndPM. . . . . . . . 14
3.3 Tela da interface da manipulao de pacotes do protocolo Modbus/TCP. . 15
4.1 Ambientes de testes utilizados. . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Teste realizado com pacote contendo o cdigo de funo igual a 1 e quan-
tidade de registradores igual a 0. . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Teste realizado com pacote contendo o cdigo de funo igual a 1 e quan-
tidade de registradores maior que 2000. . . . . . . . . . . . . . . . . . . 19
4.4 Teste realizado com pacote contendo o cdigo de funo igual a 2 e quan-
tidade de registradores igual a 0. . . . . . . . . . . . . . . . . . . . . . . 20
4.5 Teste realizado com pacote contendo o cdigo de funo igual a 3 e quan-
tidade de registradores igual a 0. . . . . . . . . . . . . . . . . . . . . . . 20
4.6 Teste realizado com pacote contendo o cdigo de funo igual a 4 e quan-
tidade de registradores igual a 0. . . . . . . . . . . . . . . . . . . . . . . 21
4.7 Teste realizado com pacote contendo o cdigo de funo igual a 15 e
quantidade de registradores igual a 0. . . . . . . . . . . . . . . . . . . . . 21
4.8 Teste realizado com pacote contendo o cdigo de funo igual a 16 e
quantidade de registradores maior que 120. . . . . . . . . . . . . . . . . 22
4.9 Teste realizado com pacote contendo o cdigo de funo igual a 23 e
quantidade de registradores leitura igual a 0. . . . . . . . . . . . . . . . . 22
4.10 Teste realizado com pacote contendo o cdigo de funo igual a 23 e
quantidade de registradores de escrita igual a 0. . . . . . . . . . . . . . . 22
4.11 Teste realizado com pacote contendo o cdigo de funo igual a 2 e quan-
tidade de registradores maior que 2000. . . . . . . . . . . . . . . . . . . 23
4.12 Teste realizado com pacote contendo o cdigo de funo igual a 3 e quan-
tidade de registradores maior que 125. . . . . . . . . . . . . . . . . . . . 23
iii
4.13 Teste realizado com pacote contendo o cdigo de funo igual a 4 e quan-
tidade de registradores maior que 125. . . . . . . . . . . . . . . . . . . . 24
4.14 Teste realizado com pacote contendo o cdigo de funo igual a 3 e a
soma do endereo inicial e a quantidade de registradores maior que 10.000. 24
4.15 Teste realizado com pacote contendo o cdigo de funo igual a 4 e a
soma do endereo inicial e a quantidade de registradores maior que 10.000. 24
4.16 Teste realizado com pacote contendo o cdigo de funo igual a 6 e o
endereo inicial maior que 10.000. . . . . . . . . . . . . . . . . . . . . . 25
4.17 Teste realizado com pacote contendo o cdigo de funo igual a 15 e a
quantidade de sadas maior que 800. . . . . . . . . . . . . . . . . . . . . 25
4.18 Teste realizado com pacote contendo o cdigo de funo igual a 16 e a
soma do endereo inicial e a quantidade de registradores maior que 10.000. 26
4.19 Teste realizado com pacote contendo o cdigo de funo igual a 22 e o
endereo inicial maior que 10.000. . . . . . . . . . . . . . . . . . . . . . 27
4.20 Teste realizado com pacote contendo o cdigo de funo igual a 23 e a
soma do endereo inicial e a quantidade de registradores de leitura maior
que 10.000. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.21 Teste realizado com pacote contendo o cdigo de funo igual a 23 e a
soma do endereo inicial e a quantidade de registradores de escrita maior
que 10.000. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.22 Teste realizado com pacote contendo o cdigo de funo igual a 7. . . . . 28
4.23 Teste realizado com pacote contendo o cdigo de funo igual a 8 e sub-
funo igual a 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.24 Teste realizado com pacote contendo o cdigo de funo igual a 8 e sub-
funo igual a 65.5353. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.25 Trfego entre o mdulo do CLP e o IndPM. . . . . . . . . . . . . . . . . 29
4.26 Monitoramento do mdulo Modbus/TCP. . . . . . . . . . . . . . . . . . 30
A.1 Encapsulamento do DNP3 sobre TCP. . . . . . . . . . . . . . . . . . . . 36
A.2 Tela da interface da manipulao de pacotes do protocolo DNP3 sobre TCP. 37
Lista de Tabelas
2.1 Principais funes especicadas no protocolo Modbus. . . . . . . . . . . 7
v
Lista de Smbolos e Abreviaturas
APCI: Application Control Protocol Information
ASCII: American Standard Code for Information Interchange
CLP: Controlador Lgico Programvel
CR: Carriage Return
CRC: Cyclic Redundancy Check
DoS: Denial of Service
GPL: General Public License
GTK: GIMP ToolKit
IP: Internet Protocol
LF: Line Feed
LRC: Longitudinal Redundancy Check
RTU: Remote Terminal Unit
SCADA: Supervisory Control And Data Acquisition
TA: Tecnologia de Automao
TCP/IP: Transmission Control Protocol/Internet Protocol
TCP: Transmission Control Protocol
XML: eXtensible Markup Language
vii
Captulo 1
Introduo
A comunicao entre dispositivos interligados em rede, geralmente, feita utilizando-
se protocolos enquadrados em modelos multinveis. Um desses modelos, apresentado na
Figura 1.1, chamado de pilha TCP/IP (Transmission Control Protocol/Internet Proto-
col)[Stevens 2001]. O modelo composto por quatro camadas: Enlace, Internet (Rede),
Transporte e Aplicao. Este modelo de comunicao entre dispositivos ser utilizado no
decorrer dessa dissertao.
Figura 1.1: Modelo de quatro camadas TCP/IP.
As redes industriais ou redes de automao possuem protocolos de comunicao es-
peccos com os quais os dispositivos trocam informaes. Essas redes so compostas
por diversos dispositivos, sendo comum encontrar os Controladores Lgicos Program-
veis (CLPs) e os dispositivos sensores e/ou atuadores. Os sensores so responsveis por
adquirir informaes, como temperatura, presso ou vazo, e envi-las ao CLP. Os atua-
dores possuem a funo de modicar os estados dos dispositivos que atuam diretamente
em um processo, como vlvulas ou motores. Os CLPs, por sua vez, so dispositivos im-
portantes num sistema de controle, uma vez que so responsveis por controlar o processo
2 CAPTULO 1. INTRODUO
atravs do recebimento de informaes dos sensores e do envio de comandos/aes para
os atuadores. Estes dispositivos constituem os nveis mais baixos das redes de automa-
o [Sauter 2005, Lobashov & Sauter 2006], sendo ilustrados na Figura 1.2.
Figura 1.2: Exemplo de uma rede de automao.
Os vrios nveis das redes industriais utilizam protocolos de comunicao diversi-
cados, sendo alguns destes baseados na pilha TCP/IP. Esses protocolos so utilizados
para permitir a interconexo entre os dispositivos da rede, que facilita a troca de infor-
maes entre esses dispositivos. Esta interconexo pode trazer desvantagem tambm,
sendo necessrio analisar mecanismos de segurana dessas informaes, que podem ser
transmitidas atravs de meios no conveis [Bailey & Wright 2003].
Os ataques s redes de automao possuem motivaes e implicaes semelhantes
a qualquer ao maliciosa que ocorre em outros sistemas computacionais. Os aspectos
chaves utilizados para garantir a segurana da informao, como integridade, disponibi-
lidade, condencialidade e autenticidade, tambm so considerados em estudos na rea
de segurana das redes industriais. Um destes trabalhos [Shifet 2004] apresenta uma ta-
xonomia para os sistemas de controle levando em considerao as peculiaridades desses
aspectos chaves de segurana existentes nos ambientes de tecnologia de automao (TA).
Um exemplo destas particularidades seria o aspecto da disponibilidade da informao.
No caso de sistemas de controle, a disponibilidade pode ser de extrema importncia para
o funcionamento normal de um sistema.
As vulnerabilidades existentes nas redes de automao tambm podem ocorrer no n-
vel de arquitetura, devido utilizao de sistemas antigos (legados). Muitos dos sistemas
antigos foram desenvolvidos sem preocupao com aspectos de segurana e com poucos
testes de segurana comprovados [Shifet 2004].
As possibilidades de insero de vulnerabilidades podem ser expandidas com a inter-
conexo das redes corporativas e redes industriais [Pires & Oliveira 2006]. Esta interco-
1.1. MANIPULAO DE PACOTES 3
nexo modica a arquitetura dos sistemas de controle, interligando diferentes sistemas e
dispositivos computacionais s redes de automao. Assim, importante denir alguns
aspectos relativos segurana, para que se possam obter as vantagens da interconexo
entre as redes.
Os protocolos de comunicao das redes industriais que so baseados na pilha TCP/IP
so comumente utilizados na comunicao entre CLPs e sistemas SCADA (Supervisory
Control And Data Acquisition) (Nvel de controle, na Figura 1.2). Como os protocolos
podem apresentar vulnerabilidades [Byres et al. 2006, Mander et al. 2007, Grzelak 2008],
importante analis-los com o objetivo de identicar essas vulnerabilidades, evitando que
problemas de segurana possam ocorrer quando de suas utilizaes.
Na Seo 1.1, apresenta-se a utilizao de manipuladores de pacotes, expondo as uti-
lidades deste tipo de ferramenta no teste de dispositivo e na anlise de protocolos. Finali-
zando este captulo, tem-se a organizao desta dissertao na Seo 1.2.
1.1 Manipulao de Pacotes
Os programas manipuladores de pacotes tm como principal objetivo construir paco-
tes modicando o contedo de seus campos, de acordo com a necessidade do usurio. Um
exemplo de uma ferramenta que tem essa funcionalidade em redes TCP/IP o Scapy
1
. Na
Figura 1.3, mostra-se um exemplo de manipulao utilizando o protocolo IP com o Scapy.
Neste exemplo, um datagrama IP manipulado, pela denio do campo de verso, do
endereo de origem e do endereo de destino.
Os manipuladores de pacotes podem ser utilizados com diferentes objetivos. Um
exemplo de uso de um manipulador de pacotes seria testar dispositivos de segurana,
como rewalls. As rewalls so mecanismos de defesa que impedem o acesso indevido
a uma rede ou a um sistema computacional, analisando o trfego destinado rede ou ao
sistema computacional [Tanenbaum 2003]. Outra utilizao de manipuladores de pacotes
na realizao de testes de conformidades de dispositivos em relao implementao
de determinado protocolo.
O objetivo neste trabalho apresentar uma ferramenta de manipulao de pacotes,
chamada IndPM (Industrial Packet Manipulator), mostrando os testes e resultados que
podem ser obtidos com este tipo de ferramenta. O IndPM permite testar os dispositivos
que implementam os protocolos industriais que tm como base a pilha TCP/IP. Como
prova de conceito, foi implementado o protocolo Modbus/TCP e foram realizados testes
em um CLP real, comumente utilizado em redes de automao que utiliza esse protocolo,
e em um emulador do protocolo Modbus/TCP.
A ferramenta tambm pode ser utilizada para coletar respostas dos dispositivos testa-
dos, criar e utilizar pacotes especcos para realizar testes de vulnerabilidades, bem como
realizar a composio de testes usando o ambiente de programao Python.
1
Scapy. http://www.secdev.org/projects/scapy/
4 CAPTULO 1. INTRODUO
Figura 1.3: Exemplo de manipulao de pacotes utilizando o Scapy.
1.2 Organizao da Dissertao
Este trabalho contm mais quatro captulos. No Captulo 2, apresenta-se o Mod-
bus/TCP, que foi implementado como prova de conceito. Sero apresentados os detalhes
necessrios para o entendimento do protocolo Modbus/TCP e sua utilizao.
No Captulo 3, so apresentados os aspectos relativos s implementaes do IndPM.
So descritos como o mdulo referente ao protocolo industrial foi implementado, bem
como a interface grca desenvolvida.
No Captulo 4, os resultados obtidos com a manipulao de pacotes realizados com
o IndPM sero apresentados. A manipulao de pacotes foi testada em dois dispositivos
diferentes, mostrando as falhas existentes nesses dispositivos.
No ltimo Captulo, apresentam-se as concluses referentes aos resultados obtidos
com a ferramenta desenvolvida e perspectivas para trabalhos futuros.
No Apndice A, apresentado o protocolo DNP3 sobre TCP e sua implementao.
Apesar de totalmente implementado na ferramenta, seu funcionamento no pode ser vali-
dado por indisponibilidade de dispositivos.
Por m, as publicaes realizadas com este trabalho esto no Apndice B.
Captulo 2
O Protocolo Modbus
Nas sees a seguir, apresentam-se alguns detalhes do protocolo industrial que foi
implementado, o Modbus/TCP. A implementao desse protocolo foi baseada na especi-
cao ([Modbus-IDA 2006a], [Modbus-IDA 2006b]).
2.1 Modbus
O protocolo Modbus baseado no paradigma de comunicao mestre-escravo, onde
o mestre o responsvel por coordenar diversos escravos. O Modbus utilizado no nvel
da camada de aplicao [Modbus-IDA 2006a] e foi inicialmente desenvolvido para ser
utilizado na comunicao dos CLPs com os sensores e os atuadores. O protocolo Mod-
bus foi desenvolvido pela Modicon Industrial Automation Systems (atualmente Schneider
Electric) nos anos 70 e recentemente tornou-se GPL (General Public License). Atual-
mente, o Modbus mantido pela Modbus-IDA que formada por um grupo de usurios
e fornecedores independentes.
2.1.1 Modos de Comunicao Serial e Formato dos Pacotes
Inicialmente, o Modbus foi desenvolvido para dispositivos que utilizavam meios de
comunicao serial. A comunicao Modbus que utiliza linhas seriais pode ser realizada
de duas formas: RTU (Remote Terminal Unit) e ASCII (American Standard Code for
Information Interchange). Esses dois modos de comunicao do Modbus possuem um
formato de pacote especco, que o mesmo para requisio ou para resposta. As formas
RTU e ASCII diferenciam-se na representao dos seus dados.
Cada pacote Modbus serial composto de seis campos que so representados por da-
dos binrios, no modo RTU, e por caracteres, no modo ASCII. Estes campos so denidos
como:
Incio: indica o comeo do pacote;
Endereo: indica qual dispositivo receber ou enviar o pacote. A faixa de ende-
reos vlidos dos dispositivos varia de 0 a 247, sendo o endereo 0 (zero) utilizado
para mensagens que so enviadas para todos os escravos;
Funo: este campo representa o objetivo do pacote;
6 CAPTULO 2. O PROTOCOLO MODBUS
Dados: campo onde os dados sero alocados. Este campo tem o seu contedo de
acordo com o campo Funo do pacote;
Controle: responsvel pela deteco de erros no pacote. Para verses que pos-
suam camadas de protocolos subjacentes que contenham mecanismos de deteco
de erros prprios, este campo dispensado;
Fim: sinaliza que a comunicao entre os dispositivos foi terminada.
No modo RTU, o campo Incio representado por um intervalo de silncio. Os cam-
pos, de Endereo e de Funo, so representados por 8 bits. O campo Dados depende
da funo utilizada e cada informao representada por 8 bits tambm, podendo conter
inmeras informaes (n) dentro de um mesmo pacote. A vericao de erro neste modo
realizada atravs do algoritmo de CRC (Cyclic Redundancy Check), sendo representado
por 16 bits. O campo Fim representado pelo mesmo contedo do campo Incio, um
intervalo de silncio.
Ocampo Incio, no modo ASCII, denido pelo caractere ":"(0x3Aemhexadecimal).
Os campos, de Endereo e de Funo, so representados por dois caracteres. O campo
Dados, no modo ASCII, representado por uma quantidade varivel (n) de caracteres. O
campo Controle representado por dois caracteres ASCII e utiliza o algoritmo de LRC
(Longitudinal Redundancy Check) para deteco de erros. O m do pacote representado
por um par de caracteres de CR (Carriage Return) e de LF (Line Feed) (0x0D e 0x0A em
hexadecimal respectivamente).
Os campos dos pacotes RTUe ASCII podemser visualizados na Figura 2.1 e na Figura
2.2, respectivamente.
Figura 2.1: Formato do Pacote RTU.
Figura 2.2: Formato do pacote ASCII.
2.1.2 Funes do Modbus
O protocolo Modbus possui algumas funes que dependem do dispositivo que im-
plementa o protocolo. As funes possuem diferentes objetivos, como a vericao da
comunicao, a visualizao da quantidade de eventos, dentre outras, sendo as mais utili-
zadas as funes de escrita e de leitura. Os dispositivos comunicam-se atravs de pacotes
2.1. MODBUS 7
de requisies e de respostas, onde os cdigos de funes para estes dois tipos de pacotes
podem ser iguais numa mesma transao.
As principais funes especicadas no protocolo Modbus, e suas descries, so mos-
tradas na Tabela 2.1. Mais detalhes das implementaes das funes podem ser obtidos
na especicao do protocolo [Modbus-IDA 2006a].
Cdigo de funo Descrio
01 Ler o estado dos registradores booleanos de sada
02 Ler o estado de entradas discretas
03 Ler o contedo de um bloco de registradores de espera
04 Ler registradores de entrada
05 Escrever em um registrador booleano de sada
06 Escrever em um registrador de espera
07 Ler o contedo de oito estados de exceo
08 Prover uma srie de testes para vericao da comunicao e
erros internos
11 Obter o contador de eventos
12 Obter um relatrio de eventos
15 Escrever em uma sequncia de sadas
16 Escrever em um bloco de registradores
17 Ler algumas informaes do dispositivo
20 Ler informaes de um arquivo
21 Escrever informaes em um arquivo
22 Modicar o contedo dos registradores de espera atravs de
operaes lgicas
23 Combina ler e escrever em registradores numa nica transao
24 Ler o contedo da la FIFO de registradores
Tabela 2.1: Principais funes especicadas no protocolo Modbus.
A especicao do protocolo dene uxogramas para cada funo, detalhando o com-
portamento de cada uma delas. Esses uxogramas apresentam como os pacotes devem
ser respondidos em cada situao. Na Figura 2.3, apresenta-se um exemplo destes uxo-
gramas, mostrando o comportamento que um dispositivo deve apresentar quando recebe
um pacote Modbus com o campo Funo igual a 1.
Algumas funes do Modbus (7, 8, 11, 12 e 17) so denidas pelo protocolo como
especcas para comunicaes realizadas em canais de comunicao seriais, no sendo
indicadas para uso em outros meios de comunicao.
2.1.3 Modbus/TCP
Com a grande utilizao e facilidade modicaes do protocolo Modbus, foram
incorporados novos meios de comunicaes como o Ethernet que utilizado pela varia-
o do protocolo, denominada Modbus/TCP. Esta variao utiliza a pilha de protocolos
TCP/IP para realizar as transaes entre os dispositivos, que contribui para uma maior
8 CAPTULO 2. O PROTOCOLO MODBUS
Figura 2.3: Fluxograma para pacotes Modbus com cdigo de funo igual a 1.
conectividade visto que permite interligar diferentes tipos de redes, compartilhando uma
mesma infra-estrutura.
Os pacotes do Modbus/TCP consistem de uma modicao do pacote Modbus tradici-
onal e do encapsulamento desse pacote em segmentos TCP, como se mostra na Figura 2.4.
O Modbus/TCP contm somente dois campos do pacote Modbus tradicional (Funo e
Dados), sendo eliminados os campos de Incio, de Endereo e de Fim que so desneces-
srios em comunicaes sobre Ethernet, realizados por protocolos especcos. O campo
de Controle tambm no est presente no Modbus/TCP porque a vericao de erros de
transmisso realizada atravs das camadas inferiores ao Modbus/TCP.
A camada do Modbus/TCP composta por um cabealho para indicar parmetros
da transmisso, um campo para indicar o cdigo de funo utilizado e um campo con-
tendo os dados que esto sendo transmitidos. Na Figura 2.5, apresentam-se esses campos
existentes em pacotes Modbus/TCP, sendo o cabealho composto pelos quatro primeiros
campos.
2.1. MODBUS 9
Figura 2.4: Pacote Modbus/TCP e encapsulamento dentro de um segmento TCP.
Figura 2.5: Contedo de um pacote Modbus/TCP.
Os quatro campos do cabealho Modbus/TCP podem ser denidos como:
Identicador de Transao: este campo, com dois bytes, identica a comunicao
entre o servidor e o cliente Modbus. Cada requisio Modbus tem sua resposta com
o mesmo identicador de transao. Para o Modbus/TCP, o nmero de requisies
que os dispositivos respondem ou requisitam depende da capacidade dos mesmos.
Este fato representa uma melhoria em relao ao Modbus tradicional que permite
apenas uma nica transao por vez.
Identicador de Protocolo: este campo, comdois bytes, utilizado para identicar
o protocolo. O Modbus especicado com valor 0 (zero).
Tamanho: este campo, com dois bytes, contm a quantidade de bytes dos campos
seguintes a ele (Identicador de Unidade, Funo e Dados).
Identicador de Unidade: este campo, com um byte, utilizado para identicar os
dispositivos Modbus que estejam interconectados na rede atravs de um gateway.
Em geral, esses gateways so utilizados para interligar dispositivos que utilizam o
barramento serial com os dispositivos da rede Ethernet.
Os outros dois campos do pacote Modbus/TCP, Funo e Dados, so semelhantes
aos campos existentes no Modbus tradicional. Eles contm o cdigo de funo e os dados
transmitidos, sendo o campo de dados determinado pelo cdigo de funo.
No prximo Captulo, ser apresentada a ferramenta desenvolvida, mostrando deta-
lhes de implementao desse protocolo e da interface grca construda.
10 CAPTULO 2. O PROTOCOLO MODBUS
Captulo 3
Implementao
Neste Captulo, sero apresentados alguns detalhes da implementao da ferramenta
desenvolvida. Inicialmente, ser apresentado o software que foi utilizado como base do
trabalho. Em seguida, ser apresentada a arquitetura do software desenvolvido e detalhes
da implementao do protocolo Modbus/TCP e da interface grca.
3.1 Descrio do Scapy
A base do nosso trabalho um manipulador de pacotes. Algumas ferramentas com
esta funcionalidade foram analisadas (Hping
1
, Nemesis
2
, PacGen
3
e Scapy
4
) e dentre
essas, optamos pela utilizao do Scapy. Os motivos da escolha do Scapy como base de
nossa implementao foram a disponibilidade do cdigo-fonte do software, a variedade
de protocolos implementados pela ferramenta bem como a facilidade para incluso de
novos protocolos e funcionalidades.
O Scapy um framework desenvolvido em Python com muitas funcionalidades, den-
tre as quais a principal a manipulao de pacotes. A ferramenta permite uma maior
interatividade em relao a outras ferramentas existentes, permitindo a manipulao de
pacotes de maneira exvel. Os pacotes podem ser construdos independentes da pilha de
protocolos, no sendo necessrio seguir a ordem existente na pilha.
O Scapy possui, ainda, outras funcionalidades como sniffer de rede, vericao de
rotas, realizao de ao maliciosa, dentre outras. A diferena do Scapy para outras
ferramentas existentes que ele no interpreta os dados recebidos, deixando essa respon-
sabilidade para o usurio do framework.
A execuo do Scapy possibilita a utilizao do interpretador Python, permitindo o
uso dos recursos dessa linguagem de programao. Desta forma, possvel combinar as
funcionalidades da ferramenta como a manipulao e a captura de pacotes com o objetivo
de realizar testes especcos.
1
Hping - Active Network Security Tool. http://www.hping.org/
2
Nemesis packet injection tool suite. http://nemesis.sourceforge.net/
3
Pacgen: Where do you want to send packets today. http://pacgen.sourceforge.net/
4
Scapy. http://www.secdev.org/projects/scapy/
12 CAPTULO 3. IMPLEMENTAO
3.2 Arquitetura do IndPM
O IndPM foi desenvolvido com o objetivo de ser um manipulador de pacotes para
protocolos industriais baseados emTCP/IP. A falta desse tipo de ferramenta foi a principal
motivao para o desenvolvimento do trabalho. Um prottipo do IndPM foi a primeira
extenso do Scapy desenvolvida para protocolos industriais [Kobayashi et al. 2007].
A ferramenta possui, atualmente, os seguintes mdulos: Scapy, Mdulo Modbus/TCP,
Mdulo DNP3 sobre TCP e a Interface Grca. Os demais mdulos de protocolos indus-
triais podem ser desenvolvidos de maneira semelhante ao Mdulo Modbus/TCP, podendo
ser incorporados ao IndPM. Um mdulo para o protocolo DNP3 sobre TCP foi desen-
volvido e est descrito no Apndice A.
Na Figura 3.1, ilustra-se a arquitetura do IndPM, apresentando a interligao entre os
mdulos e a Interface Grca, bem como a dependncia com o Scapy.
Figura 3.1: Arquitetura do IndPM.
As implementaes dos protocolos foram desenvolvidas em Python para que pudes-
sem ser utilizadas em conjunto com o Scapy. Os mdulos dos protocolos foram desenvol-
vidos de forma independente e podem ser executados sem uso da Interface Grca, que
foi desenvolvida em GTK (GIMP ToolKit)
5
. A interface grca desenvolvida serve para
visualizar e executar a manipulao de pacotes utilizando os mdulos dos protocolos.
Nas subsees a seguir, alguns detalhes da implementao desta arquitetura so apre-
sentados.
5
GTK+ project. http://www.gtk.org/
3.2. ARQUITETURA DO INDPM 13
3.2.1 Mdulo Modbus/TCP
O protocolo Modbus/TCP foi implementado com base na especicao apresentada
na Seo 2.1. Foi desenvolvido um mdulo que executado em conjunto com o Scapy,
capaz de manipular pacotes do protocolo Modbus/TCP de acordo com os parmetros que
o usurio especica. Com este mdulo, foi possvel fazer anlises de dispositivos que
implementam o Modbus/TCP [Kobayashi et al. 2007].
Este mdulo foi desenvolvido em Python com os conceitos de orientao a objetos,
onde algumas classes criadas herdam de classes existentes no Scapy. As principais classes
que o IndPM herda do Scapy so: StrField e Packet. A primeira foi usada para criao
de classes que denem alguns campos do Modbus/TCP, j a segunda foi utilizada para
construir os pacotes do protocolo.
Para cada cdigo de funo do Modbus foi denido uma classe que corresponde a um
pacote Modbus/TCP, visto que os campos existentes na rea de dados do pacote depen-
dem do cdigo de funo utilizado. Todas as classes que denem um cdigo de funo do
Modbus herdam de uma classe, denominada ModbusPDU. Esta classe determina os cam-
pos existentes em qualquer pacote do protocolo Modbus/TCP, so eles: Identicador de
Transao, Identicador de Protocolo, Tamanho, Identicador de Unidade e Fun-
o. O campo Dados o campo que varia de acordo com o cdigo de funo desejado,
no sendo includo na classe ModbusPDU.
Um exemplo da utilizao do Mdulo Modbus/TCP apresentado na Figura 3.2, onde
so manipulados pacotes com cdigo de exceo igual a 1. Para este cdigo de funo,
foi denida uma classe denominada ReadCoilRequest que quando instanciada, cria um
objeto representando um pacote Modbus/TCP contendo o respectivo cdigo de funo.
Desta maneira possvel manipular o contedo do campo Dados, denindo dentro do
atributo data, os valores para os dois campos existentes nesse cdigo de funo (address
e count).
Neste exemplo, na Figura 3.2, apresentado tambm a vantagem do Scapy em utilizar
a linguagem de programao Python para criao dos testes. Neste exemplo foi criado,
dentro de um lao, nove pacotes com cdigo de funo igual a 1 e enviados ao dispositivo
alvo. Como o Mdulo Modbus/TCP desenvolvido utilizado em conjunto com o Scapy,
ele tambm permite essa utilizao dos recursos do Python para a criao de testes.
3.2.2 Interface Grca
A Interface Grca foi desenvolvida para facilitar a manipulao de pacotes atravs
da utilizao dos mdulos que implementam os protocolos. Com a Interface Grca, o
usurio pode modicar os valores para cada campo existente nos pacotes do Modbus/TCP
presentes como botes na interface. Este procedimento elimina a necessidade do usurio
conhecer alguns detalhes das especicaes dos protocolos e dos mdulos desenvolvidos.
A interface foi desenvolvida atravs do Glade
6
, que um software usado para auxiliar
o desenvolvimento de interfaces grcas utilizando GTK. O Glade possui vrios objetos
prontos como botes, janelas, elementos de agrupamento dentre outros que facilitam o
6
Glade - a User Interface Designer for GTK+ and GNOME. http://glade.gnome.org/
14 CAPTULO 3. IMPLEMENTAO
Figura 3.2: Exemplo de utilizao do Mdulo Modbus/TCP do IndPM.
desenvolvimento de interfaces grcas. Alm disso, gera o cdigo fonte da interface
num arquivo XML (eXtensible Markup Language) que pode ser interpretado por vrias
linguagens de programao, dentre elas o Python que utilizamos para implementao dos
outros mdulos.
O mdulo da Interface Grca composto de dois arquivos: o arquivo em XML
gerado pelo Glade e o arquivo em Python contendo toda a programao da interface. O
arquivo XML contm as denies e os eventos de botes, de textos, de janelas, dentre
outros componentes presentes na interface. J o arquivo em Python responsvel por
interligar os mdulos dos protocolos com a interface, possuindo todas as denies de
eventos dos componentes existentes na mesma.
A interface grca do IndPM possui, atualmente, duas interfaces para o usurio, uma
para o protocolo Modbus/TCP e outra para o protocolo DNP3 sobre TCP (ver Apndice
A). A interface para o Modbus/TCP mostrada na Figura 3.3. Ela contm botes do tipo
SpinButton representando os possveis valores de cada campo do protocolo de acordo
com a especicao do Modbus/TCP.
Alguns botes esto agrupados com o objetivo de aumentar a facilidade de uso da
ferramenta. Como pode ser visto na Figura 3.3, existem alguns botes representando o
cabealho de um pacote Modbus/TCP. Alm do cabealho, existe outro grupo para denir
o contedo do pacote Modbus/TCP. Este grupo composto pelo campo que contm o
cdigo de funo e os dados do pacote. Dependendo do valor do campo de cdigo de
funo, o campo de dados modicado sendo visualizados os campos existentes para o
cdigo de funo selecionado.
Existe ainda na interface do Modbus/TCP do IndPM, uma rea de texto para indicar
3.2. ARQUITETURA DO INDPM 15
Figura 3.3: Tela da interface da manipulao de pacotes do protocolo Modbus/TCP.
o pacote Modbus/TCP que est sendo criado. Esta rea mostra o pacote no formato he-
xadecimal. H tambm outra rea de texto para indicar o estado da conexo, mostrando
a sada gerada pelo Scapy. Caso ocorra erros de conexo possvel identic-los nesta
rea.
A Interface Grca proporciona maior facilidade de uso para o usurio do IndPM,
sendo necessrio apenas a manipulao dos campos apresentados pela interface. Isto
abstrai o conhecimento prvio dos protocolos industriais e da implementao deles.
No Captulo seguinte, detalhes de testes realizados com o IndPM so apresentados.
16 CAPTULO 3. IMPLEMENTAO
Captulo 4
Testes Realizados
Neste Captulo, sero apresentados resultados de testes realizados com a utilizao
da ferramenta IndPM. Inicialmente, sero apresentados os ambientes utilizados para a
realizao desses testes. Em seguida, ser apresentada a metodologia utilizada nos testes
e os resultados obtidos. Todos os testes apresentados neste Captulo foram realizados no
Laboratrio de Segurana da Informao, LabSIN, do Departamento de Engenharia de
Computao e Automao da Universidade Federal do Rio Grande do Norte.
4.1 Ambientes de Testes
Em nossos testes, foram utilizados dois dispositivos diferentes como servidor Mod-
bus/TCP: um simulador e um mdulo de comunicao Modbus/TCP conectado a um CLP.
Nestas duas situaes, foram montados ambientes de testes semelhantes, interligando o
manipulador de pacotes e os servidores Modbus/TCP atravs de um switch. A Figura
4.1 mostra os dois ambientes de testes. O IndPM foi utilizado para manipular e enviar
pacotes para o mdulo de comunicao Modbus/TCP do CLP e para o simulador.
Figura 4.1: Ambientes de testes utilizados.
18 CAPTULO 4. TESTES REALIZADOS
O servidor Modbus/TCP utilizado como simulador foi o TCPSlaveTest, uma das fer-
ramentas do jamod
1
. O jamod uma biblioteca desenvolvida em Java para o protocolo
Modbus, que permite o desenvolvimento de aplicaes utilizando o protocolo. Nos testes
realizados, o TCPSlaveTest foi utilizado em sua congurao padro.
O CLP utilizado comumente encontrado em ambientes de automao, com m-
dulo de comunicao Modbus/TCP especco para este modelo de CLP. O mdulo de
comunicao Modbus/TCP atua como servidor, recebendo e respondendo s requisies
realizadas pelo IndPM.
4.2 Metodologia e Resultados
Os testes foram realizados manipulando pacotes com todas as funes do Modbus im-
plementadas pelo IndPM. Estes pacotes foram enviados para os dois dispositivos e suas
respectivas respostas foram analisadas. Essas anlises foram separadas em duas catego-
rias, testes de conformidades e teste de segurana, que so apresentadas nas subsees
seguintes.
4.2.1 Testes de Conformidades
Cada funo possui uma resposta padro descrita na especicao do protocolo Mod-
bus [Modbus-IDA 2006a]. Para os dois casos, o mdulo e o simulador, algumas respostas
so diferentes entre si, e em outros casos, as respostas so diferentes da especicao do
protocolo. Os resultados que so apresentados referem-se s respostas em discordncia
com a especicao do protocolo.
Um dos testes foi realizado usando pacotes com cdigo de funo igual a 1. Esta
funo utilizada para leitura dos estados das sadas booleanas do dispositivo. Um pacote
Modbus com este cdigo de funo possui duas informaes no campo de dados: uma
para representar o endereo inicial a ser lido e outra informando a quantidade de sadas
booleanas que devero ser lidas. Cada uma destas informaes tem uma escala de valores
e tratamento de exceo indicados pela especicao [Modbus-IDA 2006a].
Os pacotes contendo o cdigo de funo igual a 1 foram respondidos pelo mdulo de
comunicao do CLP, em discordncia com a especicao do Modbus, em dois casos.
Um dos casos, foi o envio de um pacote contendo a quantidade de sadas booleanas a
serem lidas igual a 0 e no outro caso quando esta quantidade foi um valor maior que
2000. De acordo com a especicao, estes pacotes deveriam ser respondidos com uma
exceo (pacote contendo cdigo de funo igual a 129 e cdigo de exceo igual a 3).
Para o caso do pacote contendo a quantidade de sadas booleanas igual a 0, o mdulo
Modbus/TCP respondeu normalmente a este tipo de requisio. No outro caso, o mdulo
Modbus/TCP retornou uma exceo com o campo de cdigo de exceo errado, com o
valor 2 ao invs de 3.
No teste com o simulador de Modbus/TCP, estes mesmos pacotes foram enviados
e as respostas recebidas tambm foram diferentes da especicao do protocolo. Nos
1
Java Modbus Library. http://sourceforge.net/projects/jamod
4.2. METODOLOGIA E RESULTADOS 19
dois casos, o simulador retornou excees com o campo do cdigo de exceo igual a
2, quando deveria ser igual a 3. Nas Figuras 4.2 e 4.3, so apresentados diagramas que
resumem estes testes.
Figura 4.2: Teste realizado compacote contendo o cdigo de funo igual a 1 e quantidade
de registradores igual a 0.
Figura 4.3: Teste realizado compacote contendo o cdigo de funo igual a 1 e quantidade
de registradores maior que 2000.
Alm de pacotes com cdigo de funo igual a 1, existem outros casos em que o
mdulo Modbus/TCP deveria responder determinadas requisies com uma exceo mas
responde normalmente. O simulador de Modbus/TCP, em alguns desses casos, respondeu
com cdigo de exceo errado ou no implementava a funo solicitada.
Os pacotes contendo cdigos de funo iguais a 2, a 3 e a 4, com a quantidade de re-
gistradores a serem lidos iguais a 0, deveriam ser respondidos com um pacote de exceo
e com cdigo de exceo igual a 3. Para estes casos, o mdulo Modbus/TCP respondeu
normalmente com um pacote contendo os estados dos registradores vazio. Nesses casos,
o simulador de Modbus/TCP respondeu com cdigo de exceo errado, 2 ao invs de 3.
Os diagramas que ilustram esses testes esto apresentados nas Figuras 4.4, 4.5 e 4.6.
Os testes mostram que, alm dos pacotes com cdigos de funo de leitura, alguns pa-
cotes contendo cdigos de funo de escrita, 15 e 16, tambm apresentaram discordncia
com a especicao. Os pacotes, contendo cdigo de funo igual a 15 e a quantidade de
20 CAPTULO 4. TESTES REALIZADOS
Figura 4.4: Teste realizado compacote contendo o cdigo de funo igual a 2 e quantidade
de registradores igual a 0.
Figura 4.5: Teste realizado compacote contendo o cdigo de funo igual a 3 e quantidade
de registradores igual a 0.
sadas que se deseja modicar o estado iguais a 0, foram respondidos normalmente pelo
mdulo Modbus/TCP quando deveriam ser respondidos com uma exceo com cdigo
igual a 3. Nesse caso, o simulador de Modbus/TCP respondeu com cdigo de exceo
errado, da mesma maneira que os cdigos de funo de leitura. Na Figura 4.7, est repre-
sentado este teste.
Para os pacotes com cdigo de funo igual a 16, o mdulo do Modbus/TCP respon-
deu normalmente aos pacotes contendo a quantidade de registradores, no qual se especi-
ca a modicao dos seus estados, superior ao limite denido pelo protocolo. Os testes
foram realizados com quantidade de registradores igual a 121. Nestes casos, a especi-
cao dene o limite de registradores a serem modicados, com cdigo de funo 16,
entre 0 e 120. Pacotes com valores fora desse limite deveriam ser respondidos com uma
exceo e cdigo de exceo igual a 3. Os pacotes com cdigo de funo igual a 16 no
foram respondidos pelo simulador de Modbus/TCP. O diagrama que ilustra esse teste est
4.2. METODOLOGIA E RESULTADOS 21
Figura 4.6: Teste realizado compacote contendo o cdigo de funo igual a 4 e quantidade
de registradores igual a 0.
Figura 4.7: Teste realizado com pacote contendo o cdigo de funo igual a 15 e quanti-
dade de registradores igual a 0.
representado na Figura 4.8.
Outros pacotes que foram respondidos incorretamente pelo mdulo Modbus/TCP fo-
ram os pacotes contendo cdigos de funo iguais a 23. Estes pacotes so utilizados para
ler e modicar os valores dos registradores numa nica transao. Este tipo de pacote no
foi respondido pelo simulador de Modbus/TCP. Para pacotes contendo o cdigo de fun-
o 23, o mdulo do CLP respondeu normalmente a requisies contendo a quantidade
de registradores a serem lidos ou modicados iguais a 0, quando deveria responder estas
requisies com exceo contendo o cdigo de exceo igual a 3. Nas Figuras 4.9 e 4.10,
so apresentados esses testes.
Os dispositivos testados, mdulo Modbus/TCP e simulador de Modbus/TCP, apre-
sentaram outras situaes alm das apresentadas nas Figuras 4.2 e 4.3, em que esses
dispositivos responderam com cdigo de exceo diferente do esperado. Essas situaes
ocorreram para os pacotes contendo cdigos de funo iguais a 2, a 3 e a 4, contendo a
22 CAPTULO 4. TESTES REALIZADOS
Figura 4.8: Teste realizado com pacote contendo o cdigo de funo igual a 16 e quanti-
dade de registradores maior que 120.
Figura 4.9: Teste realizado com pacote contendo o cdigo de funo igual a 23 e quanti-
dade de registradores leitura igual a 0.
Figura 4.10: Teste realizado com pacote contendo o cdigo de funo igual a 23 e quan-
tidade de registradores de escrita igual a 0.
quantidade de registradores a serem lidos fora do limite denido pela especicao.
No caso dos pacotes com cdigo de funo igual a 2, o limite especicado pelo proto-
colo para a quantidade mxima de registradores a serem lidos de 2000 registradores. Os
testes realizados com IndPM solicitando a leitura de 2001 registradores foram respondi-
4.2. METODOLOGIA E RESULTADOS 23
dos incorretamente pelos dispositivos que, ao invs de responderem com um pacote de
exceo contendo cdigo de exceo igual a 3, responderam com um pacote de exceo
com cdigo de exceo igual a 2. Esse teste est representado na Figura 4.11.
Figura 4.11: Teste realizado com pacote contendo o cdigo de funo igual a 2 e quanti-
dade de registradores maior que 2000.
Esta mesma situao ocorreu com pacotes contendo os cdigos de funo iguais a 3
e a 4, s que nesses casos o limite denido para a quantidade de registradores a serem
lidos de 125. Os testes foram realizados denindo pacotes com essa quantidade igual a
126. Esses testes de manipulao incorreta das excees por parte dos dispositivos esto
ilustrados nas Figuras 4.12 e 4.13.
Figura 4.12: Teste realizado com pacote contendo o cdigo de funo igual a 3 e quanti-
dade de registradores maior que 125.
Os testes realizados mostram, ainda, que os dispositivos testados responderam com
exceo a requisies que deveriam ser respondidas normalmente de acordo com o proto-
colo. Nas Figuras 4.14 e 4.15, so apresentados diagramas que mostram os pacotes com
cdigos de funo de leitura (3 e 4) que foram respondidos com exceo, quando deve-
riam ser respondidos normalmente. Esses pacotes foram manipulados para que a soma
do endereo inicial dos registradores a serem lidos mais a quantidade desses registradores
fosse um valor maior que 10.000. Nesses casos, o mdulo Modbus/TCP e o simulador
de Modbus/TCP responderam com uma exceo com cdigo de exceo igual a 2. Estes
tipos de pacotes deveriam ser respondidos com os valores dos registradores que foram
requisitados.
24 CAPTULO 4. TESTES REALIZADOS
Figura 4.13: Teste realizado com pacote contendo o cdigo de funo igual a 4 e quanti-
dade de registradores maior que 125.
Figura 4.14: Teste realizado com pacote contendo o cdigo de funo igual a 3 e a soma
do endereo inicial e a quantidade de registradores maior que 10.000.
Figura 4.15: Teste realizado com pacote contendo o cdigo de funo igual a 4 e a soma
do endereo inicial e a quantidade de registradores maior que 10.000.
4.2. METODOLOGIA E RESULTADOS 25
Alguns pacotes com cdigos de funo de escrita tambm apresentaram discordncia
com a especicao. Nas Figuras 4.16, 4.17 e 4.18, so apresentados os pacotes com
cdigos de funo iguais a 6, a 15 e a 16, respectivamente, que apresentaram essas dis-
cordncias. O pacote contendo cdigo de funo igual a 6 e com o endereo inicial dos
registradores a serem modicados igual a 10.001, foi respondido com um pacote de ex-
ceo contendo cdigo de exceo igual a 2 tanto pelo mdulo Modbus/TCP quanto pelo
simulador de Modbus/TCP. Estes pacotes deveriam ser respondidos com uma resposta
contendo o mesmo contedo da requisio.
Figura 4.16: Teste realizado com pacote contendo o cdigo de funo igual a 6 e o ende-
reo inicial maior que 10.000.
Figura 4.17: Teste realizado com pacote contendo o cdigo de funo igual a 15 e a
quantidade de sadas maior que 800.
Para os pacotes com cdigo de funo igual a 15, as respostas foram obtidas incorre-
tamente quando a quantidade de sadas a serem modicados tinha valor maior que 800.
Esses pacotes deveriam ser respondidos normalmente. Nesses casos, as requisies foram
26 CAPTULO 4. TESTES REALIZADOS
Figura 4.18: Teste realizado com pacote contendo o cdigo de funo igual a 16 e a soma
do endereo inicial e a quantidade de registradores maior que 10.000.
respondidas, pelo mdulo Modbus/TCP e pelo simulador de Modbus/TCP, com excees
contendo cdigo de exceo igual a 2.
Os pacotes, com cdigo de funo igual a 16, foram manipulados para que a soma,
do endereo inicial dos registradores a serem modicados juntamente com a quantidade
desses registradores, tivessem um valor maior que 10.000. Esses pacotes so respondi-
dos com uma exceo pelo mdulo Modbus/TCP, j o simulador de Modbus/TCP no
responde a essas requisies. Nesses casos, esses pacotes deveriam ser respondidos nor-
malmente com o mesmo contedo dessas requisies.
Os testes realizados com pacotes contendo cdigo de funo igual a 22 mostram que o
mdulo Modbus/TCP tambm responde incorretamente a essas requisies. Este cdigo
de funo utilizado para modicar os valores dos registradores atravs da combina-
o de operaes lgicas. Os testes que apresentam discordncias do protocolo so os
pacotes que possuem endereos a serem modicados maiores que 10.000. As requisi-
es enviadas nos testes possuam valores iguais a 10.001 nesse campo e deveriam ser
respondidas normalmente com um pacote de mesmo contedo. Nesse caso, o mdulo
Modbus/TCP responde com uma exceo com cdigo de exceo igual a 2 e o simulador
de Modbus/TCP no responde a pacotes contendo este cdigo de funo. Na Figura 4.19,
apresenta-se o diagrama correspondente desse teste.
Na Figuras 4.20 e 4.21, apresentam-se, ainda, os testes realizados com pacotes con-
tendo cdigos de funo iguais a 23. Para esses pacotes, o mdulo Modbus/TCP respon-
deu com excees a pacotes onde foram manipulados os campos que denem a leitura e
a escrita. Quando a soma dos campos, que denem a leitura ou a escrita, tem um valor
maior que 10.000, o mdulo Modbus/TCP responde a essas requisies com uma exceo
que tem cdigo de exceo igual a 2. O simulador de Modbus/TCP no responde a es-
tas requisies. Estas requisies deveriam ser respondidas normalmente com os valores
solicitados.
Os testes de conformidades mostraram tambm que pacotes com cdigos de funo,
que deveriam ser respondidos somente em dispositivos que utilizam canais de comunica-
o serial, foram respondidos normalmente pelo mdulo Modbus/TCP. O simulador de
Modbus/TCP testado no respondeu a esses tipos de pacotes.
4.2. METODOLOGIA E RESULTADOS 27
Figura 4.19: Teste realizado com pacote contendo o cdigo de funo igual a 22 e o
endereo inicial maior que 10.000.
Figura 4.20: Teste realizado com pacote contendo o cdigo de funo igual a 23 e a soma
do endereo inicial e a quantidade de registradores de leitura maior que 10.000.
Figura 4.21: Teste realizado com pacote contendo o cdigo de funo igual a 23 e a soma
do endereo inicial e a quantidade de registradores de escrita maior que 10.000.
Os testes apresentam que dois cdigos de funo, 7 e 8, reservados para comunicao
serial foram respondidos normalmente. Os pacotes contendo cdigo de funo igual a 7
deveriamser respondidos, por dispositivos que utilizamo Modbus/TCP, comuma exceo
contendo o cdigo de exceo igual a 1. Este cdigo de exceo utilizado para indicar
28 CAPTULO 4. TESTES REALIZADOS
que o cdigo de funo utilizado no permitido. Na Figura 4.22, apresentado esse
teste.
Figura 4.22: Teste realizado com pacote contendo o cdigo de funo igual a 7.
Os pacotes, contendo cdigo de funo igual a 8, possuem um campo que dene uma
sub-funo. Este campo possui valores especicados pelo protocolo, que denem a fun-
cionalidade do pacote. Nos testes realizados, os pacotes contendo nesse campo valores
denidos, e tambm os no-denidos, deveriam ser respondidos com uma exceo. No
caso dos valores denidos pela especicao, os pacotes deveriam ser respondidos com
cdigo de exceo igual a 1 pois um cdigo de funo desenvolvido para comunicaes
seriais. Alm do mais, quando se tem um valor do campo de sub-funo fora da faixa de
valores denidos pelo protocolo, o dispositivo tambm deveria responder com uma exce-
o com cdigo de exceo igual a 1. O mdulo Modbus/TCP respondeu normalmente
a estas requisies, nos dois casos, com pacotes de mesmo contedo. Esses testes so
apresentados nos diagramas das Figuras 4.23 e 4.24.
Figura 4.23: Teste realizado com pacote contendo o cdigo de funo igual a 8 e sub-
funo igual a 1.
As discordncias entre a especicao e a implementao do protocolo nos dispositi-
vos podem ocasionar problemas na interpretao dos dados. Este fato pode levar a tomada
de decises errneas.
4.2.2 Teste de Segurana
Atravs do software de manipulao de pacotes Modbus tambm foi possvel encon-
trar um grave problema no mdulo Modbus/TCP do CLP testado. Os pacotes contendo
4.2. METODOLOGIA E RESULTADOS 29
Figura 4.24: Teste realizado com pacote contendo o cdigo de funo igual a 8 e sub-
funo igual a 65.5353.
valores especcos, dentro do campo Tamanho no cabealho, fazem com que o mdulo
Modbus/TCP no responda mais a requisies posteriores. A execuo desta ao pode
ser considerada um ataque de negao de servio (DoS - Denial of Service). O mdulo de
comunicao do CLP deixa de fornecer o servio Modbus/TCP quando submetido a esta
situao, voltando a operar normalmente somente aps a sua reinicializao.
Nas Figuras 4.25 e 4.26, os resultados dos testes que ocasionam o DoS no mdulo
Modbus/TCP so apresentados. Na Figura 4.25, apresentado o trfego entre o mdulo
Modbus/TCP e o IndPM, capturado utilizando o Wireshark
2
. O valor que ocasiona o
problema, em destaque na gura, no apresentado por questes de segurana. Na Figura
4.26, mostra-se o momento em que ocorre a perda de comunicao do CLP, quando no
responde mais a requisies de ping atravs do mdulo Modbus/TCP.
Figura 4.25: Trfego entre o mdulo do CLP e o IndPM capturado com Wireshark. O
valor em destaque no mostrado por motivos de segurana.
2
Wireshark: Go deep. http://www.wireshark.org/
30 CAPTULO 4. TESTES REALIZADOS
Figura 4.26: Monitoramento do mdulo Modbus/TCP utilizando ping. Observar que o
mdulo deixa de responder ao comando no quadrado em destaque na gura.
No prximo Captulo, so apresentadas as concluses deste trabalho e so feitas algu-
mas propostas de trabalhos futuros.
Captulo 5
Concluses
Os protocolos de comunicao baseados em TCP/IP utilizados nas redes de auto-
mao, em geral, so simples e desenvolvidos com pouca preocupao em relao aos
aspectos de segurana. A anlise dos protocolos utilizados pelos dispositivos pode mos-
trar falhas existentes, como foi apresentado. Esta anlise pode auxiliar na denio dos
mecanismos de segurana que se deve utilizar para cada dispositivo.
O IndPM uma ferramenta que possibilita a anlise de protocolos baseados em
TCP/IP, utilizados pelos dispositivos em redes industriais. Essa ferramenta realiza tes-
tes de segurana e de conformidade de protocolos, de forma intrusiva na rede, atravs da
manipulao e envio de pacotes.
Com a manipulao de pacotes utilizando o IndPM, foram obtidos resultados referen-
tes discordncia entre a especicao do protocolo e o que foi efetivamente implemen-
tado pelos dispositivos. Essas respostas emdiscordncia coma especicao do protocolo
podem provocar uma ao errada no controle dos outros dispositivos da rede.
O IndPM permitiu tambm encontrar uma condio de negao de servio. Este tipo
de ataque necessita de ateno em dispositivos industriais, visto que so dispositivos im-
portantes na comunicao dos sistemas de controle. Para o CLP testado faz-se necessrio
a utilizao de ferramentas de segurana para detectar e impedir o recebimento indevido
de pacotes que possam ocasionar a negao de servio.
O trabalho desenvolvido mostra que a ferramenta IndPM pode ser utilizada num pro-
cesso de certicao de segurana e de conformidades de protocolos industriais baseados
em TCP/IP.
A validao do mdulo de manipulao para pacotes DNP3 sobre TCP uma pro-
posta para trabalho futuro, alm de testes em diferentes dispositivos tanto para o mdulo
DNP3 sobre TCP quanto o mdulo Modbus/TCP. A implementao de outros protocolos
baseados em TCP/IP, como o IEC 60870-5-104, tambm proposta de continuidade deste
trabalho.
32 CAPTULO 5. CONCLUSES
Referncias Bibliogrcas
Bailey, David & Edwin Wright (2003), Pratical SCADA for Industry, 1
a
edio, Newnes.
Byres, Eric J., Dan Hoffman & Nate Kube (2006), On Shaky Ground - A Study of Se-
curity Vulnerabilities in Control Protocols, 5th American Nuclear Society Inter-
national Topical Meeting on Nuclear Plant Instrumentation, Controls, and Human
Machine Interface Technology. .
Clarke, Gordon, Deon Reynders & Edwin Wright (2004), Pratical Modern SCADA Pro-
tocols: DNP3, 60870.5 and Related Systems, 1
a
edio, Newnes.
Grzelak, Daniel (2008), SCADA Penetration Testing - Hacking Modbus Enabled Devi-
ces, RUXCON .
Kobayashi, Tiago Hiroshi, Aguinaldo Batista Bezerra Junior, Agostinho Medeiros Brito
Junior & Paulo Srgio Motta Pires (2007), Using a Packet Manipulation Tool for
Security Analysis of Industrial Network Protocols, IEEE Conference on Emerging
Technologies and Factory Automation, 2007. ETFA. pp. 744747.
Lobashov, Maxim & Thilo Sauter (2006), Vertical Communication from the Enterprise
Level to the Factory Floor - Integrating Fieldbus and IP-based Networks, IEEE
Conference on Emerging Technologies and Factory Automation, 2006. ETFA 06.
pp. 12141221.
Mander, Todd, Farhad Nabhami, Lin Wang & Richard Cheung (2007), Data Object Ba-
sed Security for DNP3 Over TCP/IP for Increased Utility Commercial Aspects Se-
curity, IEEE Power Engineering Society General Meeting 2007. pp. 18.
Modbus-IDA (2006a), Modbus Application Protocol Specication V1.1b.
URL: http://www.Modbus-IDA.org, acessado em julho de 2009
Modbus-IDA (2006b), MODBUS Messaging on TCP/IP Implementation Guide V1.0b.
URL: http://www.Modbus-IDA.org, acessado em julho de 2009
Pires, Paulo Srgio Motta & Luiz Affonso H Guedes Oliveira (2006), Security Aspects
of SCADA and Corporate Network Interconnection: An Overview, International
Conference on Dependability of Computer Systems, 2006. DepCos-RELCOMEX
06. pp. 127134.
33
34 REFERNCIAS BIBLIOGRFICAS
Sauter, Thilo (2005), Integration Aspects in Automation - a Technology Survey, 10th
IEEE Conference on Emerging Technologies and Factory Automation, 2005. ETFA
2005. 2, 255263.
Shifet, Nancy Gill (2004), A Control System Specic Threat and Vulnerability Taxo-
nomy, ISA Automation West. AUTOWEST 2004. .
Stevens, W. Richard (2001), TCP/IP Illustrated, Volume 1: The Protocols, 1
a
edio,
Addison-Wesley.
Tanenbaum, Andrew S. (2003), Redes de Computadores, 4
a
edio, Editora Campus.
Apndice A
DNP3 sobre TCP
A.1 DNP3
O protocolo DNP3 utilizado com o mesmo objetivo do Modbus: fazer a comunica-
o entre os dispositivos de redes industriais. Cita-se na literatura, um uso maior desse
protocolo em companhias eltricas [Clarke et al. 2004]. O DNP3 um protocolo pro-
prietrio e foi desenvolvido para operar somente em canais de comunicao serial mas,
atualmente, tambm pode ser utilizado sobre Ethernet. Para utilizar o DNP3 num canal
de comunicao Ethernet, no necessrio fazer qualquer modicao do pacote que
utilizado em meios de comunicao serial. O pacote, com todas as suas camadas, encap-
sulado dentro de um segmento TCP. Devido a este encapsulamento, comum se utilizar
a denominao de DNP3 sobre TCP (DNP3 over TCP).
Um pacote DNP3 composto de 3 camadas: enlace, transporte e aplicao (Data
Link Layer, Transport Functions e Application Layer). Os pacotes do DNP3 over TCP
contm o mesmo contedo de um pacote DNP3 serial, sendo o pacote encapsulado em
um segmento TCP. Na Figura A.1, mostra-se como este encapsulamento realizado.
A camada de enlace do protocolo DNP3 responsvel pela ligao com a camada
fsica, pelo controle e endereamento dos pacotes e pela ligao com a camada superior de
transporte. O quadro do DNP3 (pacote da camada de enlace) formado por dois campos:
um cabealho e os dados. O cabealho possui campos para indicar as responsabilidades
do quadro. Um campo informa o incio do quadro, outro campo indica o tamanho do
quadro, um campo para informar algumas opes de controle, outros dois campos para
indicar os endereos de origem e destino do quadro e por m um campo para checar a
integridade do frame, atravs do CRC. O CRC tambm calculado para cada 16 bytes do
campo de dados de um pacote DNP3 [Clarke et al. 2004].
A camada de transporte do protocolo DNP3 considerada como uma pseudo-camada
de transporte e possui a funo de interligar as camadas de enlace e de aplicao do
protocolo, bem como prover alguns servios de controle de conexo. As mensagens da
pseudo-camada de transporte contm apenas um cabealho e os dados transmitidos. O
cabealho simples, contendo apenas um byte, que tem um bit para representar se existe
fragmentao, um bit para representar se o primeiro fragmento e os outros 6 bits para
representar o nmero de sequncia da mensagem [Clarke et al. 2004].
A camada de aplicao do protocolo DNP3 foi desenvolvida com o intuito de satisfa-
zer necessidades dos sistemas de automao distribudos e sistemas SCADA. A camada
36 APNDICE A. DNP3 SOBRE TCP
Figura A.1: Encapsulamento do DNP3 sobre TCP.
de aplicao responsvel pela comunicao com a camada do usurio, abstraindo todas
as outras camadas inferiores camada de aplicao. Portanto, o usurio necessita ape-
nas do conhecimento da camada de aplicao para o desenvolvimento dos sistemas de
controle que se utilizam deste protocolo. A camada dos usurios faz uso da camada de
aplicao para enviar e receber mensagens entre os dispositivos que utilizam DNP3.
Os pacotes da camada de aplicao so constitudos por trs campos: cabealho do
pacote, cabealho dos dados e dados. O cabealho contm o propsito de mensagem e as
informaes de controle da camada de aplicao (APCI - Application Control Protocol
Information). O cabealho de dados identica os dados enviados pelo dispositivo no
campo de dados. E por m, o campo de dados contm a mensagem enviada para os
dispositivos que utiliza o DNP3 [Clarke et al. 2004].
A.2 Mdulo DNP3 sobre TCP do IndPM
O mdulo que implementa o protocolo DNP3 sobre TCP, assim como o Mdulo Mod-
bus/TCP do IndPM, fornece interatividade para o usurio, possibilitando a modicao
do contedo dos campos existentes num pacote DNP3. Como mostrado na Seo A.1, o
DNP3 sobre TCP implementa trs camadas, as quais foram implementadas em diferentes
classes neste mdulo.
Diferente do Modbus/TCP, os pacotes do protocolo DNP3 no sofrem variao do
contedo, apenas dos valores dos campos existentes nas trs camadas do protocolo. Estas
camadas esto representadas por classes que herdam da classe Packet do Scapy. Assim
A.2. MDULO DNP3 SOBRE TCP DO INDPM 37
como no mdulo do Modbus/TCP, desenvolvemos algumas classes que herdam os atribu-
tos da classe StrField, denindo alguns campos necessrios para o DNP3.
A interface do IndPM referente ao DNP3 sobre TCP pode ser observada na Figura
A.2. Esta interface contmos campos existentes numpacote DNP3 sobre TCP. Os campos
so representados por botes do tipo SpinButton possuindo somente os valores especi-
cados pelo protocolo DNP3. Os botes esto agrupados de acordo com as camadas do
protocolo DNP3: enlace, transporte e aplicao. Existe outro grupo de botes para indicar
a congurao TCP/IP, tendo botes para denir o IP e a porta TCP de destino.
Figura A.2: Tela da interface da manipulao de pacotes do protocolo DNP3 sobre TCP.
Esta interface j est incorporada ao IndPM faltando apenas valid-la com testes em
dispositivos que se comunicam com o protocolo DNP3 sobre TCP.
38 APNDICE A. DNP3 SOBRE TCP
Apndice B
Publicaes
Com este trabalho, foram obtidas duas publicaes em congressos internacionais na
rea. So elas:
Using a Packet Manipulation Tool for Security Analysis of Industrial Network Pro-
tocols, publicado em Setembro de 2007, no ETFA2007 - 12th IEEE Conference on
Emerging Technology and Factory Automation, pp. 744-747, Patras - Grcia;
Analysis of Malicious Trafc in Modbus/TCP Communications, publicado em Ou-
tubro de 2008, no CRITIS08 -3rd Internacional Workshop on Critical Information
Infrastructure Security, Frascati - Itlia.