Proposta de uma Infraestrutura para Auxiliar no Controle de Ataques em Sistemas Interconectados

Transcrição

1 Proposta de uma Infraestrutura para Auxiliar no Controle de Ataques em Sistemas Interconectados Guilherme Linck 1, Rafael Righi 3, Diego Kreutz 1,2 1 Núcleo de Ciência da Computação NCC Universidade Federal de Santa Maria UFSM Campus UFSM Santa Maria RS Brasil 2 Universidade Luterana do Brasil, campus Santa Maria ULBRA SM Caixa Postal Santa Maria RS Brasil 3 Faculdade de Tecnologia SENAI Florianópolis - SENAI-SC Centro de Tecnologia em Automação e Informática (CTAI) Rodovia SC 401, n Florianópolis SC Brasil {linck,kreutz}@inf.ufsm.br, righi@ctai.senai.br Abstract. One networked system is always passive of internal and external attacks. Many attacks has not only one target in mind. It is very common a malicious action having as reference point as many systems as possible. This article presents the proposal of an infrastructure that is intended to improve protection options on interconnected systems. The main goals is to lead, as many systems as achievable, to a state of alert on the smallest time interval accomplishable. In this way, an attack may have a lower probability of achieving its goals on some of the target systems. Besides this contribution, the article presents a use case of the infrastructure as well as its analysis and evaluation. Resumo. Um sistema, conectado em rede, está sujeito tanto a ataques internos quanto externos. Muitos desses ataques não tem um único sistema como alvo, sendo comum uma ação maliciosa tentar extender-se pelo maior número possivel de sistemas. Este artigo apresenta uma proposta de infraestrutura para auxiliar na proteção contra ataques a sistemas interconectados. O objetivo principal é colocar o maior número de sistemas em estado de alerta no menor espaço de tempo possível. Desta forma, o ataque terá uma probabilidade menor de atingir seu objetivo em algum dos sistemas alvo. Além desta contribuição, o artigo apresenta um caso de uso da infraestrutura, bem como sua análise e avaliação. 1. Introdução Inicialmente, danos causados por ataques a redes de computadores deram origem a pesquisas que resultaram na primeira classe de sistemas de segurança, compreendida por sistemas de identificação de instrusão. Porém, com o passar do tempo e evolução dos ataques, os prejuízos se tornaram grandes demais para serem contornados, o que levou a pesquisas que deram origem à segunda classe de sistemas de segurança, conhecida por sistema de prevenção de instrusão. O uso em conjunto de ferramentas pertencentes a estas duas classes pode representar uma considerável melhoria na segurança em redes de computadores[holland 2004].

