42
Anais
IPSFlow – Uma Proposta de Sistema de Prevenção de
Intrusão Baseado no Framework OpenFlow
Fábio Yu Nagahama1, Fernando Farias1, Elisângela Aguiar1, Luciano Gaspary2,
Lisandro Granville2, Eduardo Cerqueira1, Antônio Abelém1
1
2
Instituto de Tecnologia - Universidade Federal do Pará (UFPA)
Instituto de Informática – Universidade Federal do Rio Grande do Sul (UFRGS)
{nagahama, fernnf, eaguiar, cerqueira, abelem}@ufpa.br,
{paschoal, granville}@inf.ufrgs.br
Abstract. The ideal Intrusion Prevention System (IPS) is the one that detects
malicious traffic across the network and blocks it at its source. Conventional
IPSs do not meet these requirements satisfactorily, because when operating in
active mode cannot have a wide coverage on the network and just block the
passing traffic. And while catching mirrored traffic, it can only block it when
working together with switches from the same solution or vendor. In this
scenario, this paper presents IPSFlow, an IPS solution for selective and
distributed capture with automated blocking of malicious traffic based on
OpenFlow.
Resumo. O sistema de prevenção de intrusão (Intrusion Prevention System –
IPS) ideal é aquele que consegue detectar um tráfego malicioso em toda a
rede e bloqueá-lo na sua origem. IPSs convencionais não atendem estas
características de forma satisfatória, pois quando atuam no modo ativo, não
conseguem ter uma ampla cobertura na rede e somente bloqueiam o tráfego
passante. E quando atuam capturando tráfego espelhado, só bloqueiam um
tráfego malicioso se atuarem em conjunto com switches da mesma solução ou
fabricante. Diante deste cenário, este artigo apresenta o IPSFlow, uma
solução de IPS baseada no framework OpenFlow para captura seletiva e
distribuída com bloqueio automatizado de tráfego malicioso.
1. Introdução
Com a crescente quantidade de incidentes de segurança, o tratamento manual de cada
incidente se torna uma atividade inviável para o administrador de segurança. Segundo o
Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança no Brasil
(CERT.br), só em 2011, foram quase 400.000 incidentes reportados [CERT 2012].
Desta forma, sistemas de detecção de intrusão de rede (Network Intrusion Detection
System - NIDS) e sistemas de prevenção de intrusão (Intrusion Prevention System - IPS)
tornam-se extremamente relevantes.
Um IPS é um NIDS que, além de capturar, analisar e reportar a ocorrência de
um tráfego malicioso na rede, tenta bloquear ou mesmo minimizar os impactos
causados pelo invasor [Mukhopadhyay 2011]. A instalação de um IPS deve considerar
dois pontos: desempenho e cobertura [Snyder 2008]. Um IPS ideal é aquele que, mesmo
na ocorrência de falhas em seu hardware, consegue detectar tráfego malicioso em toda a
rede e consegue bloqueá-lo o mais próximo de sua origem sem impactar no
funcionamento da rede.
Agradecimentos: Este trabalho foi parcialmente financiado pelo Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq) e
Fundação de Amparo à Pesquisa do Estado do Pará (FAPESPA).
III Workshop de Pesquisa Experimental da Internet do Futuro
É comum um IPS atuar no modo ativo (inline), ou seja, no caminho de um meio
físico, capturando, analisando e devolvendo o tráfego para a rede. Neste modo, o IPS é
normalmente instalado na borda da rede seguido de um firewall ou mesmo um roteador
que dá acesso a uma rede externa (e.g., conexão para um sítio principal ou Internet).
Desta forma, a captura e a análise se restringem ao tráfego que passa pelo IPS.
Consequentemente, um tráfego malicioso em um segmento interno da rede não é
capturado e não pode ser bloqueado (e.g., disseminação de um worm).
Um IPS também pode atuar capturando tráfego espelhado de um switch (modo
passivo). Porém, neste caso, o IPS só consegue bloquear um tráfego se possuir alguma
integração com os demais equipamentos da rede (normalmente da mesma solução e de
um mesmo fornecedor). Como geralmente o parque de ativos da rede é bastante
heterogêneo, dificilmente este cenário é encontrado na prática.
O framework OpenFlow, proposto por McKeown et al. [McKeown 2008], é um
padrão aberto nos moldes das redes definidas por software (Software Defined Networks
- SDNs) que prevê a separação do plano de dados e do plano de controle. Desta forma, o
OpenFlow permite que pesquisadores e administradores programem o comportamento
da rede enquanto os fabricantes de equipamentos de rede, como switches e roteadores,
definem o funcionamento interno do hardware.
Em uma rede OpenFlow, um controlador tem uma visão ampla da rede, bem
como a capacidade de manipular os fluxos de dados logo que estes são recebidos em
qualquer switch de acesso ou de distribuição que implemente as funcionalidades
contidas na especificação do OpenFlow [Openflow 2011]. Por este motivo, o uso do
OpenFlow, na área de segurança e monitoramento de redes, já foi abordado em
trabalhos anteriores [Ballard 2010] [Braga 2010] [Mehdi 2011].
No trabalho de Ballard et al. [Ballard 2010], o OpenSAFE foi proposto como
uma solução para redirecionamento de tráfego com propósitos de monitoramento em
conjunto com uma linguagem de alto nível, para especificar fluxos, chamada de
ALARMS (A Language for Arbitrary Redirection for Measuring and Security). Em
conjunto a uma rede neural artificial do tipo SOM (Self Organizing Maps), o OpenFlow
foi usado, obtendo bons resultados, por exemplo, para a detecção de ataque DDoS
(Distributed Denial of Service) [Braga 2010]. Mehdi et al. [Mehdi 2011] propuseram e
avaliaram o uso do OpenFlow na captura de tráfegos anômalos nas redes de usuários
domésticos ou de pequenas empresas (SOHO – Small Office/Home Office) conectadas a
um provedor de serviço de Internet.
Apesar da existência das pesquisas mencionadas acima, não se tem notícias do
uso do resultado da detecção de intrusão para bloqueio automático do tráfego malicioso,
tal como é proposto neste artigo. Desta forma, devido a flexibilidade permitida pela
programabilidade da rede via OpenFlow, este artigo apresenta o IPSFlow, uma solução
que consiste na utilização de uma rede OpenFlow para a construção de um IPS com
captura seletiva e distribuída de tráfego nos switches para análise em um ou mais IDSs.
Nesta solução, de acordo com o resultado da análise, o controlador OpenFlow pode ser
automaticamente instruído a bloquear o fluxo no switch mais próximo de sua origem.
O restante do artigo está estruturado da seguinte forma. A seção 2 apresenta
algumas das dificuldades envolvidas na utilização de um IPS na rede. Na seção 3, a
proposta da solução IPSFlow é detalhada. E por fim, as considerações finais e trabalhos
futuros são discutidos na seção 4.
43
44
Anais
2. Detecção de tráfego malicioso em rede
A Figura 1 apresenta uma típica rede com um switch central que concentra demais
switches de distribuição ou acesso, roteadores e servidores. As posições A, B e C na
figura representam alguns locais onde um IPS pode ser instalado e os fluxos 1, 2 e 3
(linhas tracejadas) indicam alguns tipos de tráfego que uma estação localizada em um
segmento de rede pode iniciar.
Devido ao seu modo de atuação, é comum que o IPS seja instalado inline ao
acesso externo (posição A). Porém, como este só captura o tráfego passante (i.e., fluxo
1), tráfegos confinados dentro da rede não são analisados (i.e., fluxos 2 e 3). Para
capturar os fluxos do tipo 1 e 2, o IPS pode ser conectado ao switch central (posição B)
e/ou nos switches de distribuição (posição C) e receber uma cópia de todo o tráfego
através do espelhamento de portas (modo passivo). Porém, uma vez que apenas uma
cópia do tráfego é recebida, o bloqueio de tráfego se torna inviável e sua ação fica
restrita a gerar alertas de forma semelhante a um NIDS. Para bloquear o tráfego
malicioso detectado nas posições B e C, o IPS necessitaria do auxílio de um
equipamento capaz de bloquear o tráfego malicioso, e como visto anteriormente, esta é
uma situação rara de acontecer, senão inviável.
C
3
Rede 1
1
B
A
2
Internet
Rede 2
Switch
de núcleo
Rede de servidores
Figura 1. Visão geral de uma rede com IPS.
Distribuir IPSs inline em cada conexão ao switch central pode restringir a
atuação de um ataque, mas a sincronização e administração de vários IPSs torna esta
opção inviável. Em qualquer um dos locais instalados, o hardware do IPS deve ser
dimensionado para permitir a captura e análise de todo o tráfego que receber. Atuando
no modo inline, uma falha ou mesmo um subdimensionamento do IPS, pode isolar a
comunicação com a rede externa, adicionar retardos excessivos no tráfego ou mesmo
descartar pacotes. No modo passivo, a interface que conecta o IPS deve suportar a
captura do tráfego das demais portas com o menor descarte possível.
A utilização de mais IPSs para balanceamento da carga ou com diferentes
especialidades de análise se torna inviável, pois na atuação inline, mais retardo pode ser
adicionado e no modo passivo, dependendo do fabricante do switch, a quantidade de
portas para espelhamento pode se restringir a apenas uma [Ballard 2010].
As soluções de IPSs distribuídos de grandes fabricantes comerciais atuam no
modo inline e implicam na dependência de seus clientes com os fornecedores. Nesses
casos, a adição de módulos ou mesmo a atualização do ambiente tendem a ser restritos
III Workshop de Pesquisa Experimental da Internet do Futuro
apenas ao fornecedor, inviabilizando qualquer tipo de customização por parte do
administrador da rede. Mesmo soluções com softwares livres, questões como
desempenho, administração onerosa e sincronização de informação se tornam um
problema.
Diante do exposto, a flexibilidade oferecida pelas SDNs se torna uma grande
aliada, pois combina o bom desempenho e a alta densidade de portas dos switches para
o tratamento do tráfego no plano de dados, com a programabilidade do plano de
controle ao possibilitar que o tráfego seja encaminhado de acordo com as necessidades
do administrador [Lantz 2010].
No contexto das SDNs, tem-se o OpenFlow, que vem crescendo em uso e estudo
na área de redes de computadores. Seu funcionamento básico consiste em verificar se
um fluxo possui algum tratamento previsto na tabela de fluxos dentro do switch
(também chamado de datapath). Havendo uma entrada na tabela de fluxos, a ação
definida é executada. Caso contrário, os dados do fluxo são encapsulados e
encaminhados para o controlador para tomada de decisão. O controlador decide como o
tráfego deve ser tratado e envia uma resposta ao datapath que atualiza a tabela de fluxos
com as instruções recebidas. Pacotes subsequentes do fluxo receberão o mesmo
tratamento até que a entrada na tabela de fluxos seja removida [Openflow 2011].
3. IPSFlow
O IPSFlow possui dois elementos fundamentais: uma aplicação denominada de
IPSFlowApp e um IDS (ou mais). A aplicação atua sobre o controlador para gerenciar e
armazenar as regras que definem o encaminhamento dos fluxos na rede baseadas nas
definições de segurança.
3.1. Arquitetura e funcionamento
A Figura 2(a) apresenta uma visão geral da composição de uma rede com switches
OpenFlow na solução IPSFlow. Quando o primeiro pacote de um fluxo é recebido no
switch OpenFlow (passo 1), o processo de consulta à tabela de fluxos e controlador
seguem conforme especificado no OpenFlow [Openflow 2011] (passo 2). Ao receber
uma requisição de um datapath, o controlador consulta o IPSFlowApp para verificar a
existência de regras para captura e análise do tráfego recebido (passo 3). Caso o fluxo
esteja marcado para ser analisado, este pode ser tratado de duas formas no datapath:
• Os pacotes do fluxo podem ser encaminhados para o destinatário (passo 4) e
uma cópia enviada para análise no(s) IDS(s) (passo 5). Neste caso, ao se concluir
que se trata de um tráfego malicioso, o(s) IDS(s) envia(m) o resultado ao
controlador (passo 6) para que o tráfego seja bloqueado no datapath e esta
decisão é armazenada no controlador;
• Os pacotes do fluxo podem ser retidos e uma cópia enviada para análise. Neste
momento, um contador decrescente é inicializado. Caso a análise conclua que o
tráfego é malicioso antes do contador chegar a 0, o resultado é enviado ao
controlador para instruir o datapath a descartar os pacotes retidos. Caso o
contador chegue a 0, o tráfego é liberado para o seu destino.
45
46
Anais
3.2. A aplicação IPSFlowApp
A Figura 2(b) apresenta uma visão dos módulos que compõem a aplicação
IPSFlowApp, bem como o fluxo das mensagens trocadas entre eles. O módulo de
configuração (a) é o centro de toda aplicação e o ponto de comunicação entre a
aplicação e o administrador. É neste módulo que ocorre toda a definição de quais ações
devem ser tomadas nos fluxos e o armazenamento das regras na base de regras em (b).
Ele também é responsável por receber e tratar as notificações de alertas, podendo
reconfigurar automaticamente a base de regras (b) de acordo com as definições do
administrador.
A base de regras (b) é o local onde as ações a serem tomadas para um
determinado fluxo são armazenadas, por exemplo, o bloqueio do fluxo,
encaminhamento do fluxo por uma porta com cópia para análise ou retenção com cópia
para análise.
IPSFlowApp
Base de regras
(a)
(b)
Configuração
Administrador
(c)
(d)
Alertas
Consulta
IDS
Controlador
b) IPSFlowApp
a) Fluxos
Figura 2. Solução IPSFlow.
O módulo de consulta (c) é o elemento responsável pela comunicação entre o
controlador e a aplicação. Esse módulo recebe a consulta do controlador, extrai as
informações necessárias e pesquisa na base de regras (b) à procura de ações que devem
ser tomadas para o fluxo recebido. Havendo uma regra instalada, a ação é encaminhada
ao controlador para as devidas configurações nos datapaths. Caso não haja regra
alguma, uma regra padrão de encaminhamento pode ser dada como resposta.
O módulo de alertas (d) é o responsável por classificar, tratar o resultado da
análise do(s) IDS(s) e notificar o módulo de configuração (a). Uma vez que é prevista a
utilização de diversos tipos de IDSs, esse módulo deve ser capaz de receber os
resultados das análises e compatibilizá-los em formatos que possam ser utilizados
dentro da aplicação.
O uso do OpenFlow para propósitos de segurança se mostrou bastante promissor
em trabalhos anteriores como em [Ballard 2010], [Braga 2010] e [Mehdi 2011]. Porém,
estes trabalhos se limitaram a detectar e alertar a ocorrência de tráfegos maliciosos na
rede. A proposta do IPSFlow é estender estes trabalhos, uma vez que permite a captura
do tráfego em qualquer local da rede, o encaminhamento do tráfego para análise em um
ou mais IDSs e a reutilização do resultado da análise para a reconfiguração automática
das tabelas de fluxos dos datapaths.
III Workshop de Pesquisa Experimental da Internet do Futuro
4. Considerações finais e trabalhos futuros
Com o aumento de incidentes de segurança, cada vez mais um IPS se faz necessário na
administração da segurança de uma rede. O uso de IPSs possui requisitos de cobertura e
desempenho que são melhores atendidos no modelo de IPSs distribuídos. Porém, a
sincronização e administração de diversos IPSs torna esta opção pouco escalável.
Por ser baseado no OpenFlow, o IPSFlow proposto neste artigo permite uma
administração simplificada, com solução aberta e flexível que permite a análise
centralizada de um ou mais analisadores de tráfego (IDSs). Uma vez que a nossa
solução prevê a captura seletiva, a mesma não exige o uso de hardwares robustos nos
IDSs, possibilitando inclusive o uso de diversos tipos de IDSs com especialidades
distintas. Com atuação em todos os switches da rede, nossa solução potencialmente
apresenta cobertura mais ampla e com a captura de tráfego sendo feita sem a
necessidade de espelhamento de portas. Assim, o IPSFlow permite o bloqueio do
tráfego malicioso o mais próximo de sua origem.
Como trabalhos futuros, tem-se o desenvolvimento da aplicação IPSFlowApp e
a validação da proposta através da criação de um testbed utilizando tráfego capturado
em uma rede real. Testes de desempenho da solução variando e/ou combinando diversos
tipos de IDSs também deverão ser executados para coleta e comparação de resultados.
Referências
Ballard, J., Rae, I., Akella, A. Extensible and Scalable Network Monitoring Using
OpenSAFE. Internet Network Management Workshop / Workshop on Research on
Entreprise Networking. San Jose, CA. 27 Abr. 2010.
Braga, R. S., Mota, E., Passito, A. Lightweight ddos floding attack detection using
nox/openfow. IEEE Conference on Local Computer Networks (2010), IEEE.
CERT, Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança no
Brasil. Disponível em: <http://www.cert.br>. Acesso em 25 out. 2011.
Lantz, B., Heller, B., and McKeown, N. (2010). A network in a laptop: rapid prototyping
for software-defined networks. ACM SIGCOMM Workshop on Hot Topics in
Networks, Hotnets ’10, pages 19:1–19:6, New York, NY, USA. ACM
McKeown, N., Anderson, et al. OpenFlow: Enabling Innovation in Campus Networks.
Computer
Communication
Review.
2008.
Disponível
em:
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.141.2269&rep=rep1&type=p
df >. Acesso em 20 ago. 2011.
Mehdi, S. Khalid, J., Khayam, S. Revisiting Traffic Anomaly Detection using Software
Defined Networking. Recent Advances in Intrusion Detection (RAID), 2011.
Disponível em: < http://www.wisnet.seecs.nust.edu.pk/publications/2011/raid2011_pap
er.pdf>. Acesso em 21 jan. 2012.
Mukhopadhyay, I., Chakraborty, M., Chakrabarti, S. A Comparative Study of Related
Technologies of Intrusion Detection & Prevention Systems. Journal of Information
Security, 2011, v. 2, p. 28-38.
OpenFlow.
The
OpenFlow
Switch
Specification.
Disponível
em:
<http://OpenFlowSwitch.org>. Fevereiro 2011. Acesso em 27 set. de 2011.
Snyder, J. Guide to Network Intrusion Prevention Systems. Disponível em:
<http://www.pcworld.com/businesscenter/article/144634/guide_to_network_intrusion_pr
evention_systems.html>. Outubro 2008. Acesso em 20 fev. 2012.
47