0% acharam este documento útil (0 voto)

6 visualizações81 páginas

Firewall Hierárquico em SDN

Enviado por

xohadev603

Direitos autorais

Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.

Formatos disponíveis

Baixe no formato PDF, TXT ou leia on-line no Scribd

0% acharam este documento útil (0 voto)

6 visualizações81 páginas

Firewall Hierárquico em SDN

Enviado por

xohadev603

Direitos autorais

Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.

Formatos disponíveis

Baixe no formato PDF, TXT ou leia on-line no Scribd

Dados Internacionais de Catalogação-na-Publicação (CIP)

Divisão de Informação e Documentação

Takata, Ruy Minoru Ito
Modelo de Firewall para Redes Definidas por Software com Verificação de Conflitos de Regras
Hierárquicas / Ruy Minoru Ito Takata.
São José dos Campos, 2017.
80f.

Dissertação de Mestrado – Curso de Pós-Graduação em Engenharia Eletrônica e da

Computação. Área de Informática – Instituto Tecnológico de Aeronáutica, 2017. Orientadora:
Profa . Dra . Cecı́lia de Azevedo Castro César.

1. SDN. 2. Firewall. 3. Segurança. I. Centro Técnico Aeroespacial. Instituto Tecnológico de

Aeronáutica. Divisão de Engenharia Eletrônica. II. Um Firewall Hierárquico para Redes
Definidas por Software com Verificação de Conflitos de Regras.

REFERÊNCIA BIBLIOGRÁFICA
TAKATA, Ruy Minoru Ito. Modelo de Firewall para Redes Definidas por
Software com Verificação de Conflitos de Regras Hierárquicas. 2017. 80f.
Dissertação de Mestrado – Instituto Tecnológico de Aeronáutica, São José dos Campos.

CESSÃO DE DIREITOS
NOME DO AUTOR: Ruy Minoru Ito Takata
TITULO DO TRABALHO: Modelo de Firewall para Redes Definidas por Software com
Verificação de Conflitos de Regras Hierárquicas.
TIPO DO TRABALHO/ANO: Dissertação / 2017

É concedida ao Instituto Tecnológico de Aeronáutica permissão para reproduzir cópias

desta dissertação e para emprestar ou vender cópias somente para propósitos acadêmicos
e cientı́ficos. O autor reserva outros direitos de publicação e nenhuma parte desta
dissertação pode ser reproduzida sem a autorização do autor.

Ruy Minoru Ito Takata

Rua Arthur Soter Lopes da Silva, 88
05367-140 – São Paulo–SP
MODELO DE FIREWALL PARA REDES
DEFINIDAS POR SOFTWARE COM
VERIFICAÇÃO DE CONFLITOS DE REGRAS
HIERÁRQUICAS

Ruy Minoru Ito Takata

Composição da Banca Examinadora:

Prof. Dr. Celso Massaki Hirata Presidente - ITA

Profa . Dra . Cecı́lia de Azevedo Castro César Orientadora - ITA
Prof. Dr. Edgar Toshiro Yano Membro Interno - ITA
Prof. Dr. Marcos Antonio Simplicio Junior Membro Externo - LARC-USP

ITA
Dedico aos meus pais, Minoru e Tereza
(in memoriam), e a minha irmã, Erika.
Agradecimentos

Agradeço à minha orientadora Profa . Dra . Cecı́lia de Azevedo Castro César por todo
apoio, conhecimento e paciência nesses meses todos.
Agradeço ao meu chefe e amigo, Wagner Antônio Maimoni, e também aos amigos de
equipe, Antônio Alvim de Oliveira Filho, Eduardo Yoshida Salomão, Renato Ribeiro da
Silva e Ronaldo Hideki Yamada, pelo apoio e por entender minha ausências para as aulas.
Agradeço ao amigo Rogério Marinke, pelas dicas sem as quais meu ingresso no mes-
trado não teria acontecido.
Agradeço a todos os professores da Fatec Ourinhos e do ITA que me deram aula e
contribuı́ram em todo meu percurso acadêmico.
Agradeço a todos os funcionários e alunos do ITA com os quais tive contato. Todos
ajudaram direta ou indiretamente para a conclusão desse trabalho.
“Viva como se fosse morrer amanhã. Aprenda como se fosse viver eternamente.”
— Mahatma Gandhi
Resumo

Organizações que estão distribuı́das em mais de um local fı́sico tem dificuldade em

manter a coerência entre as polı́ticas de segurança entre as localidades. Ao definir uma
nova regra de segurança em um firewall em qualquer das localidades é desejável que
esta regra não entre em contradição com a polı́tica geral da organização, o que poderia
causar uma vulnerabilidade no sistema como um todo. O processo de manter a coerência
global permitindo uma certa flexibilização na definição de polı́ticas locais não conflitantes
é muito trabalhoso e frequentemente feito de forma manual. Em grandes organizações,
com muitas regras definidas, este desafio não tem sido atingindo satisfatoriamente. O
paradigma de Redes Definidas por Software (Software Defined Networking - SDN) facilita
a definição de arquiteturas hierárquicas que permitem o fortalecimento neste cenário de
administração distribuı́da. O presente trabalho desenvolveu uma aplicação de firewall
hierárquica em ambiente SDN que faz a verificação de coerência das regras das localidades
a partir da definição de regras do nı́vel hierárquico superior. O sistema desenvolvido
mantém a coerência entre as regras de forma automática. A verificação é realizada no
momento da inserção da regra, não interferindo no desempenho normal do firewall. A
avaliação de desempenho indicou tempo reduzido na inserção.
Abstract

Organizations which are distributed in more than a site find some difficulties to keep
the coherence between the security policy between the sites. When a new rule of security
policy is established in a firewall of every one of the organization’s sites, is expected that
the same rule does not contradict the general organization security policy, situation that
could cause the whole system’s vulnerability. To conserve this global coherence giving the
permission of a kind of flexibility about the non-conflicted local security policy definitions
is a very hard-working process, usually done manually. At the big organizations, with
lots of established defined rules, these actions are not giving the results like they were
expected. The Software Defined Networking (SDN) paradigm facilitates the hierarchical
architectures definitions which allow the strengthen in this environment of distributed ad-
ministration. This work developed a hierarchical firewall application in SDN environment
that verifies the local sites security policy coherence from the definition of the superior
hierarchical level rules. The developed system keeps the coherence between the rules auto-
matically. The verification is performed at the time of rule insertion, not interfering with
the normal performance of the firewall. The performance evaluation indicated a reduced
insertion time.
Lista de Figuras

FIGURA 2.1 – Arquitetura de uma rede SDN usando protocolo OpenFlow. Imagem
retirada de (OPEN NETWORKING FOUNDATION, 2016) . . . . . . . . 22
FIGURA 2.2 – Fluxo do pacote dentro de um switch OpenFlow. Imagem retirada
de (OPEN NETWORKING FOUNDATION, 2015) . . . . . . . . . . . . . . 24
FIGURA 2.3 – Exemplo de comando para adicionar regra ao firewall do Ryu. . . . 28

FIGURA 3.1 – Exemplo de topologia de rede clássico. Retirado de (GAMAYUNOV

et al., 2013) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
FIGURA 3.2 – Exemplo de topologia resultante. Todos os 5 switches são SDN e
estão conectados ao controlador, que não foi ilustrado na figura.
Imagem retirada de (GAMAYUNOV et al., 2013). . . . . . . . . . . . . 34
FIGURA 3.3 – Avaliação de um pacote pela HTF. Imagem retirada de (FERGUSON
et al., 2012) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
FIGURA 3.4 – Workflow da detecção de conflito baseado em Hash-Trie. Imagem
retirada de (NATARAJAN et al., 2012). . . . . . . . . . . . . . . . . . . 43
FIGURA 3.5 – Exemplo de uma estrutura trie. Retirado de (SEDGEWICK; WAYNE,
2011) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
FIGURA 3.6 – Estrutura hash-trie para o campo “Ingress Port” da tabela de fluxos
3.2. Retirado de (NATARAJAN et al., 2012) . . . . . . . . . . . . . . . . 46

FIGURA 4.1 – Arquitetura do firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

FIGURA 4.2 – Fluxograma de uma regra sendo inserida no Firewall Local. . . . . . 53
FIGURA 4.3 – Fluxograma de uma regra sendo inserida no Firewall Root. . . . . . 54
FIGURA 4.4 – Linhas adicionadas ao firewall do Ryu para usá-lo como Firewall Local 55
FIGURA 4.5 – Exemplo de comando para adicionar regra ao firewall Root. . . . . . 56
FIGURA 4.6 – Pseudo-código da função set rule() do Firewall Root . . . . . . . . . 58
LISTA DE FIGURAS x

FIGURA 4.7 – Pseudo-código da função verify rule() do Firewall Root . . . . . . . 59

FIGURA 5.1 – Encadeamento de Componentes . . . . . . . . . . . . . . . . . . . . . . 61

FIGURA 5.2 – Ambiente criado para os testes . . . . . . . . . . . . . . . . . . . . . . 62
FIGURA 5.3 – Comparação dos tempos de processamento das regras de firewall.
Testes realizados em um computador Intel Core(TM) i5-2400 3.10GHz
com 8GB de memória RAM e disco SSD com sistema operacional
Ubuntu Server 16.04.02 64 bits . . . . . . . . . . . . . . . . . . . . . . 68
Lista de Tabelas

TABELA 2.1 – Exemplo de como a ordem das regras de firewall podem fazer diferença 27
TABELA 2.2 – Campos disponı́veis para o firewall do Ryu. Informações retiradas
do código fonte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
TABELA 2.3 – Relação de URIs e métodos disponı́veis no firewall do Ryu. Infor-
mações retiradas de (RYU PROJECT TEAM, 2014) . . . . . . . . . . . 30

TABELA 3.1 – Exemplo de como alteração do cabeçalho do pacote pode influenciar

no firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
TABELA 3.2 – Exemplo de uma tabela de fluxos. Cada linha representa uma en-
trada de fluxo, e cada coluna representa um campo do cabeçalho
OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
TABELA 3.3 – Exemplo de uma Matriz de Intersecção preenchida . . . . . . . . . . 46
TABELA 3.4 – Caracterı́sticas dos trabalhos analisados . . . . . . . . . . . . . . . . . 48

TABELA 4.1 – Exemplo de regras conflitantes . . . . . . . . . . . . . . . . . . . . . . . 50

TABELA 4.2 – Relação de métodos e URIs disponı́veis para o firewall Root. . . . . 56
TABELA 4.3 – Exemplo de conflitos de endereços IP . . . . . . . . . . . . . . . . . . 60

TABELA 5.1 – Regras iniciais inseridas no controlador Root . . . . . . . . . . . . . . 64

TABELA 5.2 – Regras não Root inseridas nos Controladores Locais . . . . . . . . . . 65
TABELA 5.3 – Regras adicionais para testes mais abrangentes. Nem todos os hosts
estão representados na figura 5.2 . . . . . . . . . . . . . . . . . . . . . 66
TABELA 5.4 – Comparação de tempos com Trabalhos Relacionados . . . . . . . . . 70
Lista de Abreviaturas e Siglas

ACL Access Control List (Lista de Controle de Acesso)

API Application Programming Interface (Interface de Programação de Apli-
cações)
ARP Address Resolution Protocol (Protocolo de Resolução de Endereço)
CPU Central Processing Unit (Unidade Central de Processamento)
DNS Domain Name System (Sistema de Nome de Domı́nio)
FTP File Transfer Protocol (Protocolo de Transferência de Arquivos)
HFT Hierarchical Flow Tables (Tabelas de Fluxo Hierárquicas)
HTTP Hypertext Transfer Protocol (Protocolo de Transferência de Hipertexto)
ICMP Internet Control Message Protocol (Protocolo de Mensagens de Controle
de Internet)
IDS Intrusion Detection System (Sistema de Detecção de Intrusão)
JSON JavaScript Object Notation (Notação de Objeto JavaScript)
MAC Media Access Control (Controle de Acesso ao Meio)
MPLS Multiprotocol Label Switching (Comutação de Rótulos Multiprotocolo)
NAT Network Address Translation (Tradução de Endereço de Rede)
NFV Network Functions Virtualization (Função Virtual de Rede)
NIB Network Information Base (Base de Informações de Rede)
NTP Network Time Protocol (Protocolo de Tempos para Redes)
ONF Open Network Foundation
REST Representational State Transfer (Transferência de Estado Representaci-
onal)
SMTP Simple Mail Transfer Protocol (Protocolo de Transferência de Correio
Simples)
SDN Software Defined Networking (Redes Definidas por Software)
SSH Secure Shell (Shell Seguro)
TCP Transmission Control Protocol (Protocolo de Controle de Transmissão)
UDP User Datagram Protocol (Protocolo de Datagrama de Usuário)
URI Uniform Resource Name (Identificador Uniforme de Recursos)
USENET Unix User Network (Rede de Usuários Unix)
LISTA DE ABREVIATURAS E SIGLAS xiii

VLAN Virtual Local Area Network (Rede Local Virtual)

WSGI Web Server Gateway Interface (Interface de Porta de Entrada do Servidor
Web)
Sumário

1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.1 Problema de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3 Método de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4 Organização do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2 Fundamentação Teórica . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1 Redes Definidas por Software . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.1 Funções Virtuais de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.2 Protocolo OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.3 Controlador SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.1 Firewall em SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1 Firewall Hierárquico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Verificação de Conflitos de Regras . . . . . . . . . . . . . . . . . . . . . 38
3.3 Discussão dos Trabalhos Relacionados . . . . . . . . . . . . . . . . . . 47

4 Firewall Para SDN com Verificação de Conflito de

Regras Hierárquicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.1 Arquitetura do Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3 Metodologia da Verificação de Conflito de Regras . . . . . . . . . . 58
SUMÁRIO xv

5 Verificação de Resultados . . . . . . . . . . . . . . . . . . . . . . . 61
5.1 Ambiente de Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2 Teste de Funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.3 Teste de Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.4 Comparação com Trabalhos Relacionados . . . . . . . . . . . . . . . . 70

6 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.1 Limitação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.2 Sugestões para Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . 73

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Apêndice A – Códigos Utilizados . . . . . . . . . . . . . . . . . . . 78

A.1 Script para criação da rede utilizada nos testes . . . . . . . . . . . . 78
1 Introdução

As redes de computadores e a Internet trouxeram consigo várias oportunidades. O

comércio eletrônico diminuiu a distância entre os consumidores e fornecedores, o Internet
Banking possibilitou a realização de vários serviços bancários sem precisar ficar esperando
em filas nas agências, as notı́cias circulam o mundo todo em questão de segundos, as redes
sociais conectam milhares de pessoas com interesses em comum.
Todo esse dinamismo dos serviços oferecidos acabam requerendo também um maior
dinamismo das redes de computadores. Para tentar atender essa necessidade, uma das
alternativas que está emergindo tanto na indústria como nas universidades são as Redes
Definidas por Software (SDN - Software-Defined Networking). Nessa nova arquitetura, os
switches são meros encaminhadores de pacotes e ficam numa camada denominada plano
de dados (data plane), obedecendo aos controladores que ficam no plano de controle
(control plane). Esses controladores são servidores que executam um sistema operacional
de rede, onde são colocadas aplicações programadas pelos administradores de rede, que
podem então, definir o comportamento de toda a rede de forma flexı́vel e centralizada.
O OpenFlow foi o primeiro protocolo de comunicação entre plano de controle e plano
de dados, e permite acesso e manipulação dos dispositivos do plano de dados (OPEN
NETWORKING FOUNDATION, 2016).

Segundo (YOON et al., 2015), diversas empresas estão implementando ou planejam

implementar essa nova tecnologia para fortalecer suas arquiteturas de rede, reduzir custo
operacional, e habilitar novas funções e aplicações de rede. No entanto, a segurança é
uma área do SDN que ainda precisa de mais pesquisas.
A norma ABNT NBR ISO/IEC 27002:2005 (ABNT, 2005) descreve as boas práticas
da segurança da informação. Ela destaca que, proteger os ativos de uma empresa é
vital para garantir a continuidade do negócio. A informação é um dos ativos de uma
organização, e, para protegê-la é preciso implementar um conjunto de controles, como
polı́ticas, processos, procedimentos, estruturas organizacionais e funções de software e
hardware. Polı́tica é definida por (ABNT, 2005) como sendo “intenções e diretrizes globais
formalmente expressas pela direção”. Com base na polı́tica, pode-se implementar controles
para que os ativos não sejam expostos a riscos acima de um nı́vel aceitável. Esses controles
CAPÍTULO 1. INTRODUÇÃO 17

são implementados em todas as áreas de organização, definindo por exemplo, a segurança

fı́sica de instalações, gestão de pessoas, e chegam na área de informática, onde pode
abordar temas como cópias de segurança das informações, acesso lógico aos sistemas de
informação e segurança de rede.
Dos vários recursos existentes para tentar garantir a polı́tica segurança de uma rede,
um deles é o firewall. Em uma rede tradicional, um firewall é um conjunto de hardware,
software e polı́ticas que analisam o tráfego de rede, bloqueando ou permitindo que ele
passe. Algumas polı́ticas podem ser expressas diretamente como regras de firewall. Para
dar um exemplo da necessidade de hierarquizar a definição de polı́ticas de segurança, po-
demos citar o problema de compartilhamento de arquivos diretamente via Sistema Opera-
cional. Este tipo de compartilhamento de arquivos é função historicamente já explorada
e conhecida por trazer vulnerabilidades ao ambiente da corporação. A organização pode
colocar em sua polı́tica a proibição deste tipo de compartilhamento direto e impor esta
polı́tica aos nı́veis hierárquicos inferiores. Esta polı́tica será extremamente útil e é de-
sejável que seja seguida em todos as unidades da organização. Ela será traduzida em
um conjunto de regras no ambiente central e este conjunto poderia ser automaticamente
adicionado a uma lista de regras de todas as unidades para que as redes locais confrontem
os pacotes que trafegam nestas redes com as regras que seguem estas determinações.
Mesmo sendo possı́vel utilizar uma solução de firewall tradicional em uma rede SDN,
uma alternativa de acordo com as novas tendências é implementá-lo através de regras
de fluxo mais especı́ficas em alguma aplicação executando em um controlador. O SDN
permite verificar vários campos presentes no cabeçalho de um pacote e, a partir disso,
definir qual ação tomar com o fluxo ao qual esse pacote pertence. Ou seja, é possı́vel
melhorar a segurança em uma rede SDN adaptando os mecanismos especı́ficos de firewall
tradicional.
O ambiente SDN, devido a sua caracterı́stica de centralização, parece muito indicado
para a implementação de estruturas de controle hierárquicas. Em particular, algumas
experiências estão despontando em unir firewalls a uma estrutura hierárquica. Alguns
estudos empregam o termo hierárquico em ambientes onde se estabelece regras com maior
prioridade que não podem ser desrespeitadas. A priorização de polı́ticas de segurança
é algo desejável em dois casos: quando a infraestrutura de rede é distribuı́da em várias
localidades; e quando há a delegação de poderes para administração de partes da rede
para outras pessoas.
Grandes empresas comumente são distribuı́das em mais de uma locação, tendo, por-
tanto, sua rede distribuı́da geograficamente. Mesmo que os serviços de rede fiquem apenas
em um local, uma infraestrutura é necessária em todas as localidades para manter o fun-
cionamento das estações de trabalho, incluindo algumas soluções de segurança. Nesse
cenário é possı́vel que haja uma administração de rede centralizada que defina padrões e
CAPÍTULO 1. INTRODUÇÃO 18

polı́ticas que devem ser seguidas pelas filiais.

