Proposta de uma Infraestrutura para Auxiliar no Controle de
Ataques em Sistemas Interconectados
Guilherme Linck1
, Rafael Righi3
, Diego Kreutz1 ,2
1
N´ucleo de Ciˆencia da Computac¸˜ao — NCC Universidade Federal de Santa Maria — UFSM Campus UFSM – 97105-900 – Santa Maria – RS – Brasil
2
Universidade Luterana do Brasil, campus Santa Maria — ULBRA SM Caixa Postal 15.064 – 91.501-970 – Santa Maria – RS – Brasil
3
Faculdade de Tecnologia SENAI Florian ´opolis - SENAI-SC Centro de Tecnologia em Automac¸˜ao e Inform´atica (CTAI) Rodovia SC 401, n. 3730 – 88032-005 – Florian ´opolis – SC – Brasil
{linck,kreutz}@inf.ufsm.br, righi@ctai.senai.br
Abstract. One networked system is always passive of internal and external
at-tacks. Many attacks has not only one target in mind. It is very common a mali-cious 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 ´a sujeito tanto a ataques internos
quanto externos. Muitos desses ataques n ˜ao tem um ´unico sistema como alvo, sendo comum uma ac¸ ˜ao maliciosa tentar extender-se pelo maior n ´umero pos-sivel de sistemas. Este artigo apresenta uma proposta de infraestrutura para auxiliar na protec¸ ˜ao contra ataques a sistemas interconectados. O objetivo principal ´e colocar o maior n ´umero de sistemas em estado de alerta no menor espac¸o de tempo poss´ıvel. Desta forma, o ataque ter ´a uma probabilidade menor de atingir seu objetivo em algum dos sistemas alvo. Al´em desta contribuic¸ ˜ao, o artigo apresenta um caso de uso da infraestrutura, bem como sua an ´alise e avaliac¸˜ao.
1. Introduc¸˜ao
Inicialmente, danos causados por ataques a redes de computadores deram origem a pes-quisas que resultaram na primeira classe de sistemas de seguranc¸a, compreendida por sistemas de identificac¸˜ao de instrus˜ao. Por´em, com o passar do tempo e evoluc¸˜ao dos ataques, os preju´ızos se tornaram grandes demais para serem contornados, o que levou a pesquisas que deram origem `a segunda classe de sistemas de seguranc¸a, conhecida por sistema de prevenc¸˜ao de instrus˜ao. O uso em conjunto de ferramentas pertencentes a es-tas duas classes pode representar uma consider´avel melhoria na seguranc¸a em redes de computadores[Holland 2004].
Baseando-se neste contexto, este artigo apresenta uma proposta de arquitetura, com a intenc¸˜ao de auxiliar no processo de defesa contra ataques, que tem como objetivo contribuir para o avanc¸o dos mecanismos de ac¸˜ao preventiva contra ac¸ ˜oes maliciosas di-rigidas a sistemas interconectados. A principal motivac¸˜ao para o desenvolvimento deste trabalho foi a praticamente inexistˆencia de ferramentas de prevenc¸˜ao de instrus˜ao que pos-suam a capacidade de compartilhar informac¸ ˜oes localmente coletadas, e compartilh´a-las com sistemas semelhantes local ou geograficamente distribu´ıdos, permitindo que estes to-mem ac¸˜oes preventivas, e em alguns casos com uma certa antecedˆencia, contra poss´ıveis fututos ataques.
A proposta b´asica da arquitetura ´e criar uma infra-estrutura que, al´em das ativida-des tradicionais de detecc¸˜ao e prevenc¸˜ao de intrus˜oes, seja capaz de suprir os requisitos essenciais `a troca de dados entre diferentes unidades federativas do ambiente de protec¸ ˜ao distribu´ıda e cooperativa contra intrus ˜oes em redes de computadores. Outro objetivo ´e criar unidades extens´ıveis e capazes de trabalhar em conjunto com soluc¸ ˜oes de protec¸˜ao j´a existentes. Com isso em mente, cada unidade da federac¸˜ao ´e composta por 5 com-ponentes: 1) m ´odulo de an´alise de logs; 2) n ´ucleo de controle de infrac¸ ˜oes; 3) m´odulo de compartilhamento de dados; 4) adaptador para entrada de dados de outras ferramen-tas; e 5) componente de notificac¸˜ao de dom´ınios administrativos sobre a existˆencia de m´aquinas suspeitas. A tarefa do primeiro conjunto de componentes ´e analisar logs de tr´afego da rede, buscando identificar anomalias e prov´aveis in´ıcios de ataques. Os da-dos considerada-dos cr´ıticos s˜ao encaminhada-dos para o n ´ucleo de controle de infrac¸ ˜oes. Este, por sua vez, toma medidas necess´arias para o controle dinˆamico e autom´atico de tr´afego sobre as origens das informac¸ ˜oes duvidosas. Quando ac¸ ˜oes de controle de tr´afego s˜ao tomadas em relac¸˜ao a um determinado conjunto de dados, estes s˜ao disponibilizados `as demais unidades de controle da federac¸˜ao. Os componentes 4 e 5 s˜ao utilizados para rece-ber dados de outras ferramentas de controle, aumentando o n ´umero de possibilidades na identificac¸˜ao de problemas ou ac¸ ˜oes maliciosas, e para a notificac¸˜ao dos administradores de dom´ınios dos quais originaram os fluxos de dados considerados suspeitos, respetiva-mente. Com isso muitos administradores tˆem a possibilidade de tomar medidas corretivas em suas redes locais, evitando ao m´aximo que seus dom´ınios sejam fontes de ataques contra sistemas de outras redes de computadores.
O artigo est´a estruturado da seguinte forma: a sec¸˜ao seguinte contextualiza alguns trabalhos relacionados. A arquitetura proposta ´e apresentada na sec¸˜ao 3. Em seguida s˜ao apresentados alguns resultados preliminares relacionados a um caso de uso. Por fim, ´e inferida a conclus˜ao e alguns trabalhos que dar˜ao continuidade a implementac¸˜ao, testes, validac¸˜ao e operacionalizac¸˜ao da arquitetura por completo.
2. Trabalhos Relacionados
Existem duas classes de ferramentas relacionadas `a seguranc¸a em redes de computadores: sistemas de detec¸˜ao de intrus˜oes (IDS)1e sistemas de prevenc¸˜ao de intrus˜oes (IPS)2.
Um IDS monitora um segmento da rede, um servidor ou uma aplicac¸˜ao em um determinado servidor em busca de assinaturas de acessos n˜ao autorizados, alertando o profissional respons´avel quando identificar uma invas˜ao[Fitzgerald and Dennis 2002].
1Derivado da express˜ao inglesa Intrusion Detection System. 2Derivado da express˜ao inglesa Intrusion Prevention System.
Os IPSs podem ser considerados uma evoluc¸˜ao dos IDSs. S˜ao sistemas que ana-lisam m´aquinas ou o tr´afego da rede em busca de padr ˜oes que venham a caracterizar ten-tativas 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 prevenc¸ ˜ao, de forma distribu´ıda/colaborativa, de intrus ˜oes a redes de computadores ou sistemas locais.
3. A Arquitetura Proposta
A infraestrutura proposta tem por objetivo definir uma federac¸˜ao (unidades federativas colaborando individualmente e em conjunto) para a combate de ac¸ ˜oes suspeitas ou mal in-tencionadas contra sistemas interconectados. A id´eia ´e que diferentes m´aquinas (firewalls, servidores ou estac¸ ˜oes de trabalho) ou unidades distribu´ıdas geograficamente possam co-operar no controle `a proliferac¸˜ao de ataques. Uma das caracter´ısticas da infraestrutura consiste na troca de informac¸ ˜oes que possam ser ´uteis 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 a manutenc¸˜ao da arquitetura tradicional de sis-temas de seguranc¸a, como filtros de pacotes, acrescentando m ´odulos auxiliares que ir˜ao incrementar funcionalidade nesses sistemas de modo a impedir, protelar, ou desviar o fluxo de dados (que pode ser uma tentativa de ataque) de enderec¸os suspeitos. Comple-mentando, objetiva-se utilizar diferentes ferramentas e t´ecnicas que venham a contribuir na identificac¸˜ao e notificac¸˜ao de ac¸˜oes suspeitas contra redes de computadores. Neste cen´ario, entram os mais diversos tipos de sistemas de detecc¸˜ao e prevenc¸˜ao de intrus˜oes, mecanismos de co-relacionamento de alarmes, ferramentas de an´alise de logs, entre ou-tros.
A Figura 1 apresenta uma vis˜ao geral da base do sistema. Esta ´e composta por: (1) um filtro de pacotes; (2) um arquivo de registros de atividade sobre as pol´ıticas de acesso ou tr´afego 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) seleci-onadas pelo analisador de logs ou por outras ferramentas de detecc¸˜ao e notificac¸˜ao de atividades suspeitas; (5) outras fontes de dados, ou seja, dados provenientes de ferramen-tas de detecc¸˜ao, correlac¸˜ao de alarmes, entre outras e (6) troca de dados entre unidades localizadas em diferentes pontos de uma mesma rede ou em redes distintas.
1 de Logs Analisador 3 Filtro de Pacotes Logs do 2 MONITOR 1 2 3 Fontes de Dados 5
6 bloqueio e Filtro de Pacotes
liberação de IPs Máquina 4 IPs 1 2 3 4 5
monitorados bloqueadosIPs
Troca de Dados
Figura 1. Vis ˜ao geral do sistema em uma m ´aquina
uma simples estac¸˜ao de trabalho, um servidor ou um firewall da rede. O quinto com-ponente pode ser um coletor de informac¸ ˜oes residente em diferentes m´aquinas da rede. Estas informac¸ ˜oes, neste caso, s˜ao encaminhadas atrav´es da rede ao elemento monitor.
O sexto componente ´e utilizado para efetuar troca de dados entre diferentes uni-dades de monitoramento do sistema. Com mais este recurso, espera-se incrementar a capacidade de previs˜ao das diferentes unidades de prevenc¸˜ao de intrus˜ao. Os dados das unidades servir˜ao tamb´em para alimentar o controle de prevenc¸˜ao de intrus˜oes (moni-tor) das demais unidades. Com isso, um ataque em andamento, detectado em uma das unidades, ser´a imediatamente notificado `as demais unidades do sistema.
O objetivo do sistema ´e tentar identificar e bloquear m´aquinas suspeitas, que pos-sam ser prov´aveis atacantes `a rede. Atrav´es da an´alise das tentativas de conex ˜oes n˜ao au-torizadas [Kreutz 2004] o monitor ir´a classificar os computadores, tanto da rede externa quanto da rede interna. Todos os enderec¸os IPs das m´aquinas que infringiram alguma regra do filtro de pacotes s˜ao colocadas em uma tabela de monitoramento. A partir desse ponto, o monitor comec¸a a analisar o n ´umero e a freq¨uˆencia de conex˜oes n˜ao autoriza-das de cada enderec¸o de origem. A meta ´e identificar enderec¸os com uma alta proba-bilidade de serem fontes de futuros ataques e bloque´a-los, ou desvi´a-los a um honeypot [Provos 2004, Kuwatly et al. 2004].
A partir dos dados coletados pela analisador de logs, uma m´aquina ´e considerada suspeita quando atingir o limite m´aximo de infrac¸ ˜oes permitidas [Kreutz 2004]. Neste caso, infrac¸ ˜oes est˜ao relacionadas `as entradas do arquivo de logs que registram tentativas de conex˜oes negadas(n˜ao autorizadas) a servic¸os ou m´aquinas. Outra forma de um IP ser enquadrado como uma poss´ıvel ameac¸a `a rede ´e quando a probabilidade ´e bastante grande de o enderec¸o de origem estar realizando uma varredura de portas ou m ´aquinas da rede. Uma terceira maneira de um enderec¸o ser considerado suspeito ´e quando sua atividade denota freq ¨uˆencias ou comportamentos de tempos de conex˜ao (seguindo regras autorizadas) constantes, an ˆomalos, ou reconhecidas como t´aticas de invas˜ao (a partir da an´alise de casos anteriores). Neste contexto entrar˜ao tamb´em identificac¸˜ao de ataques e anomalias atrav´es da an´alise e comparac¸˜ao de assinaturas conhecidas, que ´e um dos m´etodos utilizados por ferramentas como o Snort [Caswell and Roesch 2004].
Com essa infraestrutura espera-se impedir que muitos ataques sejam inicia-dos, prossigam ou tenham sucesso em diferentes unidades federativas de uma mesma organizac¸˜ao, estejam estas em uma mesma rede local ou geograficamente distribu´ıdas. Um ataque de negac¸˜ao de servic¸o (DoS), por exemplo, assim que detectado por uma das unidades do sistema avisaria as demais para se previnirem com antecedˆencia. Esse pode-ria ser o caso de um ataque contra servidores de DNS de uma rede. Assim que o primeiro for atacado, o servidor secund´ario ´e notificado e imediatamente se prepara contra um poss´ıvel ataque.
3.1. Controle Cooperativo
Uma caracter´ıstica do trabalho aqui apresentado ´e a capacidade de permitir a prevenc¸˜ao cooperativa entre as instˆancias do sistema. Em outras palavras, possibilitar o bloqueio n˜ao somente de atacantes identificados localmente, mas tamb´em os que forem identificados pelos sistemas remotos.
monitores, possibilitando uma ac¸˜ao conjunta e mais efetiva, evitando poss´ıveis futuros ataques e reduzindo a efic´acia de ataques em andamento. A Figura 2 ilustra a arquitetura de prevenc¸˜ao e controle cooperativo de intrus ˜oes.
Utilizando essa arquitetura em uma rede local, o ˆexito de atividades maliciosas internas `a rede pode ser reduzido significativamente. Sabe-se que os ataques mais peri-gosos comumentemente s˜ao os internos [Holland 2004], principalmente quando se tratam de tentativas de acesso n˜ao autorizadas.Logo, mecanismos que auxiliam no controle coo-perativo das diretivas de seguranc¸a de servidores e m´aquinas da rede podem ser uma boa pol´ıtica para aumentar a efetividade na prevenc¸˜ao e combate desses ataques.
(Analisador de Logs) (Analisador de Logs) (Analisador de Logs) Rede/Internet de Dados Compartilhamento Filtro de Pacotes liberação de IPs bloqueio e Logs do Filtro de Pacotes Monitoramento Dados de Filtro de Pacotes liberação de IPs bloqueio e Logs do Filtro de Pacotes Monitoramento Dados de Filtro de Pacotes liberação de IPs bloqueio e Logs do Filtro de Pacotes Monitoramento Dados de Unidade01 Unidade02 Unidade03 MONITOR MONITOR MONITOR
Figura 2. Vis ˜ao geral do sistema em uma rede
A inclus˜ao de um IP na lista de observac¸˜ao, em um dos pontos de prevenc¸˜ao de intrus˜oes, ir´a levar ao monitoramento deste enderec¸o em todos os pontos que fazem parte do sistema cooperativo de prevenc¸˜ao contra ataques.
Dados 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 opc¸˜ao pode ser a mais consistente, neste caso, utilizando tamb´em replicac¸˜ao. Isso ir´a prevenir, no caso de um ataque de negac¸˜ao de servic¸o, que o compartilhamento de informac¸ ˜oes entre os monitores seja interrompido. A n˜ao conectividade das unidades com a base de dados central implica na imediata tentativa de conex˜ao com as r´eplicas, dispon´ıveis nas demais unidades do sistema.
3.2. Exemplo de Aplicac¸ ˜ao
A figura 3 apresenta um caso de uso da arquitetura cooperativa. E ilustrada uma´ configurac¸˜ao com algumas unidades espalhadas geograficamente.
Cada unidade cont´em um ponto central de controle de acesso `a rede privada. O monitoramento ´e realizado sobre os logs do filtro de pacote dos pontos de acesso. Uma c´opia atualizada das tabelas de infratores ´e mantida na base de dados distribu´ıda e re-plicada, acess´ıvel de forma transparente por todos os m ´odulos do sistema, permitindo o compartilhamento de informac¸ ˜oes entre as filiais.
UNIDADE 04 Livramento UNIDADE 01 Alegrete UNIDADE 03 Bagé UNIDADE 05 Santa Maria UNIDADE 02 Uruguaiana Internet Locais Locais Locais Locais Locais Dados Dados Dados Dados Dados Compartilhados Dados
Figura 3. Ilustrac¸ ˜ao de aplicac¸ ˜ao em diferentes redes locais
A detecc¸˜ao de um prov´avel ataque em uma das unidades ir´a ser propagada para as demais. Com isso, tentativas de ataques subseq ¨uentes podem ser evitadas. Os sis-temas de seguranc¸a podem ser colocados em estado de alerta mesmo antes de qualquer monitoramento suspeito local ter sido identificado. Com isso, um ataque inicial, que vi-sasse a propagac¸˜ao para as demais unidades da rede privada de uma corporac¸˜ao, seria rapidamente denunciado, tendo suas possibilidades de continuidade ou sucesso bastante reduzidas.
A Figura 4 representa um segundo cen´ario de aplicac¸˜ao. Neste caso, as unidades de cooperac¸˜ao s˜ao os servidores, firewall e demais m´aquinas de uma mesma rede. O ataque a uma das m´aquinas da arquitetura ir´a notificar as demais. Estas est˜ao prontas a poss´ıvel subsequentes ataques.
Rede Interna
Servidor03
Firewall01 Servidor02
Servidor01 (Área de compartilhamento de dado)
Dados Locais Locais Dados Dados Locais Dados Locais Compartilhados Dados
Figura 4. Ilustrac¸ ˜ao de aplicac¸ ˜ao em uma rede interna
4. Avaliac¸˜ao da Ferramenta
Os objetivos do teste realizado foram comprovar o correto funcionamento do analisa-dor de logs em conjunto com o m ´odulo monitor, das ac¸ ˜oes tomadas pelo pelo moni-tor em relac¸˜ao a enderec¸os IPs considerados suspeitos, assim como a correta troca de informac¸˜oes entre as duas unidades de monitoramento utilizadas durante o teste. Os re-sultados encontrados s˜ao exibidos na Tabela 1.
Para a avaliac¸˜ao da arquitetura proposta foram utilizadas duas m´aquinas: (1) lonXP 1.6 GHz, 768 MB DDR 266MHz, disco IDE com rotac¸˜ao de 7200 RPM; (2)
Ath-Monitor Bloqueios Liberac¸ ˜oes Notificac¸˜oes Recebidas Uso m´edio da CPU
1 2338 1915 87 40%
2 2353 2232 134 65%
Tabela 1. Resultados da avaliac¸ ˜ao preliminar.
lonXP 1.66 GHz, 512MB DDR 333 MHz, disco IDE com rotac¸˜ao de 7200 RPM. O com-putador 1 utiliza a distribuic¸˜ao Gentoo Linux com kernel 2.4, enquanto que o 2 utiliza a distribuic¸˜ao Ubuntu com kernel 2.6.
O teste utilizou arquivos de log do firewall da rede do NCC3da UFSM. O objetivo principal foi analisar o mecanismo de troca de informac¸ ˜oes entre unidades de monitora-mento, visto que o correto funcionamento do analisador de logs foi certificado durante a sua implementac¸˜ao.
Foram utilizados dois arquivos distintos de log, colocando um em cada m ´aquina, correspondentes `a 24 horas de registros do tr´afego da rede. Os dois monitores foram ent˜ao ativados, iniciando processos de busca por m´aquinas suspeitas e troca de informac¸ ˜oes. No computador 1 o arquivo continha 422MB de registros e o monitor executou durante 4 minutos e 32 segundos. J´a na m´aquina 2 foi utilizado um arquivo com 353MB de logs e teve sua an´alise realizada em 6 minutos e 3 segundos.
Cabe ressaltar que quando implantado o monitoramento ser´a realizado em tempo real, obtendo os dados de entrada para an´alise assim que registrados no arquivo de log. Como consequˆencia, o uso m´edio da CPU ser´a reduzido significativamente, pois o volume de informac¸ ˜oes processadas na unidade de tempo sofrer´a uma expressiva reduc¸˜ao.
5. Conclus˜ao
Esforc¸os na pesquisa e desenvolvimento de sistemas que incrementem a seguranc¸a das redes de computadores s˜ao exigidos na medida em que ambientes seguros tornam-se cada vez mais importantes. A arquitetura aqui proposta vem contribuir para o avanc¸o neste sentido.
A infraestrutura proposta tem por objetivo auxiliar no controle e combate a ac¸ ˜oes, potencialmente perigosas, contras sistemas interconectados. A possibilidade de os mo-nitores, elementos centrais da infraestrutura, funcionarem de forma cooperativa torna seu uso interessante nos mais diversos cen´arios. Alguns destes cen´arios foram ilustra-dos durante a apresentac¸˜ao da proposta de infraestrutura, implementac¸˜ao do prot´otipo e resultados preliminares. Os resultados dos testes pr´aticos iniciais foram demonstrados, comprovando o funcionamento b´asico do sitema.
Apesar de sua fase inicial, o sistema demonstra poder trazer benef´ıcios para am-bientes onde busca-se proteger n˜ao apenas um elemento, ou conjunto de elementos, mas sim as mais diversas unidades cr´ıticas da infraestrutura conectada em rede. A cooperac¸˜ao entre as diferentes m´aquinas (ou mesmo sub-redes) na prevenc¸˜ao contra intrus ˜oes 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˜ao listados alguns trabalhos futuros: (1) melhoramentos na arquitetura e
implementac¸˜ao; (2) desenvolvimento de ferramentas para a visualizac¸˜ao de estat´ısticas dos ´ındices do sistema; (3) inclus˜ao de mecanismos para o suporte `a entrada de dados de outros sistemas de monitoramento, correlac¸˜ao de alarmes e detecc¸˜ao de intrus˜oes; (4) inclus˜ao de mecanismos para a identificac¸˜ao de padr˜oes de ataque em conex ˜oes de rede que passam pelo filtro de pacotes; (5) testes com m ´ultiplos monitores em redes distintas; (6) testes de desempenho e atividade em v´arias m´aquinas (servidores, firewalls, estac¸ ˜oes de trabalho) de uma mesma rede; (7) adaptar o sistema para o suporte e outros filtros de pacotes, como o ebtables; (8) mecanismos de seguranc¸a para elevar o grau de confianc¸a nas informac¸ ˜oes passadas por monitores vizinhos.
Referˆencias
Caswell, B. and Roesch, M. (2004). Snort - The Open Source Network Intrusion Detec-tion System. http://www.snort.org/. ´Ultimo acesso: maio de 2005.
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. http://www.sans.org/rr/whitepapers/detection/1381. php. ´Ultimo acesso: maio de 2005.
Kreutz, D. (2004). Controle Independente de Restric¸ ˜oes de Acesso a Redes Locais em Firewalls que Utilizam o IPTables. In III Simp ´osio de Inform´atica da Regi˜ao 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 95–104.
Provos, N. (2004). A virtual honeypot framework. In USENIX Security Symposium, pages 1–14.
