( PDF ) Firewall para protocolos industriais

Download PDF

ads:

UNIVERSIDADE DO RIO GRANDE DO NORTEFEDERAL

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

CENTRO DE TECNOLOGIA

PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA E

DE COMPUTAÇÃO

Firewall de Aplicação para Redes Industriais

Aguinaldo Bezerra Batista Júnior

Orientador: Prof. Dr. Paulo Sérgio da Motta Pires

Dissertação de Mestrado apresentada ao

Programa de Pós-Graduação em Engenharia

Elétrica e de Computação da UFRN (área de

concentração: Engenharia de Computação)

como parte dos requisitos para obtenção do

título de Mestre em Ciências.

Número de ordem PPgEEC: M235

Natal, RN, julho de 2009

ads:

Livros Grátis

http://www.livrosgratis.com.br

Milhares de livros grátis para download.

Divisão de Serviços Técnicos

Catalogação da publicação na fonte. UFRN / Biblioteca Central Zila Mamede

Batista Júnior, Aguinaldo Bezerra.

Firewall de aplicação para redes industriais / Aguinaldo Bezerra Batista Jú-

nior. – Natal, RN, 2009.

62 f.

Orientador: Paulo Sérgio da Motta Pires.

Dissertação (Mestrado) – Universidade Federal do Rio Grande do Norte. Cen-

tro de Tecnologia. Programa de Pós-Graduação em Engenharia Elétrica e de

Computação.

1. Proteção de infra-estrutura crítica – Dissertação. 2. Firewall de aplicação

– Dissertação. 3. Seguranças em redes industriais – Dissertação. 4. Firewall

industrial – Dissertação. 5. Modbus/TCP – Dissertação. I. Pires, Paulo Sérgio

da Motta Pires. II. Universidade Federal do Rio Grande do Norte. III. Título.

RN/UF/BCZM CDU 004.056.5(043.3)

ads:

Firewall de Aplicação para Redes Industriais

Aguinaldo Bezerra Batista Júnior

Dissertação de Mestrado aprovada em 06 de julho de 2009 pela banca examinadora com-

posta pelos seguintes membros:

Prof. Dr. Paulo Sérgio da Motta Pires (orientador) ... . . . . . . . . . . . DCA/UFRN

Prof. Dr. José Sérgio da Rocha Neto (examinador externo) . . . . . . . DEE/UFCG

Prof. Dr. Agostinho de Medeiros Brito Júnior . . . . . . . . . . . . . . . . . . DCA/UFRN

Prof. Dr. Jorge Dantas de Melo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DCA/UFRN

À minha família, pelo apoio durante

esta jornada.

Agradecimentos

Ao meu orientador, professor Paulo S. da Motta Pires, sou grato pela orientação.

Aos colegas do LABSIN (Laboratório de Segurança da Informação) pelos auxílios e su-

gestões durante o desenvolvimento desse trabalho

À Petrobras, através do projeto SERI (Segurança de Redes Industriais), pelo suporte ﬁ-

nanceiro.

Resumo

A utilização de ﬁrewalls é uma abordagem amplamente aceita quando se deseja prote-

ger redes de Tecnologia de Automação (TA) de redes de Tecnologia da Informação (TI).

Nesta dissertação aborda-se o desenvolvimento de uma ﬁrewall para redes de automação

baseadas em TCP/IP que protege dispositivos industriais de tráfego em desconformidade

com o tráfego esperado. Todo tráfego de rede que não está de acordo com os padrões

de um determinado protocolo industrial ou que não respeitas as limitações impostas, é

considerado anormal e deve ser bloqueado. Foi desenvolvida uma aplicação em nível

de usuário que realiza a ﬁltragem de tráfego sobre a camada de aplicação. O protocolo

industrial escolhido como estudo de caso foi o Modbus/TCP, devido à sua simplicidade,

documentação abundante e alta relevância para as redes industriais.

Palavras-chave: Proteção de Infra-estrutura Crítica, Firewall de Aplicação, Segu-

rança em Redes Industriais, Firewall Industrial, Modbus/TCP

Abstract

The utilization of ﬁrewalls is a widely accepted approach when protecting Automation

Technology (AT) environments from Information Technology (IT) ones. This dissertation

covers the development of a ﬁrewall system for TCP/IP-based industrial networks which

can protect automation devices from abnormal trafﬁc. Thus, all non-conformity trafﬁc or

trafﬁc which does not respect the imposed constraints is considered abnormal and must

be blocked. It was developed an user-space application which ﬁlters trafﬁc in the appli-

cation layer. The industrial protocol chosen as a case study was Modbus/TCP, due to its

simplicity, abundant documentation and high relevance for current industrial networks.

Keywords: Critical Infra-structure protection, Application Firewall, Security of In-

dustrial Networks, Industrial Firewall, Modbus/TCP

Sumário

Sumário i

Lista de Figuras iii

Lista de Tabelas v

Lista de Símbolos e Abreviaturas vii

1 Introdução 1

1.1 Segurança da Informação em Sistemas de TA . . . . . . . . . . . . . . . 4

1.2 Organização do Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Firewalls 7

2.1 Firewalls de Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Protocolos Modbus e Modbus/TCP 11

3.1 Modbus/TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Deﬁnição do Problema 17

4.1 Cenários de Risco para Redes Industriais . . . . . . . . . . . . . . . . . . 17

4.1.1 Presença de Tráfego Não-industrial em Redes Industriais . . . . . 17

4.1.2 Má Utilização de Ações dos Protocolos . . . . . . . . . . . . . . 18

4.2 Requisitos de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5 Solução Proposta 21

5.1 Tecnologias e Técnicas Utilizadas . . . . . . . . . . . . . . . . . . . . . 23

5.1.1 Regulação de Tráfego no Linux . . . . . . . . . . . . . . . . . . 24

5.1.2 Inspeção de Datagramas IP no Espaço de Usuário . . . . . . . . . 25

5.1.3 Expressões Regulares . . . . . . . . . . . . . . . . . . . . . . . . 27

6 Arquitetura do Sistema 31

6.1 A aplicação Modbus Filter . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.1.1 Modos de Operação . . . . . . . . . . . . . . . . . . . . . . . . 33

6.1.2 Arquivos de Conﬁguração . . . . . . . . . . . . . . . . . . . . . 33

6.1.3 Interface Gráﬁca com o Usuário . . . . . . . . . . . . . . . . . . 36

7 Resultados 39

7.1 Ambiente de Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

7.2 Testes Realizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

7.3 Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.3.1 Técnica Utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.3.2 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7.3.3 Gráﬁcos de RTT e Avaliação de Desempenho . . . . . . . . . . . 48

7.4 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.4.1 Conexões TCP Abertas . . . . . . . . . . . . . . . . . . . . . . . 52

7.4.2 Fila de Datagramas . . . . . . . . . . . . . . . . . . . . . . . . . 53

8 Conclusões e Trabalhos Futuros 55

Referências bibliográﬁcas 56

Lista de Figuras

1.1 Pirâmide da automação [The Harting Technology Group 2009, I.Network

Automation 2009, Kraken Automation 2009, Mitsubishi Electric Automation

2009]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Diagrama de um sistema de automação industrial que utiliza o protocolo

Modbus/TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Firewalls convencionais versus ﬁrewalls de aplicação. . . . . . . . . . . . 8

3.1 Pilha de protocolos Modbus. Adaptado de [Modbus-IDA 2006a]. . . . . . 12

3.2 Formato geral de quadro de dados do protocolo Modbus. . . . . . . . . . 12

3.3 Códigos de função do protocolo Modbus [Modbus-IDA 2006a]. . . . . . 13

3.4 Construção de um pacote Modbus/TCP. . . . . . . . . . . . . . . . . . . 15

5.1 Módulos analisadores da ﬁrewall de aplicação para o Modbus/TCP. . . . . 22

5.2 Possíveis locais de implantação da ﬁrewall de aplicação em uma rede in-

dustrial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.3 Relacionamento entre o módulo ip_queue e a biblioteca libipq. . . . . . . 27

6.1 Arquitetura do sistema ﬁrewall. . . . . . . . . . . . . . . . . . . . . . . . 32

6.2 Fluxograma de operações da aplicação Modbus Filter, sob o modo 0. . . . 34

6.3 Fluxograma de operações da aplicação Modbus Filter, sob o modo 1. . . . 35

6.4 Formulário para geração do arquivo de inicialização do Modbus Filter. . . 36

6.5 Formulário para geração do arquivo de regras do Modbus Filter. . . . . . 37

7.1 Diagrama do ambiente de testes montado. . . . . . . . . . . . . . . . . . 40

7.2 Captura de tela do Wireshark no Monitor 1, exibindo o envio de uma

mensagem via telnet por um cliente para um servidor Modbus/TCP. . . . 41

7.3 Captura de tela das mensagens de saída da ﬁrewall ao receber um seg-

mento cuja carga útil está em desconformidade com o protocolo Mod-

bus/TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7.4 Captura de tela do Wireshark no Monitor 2, mostrando que o segmento

contendo dados em desconformidade não penetrou na rede dos servidores

Modbus/TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7.5 Captura de tela do Wireshark no Monitor 1, exibindo o envio de uma re-

quisição Modbus/TCP malformada por um cliente para um servidor Mod-

bus/TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7.6 Captura de tela das mensagens de saída da ﬁrewall ao receber uma requi-

sição Modbus/TCP com o campo Length indicando um valor incorreto. . 43

iii

7.7 Captura de tela do Wireshark no Monitor 2, mostrando que o segmento

contendo dados em desconformidade não penetrou na rede dos servidores

Modbus/TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7.8 Captura de tela do Wireshark no Monitor 1, exibindo o envio de uma

requisição Modbus/TCP não autorizada por um cliente para um servidor

Modbus/TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.9 Captura de tela das mensagens de saída da ﬁrewall ao receber uma requi-

sição Modbus/TCP não autorizada para um determinado servidor. . . . . 44

7.10 Captura de tela do Wireshark no Monitor 2, mostrando que a requisição

Modbus/TCP não autorizada não adentrou à rede dos servidores Mod-

bus/TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.11 Gráﬁco das amostras de RTT para a situação 1, em que servidores e cli-

entes Modbus/TCP estão na mesma rede, interligados através de um switch. 49

7.12 Gráﬁco das amostras de RTT para a situação 2, em que há um roteador

entre as redes dos clintes e dos servidores Modbus/TCP. . . . . . . . . . . 49

7.13 Gráﬁco das amostras de RTT para a situação 3, onde os pacotes passam

pelo espaço de usuário antes de ser encaminhados. . . . . . . . . . . . . 50

7.14 Gráﬁco das amostras de RTT para a situação 4, em que a ﬁrewall opera

sob o modo 0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.15 Gráﬁco das amostras de RTT para a situação 5, onde a ﬁrewall opera sob

o modo 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Lista de Tabelas

7.1 Resumo dos resultados de latência para cada situação. . . . . . . . . . . . 52

Lista de Símbolos e Abreviaturas

ADU: Application Data Unit

ALG: Aplication-level Gateway

API: Application Programming Interface

ASCII: American Standard Code for Information Interchange

CIAG: Critical Infrastructure Assurance Group

CLP: Controlador Lógico Programável

CRC: Cyclic Redundancy Check

CSMA/CD: Carrier Sense Multiple Access/Collision Detection

ERP: Enterprise Resource Planning

HMI: Human-Machine Interface

IANA: Internet Assigned Numbers Authority

IDS: Intrusion Detection Systems

IP: Internet Protocol

IPv4: Internet Protocol version 4

ISO: International Organization for Standardization

LABSIN: Laboratório de Segurança da Informação

LAN: Local Area Network

LRC: Longitudinal Redundancy Check

MBAP: Modbus Application Protocol

MES: Manufacturing Execution System

NAT: Network Address Translation

OLE: Object Linking and Embedding

vii

OPC: OLE for Process Control

OSI: Open Systems Interconnection

PAT: Port Address Translation

PC: Personal Computer

PCRE: Perl Compatible Regular Expressions

PDU: Protocol Data Unit

RTO: Retransmission Timeout

RTT: Round-Trip Time

RTU: Remote Terminal Unit

SCADA: Supervisory Control and Data Aquisition

SCM: Supply Chain Management

TA: Tecnologia de Automação

TAP: Test Access Port

TCP: Transmission Control Protocol

TI: Tecnologia da Informação

UDP: User Datagram Protocol

WAN: Wide Area Networks

Capítulo 1

Introdução

Os sistemas industriais caracterizam-se pela utilização de uma ampla variedade de

tecnologias de comunicação com características e propósitos diferentes. Desde a última

década, é notável que esses sistemas têm passado por mudanças. Entre as mais impor-

tantes, está o fato de que esses sistemas de automação vêm migrando de tecnologias

restritas, proprietárias e especíﬁcas, para tecnologias abertas, padronizadas e de propósito

geral. Essas mudanças seguem uma tendência em direção à integração vertical entre as

várias camadas da pirâmide da Tecnologia de Automação (TA), para ﬁns de ganhos em

conectividade, ﬂexibilidade e produtividade desses sistemas, além de uma considerável

redução de custos. A pirâmide da automação é um modelo de divisão hierárquico costu-

meiramente utilizado para descrever concisamente sistemas de automação. Esse modelo

é utilizado para explicitar que um sistema de automação é formado por diversos níveis

com diferentes elementos, características, propósitos e, consequentemente, diferentes re-

des de comunicação, através dos quais dados são processados e transmitidos. Várias ver-

sões desse modelo em pirâmide podem ser encontradas na literatura especializada, com

diferentes números de camadas, e diversas nomenclaturas e deﬁnições de funcionalida-

des para estas camadas [Sauter 2005, Lobashov & Sauter 2006, The Harting Technology

Group 2009, I.Network Automation 2009, Kraken Automation 2009, Mitsubishi Electric

Automation 2009]. A Figura 1.1 ilustra um exemplo simples de pirâmide, que possui

quatro camadas:

• Gerenciamento: compreende as redes de gerenciamento, planejamento e controle

em alto nível de um sistema de automação como um todo. Predomina neste setor, a

utilização de tecnologias de TI (Tecnologia da Informação). Estão incluídas neste

nível, sistemas corporativos como os ERP (Enterprise Resource Planning), SCM

(Supply Chain Management) e MES (Manufacturing Execution System). Entre os

sistemas de comunicação presentes nessa camada, estão redes LAN (Local Area

Network) e WAN (Wide Area Networks), onde predominam a utilização de tec-

nologias baseadas em TCP/IP (Transmission Control Protocol/Internet Protocol) e

Ethernet [Sauter 2005, Lobashov & Sauter 2006];

• Supervisão: corresponde aos sistemas de monitoramento, telemetria, controle su-

pervisório, aquisição de dados, alarmes, análise de tendência, entre outros. É

nesta camada que tem início o ambiente industrial propriamente dito. Predomi-

nam nesta camada, os sistemas conhecidos como SCADA (Supervisory Control

CAPÍTULO 1. INTRODUÇÃO

and Data Aquisition), que reúnem, geralmente, ferramentas para coleta de informa-

ção, telemetria (transferência de informações entre equipamentos e sistemas sepa-

rados por grandes distâncias para unidades centrais), análise de dados, controle

supervisório e de interface homem-máquina (Human-Machine Interface - HMI)

[Sauter 2005, Krutz 2006]. É predominante nesta camada, a utilização de redes

LAN e WAN, onde prevalecem tecnologias baseadas em TCP/IP, Ethernet, OPC

(OLE for Process Control)e alguns protocolos industriais;

• Controle: nesta camada encontram-se dispositivos controladores responsáveis por

tarefas de monitoramento, controle e regulação de processos. Predominam nessa

camada as LANs baseadas em Ethernet industrial, TCP/IP r redes seriais de campo,

assim como a utilização de protocolos industriais;

• Processo: camada responsável pela medição das variáveis do processo, constituída

por dispositivos de campo como sensores e atuadores (válvulas, motores, comandos

eletrônicos, etc.).

Figura 1.1: Pirâmide da automação [The Harting Technology Group 2009, I.Network

Automation 2009, Kraken Automation 2009, Mitsubishi Electric Automation 2009].

A integração vertical nesses sistemas tem sido um tópico de bastante relevância nos

últimos anos, embora essa integração sempre tenha sido uma meta da automação. Essa

