Avaliação , Através de Simulação e Teste Real, de um Firewall Baseado em SDN

Avaliac¸a˜ o, Atrav´es de Simulac¸a˜ o e Teste Real, de um Firewall Baseado em SDN Talles Quint˜ao Pessoa12 , Guilherme Melo de Oliveira Rodrigues 1 , Lucas Soares da Silva1 , F´atima Duarte-Figueiredo1 1

Pontif´ıcia Universidade Cat´olica de Minas Gerais (PUC-MG) Rua Walter Ianni, 255 – S˜ao Gabriel – 31980-110 – Belo Horizonte – MG – Brasil 2

Centro Federal de Educac¸a˜ o Tecnol´ogica de Minas Gerais (CEFET-MG) Rua Dezenove de Novembro - 121 - Centro - 35180-008 - Tim´oteo - MG - Brasil [email protected],[email protected] [email protected], [email protected]

Abstract. The next network generation brings new paradigms, including, ubiquitous and pervasive computing, Internet of things and the concept of Software Defined Networks (SDN). Even with the advances of the past generations of networks and protocols, some problems of traditional networks, such as, for example, security can be processed and implemented using SDN concepts. In this paper, we proposed an implementation of a firewall based on concepts of SDN using an Access Point with OpenFlow protocol and POX controller. Blocking unauthorized MAC (Media Access Control) address flows was the firewall main goal. Simulations were conducted by Mininet-Wifi and a use case was deployed for real tests. The results obtained in relation to the block flows and network latency, show that it is possible to define, effectively and efficiently, firewall functions through SDN. The main advantages of this approach are greater independence from hardware, separation of data plan and control plan and device configuration process optimization. Resumo. A pr´oxima gerac¸a˜ o de redes traz novos paradigmas, dentre eles, computac¸a˜ o ub´ıqua e pervasiva, Internet das coisas e o conceito de Redes Definidas por Software (SDN - Software Defined Network). Mesmo com os avanc¸os das u´ ltimas gerac¸o˜ es de redes e protocolos, alguns problemas das redes tradicionais, como, por exemplo, os de seguranc¸a, podem ser tratados e implementados utilizando conceitos de SDN. Neste trabalho, foi proposta uma implementac¸a˜ o de um firewall baseado em conceitos de SDN, utilizando um Access Point com protocolo OpenFlow e um controlador POX. O bloqueio de fluxos n˜ao autorizados foi feito a partir do enderec¸o MAC (Media Access Control) dos hosts. Simulac¸o˜ es foram conduzidas atrav´es do Mininet-Wifi e um caso de uso foi implementado para testes reais. Os resultados obtidos em relac¸a˜ o ao bloqueio de fluxos e latˆencia da rede, mostram que e´ poss´ıvel se definir, com efic´acia e eficiˆencia, func¸o˜ es de firewall atrav´es de SDN. As vantagens dessa abordagem s˜ao maior independˆencia em relac¸a˜ o ao hardware , separac¸a˜ o do plano de controle do plano de dados e otimizac¸a˜ o do processo de configurac¸a˜ o de dispositivos.

