UNIVERSIDADE ESTADUAL PAULISTA JÚLIO DE MESQUITA FILHO Instituto de Geociências e Ciências Exatas IGCE Curso de Bacharelado em Ciências da Computação

Transcrição

1 UNIVERSIDADE ESTADUAL PAULISTA JÚLIO DE MESQUITA FILHO Instituto de Geociências e Ciências Exatas IGCE Curso de Bacharelado em Ciências da Computação JULIANO FERRAZ RAVASI UM FIREWALL COM DETECÇÃO DE ANOMALIAS DE REDE PELO TESTE QUI-QUADRADO Rio Claro SP 2005

2

3 UM FIREWALL COM DETECÇÃO DE ANOMALIAS DE REDE PELO TESTE QUI-QUADRADO Trabalho de Conclusão do Curso (Trabalho de Graduação) apresentado à disciplina ES/TG, do período Integral do Curso de Bacharelado em Ciências da Computação do Instituto de Geociências e Ciências Exatas da Universidade Estadual Paulista Júlio de Mesquita Filho - Campus de Rio Claro. Autor: Juliano Ferraz Ravasi Orientador: Prof. Dr. André Franceschi de Angelis Rio Claro SP 2005

4 AGRADECIMENTOS À minha mãe, Ana Maria, por todo seu amor e carinho, e pelo tanto que trabalhou para me manter na universidade e permitir que eu me formasse, muitas vezes sacrificando os seus sonhos para que eu pudesse realizar os meus. Também à minha irmã, Fabíola, pelo apoio. Um agradecimento muito especial a Maria Izabel, Guilherme, Ana Carolina e Ana Beatriz, minha segunda família e a qual guardo com o mais profundo carinho e respeito. Sempre me incentivaram e me guiaram, fornecendo um apoio inestimável. Seus conselhos sempre foram muito valorizados, e é graças a eles que hoje estou me formando como um Bacharel em Ciência da Computação. Ao professor André Franceschi de Angelis, pela orientação durante o trabalho, pelas idéias e pelos ensinamentos. Ao professor Carlos Norberto Fischer, que constantemente me incentivou e me apoiou durante meu desenvolvimento acadêmico, pela amizade, confiança e bons conselhos. Ao professor Eraldo Pereira Marinho, pela amizade e pelo apoio. A todos os professores e amigos que conheci durante minha vida na universidade, que me deram apoio e que de uma forma ou outra contribuíram para que eu alcançasse meus objetivos.

5 SUMÁRIO AGRADECIMENTOS SUMÁRIO Página 1 INTRODUÇÃO REVISÃO BIBLIOGRÁFICA METODOLOGIA Seleção das variáveis do modelo Coleta e análise dos dados Monitoramento IMPLEMENTAÇÃO A plataforma Linux Netfilter Estrutura principal do programa VALIDAÇÃO E RESULTADOS DISCUSSÃO CONCLUSÕES REFERÊNCIAS APÊNDICES Apêndice A Exemplo de amostra de rede...22

6 4 1 INTRODUÇÃO O surgimento das redes de computadores se deu com o intuito de atender a diversas necessidades, especialmente corporativas, tais como compartilhamento de recursos, economia de capital e escalabilidade. Inicialmente, as redes formavam pequenas vilas isoladas, cada uma restrita a uma única instituição. Cada rede possuia um grupo pequeno e restrito de usuários, e portanto, as medidas de segurança consistiam apenas em delimitar quais recursos cada usuário deveria ter acesso através de um sistema de autenticação. Para se ter acesso aos dados ou recursos oferecidos pela rede, o usuário deveria ter acesso físico ao ambiente onde a rede havia sido instalada. Com o surgimento e a expansão da rede mundial de computadores a Internet a visão e os conceitos das redes de computadores mudaram. Agora o usuário teria a oportunidade de acessar não só os recursos oferecidos pela sua rede local, mas também, alguns recursos oferecidos por outras redes (por exemplo, sítios web). Essas pequenas redes foram progressivamente sendo incorporadas e se tornando segmentos interconectados de uma única grande rede. Com isso, qualquer usuário de qualquer rede local ligada à rede mundial tem potencialmente acesso a qualquer outra rede local, isto é, para qualquer terminal da rede mundial existe um caminho físico interligando tal usuário a ele. Ao mesmo tempo, graças à variedade de serviços oferecidos e a forma como estes impulsionam a nossa produtividade, a rede mundial se tornou uma ferramenta muito importante para a sociedade. Tanto empresas quanto pessoas passaram a depender da sua presença, sendo que eventuais situações caracterizadas pela indisponibilidade da rede causam sérios transtornos. Por estas razões, é importante manter a rede funcionando em seu estado ótimo, durante todo o tempo e protegida contra acessos externos que possam comprometer a segurança dos dados ou a disponibilidade dos serviços. Diversos tipos de anomalias podem ameaçar o bom funcionamento da rede. Neste trabalho, o interesse é voltado às anomalias que causam algum efeito observável sobre o tráfego de dados da rede, que pode ser tanto a ausência de tráfego