Em casos de redes SDN geograficamente distribuı́das existem alguns motivos que jus-
tificam a utilização de mais de um controlador, e entre eles podem ser citados:

• a grande quantidade de equipamentos de rede poderia gerar um gargalo caso hou-

vesse somente um controlador;

• a distância entre as localidades faria com que o tempo de resposta se torne um

impeditivo caso alguma regra precise ser consultada no controlador presente em
outra localidade.

Nesse tipo de ambiente com controladores fisicamente distribuı́dos, grande parte das
soluções disponı́veis atualmente aplicam o conceito de “controladores logicamente centra-
lizados”, onde todos eles executam as mesmas aplicações e compartilham a mesma visão
global da rede. Ou seja, se um administrador de rede de uma filial quiser implantar uma
polı́tica de firewall especı́fica para sua localidade, será necessário fazer uma análise para
garantir que essas regras não entrem em conflito com outras definidas pela administração
central da rede.
Outros estudos utilizam o termo hierárquico relacionado a organização das regras em
árvores criadas para melhorar o desempenho do firewall em redes de alto tráfego. A
organização em hierarquia portanto parece promissora do ponto de vista de desempenho
e segurança.

1.1 Problema de Pesquisa

Em ambientes com controladores logicamente centralizados, mas fisicamente distri-

buı́dos conforme citado na sessão anterior, caso alguma polı́tica de segurança especı́fica
de uma localidade precise ser implementada como regras de firewall, é necessário uma
análise minuciosa para que elas não contrariem as polı́ticas de segurança definidas pela
administração central, pois isso poderia gerar vulnerabilidades no sistema como um todo.
Uma pequena vulnerabilidade presente em uma filial, quando explorada, poderia permitir
acesso a sistemas e informações mais crı́tico de toda a empresa.
Essa verificação precisa ser feita em todas as regras, e isso pode ser muito trabalhoso,
pois além de ser possı́vel haver uma quantidade muito grande de regras, é preciso repetir
esse processo cada vez que alguma delas seja criada, alterada ou excluı́da. Assim, o
problema sendo estudado é a inconsistência de regras de firewall em ambiente hierárquicos.
CAPÍTULO 1. INTRODUÇÃO 19

1.2 Objetivo

O objetivo desse trabalho é criar um ambiente virtual de rede SDN com mais de uma
localidade, cada um com seu controlador executando uma aplicação de firewall com regras
próprias. Essas regras devem estar em harmonia com as regras definidas em uma aplicação
de firewall executando em um controlador em um nı́vel superior, gerido pela administra-
ção central da organização. Nesse nı́vel hierárquico superior serão colocadas regras que
expressem as polı́ticas definidas pela alta gestão da organização, e que não podem ser des-
respeitadas pelas localidades, como por exemplo, regras que proı́bam compartilhamento
de arquivos entre as estações de trabalho da rede.
Isso deve ser conseguido através da camada de aplicação de forma independente da
camada de controle, pois dessa maneira, a aplicação de firewall desenvolvida pode ser
portada para outros ambientes SDN que utilizem controladores diferentes. Essa inde-
pendência é uma caracterı́stica desejável devido ao fato de atualmente existirem diversas
plataformas de controle diferentes.
A hipótese de pesquisa é que a utilização de aplicações de firewall em hierarquia
rodando em ambiente SDN fortalece a segurança de uma corporação com ambiente distri-
buı́do. Essa integração deve garantir a coerência das regras, evitando de forma automática
os conflitos que podem haver em diferentes localidades da mesma corporação.

1.3 Método de Pesquisa

Para realização desse trabalho alguns passos foram seguidos:

• Uma pesquisa abordando conceitos e tecnologias de firewall e SDN, e métodos de

verificação de conflito entre regras firewall;

• Configuração de um ambiente virtual de rede SDN para representar a arquitetura

descrita no Problema de Pesquisa;

• Definição de regras de segurança: definição de algumas regras globais que não podem
ser sobrepostas, e de algumas regras locais que devem permanecer válidas;

• Criação de uma massa de teste com diversos fluxos de rede que conflitem com as
regras de segurança definidas, e de outros que não conflitem.

• Desenvolvimento da aplicação que faça a verificação do conflito de regras no mo-

mento que elas forem carregadas pelos controladores;

• Realizar os testes dessas aplicações usando a massa de dados levantada;

CAPÍTULO 1. INTRODUÇÃO 20

• Comparação dos resultados das aplicações desenvolvidas com outros modelos de

verificação de conflito de regras.

1.4 Organização do Trabalho

A dissertação está organizada da seguinte forma:

• Capı́tulo 2: Fundamentação teórica sobre SDN e Firewall;

• Capı́tulo 3: Uma revisão da literatura de trabalhos relacionados a firewall e contro-

ladores hierárquicos;

• Capı́tulo 4: Apresentação do trabalho desenvolvido com detalhes de implementação;

• Capı́tulo 5: Apresentação dos resultados obtidos;

• Capı́tulo 6: Conclusão e sugestões para trabalhos futuros.

2 Fundamentação Teórica

Este capı́tulo aborda diversos conceitos utilizados para a elaboração desta dissertação.
A sessão 2.1 apresenta a definição de SDN e de seu principal protocolo, o OpenFlow,
citando também alguns de seus controladores. A sessão 2.2 apresenta alguns conceitos de
firewall, e como o firewall pode ser implementado utilizando SDN.

2.1 Redes Definidas por Software

A ONF (Open Network Foundation) é uma organização voltada para o usuário dedi-
cada a promoção e adoção de SDN através do desenvolvimento de padrões abertos. Essa
nova abordadem separa o controle da rede dos encaminhadores de pacote, e é direta-
mente programável (OPEN NETWORKING FOUNDATION, 2017a). Isso torna a rede mais
dinâmica, gerenciável, economicamente viável e adaptável. Essas caracterı́sitcas permi-
tem aos administradores maior programabilidade, automação e controle. Usar um padrão
aberto para implementar SDN permite maior agilidade e reduz o trabalho de desenvolvi-
mento e o custo operacional, e permite ao administrador utilizar as melhores tecnologias
a medida que elas são desenvolvidas.
Segundo (OPEN NETWORKING FOUNDATION, 2017b), as caracterı́sticas dessa arqui-
tetura emergente a torna ideal para a alta largura de banda e a natureza dinâmica das
aplicações atuais, e o protocolo OpenFlow é um elemento fundamental para a construção
de soluções SDN. Entre as caracterı́sticas de uma rede SDN tem-se:

• Diretamente programável: O controle da rede pode ser diretamente programável

pois é separado das funções de encaminhamento;

• Ágil: Abstrair o controle dos encaminhadores permite aos administradores ajustar

dinamicamente o fluxo de toda a rede para atender mudanças de necessidades;

• Gerência centralizada: A inteligência da rede é logicamente centralizada em con-

troladores SDN baseados em software que mantém uma visão global da rede, que
aparecem como um único switch lógico para as aplicações e ferramentas de polı́ticas;
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 22

• Configurável programaticamente: SDN permite aos administradores de rede configu-

rar, gerenciar, melhorar a segurança, e otimizar recursos de rede muito rapidamente,
através de programas SDN dinâmicos e automatizados. Esses programas podem ser
escritos pelos próprios administradores, pois não dependem de software proprietário;

• Baseado em padrões abertos e independente de fornecedor: quando implementado

através de padrões abertos, SDN simplifica o projeto e a operação da rede, pois as
instruções são fornecidas pelos controladores SDN ao invés de múltiplos dispositivos
e protocolos especı́ficos de fornecedores.

A estrutura lógica de uma rede SDN pode ser vista na figura 2.1. O OpenFlow foi
o primeiro padrão de comunicação entre a camada de controle e a de infraestrutura, e
ele permite acesso direto ao plano de dados, bem como manipulação de seus dispositivos
como switches e roteadores, tanto fı́sicos como virtuais.

FIGURA 2.1 – Arquitetura de uma rede SDN usando protocolo OpenFlow.

Imagem retirada de (OPEN NETWORKING FOUNDATION, 2016)

Os controladores SDN ficam na camada de controle, que disponibilizam APIs (Ap-

plication Programming Interface - Interface de Programação de Aplicação) para que os
administradores possam configurar a rede conforme suas necessidades. Depois de prontas,
essas aplicações executam na camada de aplicação, e determinam o comportamento dos
equipamentos presentes na camada de infraestrutura. Esses equipamentos da camada de
infraestrutura se tornam simples encaminhadores de pacote, pois a inteligência fica toda
nas camadas superiores.
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 23

2.1.1 Funções Virtuais de Rede

Segundo (ETSI, 2012), as Funções Virtuais de Rede (NFV - Network Functions Virtua-
lisation) tem como objetivo retirar de equipamentos de rede algumas funções e consolidá-
las em servidores executando sobre tecnologia padrão de virtualização de servidores, que
podem ser alocados em Centro de Dados, Nós de Redes, ou no usuário final, sendo possı́vel
mover essas funções de rede instantaneamente conforme a necessidade, sem precisar, para
isso, instalar um novo equipamento.
NFV e SDN são dois conceitos que caminham muito próximos. Apesar de não se-
rem dependentes eles podem ser complementares. Segundo (KAPADIA; CHASE, 2017), a
flexibilidade de uma rede SDN pode ser beneficiada com a agilidade de se mover servi-
ços complexos e especializados que estão implementados na forma de funções de rede. É
possı́vel substituir serviços tais como VPN, firewall, NAT, IPS/IDS por funções virtuais
de rede. Embora a virtualização dos serviços de rede seja uma tendência, não houve a
preocupação neste trabalho de criar tal função. Após a prova de funcionalidade dos fi-
rewalls hierarquizados, seria possı́vel desenvolver as etapas da virtualização destas mesmas
funções.

2.1.2 Protocolo OpenFlow

A comunicação entre o switch OpenFlow e seu controlador é feita por meio de um

canal de comunicação chamado OpenFlow Channel. Através dessa interface o controlador
gerencia e configura o switch, recebe eventos do switch, e envia pacotes para o switch.
Todas essas mensagens trocadas através do OpenFlow Channel precisam ser formatadas
de acordo com o protocolo OpenFlow. A versão mais recente desse protocolo é a 1.5, mas
nem todos os switches já a implementam.
O protocolo OpenFlow estabelece três tipos de mensagens conforme a lista abaixo.
Cada tipo contém múltiplos subtipos.

• Controller-to-switch: iniciadas pelo controlador e usadas para gerenciar ou inspeci-

onar o estado do switch. Pode ou não requerer uma resposta do switch;

• Asynchronous: iniciadas pelo switch e usadas para atualizar o controlador sobre os

eventos de rede e mudanças no estado do switch.

• Symmetric: mensagens iniciadas por qualquer uma das partes, sem nenhuma solici-
tação.

Internamente, um switch OpenFlow tem uma ou mais tabelas de fluxos (Flow Tables),
e cada tabela contém múltiplas entradas de fluxo (Flow Entries). Ao ingressar no switch,
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 24

o pacote é verificado com as entradas de fluxo. Se o o pacote casar com alguma entrada de
fluxo, as instruções contidas nessa entrada serão executadas. Essas instruções podem fazer
com que o pacote seja encaminhado para uma ou mais portas do switch, seja descartado,
ou seja encaminhado para outra tabela de fluxos, onde ele é verificado novamente.
Se, em determinada tabela de fluxos, o pacote não casar com nenhuma entrada de
fluxo, ocorre o chamado “table miss”. Esse fluxo contém instruções a serem executadas,
que usualmente incluem, descartar o pacote, encaminhar para outra tabela de fluxos, ou
enviar o pacote para o controlador.
O diagrama do funcionamento das tabelas de fluxos de um switch OpenFlow pode ser
vista na figura 2.2.

FIGURA 2.2 – Fluxo do pacote dentro de um switch OpenFlow.

Imagem retirada de (OPEN NETWORKING FOUNDATION, 2015)

2.1.3 Controlador SDN

Como dito na sessão anterior, em redes SDN, toda a inteligência é retirada dos equi-
pamentos de rede, e esse papel é repassado para controladores externos. Mesmo quando
utilizando mais de um controlador, eles são logicamente centralizados, fator que possibi-
lita a gerência centralizada da rede. A existência de um protocolo SDN aberto como o
OpenFlow facilita o desenvolvimento de controladores e equipamentos de rede.
Atualmente existem diversos controladores OpenFlow. Segundo (RAO, 2014), o pri-
meiro controlador OpenFlow foi o NOX. Ele foi desenvolvido pela Nicira Networks e foi
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 25

disponibilizado em 2009. Escrito originalmente em C++, deu origem ao POX, escrito em

Python.
O Floodlight (PROJECT FLOODLIGHT, 2017) é um controlador aberto e gerido pela
Open Network Foundation. Desenvolvido em Java, ele suporta o protocolo OpenFlow das
versões 1.0 até 1.4. Sua arquitetura modular facilita extendê-lo e melhorá-lo.
A OpenDaylight Foundation (OPENDAYLIGHT FOUNDATION, 2017) foi fundada em
2013 e é responsável pelo maior controlador open source, o OpenDaylight. Sua arquite-
tura de microserviços permite ao usuário ativar cada protocolo ou serviço conforme sua
necessidade.
O Ryu (RYU SDN FRAMEWORK COMMUNITY, 2017) é um controlador escrito em
Python e tem suporte ao protocolo OpenFlow das versões 1.0 até 1.5, suportando também
outros protocolos. O Ryu disponibiliza várias aplicações prontas, incluindo um firewall
(RYU PROJECT TEAM, 2014), que foi utilizado como base para essa dissertação.

2.2 Firewall

Na computação, Firewall é um dispositivo e/ou um programa que controla o tráfego

entre redes de computadores. São usados para prevenir acesso indevido a informações e
sistemas, reforçando polı́ticas de segurança.
Segundo (GAASERUD, 2013), a teoria de Firewall em computadores foi apresentada
pela primeira vez em 1988 por engenheiros da DEC (Digital Equipment Corporation). O
primeiro Firewall comercial foi desenvolvido em 1991 e disponibilizado em 1992, o DEC
SEAL (Secure External Access Link).
Segundo (RANUM, 1992), o DEC SEAL consistia em uma série de gateways entre a
Internet e a rede de computadores da empresa, prevenindo o acesso direto entre máquinas
internas e externas. Ele disponibilizava acesso transparente a USENET, SMTP, FTP e
serviço de nome.
Ao longo dos anos, a evolução das redes e sua maior criticidade exigiu que os Firewalls
também evoluissem. Uma classificação citada por (GAASERUD, 2013) divide os firewalls
conforme a lista abaixo:

• Primeira geração (firewall de filtragem de pacotes): inspeciona cada pacote baseado

em endereço IP, porta e serviço requisitados. Se o pacote casar com o critério de uma
ou mais regras do firewall, uma ação é tomada, que pode ser descartar, rejeitar1 , ou
aceitar o pacote.
1
A diferença entre descartar e rejeitar um pacote é que, ao rejeitar, envia-se uma mensagem para a
origem informando que o pacote foi rejeitado, e ao descartar, nenhum aviso é enviado.
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 26

• Segunda geração (inspeção de pacotes com estado): os firewalls de primeira geração

são considerados “stateless” (sem estado), pois não levam em consideração que o
pacote inspecionado pode fazer parte de alguma sessão de rede. Em 1994, a Check
Point emprega a denominação “stateful ” em seu firewall, e esse termo se refere ao
fato do firewall considerar o estado e o contexto do pacote. Informações das conexões
estabelecidas são armazenadas em uma tabela. Ler a tabela é mais rápido do que
interagir com as regras, e isso torna o fluxo de pacotes através do firewall mais
rápido.

• Terceira geração (gateway de aplicação): capaz de verificar informações no nı́vel de

aplicação, usando-as para tomar as decisões. Isso permite filtrar o tráfego baseado
na aplicação ou serviço.

• Firewall hı́brido: Na prática, os firewalls tem caracterı́sticas de duas ou mais das

tecnologias citadas acima, combinando as vantagens de diferentes plataformas em
uma única arquitetura de inspeção de pacotes.

• Sistema de detecção de intrusão: os IDS (Intrusion Detection Systems) agem em

conjunto com o firewall para detectar novas ameaças e comportamentos maliciosos,
reagindo pró-ativamente para bloquear atitudes suspeitas.

• Firewall de próxima geração: para conseguir prevenir novas ameaças que surgem
a cada dia os fabricantes começaram a oferecer o firewall e o IDS em uma única
plataforma de segurança de rede, chamada de Next Generation Firewall. Reunir
caracterı́sticas de todas as gerações de firewall e do IDS em um único produto pode
trazer algumas vantagens, como gerência simplificada, melhor controle, maior vazão,
entre outras.

Pensando em um firewall de primeira ou segunda geração, suas regras são representadas

como uma tupla de sete elementos: <número sequencial><ação><protocolo><endereço
de origem><porta de origem><endereço de destino><porta de destino>. O número
sequencial é muito importante, pois define a ordem com que as regras serão analisadas, e
caso haja alguma divergência, a primeira é a que será aplicada.
Com exceção do número sequencial e da ação, alguns campos podem ser omitidos,
e quando isso ocorre, o valor daquele campo no pacote não importa durante a análise.
Por exemplo, se a porta de destino for omitida, qualquer pacote cujos outros campos
correspondam irá casar com a regra, independente da porta de destino. Ilustrando melhor,
uma regra que diga: aceitar todos os pacotes vindo do endereço [Link] para o endereço
[Link] com protocolo TCP, significa que qualquer pacote com os respectivos endereços
de origem e destino, e protocolo TCP serão aceitos, independente das portas de origem e
destino.
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 27

Levando-se em consideração esses dois fatos anteriores, vê-se a importância da cor-

reta organização das regras de firewall para que elas possam representar corretamente as
polı́ticas de segurança. Se uma regra menos especı́fica for colocada antes de uma mais es-
pecı́fica, a segunda nunca será executada. Por exemplo, nas regras da tabela 2.1, pode-se
ver que a primeira regra é a mais especı́fica, pois tem o campo “Porta de Destino”, que foi
omitido na segunda regra. Se colocadas nessa ordem o firewall irá permitir pacotes TCP
vindo do endereço [Link] para o [Link] com destino a porta 80, e negar qualquer outro
pacote com esse mesmo destino e origem. Se essas regras forem invertidas, os pacotes com
destino a porta 80 também serão negados, fazendo com que a regra mais especı́fica nunca
seja verificada.

Ação Protocolo Endereço Origem Endereço Destino Porta Destino

Permitir TCP [Link] [Link] 80
Negar TCP [Link] [Link]
TABELA 2.1 – Exemplo de como a ordem das regras de firewall podem fazer diferença

2.2.1 Firewall em SDN

Em SDN é possı́vel verificar vários campos do cabeçalho dos pacotes, e com isso, criar
regras de fluxo bem especı́ficas. Essas regras, poderiam fazer referência a endereço IP de
origem e destino, porta de origem e destino, e protocolo de transporte, que são os campos
utilizados por um firewall tradicional de primeira e segunda geração. Ou seja, em uma
rede SDN, é possı́vel substituir o firewall tradicional por regras de fluxo mais especı́ficas.
Os controladores Ryu (RYU PROJECT TEAM, 2014) e Floodlight (IZARD, 2015) dispo-
nibilizam algumas aplicações prontas, e o firewall está entre elas. O controlador Ryu foi
o escolhido como base para esta dissertação devido, principalmente, a sua facilidade de
programação. As interfaces são simples, flexı́veis e há diversos casos de uso fornecidos
pelo time de desenvolvimento do Ryu que não precisaram ser refeitos mas puderam ser
aproveitados integralmente.
O Firewall disponibilizado pelo Ryu é um firewall de pacotes stateless. O Ryu tem
uma função Web Server usando WSGI2 , e a aplicação de firewall a utiliza para que as
regras possam ser manipuladas, utilizando interface RESTful.
Quando o controlador Ryu é iniciado e a aplicação de firewall é ativada, o switch
OpenFlow fica com duas regras de fluxo definidas para: tratar qualquer pacote do tipo
ARP como se fosse um switch não SDN; enviar todos os outros pacotes para o controlador.
2
Segundo (EBY, 2010), WSGI (Web Server Gateway Interface) é a especificação de como o web server
deve se comunicar com aplicações web, e como aplicaçoes web pode ser encadeadas para processar uma
requisição.
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 28