2 Baseando-se neste contexto, este artigo apresenta uma proposta de arquitetura, com a intenção de auxiliar no processo de defesa contra ataques, que tem como objetivo contribuir para o avanço dos mecanismos de ação preventiva contra ações maliciosas dirigidas a sistemas interconectados. A principal motivação para o desenvolvimento deste trabalho foi a praticamente inexistência de ferramentas de prevenção de instrusão que possuam a capacidade de compartilhar informações localmente coletadas, e compartilhá-las com sistemas semelhantes local ou geograficamente distribuídos, permitindo que estes tomem ações preventivas, e em alguns casos com uma certa antecedência, contra possíveis fututos ataques. A proposta básica da arquitetura é criar uma infra-estrutura que, além das atividades tradicionais de detecção e prevenção de intrusões, seja capaz de suprir os requisitos essenciais à troca de dados entre diferentes unidades federativas do ambiente de proteção distribuída e cooperativa contra intrusões em redes de computadores. Outro objetivo é criar unidades extensíveis e capazes de trabalhar em conjunto com soluções de proteção já existentes. Com isso em mente, cada unidade da federação é composta por 5 componentes: 1) módulo de análise de logs; 2) núcleo de controle de infrações; 3) módulo de compartilhamento de dados; 4) adaptador para entrada de dados de outras ferramentas; e 5) componente de notificação de domínios administrativos sobre a existência de máquinas suspeitas. A tarefa do primeiro conjunto de componentes é analisar logs de tráfego da rede, buscando identificar anomalias e prováveis inícios de ataques. Os dados considerados críticos são encaminhados para o núcleo de controle de infrações. Este, por sua vez, toma medidas necessárias para o controle dinâmico e automático de tráfego sobre as origens das informações duvidosas. Quando ações de controle de tráfego são tomadas em relação a um determinado conjunto de dados, estes são disponibilizados às demais unidades de controle da federação. Os componentes 4 e 5 são utilizados para receber dados de outras ferramentas de controle, aumentando o número de possibilidades na identificação de problemas ou ações maliciosas, e para a notificação dos administradores de domínios dos quais originaram os fluxos de dados considerados suspeitos, respetivamente. Com isso muitos administradores têm a possibilidade de tomar medidas corretivas em suas redes locais, evitando ao máximo que seus domínios sejam fontes de ataques contra sistemas de outras redes de computadores. O artigo está estruturado da seguinte forma: a seção seguinte contextualiza alguns trabalhos relacionados. A arquitetura proposta é apresentada na seção 3. Em seguida são apresentados alguns resultados preliminares relacionados a um caso de uso. Por fim, é inferida a conclusão e alguns trabalhos que darão continuidade a implementação, testes, validação e operacionalização da arquitetura por completo. 2. Trabalhos Relacionados Existem duas classes de ferramentas relacionadas à segurança em redes de computadores: sistemas de deteção de intrusões (IDS) 1 e sistemas de prevenção de intrusões (IPS) 2. Um IDS monitora um segmento da rede, um servidor ou uma aplicação em um determinado servidor em busca de assinaturas de acessos não autorizados, alertando o profissional responsável quando identificar uma invasão[fitzgerald and Dennis 2002]. 1 Derivado da expressão inglesa Intrusion Detection System. 2 Derivado da expressão inglesa Intrusion Prevention System.

3 Os IPSs podem ser considerados uma evolução dos IDSs. São sistemas que analisam máquinas ou o tráfego da rede em busca de padrões que venham a caracterizar tentativas de ataque. Ao localizar uma atividade suspeita, o sistema toma, automaticamente, medidas para tentar evitar que o ataque seja bem sucedido[holland 2004]. A arquitetura aqui proposta tem como abordagem principal a prevenção, de forma distribuída/colaborativa, de intrusões a redes de computadores ou sistemas locais. 3. A Arquitetura Proposta A infraestrutura proposta tem por objetivo definir uma federação (unidades federativas colaborando individualmente e em conjunto) para a combate de ações suspeitas ou mal intencionadas contra sistemas interconectados. A idéia é que diferentes máquinas (firewalls, servidores ou estações de trabalho) ou unidades distribuídas geograficamente possam cooperar no controle à proliferação de ataques. Uma das características da infraestrutura consiste na troca de informações que possam ser úteis para previnir ataques que estejam acontecendo em um local em específico e que possam vir a ocorrer em outras unidades. Entre as metas da proposta está a manutenção da arquitetura tradicional de sistemas de segurança, como filtros de pacotes, acrescentando módulos auxiliares que irão incrementar funcionalidade nesses sistemas de modo a impedir, protelar, ou desviar o fluxo de dados (que pode ser uma tentativa de ataque) de endereços suspeitos. Complementando, objetiva-se utilizar diferentes ferramentas e técnicas que venham a contribuir na identificação e notificação de ações suspeitas contra redes de computadores. Neste cenário, entram os mais diversos tipos de sistemas de detecção e prevenção de intrusões, mecanismos de co-relacionamento de alarmes, ferramentas de análise de logs, entre outros. A Figura 1 apresenta uma visão geral da base do sistema. Esta é composta por: (1) um filtro de pacotes; (2) um arquivo de registros de atividade sobre as políticas de acesso ou tráfego na rede; (3) um analisador de logs; (4) um monitor de atividades (e gerenciador de políticas de controle de acesso e roteamento do filtro de pacotes) selecionadas pelo analisador de logs ou por outras ferramentas de detecção e notificação de atividades suspeitas; (5) outras fontes de dados, ou seja, dados provenientes de ferramentas de detecção, correlação de alarmes, entre outras e (6) troca de dados entre unidades localizadas em diferentes pontos de uma mesma rede ou em redes distintas. Troca de Máquina 5 Fontes de bloqueio e 6 Filtro de Pacotes liberação de IPs 4 MONITOR 3 Analisador de Logs 1 Logs do 2 Filtro de Pacotes IPs 5 monitorados 1 2 IPs 3 bloqueados Figura 1. Visão geral do sistema em uma máquina Os quatro primeiros componentes executam na mesma máquina. Esta pode ser