7 5 esperado quanto a presença de tráfego não esperado. Um firewall é um tipo de equipamento de rede cuja finalidade é analisar e controlar o tráfego de dados que entra e sai de um determinado segmento da rede. O firewall deve ser instalado na conexão que faz divisa entre a rede local e o seu nível superior, de forma que todo tráfego de dados que precisa transpor o limite da rede local deva necessariamente passar pelo firewall. Dessa forma, podemos dizer que o firewall faz a interface entre duas áreas com diferentes níveis de confiança. De um lado, chamado de rede interna, estão os serviços que desejamos proteger; do outro lado, chamado de rede externa, estão os usuários (não confiáveis do ponto-de-vista da rede interna) que desejam acessar os serviços. Em um firewall convencional, para cada pacote de dados recebido, suas propriedades são analisadas de acordo com um conjunto de regras previamente fornecidas. De acordo com o resultado destas regras, o pacote pode ser aceito, rejeitado ou descartado. Para que isso seja possível, é necessário que já se conheça com antecedência como caracterizar e diferenciar as conexões legítimas das não-legítimas, de forma que as regras adequadas sejam programadas na configuração do firewall. Uma implementação mais moderna, um firewall stateful, possui a capacidade de reconhecer e analisar não apenas os pacotes de dados, mas também as conexões ou fluxos de dados estabelecidos entre os hosts. Ambas as abordagens não levam em consideração o estado da rede como um todo, ou como foi o seu comportamento no passado. Este trabalho visa justamente mostrar como essas informações podem ser obtidas e utilizadas para fornecer uma melhor proteção contra anomalias não previstas. No próximo capítulo será feita uma revisão bibliográfica de obras de interesse para este trabalho. Logo após, a metodologia empregada no desenvolvimento deste projeto será apresentada, e em seguida será descrito o processo de implementação do firewall. Os testes realizados para mostrar a validade do método serão descritos e seus resultados apresentados. O trabalho termina com a discussão dos resultados obtidos e com as conclusões.

8 6 2 REVISÃO BIBLIOGRÁFICA Um modelo para o tráfego de uma rede de computadores foi proposto por Angelis (2003) para a aplicação do Controle Estatístico de Processos (CEP) como forma de viabilizar ações preventivas sobre a rede. O modelo proposto será usado como base para o modelo apresentado neste trabalho. Em Ye; Chen (2001), é apresentada uma técnica de detecção de anomalias baseada em uma estatística qui-quadrado. Para esta técnica, são utilizadas as ocorrências de eventos de sistema para a construção de um perfil de atividades normais, e então, é analisado o afastamento dos eventos recentes em relação ao perfil, a fim de detectar uma invasão. O uso do quiquadrado é comparado com o uso do Hotelling's T², mostrando os benefícios do uso do quiquadrado dado o seu menor consumo de processamento. Em Ye et al. (2002), há uma análise mais detalhada das diferenças entre as técnicas.