Ao adicionar uma regra à aplicação de firewall, uma regra de fluxo referente a ela é
adicionada ao switch.
Por exemplo, o comando na figura 2.3 executado no mesmo servidor onde o controlador
Ryu está irá cria uma entrada de fluxo que permite o tráfego de pacotes com o protocolo
ICMP vindo do endereço IP [Link] com destino ao IP [Link].

curl -X POST -d ' { " nw_src " : " [Link]/32 " , " nw_dst " :
" [Link]/32 " , " nw_proto " : " ICMP " } '
http :// localhost :8080/ firewall / rules /0000000000000001

FIGURA 2.3 – Exemplo de comando para adicionar regra ao firewall do Ryu.

Além dos campos presentes no comando da figura 2.3, o firewall do Ryu aceita alguns
outros, e todos eles, bem como uma breve descrição, podem ser vistos na tabela 2.2.
A maneira como os dados devem ser passados para o Ryu também pode ser vista no
comando.
Além de adicionar regras, existem outros comandos possı́veis no firewall. Para executá-
los, basta acessar a URI correta e enviar os métodos HTTP. A lista com as URIs e métodos
podem ser vistos na tabela 2.3.
Como dito anteriormente, o firewall do Ryu é stateless, ou seja, não leva em conside-
ração que determinado pacote possa fazer parte de alguma sessão de rede já iniciada. Por
esse motivo é possı́vel ver em (RYU PROJECT TEAM, 2014) que, para permitir um tráfego,
sempre são adicionadas duas regras, uma em cada sentido (de A para B e depois de B para
A). Por exemplo, se em B existe um servidor Web (porta 80), deve-se criar uma regra de
A para B com porta de destino 80, e depois uma de B para A com porta de origem 80.
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 29

Campo Valores Descrição

priority número inteiro 0 a 65533 Prioridade da regra.
Quanto maior o número,
maior a prioridade.
Padrão é 0.
in port número inteiro 0 a 65533 Porta de entrada do
switch.
dl src xx:xx:xx:xx:xx:xx Endereço MAC de ori-
gem.
dl dst xx:xx:xx:xx:xx:xx Endereço MAC de des-
tino.
dl type ARP ou IPv4 ou IPv6 Protocolo internet uti-
lizado. Padrão IPv4
caso os campos dl src ou
dl dst estejam preenchi-
dos. Padrão IPv6 caso
os campos ipv6 src ou
ipv6 dst estejam preen-
chidos.
nw src A.B.C.D/M Endereço IP de origem
no formato IPv4.
nw dst A.B.C.D/M Endereço IP de destino
no formato IPv4.
ipv6 src xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/M Endereço IP de origem
no formato IPv6.
ipv6 dst xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/M Endereço IP de destino
no formato IPv6.
nw proto TCP ou UDP ou ICMP ou ICMPv6 Protocolo de transporte
utilizado.
tp src número inteiro de 0 a 65533 Porta de origem.
tp dst número inteiro de 0 a 65533 Porta de destino.
actions ALLOW ou DENY Ação a ser tomada com o
pacote. Padrão ALLOW.
TABELA 2.2 – Campos disponı́veis para o firewall do Ryu.
Informações retiradas do código fonte.
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 30

Método URI Descrição

GET /firewall/module/status Verifica se o firewall está ativado ou de-
sativado.
PUT /firewall/module/{op}/{switch} Ativa ou desativa o firewall. Valor do
campo “op” pode ser “enable” ou “di-
sable”. Campo “switch” pode ser “all”
para todos os switches, ou o ID do
switch onde o firewall será ativado. Ini-
cialmente estão todos desativados.
GET /firewall/rules/{switch}[/{vlan}] Lista as regras. Campo “switch” pode
ser “all” para todos os switches ou o ID
do switch. Campo “vlan” é opcional, e
pode ser “all” para todas as vlans, ou o
ID da vlan.
POST /firewall/rules/{switch}[/{vlan}] Adiciona uma regra. Campo “switch”
pode ser “all” para todos os switches ou
o ID do switch. Campo “vlan” é opcio-
nal, e pode ser “all” para todas as vlans,
ou o ID da vlan. Quando a regra é adi-
ciona com sucesso, seu ID é retornado
como resposta. Os dados sobre a regra
a ser adicionada seguem o formato que
pode ser visto na figura 2.3, e os cam-
pos e valores possı́veis estão na tabela
2.2.
DELETE /firewall/rules/{switch}[/{vlan}] Apaga uma regra. Campo “switch”
pode ser “all” para todos os switches ou
o ID do switch. Campo “vlan” é op-
cional, e pode ser “all” para todas as
vlans, ou o ID da vlan. É necessário in-
formar o ID da regra que será apagada
no formato ‘{“rule id”: “1”}’, podendo
ser “all” ao invés do número para apa-
gar todas as regras. O rule id deve ser
passado da mesma maneira que é feito
para adicionar uma regra, visto na fi-
gura 2.3.
GET /firewall/log/status Obtém um log com o status de todos os
switches
PUT /firewall/log/{op}/{switch} Ativa ou desativa o log de status dos
switches O campo “op” pode ser “ena-
ble” ou “disable”. O campo “switch”
pode ser “all” para todos os switches,
ou o ID do switch. Inicialmente todos
estão ativados.
TABELA 2.3 – Relação de URIs e métodos disponı́veis no firewall do Ryu.
Informações retiradas de (RYU PROJECT TEAM, 2014)
3 Trabalhos Relacionados

Este capı́tulo aborda vários trabalhos referentes a firewall, firewall em SDN e verifica-
ção de conflitos entre regras de firewall, e eles foram utilizados como base de conhecimento
para a elaboração desta dissertação.
Eles resolvem os problemas a que foram propostos, mas apresentam uma abordagem
diferente da esperada para esta dissertação.
Os trabalhos foram agrupados em dois grupos: o primeiro grupo, apresentado na sub-
seção 3.1, apresenta soluções que lidam com hierarquia de firewalls, mostrando algumas
técnicas que podem melhorar o desempenho do firewall, tanto tradicional como em SDN;
o segundo grupo de trabalhos, apresentado na subseção 3.2, se preocupam com a resolu-
ção de conflitos de regras em firewall, e mostra vários fatores que devem ser levados em
consideração para que, ao final do processo, as polı́ticas de segurança estejam represen-
tadas corretamente na forma de regras de firewall. Uma discussão sobre os tópicos mais
relevantes dos trabalhos apresentados neste capı́tulo é feita na subseção 3.3.

3.1 Firewall Hierárquico

Os firewalls tradicionais podem ser substituidos por um conjunto de regras no contexto

SDN. O protocolo OpenFlow foi projetado permitindo definição de regras que podem re-
gular o tráfego, indicando quais pacotes são permitidos ou não permitidos. Estas novas
definições são candidatas naturais a fazer o papel dos firewall tradicionais. Tradicio-
nalmente, as regras de firewall são expressas com alguma sintaxe semelhante a sintaxe
definida pela Cisco em suas listas de controle de acesso (ACL - Access Control Lists).
A Cisco é uma empresa lı́der de mercado e historicamente define padrões seguidos por
diversos outros fabricantes. O ponto de partida do trabalho de (GAMAYUNOV et al., 2013)
é definir uma rede não SDN formada por várias sub-redes interligadas por firewalls com
ACLs. A seguir, ele define alguns passos para a migração da topologia inicial para SDN
com preservação das polı́ticas de segurança.
O diagrama da rede utilizada pode ser visto na figura 3.1 e é formada por quatro
CAPÍTULO 3. TRABALHOS RELACIONADOS 32

zonas separadas (A, B, C e D), e o filtro acontece apenas entre as redes. Todos os
firewalls representados também podem fazer roteamento.

FIGURA 3.1 – Exemplo de topologia de rede clássico.

Retirado de (GAMAYUNOV et al., 2013)

A migração da topologia inicial para SDN com preservação das polı́ticas de segurança
seguem alguns passos.
CAPÍTULO 3. TRABALHOS RELACIONADOS 33

Entrada: composta pela topologia de rede existente e a lista de regras de todos os

firewalls. O algoritmo de migração:

1. Otimização de regras. Após esse passo o número de regras deve ser igual ou menor
ao número de regras de entrada;

2. Construção de um firewall lógico virtual para cada sub-rede na topologia;

3. Cálculo do menor número de switches OpenFlow necessários e seleção da topologia

SDN

4. Tradução das regras de firewall para regras de fluxo para cada switch OpenFlow.

Resultado: é a geração de uma polı́tica de controle de acesso para cada switch OpenFlow
da topologia contendo em cada um as regras que são capazes de reproduzir a mesma
situação da rede original.
As regras de firewall costumam ser numeradas e o número sequencial é muito impor-
tante na análise do pacote, pois as regras são analisadas seguindo essa ordem. Se esse
número não for especificado corretamente, alguma regra pode se sobrepor a outra dife-
rentemente do esperado pela polı́tica de segurança definida. Essa ordem é irrelevante em
alguns casos; se um fluxo de rede casar com uma regra “A”, mas não houver possibilida-
des dele corresponder também com a regra “B”, então não faz diferença qual dessas duas
regras será analisada primeiro, por consequência, o número sequencial de “A” tanto pode
ser maior como pode ser menor que o número sequencial de “B”.
No terceiro passo é definido a quantidade de switches e a topologia que será utilizada.
Existem diversas topologias (grafo totalmente conectado, anel, estrela, etc.), e nesse caso,
a escolhida foi a de grafo totalmente conectado. Para essa topologia, ao usar n switches,
n-1 portas em cada um deles são necessárias para a interligação de todos. A escolha final
pode ser vista na figura 3.2.
A tradução de ACL Cisco para regras SDN é o último passo, e há algumas diferenças
entre os duas abordagens. Em ACL Cisco é possı́vel especificar uma faixa de portas de
origem e de destino, e o protocolo OpenFlow não suporta isso. Outra diferença é que
ACL Cisco permitem definir faixas de tempo, como por exemplo, durante a semana das
10:00 as 19:00. Isso pode ser implementado no controlador SDN instalando e removendo
as regras das tabelas de fluxo. Já em SDN é possı́vel filtrar pacotes usando campos de
cabeçalho L2-L4 (endereço IP e endereço MAC, por exemplo) na mesma regra. Também
é possı́vel filtrar pacotes de uma VLAN ou que tenha um rótulo MPLS especı́fico. Outros
tipos de regras podem ser implementadas mais facilmente pois são mais diretas.
Esse artigo mostra que é possı́vel substituir dispositivos de firewall por regras de fluxo
SDN. Para o estudo, o autor utiliza como entrada ACLs da Cisco, que, devido a sua
CAPÍTULO 3. TRABALHOS RELACIONADOS 34

FIGURA 3.2 – Exemplo de topologia resultante. Todos os 5 switches são SDN e estão
conectados ao controlador, que não foi ilustrado na figura.
Imagem retirada de (GAMAYUNOV et al., 2013).

sintaxe simples, pode ser traduzida facilmente para outros tipos de firewalls tradicionais.
Além de substituir o firewall, é possı́vel também alterar a arquitetura da rede mantendo
as mesmas polı́ticas. Apesar de provar conceitos importante na migração de firewalls para
SDN, este trabalho não cuida da consistência na arquitetura gerada.
Um modelo de Tabelas de Fluxo Hierárquicas (HFT - Hierarchical Flow Tables) para
SDN foi apresentado por (FERGUSON et al., 2012). As polı́ticas são organizadas em árvores,
onde cada componente da árvore pode determinar independentemente a ação a ser tomada
em cada pacote. Se essas partes diferentes da árvore chegarem a um conflito, ele é resolvido
por um operador de resolução definido pelo usuário e é colocado em cada nó da árvore.
Essas polı́ticas hierárquicas são compiladas em Tabelas de Fluxo de Rede (Network
Flow Tables), que são instruções simples e lineares. A Tabela de Fluxo de Rede por sua
vez é traduzida para instruções de baixo nı́vel para que possam ser distribuı́das para os
switches. Para fazer esse processo é usada uma Base de Informações de Rede (NIB -
Network Information Base), que foi inspirada na NIB utilizada pelo controlador ONIX.
CAPÍTULO 3. TRABALHOS RELACIONADOS 35

Este controlador é uma referência na área por oferecer APIs que permitem que cada
plataforma faça sua implementação especı́fica a partir de suas primitivas (KOPONEN et
al., 2010). A NIB é um banco de dados que contém todos os elementos de rede (switches,
hosts, portas, links).
O funcionamento da HFT é ilustrado na figura 3.3, que representa uma tabela de
fluxos hierárquica que foi gerada segundo algumas polı́ticas definidas. Esta figura ilustra
um pacote sendo analisado que tem como origem o endereço IP [Link], seu destino é o IP
[Link] e a porta de destino é a 80, e é verificado por cada nó da hierarquia. Alguns nós
foram coloridos de verde para mostrar quando a polı́tica presente nele casam com algum
campo do cabeçalho do pacote analisado. Os passos da análise são descritos abaixo:

FIGURA 3.3 – Avaliação de um pacote pela HTF.

Imagem retirada de (FERGUSON et al., 2012)

• A polı́tica do nó 5 diz que pacotes cujo endereço de origem seja [Link] podem
prosseguir;

• O nó 4 utiliza a expressão GMB, que é Garantia Mı́nima de Banda (guaranteed

minimum bandwidth). Ou seja, pacotes destinados a porta 80, devem ter uma
garantia mı́nima de banda de 10;

• Os nós 4 e 5 são filhos do nó 3, que verifica que há um conflito. Conflitos são
resolvidos através de operadores de conflito presentes ao longo da árvore. Nesse
caso, o operador de conflito é representado por GMB(10) + S Allow = GMB(10),
ou seja, o nó 4 pede uma garantia mı́nima de banda igual a 10 (dstPort = 80, GMB
= 10), e o nó 5 permite a passagem do pacote (srcIP = [Link], Allow), com isso
o resultado é a garantia mı́nima de banda igual a 10. O nó 3 não tem nenhuma
polı́tica e não interfere no resultado final;
CAPÍTULO 3. TRABALHOS RELACIONADOS 36

• O nó 2 tem como polı́tica GMB(30) caso o pacote tenha como destino o IP [Link];

• O nó 1 tem como filhos os nós 2 e 3, e outro conflito é detectado. O nó 2 pede uma
garantia mı́nima de banda de 30, ao passo que o nó 3 pede uma garantia mı́nima de
banda de 10. A polı́tica de resolução de conflito aplicada é GMB(30) + S GMB(10)
= GMB(max(30, 10)), tendo como resultado GMB(30). A polı́tica presente no nó
1 que nega pacotes destinados a porta 22 não se aplica ao pacote analisado, por isso
não influencia o resultado final. Com isso, o pacote pode prosseguir com garantia
mı́nima de banda igual a 30.

A HFT foi testada como parte de um protótipo de um controlador SDN logicamente

centralizado chamado PANE (FERGUSON et al., 2013). Ela permite que polı́ticas de segu-
rança de alto nı́vel sejam traduzidas em instruções de baixo nı́vel sem que seja necessário
conhecer a topologia da rede. Com isso é possı́vel que vários administradores criem polı́-
ticas e especifiquem operadores de resolução de conflito em cada nó.
Esses operadores de resolução de conflito poderiam ser utilizados para definir uma
hierarquia de polı́ticas, fazendo com que determinadas regras nunca pudessem ser deso-
bedecidas. Mas a HFT foi implementada como parte do controlador, ou seja, para poder
utilizá-la com outros controladores seria necessário alterá-los profundamente.
O OPTWALL descrito em (ACHARYA et al., 2007) propõe um framework de otimização
hierárquica e adaptativa de firewall, com o objetivo de diminuir seu custo operacional.
Esse projeto foi o primeiro do seu tipo a usar as caracterı́sticas do tráfego para planejar
um firewall hierárquico adaptativo, e os experimentos foram conduzidos em ipchains no
Linux, portanto, ambiente não SDN.
Em um firewall baseado em lista as regras de segurança são dispostas como uma lista
com tuplas, que por sua vez é composta por campos de redes (como endereços IP de
origem e destino, porta, protocolo) e por um campo de ação a ser tomada. A posição da
tupla na lista define sua prioridade: quanto mais no inı́cio da lista, maior a prioridade
da regra. A lista de regras é verificada sequencialmente, e quando o pacote casar com
uma tupla, a ação definida nessa tupla é aplicada ao pacote, e a verificação termina. Esse
tempo que a lista leva para ser percorrida gera um processamento adicional que pode ser
reduzido se as regras forem reordenadas seguindo a classificação proposta pelo autor do
OPTWALL.
Duas métricas foram criadas para classificar o tráfego. A primeira é a rule size e mede
o tamanho de uma dada regra em termos de número de bits necessários para determinar
uma combinação entre a regra e os campos do pacote inspecionado. Por exemplo, se
houverem duas regras, sendo que uma regra diz que os pacotes vindos do endereço IP
[Link] podem passar, e outra diz que os pacotes vindo do endereço IP [Link] e
CAPÍTULO 3. TRABALHOS RELACIONADOS 37

porta 22 podem passar, teremos que segunda regra terá um rule size maior que a primeira,
pois mais bits precisaram ser analisados.
A segunda métrica é o custo de operação de uma regra, e ele depende de:

• Posição da regra: as regras de firewall ficam dispostas em uma lista sequencial.

Quanto mais no topo da lista, menor o custo de operação.

• Tamanho da regra: o rule size, explicado acima.

• Quantidade de vezes que essa regra é chamada: algumas regras são analisadas mais
vezes que outras. Por exemplo, em uma rede com um servidor NTP e um servidor
Web, provavelmente muitos mais pacotes serão destinados ao servidor Web, portanto
regras referentes a ele deveriam ficar mais no topo da lista.

O processo para construir a estrutura hierárquica é composto de três passos:

• Pré processamento (Pre-processing): Pega a lista original e produz uma lista otimi-
zada, com regras disjuntas e concisas. Todas as redundâncias e dependências são
eliminadas. Isso permite ao OPTWALL reordenar e dividir as regras em sub-grupos
sem violar a semântica original.

• Ordenação (Ordering): As regras são reordenadas de maneira que as de maior custo

sejam colocadas no topo da lista (as duas métricas explicadas anteriormente são
usadas para fazer essa ordenação). Isso reduz o custo de processar todo o tráfego.

• Divisão (Splitting): Esse passo divide o conjunto inicial de regras em subconjuntos

de regras mutuamente disjuntas. Isso é feito pegando o conjunto pré-processado de
regras e o dividir em subgrupos, cada um definido por um filtro. Cada filtro é uma
série de tuplas disjuntas com total cobertura sobre as regras desse subgrupo.

O processo de particionamento das regras inicia no conjunto inicial de regras, que é