integração vertical em um sistema de automação pode ser entendida como a interligação

sem diﬁculdades entre as várias camadas da pirâmide, com o objetivo de estabelecer o

acesso direto do nível de gerenciamento ao nível de controle de processos [Sauter 2005,

Lobashov & Sauter 2006].

No contexto dos ambientes industriais, a integração vertical tem sido eﬁcientemente

atingida através dos sistemas SCADA, juntamente com as tecnologias de comunicação

inerentes desse ambiente, como as redes e protocolos industriais [Sauter 2005]. Todavia,

existe uma lacuna no que diz respeito à separação entre ambientes corporativos e indus-

triais, não havendo, ainda, um consenso sobre a problemática da interligação eﬁciente e

segura entre esses ambientes.

O processo de integração vertical tem sido facilitado, principalmente, devido ao cres-

cente uso de redes baseadas em TCP/IP no setor de TA, utilizando, em sua maioria, o

padrão Ethernet como mídia de acesso ao meio e de enlace de dados. Estas tecnologias

foram originalmente desenvolvidas para o setor de TI, mas vêm sendo bastante usadas em

várias camadas de um sistema de automação.

Vários protocolos industriais utilizam ou são baseados em tecnologias originárias do

setor de TI. Alguns destes, principalmente os mais recentes, foram especiﬁcamente con-

cebidos sob uma base IP ou Ethernet. Constituem exemplos desses protocolos o Ether-

net/IP

, o ProﬁNet

e o Ethercat

. Existem, porém, protocolos que consistem em versões

tradicionais de protocolos industriais levementeadaptadas para serem utilizadas sobre tec-

nologias de TI, como, por exemplo, os protocolos industriais que são encapsulados como

protocolos da camada de aplicação do modelo TCP/IP, a ﬁm de que suas mensagens pos-

sam ser transportadas através de uma rede IP. Como exemplos de protocolos industriais

que deste tipo, podem ser citados o Modbus/TCP

, o DNP3/IP

e o IEC 60870-5-104

. Na

Figura 1.2 é mostrado um diagrama de exemplo de um sistema de automação industrial

que utiliza o protocolo Modbus/TCP.

Figura 1.2: Diagrama de um sistema de automação industrial que utiliza o protocolo

Modbus/TCP.

O surgimento e popularização de protocolos inerentemente industriais utilizando uma

infra-estrutura TCP/IP comprova que essas redes estão sendo cada vez mais utilizadas no

setor de automação. Assim, é notável que a utilização de tecnologias de TI em sistemas

de TA constitui uma tendência irrevogável. Por isso, em um passado recente, questões

relacionadas à segurança da informação e de dispositivos em sistemas de TA começaram

a constituir uma preocupação real, atraindo a atenção de empresas, de institutos e de

entidades reguladoras.

www.ab.com/networks/ethernet.html

www.proﬁbus.com/pn

www.ethercat.org

http://www.modbus-ida.org

http://www.dnp.org

http://www.iec.ch

CAPÍTULO 1. INTRODUÇÃO

1.1 Segurança da Informação em Sistemas de TA

A segurança da informação em sistemas de TA vem sendo um alvo de grande inte-

resse da comunidade de TA e, por isso, vários trabalhos relacionados à segurança desses

sistemas vêm surgindo na literatura especializada. Os assuntos abordados vão desde o

estabelecimento da problemática da segurança em sistema de TA até propostas de meios

de proteção desses sistemas contra ameaças [Pires & Oliveira 2006, Krutz 2006, Treytl

et al. 2004, Dzung et al. 2005, Byres et al. 2005, P. C. Group & NISCC 2005, Stouffer

et al. 2006, Paukatong2005, Pollet 2002, Byres & Hoffmann 2003, Creery & Byres 2005].

Alguns destes trabalhos propõem a utilização de ﬁrewalls de diferentes tipos, classes e

sob várias arquiteturas para proteger os sistemas de automação de atividade maliciosa

[Krutz 2006, Byres et al. 2005, Stouffer et al. 2006].

As ﬁrewalls têm seu uso bastante consolidado no setor de TI. Diante do aconteci-

mento de vários incidentes de segurança [Byres & Hoffmann 2003, Creery & Byres 2005]

e do recente estabelecimento da problemática da segurança de sistemas críticos, as ﬁ-

rewalls começam a ter seu uso recomendado por institutos e entidades reguladoras [Byres

et al. 2005, Stouffer et al. 2006]. O principal objetivo a ser alcançado com a utilização

de ﬁrewalls é o de proteger as redes de automação das redes de TI, quando estas estão

interconectadas de alguma forma. Entretanto, essa abordagem pode não ser suﬁciente

uma vez que os sistemas de TA passam também a usar tecnologias de TI em níveis mais

baixos da pirâmide da automação, onde vem crescendo a utilização da infra-estrutura

TCP/IP. Portanto, devido à natureza das redes TCP/IP, é provável que esses sistemas se

tornem mais susceptível a ataques remotos e internos (possivelmente não intencionais).

Assim, a abordagem pela utilização de ﬁrewalls pode ir mais longe, sendo também conve-

niente para agregar segurança a camadas mais baixas de um sistema de automação, onde

o tempo é crítico e os dispositivos desempenham tarefas delicadas. Estas ﬁrewalls devem,

portanto, ser capazes de “entender” os protocolos industriais, realizando ﬁltragem sobre

informações próprias dos protocolos de automação. Firewalls com a habilidade de rea-

lizar inspeção sobre a camada de aplicação do modelo de referência OSI (Open Systems

Interconnection) da ISO (International Organization for Standardization) são comumente

referidos na literatura especializada como ﬁrewalls de aplicação.

A utilização de ﬁrewalls de aplicação em redes industriais pode ser justiﬁcada pela ne-

cessidade de um controle rigoroso dos dados de aplicação (protocolos industriais) que nela

trafegam. É indesejável, por exemplo, que tráfego inapropriado (tráfego não-industrial)

seja transportado em canais que supostamente são destinados apenas a tráfego industrial.

A presença de tráfego indevido em tais canais pode introduzir latências indesejáveis e

comprometer dispositivos. Em outra situação, pode haver a necessidade da realização

de inspeções sobre campos dos protocolos industriais, a ﬁm de se obter um controle de

acesso rigoroso sobre certas ações dos protocolos.

O objetivo fundamental deste trabalho é expor um novo sistema de ﬁrewall para re-

des de automação baseadas em TCP/IP. A idéia principal da nossa abordagem é a de que

atividades presumidas como maliciosas podem ser bloqueadas utilizando um ﬁltro de pro-

tocolo que permite que apenas certos tipos de tráfego sejam transmitidos através de uma

rede de automação. Neste esquema, todo tráfego de rede que não está em conformidade

1.2. ORGANIZAÇÃO DO TEXTO

com as assinaturas dos protocolos permitidos ou que não está de acordo com as ações

permitidas para um determinado dispositivo é considerado anormal ou malicioso e deve

ser bloqueado.

Esse sistema ﬁrewall tem como principal componente uma aplicação em nível de

usuário que consiste em um ﬁltro de aplicação (camada 7) com a habilidade de bloquear

todo tráfego não-industrial (tráfego indesejado) e realizar um controle rigoroso sobre as

ações dos protocolos industriais. Essa aplicação utiliza, fundamentalmente, um meca-

nismo de enﬁleiramento de datagramas IP (packet queueing) e uma biblioteca de expres-

sões regulares. O protocolo industrial escolhido como estudo de caso para o desenvolvi-

mento da aplicação foi o Modbus/TCP, embora a abordagem proposta possa ser estendida

para qualquer outro protocolo industrial baseado em TCP/IP.

1.2 Organização do Texto

O restante desta dissertação está organizado em mais oito Seções. O Capítulo 2 apre-

senta uma breve teoria sobre ﬁrewalls enquanto que o Capítulo 3 faz uma introdução aos

protocolos industriais Modbus e Modbus/TCP. O Capítulo 4 trata da deﬁnição do pro-

blema e das motivações para o desenvolvimento deste trabalho. A solução desenvolvida é

apresentada no Capítulo 5, bem como as tecnologias e técnicas utilizadas em seu desen-

volvimento. O Capítulo 6 trata da apresentação da arquitetura e dos detalhes do sistema

ﬁrewall desenvolvido. Os resultados obtidos são exibidos no Capítulo 7. O Capítulo 8

conclui a dissertação, apresentando algumas considerações ﬁnais sobre este trabalho.

CAPÍTULO 1. INTRODUÇÃO

Capítulo 2

Firewalls

Firewall é um dispositivo de segurança da informação responsável pelo monitora-

mento e regulagem do tráfego em uma rede de computadores baseada em TCP/IP. Estes

dispositivos têm como principal propósito proteger informações, serviços e equipamentos

presentes em uma rede de uma série de ameaças como ataques, acesso não autorizado ou

uso indevido. Uma ﬁrewall pode ser entendida como um nó centralizador e ﬁltrante de

uma rede, dotado de uma entrada e de uma saída para o ﬂuxo de dados. O ﬂuxo presente

na saída corresponde a uma versão ﬁltrada do ﬂuxo de entrada, de acordo com as regras

de ﬁltragem deﬁnidas na conﬁguração da ﬁrewall. Em geral, o tráfego que não está em

conformidade com essas regras tem seus respectivos pacotes IP bloqueados.

Uma das tarefas triviais de uma ﬁrewall é a de realizar o controle de tráfego entre

redes de computadores que se comunicam, mas pertencem a ambientes de conﬁabilidade

diferente. Por exemplo, uma rede corporativa ou privada e a Internet, sob o contexto

das redes de TI, são exemplos típicos de rede conﬁável e não-conﬁável, respectivamente.

Nestes termos, uma ﬁrewall pode ser alojada entre uma rede privada e a Internet, impe-

dindo que tráfego hostil oriundo da Internet chegue à rede privada. Em um outro cenário,

onde as redes corporativa e industrial de uma empresa estão interligadas, a rede corpora-

tiva pode não ser considerada conﬁável, sendo aconselhável a utilização de ﬁrewalls para

restringir o acesso à rede industrial.

Em geral, ﬁrewalls convencionais, conhecidas como ﬁltros de pacotes, realizam ins-

peção sobre as camadas 3 e 4 (camadas de rede e de transporte, respectivamente). Sendo

assim, essas ﬁrewalls são capazes de realizar uma comparação entre as regras de ﬁltra-

gem e as informações que podem ser extraídas do tráfego passante, como, por exemplo,

endereços IP (camada 3) e números de portas (camada 4).

Apesar de os ﬁltros de pacotes serem suﬁcientes para a maioria das situações, essas

ﬁrewalls não são capazes de analisar tráfego de protocolos correspondentes à camada de

aplicação (camada 7), simplesmente pelo fato de que esses protocolos não são compre-

endidos por esse tipo de ﬁrewall. Para que a ﬁltragem sobre os protocolos na camada de

aplicação seja possível, é necessário dotar essas ﬁrewalls convencionais da capacidade de

reconhecer e realizar ﬁltragem sobre tráfego desta camada. Uma ﬁrewall com essa ha-

bilidade é comumente referida na literatura especializada como ﬁrewall de aplicação ou

gateway de aplicação (Aplication-level Gateway - ALG) [Suehring & Ziegler 2005].

CAPÍTULO 2. FIREWALLS

2.1 Firewalls de Aplicação

As ﬁrewalls de aplicação constituem uma nova classe de ﬁrewalls cuja atuação vai

além das camadas 3 e 4 (IP/porta). São utilizadas em situações em que a abordagem

convencional é insuﬁciente, ou seja, quando se deseja realizar o controle do tráfego pri-

mariamente ao nível dos dados da camada de aplicação (camada 7 do modelo OSI). Estas

ﬁrewalls consistem, tipicamente, de ﬁrewalls convencionais aperfeiçoadas com o pro-

fundo conhecimento sobre os dados de aplicação, podendo, portanto, identiﬁcar desvios

no tráfego considerado normal para a aplicação em questão [Suehring & Ziegler 2005].

Ou seja, são capazes de realizar a análise sobre a carga útil da camada de transporte (dados

das aplicações), na busca por informações que determinarão se os respectivos datagramas

IP serão aceitos ou bloqueados.

Esta abordagem para ﬁrewalls já é bastante utilizada em alguns ambientes de TI, prin-

cipalmente em situações em que ﬁltragem tradicional por IP/porta é insuﬁciente para ga-

rantir segurança ou economizar largura de banda. Nestes casos, adicionalmente à ﬁltra-

gem convencional sobre as camadas 3 e 4, faz-se necessária a caracterização desse tráfego

também com relação à camada de aplicação, para que seja possível aplicar regras de blo-

queio ou aceitação sobre o tráfego que carrega certos protocolos de aplicação. No caso

dos ambientes de TA, onde as mensagens dos protocolos industriais podem ser encapsu-

ladas como dados da camada de aplicação, a ﬁltragem sobre esta camada é de extrema

importância quando se deseja ter um controle sobre as ações do protocolo. A Figura 2.1

mostra uma comparação entre ﬁrewalls convencionais e ﬁrewalls de aplicação.

Figura 2.1: Firewalls convencionais versus ﬁrewalls de aplicação.

2.1. FIREWALLS DE APLICAÇÃO

Em um passado recente, a segurança de sistemas de automação começou a ﬁgurar

um sólido campo de interesse. Um exemplo consistente deste fato foi a criação de um

projeto de pesquisa voltado à segurança de infra-estruturas críticas, por parte de uma

grande empresa do ramo de equipamentos e segurança de redes. O projeto CIAG (Cri-

tical Infrastructure Assurance Group), lançado pela Cisco

em 2004, desenvolveu uma

solução de ﬁrewall industrial especíﬁca para o protocolo industrial Modbus/TCP. Esta so-

lução, chamada Modbus Firewall [Franz & Pothamsetty 2004], consiste em uma extensão

para o sistema de ﬁltragem de pacotes do sistema operacional Linux (Netﬁlter/Iptables),

capaz de veriﬁcar alguns campos de um pacote Modbus/TCP com relação a regras deﬁ-

nidas pelo usuário (estabelecidas através do Iptables), com o intuito de bloquear pacotes

Modbus/TCP indesejáveis em uma determinada rede de automação. Esta ﬁrewall foi de-

senvolvida para avaliar a possibilidade de se adicionar um sistema de controle de acesso

rigoroso a um protocolo industrial, utilizando como base uma infra-estrutura de ﬁrewall

comum e de propósito geral. Com uma ﬁrewall deste tipo, torna-se possível a realização

do controle sobre certas ações do protocolo, protegendo dispositivos de comandos que

possam ser inoportunos ou inapropriados para um determinado sistema.

A principal desvantagem da Modbus Firewall é que ela assume que todos tráfego

que por ela passa é Modbus/TCP, ou seja, a ﬁrewall inicia o procedimento de análise

dos campos dos pacotes sem veriﬁcar se realmente se trata de tráfego Modbus/TCP. Em

outras palavras, a ﬁrewall pode aceitar ou bloquear quaisquer que sejam os pacotes cujos

valores dos seus campos combinem com os valores deﬁnidos pelo usuário. Além disso,

esta ﬁrewall não realiza a veriﬁcação sobre todas as ações do protocolo, uma vez que não

é capaz de analisar todos os campos do mesmo.

O sistema ﬁrewall apresentado neste trabalho tem como objetivo trazer a análise na

camada de aplicação para protocolos industriais baseados em TCP/IP, mostrando a impor-

tância e a exequibilidade dessa abordagem para as redes de TA baseadas em TCP/IP. Essa

análise compreende a veriﬁcação de conformidade com a especiﬁcação e com regras que

restringem as ações do protocolo. A análise dos pacotes é realizada por uma aplicação

executada no espaço de usuário, onde é possível utilizar uma ampla variedade de recur-

sos. Para esta ﬁrewall, tanto o tráfego não-industrial quanto o tráfego referente à ações

não permitidas é considerado anormal e deve ser bloqueado.

O próximo Capítulo desta dissertação fará uma breve abordagem aos protocolos in-

dustriais Modbus e Modbus/TCP, que são os principais objetos de estudo para o desen-

volvimento da ﬁrewall de aplicação em questão.

http://cisco.com

CAPÍTULO 2. FIREWALLS