9 7 3 METODOLOGIA Para a implementação do sistema, era necessária a escolha de uma plataforma que permitisse o desenvolvimento de uma aplicação capaz de interceptar e analisar o fluxo de rede. Como o gerenciamento da rede é uma das tarefas do sistema operacional, a implementação de um firewall envolve a manutenção de código ou drivers de dispositivos que são executados em seu núcleo. Escrever código de programa que será executado no núcleo do sistema operacional (kernel-space) não é uma tarefa trivial, por diversos motivos: o ambiente de execução não conta com as mesmas bibliotecas de funções, não se pode depurar o código através de um debugger, defeitos podem potencialmente derrubar todo o sistema, etc. O sistema operacional Linux conta com uma infraestrutura modular e bem documentada de gerenciamento de rede, chamada netfilter, assim como um firewall stateful, chamado iptables (RUSSEL et al., 1999). Além das capacidades de análise de tráfego e filtragem de pacotes naturais deste sistema, este ainda permite a instalação de módulos adicionais em userspace 1, complementando sua funcionalidade através de programas escritos pelo usuário. Por este motivo, o sistema operacional Linux, versão , foi escolhido como plataforma para implementação do firewall. Com base nos artigos selecionados, foi estudada a melhor forma de se fazer a análise e o processamento dos dados. O modelo (ANGELIS, 2003) precisou ser adaptado às restrições da implementação do firewall, pois nem todas as variáveis propostas podiam ser analisadas. Também foi necessário estudar a documentação do netfilter a fim de se compreender sua interface de programação. A implementação do firewall foi acompanhada de contínuos testes, dada a necessidade de familiarização com a interface do netfilter e a fim de certificar que o código estava sendo escrito corretamente. Alguns detalhes não previstos inicialmente forçaram a revisão de uma 1 Isto é, em ambiente de usuário, o contrário de kernel-space.

10 8 parte do projeto em um estágio já avançado da implementação, o que atrapalhou o progresso dos testes. Os testes foram realizados primariamente em um computador doméstico, com conexão à Internet através do sistema Speedy (ADSL). Alguns testes também foram realizados no Laboratório de Redes do DEMAC 2 /IGCE 3 /UNESP Rio Claro. 3.1 SELEÇÃO DAS VARIÁVEIS DO MODELO O modelo estatístico de rede proposto por Angelis (2003) é composto por 23 atributos numéricos que descrevem o tráfego da rede em cada intervalo de tempo. Os atributos são apresentados no quadro 1. Ordem Quadro 1 - Variáveis do modelo proposto por Angelis Significado fluxos bytes Quantidade total de pacotes fluxos IP da fonte para o destino Quantidade total de bytes IP do destino para a fonte da fonte para o destino Quantidade total de pacotes IP do destino para a fonte não-ip com fonte interna e destino interno com fonte interna e destino externo Quantidade total de fluxos com fonte externa e destino interno com fonte externa e destino externo TCP UDP com fonte interna e destino interno com fonte interna e destino externo Quantidade total de bytes com fonte externa e destino interno com fonte externa e destino externo com fonte interna e destino interno com fonte interna e destino externo Quantidade total de pacotes com fonte externa e destino interno com fonte externa e destino externo 2 Departamento de Estatística, Matemática Aplicada e Computação. 3 Instituto de Geociências e Ciências Exatas.

11 O trabalho original foi desenvolvido sobre uma rede que possuia equipamentos baseados no protocolo IPX. O protocolo IPX não é suportado iptables, e portanto, não foi levado em consideração neste trabalho. Por se tratar de um firewall, este deve ser instalado na divisão entre duas redes, analisando o tráfego transmitido entre elas. O tráfego restrito a cada uma das redes, ou seja, que não atravessa o firewall, não é de interesse. Através do iptables só é possível interceptar e analisar o tráfego que é roteado através do sistema, o que inviabiliza até mesmo a observação do tráfego não-atravessante. Dessa forma, oito variáveis do modelo original foram descartadas: 4, 9, 10, 13, 16, 19, 20 e 23. Os testes mostraram que mesmo com apenas 15 variáveis, o funcionamento do firewall não é prejudicado. As variáveis selecionadas para a implementação são listadas no quadro 2. A coluna Eq. indica a equivalência das variáveis apresentadas com as variáveis da tabela anterior. Quadro 2 - Variáveis do modelo utilizado N. Nome Significado Eq. 1 TOTAL_FLOWS Quantidade total de fluxos 1, 4 2 TOTAL_PACKETS Quantidade total de pacotes 3 3 TOTAL_BYTES Quantidade total de bytes 2 4 SRC_TO_DST_PACKETS Pacotes da origem para o destino 7 5 DST_TO_SRC_PACKETS Pacotes do destino para a origem 8 6 SRC_TO_DST_BYTES Bytes da origem para o destino 5 7 DST_TO_SRC_BYTES Bytes do destino para a origem 6 8 OUTGOING_FLOWS Total de fluxos com origem interna e destino externo 11 9 INCOMING_FLOWS Total de fluxos com origem externa e destino interno TCP_FLOWS Total de fluxos TCP UDP_FLOWS Total de fluxos UDP OUTGOING_PACKETS Total de pacotes com origem interna e destino externo INCOMING_PACKETS Total de pacotes com origem externa e destino interno OUTGOING_BYTES Total de bytes com origem interna e destino externo INCOMING_BYTES Total de bytes com origem externa e destino interno 18 9