inicialmente dividido em dois subgrupos. Esse processo é repetido recursivamente, gerando
um novo nı́vel da hierarquia. O processo continua até que o custo global do processamento
supera o benefı́cio ganho caso o processo de divisão continue.
O OPTWALL analisa o tráfego em tempo real para verificar se houve alguma mudança
muito grande em suas caracterı́sticas e verifica se o hit count de alguma regra mudou além
de um parâmetro pré-determinado. Em caso positivo, o balanceamento é feito novamente,
incluindo novas regras que possam ter sido adicionadas.
O resultado final de todo esse processo consegue reduzir a utilização de CPU do firewall,
mostrando que, dada uma lista com muitas regras, é possı́vel otimizá-las e conseguir o
mesmo resultado esperado com menor custo computacional.
CAPÍTULO 3. TRABALHOS RELACIONADOS 38

Para o OPTWALL, a hierarquia refere-se a uma estrutura em árvore que consegue

melhorar o desempenho do firewall. Em sistemas baseados em lista de regras, a análise é
sequencial, e o processamento é interrompido quando há uma combinação. Ou seja, regras
com maior prioridade devem ser colocadas no inı́cio da lista, definindo assim, a hierarquia
esperada nesta dissertação. O OPTWALL mantém essa ordenação pois divide as regras
em sub-grupos antes de fazer a re-ordenação delas.
O OPTWALL não foi feito para trabalhar em ambiente distribuı́do, onde uma área
possa determinar algumas regras que não possam ser contrariadas por outras localidades,
além de ser para ambiente não SDN.

3.2 Verificação de Conflitos de Regras

O VeriFlow tem por objetivo verificar conflito de regras em tempo real. Ele é uma
camada entre o controlador SDN e os switches, e verifica violações no momento em que as
regras são inseridas, alteradas ou removidas. Demorar segundos ou horas pode prejudicar
a consistência do estado da rede. A versão abordada em (KHURSHID et al., 2012) foi
feita para a versão 1.1.0 do protocolo OpenFlow e para regras de redirecionamento de IP,
mas não funciona com ações de alteração de cabeçalhos de pacotes como NAT (Network
Address Translation - Tradução de endereço de rede), por exemplo.
O autor destaca que a análise em uma camada entre o controlador e o switch é in-
teressante pois as aplicações que executam sobre um controlador além de poderem ser
complexas, podem ter sido desenvolvidas por diversas pessoas que estão além do controle
do administrador da rede.
Para fazer essa verificação, o VeriFlow realiza três passos:

• Divide a rede em classes de equivalência (EC - equivalence classes). Essa divisão é

feita usando a nova regra e qualquer outra existente que tenha alguma sobreposição.
Cada EC é um conjunto de regras que tem a mesma ação de encaminhamento pela
rede. Com isso, apenas uma pequena quantidade de ECs serão afetadas por cada
mudança na rede.

• O VeriFlow cria grafos de redirecionamento para cada EC alterada, representando

o comportamento de redirecionamento da rede.

• O VeriFlow atravessa esses grafos a procura de invariantes, que são funções de

verificação especificadas.

Se a função de verificação encontrar problemas, novas ações podem ser desencadeadas

dentro do VeriFlow, como instalar a regra e enviar um aviso para o operador, ou ignorá-la.
CAPÍTULO 3. TRABALHOS RELACIONADOS 39

Pode acontecer de determinada regra precisar ser verificada em muitas ECs, fato que
impossibilita a verificação em tempo real. Nesse caso o VeriFlow instala a regra e continua
a verificação em paralelo. Mas os testes realizados mostraram que aproximadamente 99%
das vezes o número de ECs afetadas é menor que dez.
A implementação foi feita de duas maneiras: uma como um proxy entre o controlador
e o switch e outra integrada ao controlador NOX 0.9.1. A alteração feita consiste em
fazer o NOX interceptar todas as mensagens flow table modification e redirecioná-la ao
VeriFlow. Caso algum problema seja encontrado a regra de fluxo é bloqueada.
Além de não trabalhar com alterações de cabeçalhos de pacotes como tradução de en-
dereço de rede (NAT - Network Address Translation), outro grande problema no VeriFlow
é que ele precisa ter a visão global da rede, por isso ele não foi feito para trabalhar em
ambientes com múltiplos controladores, pois segundo o autor, obter tal visão nesse tipo
de ambiente seria difı́cil.
O FortNOX (PORRAS et al., 2012) é uma extensão para aplicar polı́ticas de segurança
ao controlador NOX (GUDE et al., 2008). Ele faz resolução de conflito de regras em tempo
real e autorização baseada em papéis.
Toda operação que define ou altera um fluxo passa por uma Análise de Conflito Base-
ada em Papéis (RCA - Rule-based Conflict Analysis), que garante que cada regra subme-
tida não conflite com uma regra existente cujo autor esteja associado com uma autoridade
maior do que o autor da regra candidata.
Para fazer a verificação de conflito de regras o FortNOX implementa um esquema de
autorização hierárquico com três papéis conforme abaixo:

• ADMIN: Atribuı́do a regras de fluxo criada por aplicações administrativas, como

um console de administração, por exemplo. Essas regras tem a mais alta prioridade
no esquema de resolução de conflitos;

• SEC: Algumas aplicações de rede podem alterar dinamicamente ou estender as polı́-

ticas de segurança em resposta a alguma ameaça detectada em tempo de execução;
como um fluxo malicioso, um ativo de rede interno infectado, uma blacklist de al-
guma entidade externa, ou um novo padrão de rede malicioso. Essas aplicações de
segurança geram regras com o papel SEC, que tem a segunda maior prioridade na
verificação de conflitos.

• APP: Todas as outras aplicações geram regras com o papel APP.

Em outro trabalho que é a continuação do FortNOX (PORRAS et al., 2015) afirma que
um conflito de regras surge quando uma regra candidata ativa ou desativa um fluxo de
CAPÍTULO 3. TRABALHOS RELACIONADOS 40

rede que de outra forma é inversamente proibida, ou permitida, por uma regra existente.
O conflito pode ser direto ou indireto:

• Conflito direto é quando uma regra candidata contraria uma regra existente (uma
regra existente redireciona pacotes entre A e B enquanto uma regra candidata os
descarta);

• Conflito indireto ocorre quando uma regra candidata em conjunto com outra regra
pré-existente contraria alguma regra. Por exemplo, existe uma regra que permite
pacotes de A para B, e uma que nega pacotes de A para C, e a regra candidata
permite pacotes de B para C.

Apesar de ter sido desenvolvido para o controlador NOX, o autor menciona que a
metodologia poderia ser extendida para outras arquiteturas, como Beacon, Maestro e
DevoFlow.
O FortNOX faz verificação de conflito de regras baseada em papéis, e as advindas
de aplicações com papel de ADMIN têm maior prioridade e não podem ser ignoradas
por aplicações com papel SEC ou APP. Nesta dissertação espera-se fazer uma verificação
de regras mas não baseadas em papéis, mas sim em uma hierarquia de controladores.
Outra diferença é que essa verificação será feita em uma aplicação executando sobre o
controlador, e não em um módulo dentro dele. Utilizar aplicações ao invés de módulos é
interessante pois existem muitos controladores disponı́veis atualmente, e nem todos têm
seu código fonte disponı́vel para que tais módulos possam ser adicionados.
O FlowGuard (HU et al., 2014) é um framework para detectar e resolver violações nas
polı́ticas de firewall em redes baseadas em OpenFlow. Ele verifica o espaço de fluxo de
rede para detectar violações no momento que o estado da rede é atualizado.
A detecção de violação é algo complexo pois tanto as regras de fluxo como as de
firewall podem fazer referência a um endereço IP exato, mas também a uma faixa de
endereços. Por exemplo, é possı́vel fazer uma regra que tenha como origem o endereço IP
[Link]/24, e qualquer pacote no intervalo de [Link] até [Link] irão casar
com ela.
Além disso, os campos dos cabeçalhos dos pacotes do fluxo podem ser alterados di-
namicamente enquanto atravessam a rede. Isso é feito usando-se uma ação Set-Field do
OpenFlow. As ações Set-Field alteram valores de campos dos cabeçalhos nos pacotes,
sendo possı́vel, por exemplo, alterar o endereço IP de destino de um pacote. A tabela 3.1
ilustra como isso pode afetar a integridade do firewall.
Mesmo que as regras da tabela 3.1 sejam analisadas na ordem, um pacote que tenha
A como IP de origem e D como endereço de destino terá seu cabeçalho alterado e chegará
CAPÍTULO 3. TRABALHOS RELACIONADOS 41

# Ação Descrição
1 A to B, DROP Pacotes que tenham A como IP de origem, e
B como IP de destino devem ser descartados
2 * to D, set D → B, Output to table Qualquer pacote com IP de destino igual a
D, altere o IP de destino de D para B. Con-
tinue checando o pacote
3 A to *, set A → C, Output to table Pacotes que tenham A como IP de origem,
altere o IP de origem para C. Continue che-
cando o pacote
4 C to B, forward Pacotes cujo IP de origem seja C, e IP de
destino seja B, encaminhar
TABELA 3.1 – Exemplo de como alteração do cabeçalho do pacote pode influenciar no
firewall

até B, o que contraria a primeira regra que define que fluxos de A para B devem ser
descartados. Por esses motivos é necessário seguir todo o caminho da rede e determinar
a origem inicial e o destino final de cada fluxo da rede. Isso é feito em três passos:

• Análise do espaço de fluxo de rede: É feita uma análise do fluxo de rede, desde a
origem do pacote até seu destino, mesmo que haja alterações nesse pacote. Define-se
três espaços de fluxo:

– Espaço de fluxo de entrada: Representa os cabeçalhos de pacotes de origem

que podem trafegar pelo fluxo;
– Espaço de fluxo de saı́da: Representa os cabeçalhos de pacotes depois deles
passarem pelo fluxo, com eventuais alterações que podem ter sofrido ao longo
do caminho;
– Espaço de fluxo monitorados: É a combinação dos dois anteriores, ou seja,
contém os cabeçalhos de pacotes com o endereço inicial (antes de passar pelo
fluxo), e com o endereço final depois de passar pelo fluxo (e terem sofrido
eventuais alterações).

• Divisão do espaço de autorização do firewall: As regras de firewall são divididas em

dois espaços: espaço de autorização negado, e espaço de autorização permitido.

• Descoberta da violação: Verifica-se se há intersecção entre os espaços definidos nos

dois passos anteriores. Essa interesecção representa as violações de polı́ticas de
firewall.

Existem dois tipos de violação de polı́ticas de firewall: a completa e a parcial:

• Violação completa: Se o espaço de autorização negado contiver todo espaço percor-

rido pelo fluxo, é uma violação completa;
CAPÍTULO 3. TRABALHOS RELACIONADOS 42

• Violação parcial: Se o espaço de autorização negado contiver somente parte do

espaço percorrido pelo fluxo, é uma violação parcial.

A resolução da violação é uma tarefa que precisa de atenção. Caso haja uma violação
parcial, remover a regra pode afetar o funcionamento da rede. Se a regra tiver alguma
dependência com outras regras, sua remoção pode causar impacto em outras regras, e
causar novas violações. Para evitar isso, o FlowGuard utiliza quatro técnicas:

• Quebra da dependência: Ao adicionar numa nova polı́tica de fluxo, ela pode não
violar a polı́tica de firewall, mas pode violar a polı́tica de fluxo existente. Isso pode
gerar dependências entre regras, que por sua vez podem causas violação da polı́tica
de firewall. Para evitar isso, dois mecanismos são utilizados:

– Re-roteamento de fluxo: caso um novo fluxo gere um caminho que cause uma
dependência de regras, a aplicação de firewall pede ao controlador um novo
caminho sem dependências. Esse processo pode ser executado recursivamente
até que o controlador encontre um caminho que não gere uma violação;
– Marcar o fluxo: os pacotes do fluxo são marcados, e tratados de maneira dife-
rente por outras polı́ticas.

• Rejeitar a atualização: aplicado a três casos: 1) ao adicionar uma nova polı́tica de

fluxo, ela gerar uma violação completa; 2) alterar uma regra levar a uma violação
completa; 3) apagar uma regra gerar uma violação completa;

• Remover o fluxo: aplicado a dois casos: 1) se a atualização (adição, alteração,

ou remoção) de uma regra da polı́tica de firewall gerar uma violação completa;
2) a alteração ou remoção de uma regra é permitida mesmo causando violação
completa. Nesses dois casos, todos os fluxos referentes a essa violação são removidos
dos switches.

• Bloquear o pacote: aplicada a qualquer violação parcial detectada pela aplicação de

firewall.

O FlowGuard é um framework para desenvolvimento de aplicações de firewall para

rede baseadas em OpenFlow. Para cada novo fluxo, ele analisa todo o caminho por onde
esse fluxo pode passar na rede, verificando, desde a fonte inicial até o destino final, se esse
novo fluxo passa por algum espaço de autorização negado. Embora o FlowGuard faça a
verificação fim-a-fim do fluxo, o objetivo dessa dissertação não é exatamente o mesmo,
visto que deseja-se aqui priorizar as regras da hierarquia superior.
O conceito de virtualização em redes oferece a possibilidade de configurar várias redes
lógicas em uma infraestrutura comum de rede. Em redes OpenFlow uma solução de virtu-
alização muito citada é o FlowVisor (SHERWOOD et al., 2009). O FlowVisor cria camadas
CAPÍTULO 3. TRABALHOS RELACIONADOS 43

na rede SDN e permite que cada uma delas seja gerenciada por um controlador diferente.
A virtualização em OpenFlow permite que vários controladores instalem entradas de fluxo
em um mesmo switch. Segundo (NATARAJAN et al., 2012), isso pode gerar conflitos e erros
de configuração pelo fato de os switches OpenFlow atuais não oferecerem mecanismos de
isolamento por hardware nas tabelas de fluxo. Caso haja conflitos, o OpenFlow atribui
prioridades a cada entrada de fluxo. Mas em ambientes SDN virtualizados onde vários
controladores alteram as tabelas de fluxo, utilizar prioridades pode fazer com que o rote-
amento final não reflita a visão de cada controlador.
Para resolver esse tipo de problema em redes OpenFlow virtualizadas, (NATARAJAN et
al., 2012) apresentam duas técnicas de detecção de conflitos. O primeiro método usa uma
estrutura hı́brida hash-trie para representar a tabela de fluxos. O segundo método usa
um sistema de ontologia baseado em lógica de inferência. Em testes executados usando
uma tabela de fluxo com milhares de fluxos de entrada ambas as técnicas resolveram
os conflitos em aproximadamente 100 milissegundos. Os dois métodos de detecção de
conflitos serão detalhados a seguir.
A detecção de conflito baseado em hash-trie associa um FlowID a cada entrada de
fluxo e utiliza um método dividir e conquistar. O “dividir” divide cada entrada de fluxo
em conjuntos de campos de cabeçalhos para detectar o conflito em cada campo individu-
almente, e retorna um conjunto de FlowIDs que representa os conflitos em cada campo.
No “conquistar” o conjunto de FlowIDs retornados de cada campo são colocados uma
tabela Matriz de Intersecção (Intersection Matrix Table) para determinar quais entradas
de fluxo são conflitantes com a nova entrada de fluxo. A figura 3.4 ilustra esse algoritmo.
Input: new flow entry

DIVIDE

Ingress Eth Eth Eth VLAN VLAN IP IP Src Dst IP IP

Ip ToS
Port Src Dst Type ID Priority Proto ToS Port Port Src Dst

Hash-Trie Radix Trie

Intersection Matrix Table

CONQUER

Output: conflicting flow entries

FIGURA 3.4 – Workflow da detecção de conflito baseado em Hash-Trie.

Imagem retirada de (NATARAJAN et al., 2012).

Os campos IP de origem e IP de destino são chamados pelos autores de “Campos

CAPÍTULO 3. TRABALHOS RELACIONADOS 44

Baseados em Prefixo” e são representados usando uma estrutura radix trie, e os outros
são chamados de “Campos de Valores Exatos” e são armazenados em uma estrutura que
usa uma combinação de trie e hash.
A estrutura trie é uma estrutura de dados que cria uma árvore de prefixos. Segundo
(SEDGEWICK; WAYNE, 2011), cada nó da árvore contém links que podem ser nulos ou
ser referência para outros nós. Cada nó tem N links, onde N é o tamanho do alfabeto
utilizado. Cada link corresponde a um caractere. Cada nó tem um valor correspondente,
que pode ser nulo, ou conter o valor associado à palavra representada na árvore. Quando
o valor do nó não é nulo, significa que ele é o último caractere da palavra. A figura 3.5
mostra o exemplo de uma trie. Apesar dessa representação, na prática cada nó da árvore
tem N links, mas os nós nulos não são representados.
root

link para a trie para

todas as palavras que
começam com S

link para a trie para

todas as palavras que
b s t começam com "she"

valor para "she" no

nó correspondente
y 4 e h h ao último caractere
da palavra

a 2 l e 0 e 5

Palavra Valor
l l
by 4
sea 2
sells 1
she 0
shells 3
s 1 l
the 5

s 3
Rotular cada nó com
o caractere associado
ao link de entrada

FIGURA 3.5 – Exemplo de uma estrutura trie.

Retirado de (SEDGEWICK; WAYNE, 2011)

Para efetuar uma busca em uma trie, a partir do nó raı́z, segue-se o link correspondente
ao primeiro caractere da palavra; a partir desse nó, segue-se o nó correspondente ao
segundo caractere da palavra, e assim sucessivamente, até encontrar o último caractere
da palavra, ou um link nulo. Nesse ponto, existem três condições:
CAPÍTULO 3. TRABALHOS RELACIONADOS 45

• O valor do nó correspondente ao último caractere da palavra não é nulo. Isso quer
dizer que a busca encontrou a palavra procurada. O valor associado com a palavra
é o valor no nó correspondente ao último caractere;

• O valor no nó correspondente ao último caractere da palavra é nulo. Isso significa

que a palavra não foi encontrada;

• a busca terminou com um link nulo. A palavra também não foi encontrada.

Para encontrar os os endereços IPs conflitantes é utilizado o mecanismo “Longest Prefix

Match”. Dado uma string, a função Longest Prefix Match retorna o valor da maior palavra
que é prefixo dessa string. No caso da árvore da figura 3.5, uma busca pela string “shell”,
o maior prefixo seria “she”, e para a string “shellshort” o maior prefixo seria “shells”. O
algoritmo implementado no artigo realiza uma busca Longest Prefix Match e, encontrado
o maior prefixo, todos os nós pais e filhos representam entradas de fluxo conflitantes com
o fluxo de entrada. Todos os FlowIDs desses fluxos conflitantes são alterados para o valor
1 na matriz de intersecção.
Cada um dos outros campos (campos de valor exato) são armazenados em uma es-
trutura que combina hash e trie. A raı́z da árvore representa entradas que tenham o *
como valor, ou sejam qualquer valor. Abaixo da raı́z, os valores são armazenados usando
uma tabela hash, onde mais de uma entrada de fluxo pode ser mapeada para o mesmo
valor. Dada a tabela de fluxos 3.2, a estrutura hash-trie para o campo “Ingress Port” seria
representada na figura 3.6. Na tabela, os fluxos e3 e e4 estão com *, ou seja, qualquer
porta de entrada, por isso estão associados ao nó raı́z. O fluxo e1 tem como porta de
entrada o valor 5, por isso ele está associado a esse valor na tabela hash, e o fluxo e2 tem
o valor 1, e está associado a esse valor. Para cada nova entrada de fluxo, os campos são
comparados, e se ele casar com algum valor na tabela hash, os FlowIDs associados a esse
valor e os associados ao nó raı́z são retornados. Se o valor da nova entrada for *, todos
os FlowIDs são retornados. Esses FlowIDs retornados são usados para atualizar a matriz
intersecção.
Flows Ingress Ether Ether Ether VLAN VLAN IP IP IP IP Src Dst Actions
Port Src Dst Type ID Prio- Src Dst Proto ToS Port Port
rity
e1 5 00:24: 58:B0: 0x800 * * * 01* TCP * * 2211 action
D7:63: 35:F6: 1
2C:14 12:F1
e2 1 * * 0x800 * * 010* 100* UDP * * 2210 action
2
e3 * * * 0x800 * * 101* 011* * * * 2211 action
3
e4 * * * * * * * * * * * * action
4