Capítulo 3

Protocolos Modbus e Modbus/TCP

O protocolo Modbus é um dos mais antigos e populares protocolos desenvolvidos para

sistemas de automação. Foi concebido ao ﬁnal da década de 1970 pela Modicon Industrial

Automation (atualmente Schneider Electric

), que em 2004 tornou a especiﬁcação do

protocolo livre e tem assistido o desenvolvimento de uma organização independente e

sem ﬁns lucrativos, responsável pela manutenção do protocolo, a Modbus-IDA

[Modbus-

IDA 2006a, Bies 2009].

O Modbus por si próprio é um protocolo da camada de aplicação (camada 7) o qual

oferece serviços que são especiﬁcados através dos códigos de função Modbus. O proto-

colo deﬁne regras para organização e interpretação de dados, mantendo uma estrutura de

mensagens mestre/escravo, independentemente do meio de transmissão utilizado (cama-

das inferiores). Ou seja, a especiﬁcação deﬁne regras que regem a troca de informações

entre dispositivos Modbus, mas nao estabelece os meios através dos quais essa troca é

viabilizada, fato ilustrado na Figura 3.1. A especiﬁcação original do Modbus recomen-

dava o padrão serial RS-232 como meio físico, mas muitas implementações mais recentes

utilizaram o padrão RS-485 [Bies 2009].

Por ser um protocolo simples e livremente disponível, é amplamente suportado por

vários fabricantes de dispositivos para automação industrial. Sua especiﬁcação deﬁne

dois modos de transmissão: RTU (Remote Terminal Unit) e ASCII (American Standard

Code for Information Interchange), que diferem apenas no modo em que os dados são

codiﬁcados para transmissão serial. O primeiro, mais utilizado, transmite mensagens co-

diﬁcadas em um formato binário compacto e utiliza CRC (Cyclic Redundancy Check)

para detecção de erros. O segundo, utilizado geralmente por dispositivos legados (legacy

devices) ou com propósitos didáticos, utiliza dois caracteres ASCII (legíveis) para cons-

truir os pacotes e utiliza LRC (Longitudinal Redundancy Check) para detecção de erros

[Modbus-IDA 2006a, Acromag 2005].

A Figura 3.2 ilustra o formato geral de quadro do protocolo Modbus, chamado de

ADU (Application Data Unit). É composto por um campo de endereçamento (Address),

a unidade funcional do protocolo, chamada de PDU (Protocol Data Unit), e um campo

de veriﬁcação de erros (Checksum). A PDU é formada pelos campos de código de função

(Function Code), que especiﬁca uma ação a ser realizada, e de dados (Data), contendo

informações referentes à ação requisitada pelo código de função, ou seja, dados referentes

http://www.schneiderelectric.com

http://www.modbus.org

CAPÍTULO 3. PROTOCOLOS MODBUS E MODBUS/TCP

Figura 3.1: Pilha de protocolos Modbus. Adaptado de [Modbus-IDA 2006a].

às respostas ou às exceções [Modbus-IDA 2006a, Acromag 2005].

Figura 3.2: Formato geral de quadro de dados do protocolo Modbus.

O tamanho máximo da ADU do protocolo Modbus é de 256 bytes, e consequente-

mente, a PDU do protocolo não deve ter mais que 253 bytes. Essa limitação foi herdada da

primeira implementação do protocolo sobre linhas seriais RS-485 [Modbus-IDA 2006a].

Essa característica também é encontrada na versão sobre TCP/IP do protocolo, o Mod-

bus/TCP, que será abordada mais adiante.

O formato padrão de quadro do Modbus pode transportar três tipos de mensagens do

protocolo: requisição (request), resposta (response) e exceção (exception) [Modbus-IDA

2006a]. As mensagens de requisição são enviadas pelo cliente para o servidor, que por

sua vez, responde essas requisições com mensagens de resposta ou de exceção (em caso

da ocorrência de algum erro no servidor), sem que haja modiﬁcação do formato padrão

do pacote. Um quadro da mensagem de resposta é construído utilizando o mesmo código

da requisição, juntamente com os dados referentes à resposta. Um quadro de exceção tem

como objetivo prover ao cliente informações relevantes sobre o erro detectado durante o

processamento da requisição pelo servidor. Este quadro é construído somando-se 0x80

(hexadecimal) ao código de função da requisição, constituindo um código de exceção,

que indica a provável razão do erro.

Os códigos de função correspondem às possíveis ações do protocolo, enquanto que

o campo Data diz respeito às informações necessárias para que a ação especiﬁcada no

código de função possa ser realizada. A maioria das ações do protocolo Modbus en-

volve operações de leitura e escrita do mestre em registradores do escravo. Assim, as

requisições do protocolo consistem, geralmente, da indicação do código de função, e, no

campo de dados, da indicação do endereço do registrador inicial (registrador de referên-

cia) e valor que geralmente está relacionado à quantidade de registradores que se deseja

manipular.

Os valores válidos para o campo Function Code variam de 1 a 255 (1 byte), sendo que

a faixa de valores entre 128 e 255 é utilizada para os códigos das mensagens de exceção

(Function Code + 0x80) [Modbus-IDA 2006a]. Os códigos de função do protocolo Mod-

bus são classiﬁcados em códigos públicos e códigos deﬁnidos pelo o usuário, distribuídos

na faixa de valores entre 1 e 127, como mostra a Figura 3.3. Os códigos de função públi-

cos são bem deﬁnidos, únicos e publicamente documentados na especiﬁcação oﬁcial do

protocolo. Logo, devem ser implementados e utilizados de acordo com a especiﬁcação.

Por outro lado, a faixa personalizável de códigos pode ser livremente implementada e uti-

lizada à critério dos fabricantes e usuários, embora não haja qualquer suporte ou garantia

de unicidade desses códigos de função por parte da Modbus-IDA.

Figura 3.3: Códigos de função do protocolo Modbus [Modbus-IDA 2006a].

A especiﬁcação do protocolo estabelece, ainda, que alguns códigos de função são

reservados. Estes códigos de função são utilizados somente por alguns fabricantes para

ﬁns de compatibilidade com dispositivos legados e, portanto, não estão disponíveis para

utilização pública.

CAPÍTULO 3. PROTOCOLOS MODBUS E MODBUS/TCP

3.1 Modbus/TCP

Ao ﬁnal da década de 1990, foi desenvolvida uma variante do protocolo Modbus,

que permite que o protocolo seja utilizado sobre TCP/IP, usando Ethernet como meio de

transmissão. Esta variante, nomeada Modbus/TCP, pode ser deﬁnida como uma versão

modiﬁcada do Modbus, em que um quadro originalmente serial Modbus, do tipo RTU, é

levemente alterado para ser transmitido através uma conexão TCP previamente estabele-

cida clientes (mestres) e servidores (escravos) [Acromag 2005, Modbus-IDA 2006b, Sim-

ply Modbus 2008].

O protocolo de transporte TCP, deﬁnido formalmente na RFC 793

, foi desenvolvido

para oferecer um ﬂuxo de dados ﬁm a ﬁm conﬁável, mesmo quando as partes envolvidas

estão separadas por redes heterogêneas [Tanenbaum 2003]. O protocolo caracteriza-se,

principalmente, por ser orientado a conexão e robusto à falhas. O TCP garante a entrega

dos dados (livre de erros) no destinatário e transmite fragmentos de dados, chamados seg-

mentos. Estes segmentos podem ser de dois tipos: segmentos de controle, responsáveis

pelo estabelecimento e ﬁnalização de conexões, e segmentos de dados, que transportam

os dados propriamente ditos (requisições e respostas). Para o estabelecimento de cone-

xões o protocolo utiliza o mecanismo de sincronização conhecido como negociação de

três vias (3-way handshake), onde as partes negociam os parâmetros da conexão antes

que comecem a trocar informações [Tanenbaum 2003, Stevens 1994]. A ﬁnalização de

conexões é realizada através de uma negociação semelhante.

Os dados do protocolo Modbus/TCP são, então, encapsulados em segmentos TCP

de dados de uma transação TCP previamente estabelecida. O fato de o protocolo Mod-

bus/TCP ser implementado sobre TCP caracteriza-o como um protocolo cliente/servidor

da camada de aplicação, no contexto do modelo TCP/IP. As mensagens do protocolo são

encapsuladas como os dados da carga útil (payload) de segmentos TCP, que não podem

ser utilizados para carregar mais de uma mensagem Modbus/TCP por vez.

Para a construção de um pacote Modbus/TCP, um quadro Modbus RTU, referido na

especiﬁcação do protocolo como ADU (Application Data Unit), tem seus campos de en-

dereço (Address) e de veriﬁcação de erros (Checksum) excluídos. Ao restante dos dados

é adicionado um cabeçalho especíﬁco para o protocolo Modbus/TCP, referido como ca-

beçalho MBAP (Modbus Application Protocol) , como ilustrado na Figura 3.4. Os dados

resultantes são então encapsulados na cargaútil de um segmentoTCP. O cabeçalho MBAP

é uma estrutura de 7 bytes que inclui os seguintes campos [Modbus-IDA 2006b, Acromag

2005]:

• Transaction Identiﬁer (2 bytes): é um campo de identiﬁcação de transações Mod-

bus/TCP. Este campo é usado para fazer a distinção de transações, quando múltiplas

mensagens são transmitidas através de uma mesma conexão TCP;

• ProtocolIdentiﬁer (2 bytes): é o campo de identiﬁcação do protocolo Modbus/TCP.

Seu valor padrão é 0000;

• Length (2 bytes): o valor deste campo representa a contagem de bytes dos cam-

pos restantes. Contém, portanto, a soma dos tamanhos dos campos Unit Identiﬁer,

Function Code and Data;

http://www.ietf.org/rfc/rfc0793.txt

3.1. MODBUS/TCP

• Unit Identiﬁer (1 byte): este campo é utilizado para roteamento interno. Identiﬁca

um servidor remoto localizado em uma rede não-TCP/IP, em situações em que redes

Modbus e Modbus/TCP se comunicam através de um gateway.

Figura 3.4: Construção de um pacote Modbus/TCP.

O processo de construção de um pacote Modbus/TCP, ilustrado na Figura 3.4, modi-

ﬁca um pacote Modbus RTU tradicional excluindo os campos responsáveis pela detec-

ção de erro e pelo endereçamento de dispositivos. O campo Checksum é desconsiderado

porque o Modbus/TCP conta com os métodos de detecção de erro padrões das camadas

inferiores (TCP/IP) para garantir a integridade dos dados. O campo de endereçamento

(Address) do Modbus serial é suplantado pelo campo Unit Identiﬁer no cabeçalho MBAP.

O campo Function Code juntamente com o campo Data compõem a PDU (Protocol Data

Unit), que, por sua vez, é concatenada à esquerda com o cabeçalho MBAP, formando a

Modbus/TCP ADU. Esta estrutura corresponde ao formato de pacote padrão do proto-

colo Modbus/TCP. A ADU do Modbus/TCP é encapsulada no campo de dados de um

segmento TCP em uma conexão TCP previamente estabelecida e é transmitido através de

uma rede TCP/IP. Cada segmento TCP pode somente transportar uma ADU por vez.

Apesar de o campo Length do cabeçalho MBAP, por ter 2 bytes, admitir um contagem

no valor de até 65535 bytes, a especiﬁcação do protocolo Modbus/TCP sugere em alguns

pontos que este campo normalmente carrega um valor bem inferior. Além disso, existe a

clara menção de que o tamanho máximo de uma ADU do Modbus/TCP deve ser de 260

bytes, dos quais 7 bytes correspondem ao cabeçalho MBAP e 253 bytes dizem respeito à

PDU do protocolo [Modbus-IDA 2006a]. Assim, o campo de dados (Data) do protocolo

não pode conter mais que 252 bytes. Como o campo Length carrega a soma dos tamanhos

dos campos Unit Identiﬁer, Function Code e Data, logo, pode indicar um valor máximo

não superior a 254 bytes.

As portas TCP/UDP (User Datagram Protocol) 502 foram especiﬁcamente designa-

das pela IANA

(Internet Assigned Numbers Authority) ao protocolo. Segundo a especiﬁ-

http://www.iana.org/assignments/port-numbers

CAPÍTULO 3. PROTOCOLOS MODBUS E MODBUS/TCP

cação, é obrigatório que as implementações do protocolo utilizem este número reservado

de porta [Modbus-IDA 2006b].

Alguns fabricantes utilizam uma conexão UDP ao invés de TCP para transportar

ADUs, também através da porta 502. Esta implementação, oﬁcialmente não suportada, é

referida normalmente como Modbus/UDP e é utilizada em aplicações especíﬁcas onde a

conﬁabilidade de uma conexão TCP não é requerida. Existe ainda a prática, embora me-

nos comum, de encapsular diretamente um quadro Modbus serial convencional em uma

conexão TCP. Essa variação é referida na literatura como Modbus-over-IP e é geralmente

praticada por gateways serial/Ethernet nas duas bordas de transmissões onde não há liga-

ção serial entre as partes envolvidas, utilizando-se uma infra-estrutura IP para transportar

quadros seriais [Simply Modbus 2008].

Uma abordagem mais abrangente aos protocolos Modbus e Modbus/TCP está fora do

escopo desta dissertação. Mais informações técnicas sobre estes protocolos podem ser

encontradas nos documentos de especiﬁcação dos mesmos, desenvolvidos e livremente

disponibilizados pela Modbus-IDA.

O próximo Capítulo descreve a motivação para o desenvolvimento deste trabalho.

Capítulo 4

Deﬁnição do Problema

O uso de tecnologias oriundas do setor de TI, especialmente as redes baseadas em

Ethernet e IP, nas camadas mais baixas de um sistema de automação, demanda uma sé-

rie de preocupações com a segurança que não eram cogitadas no passado, quando esses

sistemas eram restritos e isolados. Em vista disso, é importante ter um controle absoluto

dos dados que trafegam, por exemplo, em uma rede industrial baseada em TCP/IP que

transmite mensagens de protocolos industriais. Utilizar ﬁrewalls comuns (veriﬁcação de

IP/porta) é uma abordagem bem aceita, mas muitas vezes insuﬁciente, visto que alguns

protocolos industriais, em redes TCP/IP, constituem protocolos da camada de aplicação

e, portanto, ﬁrewalls convencionais não são capazes de inspecioná-los. É apropriado

construir um sistema ﬁrewall capaz de atuar sobre a camada de aplicação, entendendo

os protocolos industriais, para que seja possível a regulação rigorosa do tráfego. Nesta

Seção, serão expostas as situações de risco que impulsionaram o desenvolvimento de uma

solução ﬁrewall de aplicação especíﬁca para redes industriais, assim como os requisitos

estabelecidos para a etapa de desenvolvimento de software.

4.1 Cenários de Risco para Redes Industriais

Esta propensão em desenvolver um ﬁltro especíﬁco para protocolos industriais surgiu

durante estudos e sessões de testes desenvolvidos no LABSIN (Laboratório de Segurança

da Informação do DCA/UFRN), sobre a segurança de redes, dispositivos e protocolos

industriais baseados em TCP/IP. A partir desses estudos, vieram à tona duas situações em

que tráfego indesejado pode representar riscos à integridade das redes e dispositivos de

automação. A primeira delas diz respeito à presença de tráfego não-industrial nas redes

de automação e a segunda se refere à má utilização de ações dos protocolos por entidades

maliciosas. Ambas as situações nocivas podem ter seus efeitos minimizados através de

uma ﬁrewall de aplicação especíﬁca para o protocolo industrial alvo.

4.1.1 Presença de Tráfego Não-industrial em Redes Industriais

O tráfego referido nesta dissertação como não-industrial consiste em todo tráfego

cuja presença é imprópria ou inesperada em redes por onde deve transitar apenas tráfego

CAPÍTULO 4. DEFINIÇÃO DO PROBLEMA

oriundo de aplicações industriais. A presença de tráfego indevido em redes de automa-

ção pode representar um grande risco no que diz respeito à segurança da informação e

a integridade dos dispositivos e da planta. Informações importantes podem estar sendo

indevidamente acessadas ou dispositivos podem ter seu funcionamento comprometido

(ataques de negação de serviço) por entidades maliciosas internas ou externas à rede.