12 COLETA E ANÁLISE DOS DADOS Ao ser carregado e configurado, o firewall passa a receber todos os pacotes de dados da rede que forem roteados pelo sistema operacional. Cada pacote de dados carrega informações sobre os tipos e endereços das interfaces físicas do sistema, endereços de origem e destino, protocolo de comunicação, portas de conexão (TCP e UDP), etc. Todo o pacote IP é disponibilizado para análise na sua forma crua, ou seja, exatamente da forma como foi recebido pela interface de rede. Através dos endereços de origem e de destino, do protocolo de comunicação e das portas de conexão (quando for o caso), podemos identificar e agrupar pacotes relacionados, que pertencem a uma mesma comunicação. Estes agrupamentos são chamados de fluxos. Angelis (2003), em seu trabalho, fez a coleta dos dados sobre o tráfego de rede através do software NeTraMet (BROWNLEE, 1998), gerando extensos relatórios que foram posteriormente processados e analisados. Para a implementação de um firewall, essa abordagem não é adequada. É necessário que a coleta e a análise dos dados sejam realizadas simultaneamente, pois o objetivo do firewall é a sinalização de situações anômalas tão antes elas possam ser detectadas. Para tanto, o firewall identifica e classifica os fluxos aos quais cada pacote pertence assim que são recebidos. Esta tarefa é crítica quanto ao seu desempenho, pois o firewall pode potencialmente receber centenas ou milhares de pacotes por segundo, dependendo da velocidade da rede. Por esse motivo, foi dada uma atenção especial à otimização desta parte do código. O firewall opera em duas fases distintas. Durante a primeira fase, de treinamento, o firewall analisa e registra o comportamento da rede. Durante a segunda fase, de monitoramento, os dados obtidos durante o treinamento são utilizados para determinar se a rede está operando nas condições esperadas. Durante o treinamento, a cada intervalo de tempo definido pelo usuário, os números de fluxos, pacotes e bytes são totalizados e a observação é registrada, iniciando-se uma nova observação. O perfil do comportamento normal da rede é criado através da média da amostra coletada durante o treinamento, e calculando-se a distância de cada observação à média através da fórmula do qui-quadrado:

13 11 n x 2 = i x i 2 (1) i =0 x i Nesta fórmula, x i representa o valor observado para a i-ésima variável do modelo, enquanto que x i representa o valor médio da amostra para a i-ésima variável. O cálculo do qui-quadrado presume que todas variáveis possuam a mesma unidade, contudo, nosso modelo possui variáveis com três diferentes unidades (fluxos, pacotes e bytes). Se as unidades fossem ignoradas, haveria uma discrepância no cálculo (por exemplo, uma pequena diferença em bytes teria tanto peso quanto uma grande diferença em fluxos). Para resolver este problema, os valores foram normalizados dividindo-os pelo número máximo observado de fluxos, pacotes ou bytes, conforme apropriado para cada variável. Assim, no cálculo do qui-quadrado, cada variável representa sua proporção em relação ao máximo observado. A média e o desvio padrão dos valores 2 obtidos para cada observação da amostra são calculados, de forma a se obter a distância esperada das observações com relação ao perfil criado. 3.3 MONITORAMENTO Durante o monitoramento, a rede é observada em intervalos de tempo iguais aos usados para o treinamento, e para cada observação é calculada a sua distância em relação ao perfil obtido utilizando o mesmo teste qui-quadrado. Os valores 2 descrevem uma distribuição normal, e portanto, de acordo com as propriedades da distribuição normal, podemos esperar que 99,7% das observações estejam entre 2 3 S 2 e 2 3 S 2 (YE; CHEN, 2001). Como o interesse neste trabalho é detectar grandes afastamentos em relação ao perfil obtido, o firewall apenas leva em consideração o limite superior, ou seja, 2 3 S 2. Quando uma observação possui um valor 2 anomalia de rede. maior do que este limite, o firewall sinaliza uma possível