TABELA 3.2 – Exemplo de uma tabela de fluxos. Cada linha representa uma entrada de
fluxo, e cada coluna representa um campo do cabeçalho OpenFlow
CAPÍTULO 3. TRABALHOS RELACIONADOS 46

* {e3, e4}

Hash h(5) h(1)

5 1

{e1} {e2}

FIGURA 3.6 – Estrutura hash-trie para o campo “Ingress Port” da tabela de fluxos 3.2.
Retirado de (NATARAJAN et al., 2012)

Na matriz de intersecção, cada linha representa uma entrada de fluxo, e cada coluna
representa um campo do cabeçalho do pacote. Inicialmente, todas as entradas da matriz
de intersecção são preenchidas com zero (0). Se no passo anterior for detectado um conflito
no campo “IP de origem” da entrada de fluxo “e1”, essa célula da matriz será alterada para
um (1). Após preenchida, se alguma linha da matriz tiver somente valores 1’s, significa
que essa entrada conflita com a nova entrada de fluxo.
A tabela 3.2 é um exemplo de uma tabela de fluxos OpenFlow, onde cada linha é
uma entrada de fluxo, e cada coluna é um campo do cabeçalho OpenFlow. Dado um
ambiente que esteja configurado com essa tabela, se nele for inserido a nova entrada de
fluxo [5,*,*,*,*,*,10*,01*,TCP,*,*,*], o algoritmo hash-trie preenche a matriz intersecção
conforme pode-se ver na tabela 3.3. As linhas referentes aos fluxos e1, e3 e e4 estão
preenchidas totalmente com 1’s, o que indica que o novo fluxo conflita com esses três
fluxos.
Flows f1 f2 f3 f4 f5 f6 f7 f8 f9 f10 f11 f12
e1 1 1 1 1 1 1 1 1 1 1 1 1
e2 0 1 1 1 1 1 0 0 0 1 1 1
e3 1 1 1 1 1 1 1 1 1 1 1 1
e4 1 1 1 1 1 1 1 1 1 1 1 1
TABELA 3.3 – Exemplo de uma Matriz de Intersecção preenchida

A segunda técnica apresentada por (NATARAJAN et al., 2012) utiliza um sistema de

lógica baseada em ontologia para detectar os conflitos. Nele, uma linguagem de represen-
tação transforma o conhecimento do mundo real em uma representação lógica, e com uma
metodologia de raciocı́nio consegue deduzir e inferir soluções através de conhecimento
acumulado.
A tabela de fluxos é representada usando Lógica de Descrição (Description Logic (BA-
ADER et al., 2003)). Uma classe representa uma tabela de fluxos, e ela contém um conjunto
de indivı́duos, que são as entradas de fluxo. A linguagem de pesquisa baseada em lógica
de descrição provê um mecanismo de pesquisa que consegue determinar se há conflitos
entre as entradas de fluxo.
CAPÍTULO 3. TRABALHOS RELACIONADOS 47

As duas técnicas apresentadas por (NATARAJAN et al., 2012) conseguem detectar con-
flitos entre regras de fluxo em um ambiente OpenFlow virtualizado. A primeira técnica
utiliza uma estrutura hı́brida de hash-trie para detectar conflitos, e pode ser adaptada
para detecção de conflitos em um ambiente SDN hierárquico. A segunda técnica utiliza
uma Lógica de Descrição para representar a tabela de fluxos, e nela efetuar pesquisas para
detectar os conflitos. Ambas as técnicas parecem complexas, e o artigo não deixa claro
como aplicar a segunda técnica. Conforme será mostrado no capı́tulo 4, subseção 4.3,
nesta dissertação será utilizada uma adaptação da técnica hash-trie para a verificação de
conflitos.

3.3 Discussão dos Trabalhos Relacionados

Todos os trabalhos apresentados nesse capı́tulo trouxeram informações importantes

para o desenvolvimento desta dissertação.
Em seu artigo, (GAMAYUNOV et al., 2013) demonstra que é possı́vel substituir um
firewall tradicional por regras de fluxo em SDN e conseguir as mesmas polı́ticas de segu-
rança em uma nova estrutura de rede. O objetivo é migrar as regras de firewall, e não
manter a coerência entre elas depois que a rede estiver em funcionamento, ou seja, quando
novas regras são inseridas não é feita uma verificação de conflitos com as regras existentes.
A Tabela de Fluxo Hierárquicos de (FERGUSON et al., 2012) utiliza o termo hierárquico
pois faz uso de uma estrutura em árvore para organizar as regras e com isso melhorar o
desempenho do firewall. Para o OPTWALL de (ACHARYA et al., 2007), o termo hierárquico
diz respeito à ordem com que as regras devem ser dispostas na lista de regras, também com
o objetivo de melhorar o desempenho do firewall. Nos dois artigos o termo hierárquico não
diz respeito a regras definidas por um nı́vel superior e que não podem ser contrariadas.
O Veriflow de (KHURSHID et al., 2012), o FlowGuard de (HU et al., 2014) e (NATARAJAN
et al., 2012) demonstram a verificação de conflito em redes OpenFlow mas não abordam
a hieraquia entre as regras.
O FortNox de (PORRAS et al., 2012) faz a verificação de conflitos de regras e define
uma hierarquia baseada em papéis e não uma hierarquia entre os controladores
A tabela 3.4 mostra um resumo das caracterı́sticas dos trabalhos analisados. Esta dis-
sertação irá focar nas três primeiras colunas da tabela: Definição de Regras Hierárquicas;
Verificação de Conflitos; Tratamento SDN de Regras de Firewall.
CAPÍTULO 3. TRABALHOS RELACIONADOS 48

Definição Verificação Tratamento Otimização

de Regras de SDN de de Regras
Hierárquicas Conflitos regras de
Firewall
(GAMAYUNOV et al., Não Não Sim Sim
2013)
PANE (FERGUSON et al., Não Não Sim Sim
2012)
OPTWALL (ACHARYA et Não Não Não Sim
al., 2007)
Veriflow (KHURSHID et Não Sim Sim Não
al., 2012)
FortNox (PORRAS et al., Sim (Baseado Sim Sim Não
2012) em Papéis)
FlowGuard (HU et al., Não Sim Sim Não
2014)
(NATARAJAN et al., 2012) Não Sim Sim Não
TABELA 3.4 – Caracterı́sticas dos trabalhos analisados
4 Firewall Para SDN com
Verificação de Conflito de Regras
Hierárquicas

Este capı́tulo detalha a implementação do firewall proposto. Como mencionado, a

aplicação desenvolvida é um avanço em relação as funções de firewall já implementadas
no Ryu e que puderam ser totalmente aproveitadas. Foram feitas algumas alterações no
firewall do Ryu para que ele pudesse enviar e receber as regras do firewall desenvolvido
denominado Root, ou seja, o firewall que está no nı́vel mais alto da hierarquia. A próxima
subseção apresenta a arquitetura, explicando cada módulo que a compõe. A implementa-
ção técnica é detalhada na subseção 4.2. A subseção 4.3 apresenta a estratégia empregada
para a verificação dos conflitos entre regras.

4.1 Arquitetura do Firewall

Durante essa dissertação serão utilizados alguns termos que serão explicados abaixo
para facilitar a leitura:

Firewall Root : aplicação de firewall executando no nı́vel hierárquico superior, onde

serão inseridas regras que representem polı́ticas de segurança definidas pela alta
administração da organização;

Firewall Local : aplicação de firewall executando nas localidades, em um nı́vel hierár-

quico abaixo do Firewall Root;

Regras Root : Algumas polı́ticas de segurança definidas pela alta administração da

organização podem ser representadas diretamente como uma ou um conjunto de re-
gras de firewall, e foram denominadas Regras Root. Elas serão inseridas no Firewall
Root;

Regras Locais : Regras de firewall que são definidas pelos administradores locais, e que
CAPÍTULO 4. FIREWALL PARA SDN COM VERIFICAÇÃO DE CONFLITO DE
REGRAS HIERÁRQUICAS 50
dizem respeito somente àquela localidade. Essas Regras Locais não podem entrar
em conflito com as Regras Root;

Controlador Root : No nı́vel hierárquico superior, a aplicação Firewall Root executa

sobre um controlador SDN que será chamado Controlador Root;

Controlador Local : Nas localidades, a aplicação Firewall Local executa sobre um con-
trolador SDN que será chamado Controlador Local.

Outro termo importante que será utilizado é o “Conflito”. Nesta dissertação, duas
regras são consideradas em conflito quando, levando-se em consideração os campos a que
elas fizerem referência coincidirem, mas elas definirem ações divergentes. Por exemplo, na
tabela 4.1, caso a primeira regra seja analisada contra a segunda regra, elas estarão em
conflito pois, um pacote que corresponda com a primeira regra irá também corresponder
com a segunda regra (o endereço IP de origem da segunda regra representa uma faixa de
IPs que vai desde [Link] até [Link], ou seja, o IP de origem da primeira regra está
contido nesta faixa, mas a ação das duas regras são divergentes). Já a terceira regra está
em conflito com a primeira pois a porta de destino da primeira regra é a 80, e a terceira
regra não faz referência a nenhuma porta de destino, significando, portanto, qualquer
porta, ou seja, um pacote que corresponda com primeira regra irá também corresponder
com a terceira regra. A segunda e a terceira regras não estão em conflito pois, apesar de
haver pacotes que possam corresponder às duas ao mesmo tempo, elas definem a mesma
ação.

IP origem IP destino porta destino protocolo ação

[Link]/32 [Link]/32 80 TCP DENY
[Link]/8 [Link]/32 80 TCP ALLOW
[Link]/32 [Link]/32 TCP ALLOW
TABELA 4.1 – Exemplo de regras conflitantes

A verificação de conflitos nesta dissertação não leva em consideração a ordem das regras
pois a verificação não é feita com regras do mesmo nı́vel, ou seja, quando uma regra é
inserida no Firewall Root, ela é verificada somente contra Regras Locais, e vice-versa.
Isso é feito porque, em um mesmo nı́vel pode haver conflitos, que serão resolvidos pela
ordem em que as regras estão dispostas. Esse comportamento é necessário em situações
em que regras mais especı́ficas convivam com regras menos especı́ficas mas que tenham
ações diferentes. Por exemplo, para expressar uma polı́tica que diga que o DNS da rede
local só pode ser utilizado por hosts da própria rede, seriam necessárias duas regras: (1)
permitir pacotes do tipo UDP cujo IP de origem seja [Link]/8 com destino ao IP [Link]
na porta 53; (2) negar pacotes do tipo UDP com qualquer IP de origem ([Link]/0) com
destino ao IP [Link] na porta 53. Caso houvesse verificação de conflitos no mesmo
CAPÍTULO 4. FIREWALL PARA SDN COM VERIFICAÇÃO DE CONFLITO DE
REGRAS HIERÁRQUICAS 51
nı́vel, essas duas regras seriam detectadas como conflitantes pois elas tem ações opostas,
e pacotes que correspondam à primeira regras correspondem também à segunda regra (IP
de origem [Link]/8 está contido em [Link]/0).
Para fazer a verificação de conflito de regras hierárquicas foi definida uma arquitetura
de dois nı́veis, e foram desenvolvidas duas aplicações. No nı́vel superior, a aplicação será
chamada de “Firewall Root”. No nı́vel abaixo a aplicação será chamada de “Firewall
Local”, e uma instância dela executa em cada localidade. A arquitetura pode ser vista na
figura 4.1.

Operador
Firewall
Root

Interface
com Operador

Banco Verificação
de Dados de Conflito
de Regras

Interface
com o
Firewall Local

Firewall Firewall Firewall

Local 1 Local 2 Local N

Interface Interface Interface

Externa Externa Externa
...
Operador Interface Interface Interface
Local Controlador Controlador Controlador
SDN SDN SDN

FIGURA 4.1 – Arquitetura do firewall

Para a definição dessa arquitetura foram considerados dois cenários: (1) Empresas
com perfil Matriz - Filial; (2) Estruturação de diversas Organizações Militares (OMs) em
relação ao Comando Central em Brası́lia. Nestes cenários considerados não se identificou,
CAPÍTULO 4. FIREWALL PARA SDN COM VERIFICAÇÃO DE CONFLITO DE
REGRAS HIERÁRQUICAS 52
num primeiro momento, a necessidade dos nı́veis inferiores terem a visão geral da rede, mas
apenas seguir estratégias definidas pela matriz ou Comando Central. Portanto, conforme
pode-se ver na figura 4.1, não há comunicação entre os Firewalls Locais, mas somente entre
Firewall Local ↔ Firewall Root. Caso exista a necessidade de haver comunicação entre
os Controladores Locais, eles mesmos são responsáveis pelo compartilhamento da visão
global da rede, bem como das regras de firewall, como em um ambiente com controladores
logicamente centralizados, mas fisicamente distribuı́dos. Ou seja, o Controlador Root não
é responsável por orquestrar essa comunicação entre Controladores Locais.
As regras são inseridas em ambos os firewalls por operadores através de uma interface
disponibilizada, sendo que, no Firewall Local, essa mesma interface é utilizada para co-
municação com o Firewall Root. Na figura 4.1 também é possı́vel notar que o Firewall
Root não se comunica com os Controladores Locais e nem com os switches; quando uma
regra é inserida com sucesso no Firewall Root, ele a envia para os Firewalls Locais, e eles
são responsáveis pelo envia dessa regra para seus respectivos Controladores Locais.
Como é o Firewall Local que envia todas as regras para o controlador, depois que as
regras estiverem instaladas não há como diferenciar uma Regra Root de uma Regra Local.
É necessário distinguir as regras pois, como dito anteriormente, quando uma Regra Root
é inserida, ela é verificada somente contra Regras Locais, e vice-versa. Para fazer essa
distinção, optou-se por armazená-las em um banco de dados, em tabelas diferentes, para
evitar que o controlador precisasse lidar com esta informação. Desta maneira, a aplicação
fica totalmente independente do controlador.
A aplicação de Firewall Root gerencia este banco de dados, uma vez que é esta apli-
cação que executa o algoritmo de verificação de conflitos. Além disso as aplicações locais,
em maior número, terão o código simplificado.
O processo executado quando uma regra é inserida no Firewall Root é um pouco
diferente de quando é inserida em um Firewall Local. Esses processos serão detalhados a
seguir.
A figura 4.2 mostra um fluxograma de uma regra sendo inserida no Firewall Local. Os
passos seguidos são:

• A nova regra é inserida no Firewall Local através da interface externa;

• Verifica-se se a regra está vindo do Firewall Root. Essa verificação é necessária pois,
quando uma regra é inserida no Firewall Root, ele a encaminha para o Firewall
Local para que ele a envie para o Controlador Local;

• Caso a regra não venha do Firewall Root, ela é enviada para ele através da interface
externa;
CAPÍTULO 4. FIREWALL PARA SDN COM VERIFICAÇÃO DE CONFLITO DE
REGRAS HIERÁRQUICAS 53
Regra de firewall Local

Firewall Local Firewall Root

Não Conflita com Não

Regra veio Envia para o
firewall Root regras não
do Root?
Root?
Sim
Sim

Retorna
Retorna
erro para
erro.
Envia para o o operador
Controlador Local. Armazena em banco.
Retorna mensagem Retorna mensagem de
de sucesso para sucesso.
o operador.

Mensagem informando ao operador que a regra foi inserida com sucesso

Mensagem de erro informando que um conflito foi detectado. A regra não foi inserida

FIGURA 4.2 – Fluxograma de uma regra sendo inserida no Firewall Local.

• No Firewall Root há um banco de dados com todas as regras já inseridas (regras
Root e não Root). O Firewall Root verifica se a nova regra conflita com alguma
regra Root existente;

• Caso haja um conflito:

– o Firewall Root retorna um erro para o Firewall Local informando que o conflito
foi detectado;
– a mensagem de erro é retornada para o usuário.

• Caso não haja conflitos:

– a nova regra é armazenada em banco;

– uma mensagem de sucesso é enviada para o Firewall Local;
– a regra é enviada para o Controlador Local;
– a mensagem de sucesso é retornada para o usuário.

O processo para inserir regras no Firewall Root é um pouco diferente, conforme pode
ser visto na figura 4.3. Seus passos são:

• Como o Firewall Root também armazena em banco as regras não Root, ele verifica
se a nova regra conflita com alguma regra não Root já existente;
CAPÍTULO 4. FIREWALL PARA SDN COM VERIFICAÇÃO DE CONFLITO DE
REGRAS HIERÁRQUICAS 54

Regra de firewall Root

Firewall Root
Firewall Local

Regra veio Conflita com Sim

do Root? regras não
Root?
Retorna
Sim Não erro para
o operador

Armazena em banco.
Envia para o Envia para Firewall
Controlador Root. Local
Retorna mensagem
de sucesso.

Retorna mensagem de
sucesso para o operador

Mensagem informando ao operador que a regra foi inserida corretamente

Mensagem de erro informando que um conflito foi detectado. A regra não foi inserida

FIGURA 4.3 – Fluxograma de uma regra sendo inserida no Firewall Root.

• Caso haja algum conflito, um erro é retornado para o operador;

• Caso não haja nenhum conflito:

– armazena a nova regra em banco;

– envia a regra para a interface externa do Firewal Local;
– Firewall Local verifica que a regra veio do Firewall Root;
– Firewall Local envia a regra para o Controlador Local e retorna uma mensagem
de sucesso para o Firewall Root;
– a mensagem de sucesso é retornada para o operador.

Quando uma nova regra Root é inserida significa que houve uma alteração na polı́tica
de segurança corporativa, e por isso as regras Locais existentes precisam ser verificadas
novamente. Caso seja detectado algum conflito, significa que alguma regra Local precisa
ser revista, pois a partir de agora, ela contradiz a nova polı́tica de segurança. Essa
regra Local conflitante não é sobreposta incondicionalmente porque essa ação poderia
CAPÍTULO 4. FIREWALL PARA SDN COM VERIFICAÇÃO DE CONFLITO DE
REGRAS HIERÁRQUICAS 55
indisponibilizar algum serviço importante que esteja hospedado em alguma localidade, ou
até mesmo parar a rede desta localidade.

4.2 Implementação

O controlador utilizado nesta dissertação foi o Ryu. Ele já disponibiliza uma aplicação
de firewall, que foi utilizada como base. O controlador Ryu é feito na linguagem Python,
e por isso as aplicações desenvolvidas também foram feitas nessa linguagem. Para o
Firewall Root, foi necessário utilizar duas bibliotecas que não são utilizadas pelo firewall
nativo do Ryu: pymongo para manipulação do banco de dados; IPNetwork para manipular
endereços IP. Para facilitar a codificação foi utilizada a IDE Eclipse1 com o plugin PyDev2 .
O ambiente utilizado para os testes será detalhado no capı́tulo 5
O Firewall Local recebe as regras de firewall através da interface externa, e a envia
para o controlador na forma de regras de fluxo, que por sua vez, a envia para os switches.
O controlador Ryu tem uma função WSGI que disponibiliza uma interface RESTful, e é
por ela que o firewall nativo do Ryu recebe as regras de firewall. Foi feita uma alteração
para que, antes de enviar a regra de firewall para o controlador, o Firewall Local verifique
se a regra não está vindo do Firewall Root, e então a envie para ele, onde será feita a
verificação de conflitos. Se não houver nenhum conflito, o processo continua, e a regra de
fluxo é enviada para o controlador. Essa alteração exigiu a adição de poucas linhas ao
firewall do Ryu, e o pseudo-código pode ser visto na figura 4.4.