4 uma simples estação de trabalho, um servidor ou um firewall da rede. O quinto componente pode ser um coletor de informações residente em diferentes máquinas da rede. Estas informações, neste caso, são encaminhadas através da rede ao elemento monitor. O sexto componente é utilizado para efetuar troca de dados entre diferentes unidades de monitoramento do sistema. Com mais este recurso, espera-se incrementar a capacidade de previsão das diferentes unidades de prevenção de intrusão. Os dados das unidades servirão também para alimentar o controle de prevenção de intrusões (monitor) das demais unidades. Com isso, um ataque em andamento, detectado em uma das unidades, será imediatamente notificado às demais unidades do sistema. O objetivo do sistema é tentar identificar e bloquear máquinas suspeitas, que possam ser prováveis atacantes à rede. Através da análise das tentativas de conexões não autorizadas [Kreutz 2004] o monitor irá classificar os computadores, tanto da rede externa quanto da rede interna. Todos os endereços IPs das máquinas que infringiram alguma regra do filtro de pacotes são colocadas em uma tabela de monitoramento. A partir desse ponto, o monitor começa a analisar o número e a freqüência de conexões não autorizadas de cada endereço de origem. A meta é identificar endereços com uma alta probabilidade de serem fontes de futuros ataques e bloqueá-los, ou desviá-los a um honeypot [Provos 2004, Kuwatly et al. 2004]. A partir dos dados coletados pela analisador de logs, uma máquina é considerada suspeita quando atingir o limite máximo de infrações permitidas [Kreutz 2004]. Neste caso, infrações estão relacionadas às entradas do arquivo de logs que registram tentativas de conexões negadas(não autorizadas) a serviços ou máquinas. Outra forma de um IP ser enquadrado como uma possível ameaça à rede é quando a probabilidade é bastante grande de o endereço de origem estar realizando uma varredura de portas ou máquinas da rede. Uma terceira maneira de um endereço ser considerado suspeito é quando sua atividade denota freqüências ou comportamentos de tempos de conexão (seguindo regras autorizadas) constantes, anômalos, ou reconhecidas como táticas de invasão (a partir da análise de casos anteriores). Neste contexto entrarão também identificação de ataques e anomalias através da análise e comparação de assinaturas conhecidas, que é um dos métodos utilizados por ferramentas como o Snort [Caswell and Roesch 2004]. Com essa infraestrutura espera-se impedir que muitos ataques sejam iniciados, prossigam ou tenham sucesso em diferentes unidades federativas de uma mesma organização, estejam estas em uma mesma rede local ou geograficamente distribuídas. Um ataque de negação de serviço (DoS), por exemplo, assim que detectado por uma das unidades do sistema avisaria as demais para se previnirem com antecedência. Esse poderia ser o caso de um ataque contra servidores de DNS de uma rede. Assim que o primeiro for atacado, o servidor secundário é notificado e imediatamente se prepara contra um possível ataque Controle Cooperativo Uma característica do trabalho aqui apresentado é a capacidade de permitir a prevenção cooperativa entre as instâncias do sistema. Em outras palavras, possibilitar o bloqueio não somente de atacantes identificados localmente, mas também os que forem identificados pelos sistemas remotos. Para isso, a detecção de um endereço suspeito deverá ser compartilhada entre os