14 12 4 IMPLEMENTAÇÃO A linguagem de programação utilizada na implementação do firewall foi o GNU C, que é basicamente a linguagem C acrescida de algumas extensões (FSF, 2004). É a mesma linguagem utilizada no núcleo do sistema operacional Linux, assim como em diversos outros aplicativos para esta plataforma. Um recurso importante desta linguagem é o suporte a variáveis inteiras de 64 bits (unsigned long long), necessárias para a implementação do programa, dada a grande ordem de grandeza dos valores calculados (especialmente bytes). O programa foi implementado com base também na biblioteca GLib (GTK, 2005), que fornece diversas funções utilitárias para simplificar e otimizar o desenvolvimento de programas em linguagem C. Entre os recursos utilizados, podemos destacar: threads, filas assíncronas, registro de log, vetores e tabelas hash. A plataforma netfilter (RUSSEL et al., 1999) foi utilizada para a funcionalidade básica do firewall, ou seja, extrair os pacotes de dados da rede e emitir um veredito se cada pacote deve ser aceito ou descartado. Mais sobre essa plataforma será explicado na próxima seção. Foram utilizados conhecimentos das disciplinas de Estruturas de Dados, Compiladores, Sistemas Operacionais e Redes de Computadores. 4.1 A PLATAFORMA LINUX NETFILTER A plataforma netfilter consiste em uma série de hooks 4 presentes no núcleo do sistema operacional Linux que permite que módulos registrem funções de callback na pilha de rede. As funções são chamadas para cada pacote que atravessa o respectivo hook durante o seu percurso dentro do subsistema de rede do sistema operacional. Através destes hooks, o núcleo do sistema operacional Linux implementa diversas funcionalidades, como filtragem de pacotes, NAT/NAPT (network address (and port) translation), QoS (quality of service), etc. (RUSSEL 4 Literalmente, um gancho, onde funções externas ao módulo são penduradas. Quando este gancho é acionado em resposta a um evento, as funções a ele penduradas são executadas uma a uma. Dessa forma, a funcionalidade do módulo pode ser expandida sem necessidade de alterar diretamente o seu código.

15 13 et al., 1999) O iptables é um firewall stateful, que faz parte da plataforma netfilter. O iptables é responsável pela análise e filtragem de pacotes para a pilha de rede IPv4, e é onde a nossa implementação de firewall se acopla. Sua estrutura é composta por tabelas que implementam funções específicas (filtragem de pacotes, tradução de endereços ou alteração de pacotes), cada tabela possuindo listas (chamadas de correntes) de regras. Cada regra procura determinadas características no pacote ou na conexão, e caso haja uma combinação, define o veredito do pacote (aceitar, rejeitar, descartar, registrar, etc.). A figura 1 mostra o percurso de um pacote através do iptables. Apenas as principais correntes foram mostradas. O pacote, ao entrar no sistema, é verificado de acordo com a tabela de rotas a fim de se determinar se o mesmo é destinado para a própria máquina ou se deve ser roteado para uma outra interface de rede. Caso o pacote seja destinado para a própria máquina, as regras da corrente INPUT serão consultadas e, caso o pacote seja aceito, será passado para os processos locais. Caso o pacote seja destinado para outra rede, as regras da corrente FORWARD serão consultadas e, caso o pacote seja aceito, será encaminhado (roteado) para a interface de saída da rede de destino. Por fim, os pacotes gerados pelos processos locais são analisados pela corrente OUTPUT antes de serem encaminhados para a rede. Figura 1 - Percurso de um pacote através do iptables. Um dos vereditos possíveis para uma regra do iptables é QUEUE, que instrui o iptables a encaminhar o pacote para um processo em user-space neste caso o nosso firewall para análise e posterior decisão de filtragem. A corrente onde a regra deverá ser instalada depende do que deseja-se proteger. Para proteger a máquina local, é necessária a instalação de regras em ambas as correntes INPUT e OUTPUT, enquanto que para proteger uma rede roteada através deste sistema, é necessária a instalação de uma regra na corrente FORWARD. 4.2 ESTRUTURA PRINCIPAL DO PROGRAMA O programa foi dividido em diversos módulos que controlam partes específicas do firewall. Mesmo tendo sido implementado em uma linguagem não orientada a objetos, o