1. Introduc¸a˜ o As Redes Definidas por Software, tamb´em conhecidas como SDN (Software Defined Network), s˜ao uma nova tendˆencia em todo o mundo. Elas podem ser classificadas como frameworks capazes de separar o plano de dados do plano de controle, ou seja, o controle da rede e´ separado do sistema de encaminhamento de pacotes, permitindo a programac¸a˜ o do controle da rede. Dentre os principais benef´ıcios est˜ao a centralizac¸a˜ o da rede e a alocac¸a˜ o de recursos de forma dinˆamica, de acordo com a demanda. Em uma rede definida por software, os dispositivos n˜ao possuem autonomia nas decis˜oes, todos os pacotes passam pelo controlador SDN, que trac¸a o plano de controle. Ele e´ respons´avel pelo aprendizado das melhores rotas no tr´afego dos pacotes, otimizando a tomada de decis˜ao [Flauzac et al. 2015]. As redes definidas por software prop˜oem maior flexibilidade para a rede, separando a l´ogica de controle da rede dos roteadores e switches, centralizando as pol´ıticas das redes [Kreutz et al. 2015], sendo que, o controlador manipula as tabelas de fluxo atrav´es do protocolo OpenFlow, estabelecendo o padr˜ao de comunicac¸a˜ o entre o controlador e os dispositivos de rede em uma arquitetura SDN. Atrav´es do controlador, o administrador da rede elabora as regras que controlam o encaminhamento de pacotes nos switches, access point e roteadores[Xia et al. 2015]. O controlador responde dinamicamente a` s mudanc¸as e a` s necessidades das redes. Um switch OpenFlow, por exemplo, pode comportar-se como balanceador de carga, ou como firewall, dependendo das regras definidas no controlador. As SDNs oferecem versatilidade no controle das redes, atrav´es do OpenFlow. Esse protocolo permite a separac¸a˜ o do plano de controle e do plano de dados, onde um controlador centraliza as tarefas de gerenciamento da rede e tomadas de decis˜ao, agregando facilmente novas pol´ıticas de controle [Xie et al. 2015]. Mesmo com a popularizac¸a˜ o das SDN’s, existem alguns desafios encontrados em sua utilizac¸a˜ o e um dos principais e´ a seguranc¸a. Ameac¸as em redes tradicionais s˜ao similares a` s encontradas nas redes definidas por software, por´em o impacto e os riscos fornecidos por essas ameac¸as podem ser completamente diferentes. Muitos trabalhos apresentam a SDN como forma de aumentar a seguranc¸a da rede atrav´es de sistemas de monitoramento, com pol´ıticas de seguranc¸a para detectar dinamicamente tr´afegos suspeitos em tempo real. O objetivo deste trabalho e´ simular e implementar uma rede sem fio definida por software, cujo firewall e´ implementado no controlador POX, utilizando um access point (AP) h´ıbrido que utiliza o protocolo OpenFlow. O firewall e´ totalmente definido por software, tem regras de controle de acesso, atrav´es do enderec¸o MAC. Foi utilizado o simulador Mininet-Wifi [Fontes et al. 2015], capaz de prototipar redes sem fio definidas por software de maneira r´apida e eficiente, para definic¸a˜ o da arquitetura simulada e, tamb´em, para a implementac¸a˜ o do firewall. Um teste real foi conduzido, em um access point com suporte a openflow, com o objetivo de validar as simulac¸o˜ es atrav´es de um caso de uso da proposta. Este trabalho proporciona alguns exemplos pr´aticos da utilizac¸a˜ o das Redes Definidas por Software na protec¸a˜ o de uma rede, simplificando a arquitetura de seguranc¸a da rede com definic¸o˜ es de fluxos de acordo com as pol´ıticas de seguranc¸a. O trabalho foi dividido em 6 sec¸o˜ es. A sec¸a˜ o dois apresenta alguns conceitos para melhor entendimento do trabalho. A sec¸a˜ o trˆes apresenta os trabalhos relevantes na construc¸a˜ o da proposta

apresentada. A sec¸a˜ o quatro mostra um detalhamento do funcionamento do firewall proposto neste trabalho. A sec¸a˜ o cinco apresenta os cen´arios de simulac¸a˜ o, o caso de uso e tamb´em os resultados obtidos. A sec¸a˜ o seis apresenta as conclus˜oes do trabalho.

2. Referencial Te´orico 2.1. Redes Definidas por Software (SDN) As redes tradicionais normalmente possuem fluxos de dados e de controle concentrados em um mesmo dispositivo. Dessa forma, para que o administrador possa realizar o controle da rede, cada dispositivo deve ser configurado separadamente, limitando o uso de configurac¸o˜ es avanc¸adas que poderiam ser realizadas no plano de controle e de dados de forma independente. A principal proposta das Redes Definidas por Software e´ permitir que o controle do dispositivo que encaminha os pacotes da rede seja realizado pelo administrador [Jammal et al. 2014]. Assim, os dispositivos mant´em seu plano de dados original e o plano de controle e´ centralizado em um controlador, permitindo maior flexibilidade e controle mais eficiente da rede. A Figura 1 apresenta a arquitetura de uma SDN gen´erica com os planos de dados e de controle e uma interface para administrac¸a˜ o da rede.

Figura 1. Arquitetura SDN

O controlador SDN permite compatibilidade entre diferentes fabricantes de hardware, possibilitando que o controle da rede e a comunicac¸a˜ o com outras plataformas seja independente do sistema operacional do dispositivo de rede. A camada de controle atua como o n´ucleo da SDN, usando o OpenFlow, ela gerencia a camada de infraestrutura onde se encontra os ativos das redes, definindo como o controlador ir´a comunicar com os switches e roteadores, permitindo migrar e centralizar o plano de controle [Lara et al. 2014].

2.2. Protocolo OpenFlow O protocolo OpenFlow e´ aplicado para Redes Definidas por Software e e´ completamente open-source. Foi desenvolvido originalmente na Universidade de Stanford com o principal objetivo de permitir a experimentac¸a˜ o de novos protocolos de rede em dispositivos comerciais e ao mesmo tempo permitir o fluxo tradicional das redes. A tecnologia estabelece o padr˜ao de comunicac¸a˜ o entre o controlador e os dispositivos da rede em uma arquitetura SDN. Atrav´es da interface de programac¸a˜ o no controlador, o administrador da rede elabora as regras que controlam diretamente os elementos de encaminhamento de pacotes presentes nos switches e roteadores[Xia et al. 2015]. O controlador responde dinamicamente as mudanc¸as e as necessidades das redes. Por exemplo, um roteador OpenFlow pode comportar-se como um switch, um balanceador de carga ou um firewall, dependendo das regras definidas no controlador. Al´em disso, o protocolo trouxe uma uni˜ao entre o meio acadˆemico e a ind´ustria, permitindo que equipamentos de diversas marcas possuam o mesmo c´odigo de programac¸a˜ o e o desenvolvimento de novas tecnologias [Guedes et al. ]. A caracter´ıstica b´asica do protocolo, tamb´em compartilhada pelo conceito de SDN, e´ a divis˜ao do plano de dados e do plano de controle em elementos distintos. O plano de dados tem a responsabilidade de encaminhar os pacotes de acordo com regras estabelecidas em entradas da tabela de encaminhamento de pacotes do switch OpenFlow. o plano de controle possibilita a programac¸a˜ o da tabela de encaminhamento de pacotes atrav´es do controlador, de acordo com pol´ıticas ou fluxos de interesse, por exemplo. 2.3. Controlador POX Observando o plano de controle, podemos verificar a existˆencia de um controlador respons´avel por realizar a programac¸a˜ o da rede. Com diversas nomenclaturas, como sistema operacional da rede ou hypervisor da rede, o controlador e´ a centralizac¸a˜ o de toda a comunicac¸a˜ o dos dispositivos pertencentes a uma rede, fornecendo uma vis˜ao u´ nica da rede como um todo [Casado et al. 2010]. O controlador POX vem substituindo o controlador NOX, principalmente em projetos acadˆemicos. Por´em, e´ sempre necess´ario verificar se o desempenho do projeto e´ um requisito principal, pois o desempenho do controlador NOX e´ bastante superior ao do POX, mas o POX tem a vantagem de possuir uma interface moderna baseada em Python. 2.4. Simuladores O Mininet permite a prototipagem r´apida de SDN [Lantz et al. 2010], simulando a implementac¸a˜ o e a an´alise dos cen´arios. Amplamente utilizado no meio acadˆemico, o Mininet n˜ao suporta modelagem do canal sem fio. Visando propiciar a emulac¸a˜ o de redes sem fio, o Mininet-Wifi [Fontes et al. 2015] e´ uma extens˜ao do emulador Mininet, proporcionando a utilizac¸a˜ o de controladores OpenFlow em um ambiente controlado. Existem outros simuladores e testbeds que permitem simular redes sem fio definidas por software, por exemplo, o OpenNet [Chan et al. 2014] que integra o ns-3 ao Mininet, possibilitando a mobilidade sem fio em SDN.

3. Trabalhos Relacionados Atualmente, v´arias ferramentas de seguranc¸a s˜ao implementadas utilizando SDN, com intuito de proteger a rede de ataques externos. Em Lobato et al., a proposta com-

bina as Redes Definidas por Software com um Sistema de detecc¸a˜ o de intrusos (IDS)[Lobato et al. 2014]. Diante da arquitetura proposta, e´ realizado a prevenc¸a˜ o de intrus˜ao, bloqueando fluxos maliciosos atrav´es do controlador OpenFlow. As SDN’s podem ser utilizadas na detecc¸a˜ o de malware em dispositivos m´oveis [Jin and Wang 2013] e em Sistemas de Prevenc¸a˜ o de Intrus˜ao (IPS) para computac¸a˜ o em nuvem [Xing et al. 2013] e [Xing et al. 2014]. A seguranc¸a e a privacidade das SDN’s s˜ao aspectos fundamentais da arquitetura e s˜ao grandes preocupac¸o˜ es durante o projeto das mesmas. Existem abordagens que s˜ao respons´aveis por bloquear acessos n˜ao autorizados atrav´es das camadas um e quatro [Kaur et al. 2015] do protocolo TCP/IP. Existem outras abordagens que procuram mostrar a possibilidade de implementar as principais func¸o˜ es de um firewall em SDN [Suh et al. 2014] e [Collings and Liu 2014]. Alguns artigos, apresentam uma soluc¸a˜ o de distribuic¸a˜ o de firewall, que seleciona o envio das regras de configurac¸a˜ o de acordo com o tr´afego e a topologia da rede [Tran and Ahn 2015]. As Redes Definidas por Software fornecem um melhor gerenciamento e diagn´ostico de problemas nas redes [Kim and Feamster 2013], onde novas aplicac¸o˜ es de seguranc¸a, como IDS, IPS e firewalls, podem ser criadas a partir das necessidades da administrac¸a˜ o da rede, simplificando a arquitetura de seguranc¸a da rede. O principal trabalho relacionado [Javid et al. 2014], procura realizar o bloqueio de fluxos n˜ao autorizados atrav´es do enderec¸o MAC e utiliza um switch com algoritmo de aprendizado para encaminhamento de pacotes.

4. Firewall implementado com conceitos de SDN Um firewall, que pode ser implementado tanto em software quanto em hardware, tem como principal func¸a˜ o verificar as informac¸o˜ es trafegadas na rede e bloquear ou permitir que essas informac¸o˜ es atinjam um destino, de acordo com regras predefinidas. Para o desenvolvimento de um firewall podem ser consideradas duas abordagens diferentes: a instalac¸a˜ o pr´evia das regras na tabela de fluxos de equipamento ou o gerenciamento dinˆamico de pacotes durante os fluxos [Suh et al. 2014]. Neste trabalho foi utilizada a abordagem da instalac¸a˜ o pr´evia das regras, onde os fluxos s˜ao bloqueados pelo enderec¸o MAC dos hosts. Antes de iniciar o tr´afego, e´ consultada uma tabela e s˜ao verificados quais hosts devem ser bloqueados. Posteriormente, todas as regras encontradas no AP foram instaladas e durante o tr´afego consultadas para permitir ou bloquear determinados fluxos. O controlador utilizado para implementar as regras de firewall e´ o POX [Guedes et al. ], baseado no controlador NOX. As condic¸o˜ es ideais para utilizac¸a˜ o deste tipo de firewall implicam no conhecimento dos fluxos que s˜ao trafegados na rede, pois e´ necess´ario definir quais fluxos ser˜ao bloqueados previamente. O algoritmo utilizado durante as simulac¸o˜ es foi baseado no algoritmo apresentado no curso denominado ”Redes Definidas por Software”promovido pela Universidade de Princeton e dispon´ıvel no site Coursera [Feamster 2013]. O algoritmo proposto trabalha da seguinte forma: Para cada pacote do switch, e´ coletado o seu enderec¸o e porta de origem para atualizac¸a˜ o da tabela de encaminhamento de pacotes. Inicialmente s˜ao verificadas as regras de firewall com o objetivo de bloquear qualquer fluxo que n˜ao esteja previamente inclu´ıdo nas regras. Caso seu Ethertype seja do tipo LLDP, ele e´ descartado.

Se seu enderec¸o de destino for multicast, o pacote e´ encaminhado para todas as portas. Caso a porta de destino n˜ao esteja mapeada na tabela de encaminhamento, o pacote e´ enviado a todas as portas com o objetivo de identificar a porta correta e posteriormente o fluxo e´ atualizado na tabela de encaminhamento. Se a porta de origem e´ a mesma de destino, o pacote e´ descartado. O Algoritmo 1 mostra o pseudoc´odigo do firewall implementado. Algorithm 1 Firewall-Switch L2 1: procedure F IREWALL -L2-S WITCH(packet) 2: updateTable(sourceAddress, sourceP ort) 3: if checkRules(packet) then 4: dropPacket() 5: end if 6: if packet.Ethertype == LLDP then 7: dropPacket() 8: end if 9: if isMulticast(packet) then 10: floodPacket() 11: end if 12: if !checkTable(packet) then 13: floodPacket() 14: else 15: if packet.sourceP ort == packet.destinationP ort then 16: dropPacket() 17: end if 18: end if 19: installFlow(packet) 20: sendPacket(packet) 21: end procedure Diferentemente do trabalho de Javid et al (2014), este trabalho busca simular um ambiente real, que ser´a descrito na pr´oxima sec¸a˜ o, e aplicar o firewall para resoluc¸a˜ o do problema, que nesse caso e´ o acesso n˜ao autorizado a um Servidor Web.

5. Resultados 5.1. Cen´ario de simulac¸a˜ o Para realizar as simulac¸o˜ es foi utilizado o simulador Mininet-Wifi, cujo principal objetivo e´ prototipar redes definidas por software de uma maneira r´apida e simples [Fontes et al. 2015]. O cen´ario para testar a aplicac¸a˜ o do firewall foi definido com seis hosts diferentes, sendo um servidor Web e os outros como usu´arios comuns da rede, um controlador POX e um access point com protocolo OpenFlow. O cen´ario simulado e´ baseado em um ambiente corporativo onde apenas funcion´arios autorizados podem acessar o conte´udo de um servidor Web, como por exemplo um reposit´orio de arquivos. Al´em disso, os hosts est˜ao conectados por uma conex˜ao sem fio, o servidor e o controlador est˜ao conectados fisicamente via cabo na porta Ethernet do AP. Desta forma, e´ necess´ario bloquear qualquer tipo de acesso que n˜ao esteja previamente inclu´ıdo nas regras de firewall. A Figura 2 mostra um esquema de como est˜ao distribu´ıdos os elementos da rede.

˜ do Firewall no Cenario ´ Figura 2. Aplicac¸ao

A Tabela 1 apresenta a nominac¸a˜ o dos hosts durante as simulac¸o˜ es, al´em de fornecer o enderec¸o IP, o enderec¸o MAC e informar se os hosts est˜ao previamente inclu´ıdos nas regras de firewall. ˜ dos hosts Tabela 1. Regras do firewall com descric¸ao

Host

MAC

IP

Permitido

h1

00:00:00:00:00:01

10.0.0.1

X

h2

00:00:00:00:00:02

10.0.0.2

X

h3

00:00:00:00:00:03

10.0.0.3

X

h4

00:00:00:00:00:04

10.0.0.4

X

h5

00:00:00:00:00:05

10.0.0.5

X

h10

00:00:00:00:00:0a

10.0.0.10

5.2. Simulac¸o˜ es com Mininet-Wifi Para criar a topologia utilizada na simulac¸a˜ o, foi gerado um script em phyton, onde a associac¸a˜ o entre os hosts e o access point e´ instˆanciada pela classe addLink e atrav´es da classe addStation s˜ao adicionados os hosts, o access point pela classe addBaseStation e finalmente o controlador pela classe addController. Posteriormente o script do controlador foi executado pelo acesso remoto atrav´es do comando $./pox.py log.level –DEBUG l2 firewall. O primeiro passo foi definir um dos hosts como um servidor Web, neste caso o host h1. Para isto, e´ necess´ario abrir um terminal para o host h1 atrav´es do comando

mininet>xterm h1 e posteriormente $sudo python –m SimpleHTTPServer 80 habilitando o host a realizar conex˜oes HTTP e disponibilizando um c´odigo HTML simples. O host n˜ao autorizado a se conectar ao host h1 foi o h10. Dessa forma, foi aberto outro terminal para o h10 atrav´es do comando mininet>xterm h10 e posteriormente foi feita uma requisic¸a˜ o HTTP ao enderec¸o de h1 atrav´es do comando $curl 10.0.0.1. O host h10 n˜ao consegue se conectar ao host h1 devido ao fato de n˜ao estar listado nas regras do firewall. A Figura 3 mostra o terminal dos hosts ao tentarem realizar a requisic¸a˜ o HTTP e o log do controlador.

˜ HTTP entre h1 e h10 Figura 3. Requisic¸ao

Qualquer um dos outros hosts listados nas regras de firewall seria autorizado a se conectar ao servidor Web (h1). A Figura 4 mostra uma requisic¸a˜ o realizada pelo host h2 para h1, onde e´ retornado com sucesso um c´odigo HTML disponibilizado pelo servidor Web.

˜ HTTP entre h1 e h2 Figura 4. Requisic¸ao

Com o objetivo de analisar a eficiˆencia do algoritmo de aprendizado, foi analisada a latˆencia da rede em relac¸a˜ o a conex˜ao dos hosts ao servidor Web. Foram realizados 30 pings de cada host da rede ao host h1 (Servidor Web). Os resultados obtidos foram apresentados no Gr´afico 5, mostrando o valor m´ınimo e m´aximo de latˆencia da rede e tamb´em a m´edia aritm´etica de todos pings realizados de cada host.

Figura 5. Mininet: Testando a conectividade entre os hosts

Os resultados mostram que o valor m´aximo da latˆencia apresentado e´ de 19,11 ms. Esse valor se deve ao tempo gasto para realizar a primeira consulta ao controlador, como os demais acessos n˜ao necessitam consultar o controlador, o tempo m´edio cai para menos de 1 ms. Os valores de potˆencia do sinal entre o access point e os hosts permaneceram -30dBm. A Tabela 2 apresenta todos os valores num´ericos de cada host. ˆ Tabela 2. Latencia da Rede no Mininet-Wifi

h1(min-ms) h1(max-ms) h1(avg-ms) h2

0,038

19,11

0,729

h3

0,057

17,94

0,69

h4

0,066

11,1

0,474

h5

0,048

18,17

0,712

5.3. Caso de Uso Com o objetivo de reproduzir o comportamento real de uma rede dentro da soluc¸a˜ o apresentada, foi criado um ambiente de testes, conforme a Figura 2. Utilizando um access point TPLink1043nd v2.1, foi alterado o firmware do dispositivo atrav´es do OpenWRT [Huang et al. 2014], permitindo conex˜oes OpenFlow. Uma das portas Ethernet do Access Point foi conectada ao controlador POX e a outra ao servidor web. O restante dos hosts foram conectados atrav´es de uma conex˜ao sem fio. A Tabela 3 apresenta os hosts e seus respectivos enderec¸os MAC, que est˜ao previamente inclu´ıdos nas regras de firewall no controlador POX. Novamente, foram realizados 30 pings de cada host da rede ao host h1 (Servidor Web). Os resultados obtidos foram apresentados no Gr´afico 6, mostrando o valor m´ınimo e m´aximo de latˆencia da rede e tamb´em a potˆencia do sinal em cada host.

Tabela 3. Lista de macs cadastrados no firewall

Host

MAC

IP

h1

90:f6:52:3e:dd:06

10.0.0.1

h2

3c:07:54:07:b4:93 10.0.0.2

h3

3c:07:54:37:20:5a

10.0.0.3

h4

e4:58:e7:d0:a4:3e

10.0.0.4

h5

b8:8d:12:2d:c3:54 10.0.0.5

Figura 6. Testbed:A conectividade entre os hosts

Os resultados mostram que o valor m´aximo da latˆencia, que tem o seu maior valor igual a 53,59 ms, e´ sempre superior aos valores da m´edia, que est˜ao pr´oximos de 5 ms. Isso e´ justific´avel, pois a primeira vez em que o fluxo e´ recebido pelo access point, e´ necess´ario consultar o controlador para atualizac¸a˜ o da tabela de encaminhamento de pacotes. Os valores de potˆencia do sinal entre o access point e os hosts s˜ao diferentes. A Tabela 4 apresenta todos os valores num´ericos e a intensidade do sinal em cada host.

ˆ Tabela 4. Testbed: Latencia da Rede

h1(min-ms) h1(max-ms) h1(avg-ms) Potˆencia(dBm) h2

1,12

16,4

5,19

-25

h3

1,29

53,59

5,75

-45

h4

1,52

20,12

5,61

-32

h5

1,16

18,7

5,21

-29

6. Conclus˜ao As Redes Definidas por Software s˜ao uma tendˆencia e cada vez mais ser˜ao utilizadas para diversos prop´ositos. Este trabalho apresentou a aplicac¸a˜ o de um firewall em redes definidas por software atrav´es de simulac¸o˜ es realizadas com o simulador Mininet-Wifi. Foi poss´ıvel ilustrar, atrav´es de exemplos pr´aticos, a utilizac¸a˜ o das SDN’s no aspecto de seguranc¸a, simplificando a arquitetura de seguranc¸a da rede, com definic¸o˜ es de fluxo de acordo com as pol´ıticas de seguranc¸a. Os resultados demonstraram a eficiˆencia do firewall em relac¸a˜ o ao bloqueio de hosts n˜ao autorizados a se conectarem a rede em simulac¸o˜ es de um cen´ario corporativo. Nas simulac¸o˜ es com o Mininet-Wifi, foi comprovada a eficiˆencia do algoritmo de aprendizado utilizado no encaminhamento de pacotes, onde a latˆencia ficou com um valor abaixo de 1 ms. Acreditamos que no cen´ario real o aumento do valor m´edio da latˆencia para aproximadamente 5 ms, podem ter sido ocasionados pela variac¸a˜ o da potˆencia do sinal ou interferˆencia. Como trabalhos futuros, poder´a ser investigado de forma mais contundente o desempenho e a escalabilidade da soluc¸a˜ o em outras topologias de redes, al´em de propor mudanc¸as em alguns aspectos do firewall com intuito de adequ´a-lo a determinados cen´arios. Outra proposta tamb´em seria investigar a possibilidade de se utilizar um algoritmo de aprendizado no firewall para realizar o bloqueio de fluxos n˜ao autorizados em tempo real.

Referˆencias Casado, M., Koponen, T., Ramanathan, R., and Shenker, S. (2010). Virtualizing the network forwarding plane. In Proceedings of the Workshop on Programmable Routers for Extensible Services of Tomorrow, PRESTO ’10, pages 8:1–8:6, New York, NY, USA. ACM. Chan, M. C., Chen, C., Huang, J. X., Kuo, T., Yen, L. H., and Tseng, C. C. (2014). Opennet: A simulator for software-defined wireless local area network. In Wireless Communications and Networking Conference (WCNC), 2014 IEEE, pages 3332–3336. Collings, J. and Liu, J. (2014). An openflow-based prototype of sdn-oriented stateful hardware firewalls. In Network Protocols (ICNP), 2014 IEEE 22nd International Conference on, pages 525–528. Feamster, N. (2013). Redes definidas por software. https://www.coursera.org/course/sdn1.

Coursera.

Dispon´ıvel em:

Flauzac, O., Gonzalez, C., Hachani, A., and Nolot, F. (2015). Sdn based architecture for iot and improvement of the security. In Advanced Information Networking and Applications Workshops (WAINA), 2015 IEEE 29th International Conference on, pages 688–693. Fontes, R. R., Afzal, S., Brito, S. H. B., Santos, M. A. S., and Rothenberg, C. E. (2015). Mininet-wifi: Emulating software-defined wireless networks. In Network and Service Management (CNSM), 2015 11th International Conference on, pages 384–389. Guedes, D., Vieira, L., Vieira, M., Rodrigues, H., and Nunes, R. V. Redes definidas por software: uma abordagem sistˆemica para o desenvolvimento de pesquisas em redes de computadores.

Huang, K. L., Liu, C. L., Gan, C. H., Wang, M. L., and Huang, C. T. (2014). Sdn-based wireless bandwidth slicing. In Software Intelligence Technologies and Applications International Conference on Frontiers of Internet of Things 2014, International Conference on, pages 77–81. Jammal, M., Singh, T., Shami, A., Asal, R., and Li, Y. (2014). Software defined networking: State of the art and research challenges. Computer Networks, 72:74 – 98. Javid, T., Riaz, T., and Rasheed, A. (2014). A layer2 firewall for software defined network. In Information Assurance and Cyber Security (CIACS), 2014 Conference on, pages 39–42. Jin, R. and Wang, B. (2013). Malware detection for mobile devices using software-defined networking. In Research and Educational Experiment Workshop (GREE), 2013 Second GENI, pages 81–88. Kaur, K., Kumar, K., Singh, J., and Ghumman, N. (2015). Programmable firewall using software defined networking. In Computing for Sustainable Global Development (INDIACom), 2015 2nd International Conference on, pages 2125–2129. Kim, H. and Feamster, N. (2013). Improving network management with software defined networking. Communications Magazine, IEEE, 51(2):114–119. Kreutz, D., Ramos, F., Esteves Verissimo, P., Esteve Rothenberg, C., Azodolmolky, S., and Uhlig, S. (2015). Software-defined networking: A comprehensive survey. Proceedings of the IEEE, 103(1):14–76. Lantz, B., Heller, B., and McKeown, N. (2010). A network in a laptop: Rapid prototyping for software-defined networks. In Proceedings of the 9th ACM SIGCOMM Workshop on Hot Topics in Networks, Hotnets-IX, pages 19:1–19:6, New York, NY, USA. ACM. Lara, A., Kolasani, A., and Ramamurthy, B. (2014). Network innovation using openflow: A survey. Communications Surveys Tutorials, IEEE, 16(1):493–512. Lobato, A. G. P., da Rocha Figueiredo, U., Lopez, M. A., Duarte, O. C. M. B., and de Janeiro-RJ-Brasil, R. (2014). Uma arquitetura el´astica para prevenc¸ ao de intrusao em redes virtuais usando redes definidas por software. Suh, M., Park, S. H., Lee, B., and Yang, S. (2014). Building firewall over the softwaredefined network controller. In Advanced Communication Technology (ICACT), 2014 16th International Conference on, pages 744–748. Tran, T. V. and Ahn, H. (2015). A network topology-aware selectively distributed firewall control in sdn. In Information and Communication Technology Convergence (ICTC), 2015 International Conference on, pages 89–94. Xia, W., Wen, Y., Foh, C. H., Niyato, D., and Xie, H. (2015). A survey on softwaredefined networking. Communications Surveys Tutorials, IEEE, 17(1):27–51. Xie, J., Guo, D., Hu, Z., Qu, T., and Lv, P. (2015). Control plane of software defined networks: A survey. Computer Communications, 67:1 – 10. Xing, T., Huang, D., Xu, L., Chung, C.-J., and Khatkar, P. (2013). Snortflow: A openflowbased intrusion prevention system in cloud environment. In Research and Educational Experiment Workshop (GREE), 2013 Second GENI, pages 89–92.

Xing, T., Xiong, Z., Huang, D., and Medhi, D. (2014). Sdnips: Enabling software-defined networking based intrusion prevention system in clouds. In Network and Service Management (CNSM), 2014 10th International Conference on, pages 308–311.