Torna-se importante, do exposto, o desenvolvimento de um dispositivo capaz de re-

alizar uma ﬁltragem sobre o tráfego de rede direcionado aos dispositivos de automação,

partindo da primitiva de que somente a passagem de tráfego em conformidade com as

especiﬁcações dos protocolos deve ser permitida. Uma vez que tal ﬁltro de protocolo é

utilizado, o tráfego nas partes protegidas da rede será essencialmente industrial, a pre-

ocupação com eventuais vulnerabilidades que os dispositivos possam ter será, portanto,

minimizada.

4.1.2 Má Utilização de Ações dos Protocolos

É possível aﬁrmar que a maioria dos protocolos industriais existentes, por terem sido

desenvolvidos em épocas em que a segurança de sistemas industriais não constituía uma

preocupação real, não dispõem de mecanismos intrínsecos de segurança. Os problemas

de integridade e disponibilidade são bem conhecidos e remediados, mas sob uma ótica de

segurança que visa à proteção do sistema contra erros acidentais, mal-funcionamento e

interferências. Esses protocolos não exibem mecanismos nativos de integridade e autenti-

cação que previnam que dados sejam maliciosamente manipulados ou que essa manipula-

ção seja facilmente detectável. Alguns mecanismos simples de autenticação, proteção de

acesso local (grupos de acesso) e proteção de memória estão presentes na camada de apli-

cação, mas, na maioria dos casos, representam apenas atributos de qualidade de serviço

ou proteção contra utilização errônea [Treytl et al. 2004].

Devido à ausência de mecanismos de conﬁdencialidade, integridade e autenticação,

é possível antever vários possíveis cenários em que o próprio protocolo industrial pode

ser utilizado para comprometer uma planta. Entidades maliciosas podem utilizar a ma-

nipulação de pacotes para explorar diversas ações dos protocolos. Uma vez que uma

entidade maliciosa consiga contornar estruturas de segurança e adentrar uma rede indus-

trial, esta pode, a partir de algum conhecimento prévio das características e limitações

dos dispositivos alvos, injetar na rede comandos não suportados, ilegais ou realizar opera-

ções inesperadas. A utilização indevida das ações dos protocolos por entidades maliciosas

pode ter conseqüências gravíssimas para a planta. Dispositivos podem ser maliciosamente

re-programados, re-conﬁgurados, comprometidos ou até mesmo levados à condição de

negação de serviço, a partir de ataques que injetam tráfego considerado legal, dada a

especiﬁcação do protocolo.

Um outro panorama de má utilização de comandos do protocolo é abordado em um

trabalho desenvolvido por [Carcano et al. 2008]. O trabalho consiste na construção de um

cenário de infecção de dispositivos em uma planta por malwares especiﬁcamente criados

para afetar dispositivos industriais que utilizam o protocolo Modbus/TCP. Neste trabalho,

é utilizada uma plataforma móvel de agentes que simula o comportamento (infecção e

propagação) de várias famílias de malwares. Neste cenário, máquinas clientes infectadas

4.2. REQUISITOS DE SOFTWARE

pelos malwares começam a lançar dois tipos de ataque sobre os servidores Modbus/TCP:

ataques de negação de serviço e ataques explorando as ações do protocolo. O primeiro

tipo de ataque tem como objetivo causar a dessincronização entre clientes e servidores

através do envio de uma grande quantidade de pacotes (ﬂood) Modbus/TCP, com objetivo

de forçar um estado de negação de serviço por saturação de banda no servidor Mod-

bus/TCP. Para este tipo de ataque, a maioria das ﬁrewalls modernas contam com mecanis-

mos nativos de proteção, como limitadores de banda e bloqueadores de ﬂood. O segundo

tipo de ataque abordado no artigo tem o intuito de tomar controle sobre os servidores,

explorando as ações do protocolo de maneira maliciosa. Entre as ações maliciosas estão

operações de escrita em uma quantidade grande de registradores de uma só vez e inversão

dos estados de registradores. Estas ações, teoricamente legais segundo a especiﬁcação

do protocolo, se realizadas por entidades maliciosas atuando como clientes Modbus/TCP

legítimos, podem alterar consideravelmente o comportamento de uma planta.

Essas situações, onde as ações do protocolo podem ser utilizadas com ﬁns maléﬁcos

para a planta, reforçam a importância do controle rigoroso sobre as ações do protocolo,

uma vez que requisições considerados legais segundo a especiﬁcação do protocolo podem

também ser utilizadas para ﬁns maliciosos, especialmente quando a entidade maliciosa

que lança esses ataques detém conhecimento sobre o comportamento, vulnerabilidades e

limitações dos dispositivos da planta. É conveniente, portanto, adicionar a essas redes um

dispositivo capaz impedir que certas requisições cheguem aos dispositivos.

Diante disso, é notável que para contornar tais situações de risco, uma alternativa

adequada seria o desenvolvimento de uma ﬁrewall de aplicação com a habilidade de reco-

nhecer os protocolos industriais, sendo capaz de bloquear todo tráfego ilegal ou indevido

que chegasse à rede de dispositivos de automação. Assim, de posse dessa perspectiva e

de insumos técnicos, a implementação de uma ﬁrewall deste tipo mostrou-se viável.

4.2 Requisitos de Software

Diante dessa problemática, foi estabelecida uma série de requisitos funcionais e não-

funcionais que deveriam nortear as etapas de desenvolvimento da aplicação de ﬁltragem

de pacotes.

Requisitos Funcionais

• A aplicação deve ter o comportamento de ﬁrewall, descartando pacotes contendo

tráfego indesejado. Ou seja, deve impedir, de forma ativa, a chegada desse tipo de

tráfego nos dispositivos;

• A aplicação deve ser uma prova de conceito de ﬁrewall de aplicação para redes

industriais;

• A ﬁrewall deve bloquear todo tráfego de rede que não possa ser classiﬁcado como

oriundo de uma aplicação industrial;

• A ﬁrewall deve ser capaz de realizar um controle rigoroso sobre as ações do proto-

colo industrial alvo. Todos os campos relevantes, que dizem respeito às ações do

protocolo, devem ser analisados;

CAPÍTULO 4. DEFINIÇÃO DO PROBLEMA

• As regras que regulam as ações devem ser individuais para cada dispositivo servidor

presente na rede;

• A aplicação deve ser capaz de realizar o registro (log) das operações de bloqueio de

pacotes, informando os endereços IP de origem e destino do pacote, assim como o

motivo pelo qual um pacote foi bloqueado.

Requisitos Não-funcionais

• A aplicação deve inﬂuir o mínimo possível no desempenho da rede. A latência

introduzida deve ser minimizada ao máximo, uma vez que em sistemas industriais

o tempo é um fator crítico e aumentos sensíveis de latência podem causar alteração

no funcionamento normal da planta;

• A aplicação deve ser construída sobre uma plataforma baseada em software livre;

• A aplicação deve fornecer uma interface gráﬁca para facilitar a conﬁguração.

O próximo Capítulo desta dissertação apresentará a solução de ﬁrewall de aplicação

proposta para resolver os problemas relativos ao tráfego indevido e ao mau uso das ações

dos protocolos.

Capítulo 5

Solução Proposta

Os problemas apresentados podem ser resolvidos a partir do desenvolvimento de um

sistema de ﬁrewall capaz de realizar a ﬁltragem sobre a camada de aplicação do ﬂuxo

de dados. A principal característica dessa abordagem é a de que a possibilidade de haver

tráfego malicioso atingindo dispositivos de automação pode ser reduzida ao se utilizar um

ﬁltro de protocolo que somente autorize a passagem de tráfego industrial, analisado sob

regras deﬁnidas sobre as ações permitidas. Neste esquema, todo tráfego de rede que não

está em conformidade com a especiﬁcação dos protocolos e com as regras deﬁnidas para

o protocolo é considerado anormal ou malicioso e deve ser, portanto, descartado.

O sistema proposto tem como principal componente uma aplicação em nível de usuá-

rio capaz de inspecionar tráfego de rede com relação à camada de aplicação, onde resi-

dem os dados de protocolos industriais que utilizam TCP/IP. Essa aplicação utiliza um

mecanismo de enﬁleiramento de datagramas IP (packet queueing) do sistema operacional

Linux para permitir que estes pacotes sejam processados em espaço do usuário. O pro-

cessamento em espaço de usuário, que constitui uma abordagem ﬂexível e independente

para o desenvolvimento de aplicações de ﬁltragem de pacotes, será abordado em deta-

lhes na sessão seguinte. O processamento sobre os pacotes consiste, fundamentalmente,

em analisar a carga útil de segmentos TCP, a ﬁm de identiﬁcar e aplicar regras sobre

os dados oriundos de protocolos industriais que operam sobre TCP/IP. Como estudo de

caso, consideramos o protocolo Modbus/TCP, por ser um protocolo industrial simples, de

especiﬁcação acessível e de relevância em redes industriais.

A análise de conformidade com a especiﬁcação do protocolo é importante para garan-

tir que tráfego não-industrial não esteja presente em uma rede industrial. Entretanto, além

desta análise, é desejável também que se possa realizar, já sobre o tráfego considerado le-

gítimo, uma veriﬁcação sobre os campos do protocolo, segundo regras estabelecidas pelo

usuário. Através de tal análise, um controle rigoroso sobre as ações do protocolo pode

ser efetuado, evitando a execução de procedimentos que possam ser julgados maliciosos,

danosos ou simplesmente fora de contexto para uma determinada rede industrial ou con-

junto de dispositivos. Embora uma funcionalidade semelhante já possa encontrada para o

protocolo Modbus/TCP na ﬁrewall de aplicação Modbus Firewall (mencionada na Seção

2.1), julgou-se conveniente realizar melhorias nesta funcionalidade, complementando a

ﬁrewall de aplicação proposta nesta dissertação. Sendo assim, a aplicação deve uniﬁcar a

aptidão de analisar a conformidade das requisições junto à especiﬁcação do protocolo e

CAPÍTULO 5. SOLUÇÃO PROPOSTA

de analisar essas requisições com relação a um cojunto de regras restritivas para as ações

do protocolo.

O sistema ﬁrewall em proposição é composto por dois módulos analisadores que se

complementam: um com a habilidade de realizar uma análise de conformidade com a

especiﬁcação do protocolo, baseado em expressões regulares, e o outro com a competên-

cia de veriﬁcar campos do pacote de requisição (request) Modbus/TCP, de acordo com

regras deﬁnidas pelo usuário para estes campos. Como a análise sobre os campos da

requisição tem o objetivo de restringir as ações do protocolo e estas correspondem às

requisições do do mesmo, o módulo competente só é acionado para pacotes oriundos

do cliente Modbus/TCP, ou seja, para pacotes de requisição Modbus/TCP. A Figura 5.1

ilustra o relacionamento entre esses módulos.

Figura 5.1: Módulos analisadores da ﬁrewall de aplicação para o Modbus/TCP.

A ﬁrewall foi desenvolvida com base na estratégia clássica de primeiramente negar

tudo (deny all) por padrão e deixar passar somente pacotes que estão em conformidade

com o padrão e condizem com regras permissivas pré-deﬁnidas. Assim, todos os paco-

tes são negados a não ser que sejam aprovados em uma série de testes executados em

cascata. Esses testes vão desde a veriﬁcação de conformidade com a especiﬁcação até a

veriﬁcação dos campos do pacote junto às regras deﬁnidas para estes campos, para cada

servidor Modbus/TCP. Após passarem pelos testes de conformidade com a especiﬁca-

ção do protocolo, os pacotes aprovados são veriﬁcados de acordo com regras deﬁnidas

para cada servidor Modbus/TCP na rede. Esta estratégia tem o intuito de limitar as ações

do protocolo para cada servidor Modbus/TCP, individualmente. Dessa forma, a partir

do conhecimento das limitações e problemas dos dispositivos, é possível escrever regras

garantindo que apenas tráfego correspondente às ações autorizadas chegue aos dispositi-

vos. Todo tráfego que não condiz com essas regras é considerado ilegal, sendo, portanto,

bloqueado.

As regras mencionadas correspondem à explicitação dos valores ou intervalo de valo-

5.1. TECNOLOGIAS E TÉCNICAS UTILIZADAS

res permitidos para os campos de um pacote Modbus/TCP que possa ser entregue a um

determinado servidor. A imposição de limites para estes campos implica diretamente na

limitação das ações do protocolo.

A solução proposta nesta dissertação consiste, ﬁsicamente, de um dispositivo ﬁrewall

que se localiza, em uma rede de automação, à frente de um dispositivo ou conjunto de

dispositivos Modbus/TCP que se deseja proteger de tráfego indesejado. Em outras pala-

vras, a ﬁrewall de aplicação pode ser alocada em segmento de rede situado entre o cliente

(ou clientes) e o servidor (ou servidores) Modbus/TCP. A Figura 5.2 ilustra os possíveis

locais de implantação da ﬁrewall de aplicação no diagrama mostrado na Figura 1.2.

A ﬁrewall proposta tem o intuito especíﬁco de proteger segmentos de rede em que o

tráfego deve ser estritamente industrial. Não foi, portanto, desenvolvida com o objetivo

de substituir os sistemas ﬁrewalls existentes, como os que costumeiramente protegem os

ambientes industriais dos ambientes corporativos. O intento da nossa ﬁrewall é traba-

lhar em conjunto com os sistemas de segurança existentes, agregando segurança também

aos dispositivos de camada mais baixas de um sistema de automação baseado em redes

TCP/IP.

Figura 5.2: Possíveis locais de implantação da ﬁrewall de aplicação em uma rede indus-

trial.

5.1 Tecnologias e Técnicas Utilizadas

Nesta Seção são abordadas as principais tecnologias e técnicas utilizadas no desen-

volvimento do sistema ﬁrewall proposto: o subsistema de regulação de tráfego do sistema

CAPÍTULO 5. SOLUÇÃO PROPOSTA

operacional Linux (Netﬁlter) como base para aceitação e bloqueio de pacotes, o sistema

de processamento de datagramas IP no espaço de usuário como mecanismo de captura de

pacotes para análise e a utilização de expressões regulares como técnica para o reconhe-

cimento de pacotes Modbus/TCP.

5.1.1 Regulação de Tráfego no Linux

A regulação de tráfego no sistema operacional Linux é realizado através de uma apli-

cação em espaço do kernel, o Netﬁlter, e de uma aplicação em espaço de usuário, o Ip-

tables. O Netﬁlter é um subsistema do kernel do Linux (kernel 2.4 e superiores) capaz

de executar procedimentos de controle de tráfego sobre a pilha de protocolos. Possui,

entre várias outras, as habilidades de stateful ﬁrewall, realizar rastreamento de cone-

xão e de realizar NAT (Network Address Translation) e PAT (Port Address Translation)

[Netﬁlter.org 2009]. Já o Iptables, é a aplicação em espaço de usuário que rege o Netﬁl-

ter. O Iptables provê uma estrutura de tabelas e cadeias para criação de regras que serão

utilizadas pelo Netﬁlter para regular o tráfego.

Com o Iptables, são deﬁnidas regras que são comparadas com o conteúdo dos pacotes,

juntamente com a ação que deve ser realizada pelo Netﬁlter para com os pacotes que

“casarem” com as regras deﬁnidas. O Netﬁlter admite uma vasta gama de ações (targets

ou jumps), embora as mais comuns sejam as ações de aceitar (ACCEPT) ou bloquear

(DROP) pacotes. No Iptables, as regras são agrupadas em cadeias (chains) que, por sua

vez, são agrupadas em tabelas (tables). As tabelas são estruturas relacionadas com tipo

de processamento que se deseja realizar sobre os pacotes (ﬁltragem, manipulação, NAT),

enquanto as cadeias são estruturas que organizam as regras segundo sua natureza e podem

ser pré-deﬁnidas ou criadas pelo o usuário [Suehring & Ziegler 2005, Andreasson 2006,

Burns et al. 2007].

A tabela ﬁlter é a tabela padrão do Iptables, responsável por permitir ou bloquear a

passagem de pacotes. Possui três cadeias pré-deﬁnidas [Andreasson 2006, Burns et al.

2007]

• INPUT: Agrega as regras voltadas a pacotes direcionados à máquina local.

• FORWARD: Concentra as regras dirigidas a pacotes roteados pela máquina local.