16 14 programa seguiu uma abordagem OO, inclusive com implementação de classes para representar fluxos, pacotes, comandos, modelo de rede, etc. Para uma implementação orientada a objetos em uma linguagem sem essa funcionalidade, as classes são implementadas na forma de registros estruturados (structs), com seus métodos implementados na forma de funções específicas para a manipulação de cada classe (FIELD, 1998). Um exemplo é a biblioteca GLib (GTK, 2005), utilizada no desenvolvimento do programa, que implementa e aprimora esta técnica, adicionando suporte a herança simples, interfaces, sobreposição de métodos, métodos estáticos, tipos genéricos, propriedades, métodos construtores e destruidores e coletor de lixo. Três módulos do programa exigem execução simultânea: interface com o usuário, coleta e controle, e análise e processamento. Para isso, o programa faz o uso de duas threads adicionais. Um uso cuidadoso de mutexes e filas de mensagens foi importante para evitar colisões, condições de corrida e deadlocks entre as linhas de execução. O programa apresenta uma interface de usuário na forma de um interpretador de comandos textuais (figura 2). Através desta interface, o usuário pode configurar, controlar e Figura 2 - Interface com o usuário

17 15 consultar o estado do firewall, bem como ser informado caso uma anomalia seja detectada. As bibliotecas libreadline e libhistory (RAMEY, 2005) foram utilizadas para gerenciar a entrada de comandos. A linha de execução da coleta e controle é dedicada a receber os pacotes enviados pelo núcleo do sistema operacional, decodificar cada pacote, determinar o fluxo ao qual pertence, contabilizar os números de pacotes e de bytes, e emitir o veredito para a aceitação do pacote. Os fluxos são organizados em uma tabela hash, para permitir a busca em tempo mínimo e não causar um grande impacto no desempenho da coleta. Finalmente, a linha de execução da análise e processamento é responsável por realizar os cálculos necessários para a construção do modelo, bem como separar as informações em observações de duração definida pelo usuário. Esta thread fica em repouso durante a maior parte do tempo, sendo acionada periodicamente através de um timer para realizar a totalização das observações e a verificação de anomalias. Também é acionada através de passagem de mensagens enviadas pela thread do interpretador de comandos, para manutenção do histórico de treinamento.

18 16 5 VALIDAÇÃO E RESULTADOS Com o propósito de verificar a eficiência do método qui-quadrado na detecção de anomalias de rede, durante os estágios finais da implementação, o firewall permaneceu constantemente analisando e monitorando a conexão Internet de um computador doméstico. Dessa forma, foi possível coletar diversas amostras de tráfego, com intervalos de observação de 30 e 120 segundos, e períodos treinamento variando entre 30 minutos e 5 horas. O computador utilizado nos testes possuia conexão com a Internet através do sistema Speedy (ADSL), com velocidade teórica máxima de download de 600 kbps e velocidade máxima de upload de 128 kbps (valores práticos em bytes: aproximadamente 62 kb/s para download e 13 kb/s para upload). Após cada treinamento, o firewall era ajustado para o modo de monitoramento, e então exposto a diversos períodos de tráfego, semelhantes ou não ao tráfego presente durante o treinamento. O quadro 3 (APÊNDICE A) exibe uma das amostras coletadas. Algumas variáveis do modelo não foram mostradas por questão de espaço, mas foram contabilizadas nos cálculos. Esta amostra foi obtida utilizando-se intervalos de observação de 30 segundos, durante 30 minutos (portanto, 60 observações). Durante o período de treinamento, o acesso à Internet foi utilizado para diversas tarefas cotidianas, consistindo de navegação web, envio e recebimento de , leitura de newsgroups e downloads de arquivos. Nota-se que a maioria das observações apresentam um valor baixo para 2, poucas mostram valores acima de 10. Isso mostra que o tráfego durante o período de treinamento foi razoavelmente homogêneo, próximo à média calculada.