if ( N~
a o veio do Firewall Root )
envia para o Firewall Root
if ( Há conflito )
retorna erro para o operador
Continua o processo

FIGURA 4.4 – Linhas adicionadas ao firewall do Ryu para usá-lo como Firewall Local

O Firewall Root também utiliza a interface REST para receber as regras de firewall.
Existe uma interface para regras inseridas pelo operador, e uma para regras vindas do
Firewall Local. As URIs e os métodos disponibilizados podem ser vistos na tabela 4.2.
Por exemplo, para adicionar uma regra ao firewall Root que permita pacotes TCP vindos
do host [Link] para o host [Link] na porta 80, basta executar o comando da figura 4.5.
O Firewall Root também é responsável por armazenar as regras em banco de dados.
O banco de dados utilizado atualmente é o MongoDB. Segundo (MONGODB, INC,
1
[Link]
2
[Link]
CAPÍTULO 4. FIREWALL PARA SDN COM VERIFICAÇÃO DE CONFLITO DE
REGRAS HIERÁRQUICAS 56
Método URI Descrição
POST /rootFw/rules/ Adiciona uma regra ao firewall Root.
POST /rootFw/verify Recebe a regra do Firewall Local para fa-
zer a veficação de conflitos
GET /rootFw/list Lista todas as regras Root definidas
PUT /rootFw/purgeDb Apaga o banco de dados de regras, tanto
as Root como as não Root. Isso não apaga
as regras que estão instaladas no Firewall
Local e nos switches.
TABELA 4.2 – Relação de métodos e URIs disponı́veis para o firewall Root.

curl -X POST -d ' { " nw_src " : " [Link]/32 " , " nw_dst " :
" [Link]/32 " , " nw_proto " : " TCP " , " tp_dst " : " 80 " ,
" dl_type " : " IPv4 " , " actions " : " ALLOW " } '
http :// localhost :8080/ rootFw / rules /0000000000000001

FIGURA 4.5 – Exemplo de comando para adicionar regra ao firewall Root.

2017), o MongoDB “armazena dados usando um flexı́vel modelo de dados de documentos

que é similar ao JSON”. Documento é uma estrutura de dados composta por um par
{campo: valor}, sendo que o valor pode ser outro documento, um array, e arrays de
documentos. Dentro de um mesmo gerenciador de banco de dados MongoDB, é possı́vel
criar vários bancos de dados, que por sua vez pode conter várias coleções (collections),
que são similares às tabelas em um banco de dados relacional.
Para separar as regras Root de não Root, foram criadas duas coleções no MongoDB.
Quando uma regra não Root estiver sendo inserida, somente as regras Root são lidas, e
vice-versa. Ou seja, quando o firewall Root precisa fazer a verificação de conflitos, ele
lê somente parte das regras, e não todas. Para o modelo atual, somente cinco métodos
referentes a acesso a banco de dados foram implementados, e caso seja necessário utilizar
outro banco de dados no lugar do MongoDB, basta alterar esses cinco métodos, adaptando-
os ao novo banco de dados. Os cinco métodos são:

• setRootFw: Insere uma regra Root na coleção “root” do banco de dados;

• getRootFw(filtro): Lê todas as regras que estão na coleção “root” do banco de dados
que coincidam com o filtro;

• setLocalFw: Insere uma regra não Root na coleção “local” do banco de dados;

• getLocalFw(filtro): Lê todas as regras que estão na coleção “local” do banco de

dados que coincidam com o filtro;

• purgeDb: Apaga todas as regras e exclui todas as coleções.

CAPÍTULO 4. FIREWALL PARA SDN COM VERIFICAÇÃO DE CONFLITO DE
REGRAS HIERÁRQUICAS 57
Nos métodos getRootFw e getLocalFw, o filtro passado é uma expressão do tipo
{“campo”: “valor”}. Por exemplo, para retornar somente as regras que sejam referen-
tes ao protocolo TCP e porta de destino 80, o filtro passado seria {“nw proto”: “TCP”,
“tp dst”: “80”}. Nas duas coleções (root e local) todos os campos foram indexados para
acelerar as buscas. O MongoDB utiliza estrutura B-tree para os ı́ndices.
Quando o Firewall Root recebe a nova regra, caso campos da dela tenham sido omiti-
dos, eles são preenchidos com valores padrão conforme descrito em (RYU PROJECT TEAM,
2014). Nesse documento não há nenhuma menção caso endereços IPs não tenham sido
informados. Quando um endereço não é informado, assume-se que significa todos os en-
dereços possı́veis, por exemplo, se o endereço de origem (dl src) não estiver presente,
significa que pode ser de qualquer origem, tanto intranet como Internet. Nesses casos
em que os endereços foram omitidos, eles foram preenchidos com “[Link]/0” para IPv4, e
“::/0” para IPv6.
Quando o operador insere uma nova regra no Firewall Root, a função set rule(novaRegra)
é chamada, e o pseudo-código dela pode ser visto na figura 4.6. A nova regra é enviada
para os Firewall Locais através de um POST HTTP, ou seja, da mesma forma como um
operador insere regras locais. Como o Firewall Local envia novas regras para o Firewall
Root, o processo não teria fim, pois o Firewall Local não tem como diferenciar a origem da
regra. Para evitar isso, antes de enviar a nova regra Root para o Firewall Local, o Firewall
Root altera o cabeçalho HTTP do POST que será feito. Isso permite que o Firewall Local
identifique que essa regra não precisa ser enviada novamente para o Firewall Root para
fazer a verificação de conflitos.
Quando o Firewall Local envia uma nova regra para o Firewall Root, a função chamada
é a verify rule(novaRegra), e o pseudo-código dela pode ser visto na figura 4.7. Nessa
função, caso não haja conflito de regras, uma mensagem de sucesso é retornada somente
para o Firewall Local que enviou a nova regra para ser analisada. Não é feita uma
requisição HTTP pois a nova regra já está no Firewall Local, e ele só precisa continuar
normalmente o processo de envio da regra para o Controlador Local.
As mensagem trocadas entre os firewalls, e entre operadores e firewalls segue o mesmo
padrão utilizado pelo firewall nativo do Ryu. Quando não há conflitos, a mensagem
é ({“command result”: “OK”, “details”: “Firewall rule added”}). Quando há
conflitos, as regras conflitantes também são adicionadas a essa mensagem, ficando en-
tão, com o formato ({“command result”: [{“result”: “fail”, “details”: “Firewall
rule conflict detected”, “newRule”: “<Nova regra>”, “existingRule”: “<Regra
existente>”}]}).
CAPÍTULO 4. FIREWALL PARA SDN COM VERIFICAÇÃO DE CONFLITO DE
REGRAS HIERÁRQUICAS 58
funç~
a o set_rule ( nova_regra )
preenche campos omitidos
busca regras conflitantes na coleç~ a o " local " do
banco de dados
if ( nenhum regra retornou na busca acima )
continua
else
var lista [] = vazio
for ( cada regra retornada do banco )
if ( tem conflito de IP )
lista . append ( regra
conflitante )
if ( lista [] n~ a o está vazia )
retorna erro para operador
grava regra na coleç~ a o " root " do banco de dados
altera cabeç~ a o da requisiç~ a o HTTP
envia nova regra para os Controladores Locais com um
POST HTTP

FIGURA 4.6 – Pseudo-código da função set rule() do Firewall Root

4.3 Metodologia da Verificação de Conflito de Regras

O método para verificar se há conflito de regras foi inspirado no trabalho de (NATA-
RAJAN et al., 2012), que descreve uma técnica de verificação de conflito hı́brida hash-trie,
que divide cada entrada de fluxo em conjuntos de cabeçalhos para detectar o conflito em
cada campo individualmente, e depois utiliza uma matriz de intersecção para determinar
quais entradas de fluxo conflitam com a nova entrada de fluxo. Para maiores detalhes
da estratégia mencionada, volte ao capı́tulo 3, subseção 3.2 que, ao explanar o referido
trabalho, contém uma explicação das técnicas hash-trie e radix-trie.
No artigo, os autores utilizam uma estrutura radix trie para verificar conflitos nos
endereços IPs de origem e destino (chamados de campos baseados em prefixo), e uma es-
trutura hash-trie para verificar conflitos nos outros campos do fluxo (chamados de campos
de valores exatos).
Nessa dissertação, as regras de firewall são armazenadas em banco de dados, que
permite a criação de ı́ndices do tipo B-tree. Essa facilidade foi utilizada para a verificação
de conflitos nos campos de valores exatos. Então, ao invés de buscar no banco todas
as regras inseridas anteriormente, é feita uma busca utilizando-se filtros, que retornam
somente as regras que conflitem com a nova regra inserida, levando-se em consideração
somente esses campos de valores fixos.
Por exemplo, para criar uma regra que permita o tráfego do tipo TCP com destino a
CAPÍTULO 4. FIREWALL PARA SDN COM VERIFICAÇÃO DE CONFLITO DE
REGRAS HIERÁRQUICAS 59
funç~
a o verify_rule ( nova_regra )
preenche campos omitidos
busca regras conflitantes na coleç~ a o " root " do banco
de dados
if ( nenhuma regra retornou da busca acima )
continua
else
var lista [] = vazio
for ( cada regra retornada do banco )
if ( tem conflito de IP )
lista []. append ( regra
conflitante )
if ( lista [] nao está vazia )
retorna erro para o Firewall Local
grava nova regra na coleç~ a o " local " do banco de dados
retorna mensagem de sucesso para o Firewall Local

FIGURA 4.7 – Pseudo-código da função verify rule() do Firewall Root

porta 80, com origem no host [Link]/32 e com destino ao host [Link]/32, a regra a ser
inserida é a seguinte: {“nw src”: “[Link]/32”, “nw dst”: “[Link]/32”, “dl type”: “IPv4”,
“nw proto”: “TCP”, “tp dst”: “80”, “actions”: “ALLOW”}. Desconsiderando os campos
baseados em prefixo (nw dst e nw src), qualquer regra que negue tráfego TCP com destino
a porta 80, com endereço do tipo IPv4, estará em conflito com essa nova regra. Então,
todo o processo de construir uma estrutura hash-trie utilizada por (NATARAJAN et al.,
2012) foi substituı́da por uma busca no banco de dados que já utiliza uma chave hash
dos campos relevantes. Para o caso acima, o filtro para a busca seria {“dl type”: “IPv4”,
“nw proto”: “TCP”, “tp dst”: “80”, “actions”: “DENY”}.
A verificação de conflito não pode ser feita usando uma pesquisa de hash nos campos
de endereço de IP de origem e destino porque as regras podem fazer referência a uma sub-
rede inteira. Então por exemplo, se uma regra tem como endereço de origem [Link]/32,
ela conflita com uma outra regra cujo endereço de origem seja [Link]/8, pois o primeiro
faz parte da sub-rede do segundo. Dado o conjunto de regras retornado pela busca feita
no banco, a nova regra compara os endereços de origem e destino um a um, utilizando-se
funções que comparam dois endereços IPs para ver se são iguais, ou se um pertence ao
outro (caso um deles ou os dois sejam uma sub-rede). Esta estratégia de implementação
de conferência de faixas de IP é similar a implementação do artigo que emprega radix-trie
e bastante difundida na área, embora o desempenho esperado do radix-trie seja superior.
Um exemplo de IPs que conflitam podem ser vistos na tabela 4.3.
No pior caso, a busca efetuada no banco irá retornar todas as regras da coleção (root
ou não root). Com isso, a verificação de conflito nos campos de endereço IP será feita em
CAPÍTULO 4. FIREWALL PARA SDN COM VERIFICAÇÃO DE CONFLITO DE
REGRAS HIERÁRQUICAS 60
IP da nova regra IP de regra existente Conflito de IP?
[Link]/32 [Link]/32 conflito
[Link]/8 [Link]/32 conflito
[Link]/32 [Link]/8 conflito
[Link]/8 [Link]/16 conflito
[Link]/16 [Link]/8 conflito
* [Link]/32 ou [Link]/8 conflito
[Link]/32 ou [Link]/8 * conflito
TABELA 4.3 – Exemplo de conflitos de endereços IP

todas as regras. Ou seja, o tempo para detectar o conflito, no pior caso, será O(n), onde
n é o número de regras presentes na coleção.
5 Verificação de Resultados

Este capı́tulo aborda os testes realizados para verificar o funcionamento do Firewall

Root. A próxima subseção apresenta a arquitetura montada para a realização dos testes.
A subseção 5.2 apresenta os testes utilizando algumas regras de firewall para verificar
o correto funcionamento da verificação de conflito. A subseção 5.3 apresenta os testes
realizados para medir o tempo que o sistema desenvolvido gasta para fazer a verificação
de conflitos.

5.1 Ambiente de Testes

Para a realização dos testes foi criada uma rede virtual utilizando o Mininet. O
Mininet “é capaz de criar uma rede virtual realista, executando kernel, switch e códigos
de aplicações reais em uma única máquina, em segundos, com um simples comando”
(MININET TEAM, 2017). O Mininet foi instalado diretamente no sistema operacional do
computador utilizado para o teste. A figura 5.1 ilustra os componentes da estrutura
montada para os testes, onde vê-se o encadeamento em camadas de hardware e software.

VM VM VM
Mininet
VirtualBox

SO Hospedeiro - Ubuntu

Hardware

FIGURA 5.1 – Encadeamento de Componentes

O ambiente de teste é composto por três controladores, sendo um Controlador Root,

que executa a aplicação Firewall Root. Os outros dois controladores estão um nı́vel abaixo
e executam o Firewall Local. Cada um desses controladores é responsável por um switch
OpenFlow virtual sendo que não há comunicação entre os dois controladores e nem entre
CAPÍTULO 5. VERIFICAÇÃO DE RESULTADOS 62

os dois switches, ou seja, cada controlador controla uma rede independente, e como dito
anteriormente, o objetivo do Controlador Root não é orquestrar uma rede logicamente
centralizada, e sim definir regras que serão repassadas para todos os switches de nı́vel
inferior e que não poderão ser sobrepostas.
Em cada switch estão ligados quatro hosts, totalizando oito hosts. O script utili-
zado para a criação da arquitetura utilizada para os testes no mininet está disponı́vel no
Apêndice A.1.
Para a execução dos três controladores foram criadas máquinas virtuais separadas
(representadas na figura 5.1). Neste ambiente se pode testar a comunicação entre os con-
troladores como se estivessem executando em máquinas diferentes, tornando o ambiente
de teste mais realista. Tanto as portas onde os controladores escutam como as portas
da interface REST foram unicamente definidas. Essas ações foram tomadas para evitar
qualquer dúvida sobre para qual controlador os switches estavam apontando, e para qual
controlador as regras de firewall estavam sendo enviadas.
Hospedeiro [Link]
porta controlador: 6636
porta Rest: 8080

VM MongoDB
[Link] [Link]
porta controlador: 6637 porta controlador:6638
porta Rest: 8081 porta Rest: 8082

VM VM
Firewall
Firewall Root Firewall
Local Local
Controlador
Controlador Root Controlador
Local Local

Mininet

[Link]/8 [Link]/8 [Link]/8 [Link]/8 [Link]/8 [Link]/8 [Link]/8 [Link]/8

Servidor Adm Local Servidor Adm Local
(HTTP e SSH) (HTTP e SSH)

FIGURA 5.2 – Ambiente criado para os testes

Em cada um dos hosts foi iniciado um serviço HTTP usando o python para que os
testes pudessem ser feitos utilizando protocolo TCP, que é um protocolo de camada de
transporte do modelo TCP/IP que estabelece uma sessão entre os dois hosts envolvidos
na comunicação. O comando para subir um servidor HTTP nos hosts foi “python -m
CAPÍTULO 5. VERIFICAÇÃO DE RESULTADOS 63

SimpleHTTPServer 80’ ’. A partir deste ponto qualquer dos hosts poderia ser utilizado
para criação de fluxos de dados entre eles. A conexão ao serviço HTTP foi feita usando
o comando wget do Linux. Também foi utilizado o serviço SSH, que permite testes de
sessão remota com login e execução de comandos. Este foi um outro serviço adicionado
para enriquecer os testes das regras de firewall uma vez que o serviço SSH, diferente da
transferência via HTTP, mantem a sessão aberta indefinidamente.

5.2 Teste de Funcionamento

Para realizar o teste de funcionamento utilizou-se o ambiente conforme a figura 5.2.

Nela é possı́vel ver o Controlador Root em um nı́vel superior ([Link]), e dois
Controladores Locais ([Link] e [Link]). Para cada controlador local foi
criada uma rede hipotética composta por quatro hosts, sendo que um deles assumiu o
papel de servidor, um deles representa a estação de trabalho do administrador local, e os
outros dois são clientes dos serviços. A polı́tica de segurança definida pela administração
central especifica que o servidor pode ser acessado através do protocolo HTTP por todos
os hosts da rede, e somente a estação de trabalho do adminitrador local pode acessá-lo
através do protocolo SSH. As regras para isso estão representadas na tabela 5.1 e foram
inseridas no Firewall Root.
Também foram criadas regras não Root para o teste, sendo que uma conflita com
alguma regra Root, e outra não conflita. Elas podem ser vistas na tabela 5.2.
Ao tentar inserir as regras descritas na tabela 5.2, o comportamento foi conforme
o esperado. A primeira regra não foi inserida no controlador [Link] pois ela
contradiz a polı́tica que diz que somente a estação de trabalho do administrador da rede
pode acessar o servidor através do protocolo SSH. A segunda regra inserida no controlador
[Link] foi inserida com sucesso, pois ainda que um servidor web não tenha sido
configurado nesta máquina, do ponto de vista do firewall só há preocupação com o conflito
das regras e não com a coerência da configuração dos serviços da corporação. As regras
inseridas no controlador [Link] seguem essa mesma lógica.
Depois que as regras foram inseridas nos controladores locais foram efetuados testes
de acesso para verificar se elas funcionaram como o esperado. Em todos os hosts foram
iniciados os serviços Web e SSH. Conforme o esperado, somente os hosts que assumiram o
papel de estação de trabalho do administrador da rede puderam acessar o servidor através
do protocolo SSH, e todos puderam acessá-lo através do protocolo HTTP.
Com esses testes iniciais foi possı́vel comprovar que a verificação de conflito funciona
com regras simples e também que o firewall está se comportando conforme as regras
inseridas nele. Para comprovar o funcionamento do sistema com regras mais complexas,
CAPÍTULO 5. VERIFICAÇÃO DE RESULTADOS 64