• OUTPUT: Reúne as regras sobre pacotes criados na máquina local.

Assim, como exemplo, pode-se ter uma regra de Iptables deﬁnida através do seguinte

comando:

# iptables -A INPUT -p tcp -j DROP

Com este comando, adiciona-se uma regra (-A) à cadeia INPUT (pacotes direcionados

à máquina local), estabelecendo que todos os pacotes IP contendo segmentos do protocolo

TCP (-p tcp) sejam descartados (-j DROP).

A infra-estrutura Netﬁlter/Iptables tem fundamental importância na ﬁrewall de aplica-

ção desenvolvida. O Iptables é utilizado principalmente por ser necessário para estabele-

cer uma regra que desvia o tráfego de seu curso para que este seja processado em espaço

5.1. TECNOLOGIAS E TÉCNICAS UTILIZADAS

de usuário. Já o Netﬁlter é a entidade com quem a aplicação em espaço do usuário se

comunica, sendo quem, de fato, aceita ou bloqueia os pacotes.

A grande vantagem de se construir um sistema de ﬁltragem de pacotes de propósito

especíﬁco utilizando como base essa infra-estrutura é o fato de que o Iptables pode ser

também utilizado em conjunto com a aplicação de ﬁltragem de pacotes, auxiliando-a.

Regras de Iptables podem ser estabelecidas para complementar o sistema, suprindo deﬁ-

ciências da aplicação de propósito especíﬁco. No caso do nosso sistema ﬁrewall, regras

de Iptables podem ser normalmente utilizadas, por exemplo, para bloquear outros tipos de

tráfego, restringir endereços IPs e portas, ou até mesmo para limitar a taxa de transmissão

do tráfego, prevenindo o sistema contra ataques de inundação de tráfego (ﬂood).

5.1.2 Inspeção de Datagramas IP no Espaço de Usuário

A abordagem mais comum ao se implementar ﬁrewalls de propósito especíﬁco, utili-

zando como estrutura base o sistema operacional Linux, consiste no desenvolvimento de

uma série de modiﬁcações (patches) para o Netﬁlter e, consequentemente, para o Iptables.

O desenvolvimento desses patches é uma tarefa custosa, uma vez que envolve manipula-

ção do código-fonte do kernel, requer um aprofundado conhecimento do funcionamento

do Netﬁlter e do Iptables, e no desenvolvimento de patches para o kernel (kernel pat-

ching). A adoção de tal abordagem torna todas as fases do desenvolvimento diretamente

dependentes de inúmeras compilações e instalações do kernel, o que, em geral, demanda

bastante tempo. Outra diﬁculdade relacionada à esta abordagem está no processo de dis-

tribuição do software, onde seria necessário o desenvolvimento de patches apropriados

para diversas versões do kernel do Linux.

Uma abordagem alternativa para evitar os problemas do desenvolvimento em nível do

kernel consiste em utilizar um cenário de processamento de pacotes em que datagramas

IP são capturados no espaço do kernel, trazidos ao espaço de usuário, onde são analisados

ou manipulados, e em seguida, autorizados a voltarem ao espaço do kernel, para que

possam ser liberados. Este procedimento pode ser entendido como um mecanismo de

“seqüestro” de datagramas, em que somente após processamento em nível de usuário,

estes datagramas seriam autorizados a dar continuidade às suas trajetórias através da rede.

Uma maneira de se realizar tal procedimento em um sistema Linux se dá pela utili-

zação do mecanismo de enﬁleiramento de datagramas para processamento em espaço de

usuário do Netﬁlter. Este sistema é capaz de passar datagramas IP do espaço do kernel

para o espaço de usuário, e, então, recebê-los de volta juntamente com um veredicto, es-

peciﬁcando a ação que o Netﬁlter deve tomar (aceitar ou descartar o datagrama) [Burns

et al. 2007, Libipq 2009, Netﬁlter 2009]. Um módulo manipulador de ﬁlas do kernel é

utilizado para interagir com o Netﬁlter e para desempenhar o mecanismo de passagem

de datagramas do espaço de kernel para o de usuário e vice-versa. Enquanto isso, uma

biblioteca é utilizada para permitir que aplicações em espaço de usuário obtenham acesso

a esses datagramas provenientes do espaço do kernel.

A principal vantagem dessa abordagem está na simplicidade de implementação. Dessa

forma, o programador pode direcionar sua atenção no desenvolvimento de ﬁrewalls ou

aplicações de manipulação de pacotes personalizadas inteiramente no espaço de usuário,

CAPÍTULO 5. SOLUÇÃO PROPOSTA

em um nível de abstração superior, de maneira alheia à complexidade envolvida na pro-

gramação orientada ao kernel. Além disso, esta abordagem não polui o código do kernel,

evitando problemas de instabilidade. Outra vantagem que merece ser destacada é a por-

tabilidade da aplicação, já que a mesma poderá ser executada em praticamente qualquer

distribuição Linux, independentemente da sub-versão do kernel. Além disso, o processo

de atualização da aplicação é bastante simples, não havendo sequer a necessidade de para-

lisação ou reinício do sistema durante o processo. Entretanto, uma preocupação existente

diz respeito à perda de desempenho relacionada com a jornada dos datagramas através

do espaço de usuário, o que pode constituir um obstáculo quando se deseja realizar ﬁltra-

gem sobre uma grande quantidade de tráfego ou em sistemas onde a latência é um fator

crítico. O desempenho da ﬁrewall de aplicação desenvolvida, baseada neste cenário, será

abordado mais adiante nesta dissertação.

O Módulo ip_queue

O manipulador de ﬁlas padrão para o IPv4 (Internet Protocol version 4) é o ip_queue

[Libipq 2009], provido como um módulo estável opcional do kernel do Linux, a partir da

versão 2.6. Este módulo utiliza um soquete Netlink (interface preferencialmente utilizada

no Linux para realizar a comunicação entre aplicações em espaço de usuário com o kernel

[Benvenuti 2005]) como canal de comunicação entre os espaços do kernel e de usuário.

Uma vez que o modulo é carregado, uma nova ação, chamada QUEUE, é adicionada às

possíveis ações que podem ser tomadas através de regras de Iptables. Assim, datagramas

IP podem ser selecionados no espaço do kernel com regras de Iptables usando a tabela

ﬁlter (padrão) e, em seguida, enﬁleirados para processamento no espaço de usuário através

da ação QUEUE. Um exemplo de regra que pode ser deﬁnida, direcionando pacotes para

a ação QUEUE, pode ser estabelecida com o comando:

# iptables -A INPUT -p udp -j QUEUE

Com esse comando, cria-se uma regra que deﬁne que todos os datagramas IP portando

datagramas UDP que chegarem à cadeia INPUT (pacotes direcionados à máquina local)

devem ser direcionados à ação QUEUE.

A Biblioteca libipq

Uma vez que um datagrama IP encontra-se acessível na ﬁla para processamento, é

possível acessá-lo integralmente através de uma biblioteca chamada libipq [Libipq 2009].

Esta biblioteca, escrita em linguagem C, provê uma API (Application Programming Inter-

face) para comunicação entre programas em espaço de usuário com o módulo ip_queue.

Logo, qualquer aplicação que utilize esta biblioteca poderá acessar os datagramas enﬁ-

leirados e processá-los em espaço de usuário, de modo similar ao tratamento que seria

realizado em espaço do kernel, utilizando, inclusive, as mesmas estruturas de dados que

o kernel utiliza.

Fazendo uso da biblioteca libipq e do módulo ip_queue, é possível realizar prati-

camente qualquer tipo de processamento de datagramas no espaço de usuário, desde

5.1. TECNOLOGIAS E TÉCNICAS UTILIZADAS

simplesmente estipular um veredicto de aceitação ou negação para os datagramas, a até

mesmo manipular o conteúdo de seus campos (packet mangling).

Figura 5.3: Relacionamento entre o módulo ip_queue e a biblioteca libipq.

Devido às características supracitadas, esta estratégia mostrou-se conveniente para o

desenvolvimento da ﬁrewall de propósito especíﬁco proposta. Sob este contexto, datagra-

mas IP em uma rede Modbus/TCP podem ser seqüestrados no nível do kernel e subme-

tidos a testes de conformidade em uma aplicação no nível de usuário, que deverá, então,

determinar se os datagramas serão aceitos ou descartados pelo Netﬁlter.

5.1.3 Expressões Regulares

Expressões regulares são notações de padrões que permitem descrever e analisar da-

dos. Ilustrativamente, podem ser entendidas como mini-linguagens de programação ca-

pazes de descrever, gerar e identiﬁcar seqüências de caracteres (strings) especíﬁcas. Es-

sas expressões constituem uma ferramenta poderosa, ﬂexível e eﬁciente, comumente

empregada em diversas tarefas que envolvam a análise e o reconhecimento de dados

[Friedl 2006].

As expressões regulares são ferramentas encontradas em processadores de texto, lin-

guagens de programação (ferramentas, compiladores e interpretadores) e em diversos

aplicativos. No contexto das aplicações relacionadas com redes de computadores, as ex-

pressões regulares podem ser empregadas por sistemas que realizam a análise e reconhe-

cimento de tráfego de rede, como Sistemas de Detecção de Intrusos (Intrusion Detection

Systems - IDS), ﬁrewalls, sniffers, analisadores de protocolos, servidores proxy, sistemas

de controle de conteúdo, entre outros. Nestes sistemas, os dados de tráfego de rede obtidos

são convertidos para um formato adequado e podem ser processados através de sistemas

que implementam expressões regulares.

Expressões regulares são geralmente compostas por dois tipos de caracteres: caracte-

res especiais, chamados de meta-caracteres, e os caracteres literais. As expressões regu-

lares podem ser compreendidas como linguagens em que caracteres literais atuam como

palavras e os meta-caracteres como a gramática. As palavras são combinadas com a gra-

CAPÍTULO 5. SOLUÇÃO PROPOSTA

mática de acordo com um conjunto de regras, criando uma expressão capaz de comunicar

uma idéia [Friedl 2006].

Existem várias maneiras de se trabalhar com expressões regulares. Uma delas é atra-

vés das linguagens de programação, visto que muitas delas possuem suas ferramentas

próprias de manipulação de expressões regulares. Além disso, temos os compiladores e

interpretadores, que são outros exemplos de sistemas que utilizam expressões regulares

em sua essência. Outra forma se dá através do uso de bibliotecas independentes próprias

para criação e processamento de expressões regulares.

Uma popular biblioteca desse tipo é a PCRE (Perl Compatible Regular Expressions),

normalmente disponível ou de fácil instalação na maioria das distribuições do Linux

[PCRE 2009]. A biblioteca PCRE é escrita em linguagem C e é munida de um con-

junto de funções e procedimentos que implementam a análise de expressões regulares,

utilizando a mesma sintaxe e semântica do sistema de expressões regulares da linguagem

Perl [PCRE 2009].

A biblioteca PCRE (libpcre) foi escolhida como ferramenta, pois mune o programador

da linguagem C de um sistema de expressões regulares simples, popular, eﬁciente e de

documentação extensa, já que toda a documentação do sistema de expressões regulares da

linguagem Perl pode ser utilizada [Perl 2009]. A biblioteca fornece sua própria API, o que

torna simples o uso das funções da libpcre pelas aplicações que a utilizam. As funções

principais da biblioteca são

pcre_compile()

, que compila a expressão regular fornecida,

pcre_exec()

, que realiza a comparação entre o padrão compilado e o conjunto de

caracteres alvo da análise.

A aplicação ﬁrewall faz uso da biblioteca PCRE como o principal sistema de reco-

nhecimento do protocolo industrial escolhido para estudo de caso, o Modbus/TCP. Em

uma aplicação executada em espaço de usuário, a biblioteca PCRE, juntamente com ex-

pressões regulares desenvolvidas especiﬁcamente para o Modbus/TCP, é utilizada para

realizar uma análise de conformidade sobre datagramas IP capturados, veriﬁcando se es-

ses datagramas contém pacotes Modbus/TCP válidos.

As expressões regulares devem ser desenvolvidas com base na especiﬁcação do pro-

tocolo, sendo capaz de suportar todos os três tipos de mensagem Modbus/TCP. Para isso,

pelo menos duas expressões regulares precisam ser desenvolvidas, uma para mensagens

oriundas dos clientes (requisições) e outra para mensagens oriundas dos servidores (res-

postas e mensagens de exceção). Expressões regulares de boa qualidade para o proto-

colo Modbus/TCP podem considerar todos os campos do formato padrão de pacote Mod-

bus/TCP que não variam em tamanho (em bytes), ou seja, todos os campos menos o

campo variável de dados do protocolo (Data). Foram, portanto, desenvolvidas expres-

sões regulares que consideram todos os campos do cabeçalho MBAP e o campo Function

Code da PDU do protocolo, totalizando 8 bytes do pacote

As expressões regulares para o protocolo Modbus/TCP podem realizar uma veriﬁca-

ção de concordância sobre todos os possíveis valores do cabeçalho MBAP e do campo

Function Code (os 8 primeiros bytes de cada pacote Modbus/TCP) para mensagens de

requisição do protocolo. Expressões regulares mais reﬁnadas podem ser desenvolvidas

de acordo com a necessidade, abrangendo o campo de dados do protocolo, mesmo este

sendo de tamanho variável, o que pode ser contornado através do desenvolvimento de

5.1. TECNOLOGIAS E TÉCNICAS UTILIZADAS

expressões regulares condicionais (utilização das primitivas lookbehind e backreferences

[Perl 2009] do sistema de expressões regulares do Perl).

No processo de análise, uma representação adequada dos pacotes passantes é subme-

tida à função

pcre_exec()

, através da qual o tráfego passante é submetido a uma veriﬁ-

cação de conformidade com o padrão estabelecido (expressão regular do protocolo). Com

a utilização desse mecanismo de exame, é possível reconhecer pacotes Modbus/TCP, os

únicos tipos de pacotes que devem trafegar em uma rede industrial Modbus/TCP.

O proximo Capítulo aborda a estruturação do sistema ﬁrewall proposto nesta disserta-

ção.

CAPÍTULO 5. SOLUÇÃO PROPOSTA

Capítulo 6

Arquitetura do Sistema

A ﬁrewall de aplicação em questão é montada em uma plataforma computacional do

tipo PC (Personal Computer), dotada de no mínimo duas interfaces de rede (Ethernet),

tendo o Linux (kernel 2.6) como sistema operacional. O sistema Linux deve ter seu

mecanismo de roteamento de pacotes habilitado, fazendo com que o PC atue como um

dispositivo roteador entre as redes do cliente e do servidor Modbus/TCP.

Nesse PC, é deﬁnida uma regra de Iptables que direciona o tráfego alvo de análise (da-

tagramas IP contendo segmentos TCP) à ação QUEUE, responsável pela disponibilização

destes pacotes em uma ﬁla no espaço de usuário. A utilização do Iptables é imprescin-

dível somente pela necessidade de utilização da ação QUEUE para que os pacotes sejam

processados em espaço de usuário. O PC executa a aplicação responsável pela análise dos

pacotes, a qual foi dado o nome de Modbus Filter. Esta aplicação é incumbida de resgatar

os pacotes na ﬁla, utilizando a biblioteca libipq, e de realizar análises sobre os mesmos

(principalmente utilizando a biblioteca PCRE), decidindo, em seguida, se esses pacotes

serão aceitos ou rejeitados. O sistema é capaz de realizar análise de pacotes oriundos

tanto da rede do cliente quanto da rede do servidor Modbus/TCP. A Figura 6.1 resume a

arquitetura do sistema, ilustrando a trajetória dos pacotes através do ﬁltro e as relações

entre os componentes do sistema.

A arquitetura do sistema reúne uma plataforma de hardware do tipo PC, as habilidades

de roteamento e regulação de tráfego do sistema operacional Linux, e uma aplicação

em nível de usuário responsável pelo processamento dos pacotes repassados da rede do

cliente para a rede do servidor Modbus/TCP (e vice-versa).

6.1 A aplicação Modbus Filter

A aplicação ﬁrewall desenvolvida consiste em um programa escrito em linguagem C

que emprega a biblioteca libipq para capturar pacotes para processamento em espaço de

usuário e a biblioteca de expressões regulares PCRE para realizar uma análise de con-