5 monitores, possibilitando uma ação conjunta e mais efetiva, evitando possíveis futuros ataques e reduzindo a eficácia de ataques em andamento. A Figura 2 ilustra a arquitetura de prevenção e controle cooperativo de intrusões. Utilizando essa arquitetura em uma rede local, o êxito de atividades maliciosas internas à rede pode ser reduzido significativamente. Sabe-se que os ataques mais perigosos comumentemente são os internos [Holland 2004], principalmente quando se tratam de tentativas de acesso não autorizadas.logo, mecanismos que auxiliam no controle cooperativo das diretivas de segurança de servidores e máquinas da rede podem ser uma boa política para aumentar a efetividade na prevenção e combate desses ataques. Unidade01 Rede/Internet MONITOR (Analisador de Logs) bloqueio e liberação de IPs Filtro de Pacotes Compartilhamento de de Monitoramento Logs do Filtro de Pacotes Unidade02 Unidade03 MONITOR (Analisador de Logs) bloqueio e liberação de IPs Filtro de Pacotes MONITOR (Analisador de Logs) bloqueio e liberação de IPs Filtro de Pacotes de Monitoramento Logs do Filtro de Pacotes de Monitoramento Logs do Filtro de Pacotes Figura 2. Visão geral do sistema em uma rede A inclusão de um IP na lista de observação, em um dos pontos de prevenção de intrusões, irá levar ao monitoramento deste endereço em todos os pontos que fazem parte do sistema cooperativo de prevenção contra ataques. compartilhados. Os dados compartilhados entre as diferentes unidades podem ser armazenados em uma base de dados. Esta pode ser centralizada ou distribuída. A segunda opção pode ser a mais consistente, neste caso, utilizando também replicação. Isso irá prevenir, no caso de um ataque de negação de serviço, que o compartilhamento de informações entre os monitores seja interrompido. A não conectividade das unidades com a base de dados central implica na imediata tentativa de conexão com as réplicas, disponíveis nas demais unidades do sistema Exemplo de Aplicação A figura 3 apresenta um caso de uso da arquitetura cooperativa. configuração com algumas unidades espalhadas geograficamente. É ilustrada uma Cada unidade contém um ponto central de controle de acesso à rede privada. O monitoramento é realizado sobre os logs do filtro de pacote dos pontos de acesso. Uma cópia atualizada das tabelas de infratores é mantida na base de dados distribuída e replicada, acessível de forma transparente por todos os módulos do sistema, permitindo o compartilhamento de informações entre as filiais.

6 Alegrete Bagé UNIDADE 03 UNIDADE 01 Uruguaiana UNIDADE 02 Internet Compartilhados Santa Maria UNIDADE 05 UNIDADE 04 Livramento Figura 3. Ilustração de aplicação em diferentes redes locais A detecção de um provável ataque em uma das unidades irá ser propagada para as demais. Com isso, tentativas de ataques subseqüentes podem ser evitadas. Os sistemas de segurança podem ser colocados em estado de alerta mesmo antes de qualquer monitoramento suspeito local ter sido identificado. Com isso, um ataque inicial, que visasse a propagação para as demais unidades da rede privada de uma corporação, seria rapidamente denunciado, tendo suas possibilidades de continuidade ou sucesso bastante reduzidas. A Figura 4 representa um segundo cenário de aplicação. Neste caso, as unidades de cooperação são os servidores, firewall e demais máquinas de uma mesma rede. O ataque a uma das máquinas da arquitetura irá notificar as demais. Estas estão prontas a possível subsequentes ataques. Rede Interna (Área de compartilhamento de dado) Firewall01 Servidor02 Servidor03 Compartilhados Servidor01 Figura 4. Ilustração de aplicação em uma rede interna 4. Avaliação da Ferramenta Os objetivos do teste realizado foram comprovar o correto funcionamento do analisador de logs em conjunto com o módulo monitor, das ações tomadas pelo pelo monitor em relação a endereços IPs considerados suspeitos, assim como a correta troca de informações entre as duas unidades de monitoramento utilizadas durante o teste. Os resultados encontrados são exibidos na Tabela 1. Para a avaliação da arquitetura proposta foram utilizadas duas máquinas: (1) AthlonXP 1.6 GHz, 768 MB DDR 266MHz, disco IDE com rotação de 7200 RPM; (2) Ath-