# Descrição Regra
Estação do administrador de {“nw src”: “[Link]/32”, “nw dst”: “[Link]/32”, “dl type”:
1
rede local ([Link]) pode “IPv4”, “nw proto”: “TCP”, “tp dst”: “22”, “actions”:
acessar o servidor ([Link]) “ALLOW”}
usando a porta 22 (SSH) {“nw src”: “[Link]/32”, “nw dst”: “[Link]/32”, “dl type”:
“IPv4”, “nw proto”: “TCP”, “tp src”: “22”, “actions”:
“ALLOW”}
Todas os hosts da rede {“nw src”: “[Link]/8”, “nw dst”: “[Link]/32”, “dl type”:
2
([Link]/8) podem acessar o “IPv4”, “nw proto”: “TCP”, “tp dst”: “80”, “actions”:
servidor ([Link]) através da ”ALLOW”}
porta 80 (HTTP) {“nw src”: “[Link]/32”, “nw dst”: “[Link]/8”, “dl type”:
“IPv4”, “nw proto”: “TCP”, “tp src”: “80”, “actions”:
“ALLOW”}
Os outros hosts da rede não {“nw src”: “[Link]/8”, “nw dst”: “[Link]/32”, “dl type”:
3
podem acessar o servidor “IPv4”, “nw proto”: “TCP”, “tp dst”: “22”, “actions”:
([Link]) através da porta 22 “DENY”}
(SSH) {“nw src”: “[Link]/32”, “nw dst”: “[Link]/8”, “dl type”:
“IPv4”, “nw proto”: “TCP”, “tp src”: “22”, “actions”:
“DENY”}
Estação do administrador de {“nw src”: “[Link]/32”, “nw dst”: “[Link]/32”, “dl type”:
4
rede local ([Link]) pode “IPv4”, “nw proto”: “TCP”, “tp dst”: “22”, “actions”:
acessar o servidor Web “ALLOW”}
([Link]) usando a porta 22 {“nw src”: “[Link]/32”, “nw dst”: “[Link]/32”, “dl type”:
(SSH) “IPv4”, “nw proto”: “TCP”, “tp src”: “22”, “actions”:
“ALLOW”}
Todas os hosts da rede {“nw src”: “[Link]/8”, “nw dst”: “[Link]/32”, “dl type”:
5
([Link]/8) podem acessar o “IPv4”, “nw proto”: “TCP”, “tp dst”: “80”, “actions”:
servidor ([Link]) através da “ALLOW”}
porta 80 (HTTP) {“nw src”: “[Link]/32”, “nw dst”: “[Link]/8”, “dl type”:
“IPv4”, “nw proto”: “TCP”, “tp src”: “80”, “actions”:
“ALLOW”}
Os outros hosts da rede não {“nw src”: “[Link]/8”, “nw dst”: “[Link]/32”, “dl type”:
6
podem acessar o servidor “IPv4”, “nw proto”: “TCP”, “tp dst”: “22”, “actions”:
([Link]) através da porta 22 “DENY”}
(SSH) {“nw src”: “[Link]/32”, “nw dst”: “[Link]/8”, “dl type”:
“IPv4”, “nw proto”: “TCP”, “tp src”: “22”, “actions”:
“DENY”}

TABELA 5.1 – Regras iniciais inseridas no controlador Root

uma massa de dados mais abrangente foi testada. Algumas das regras utilizadas estão
descritas na tabela 5.3 e foram inseridas nessa ordem. Com essas regras mais abrangentes
o sistema de verificação de conflito também obteve o resultado esperado. Essas novas
regras são mais abrangentes pois fazem referência a:

• Protocolo UDP;

• Uma determinada rede;

• Um host especı́fico;

• Qualquer host;
CAPÍTULO 5. VERIFICAÇÃO DE RESULTADOS 65

# Descrição Inserida Controlador Regra