formidade dos pacotes Mobdus/TCP através de expressões regulares características do

protocolo. Além disso, vários campos dos pacotes Modbus/TCP são submetidos a testes

de concordância com regras pré-deﬁnidas para os campos analisados.

O programa implementa uma seqüência de operações de análise sobre todos os seg-

mentos TCP passantes, sejam eles de controle da conexão ou de dados. Esses segmentos

CAPÍTULO 6. ARQUITETURA DO SISTEMA

Figura 6.1: Arquitetura do sistema ﬁrewall.

6.1. A APLICAÇÃO

MODBUS FILTER 33

são extraídos de datagramas IP contendo segmentos TCP, selecionados pelo Iptables, atra-

vés da opção “-p tcp”. A cada segmento recebido, é disparada uma seqüência de testes

a qual a carga útil desses segmentos é submetida, a ﬁm de determinar se o datagrama

IP correspondente será repassado de uma rede para a outra ou descartado pelo sistema

ﬁrewall.

6.1.1 Modos de Operação

A aplicação possui dois modos de operação que dizem respeito à ativação dos mó-

dulos mencionados no Capítulo 5. No primeiro modo, chamado de modo 0, apenas o

módulo analisador de conformidade com o protocolo Modbus/TCP é ativado, e, portanto,

a ﬁrewall de aplicação realiza somente a análise de conformidade sobre os pacotes. A Fi-

gura 6.2 mostra o ﬂuxograma deste modo de operação, descrevendo o ﬂuxo das análises

realizadas pelo programa sobre segmentos TCP, antes do descarte ou aceitação do pacote

IP correspondente.

No segundo modo de operação, chamado de modo 1, ambos os módulos (analisador

de conformidade e analisador sobre os campos) são ativados. Logo, em conjunto, esses

módulos realizam uma análise completa sobre o pacote Modbus/TCP, tanto com relação

à conformidade com o protocolo quanto com relação às regras permissivas deﬁnidas pelo

usuário. A Figura 6.3 ilustra o ﬂuxograma da seqüência de análises realizadas pela apli-

cação ﬁrewall, sendo executada sob o modo 1 de operação.

A implementação dessa aplicação envolve chamadas às funções da biblioteca libipq,

para capturar datagramas IP e deﬁnir veredictos aos mesmos, e chamadas às funções

da biblioteca PCRE, para realizar a análise de conformidade dos pacotes com relação

especiﬁcação do protocolo. Além disso, o módulo analisador de campos realiza uma

veriﬁcação de concordância entre os campos dos pacotes Modbus/TCP recebidos pela

ﬁrewall e as regras permissivas deﬁnidas pelo usuário, explicitadas em um arquivo de

regras.

6.1.2 Arquivos de Conﬁguração

A aplicação utiliza dois arquivos de conﬁguração: um arquivo de inicialização e um

arquivo de regras da ﬁrewall. O arquivo de inicialização contém informações relativas à

conﬁguração da ﬁrewall em si, como os nomes e os endereços IP das interfaces da ﬁrewall

e as expressões regulares para o protocolo Modbus/TCP. O arquivo de regras contém o

inventário de dispositivos da rede, onde estão armazenadas informações relativas às ca-

racterísticas dos servidores Modbus/TCP. Neste arquivo, os dispositivos são identiﬁcados

com seus respectivos endereços IP e são deﬁnidas as regras, permitindo determinadas

ações do protocolo, para cada servidor, individualmente.

O arquivo de inicialização é lido a cada inicialização da ﬁrewall enquanto que o ar-

quivo de regras só é lido quando a ﬁrewall é iniciada sob o modo de operação 1, onde é

necessário que o conhecimento do inventário de dispositivos. A reiniciação da ﬁrewall é

requerida para que as modiﬁcações dos arquivos de conﬁguração obtenham efeito.

CAPÍTULO 6. ARQUITETURA DO SISTEMA

Figura 6.2: Fluxograma de operações da aplicação Modbus Filter, sob o modo 0.

6.1. A APLICAÇÃO

MODBUS FILTER 35

Figura 6.3: Fluxograma de operações da aplicação Modbus Filter, sob o modo 1.

CAPÍTULO 6. ARQUITETURA DO SISTEMA

6.1.3 Interface Gráﬁca com o Usuário

Uma interface gráﬁca com o usuário foi desenvolvida, com o intuito de facilitar o

processo de síntese dos arquivos de conﬁguração e de regras. A interface é bastante

simpliﬁcada, tendo o objetivo principal fornecer formulários que podem ser preenchidos

à critério do usuário, com dados que são usados para a geração dos arquivos utilizados

pela ﬁrewall. Uma vez que a ﬁrewall de aplicação pode ser montada em uma plataforma

embarcada, desprovida suporte a vídeo, optou-se pelo desenvolvimento de uma interface

web, escrita em HTML (layout) e PHP (processamento dos formulários).

A Figura 6.4 mostra uma captura de tela do formulário referente à criação do arquivo

de conﬁguração da ﬁrewall. É possível veriﬁcar campos em branco para os parâmetros

do arquivo de inicialização e um visualizador do conteúdo desse arquivo embutido na

interface. Na Figura 16, é mostrada um formulário semelhante para criação do arquivo de

regras, onde também é possível visualizar o conteúdo do arquivo criado.

Figura 6.4: Formulário para geração do arquivo de inicialização do Modbus Filter.

6.1. A APLICAÇÃO

MODBUS FILTER 37

Figura 6.5: Formulário para geração do arquivo de regras do Modbus Filter.

CAPÍTULO 6. ARQUITETURA DO SISTEMA

Através da interface gráﬁca também é possível deﬁnir os modos de operação, visua-

lizar os registros das operações da ﬁrewall e reiniciar o sistema para que as novas conﬁ-

gurações entrem em vigor. O próximo Capítulo aborda os resultados obtidos na fase de

testes da ﬁrewall.

Capítulo 7

Resultados

Neste Capítulo, serão apresentados os resultados obtidos com a aplicação já em es-

tágio funcional, explicitando o ambiente de testes utilizado e os testes realizados para

validar a aplicação com relação aos requisitos estabelecidos. Ao ﬁnal do Capítulo, será

apresentado o resultado de uma análise de desempenho baseada na medição da latência

introduzida pela ﬁrewall de aplicação no ambiente de testes.

7.1 Ambiente de Testes

Os ciclos de desenvolvimento e testes da aplicação foram realizados sob um ambiente

de testes (testbed) que remonta, de maneira simpliﬁcada, uma rede industrial contendo

clientes e servidores Modbus TCP. O ambiente de testes, ilustrado na Figura 7.1, consiste

no estabelecimento de duas sub-redes de dispositivos, sendo uma correspondente à rede

dos clientes Modbus/TCP (rede 192.168.200.0/24) e outra relativa aos servidores Mod-

bus/TCP (rede 192.168.100.0/24). Em ambas as redes, switches idênticos são utilizados.

Estas sub-redes estão segmentadas por um roteador que executa a ﬁrewall de aplicação

Modbus Filter. Para ﬁns de visualização e para realização de testes de desempenho, cada

rede é monitorada através da utilização de dispositivos TAP (Test Access Port) acoplados

a computadores que executam a aplicação Wireshark (analisador de protocolos). A utili-

zação de TAPs se deu pela necessidade de se ter dispositivos monitores completamente

passivos e transparentes à rede. Como estes dispositivos teoricamente não introduzem la-

tência na rede, mostram-se adequados para uso em tarefas de monitoramento e avaliação

de desempenho.

Os clientes são computadores do tipo PC executando o sistema operacional Linux.

São capazes de injetar vários tipos de tráfego na rede, através de uma interface de rede

Ethernet, desde tráfego Modbus/TCP (tanto tráfego legal quanto tráfego ilegal) a tráfego

comum em ambientes de TI, como o tráfego oriundo de aplicações de produção e escritó-

rio, de ferramentas de administração de redes e tráfego malicioso oriundo de vermes, ví-

rus e ataques. O tráfego Modbus/TCP (legal e ilegal) é gerado através de uma ferramenta

para geração e manipulação de tráfego industrial com suporte ao protocolo Modbus/TCP

[T. H. Kobayashi & Pires 2007], também desenvolvida no LABSIN. Esta ferramenta é

capaz de manipular todos os campos de um pacote Modbus/TCP, sendo possível gerar

tráfego de qualquer ação do protocolo, assim como tráfego mal-formado.

CAPÍTULO 7. RESULTADOS

Figura 7.1: Diagrama do ambiente de testes montado.

A ﬁrewall de aplicação foi implementada sobre um computador do tipo PC que utiliza

um processador Intel



Celeron

ULV de 630 MHz e 2 Gigabytes de memória RAM.

Este PC é dotado de duas interfaces de rede Ethernet idênticas, às quais são atribuídos os

endereços IP das rede dos clientes e dos servidores. Sobre este PC é executado o sistema

operacional Linux (kernel 2.6.27), com as funcionalidades de roteamento habilitadas e

devidamente conﬁgurado como roteador entre as redes dos clientes e dos servidores. O

sistema executa o aplicativo ﬁrewall desenvolvido, tornando o dispositivo roteador capaz

de analisar pacotes sobre a camada 7, repassando, de uma rede para a outra, os pacotes

legais e bloqueando os pacotes ilegais.

O servidores Modbus/TCP consistem, de fato, de PCs que executam uma aplicação

capaz de atender à requisições Modbus/TCP. Esta aplicação, chamada jamod, consiste de

uma implementação do protocolo Modbus completamente escrita em linguagem Java, que

pode ser utilizada para implementar, com propósitos educacionais, clientes e servidores

Modbus, sob as diversas variantes do protocolo [Jamod 2009]. O jamod foi, então, conﬁ-

gurado como servidor Modbus/TCP, escutando à porta 502/TCP destes PCs. Este cenário

foi utilizado para que fosse possível simular uma rede homogênea constituída de vários

servidores Modbus/TCP, uma vez que dispomos apenas de um servidor Modbus/TCP ge-

nuíno. Como o a analise é sobre a ﬁrewall desenvolvida, este cenário não prejudica os re-

sultados. Em um cenário real, estes servidores corresponderiam, por exemplo, a módulos

Modbus/TCP de CLPs (Controlador Lógico Programável) ou qualquer outro dispositivo

de automação que suporte o protocolo Modbus/TCP.

7.2 Testes Realizados

Foi deﬁnido um cronograma de testes que envolveu o disparo de vários tipos de trá-

fego contra a sub-rede dos servidores Modbus/TCP, comprovando o funcionamento e a

eﬁcácia do sistema ﬁrewall desenvolvido. O tráfego típico dos ambientes de TI, como o

tráfego oriundo de scanners de rede (nmap

, nessus

), tráfego de aplicações para acesso

remoto (telnet, ssh) e o tráfego oriundo de vermes e ataques comuns às redes de TI, foi

http://www.insecure.org

http://www.nessus.org

7.2. TESTES REALIZADOS

satisfatoriamente bloqueado. Exceto pelos segmentos TCP de controle, cuja passagem

é livre através da ﬁrewall, todo tráfego oriundo dessas aplicações é bloqueado por não

passar no teste de conformidade com as expressões regulares do protocolo. A Figura 7.2

mostra uma captura de tela do sniffer Wireshark no Monitor 1, onde é capturado o tráfego

de uma sessão telnet, propositalmente estabelecida entre um cliente e um servidor Mod-

bus/TCP. Um dos clientes abre uma sessão telnet na porta TCP 502 de um dos servidores

e envia o texto “Hello!”. É possível notar, devido às retransmissões subseqüentes do seg-

mento causadas pela falta de conﬁrmação de recebimento do segmento pelo servidor, que

a ﬁrewall bloqueou a mensagem enviada pelo cliente. A Figura 7.3 exibe as mensagens

de saída da ﬁrewall ao processar um segmento deste tipo, onde é possível constatar que a

mensagem foi bloqueada por não passar no teste de conformidade para o protocolo Mod-

bus/TCP. A Figura 7.4, referente à captura de tráfego realizada pelo Monitor 2, mostra

que na rede dos servidores há apenas tráfego TCP relativo ao 3-way handshake, ou seja, o

tráfego da requisição inválida (segmento TCP com carga útil desconforme) não penetrou

a rede dos servidores Modbus/TCP.

Figura 7.2: Captura de tela do Wireshark no Monitor 1, exibindo o envio de uma mensa-

gem via telnet por um cliente para um servidor Modbus/TCP.

Figura 7.3: Captura de tela das mensagens de saída da ﬁrewall ao receber um segmento

cuja carga útil está em desconformidade com o protocolo Modbus/TCP.

CAPÍTULO 7. RESULTADOS

Figura 7.4: Captura de tela do Wireshark no Monitor 2, mostrando que o segmento con-

tendo dados em desconformidade não penetrou na rede dos servidores Modbus/TCP.

Utilizando a ferramenta de manipulação de pacotes Modbus/TCP, foram gerados vá-

rios tipos de pacotes Modbus/TCP mal-formados. Através da manipulação de campos do

cabeçalho MBAP e da PDU do protocolo, foram gerados vários tipos de requisições in-

válidas, como requisições excedendo o valor máximo de 260 bytes de tamanho total, com

o campo de identiﬁcação do protocolo (Protocol Identiﬁer) inválido, utilizando códigos

de função não suportados pela especiﬁcação e requisições cujo campo Length indicava

um valor diferente do valor real. Em todos os casos, todos os pacotes mal-formados fo-

ram bloqueados com sucesso. A Figura 7.5 exibe uma captura de tela do Monitor 1, no

momento em que um dos clientes envia uma requisição Modbus/TCP malformada. Nesta

requisição, o campo Length do cabeçalho MBAP do protocolo foi manipulado, indicando

o valor de 10 bytes quando deveria indicar 6 bytes (tamanho real calculado para esta re-

quisição). Na Figura 7.6, as mensagens de saída da ﬁrewall ao processar tal requisição

mostram que, apesar da requisição ter sido aprovada no teste de expressão regular, não

passou no teste de veriﬁcação do campo Length. A Figura 7.7 mostra que tal requisição

inválida não chegou aos servidores Modbus/TCP.

Requisições Modbus/TCP legais segundo a especiﬁcação, mas que correspondiam às

ações que não estavam expressamente autorizadas no arquivo de regras da ﬁrewall, tam-

bém foram bloqueadas com sucesso. A Figura 7.8 mostra a captura de tela do tráfego no

Monitor 1, quando é enviada uma requisição Modbus/TCP não autorizada. A requisição

utiliza o código de função 15, tendo o valor 6 como indicador do registrador de referência.

Entretanto, no arquivo de regras, está explicitado que este valor não está autorizado para

o servidor alvo e, em vista disso, a requisição foi bloqueada. Isto pode ser constatado

pelas sucessivas retransmissões dessa requisição. A Figura 7.9 mostra as mensagens de

saída da ﬁrewall ao receber uma requisição Modbus/TCP não autorizada, enquanto que a

Figura 7.10 mostra, através da captura de tela do tráfego no Monitor 2, que para a rede

dos servidores somente o tráfego relativo ao 3-way handshake foi autorizado a passar.

Em suma, os problemas que motivaram o desenvolvimento do sistema, relativos à

presença de tráfego não-industrial na rede de dispositivos industriais e à má utilização

de ações de um protocolo, mencionados no Capítulo 4, foram remediados através do

bloqueio de pacotes pelo sistema ﬁrewall desenvolvido.

7.2. TESTES REALIZADOS

Figura 7.5: Captura de tela do Wireshark no Monitor 1, exibindo o envio de uma requisi-

ção Modbus/TCP malformada por um cliente para um servidor Modbus/TCP.

Figura 7.6: Captura de tela das mensagens de saída da ﬁrewall ao receber uma requisição

Modbus/TCP com o campo Length indicando um valor incorreto.

Figura 7.7: Captura de tela do Wireshark no Monitor 2, mostrando que o segmento con-

tendo dados em desconformidade não penetrou na rede dos servidores Modbus/TCP.

CAPÍTULO 7. RESULTADOS

Figura 7.8: Captura de tela do Wireshark no Monitor 1, exibindo o envio de uma requisi-

ção Modbus/TCP não autorizada por um cliente para um servidor Modbus/TCP.

Figura 7.9: Captura de tela das mensagens de saída da ﬁrewall ao receber uma requisição