7 Monitor Bloqueios Liberações Notificações Recebidas Uso médio da CPU % % Tabela 1. Resultados da avaliação preliminar. lonxp 1.66 GHz, 512MB DDR 333 MHz, disco IDE com rotação de 7200 RPM. O computador 1 utiliza a distribuição Gentoo Linux com kernel 2.4, enquanto que o 2 utiliza a distribuição Ubuntu com kernel 2.6. O teste utilizou arquivos de log do firewall da rede do NCC 3 da UFSM. O objetivo principal foi analisar o mecanismo de troca de informações entre unidades de monitoramento, visto que o correto funcionamento do analisador de logs foi certificado durante a sua implementação. Foram utilizados dois arquivos distintos de log, colocando um em cada máquina, correspondentes à 24 horas de registros do tráfego da rede. Os dois monitores foram então ativados, iniciando processos de busca por máquinas suspeitas e troca de informações. No computador 1 o arquivo continha 422MB de registros e o monitor executou durante 4 minutos e 32 segundos. Já na máquina 2 foi utilizado um arquivo com 353MB de logs e teve sua análise realizada em 6 minutos e 3 segundos. Cabe ressaltar que quando implantado o monitoramento será realizado em tempo real, obtendo os dados de entrada para análise assim que registrados no arquivo de log. Como consequência, o uso médio da CPU será reduzido significativamente, pois o volume de informações processadas na unidade de tempo sofrerá uma expressiva redução. 5. Conclusão Esforços na pesquisa e desenvolvimento de sistemas que incrementem a segurança das redes de computadores são exigidos na medida em que ambientes seguros tornam-se cada vez mais importantes. A arquitetura aqui proposta vem contribuir para o avanço neste sentido. A infraestrutura proposta tem por objetivo auxiliar no controle e combate a ações, potencialmente perigosas, contras sistemas interconectados. A possibilidade de os monitores, elementos centrais da infraestrutura, funcionarem de forma cooperativa torna seu uso interessante nos mais diversos cenários. Alguns destes cenários foram ilustrados durante a apresentação da proposta de infraestrutura, implementação do protótipo e resultados preliminares. Os resultados dos testes práticos iniciais foram demonstrados, comprovando o funcionamento básico do sitema. Apesar de sua fase inicial, o sistema demonstra poder trazer benefícios para ambientes onde busca-se proteger não apenas um elemento, ou conjunto de elementos, mas sim as mais diversas unidades críticas da infraestrutura conectada em rede. A cooperação entre as diferentes máquinas (ou mesmo sub-redes) na prevenção contra intrusões pode ser uma valiosa arma contra infratores da rede, tanto externos quanto internos. Para dar continuidade ao aprimoramento e testes da infraestrutura proposta, a seguir são listados alguns trabalhos futuros: (1) melhoramentos na arquitetura e 3 NCC - Núcleo de Ciência da Computação.

8 implementação; (2) desenvolvimento de ferramentas para a visualização de estatísticas dos índices do sistema; (3) inclusão de mecanismos para o suporte à entrada de dados de outros sistemas de monitoramento, correlação de alarmes e detecção de intrusões; (4) inclusão de mecanismos para a identificação de padrões de ataque em conexões de rede que passam pelo filtro de pacotes; (5) testes com múltiplos monitores em redes distintas; (6) testes de desempenho e atividade em várias máquinas (servidores, firewalls, estações de trabalho) de uma mesma rede; (7) adaptar o sistema para o suporte e outros filtros de pacotes, como o ebtables; (8) mecanismos de segurança para elevar o grau de confiança nas informações passadas por monitores vizinhos. Referências Caswell, B. and Roesch, M. (2004). Snort - The Open Source Network Intrusion Detection System. Último acesso: maio de Fitzgerald, J. and Dennis, A. (2002). Business Data Communications and Networking. John Wiley and Sons, Inc. Holland, T. (2004). Understanding IPS and IDS: Using IPS and IDS together for Defense in Depth. php. Último acesso: maio de Kreutz, D. (2004). Controle Independente de Restrições de Acesso a Redes em Firewalls que Utilizam o IPTables. In III Simpósio de Informática da Região Centro do RS. UNIFRA. Kuwatly, I., Sraj, M., Masri, Z. A., and Artail, H. (2004). A dynamic honeypot design for intrusion detection. In ICPS, pages Provos, N. (2004). A virtual honeypot framework. In USENIX Security Symposium, pages 1 14.