19 17 O valor médio de 2 calculado para esta amostra foi de 2,50512, e seu desvio padrão foi de 4, O limite superior para considerar o tráfego da rede como normal (3-sigma) foi, para essa amostra, de 15,0053. Essa amostra foi utilizada para monitorar o tráfego de rede em condições semelhantes ao do treinamento, por mais 30 minutos. Nenhum alarme foi disparado nessas condições, sendo que o valor máximo obtido para 2 durante o monitoramento foi de 12,94. Em seguida, foi providenciada a ocorrência de um grande número de conexões externas ao computador, tráfego que não havia similar durante o treinamento. Tão logo 30 segundos se passaram (intervalo entre observações), o firewall sinalizou corretamente uma anomalia. O valor 2 calculado para as 5 primeiras observações nestas condições foram: 12009,9; 12051,8; 13797,3; 35004,7 e 26844,6. Outros testes foram realizados. Em geral, mesmo pequenos afastamentos em relação ao perfil são detectados corretamente, com valores de 2 pelo menos uma ordem de grandeza acima do limite superior estabelecido durante o treinamento. Não houve falsos positivos durante os testes. Contudo, podemos notar que para este teste em específico, uma das observações do treinamento está acima do limite superior calculado para a amostra. Essa foi a única ocorrência desse evento durante os testes.

20 18 6 DISCUSSÃO Os testes realizados demonstraram que o teste qui-quadrado, em conjunto com o modelo de rede proposto, pode ser usado com eficiência para detectar anomalias que exercem influência sobre o tráfego de uma rede nas condições estabelecidas. O intervalo entre as observações, o período de treinamento e o limite superior considerado como tráfego normal são fundamentais para definir a sensibilidade e a eficácia do método. Para que o firewall seja usado em produção, o intervalo entre as observações deve ser maior, para desconsiderar pequenas flutuações e gerar um perfil mais homogêneo. O período de treinamento também deve ser maior do que o dos testes realizados, pois em geral as redes apresentam comportamentos distintos em diferentes períodos do dia (ou da semana). Na amostra usada como exemplo, um dos valores 2 do próprio treinamento se encontrava fora do limite superior calculado, e seria sinalizado como anomalia caso essa amostra fosse usada no monitoramento. Caso isso se torne um problema, podemos aumentar o limite superior para um valor maior de sigmas. Por exemplo, usando seis sigmas acima da média ( 2 6 S 2 ), o limite superior seria 27,5055. Esse valor não acusaria falsos positivos na própria amostra de treinamento, e também não prejudicaria a detecção de anomalias (que geram valores 2 ainda muito grandes). É importante ressaltar que existem outros tipos de situações anômalas que não são detectadas por este firewall, e que são do interesse de um administrador de redes. Apenas situações que produzem um efeito observável sobre o tráfego de rede podem ser detectadas. Uma invasão, por exemplo, pode ser tão silenciosa a ponto de não perturbar a rede o suficiente para ser detectada por esse método. Para isso, a rede deverá contar também com um firewall convencional ou um Sistema de Detecção de Intrusão. Da forma como foi implementado, quando uma anomalia é detectada, o firewall apenas sinaliza com um alarme. Uma das idéias originais do projeto era fazer com que o firewall

21 19 determinasse quais fluxos são responsáveis pela divergência e tomasse providências para levar o tráfego da rede devolta para perto do perfil gerado. Cada fluxo armazena informações sobre número de pacotes e bytes enviados por cada extremidade. Dessa forma, uma abordagem trivial seria iterar sobre os fluxos a procura de um que, quando subtraído da última observação, fizesse seu valor 2 se aproximar da média. A eficiência dessa abordagem é questionável, pois poucas vezes uma anomalia é causada por um único fluxo. Encontrar todas as combinações possíveis também é inviável, pois trata-se de um problema de complexidade exponencial.

22 20 7 CONCLUSÕES Este trabalho teve como objetivo demonstrar como o tráfego de rede pode ser analisado e processado a fim de se criar um perfil baseado em um modelo de tráfego, de forma a permitir a detecção de anomalias através do teste qui-quadrado. Para isso, foi implementado um firewall utilizando-se a plataforma netfilter do sistema operacional Linux. O firewall analisa os pacotes recebidos da rede e identifica os fluxos aos quais pertencem, totalizando o número de fluxos, pacotes e bytes e gerando o perfil da rede. Com base neste perfil, o firewall é capaz de sinalizar anomalias de rede verificando quando as observações se afastam do perfil gerado. Diversos testes foram realizados em um computador doméstico, analisando o tráfego de rede durante tarefas comuns, e então, comparando com diversas outras situações. O firewall sinalizou corretamente situações que não haviam sido observadas durante o treinamento, e não gerou falsos positivos para situações normais. Os problemas e a eficiência do método foram então discutidos. O objetivo do trabalho foi cumprido de forma satisfatória, demonstrando que o teste quiquadrado, em conjunto com o modelo proposto, pode ser usado para detectar anomalias de rede.