Modbus/TCP não autorizada para um determinado servidor.

Figura 7.10: Captura de tela do Wireshark no Monitor 2, mostrando que a requisição

Modbus/TCP não autorizada não adentrou à rede dos servidores Modbus/TCP.

7.3. DESEMPENHO

7.3 Desempenho

O desempenho de ﬁrewalls pode ser avaliado sob diversos pontos de vista e utilizando

diversas métricas. Dependendo do tipo e do grau de soﬁsticação da ﬁrewall sob teste,

diversos parâmetros e métricas podem ser levados em consideração. Entre os vários pa-

râmetros [Gabole & Conklin 2003, Technologies 2004] que podem ser examinados para

avaliar o desempenho de ﬁrewalls, estão:

• Latência introduzida pela ﬁrewall;

• Latência versus tamanho dos datagramas IP;

• Tempo gasto no estabelecimento e ﬁnalização de conexões TCP;

• Tempo gasto na transferência de dados da camada de aplicação;

• Número máximo de conexões TCP ativas;

• Número máximo de novas conexões por segundo;

• Número total de conexões concadeias suportadas pela ﬁrewall;

• Máximo throughput suportado;

• Taxa de transferência média;

• Taxa de transferência multi-protocolo;

• Comportamento da ﬁrewall em estado de saturação de recursos;

• Dependência entre desempenho e o tamanho do conjunto de regras;

• Porcentagem de uso dos recursos de hardware da ﬁrewall.

A métrica selecionada para medir o desempenho da ﬁrewall de aplicação desenvol-

vida foi a avaliação da latência inserida pela mesma no ambiente de testes montado. Essa

escolha deu-se porque a latência é um fator de extrema importância em sistemas críticos

e, por isso, um dos requisitos não-funcionais estabelecidos para a aplicação foi de que a

latência introduzida fosse a menor possível. De posse da medida de latência, é possível

estimar o possível impacto da implantação de uma ﬁrewall deste tipo em uma rede de dis-

positivos industriais, avaliando a viabilidade da utilização deste dispositivo no ambiente

desejado.

Outros parâmetros, como os supracitados, poderiam ter sido avaliados. Entretanto,

como a ﬁrewall desenvolvida utiliza a infra-estrutura do sistema operacional Linux (ha-

bilidades de roteamento e a utilização do Netﬁlter), ela herda as várias características de

desempenho desses sistemas. Alguns trabalhos sobre o desempenho das habilidades do

Linux como roteador e do Netﬁlter podem ser encontrados na literatura [Kadlecsik &

Pásztor 2002, Harris et al. 2002].

O estudo desta seção visa avaliar o impacto em latência dos componentes que formam

a ﬁrewall de aplicação, com atenção particular à aplicação em espaço de usuário que

realiza a análise dos pacotes.

7.3.1 Técnica Utilizada

O foco desta Seção é avaliar a latência inserida pela ﬁrewall no trânsito dos pacotes

que são processados pela aplicação e encaminhados de uma rede para outra. Essa avalia-

ção diz respeito ao desempenho da ﬁrewall como dispositivo, o que, consequentemente,

CAPÍTULO 7. RESULTADOS

deve abranger as latências geradas tanto pelo processo de roteamento de pacotes quanto

pelo processamento de pacotes no espaço de usuário. É interessante medir a latência in-

serida por cada elemento potencialmente introdutor de latência, para que seja possível

apontar, após o estudo, o fator que mais causa degradação de desempenho na ﬁrewall.

Para a realização desse estudo, foi escolhida uma técnica comumente utilizada para

avaliar o comportamento de redes baseadas em TCP/IP, que consiste da medição de tempo

de viagem completa (Round-Trip Time - RTT) das informações. O RTT é a medida do

intervalo de tempo levado pelo trânsito de uma informação em um circuito fechado. Ou

seja, é o tempo levado para que uma informação chegue ao receptor e a sua conﬁrmação

ou resposta seja recebida de volta ao emissor [Stevens 1994]. É possível inferir, portanto,

que a medida do RTT está diretamente relacionada com a latência da rede. O cálculo

de amostras de RTT tem grande importância no gerenciamento de redes, sendo utilizado

para identiﬁcar segmentos da rede com grande latência e auxiliar na tomada de decisões

sobre remodelagem da rede [But et al. 2005].

Em se tratando do protocolo TCP, este intervalo é computado como a diferença entre

o tempo em que um segmento é enviado e o tempo em que uma conﬁrmação (ACK)

referente àquele segmento em particular é recebido. O cálculo do RTT é fundamental para

o protocolo TCP, cuja implementação utiliza tal medida como um dos parâmetros para

calcular o tempo limite para retransmissão (Retransmission Timeout - RTO) de segmentos

[Stevens 1994].

A ﬁrewall de aplicação desenvolvida utiliza-se das habilidades de roteamento de um

sistema operacional e atua inspecionando a carga útil de segmentos TCP no espaço de

usuário. Evidentemente, esses processos são potenciais elevadores de latência. Uma

medida média dos RTTs das transações Modbus/TCP (requisição/resposta) pode indicar a

magnitude da latência inserida pela ﬁrewall no repasse de pacotes IP contendo segmentos

TCP com dados de mensagens Modbus/TCP do cliente para o servidor e vice-versa. Esse

estudo pode ser utilizado para avaliar a viabilidade, no contexto da latência inserida, da

implantação de um sistema ﬁrewall deste tipo em redes industriais.

7.3.2 Metodologia

A metodologia adotada consiste no cálculo dos RTTs com relação aos segmentos uti-

lizados, em uma conexão TCP, para transportar mensagens Modbus/TCP. A partir da cap-

tura do tráfego relativo a essas transações TCP, é possível calcular os RTTs dos segmentos

enviados, tanto a partir do cliente (requisições) quanto a partir do servidor (respostas).

Nos experimentos realizados, as amostras de RTT são calculadas a partir dos segmentos

que partem do cliente para o servidor, ou seja, o RTT é calculado com base na diferença

de tempo entre o envio de uma requisição Modbus/TCP pelo cliente e o recebimento da

respectiva resposta no mesmo.

O cálculo dos RTTs dos segmentos foi realizado a partir do tráfego capturado por um

dos computadores monitores no ambiente de testes montado. Estes computadores exe-

cutam o analisador de protocolos Wireshark, que além de capturar o tráfego, é também

capaz de realizar o cálculo dos RTTs, a partir do tráfego TCP capturado. O Wireshark é

também capaz de gerar gráﬁcos das amostras de RTT calculadas com relação ao número

7.3. DESEMPENHO

de seqüência dos segmentos. Como complemento a este procedimento de análise de de-

sempenho, foi utilizado o programa tcptrace

, capaz de produzir algumas estatísticas a

partir do tráfego TCP capturado. Nestes experimentoso tcptrace é utilizado para calcular

a média e o desvio padrão sobre as amostras de RTT capturadas.

Em um dos clientes, a ferramenta de manipulação de pacotes é conﬁgurada para en-

viar requisições Modbus/TCP de vários tamanhos (tamanho da carga útil do segmento

TCP), desde o tamanho mínimo de 8 bytes até o tamanho máximo de 260 bytes. Os testes

foram realizados para os vários tamanhos estabelecidos para essas requisições, mas não

foram detectadas diferenças relevantes nos resultados pelo uso de requisições de tama-

nhos diferentes. Todas as requisições foram transmitidas em uma mesma conexão TCP.

Como a mídia física/enlace utilizada na interconexão entre os componentes do testbed é

o Ethernet, a qual é uma tecnologia de comunicação de natureza não-determinística por

utilizar o CSMA/CD (Carrier Sense Multiple Access/Collision Detection) como proto-

colo de acesso ao meio, é conveniente que se obtenha um número elevado de amostras de

RTT, para que a validade estatística dos experimentos seja aumentada. Com base nessas

amostras, é possível calcular o RTT médio e o desvio padrão para as amostras de RTT.

Estes parâmetros podem reﬂetir uma boa idéia do desempenho da rede analisada [Sessini

& Mahant 2006].

A captura de tráfego referente às requisições Modbus/TCP foi realizada sob algumas

variações nas características do dispositivo roteador/ﬁrewall entre as redes dos clientes e

dos servidores Modbus/TCP. Essas situações foram criadas para que se pudesse realizar

uma avaliação de latência gradual, à medida que são adicionados neste sistema os fato-

res que potencialmente aumentariam a latência da comunicação. As situações foram as

seguintes:

1. O dispositivo que segmenta as redes (PC roteador) é substituído por um switch. Ou

seja, os clientes e servidores estão situados na mesma rede, interligados através de

um switch. O objetivo de estabelecer este cenário é calcular os RTTs em uma situ-

ação onde o grau de separação entre clientes e servidores é o menor possível, para

que esta medida possa servir como base de comparação para os RTTs calculados

nas outras situações;

2. O dispositivo que segmenta as redes é apenas um PC executando o sistema operaci-

onal Linux conﬁgurado como roteador de pacotes. Assim, o dispositivo encaminha

diretamente os pacotes da rede dos clientes para a rede dos servidores e vice-versa.

O objetivo aqui é simplesmente avaliar o aumento de latência causada por um ele-

mento que encaminha pacotes de uma rede para a outra;

3. O PC roteador, antes de encaminhar os pacotes, direciona-os para processamento

no espaço de usuário, mas nenhum processamento é realizado. A aplicação em

espaço de usuário simplesmente autoriza que os pacotes voltem ao espaço do kernel

e continuem seus trajetos. O objetivo deste cenário é avaliar o custo de latência

adicionado pelo trajeto dos pacotes através do espaço de usuário, antes de serem

encaminhados no processo de roteamento;

4. O PC roteador executa o Modbus Filter sob o modo 0 de operação. O intuito neste

http://www.tcptrace.org

CAPÍTULO 7. RESULTADOS

cenário é estimar o custo em latência causado pelo processamento do pacote Mod-

bus/TCP realizado pela aplicação, com apenas o analisador de conformidade com a

especiﬁcação ativado;

5. O PC roteador executa o Modbus Filter sob o modo 1 de operação. O objetivo

é avaliar a latência inserida pelo processamento dos pacotes com a aplicação em

funcionamento pleno, ou seja, com os dois módulos analisadores ativados.

Foi estabelecido o número de 50000 requisições enviadas sequencialmente pelos cli-

entes nos testes para cada situação. Consequentemente, foi possível obter 50000 amostras

de RTT para requisições Modbus/TCP. Esta quantidade de amostras foi deﬁnida arbi-

trariamente, de modo que fosse suﬁcientemente elevado para validar estatisticamente o

experimento e para melhor visualização da latência inserida.

7.3.3 Gráﬁcos de RTT e Avaliação de Desempenho

A partir do tráfego capturado em cada uma das situações descritas é possível, através

do Wireshark, imprimir um gráﬁco das amostras de RTT calculadas com relação aos nú-

meros de seqüência dos segmentos TCP. Uma análise do conjunto de amostras de RTT

fornece-nos uma estimativa da latência em uma determinada conexão TCP.

A Figura 7.11 mostra o gráﬁco que representa amostras de RTT calculadas para a

situação 1. Assim como esperado, esta é a situação de menor latência, já que não há seg-

mentação entre as redes. As 50000 requisições levaram aproximadamente 11 minutos e

12 segundos para serem realizadas, a uma taxa de throughput de 892 B/s (bytes/segundo).

O RTT médio calculado foi de 9,9 ms e o desvio padrão para as amostras foi de 0,6 ms.

Na Figura 7.12 temos o gráﬁco das amostras de RTT para a situação 2. Pode-se

notar claramente uma elevação generalizada dos RTTs calculados sobre as requisições.

Esse aumento de latência era esperado e deu-se devido à introdução de um dispositivo

de roteamento de pacotes na rede. As requisições levaram um tempo de 13 minutos e 20

segundos, a uma taxa de 750 B/s. O RTT médio foi de 12,7 ms e o desvio padrão foi de

0,7 ms.

Para a situação 3, o gráﬁco dos RTTs calculados está representado na Figura 7.13. Re-

lembremos que esta situação foi estabelecida para avaliar o impacto em latência causado

pela jornada dos pacotes através do espaço de usuário (sem qualquer tipo de processa-

mento) antes da etapa de roteamento. A uma taxa de 749 B/s, as requisições levaram 13

minutos e 22 segundos para serem executadas. Comparando os gráﬁcos dessa situação

com o da anterior, nota-se que houve uma elevação muito sensível dos valores de RTT. O

RTT médio calculado foi de 12,8 ms e o desvio padrão para as amostras foi de 0,7 ms. O

experimento foi repetido várias vezes e os resultados sempre se aproximaram muito dos

resultados obtidos nos experimentos realizados sob a situação 2. Pode-se concluir, por-

tanto, que o custo de latência relacionado com esse percurso dos pacotes através espaço

de usuário é muito baixo.

Na Figura 7.14 temos os RTTs para a situação 4, na qual deseja-se avaliar o custo em

latência do processamento promovido pela ferramenta em seu modo de operação mais

simplista, em que os pacotes são analisados somente com relação à conformidade com a

especiﬁcação do protocolo Modbus/TCP, ou seja, onde uma análise de concordância entre

7.3. DESEMPENHO

Figura 7.11: Gráﬁco das amostras de RTT para a situação 1, em que servidores e clientes

Modbus/TCP estão na mesma rede, interligados através de um switch.

Figura 7.12: Gráﬁco das amostras de RTT para a situação 2, em que há um roteador entre

as redes dos clintes e dos servidores Modbus/TCP.

CAPÍTULO 7. RESULTADOS

Figura 7.13: Gráﬁco das amostras de RTT para a situação 3, onde os pacotes passam pelo

espaço de usuário antes de ser encaminhados.

os pacotes e uma expressão regular para o protocolo é realizada. O processo de envio de

requisições levou 15 minutos e 38 segundos para ser completado, sob uma taxa 639 B/s.

Observando o gráﬁco, nota-se que houve um aumento considerável nos valores de RTT,

devido ao processo de análise das requisições junto às expressões regulares do protocolo.

O RTT médio calculado foi de 15,6 ms e o desvio padrão foi de 1 ms.

A Figura 7.15 ilustra os RTTs calculados na situação 5. Nesta situação, deseja-se

avaliar o impacto em latência da ﬁrewall em seu modo completo de operação, ou seja,

com seus dois módulos de análise ativados. Desse modo, é possível avaliar a degradação

de desempenho relacionada com as análises sobre requisições Modbus/TCP segundo as

ações expressamente permitidas pelo usuário para cada servidor Modbus/TCP. No arquivo

de regras foram explicitados dois servidores Modbus/TCP. O envio das requisições tomou

16 minutos e 29 segundos, a uma taxa de 606 B/s. O gráﬁco mostra um aumento consi-

derável nos valores de RTT com relação à situação 4. O RTT médio para esta situação

foi de 16,6 ms e o desvio padrão foi de 1 ms. Esta situação mostra que a utilização da

ﬁrewall em seu modo completo de operação impõe no sistema um aumento de latência de

aproximadamente de 60%.

O teste da situação 5 foi repetido para avaliar a inﬂuência do tamanho do conjunto

de regras na latência. Foram produzidos arquivos de regras de vários tamanhos (quanti-

dade de servidores Modbus/TCP). O resultado que se obteve é de que a latência aumenta

muito sensivelmente à medida que o conjunto de regras aumenta, até que certo gargalo

é atingido. Com 100 servidores conﬁgurados, o RTT médio obtido foi de 16,7 ms. Para

1000 servidores, o RTT médio cresce para 18,3 ms. Já com 10000 servidores conﬁgu-

7.3. DESEMPENHO

Figura 7.14: Gráﬁco das amostras de RTT para a situação 4, em que a ﬁrewall opera sob

o modo 0.

Figura 7.15: Gráﬁco das amostras de RTT para a situação 5, onde a ﬁrewall opera sob o

modo 1.

CAPÍTULO 7. RESULTADOS

rados no arquivo de regras, o RTT médio salta para 60,5 ms. Este fato leva à conclusão

de que, para o sistema desenvolvido, há uma degradação de desempenho proporcional ao

número de servidores Modbus/TCP conﬁgurados no arquivo de regras. Entretanto esse

aumento é sensível até que um gargalo é atingido e, a partir deste, o RTT médio cresce

