Controle Independente de Restrições de Acesso a Redes Locais em Firewalls que Utilizam o IPTables Diego Luís Kreutz 1 1 Laboratório de Sistemas de Computa cão LSC Núcleo de Ciência da Computa cão NCC Universidade Federal de Santa Maria UFSM kreutz@inf.ufsm.br Abstract. This work presents a proposal and a prototype of a system which aims to support a dinamic and automatic rule management in firewalls that work with the IPTables package filter. One of the goals is automatically identify and block connections that probably are schedules for future attacks. Resumo. Este trabalho apresenta uma proposta e um protótipo de um sistema que visa dar autonomia e dinamicidade a um firewall que utilize o filtro de pacotes IPTables. Um dos objetivos é identificar e bloquear automaticamente conexões que tem uma boa probabilidade de serem prévias de um futuro ataque. 1. Introdução Como as tecnologias de rede são desenvolvidas a ritmos frenéticos, as soluções para a segurança e integridade de usuários e dados de uma rede precisam evoluir e apresentar soluções mais flexíveis e versáteis. Estas devem buscar garantir uma maior tranqüilidade aos usuários e administradores de rede [16, 12, 6]. Os firewalls são sistemas importantes para garantir um certo nível de segurança a redes de computadores e aos seus usuários. Técnicas e ferramentas que auxiliam o gerenciamento e monitoramento desses sistemas são necessárias e imprescindíveis para um bom controle e filtragem do tráfego de uma rede. O objetivo deste trabalho é apresentar uma proposta e um protótipo de um sistema que busca realizar um controle automático e dinâmico das regras de acesso a rede, mantidas pelo IPTables. A proposta é criar um sistema simples e eficaz para identificar e prevenir conexões com uma boa probabilidade de originarem ataques futuros. Além disso, identificar e bloquear ataques em andamento, que se enquadrem em padrões de freqüências de conexões, observadas em técnicas de ataques conhecidas. O texto esta dividido da seguinte forma: seção 2) protótipo e funcionamento do sistema; seção 3) resultados; seção 4) trabalhos relacionados; e seção 5) conclusão. Junto a conclusão são apresentados também alguns trabalhos futuros. 2. Protótipo e Funcionamento do Sistema A proposta do sistema surgiu de necessidades de segurança e controle de tráfego encontradas no Núcleo de Ciência da Computação (NCC) da UFSM. O objetivo mestre é desenvolver uma ferramenta simples e prática para o monitoramento e aplicação dinâmica e automática de regras no filtro de pacotes do firewall principal da rede. Bolsista do CNPq
Uma visão global da proposta pode ser vista na figura 1. Como pode ser observado, este protótipo do sistema tem duas opções de configuração. A primeira é formada por quatro componentes básicos, o IPTables 1, arquivos de log, filtros e módulo de operação e controle do sistema. A segunda configuração é composta por três módulos principais, o IPTables, módulo de acoplagem e o componente de inteligência do sistema. Ambas as configurações buscam seguir a filosófica dos sistemas IPS 2. O IPTables foi escolhido como referência de filtro de pacotes por ser o mais utilizado e conhecido entre administradores de sistemas GNU/Linux. Além disso, em grande parte dos casos o firewall da rede é composto por um sistema GNU/Linux e o filtro de pacotes IPTables. Sistemas de gerenciamento de filtros de pacotes como o giptables[11], gshield[5], firehol[14], fwbuilder[9], gtk-iptables[13], knetfilter[4] e shorewall[3] utilizam o IPTables para aplicar e gerenciar regras, tabelas e políticas. Firewall IPTables Sistema IPTables + ModuloS Logs Filtro Sistema Configuracao 1 Configuracao 2 Figura 1: Ilustração das opções de configuração e uso do sistema A configuração 1 (figura 1) é possível sem nenhuma alteração ou instalação de componentes auxiliares no sistema GNU/Linux, ou seja, a ferramenta não depende de outros recursos do sistema operacional. Para ativar esse ambiente basta instalar e ativar o sistema de monitoramento e aplicação de regras sobre o IPTables. O monitoramento e controle de acesso é feito sobre os próprios registro de atividade do IPTables. No caso, o sistema ativa um filtro de log próprio (esse filtro é ativado sobre o arquivo de logs padrão do IPTables), identificando ações inapropriadas e aplicando automaticamente regras de bloqueio de acesso. A ativação do sistema, no caso da configuração 1, é simples e rápida. Basta definir três requisitos do sistema: 1) o número mínimo de infrações 3 ; 2) o intervalo de tempo de monitoramento; 3) o intervalo de tempo para a rotação dos logs auxiliares do filtro do sistema. Com apenas essas três variáveis setadas o sistema inicia o monitoramento e aplicação de regras de controle de conexões no IPTables. O primeiro requisito define o número mínimo de infrações para considerar uma máquina como uma possível ameaça a rede. Todas as máquinas que venham a cometer mais infrações que o número mínimo definido terão seu acesso a rede interna automaticamente bloqueado pelo sistema. A definição do número mínimo de infrações deve ser feita de acordo com análises do tráfego e ações contra a rede local. Na seção 3 são apresentados alguns gráficos, da rede do NCC, que podem auxiliar a determinar esse valor mínimo. O segundo requisito do sistema é o intervalo de tempo do monitoramento. Esse 1 IP tables - tabelas IP (mais conhecido como filtro de pacotes) 2 Intrusion Prevention System - Sistema de Prevenção de Intrusão 3 Infrações, no âmbito deste trabalho, representam tentativas de acessos não autorizados. As infrações incluem tentativas (externas) de acessar serviços e máquinas restritos a rede interna.
intervalo remete ao tempo de espera do sistema até analisar os registros armazenados pelo filtro do sistema. A cada intervalo de análise o sistema manterá uma tabela de relação de infratores e uma tabela de infratores bloqueados (IPs que ultrapassaram o número mínimo de infrações). As infrações de cada endereço IP são cumulativas e verificadas a cada intervalo de monitoramento. Esses intervalos de monitoramento tem por objetivo evitar uma possível sobrecarga de processamento do sistema no caso de uma análise em tempo real. Com os intervalos de tempo de monitoramento de registros os dados são agrupados por faixas de tempo e mais rapidamente comparados. A definição desses intervalos pode ser determinada e programada pelo nível de atividade do sistema. Quanto maior o número de registros de log do filtro do sistema por segundo, menor o intervalo de monitoramento. Quanto menor for o número de registros por segundo, maior pode ser o intervalo de monitoramento. Neste último caso é interessante estabelecer um limite superior, ou seja, um intervalo de monitoramento máximo (exemplo: 4 minutos - uma análise dos logs é processada a cada quatro minutos). O terceiro requisito, o tempo de rotação dos logs auxiliares do filtro do sistema, determina o intervalo de bloqueio dos IPs infratores. Quando o sistema realiza a rotação dos logs ele verifica quais endereços IP não estiveram cometendo novas infrações nos últimos intervalos de monitoramento (requisito 2 do sistema). O número de intervalos de monitoramento que serão utilizados na comparação é determinado pelo resultado da divisão entre o tempo de rotação dos logs e o tempo de um intervalo de monitoramento. Os IPs que não cometeram novas infrações serão liberados pelo sistema. Para o funcionamento da configuração 1 do sistema é necessário que o IPTables esteja configurado de acordo com as seguintes políticas: a) existem regras explicitas para liberar todas as conexões autorizadas; b) a regra geral é nega-se tudo o que não é explicitamente permitido; c) são logadas e identificadas todas as tentativas de acesso não autorizado, levando em conta endereços IP e portas. A configuração 2 (figura 1) é semelhante a configuração 1. A diferença é que os pacotes serão analisados diretamente no fluxo de tráfego, não sendo necessário analisar os arquivos de log do IPTables. Um segundo diferencial é que nesse caso o IPTables será modificado para permitir a análise e retenção de pacotes. O objetivo é processar uma análise em tempo real e acumular seqüências de pacotes de uma mesma origem, tentando identificar o tipo de ação pretendida. Uma varredura na rede poderia ser um exemplo. Neste caso, supondo que o sistema retenha a resposta dos 1 primeiros pacotes, se for detectado que os pacotes retidos tinham como destino máquinas e/ou portas distintas, e uma ou mais dessas conexões foram enquadradas como infrações, todos os pacotes serão descartados. Em uma situação como essa, a origem dos prováveis ataques ou varreduras não receberá nenhuma resposta e, além disso, será automaticamente bloqueada qualquer tentativa futura de conexão, dispensando análises futuras de pacotes desse IP de origem. Contudo, essa não análise é válida apenas até o momento em que o endereço IP seja novamente liberado pelo sistema. Após a liberação ele entrará novamente nas políticas de análise normal de pacotes. 3. Resultados Esta seção apresenta alguns resultados da implementação e uso do sistema de controle dinâmico e automatizado de conexões registradas pelo IPTables. A primeira versão do sistema é baseada na configuração 1, descrita na seção anterior. Os dados estatísticos aqui apresentados foram extraídos da atividade do sistema no firewall principal do NCC. A máquina que comporta o firewall e executou também o protótipo do sistema é um Pentium 166MHz. Apesar disso, praticamente não houveram
problemas de desempenho. Apenas em alguns momentos de muito tráfego na rede o sistema apresentou uma maior utilização da CPU. Mesmo assim, seu desempenho continuou aceitável. A coleta e análise dos dados ocorreu do dia 2 de abril ao dia 1 de junho de 24. O gráfico 2 apresenta o número de máquinas que cometeram algum tipo de infração, segundo as tabelas de regras do IPTables. Este está configurado para registrar todas as conexões, ou tentativas de conexão, que não são explicitamente permitidas. Os dados referem-se ao período do dia 21 ao dia 27 de abril de 24. Pode ser observado que o maior nível de incidência ocorre no dia 23, sexta-feira. No gráfico 2 é expresso, além do número de máquinas infratoras por dia, o número de máquinas de acordo com um número mínimo de infrações. Pode ser observado que a partir de 4 infrações as linhas do gráfico começam a estabilizar-se, não havendo mais grandes modificações ou picos acima da linha de bloqueio (número de infrações tomado como mínimo). Além disso, pode ser visto que existe uma queda significativa no número de IPs entre mais de 1 e mais de 2 infrações. Essa queda é ainda mais expressiva quando comparados com os limites de 1 e 4 infrações mínimas. Por este gráfico poderia ser concluído que um bom número mínimo de infrações para a programação do sistema seria um valor entre 4 ou mais infrações. Entre 1 e 4 infrações aparecem variações grandes no número de máquinas infratoras. Isso pode significar que muitas máquinas não maliciosas, mas que tentaram casualmente acessar alguma porta ou serviço bloqueado, também estão sendo contabilizadas. 14 numero de maquinas infratoras por dia 18 numero de maquinas por internalo de reciclagem 12 16 numero de maquinas 1 8 6 4 2 2 21 22 23 24 25 26 27 dia do mes (abril de 24) mais de 1 infracoes mais de 2 infracoes mais de 3 infracoes mais de 4 infracoes legenda mais de 5 infracoes mais de 7 infracoes mais de 9 infracoes uma ou mais infracoes numero de maquinas bloqueadas 14 12 1 8 6 4 2 5 1 15 2 25 3 35 4 45 5 das 15:15 do dia 2 as 3:15 do dia 21 de abril de 24 (intervalos de 1 a 2 horas) Figura 2: Variação do número de máquinas (IPs) Figura 3: Número de IPs bloqueados 3 numero de maquinas por internalo de reciclagem 35 numero de maquinas por internalo de reciclagem 25 3 numero de maquinas bloqueadas 2 15 1 numero de maquinas bloqueadas 25 2 15 1 5 5 2 4 6 8 1 12 14 das 7:3 do dia 23 ate as 19:3 do dia 24 (abril de 24) (intervalos de 1 a 2 horas) 1 2 3 4 5 6 do dia 2 ao dia 27 de abril de 24 Figura 4: Número de IPs infratores Figura 5: Número de IPs infratores Os dados dos gráficos 3, 4 e 5 resultaram da utilização do valor 4 como o número mínimo de infrações para a máquina (IP) ser enquadrada como infratora. Neste enquadramento, o IP é bloqueado até a rotação dos logs auxiliares.
O gráfico 3 apresenta o número de IPs bloqueados por intervalo de monitoramento dos logs auxiliares. Pode ser observado que a aproximadamente cada 5 intervalos de monitoramento ocorre uma rotação de logs, quando os endereços IP que não cometeram novas infrações durante os últimos 5 intervalos de monitoramento são liberados. Nesse exemplo, a rotação dos logs é feita em intervalos dinâmicos que variam de 1 a 2 horas. A precisão do intervalo depende da quantidade de atividade (registros de log) do IPTables. O gráfico 4 mostra um intervalo de tempo maior. Nele estão representados o número de IPs bloqueados em um período de 36 horas. A variação é semelhante a do gráfico 3. Uma diferença mais significativa é a brusca variação entre os intervalos (do gráfico) 12 e 14. A liberação de todos os IPs bloqueados, próximo ao ponto 14, ocorreu por problemas no acesso a rede interna do NCC. Devido a problemas no roteador da UFSM, que estabelece o link com a RNP 4 em Porto Alegre, o acesso a rede esteve impossibilitado por mais de 1 hora, causando a liberação de todos os IPs bloqueados. Antes da queda podem ser observados os pontos de inatividade do roteador. Os pontos ligeiramente anteriores a queda permaneceram constantes, o que significa que não foram bloqueados e nem liberados endereços IP. A queda, no gráfico, ocorreu justamente na próxima rotação dos logs auxiliares do sistema. O gráfico 5 apresenta alguns intervalos de monitoramento entre os dias 2 e 27 de abril de 24. Dos três maiores picos, os dois primeiros representam o número de máquinas bloqueadas nas madrugadas de sexta para sábado (dia 23 para 24) e sábado para domingo (24 para 25). No intervalo 2 a 3 pode ser observado que a atividade cai bastante no sábado pela manhã e volta a aumentar na parte da tarde. Uma nova queda é detectada no início da noite e um novo pico surge na madrugada de sábado para domingo. Pode ser visualizada também uma queda média do intervalo 4 a 5 em relação ao intervalo 2 a 4. O intervalo 2 a 4 configura o final da semana, enquanto que o intervalo 4 a 5 apresenta os dados do início da semana seguinte. Essas taxas médias de IPs bloqueados, altas nos finais de semana e baixas na segunda e terça-feira, foram identificadas em praticamente todos os dados coletados. 16 numero de maquinas infratoras por dia 18 numero de maquinas infratoras por intervalo de tempo 14 16 numero de maquinas infratoras 12 1 8 6 4 2 5 1 15 2 25 3 dia do mes (maio de 24) numero de maquinas infratoras 14 12 1 8 6 4 2 mais de 1 infracoes mais de 2 infracoes mais de 4 infracoes legenda mais de 6 infracoes mais de 8 infracoes uma ou mais infracoes 2 4 6 8 1 12 14 16 18 2 das :3 do dia 1 as 2:9 do dia 3 de maio de 24 Figura 6: Variação do número de máquinas (IPs) Figura 7: Número de IPs bloqueados O gráfico 6 apresenta os resultados do monitoramento do mês de maio de 24. O comportamento visualizado nesse gráfico é semelhante ao comportamento detectado no gráfico 2. As amostragens dos dias 27 a 31 são um exemplo de como o tráfego da rede normalmente é não-determinístico e muitas vezes imprevisível. Neste caso, ocorreu uma queda contínua anormal (se comparada com os demais dias do mês) no número de má- 4 Rede Nacional de Pesquisa
quinas infratoras. No entanto, o número de IPs que cometeram mais de 4 infrações não seguiu o mesmo ritmo. Isso pode ser uma boa indicação de relativa estabilidade na definição do valor mínimo de infrações para que um endereço IP seja considerado uma provável ameaça a rede (e automaticamente bloqueado pelo sistema). Os dados do gráfico 7 foram extraídos com o sistema configurado para rastrear IPs que cometeram mais de 6 infrações. As duas quedas bruscas apresentam os mesmos sintomas e justificativas da queda apresentada, e comentada, no gráfico 4. Em relação aos gráficos anteriores, que utilizavam 4 infrações como um valor mínimo, houve um afrouxamento das restrições do sistema. Um dos objetivos dessa fase experimental é justamente tentar identificar valores mínimos o mais próximo possível do ideal para as características e perfis dos IPs que acessam a rede do NCC. Apesar de aumentar o número de 4 para 6 infrações, aparentemente não foram bloqueados menos máquinas "inocentes". A maior parte dessas máquinas "inocentes"figuram como mal configurações de seus sistemas ou estão infectadas por algum tipo de parasita eletrônico (mais conhecidos como worms e/ou vírus). No decorrer dos testes foram identificados alguns casos como o bloqueio de servidores externos de e-mail. Entretanto, analisando os logs pôde ser verificado que tentativas de conexão não autorizadas a máquinas e serviços haviam sido originadas desses servidores. Isso leva a concluir que esses servidores de e-mail estavam mal configurados ou infectados por algum tipo de parasita eletrônico. Além dos servidores de e-mail, algumas máquinas de usuários comuns também foram bloqueadas. Após a verificação e analise dos logs foram constatadas as mesmas características dos servidores de e-mail bloqueados. Como os servidores de e-mail, essas máquinas poderiam estar rodando serviços, ou estarem infectadas, sem o conhecimento do usuário. Esses serviços, ou parasitas, estavam realizando tentativas de conexão não autorizadas. 4. Trabalhos Relacionados Atualmente existem várias ferramentas que monitoram o comportamento da rede, filtrando pacotes, analisando logs e apresentando estatísticas de problemas e/ou acontecimentos que podem comprometer a segurança da rede. Algumas delas atuam de forma isolada e outras apresentam integrações e compatibilidades com ferramentas similares. Ferramentas como o fwanalog[1] e o fwlogwatch[15] possibilitam a análise e sumarização de logs de filtros de pacotes e sistemas de detecção de intrusão. Essas ferramentas não atuam no bloqueio, controle e intervenção de ataques. Elas apenas fornecem dados resumidos aos administradores de sistemas. Utilitários como o firestarter são destinados a configurar e proteger estações de trabalho contra ataques vindos da rede. Normalmente são ferramentas gráficas e relativamente amigáveis. Uma classe de ferramentas com uma semelhança maior com o sistema são utilitários como o firestorm[7], Snort[2] e prelude-nids[1]. Uma grande desvantagem desses sistemas é a relativa complexidade de opções de configuração que podem dificultar a vida do usuário. Ao contrário, o sistema aqui proposto visa tornar a vida dos administradores da rede o mais simples possível e ainda fornecer uma ferramenta com um bom nível de desempenho e pré-atividade na detecção e prevenção automática e dinâmica de ataques. Além disso, essas ferramentas são destinadas principalmente a detecção de intrusões. O objetivo do sistema proposto é construir uma ferramenta simples que atue de forma efici-
ente como um sistema de prevenção de intrusões e ataques. Outras pesquisas caminham para a criação de sistemas de alerta e sumarização baseados em políticas e regras de semelhança [8]. Diferentemente do protótipo aqui apresentado, que busca identificar e bloquear possíveis ataques ou ameaças contra a rede. Isso inclui a detecção e bloqueio de varreduras por porta e por faixa de IPs, por exemplo. 5. Conclusão A prevenção e detecção de possíveis ataques ou ações mal intencionadas em redes de computadores é algo necessário e útil. Sistemas desse gênero, mais conhecidos como IPS, buscam garantir a segurança e integridade da rede. O protótipo do sistema apresentado mostrou bons resultados na identificação e bloqueio de máquinas com uma boa probabilidade de figurarem entre origens de conexões maliciosas. A ferramenta identifica e bloqueia dinâmica e automaticamente endereços IPs que se enquadrarem na regras definidas pelo administrador. A configuração do sistema e das regras é bastante simples e rápida. Apesar dos resultados experimentais, maiores análises e testes são necessários. Identificar padrões de freqüência de conexões que figuram ataques a rede e identificar números mínimos de infrações que representem ao máximo apenas endereços de origem com alta probabilidade de serem ataques a rede são objetos de maior estudo e pesquisa. Contudo, apesar da fase inicial de testes, o sistema vem apresentando bons resultados. Analisando os logs de conexão das máquinas temporariamente bloqueadas, mais de 95% delas cometeram infrações que poderiam ser enquadradas em possíveis ataques a rede. Grande parte deste conjunto de máquinas estava praticando ações como escaneamento de portas e IPs da rede. Ações desse gênero normalmente são enquadradas como prévias para ataques em um futuro relativamente próximo. Trabalhos futuros. Entre as possibilidades de trabalhos futuros podem ser citados o desenvolvimento de um detector de ataques por padrões de freqüência de conexão e realização de mais testes com o protótipo inicial. Apesar do relativamente bom desempenho, identificar também pontos passíveis de otimização. Uma outra etapa é o projeto e implementação da configuração 2 do sistema (seção 2). Referências [1] Janet Casey. fwanalog - Parses and summarizes firewall logfiles, 2. http://www. gnu.org/directory/security/firewall/fwanalog.html. [2] Brian Caswell and Marty Roesch. Snort - The Open Source Network Intrusion Detection System, 22. http://www.snort.org/. [3] Thomas M. Eastep. Shorewall - Iptables Made Easy, 21. http://www. shorewall.net/. [4] Luigi Genoni. Knetfilter, 24. http://expansa.sns.it/knetfilter/. [5] gshield. gshield, 24. http://muse.linuxmafia.org/gshield/. [6] Hermann Hartig. Security architectures revisited, 22. citeseer.ist.psu.edu/ 531623.html. [7] John Leach and Gianni Tedesco. Firestorm NIDS, 24. http://www.scaramanga. co.uk/firestorm/index.html.
[8] Samir Lohmann, Cristina Melchiors, and Luciano Gaspary. Aplicando a Técnica de Racioncínio Baseado em Casos na Identificação de Cenários de Intrusão em Logs de Firewalls. In Anais da Segunda Escola Regional de Redes de Computadores (ERRC24), pages 19 114, 24. [9] NetCitadel LLC. Firewall Builder, 23. http://www.fwbuilder.org/. [1] Open Source Development Network. Prelude NIDS, 23. http://freshmeat. net/projects/preludenids/. [11] Adrian Pascalau. GIPTables Firewall, 22. http://www.giptables.org/. [12] O. Sami Saydjari. Cyber defense: art to science. Commun. ACM, 47(3):52 57, 24. [13] Daniel E. Testa. gtk-iptables, 23. http://gtk-iptables.sourceforge. net/. [14] Costa Tsaousis. FireHOL, 23. http://firehol.sourceforge.net/. [15] Boris Wesslowski. fwlogwatch, 24. http://fwlogwatch. inside-security.de/. [16] Michael E. Whitman. Enemy at the gate: threats to information security. Commun. ACM, 46(8):91 95, 23.