com
su-
cesso?
Permitir que o Não {“nw src”: “[Link]/32”, “nw dst”: “[Link]/32”,
7 [Link]
host [Link] (contra “dl type”: “IPv4”, “nw proto”: “TCP”, “tp dst”:
acesse o servidor #3) “22”, “actions”: “ALLOW”}
através da porta {“nw src”: “[Link]/32”, “nw dst”: “[Link]/32”,
22 (SSH) “dl type”: “IPv4”, “nw proto”: “TCP”, “tp src”:
“22”, “actions”: “ALLOW”}
Permitir que o {“nw src”: “[Link]/32”, “nw dst”:
8 Sim [Link]
host [Link] “[Link]/32”, “dl type”: “IPv4”, “nw proto”:
acesse um “TCP”, “tp dst”: “80”, “actions”: “ALLOW”}
serviço {“nw src”: “[Link]/32”, “nw dst”:
(80/HTTP) no “[Link]/32”, “dl type”: “IPv4”, “nw proto”:
host [Link] “TCP”, “tp src”: “80”, “actions: “ALLOW”}
Permitir que o Não {“nw src”: “[Link]/32”, “nw dst”:
9 [Link]
host [Link] (contra “[Link]/32”, “dl type”: “IPv4”, “nw proto”:
acesse o servidor #6) “TCP”, “tp dst”: “22”, “actions”: “ALLOW”}
através da porta {“nw src”: “[Link]/32”, “nw dst”:
22 (SSH) “[Link]/32”, “dl type”: “IPv4”, “nw proto”:
“TCP”, “tp src”: “22”, “actions”: “ALLOW”}
Permitir que o {“nw src”: “[Link]/32”, “nw dst”:
10 Sim [Link]
host [Link] “[Link]/32”, “dl type”: “IPv4”, “nw proto”:
acesse um “TCP”, “tp dst”: “80”, “actions”: “ALLOW”}
serviço {“nw src”: “[Link]/32”, “nw dst”:
(80/HTTP) no “[Link]/32”, “dl type”: “IPv4”, “nw proto”:
host [Link] “TCP”, “tp src”: “80”, “actions”: “ALLOW”}

TABELA 5.2 – Regras não Root inseridas nos Controladores Locais

# Descrição Inserida Controlador Regra

com
su-
cesso?
Permitir {“nw src”: “[Link]/8”, “nw dst”: “[Link]/32”,
11 Sim [Link]
acesso ao “tp dst”: “53”, “nw proto”: “UDP”, “dl type”: “IPv4”,
DNS da “actions”: “ALLOW”}
Intranet {“nw dst”: “[Link]/8”, “nw src”: “[Link]/32”,
“tp src”: “53”, “nw proto”: “UDP”, “dl type”: “IPv4”,
“actions”: “ALLOW”}
Negar acesso {“nw src”: “[Link]/8”, “nw dst”: “[Link]/0”,
12 Sim [Link]
da intranet a “tp dst”: “53”, “nw proto”: “UDP”, “dl type”: “IPv4”,
DNSs “actions”: “DENY”}
externos {“nw dst”: “[Link]/8”, “nw src”: “[Link]/0”,
“tp src”: “53”, “nw proto”: “UDP”, “dl type”: “IPv4”,
“actions”: “DENY”}
Tabela 5.3 – continua na próxima página
CAPÍTULO 5. VERIFICAÇÃO DE RESULTADOS 66

Tabela 5.3 – continuação da página anterior

# Descrição Inserida Controlador Regra
com
su-
cesso?
Negar acesso {“nw src”: “[Link]/8”, “nw dst”: “[Link]/8”,
13 Sim [Link]
SSH entre as “tp dst”: “22”, “nw proto”: “TCP”, “dl type”: “IPv4”,
estações “actions”: “DENY”}
{“nw dst”: “[Link]/8”, “nw src”: “[Link]/8”,
“tp src”: “22”, “nw proto”: “TCP”, “dl type”: “IPv4”,
“actions”: “DENY”}
Permitir que {“nw src”: “[Link]/32”, “nw dst”: “[Link]/32”,
14 Sim [Link]
uma estação “tp dst”: “5432”, “nw proto”: “TCP”, “dl type”:
acesse um “IPv4”, “actions”: “ALLOW”}
servidor de {“nw dst”: “[Link]/32”, “nw src”: “[Link]/32”,
banco de “tp src”: “5432”, “nw proto”: “TCP”, “dl type”:
dados “IPv4”, “actions”: “ALLOW”}
Negar {“nw src”: “[Link]/0”, “nw dst”: “[Link]/32”,
15 Sim [Link]
qualquer “tp dst”: “5432”, “nw proto”: “TCP”, “dl type”:
outro acesso “IPv4”, “actions”: “DENY”}
ao servidor {“nw dst”: “[Link]/0”, “nw src”: “[Link]/32”,
de banco de “tp src”: “5432”, “nw proto”: “TCP”, “dl type”:
dados “IPv4”, “actions”: “DENY”}
Permitir {“nw src”: “[Link]/32”, “nw dst”: “[Link]/32”,
16 Não [Link]
acesso de “tp dst”: “53”, “nw proto”: “UDP”, “dl type”: “IPv4”,
uma estação “actions”: “ALLOW”}
a um {“nw dst”: “[Link]/32”, “nw src”: “[Link]/32”,
servidor “tp src”: “53”, “nw proto”: “UDP”, “dl type”: “IPv4”,
DNS externo “actions”: “ALLOW”}
Permitir Não {“nw src”: “[Link]/8”, “nw dst”: “[Link]/32”,
17 [Link]
acesso das (contra “tp dst”: “53”, “nw proto”: “UDP”, “dl type”: “IPv4”,
estações a #12) “actions”: “ALLOW”}
um servidor {“nw dst”: “[Link]/8”, “nw src”: “[Link]/32”,
DNS externo “tp src”: “53”, “nw proto”: “UDP”, “dl type”: “IPv4”,
“actions”: “ALLOW”}
Permitir Não {“nw src”: “[Link]/32”, “nw dst”: “[Link]/8”,
18 [Link]
acesso SSH (contra “tp dst”: “22”, “nw proto”: “TCP”, “dl type”: “IPv4”,
de uma #13) “actions”: “ALLOW”}
estação a {“nw dst”: “[Link]/32”, “nw src”: “[Link]/8”,
todos os “tp src”: “22”, “nw proto”: “TCP”, “dl type”: “IPv4”,
hosts “actions”: “ALLOW”}

TABELA 5.3 – Regras adicionais para testes mais abrangentes. Nem todos os hosts estão
representados na figura 5.2
CAPÍTULO 5. VERIFICAÇÃO DE RESULTADOS 67

5.3 Teste de Desempenho

Para verificar o desempenho das aplicações de firewall desenvolvidas foram efetuados

alguns testes. A cada novo teste o ambiente foi reiniciado para que não houvesse nenhuma
influência do teste anterior. O objetivo destes testes é verificar qual o impacto causado por
cada componente do modelo de firewall proposto por esta dissertação. Se os resultados
obtidos fossem proibitivos, seria necessário alterar a arquitetura utilizada. Os testes foram
realizados seguindo os passos:

• Inserir regras no firewall padrão do Ryu: teste feito para coletar o tempo que a
inserção de regras leva no firewall do Ryu sem nenhuma alteração.

• Inserir somente regras Root no Firewall Root, sem verificação de conflito, mas sem
armazená-las em banco de dados: teste feito para coletar o tempo que a inserção
de regras leva sem armazenar em banco de dados. Com isso será possı́vel calcular o
impacto que o acesso a disco irá causar.

• Inserir somente regras Root no Firewall Root, sem verificação de conflito, porém
armazenando-as em banco de dados: sem ter nenhuma regra conflitante espera-se
que o tempo de inserção permaneça constante entre regras, uma vez que acontece
uma mera inserção sem processamento adicional.

• Inserir somente regras não Root, sem nenhuma regra Root: assim como no ı́tem
anterior, espera-se que o tempo permaneça constante.

• Inserir alternadamente regras Root e não Root: serão inseridas regras Root cujos
endereços IP de origem serão incrementados sequencialmente mas com o mesmo en-
dereço de destino (“nw dst”: “[Link]/32”, “nw src”: “10.0.x.y”, “dl type”: “IPv4”,
“nw proto”: “TCP”, “tp dst”: “80”, “actions”: “ALLOW”). Alternadamente, será in-
serida uma regra não Root que conflite com as regras Root (“nw dst”: “[Link]/32”,
“nw src”: “[Link]/8”, “dl type”: “IPv4”, “nw proto”: “TCP”,“tp dst”: “80”, “actions”:
“DENY”). Com isso, a cada iteração, a quantidade de regras conflitantes será incre-
mentada.

O gráfico com a comparação dos tempos pode ser visto na figura 5.3. Foram inseridas
mil regras em cada teste, e foi calculada a média do tempo de processamento medido a
cada dez regras. O tempo de processamento foi medido a partir da entrada da regra pelo
operador passando pela etapa de envio ao Root, verificação de conflito e concluindo com
a resposta de aceitação ou não da regra. Os testes foram gerados através de um laço que
a cada incremento de IP gerava uma nova regra.
CAPÍTULO 5. VERIFICAÇÃO DE RESULTADOS 68

Comparação de tempos de processamento das regras

0.02

0.018

0.016
Tempo médio em segundos

0.014

0.012

0.01

0.008

0.006

0.004

0.002
0 10 20 30 40 50 60 70 80 90 100
Quantidade de regras inseridas (x10)
Firewall padrão do Ryu
Inserção de regras Root sem verificação de conflito e sem armazenar em banco
Inserção de regras Root sem verificação de conflitos
Inserção de regras não Root sem regras Root
Inserção de regras alternadas

FIGURA 5.3 – Comparação dos tempos de processamento das regras de firewall. Testes
realizados em um computador Intel Core(TM) i5-2400 3.10GHz com 8GB de memória
RAM e disco SSD com sistema operacional Ubuntu Server 16.04.02 64 bits

É possı́vel verificar que o Firewall Root causa um aumento de tempo na inserção

de regras em relação ao firewall original do Ryu. Inserir regras no firewall do Ryu leva
aproximadamente 0,003 segundos, ao passo que, com o firewall Root, inserir regras não
Root sem conflitos leva aproximadamente 0,01 segundos (aumento de tempo de 3x). Essa
diferença deve-se não somente a verificação de conflitos, mas também ao acesso ao banco
de dados e a comunicação entre os controladores.
A comunicação entre os firewalls gera um aumento de tempo razoável, e é possı́vel
verificar isso no gráfico. Inserir uma regra Root leva mais tempo do que inserir uma regra
não Root (de 0,011 segundos para 0,016 segundos, ou seja, 45%). Isso é causado pelo
fato de, ao inserir uma regra Root, ela precisa ser encaminhada para todos os firewalls
subordinados, ao passo que inserir uma regra não Root, ela é encaminhada somente para
um firewall Root, e não é distribuı́da para todos os firewalls de nı́vel inferior. O acesso ao
banco também gera um pequeno impacto; quando as regras não são gravadas no banco de
dados o tempo foi próximo de 0,014 segundos, e quando as regras são gravadas o tempo
foi próximo de 0,016 segundos (aumento de tempo de 1,15x).
No gráfico também foi possı́vel verificar que, conforme aumenta a quantidade de regras
conflitantes, o tempo de inserção de novas regras aumenta proporcionalmente. No inı́cio
CAPÍTULO 5. VERIFICAÇÃO DE RESULTADOS 69

do teste, o tempo de inserção das regras ficou próximo de 0,009 segundos, e no fim do
teste o tempo ficou próximo de 0,016 segundos, o que representa um aumento de 1,77x
da primeira para a última inserção do teste. Lembrando que esse teste é o pior caso, onde
a regra inserida (não Root) irá conflitar com todas as regras Root existentes, ou seja, na
última medição, ela está sendo verificada contra mil regras.
Uma descrição das operações que são executadas pela verificação de conflitos em cada
um dos testes segue abaixo:

• Inserção de regras Root sem verificação de conflitos e sem armazenar em banco

(linha verde): verificação de conflitos; envio da regra para aos dois controladores;
resposta dos controladores.

• Inserção de regras Root sem verificação de conflitos (linha azul): Tem o pior tempo
pois contém o maior número de tarefas: verificação de conflitos; armazenamento em
banco; envio da regra aos dois controladores; resposta dos controladores.

• Inserção de regras não Root sem regras Root (linha laranja): envio da regra ao
controlador Root; verificação de conflito; armazenamento em banco; resposta do
Root ao controlador local que enviou a regra.

• Inserção de regras alternadas (linha amarela): corresponde ao tempo medido para

inserir a regra não Root que, a cada iteração, conflita com uma regra Root a mais.
Contém as tarefas: envio da regra local ao Root; verificação de conflito; armazena-
mento em banco; resposta do controlador Root ao controlador Local que enviou a
regra.

Na prática é necessário inserir uma grande quantidade de regras para que um adminis-
trador de rede perceba a diferença de tempo. Inserir mil regras no firewall nativo do Ryu
levará 4 segundos, e inserir mil regras com mil regras conflitantes irá leva 16 segundos, e
esse é o pior caso. Esse cenário onde muitas regras são inseridas por segundo é possı́vel,
por exemplo, caso haja uma integração do firewall com um IPS, e o ambiente esteja so-
frendo um ataque. O IPS irá detectar muitos acessos indevidos em um curto espaço de
tempo, e irá enviar muitas regras novas para o firewall. Nesse caso, o tempo de inserção
irá depender de quantas Regras Locais existem, pois como visto no gráfico, o tempo é
constante caso só haja um aumento de Regras Root sendo inseridas.
Outro ponto importante é que, depois que as regras estiverem inseridas, isso não irá
prejudicar o desempenho dos controladores, pois o firewall Root atua somente quando as
regras são inseridas.
CAPÍTULO 5. VERIFICAÇÃO DE RESULTADOS 70

5.4 Comparação com Trabalhos Relacionados

O FlowGuard (HU et al., 2014) não especifica a configuração do hardware onde os

testes foram efetuados, mas foi utilizado o backbone da rede de Stanford, com quatorze
roteadores de zona, dez switches, e dois roteadores de backbone. Esse ambiente tem 1206
regras de firewall e 8908 regras de fluxo de rede. Dependendo da violação que ocorrer, o
FlowGuard pode adotar uma entre cinco resoluções diferentes. A resolução de violação
mais rápida é a rejeição de fluxo que gasta 0,06ms, e a mais lenta é o bloqueio do pacote,
que gasta 9,01ms. O artigo descreve um teste realizado para verificar se o FlowGuard
influencia no desempenho da rede (depois de instaladas as regras), e em comparação com
o firewall do Floodlight, o tempo de inspeção de pacote aumentou muito pouco: 90% dos
pacotes o FlowGuard gastou menos de 79µs, enquanto o firewall do Floodlight gastou
menos de 40µs, o que representa um aumento de 2x.
Segundo (KHURSHID et al., 2012), o Veriflow foi testado em um servidor Intel(R)
Core(TM) i7-3770 com 32GB de memória RAM rodando Ubuntu Linux 11.10 64 bits.
Ao inserir uma nova regra, o Veriflow cria Classes de Equivalência com as regras já exis-
tentes para poder verificar se há conflitos. O número de classes de equivalências afetadas
pela nova regra influencia fortemente o tempo de verificação. Durante os testes feitos
pelos autores, o maior número de classes de equivalências afetadas por uma única regra
foi 574, fazendo com que a verificação gastasse 159,2ms. Mas durante esses testes eles
verificaram também que em 99,1% das atualizações menos de 10 classes de equivalências
foram afetadas. Na grande maioria dos casos o tempo ficou abaixo de 1ms.
Os tempos narrados nestes outros trabalhos indicam que os tempos encontrados nos
testes desta dissertação são compatı́veis, uma vez que nosso sistema contempla ainda o
tempo de rede para adequação do sistema de regras na hierarquia. Um resumo dos tempos
pode ser visto na tabela 5.4. Nela foram colocados os melhores e piores tempos medidos
durante os testes realizados por seus respectivos autores.

Tempo
FlowGuard 0,06ms ∼ 9,01ms
Veriflow 1ms ∼ 159,2ms
Este Trabalho 10ms ∼ 16ms
TABELA 5.4 – Comparação de tempos com Trabalhos Relacionados

Na subseção anterior, o teste de desempenho demonstrou que a solução apresentada

nesta dissertação causa um aumento de tempo de 3x em relação ao firewall original do
Ryu, ao passo que o FlowGuard causa um aumento de 2x em relação ao firewall original
do Floodlight. Essa diferença deve-se ao fato de a solução apresentada nesta dissertação
utilizar uma arquitetura distribuı́da, e para fazer a verificação de conflitos é necessário
CAPÍTULO 5. VERIFICAÇÃO DE RESULTADOS 71

haver algumas trocas de mensagens entre os controladores e esta medida considerou o

tempo de rede incluindo o handshake entre os firewalls Root e Locais. Outras soluções
não precisam dessa comunicação durante o processo de verificação de conflitos.
Um ponto importante é que a tarefa de inserção de regras de firewall não é crı́tica do
ponto de vista de desempenho, pois é ocasionalmente realizada. O tempo de tratamento
da regra no switch é crı́tico uma vez que as regras são confrontadas com cada pacote que
chega, todavia nosso sistema não interfere nesta tarefa.
6 Conclusão

Nesse trabalho foi abordado o problema de harmonia de regras de firewall em ambiente

de rede geograficamente distribuı́dos com organização hierárquica. Com o objetivo de
evitar que vulnerabilidades surjam nesse tipo de ambiente é importante que as regras de
firewall de todas as localidades estejam de acordo com as polı́ticas de segurança definidas
pela administração central. Para resolver este problema foi desenvolvida uma aplicação
de firewall executada sobre um controlador SDN englobando um sistema de verificação de
conflito de regras.
O sistema de firewall desenvolvido utiliza uma arquitetura hierárquica onde um firewall
Root é executado sobre um controlador Root SDN que fica um nı́vel acima dos controla-
dores locais. Essa aplicação também é responsável pelo armazenamento e distribuição das
regras definidas pela administração central. O controlador Root não é responsável pela
orquestração de como os controladores locais funcionam, conferindo assim, independência
do controle local. Foi desenvolvida uma outra aplicação de firewall local que trabalha em
sincronia o firewall Root.
Os testes realizados indicaram que a tarefa de inserção de uma nova regra no firewall
Root incluindo a verificação de potencial conflito leva, no pior caso, apenas 16ms. Esse
tempo mostrou-se próximo de outros trabalhos que também fazem verificação de conflitos.
A diferença de tempo em comparação com o firewall original do Ryu deve-se a utilização de
uma arquitetura distribuı́da, onde é necessário haver comunicação entre os controladores.
A verificação de conflito atua no momento em que a regra está sendo inserida no
firewall, e, portanto, não tem nenhuma outra ação necessária depois que a regra já estiver
efetivada no controlador. Por isso, o firewall desenvolvido não causa nenhum impacto
ao avaliar um novo fluxo de rede que esteja chegando ao switch. Apesar de existirem
ambientes de rede que tenham milhares de regras de firewall, o sistema de verificação de
conflito só traria algum prejuı́zo devido ao desempenho se fosse necessário inserir milhares
de regras de firewall por segundo.
A grande contribuição desta dissertação é que, com o novo sistema desenvolvido, as
organizações podem ter uma maior garantia de que suas polı́ticas de segurança estão sendo
seguidas por todas as localidades, e também que essas polı́ticas estão sendo atualizadas
CAPÍTULO 6. CONCLUSÃO 73

mais rapidamente em todas elas caso haja alguma alteração. Isso permite um controle com
grande flexibilidade nas filiais, pois os administradores locais podem continuar a definir
polı́ticas que dizem respeito somente àquela porção da rede da organização.
O uso de SDN foi muito conveniente para o desenvolvimento do sistema. É uma abor-
dagem moderna que por ser centralizada simplificou a integração das localidades. Além
disso, os controladores OpenFlow disponı́veis fornecem APIs para o desenvolvimento de
aplicações tornando também relativamente simples o desenvolvimentos do firewall. O sis-
tema de verificação de conflitos desenvolvido foi feito totalmente na camada de aplicação,
sem interferência ou alteração dos controladores SDN sobre os quais se apoiam. Essa
caracterı́stica permite que o sistema seja portável para outros controladores diferentes,
bastando para isso implementá-lo usando a API do controlador onde se deseja execu-
tar. Os testes em máquinas virtuais mostraram a viabilidade de tornar este firewall uma
Função Virtual de Rede (NFV - Network Functions Virtualization). A flexibilidade da
estrutura é altamente aderente com as tendências atuais das redes e suas configurações.

6.1 Limitação

Uma limitação do trabalho é o não tratamento de alterações no cabeçalho dos pacotes

dentro dos switches. Nas redes tradicionais isto é conhecido como NAT (Network Address
Translation) e o Openflow tem um mecanismo para alterar os cabeçalhos: o “Set-Field”. O
sistema de verificação de conflitos desenvolvido para essa dissertação não consegue tratar
esse tipo de situação, pois ele verifica se há conflitos entre as regras existentes, e não se
há conflitos entre os fluxos e as regras.

6.2 Sugestões para Trabalhos Futuros

A primeira sugestão para trabalhos futuros refere-se a firewall stateful, onde se conhe-
cem as conexões e se mantém regras conhecidas para os fluxos em andamento. Ao longo
da pesquisa para o desenvolvimento dessa dissertação verificou-se o inı́cio de estudos sobre
a implementação desse tipo de firewall em SDN. É necessário avaliar quais alterações são
necessárias no sistema hierárquico desenvolvido para que ele funcione corretamente com
firewall stateful.
Outra sugestão para a continuidade deste trabalho é a implementação de mais nı́veis de
hierarquia. Fazer essa alteração é um processo que não demanda muito esforço. Durante
a pesquisa os ambientes considerados não necessitaram de mais de um nı́vel pois, mesmo
que a organização tenha vários nı́veis, isso não necessariamente se reflete na administração
da rede e suas polı́ticas de segurança.
CAPÍTULO 6. CONCLUSÃO 74

Uma otimização sugerida em termos da implementação é um projeto multithreads para

o envio das regras aos Controladores Locais. Em ambientes com muitos sı́tios esse processo
pode gerar um certo impacto quando as regras estão sendo inseridas no Controlador
Root, pois atualmente ele as envia de maneira sequencial para os Controladores Locais.
Quando regras são inseridas nos controladores locais o controlador Root responde somente
para quem enviou a regra, e por isso essa operação não seria afetada por um projeto
multithreads na metodologia de comunicação.
Também na esfera de melhoria de implementação, sugere-se uma versão de navegação
nos endereços IP usando uma estrutura de árvore do tipo “trie” visto que o método usado
no momento não é o mais eficiente.
Feitas estas melhorias de implementação, pretende-se implantar este sistema em dife-
rentes organizações com diferentes perfis para avaliar na prática a aceitação pelas unidades
locais das polı́ticas centrais definidas.
Referências

ABNT. ABNT NBR ISO/IEC 27002:2005 Tecnologia da Informação - Técnica

de Segurança - Código de Prática para a Gestão da Segurança da
Informação. 2005.
ACHARYA, S.; MILLS, B. N.; ABLIZ, M.; ZNATI, T.; WANG, J.; GE, Z.;
GREENBERG, A. G. Optwall: A hierarchical traffic-aware firewall. In: NDSS. San
Diego, CA, USA: Network and Distributed System Security Symposium (NDSS), 2007.
BAADER, F.; CALVANESE, D.; MCGUINNESS, D. L.; NARDI, D.;
PATEL-SCHNEIDER, P. F. (Ed.). The Description Logic Handbook: Theory,
Implementation, and Applications. New York, NY, USA: Cambridge University
Press, 2003. ISBN 0-521-78176-0.
EBY, P. PEP 3333 – Python Web Server Gateway Interface v1.0.1. september
2010. Disponı́vel em: <[Link]
ETSI. Network Functions Virtualisation - Introdutory White Paper.
Darmstadt - Germany, October 2012. Disponı́vel em:
<[Link] White [Link]>.
FERGUSON, A. D.; GUHA, A.; LIANG, C.; FONSECA, R.; KRISHNAMURTHI, S.
Hierarchical policies for software defined networks. In: Proceedings of the First
Workshop on Hot Topics in Software Defined Networks. New York, NY, USA:
ACM, 2012. (HotSDN ’12), p. 37–42. ISBN 978-1-4503-1477-0. Disponı́vel em:
<[Link]
FERGUSON, A. D.; GUHA, A.; LIANG, C.; FONSECA, R.; KRISHNAMURTHI, S.
Participatory networking: An api for application control of sdns. SIGCOMM
Comput. Commun. Rev., ACM, New York, NY, USA, v. 43, n. 4, p. 327–338, ago.
2013. ISSN 0146-4833. Disponı́vel em: <[Link]
GAASERUD, A. Towards an unified policy for Next-Generation Firewalls.
Dissertação (Mestrado) — Universidade de Oslo, 2013. Disponı́vel em:
<[Link]
GAMAYUNOV, D.; PLATONOV, I.; SMELIANSKY, R. Toward network access control
with software-defined networking. SDNFW, 2013. Disponı́vel em:
<[Link]
/236148336 Toward Network Access Control With Software-Defined Networking>.
REFERÊNCIAS 76

GUDE, N.; KOPONEN, T.; PETTIT, J.; PFAFF, B.; CASADO, M.; MCKEOWN, N.;
SHENKER, S. Nox: Towards an operating system for networks. SIGCOMM
Comput. Commun. Rev., ACM, New York, NY, USA, v. 38, n. 3, p. 105–110, jul.
2008. ISSN 0146-4833. Disponı́vel em: <[Link]

HU, H.; HAN, W.; AHN, G.-J.; ZHAO, Z. Flowguard: Building robust firewalls for
software-defined networks. In: Proceedings of the Third Workshop on Hot
Topics in Software Defined Networking. New York, NY, USA: ACM, 2014.
(HotSDN ’14), p. 97–102. ISBN 978-1-4503-2989-7. Disponı́vel em:
<[Link]

IZARD, R. Firewall REST API. 2015. Disponı́vel em: <[Link]

.net/wiki/display/floodlightcontroller/Firewall+REST+API>.

KAPADIA, A.; CHASE, N. Understanding OPNFV. Mirantis, 2017. Disponı́vel em:

<[Link]

KHURSHID, A.; ZHOU, W.; CAESAR, M.; GODFREY, P. B. Veriflow: Verifying

network-wide invariants in real time. In: Proceedings of the First Workshop on
Hot Topics in Software Defined Networks. New York, NY, USA: ACM, 2012.
(HotSDN ’12), p. 49–54. ISBN 978-1-4503-1477-0. Disponı́vel em:
<[Link]

KOPONEN, T.; CASADO, M.; GUDE, N.; STRIBLING, J.; POUTIEVSKI, L.; ZHU,
M.; RAMANATHAN, R.; IWATA, Y.; INOUE, H.; HAMA, T.; SHENKER, S. Onix: A
distributed control platform for large-scale production networks. In: Proceedings of
the 9th USENIX Conference on Operating Systems Design and
Implementation. Berkeley, CA, USA: USENIX Association, 2010. (OSDI’10), p.
351–364. Disponı́vel em: <[Link]

MININET TEAM. Mininet: An Instant Virtual Network on your Laptop (or

other PC). 2017. Disponı́vel em: <[Link]

MONGODB, INC. Do What You Could Never Do Before. 2017. Disponı́vel em:
<[Link]

NATARAJAN, S.; HUANG, X.; WOLF, T. Efficient conflict detection in flow-based

virtualized networks. In: 2012 International Conference on Computing,
Networking and Communications (ICNC). Maui, HI, USA: IEEE, 2012. p.
690–696.

OPEN NETWORKING FOUNDATION. OpenFlow Switch Specification version

1.3.5. 2015. Disponı́vel em: <[Link]
/downloads/sdn-resources/onf-specifications/openflow/[Link]>.

OPEN NETWORKING FOUNDATION. OpenFlow.

[Link] 2016. Disponı́vel em:
<[Link]
REFERÊNCIAS 77

OPEN NETWORKING FOUNDATION. ONF Overview. 2017. Disponı́vel em:

<[Link]

OPEN NETWORKING FOUNDATION. Software-Defined Networking (SDN)

Definition. 2017. Disponı́vel em:
<[Link]

OPENDAYLIGHT FOUNDATION. The OpenDaylight Platform. 2017. Disponı́vel

em: <[Link]

PORRAS, P.; CHEUNG, S.; FONG, M.; SKINNER, K.; YEGNESWARAN, V. Securing
the software-defined network control layer. In: Proceedings of the 2015 Network
and Distributed System Security Symposium (NDSS). San Diego, CA, USA:
Network and Distributed System Security Symposium (NDSS), 2015.

PORRAS, P.; SHIN, S.; YEGNESWARAN, V.; FONG, M.; TYSON, M.; GU, G. A
security enforcement kernel for openflow networks. In: Proceedings of the First
Workshop on Hot Topics in Software Defined Networks. New York, NY, USA:
ACM, 2012. (HotSDN ’12), p. 121–126. ISBN 978-1-4503-1477-0. Disponı́vel em:
<[Link]

PROJECT FLOODLIGHT. Floodlight. 2017. Disponı́vel em:

<[Link]

RANUM, M. J. A network firewall. In: Proceedings of World Conference on

Systems Management and Security. USA: Digital Equipment Corporation (DEC),
1992.

RAO, S. SDN Series Part Three: NOX, the Original OpenFlow Controller.
December 2014. Disponı́vel em:
<[Link]

RYU PROJECT TEAM. Ryubook 1.0 documentation. 2014. Disponı́vel em:

<[Link] [Link]>.

RYU SDN FRAMEWORK COMMUNITY. Ryu SDN Framework. 2017. Disponı́vel

em: <[Link]

SEDGEWICK, R.; WAYNE, K. Algorithms. 4th. ed. Boston, MA, USA:

Addison-Wesley Professional, 2011. ISBN 032157351X, 9780321573513.

SHERWOOD, R.; GIBB, G.; YAP, K. kiong; CASADO, M.; MCKEOWN, N.;
PARULKAR, G. FlowVisor: A Network Virtualization Layer. Palo Alto, CA,
USA, 2009.

YOON, C.; PARK, T.; LEE, S.; KANG, H.; SHIN, S.; ZHANG, Z. Enabling security
functions with sdn: A feasibility study. Computer Networks, v. 85, p. 19–35, 2015.
Apêndice A - Códigos Utilizados

A.1 Script para criação da rede utilizada nos testes

1 # !/ usr / bin / python

3 """
4 Script created by VND - Visual Network Description ( SDN
version )
5 """
6 from mininet . net import Mininet
7 from mininet . node import Controller , RemoteController ,
OVSKernelSwitch , IVSSwitch , UserSwitch
8 from mininet . link import Link , TCLink
9 from mininet . cli import CLI
10 from mininet . log import setLogLevel
11

12 def topology () :
13

14 " Create a network . "

15 net = Mininet ( controller = RemoteController , link = TCLink ,
switch = OVSKernelSwitch )
16

17 print " *** Creating nodes "

18 c1 = net . addController ( ' c1 ' , ip = ' [Link] ' , port
=6636 )
19 c2 = net . addController ( ' c2 ' , ip = ' [Link] ' , port
=6637 )
20 c3 = net . addController ( ' c3 ' , ip = ' [Link] ' , port
=6638 )
21 s4 = net . addSwitch ( ' s4 ' , protocols = ' OpenFlow13 ' ,
listenPort =6673 , mac = ' 00:00:00:00:00:04 ' )
APÊNDICE A. CÓDIGOS UTILIZADOS 79

22 s5 = net . addSwitch ( ' s5 ' , protocols = ' OpenFlow13 ' ,

listenPort =6674 , mac = ' 00:00:00:00:00:05 ' )
23 s6 = net . addSwitch ( ' s6 ' , protocols = ' OpenFlow13 ' ,
listenPort =6675 , mac = ' 00:00:00:00:00:06 ' )
24 h7 = net . addHost ( ' h7 ' , mac = ' 00:00:00:00:00:07 ' , ip = '
[Link]/8 ' )
25 h8 = net . addHost ( ' h8 ' , mac = ' 00:00:00:00:00:08 ' , ip = '
[Link]/8 ' )
26 h9 = net . addHost ( ' h9 ' , mac = ' 00:00:00:00:00:09 ' , ip = '
[Link]/8 ' )
27 h10 = net . addHost ( ' h10 ' , mac = ' 00:00:00:00:00:10 ' , ip = '
[Link]/8 ' )
28 h11 = net . addHost ( ' h11 ' , mac = ' 00:00:00:00:00:11 ' , ip = '
[Link]/8 ' )
29 h12 = net . addHost ( ' h12 ' , mac = ' 00:00:00:00:00:12 ' , ip = '
[Link]/8 ' )
30 h13 = net . addHost ( ' h13 ' , mac = ' 00:00:00:00:00:13 ' , ip = '
[Link]/8 ' )
31 h14 = net . addHost ( ' h14 ' , mac = ' 00:00:00:00:00:14 ' , ip = '
[Link]/8 ' )
32

52 print " *** Running CLI "

53 CLI ( net )
54

55 print " *** Stopping network "

56 net . stop ()
57

58 if name == ' main ' :

59 setLogLevel ( ' info ' )
60 topology ()
FOLHA DE REGISTRO DO DOCUMENTO

1. 2. 3. 4.
CLASSIFICAÇÃO/TIPO DATA DOCUMENTO Nº Nº DE PÁGINAS
DM 31 de julho de 2017 DCTA/ITA/DM-061/2017 80
5.
TÍTULO E SUBTÍTULO:
Modelo de Firewall para Redes Definidas por Software com Verificação de Conflitos de Regras Hierárquicas
6.
AUTOR(ES):
Ruy Minoru Ito Takata
7.
INSTITUIÇÃO(ÕES)/ÓRGÃO(S) INTERNO(S)/DIVISÃO(ÕES):
Instituto Tecnológico de Aeronáutica – ITA
8.
PALAVRAS-CHAVE SUGERIDAS PELO AUTOR:
Redes de Computadores, SDN, firewall, segurança, firewall hierárquico
9.
PALAVRAS-CHAVE RESULTANTES DE INDEXAÇÃO:
Redes de Computadores; Redes Definidas por Software; Arquitetura de Software; Avaliação de Desempenho;
Computação.
10.
APRESENTAÇÃO: (X) Nacional ( ) Internacional
ITA, São José dos Campos. Curso de Mestrado. Programa de Pós-Graduação em Engenharia Eletrônica e
Computação. Área de Informática. Orientadora: Profa . Dra . Cecı́lia de Azevedo Castro César. Defesa em
06/07/2017. Publicada em 2017.
11.
RESUMO:
Organizações que estão distribuı́das em mais de um local fı́sico tem dificuldade em manter a coerência entre as
polı́ticas de segurança entre as localidades. Ao definir uma nova regra de segurança em um firewall em qualquer
das localidades é desejável que esta regra não entre em contradição com a polı́tica geral da organização, o que po-
deria causar uma vulnerabilidade no sistema como um todo. O processo de manter a coerência global permitindo
uma certa flexibilização na definição de polı́ticas locais não conflitantes é muito trabalhoso e frequentemente feito
de forma manual. Em grandes organizações, com muitas regras definidas, este desafio não tem sido atingindo
satisfatoriamente. O paradigma de Redes Definidas por Software (Software Defined Networking - SDN) facilita a
definição de arquiteturas hierárquicas que permitem o fortalecimento neste cenário de administração distribuı́da.
O presente trabalho desenvolveu uma aplicação de firewall hierárquica em ambiente SDN que faz a verificação
de coerência das regras das localidades a partir da definição de regras do nı́vel hierárquico superior. O sistema
desenvolvido mantém a coerência entre as regras de forma automática. A verificação é realizada no momento
da inserção da regra, não interferindo no desempenho normal do firewall. A avaliação de desempenho indicou
tempo reduzido na inserção.

12.
GRAU DE SIGILO:
(X) OSTENSIVO ( ) RESERVADO ( ) CONFIDENCIAL ( ) SECRETO