exponencialmente.

A Tabela 7.1 sumariza os resultados de latência obtidos para todas as situações.

Situação

RTT médio (ms) Desvio Padrão (ms)

9,9 0,6

12,7 0,7

12,8 0,7

15,6 1,0

16,6 1,0

Tabela 7.1: Resumo dos resultados de latência para cada situação.

7.4 Limitações

Além das questões relativas à latência, a ﬁrewall de aplicação desenvolvida possui

algumas limitações originárias da sua própria natureza e das tecnologias utilizadas.

7.4.1 Conexões TCP Abertas

A primeira limitação, que é natural das ﬁrewalls de aplicação, diz respeito ao descarte

de datagramas IP contendo segmentos TCP com dados não autorizados. Esse descarte

interfere no ﬂuxo da conexão TCP, já que nenhuma das partes envolvidas na conexão tem

qualquer conhecimento desse descarte. Isso dispara uma série de ações nos dispositivos,

que podem depender da implementação do software cliente/servidor ou da implementação

pilha TCP/IP dos dispositivos. Por exemplo, para o caso do testbed montado, ao ocorrer

um descarte de um datagrama IP pela ﬁrewall, a conexão TCP continua aberta por tempo

indeterminado em ambos os lados da conexão, até que a conexão seja forçadamente ﬁna-

lizada por um dos lados através de um segmento TCP de ﬁnalização (FIN) ou abortagem

(RST) da conexão. Nesse meio tempo, a pilha TCP/IP dos PCs que fazem as vezes de

clientes Modbus/TCP se encarrega de retransmitir, por um número ﬁnito de vezes, o seg-

mento cuja conﬁrmação de recebimento não foi obtida. Obviamente, estas retransmissões

são prontamente bloqueadas pela ﬁrewall, e a conexão TCP permanece aberta em ambos

os lados, até que o cliente pára de enviar retransmissões e, supondo que o servidor não

está mais a receber, desiste da conexão, sem enviar mais segmentos. Assim, a conexão

TCP ﬁca em estado de half-open (parcialmente aberta) para o servidor, visto que este

não sabe que, na outra ponta, o cliente não está mais na escuta. Essa situação persiste

até que se ordene que o servidor termine a conexão (fechando a aplicação), enviando um

segmento do tipo FIN para o cliente. Como no cliente não há mais qualquer informa-

ção sobre aquela conexão a qual o servidor referencia, este cliente envia um servidor um

7.4. LIMITAÇÕES

segmento abortando a conexão (RST). Somente após isso, neste cenário em especíﬁco, é

que se pode dizer que a conexão que teve segmentos TCP descartados pela ﬁrewall está

ﬁnalizada em ambos os lados. Como já mencionado, essa situação muda de acordo com

a implementação da pilha TCP/IP e das aplicações dos clientes e servidores.

O problema de se ter conexões TCP/IP não ﬁnalizadas, em ambos os lados, está no

fato de que, por razões óbvias, cada cliente ou servidor é capaz de gerir um número

ﬁnito de conexões. Quando esse limite é atingido, cada implementação pode lidar de uma

forma, seja ﬁnalizando imediatamente as conexões mais antigas para dar espaço às novas,

seja simplesmente negando novas conexões TCP. Ao implantar uma ﬁrewall deste tipo na

rede, o comportamento dos clientes e servidores diante de descartes de segmentos deve

ser avaliado.

7.4.2 Fila de Datagramas

A outra limitação da ﬁrewall diz respeito ao sistema de enﬁleiramento de pacotes uti-

lizado. Este sistema, que disponibiliza datagramas IP no espaço de usuário, consiste no

direcionamento do tráfego passante, à medida que os datagramas chegam, para uma ﬁla de

tamanho ﬁxo (embora manualmente ajustável), cuja cabeça é disponibilizada para ser lida

pela aplicação em espaço de usuário. Por ter tamanho limitado, enquanto esta ﬁla esti-

ver lotada, os datagramas subseqüentes serão automaticamente descartados pelo Netﬁlter.

Contudo, a ﬁla, que tem o tamanho padrão de 1024 posições, pode ser ajustada indeﬁ-

nidamente até um tamanho limitado pela quantidade de memória física da máquina. O

ajuste na quantidade de posições não é realizado automaticamente, mas é possível ajustar

este tamanho dinamicamente, à medida que um tamanho maior de ﬁla é demandado.

Na prática, este ajuste não se mostrou necessário, visto que em todos os testes reali-

zados, poucos pacotes chegaram a ser enﬁleirados. Ou seja, o tempo processamento de

datagramas realizado pela aplicação não é suﬁcientemente grande para que a ﬁla atinja

um tamanho avantajado, mesmo com toda a carga de tráfego que se conseguiu produzir.

CAPÍTULO 7. RESULTADOS

Capítulo 8

Conclusões e Trabalhos Futuros

Nesta dissertação relata-se uma abordagem alternativa para o desenvolvimento de ﬁl-

tros da camada de aplicação (ﬁrewalls de aplicação) para redes industriais. O trabalho

exibe os detalhes de como uma aplicação em nível de usuário, baseada em bibliotecas de

enﬁleiramento de pacotes e expressões regulares, foi desenvolvida com o objetivo de pro-

teger dispositivos industriais de tráfego não-industrial e de ações indesejadas, prevenindo

que esses dispositivos tenham comportamento anômalo. Este estudo deu foco às camadas

mais baixas da pirâmide de um sistema de automação, ao nível de dispositivos indus-

triais que se comunicam sobre TCP/IP. O protocolo Modbus/TCP foi escolhido por sua

simplicidade e alta relevância nas redes industriais. O sistema desenvolvido distingue-

se de outra solução de propósito semelhante para o protocolo Modbus/TCP[Franz &

Pothamsetty 2004], já que possui a capacidade de realizar uma análise de conformidade

com a especiﬁcação do protocolo sobre os pacotes e pode executar uma inspeção mais

aprofundada nas requisições (ações do protocolo). Este desenvolvimento demonstra a

viabilidade de se implementar, de maneira simples, ﬁltros de aplicação capazes de cons-

truir canais de comunicação cujo tráfego é limitado ao tráfego de protocolos industriais e,

ainda, referente às ações autorizadas desses protocolos em uma determinada rede indus-

trial. Os resultados obtidos mostraram que a aplicação desenvolvida soluciona o problema

de proteger dispositivos Modbus/TCP potencialmente vulneráveis contra tráfego indese-

jado, através do bloqueio de todo tráfego que não condiz com requisições legais do pro-

tocolo. Entretanto, foi constatado que o sistema desenvolvido possui algumas limitações

e que sua implantação causa um aumento considerável na latência da rede. Uma análise

do comportamento do tráfego em redes industriais reais poderá determinar se a latência

introduzida pela implantação da ﬁrewall é insatisfatória, o que justiﬁcaria o desenvolvi-

mento de melhorias estruturais no sistema. Como extensão para o sistema desenvolvido,

o suporte a outros protocolos industriais baseados em TCP/IP, como o DNP3/IP, IEC

60870-5-104 e o Ethernet/IP, pode ser adicionado. Além disso, julga-se conveniente o

desenvolvimento de um sistema de processamento de regras, para que estas possam ser

validadas e otimizadas.

CAPÍTULO 8. CONCLUSÕES E TRABALHOS FUTUROS

Referências Bibliográﬁcas

Acromag (2005), Introduction To Modbus TCP/IP, Acromag Incorporated.

URL: http://www.acromag.com/pdf/intro_modbusTCP_765a.

pdfusTCP_765a.pdf

Andreasson, Oskar (2006), Iptables Tutorial 1.2.2.

URL: http://iptables-tutorial.frozentux.net/

iptables-tutorial.html

Benvenuti, Christian (2005), Understanding Linux Network Internals, O’Reilly.

Bies, Lammert (2009), ‘Modbus Interface Tutorial’.

URL: http://www.lammertbies.nl/comm/info/modbus.html.

Burns, Bryan, Jennifer Stisa Granick, Steve Manzuik, Paul Guersch, Dave Killion, Ni-

colas Beauchesne, Eric Moret, Julien Sobrier, Michael Lynn, Eric Markham, Chris

Iezzoni & Philippe Biondi (2007), Security Power Tools, 1

edição, O’Reilly.

But, J., U. Keller, D. Kennedy & G. Armitage (2005), ‘Passive TCP Stream Estimation of

RTT and Jitter Parameters’, IEEE Conference on Local Computer Networks .

Byres, E. & D. Hoffmann (2003), The Myths and Facts behind Cyber Security Risks for

Industrial Control Systems, Relatório técnico.

URL: http://www.isa.org/link/cyber_myth_fact

Byres, E., J. Karsch & J. Carter (2005), ‘NISCC Good Practice Guide on Firewall De-

ployment for SCADA and Process Control Networks’. Visitado em Julho de 2009.

URL: http://www.cpni.gov.uk/Docs/re-20050223-00157.pdf

Carcano, A., I. Nai Fovino, M. Masera & A. Trombetta (2008), Scada Malware, a proof

of Concept, em ‘Conference Pre-Proceedings of the 3rd International Workshop on

Critical Information Infrastructures Security (CRITIS’08)’, pp. 247–257.

Creery, A. & E. Byres (2005), ‘Industrial Cybersecurity For Power System And Scada

Networks’, 52nd Industry Applications Society Conference on Petroleum and Che-

mical Industry pp. 303–309.

Dzung, D., M. Naedele, T. P. Von Hoff & M. Crevatin (2005), Security for Industrial

Communication Systems, em ‘Proceedings of IEEE’, Vol. 93, pp. 1152–1177.

REFERÊNCIAS BIBLIOGRÁFICAS

Franz, Matthew & Venkat Pothamsetty (2004), ‘Transparent Modbus/TCP Filtering with

Linux’. Visitado em Julho de 2009.

URL: http://modbusfw.sourceforge.net/

Friedl, Jeffrey E. F. (2006), Mastering Regular Expressions, 3

edição, O’Reilly.

Gabole, H. & N. Conklin (2003), Firewall Testing Methodology Using Spirent Solutions,

Spirent Communications. Visitado em Julho de 2009.

URL: http://www.spirent.com/documents/1095.pdf

Harris, James, Americo J. Melara, Hugh Smith & Phillip Nico (2002), Performance

Analysis of the Linux Firewall in a Host, Dissertação de mestrado, Faculty of Cali-

fornia Polytechnic State University.

I.Network Automation (2009), ‘Pyramid Model’. Visitado em Julho de 2009.

URL: http://www.inetlb.com/inet/Component/Static/

Pyramid.asp

Jamod (2009), ‘jamod’. Visitado em Julho de 2009.

URL: http://jamod.sourceforge.net

Kadlecsik, J. & J. Pásztor (2002), ‘Netﬁlter Performance Testing’. Visitado em Julho de

2009.

URL: http://people.netfilter.org/kadlec/nftest.pdf

Kraken Automation (2009), ‘Kraken Automation System Pyramid’. Visitado em Julho

de 2009.

URL: http://www.krakenautomation.com/prod_Automation_

Overview.htm

Krutz, Ronald L. (2006), Securing SCADA Systems, Willey, Indianapolis, Indiana, EUA.

Libipq (2009), ‘Libipq - Iptables userspace packet queuing library’. Visitado em Julho de

2009.

URL: http://linux.die.net/man/3/libipq

Lobashov, M. & T. Sauter (2006), ‘Vertical Communication from the Enterprise Level to

the Factory Floor - Integrating Fieldbus and IP-based Networks’, 11th IEEE Con-

ference on Emerging Technologies and Factory Automation (ETFA’06) pp. 1214–

1221.

Mitsubishi Electric Automation (2009), ‘PLC Q Series - Networking Solutions’. Visitado

em Julho de 2009.

URL: http://www.meau.com/eprise/main/Web_Site_

Pages/Public/Products/Product_Selection_Guide/

PLC-Q-Series-SG-Section/P-Q-Networks

REFERÊNCIAS BIBLIOGRÁFICAS

Modbus-IDA (2006a), Modbus Application Protocol Speciﬁcation, Modbus-IDA. Visi-

tado em Julho de 2009.

URL: http://www.modbus.org/docs/Modbus_Application_

Protocol_V1_1b.pdf

Modbus-IDA (2006b), Modbus Messaging on TCP/IP Implementation Guide, Modbus-

IDA. Visitado em Julho de 2009.

URL: http://www.modbus.org/docs/Modbus_Messaging_

Implementation_Guide_V1_0b.pdf

Netﬁlter (2009), ‘Linux Netﬁlter Hacking HOWTO’. Visitado em Julho de 2009.

URL: http://www.netfilter.org/documentation/HOWTO/

netfilter-hacking-HOWTO-4.html

Netﬁlter.org (2009), ‘Linux Netﬁlter’. Visitado em Julho de 2009.

URL: http://www.netfilter.org

P. C. Group & NISCC (2005), ‘Good Practice Guide: Process Control and SCADA Secu-

rity’. Visitado em Julho de 2009.

URL: http://www.cpni.gov.uk/docs/re-20051025-00940.pdf

Paukatong, T. (2005), ‘SCADA Security: A New Concerning Issue of an In-house EGAT-

SCADA’, 2005 IEEE/PES Transmission and Distribution Conference and Exhibi-

tion: Asia and Paciﬁc pp. 1–5.

PCRE (2009), ‘PCRE - Perl Compatible Regular Expressions’.

URL: http://www.pcre.org

Perl (2009), ‘perlre - Perl regular expressions’.

URL: http://perldoc.perl.org/perlre.html

Pires, P. S. M. & L. A. H. G. Oliveira (2006), Security Aspects of SCADA and Corporate

Network Interconnection: An Overview, em ‘International Conference on Dependa-

bility of Computer Systems, 2006’, pp. 127–134.

Pollet, J. (2002), ‘Developing a Solid SCADA Security Strategy’, Sensors for Industry

Conference (Sicon/02) pp. 19–21.

Sauter, T. (2005), ‘Integration Aspects in Automation - a Technology Survey’, 10th IEEE

Conference on Emerging Technologies and Factory Automation (ETFA’05) 2, 19–

22.

Sessini, P. & A. Mahant (2006), ‘Observations on Round-Trip Times of TCP Connecti-

ons’.

Simply Modbus (2008), ‘Modbus TCP/IP’. Visitado em Julho de 2009.

URL: http://www.simplymodbus.ca/TCP.htm.

Stevens, W. Richard (1994), TCP/IP Illustrated, Vol. 1, Addison-Wesley.

REFERÊNCIAS BIBLIOGRÁFICAS

Stouffer, K., J. Falco & K. Kent (2006), ‘Guide to Supervisory Control and Data

Acquisition (SCADA) and Industrial Control Systems Security’, NIST Special

Publication (800-82). Visitado em Julho de 2009.

URL: http://csrc.nist.gov/publications/drafts/800-82/

2nd-Draft-SP800-82-clean.pdf

Suehring, S. & R. Ziegler (2005), Linux Firewalls, 3

edição, Sams Publishing.

T. H. Kobayashi, A. B. Batista, A. M. Brito & P. S. M. Pires (2007), ‘Using a Packet Ma-

nipulation Tool for Security Analysis of Industrial Network Protocols’, IEEE Confe-

rence on Emerging Technologies and Factory Automation, 2007. ETFA pp. 744–747.

Tanenbaum, A. S. (2003), Redes de Computadores, 4

edição, Elsevier.

Technologies, Agilent (2004), Evaluating Application-aware Firewall Performance,

Agilent Technologies. Visitado em Julho de 2009.

URL: http://advanced.comms.agilent.com/networktester/

docs/whitepapers/pdfs/5989-1672EN.pdf

The Harting Technology Group (2009), ‘The automation pyramid’. Visitado em Julho de

2009.

URL: http://www.harkis.harting.com/WebHelp/GBDEV/

WebHelp/GBDEVThe_automation_pyramid.htm

Treytl, A., T. Sauter & C. Schwaiger (2004), Security Measures for Industrial Fieldbus

Systems - State of the Art and Solutions for IP-based Approaches, em ‘Proceedings

of IEEE International Workshop on Factory Communication Systems’, pp. 201–209.

Livros Grátis
( http://www.livrosgratis.com.br )
 
Milhares de Livros para Download:
 
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas

Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo
 
 