UNIVERSIDADE FEDERAL DA BAHIA

INSTITUTO DE MATEMTICA
DEPARTAMENTO DE CINCIA DA COMPUTAO

Italo Valcy da Silva Brito

TRAIRA: uma ferramenta para o Tratamento de Incidentes de Rede Automatizado

Salvador 2010

Italo Valcy da Silva Brito

TRAIRA: uma ferramenta para o Tratamento de Incidentes de Rede Automatizado

Monograa apresentada ao curso de graduao em Cincia da Computao, Departamento de Cincia da Computao, Instituto de Matemtica, Universidade Federal da Bahia, como requisito parcial para obteno do grau de Bacharel em Cincia da Computao. Orientador: Profo . Luciano Porto Barreto Co-orientador: Jernimo Aguiar Bezerra

Salvador 2010

RESUMO
O crescimento atual da Internet tem alavancado o nmero de incidentes de segurana da informao. Segundo dados do CERT.Bahia, de Janeiro Outubro de 2010 j foram reportados mais de 1500 incidentes de segurana s instituies de ensino e pesquisa monitoradas na Bahia. Devido aos prejuzos causados por tais incidentes e sua diculdade de preveno, necessrio estabelecer polticas e mecanismos ecientes de tratamento e resposta a incidentes de segurana. Entretanto, um dos entraves correta identicao de equipamentos comprometidos ou participantes em um incidente de segurana consiste na ampla existncia de redes que utilizam equipamentos para traduzir ou mapear os endereos dos hosts internos rede via NAT ou DHCP. O emprego dessas tcnicas oculta a identicao precisa dos hosts internos, o que diculta o tratamento adequado de incidentes. Este trabalho descreve o projeto, a implementao e avaliao da ferramenta TRAIRA, a qual automatiza o procedimento de deteco, identicao e isolamento da mquina geradora do incidente. O custo da implantao da soluo proposta baixo e facilita sobremaneira o trabalho da equipe de tratamento de incidentes de segurana. A ferramenta desenvolvida foi avaliada experimentalmente e em um ambiente real, na Universidade Federal da Bahia (UFBA). Atualmente, a equipe de segurana da UFBA utiliza essa ferramenta para tratar e responder a todos os incidentes de segurana reportados pelo CERT.Bahia. O baixo custo de execuo e implantao da ferramenta indica, assim, a viabilidade de sua aplicao prtica em ambientes corporativos. Palavras-chave: segurana da informao, tratamento de incidentes de segurana, resposta a incidentes, cdigo malicioso, NAT.

ABSTRACT
The current growth of the Internet has increased the number of computer security incidents. CERT.Bahia reported, from January to Octuber 2010, over 1500 security incidents involving education and research institutions of Bahia. Since security incidents are hard to prevent and lead to nancial losses, it is necessary to establish effective policies and mechanisms to cope with such kind of incidents. However, one of the most challenging issues related to the proper identication of affected systems is the wide use of techniques to translate or map the host internal address through NAT or DHCP. Thus, such techniques make the security incident handling process difcult to be performed since they hide the real host identication. This work describes the design, implementation and evaluation of a tool called TRAIRA, which is a software designed to automate the process of detection, identication and containment of computers responsable for security incidents. The deployment requirements of TRAIRA are simple. In addition, TRAIRA helps the computer security incident response teams on their work. TRAIRA was veried using experiments and a case study with the Federal University of Bahia (UFBA). At UFBA, with the use of TRAIRA it was possible to handle and respond to all security incidents reported by CERT.Bahia. The low costs deployment and utilization of TRAIRA indicate the viability of its use in real environments. Keywords: information security, handling of security incidents, incident response, malicious software, NAT.

DEDICATRIA
Cerca de doze anos atrs (as lembranas daquele momento no so mais to claras), maravilhado com um ato de pura nobreza de meus pais, quei a me perguntar como poderia retribulos. Daquele momento em diante, tenho me esforado ao mximo para dar-lhes orgulho de seu lho e acredito que esse trabalho representa bem esse esforo. Gostaria de dedicar esse trabalho meus pais, pessoas honestas, trabalhadoras, de bom corao e ps-doutores na arte de educar. Eles sempre estiveram comigo durante minha caminhada, aconselhando a estudar nos momentos de desleixo e a relaxar nos momentos de estudo excessivo, anal a mente tambm precisa descansar.

AGRADECIMENTOS
Gostaria de agradecer a todos que, direta ou indiretamente, me ajudaram nesse projeto. Em particular, agradecer Deus e meus pais, Valdir e Ana, fundamentais nessa conquista; meus irmos e demais parentes; meus amigos de todos os tempos; pessoal do Graco (Gestores da Rede Acadmica de Computao DCC/UFBA), DAComp (Diretrio Acadmico de Computao UFBA), PoP-BA/RNP (Ponto de Presena da RNP na Bahia), CPD/UFBA (Centro de Processamento de Dados da UFBA), PSL-BA (Projeto Software Livre Bahia), professores e funcionrios do DCC/IM/UFBA, e colegas das disciplinas. Este trabalho apenas a ponta de um iceberg, fruto de um projeto muito maior iniciado em 2006 com a inacreditvel aprovao no vestibular da UFBA. Ao longo desses quatro anos e meio de vivncia intensiva da UFBA, conheci pessoas incrveis, pessoas fundamentais na construo de quem sou hoje. Preferi no citar nomes aqui, evitando magoar os possveis esquecidos, mas agradeo a todos que me ajudaram, uns mais que outros, a conquistar o que conquistei, desde as primeiras oportunidades, conselhos nos momentos de indeciso, crticas, apoio moral e tcnico, compreenso etc. No pude, no entanto, deixar de relacionar as pessoas abaixo, pois tiveram contribuio especial na realizao desse TCC: Jernimo Bezerra - PoP-BA/RNP; Luciano Porto - Orientador; Daniel Batista - USP; equipe do PoP-BA/RNP, CPD/UFBA e CERT.Bahia; membros do Graco.

LISTA DE FIGURAS
1.1 Nmero total de acessos ao honeypot versus acessos originados nos clientes da RNP na Bahia (CERT.BAHIA, 2010b) . . . . . . . . . . . . . . . . . . . . . . 2.1 Ciclo de vida da resposta a incidentes - adaptado de (SCARFONE; GRANCE; MASONE, 2008) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 3.2 3.3 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 Viso geral da arquitetura do TRAIRA . . . . . . . . . . . . . . . . . . . . . . Tela do TRAIRA para exibio de relatrios/estatsticas . . . . . . . . . . . . . Cenrio utilizado nos experimentos do TRAIRA . . . . . . . . . . . . . . . . . Esquema de chains da tabela NAT (MOTA FILHO, 2003) . . . . . . . . . . . . Cenrio para utilizao de SNAT no IPTables/Netlter . . . . . . . . . . . . . Viso geral de funcionamento do NFCT-SNATLOG . . . . . . . . . . . . . . . Cenrio para experimentos de avaliao de desempenho do NFCT-SNATLOG . Grcos de utilizao de CPU do rewall com tradues SNAT sem logging. . 21 31 42 44 48 49 55 59 62 12

Grcos de utilizao de memria do rewall com tradues SNAT sem logging. 62 Grcos de utilizao de disco do rewall com tradues SNAT sem logging. . Grcos de utilizao de CPU do rewall com tradues SNAT e logging local. Grcos de utilizao de memria do rewall com tradues SNAT e logging local. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 64 62 63

4.10 Grcos de utilizao de disco do rewall com tradues SNAT e logging local.

4.11 Grcos de utilizao de CPU do rewall com tradues SNAT e logging remoto. 64 4.12 Grcos de utilizao de memria do rewall com tradues SNAT e logging remoto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.13 Grcos de utilizao de disco do rewall com tradues SNAT e logging remoto. 65

LISTA DE ABREVIATURAS E SIGLAS

ARP CAIS CERT.Bahia CERT.br CGI.br CSA CSIRT DHCP HIPS IDS IETF L2M MAC NAPT NAT OTRS PoP-BA/RNP RNP RT RTIR UFBA Address Resolution Protocol, Centro de Atendimento a Incidentes de Segurana, Grupo de Resposta a Incidentes de Segurana da Bahia/Brasil, Grupo de Resposta a Incidentes de Segurana no Brasil, Comit Gestor da Internet no Brasil, Cisco Security Agent, Computer Security Incident Response Teams, Dynamic Host Conguration Protocol, Host Intrusion Prevention System, Intrusion Detection System, Internet Engineering Task Force, Layer 2 Manager, Media Access Control, Network Address Port Translation, Network Address Translation, Open Source Ticket Request System, Ponto de Presena da RNP na Bahia, Rede Nacional de Ensino e Pesquisa, Request Tracker, Request Tracker for Incident Response, Universidade Federal da Bahia, p. 38 p. 18 p. 19 p. 18 p. 18 p. 26 p. 17 p. 23 p. 26 p. 26 p. 22 p. 38 p. 24 p. 23 p. 11 p. 27 p. 19 p. 18 p. 27 p. 27 p. 19

SUMRIO

Introduo 1.1 1.2 1.3 Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estrutura da dissertao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10 10 13 15 16 16 17 19 19 20 21 23 23 24 25 26

Fundamentos do Tratamento de Incidentes de Segurana 2.1 2.2 Eventos e Incidentes de Segurana . . . . . . . . . . . . . . . . . . . . . . . . Noticaes de Incidentes de Segurana . . . . . . . . . . . . . . . . . . . . . 2.2.1 2.2.2 2.2.3 2.3 2.4 CERT.br . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CAIS/RNP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CERT.Bahia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Tratamento de Incidentes de Segurana . . . . . . . . . . . . . . . . . . . . . Principais diculdades do tratamento de incidentes . . . . . . . . . . . . . . . 2.4.1 2.4.2 2.4.3 NAT e o impacto de esconder as mquinas da rede interna . . . . . . Atribuio dinmica de endereos IP via DHCP . . . . . . . . . . . . . Falta de gerenciamento dos logs de dispositivos . . . . . . . . . . . . .

2.5 3

Trabalhos correlatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

TRAIRA: uma ferramenta para Tratamento de Incidentes de Rede Automatizado 29 3.1 3.2 Viso geral do TRAIRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arquitetura do TRAIRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Mdulos do TRAIRA . . . . . . . . . . . . . . . . . . . . . . . . . . 29 30 33

3.2.2 3.2.3 3.3 3.4 4

Gerao de estatsticas . . . . . . . . . . . . . . . . . . . . . . . . . . Integrao com o RT . . . . . . . . . . . . . . . . . . . . . . . . . . .

41 43 44 45

Avaliao experimental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Requisitos para implantao do TRAIRA . . . . . . . . . . . . . . . . . . . .

NFCT-SNATLOG: Uma ferramenta para registro das tradues SNAT do IPTables/Netlter 4.1 4.2 O problema do registro de tradues NAT no IPTables/Netlter . . . . . . . . . NFCT-SNATLOG: Registro das tradues de SNAT no IPTables/Netlter . . . 4.2.1 4.2.2 4.2.3 4.3 Arquitetura do NFCT-SNATLOG . . . . . . . . . . . . . . . . . . . . Questes de implementao . . . . . . . . . . . . . . . . . . . . . . . Exemplo de utilizao . . . . . . . . . . . . . . . . . . . . . . . . . . 47 48 53 54 55 57 58 59 61 65 67 70 73

Avaliao de desempenho da proposta . . . . . . . . . . . . . . . . . . . . . . 4.3.1 4.3.2 4.3.3 Cenrios para a avaliao de desempenho . . . . . . . . . . . . . . . . Resultados obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . Anlise dos resultados . . . . . . . . . . . . . . . . . . . . . . . . . .

Concluso

Apndice A -- Ferramentas para avaliao de desempenho do NFCT-SNATLOG Referncias Bibliogrcas

10

INTRODUO

O crescimento atual da Internet tem inuenciado diretamente no aumento do nmero de incidentes de segurana. Falhas relacionadas segurana tornam-se no somente mais numerosas e diversas, como tambm mais prejudiciais sade nanceira e desenvolvimento geral das instituies. Atividades preventivas baseadas, por exemplo, nos resultados da anlise de risco das atividades de TI de uma instituio, contribuem na diminuio do nmero de incidentes, porm nem todos os incidentes podem ser prevenidos (SCARFONE; GRANCE; MASONE, 2008). Dessa forma, a capacidade de tratar e responder aos incidentes reportados uma instituio importante para rapidamente detectar o incidente, minimizar as perdas e destruies, mitigar as falhas que foram exploradas e restaurar os servios computacionais afetados. No obstante, a identicao e tratamento de um incidente de segurana no uma tarefa simples. Ao contrrio, exige que todo um processo seja executado para detectar a mquina que gerou (ou sofreu) o incidente, vericar os impactos causados na rede, aplicar o plano de recuperao para o desastre, documentar as aes realizadas e rever as polticas de segurana com o propsito de diminuir a chance de repetio do incidente (fazendo o levantamento das lies aprendidas). Esse processo de tratamento de incidentes deve estar alinhado com a poltica de segurana e sua complexidade depende das caractersticas da rede da instituio. No caso das instituies de ensino e pesquisa, por exemplo, cada unidade possui demandas especcas, o que torna o ambiente bastante heterogneo e diculta a resposta aos incidentes. Em particular, este trabalho tem um foco especial nas instituies de ensino e pesquisa da Bahia que se conectam Internet atravs da Rede Nacional de Ensino e Pesquisa (RNP) e como estas instituies tm participado do cenrio de (in)segurana da Internet.

1.1

MOTIVAO

A Rede Nacional de Ensino e Pesquisa (RNP) opera, desde 1991, a rede acadmica nacional (tambm conhecida, a partir de 2005, como Rede Ip). Financiada pelos Ministrios da

11

Cincia e Tecnologia e da Educao, a RNP foi concebida para atender comunidade de ensino e pesquisa brasileira, interconectando instituies e redes regionais em nvel nacional e oferecendo enlaces prprios para a rede de produo (Internet commodity) (RNP, 2007a). Por exemplo, algumas instituies clientes da RNP na Bahia so: UFBA, UFRB, IFBA, UNEB, UEFS, UESC, UESB, IFBaiano, Fiocruz, Embrapa, UCSAL, UNIFACS. A poltica de uso da RNP (RNP, 2007b) especica que as instituies podem usar a Rede Ip para promover atividades de ensino e pesquisa, exceto para: produo ou transmisso de dados ou materiais considerados ilegais; transmisso de mensagens ou material de propaganda no solicitados pelo destinatrio; atividades que contribuam para inecincia ou esgotamento dos recursos na rede; atividades que promovam a corrupo ou destruio de dados de usurios. Por outro lado, observando-se particularmente os clientes da RNP na Bahia, percebe-se que a rede acadmica tambm tem contribudo no aumento dos incidentes de segurana na Internet, conforme pode ser visto no grco da Figura 1.1, gerado pelo Grupo de Resposta a Incidentes de Segurana da Bahia/Brasil (CERT.Bahia)(CERT.BAHIA, 2010b). Esse grco mostra a quantidade de tentativas de ataques ao sensor de honeypot do CERT.Bahia, com a linha superior (linha verde) representando o total de acessos e a linha inferior (linha azul) aqueles cujo endereo de origem pertence a um dos clientes da RNP na Bahia. Tais acessos indicam, com alta probabilidade, um possvel comprometimento da mquina de origem com vrus/worms1 , ou at mesmo que a mquina pode estar sendo usada como bot2 . Ainda, segundo dados do CERT.Bahia sobre as noticaes de incidentes de segurana recebidas em 2010 (dados coletados at Outubro), foram noticados 1431 incidentes do tipo host possivelmente infectado com vrus/worm (93.8%), 45 incidentes de envio de spam (3%), 23 incidentes relacionados violao de copyright (1.5%), dentre outros. Em outras palavras, a partir desses dados possvel ter uma noo do impacto da comunidade baiana conectada RNP na gerao de incidentes de
1 Segundo (CERT.BR, 2006b), worm um programa malicioso capaz de se propagar automaticamente atravs de redes, enviando cpias de si mesmo de computador para computador. Diferente do vrus, o worm no inclui cpias de si mesmo em outros programas ou arquivos e no necessita ser explicitamente executado para se propagar. Sua propagao se d atravs da explorao de vulnerabilidades existentes ou falhas na congurao de softwares instalados em computadores. 2 Segundo (CERT.BR, 2006b), bot um programa malicioso capaz de se propagar automaticamente (similar ao worm), explorando vulnerabilidades existentes ou falhas na congurao de softwares instalados em um computador. Adicionalmente ao worm, possui mecanismos para se comunicar com o invasor e ser controlado remotamente (o invasor, ao se comunicar com o bot, pode orient-lo a realizar ataques contra outros computadores, furtar dados, enviar spam, etc.)

12

Figura 1.1: Nmero total de acessos ao honeypot versus acessos originados nos clientes da RNP na Bahia (CERT.BAHIA, 2010b) segurana na Internet, principalmente no que concerne a incidentes do tipo host possivelmente infectado com vrus/worm. O tratamento dessa gama de incidentes de segurana em instituies de ensino e pesquisa constitui um grande desao para as equipes de segurana, principalmente levando-se em considerao o volume de noticaes recebidas e a heterogeneidade da rede. Mesmo as grandes instituies, geralmente, no possuem uma equipe e ferramentas de segurana necessrias para tratar todos os incidentes. Alm disso, a maior parte dos incidentes, aqueles relacionados s mquinas infectadas com vrus/worm, so causados por ferramentas que comprometem a mquina de forma automatizada e, no geral, so simples de resolver, apesar de trabalhosos (KAISER et al., 2006). Obviamente, a infeco automatizada de mquinas com software malicioso no pode ser tratada de forma manual. Uma alternativa tornar o processo de tratamento desses incidentes o mais automatizado possvel. Por exemplo, usando ferramentas para detectar e isolar as mquinas comprometidas de forma automatizada e contando com o apoio de uma equipe de apoio (helpdesk) para trabalhar na desinfeco das mquinas. Dessa maneira, reserva-se os analistas de segurana (cujo custo de contratao comumente alto) para o tratamento de incidentes mais importantes ou complexos, e para as outras atividades de segurana da instituio. Uma ferramenta de tratamento automatizado de incidentes deve lidar com uma diculdade frequentemente reportada pelas instituies de ensino e pesquisa da Bahia (qui de grande parte das instituies): a correspondncia entre o endereo IP contido na noticao recebida e aquele da mquina da rede interna3 que, de fato, gerou o incidente. Essa diculdade ocatrabalho, considera-se que a instituio possui uma rede interna, na qual os hosts so endereados utilizando-se endereos IP privados (denidos na RFC 1918 (REKHTER et al., 1996)), e, para acessar a Internet, tais endereos so traduzidos em endereos IP roteveis na Internet atravs de um dispositivo de NAT.
3 Neste

13

sionada, principalmente, pelo uso da tcnica de traduo de endereos de rede (NAT, do ingls Network Address Translation), que esconde os endereos IP da rede interna da instituio (REKHTER et al., 1996), em conjunto com os mecanismos de congurao dinmica de endereos IP (DHCP), que possibilitam que uma mquina possa ser endereada por dois ou mais diferentes endereos IP ao longo do dia.

1.2

PROPOSTA

Os desaos supracitados motivaram o desenvolvimento de uma ferramenta e a confeco de documentos de boas prticas que, aplicados em conjunto, permitem um tratamento dos incidentes de segurana altamente automatizado. A esse conjunto de programas, interfaces e documentos de boas prticas que compem a soluo de tratamento de noticaes de incidentes, deu-se o nome TRAIRA (Tratamento de Incidentes de Rede Automatizado). Em sua primeira verso, o TRAIRA atua nas duas primeiras fases do tratamento de incidentes (SCARFONE; GRANCE; MASONE, 2008) (preparao e deteco e anlise - descrito na Seo 2.3) de forma que a deteco da mquina interna que gerou o incidente, etapa trabalhosa do processo, totalmente automatizada. A arquitetura da ferramenta prev ainda uma atuao na etapa de isolamento das mquinas comprometidas. O TRAIRA, na verdade, originou-se a partir de um conjunto de scripts que eram utilizados na Universidade Federal da Bahia (UFBA) para busca nos logs dos equipamentos por evidncias que indicassem a mquina interna que gerou o incidente (pois, com o uso de NAT, o endereo que listado em uma noticao, na maioria das vezes, no mapeado diretamente na mquina da rede interna que causou o incidente). Esses scripts, no entanto, eram especcos para o ambiente de rede da UFBA e de difcil extenso. Assim, o TRAIRA foi criado como uma refatorao dos scripts anteriores de forma a transform-los em uma ferramenta modular e facilitar sua adaptao outros cenrios de rede, acrescentando algumas funcionalidades observadas pela equipe da UFBA. Dessa forma, o TRAIRA poder ser usado em outras instituies e ajudar a diminuir as estatsticas apresentadas anteriormente. Segue abaixo uma listagem no exaustiva das principais contribuies desse trabalho. Criao de uma ferramenta de tratamento automatizado de incidentes de segurana, o TRAIRA, a partir da refatorao do cdigo-fonte de scripts utilizados na UFBA com propsito similar, que permita modularidade nas vrias etapas que compem o processo de tratamento de uma noticao e, consequentemente, utilizao em diversos cenrios de rede;

14

Integrar a ferramenta criada, o TRAIRA, em um software que permita fazer a gerncia completa do incidente de segurana. Por gerncia do incidente de segurana entendese o registro ou execuo das aes relacionadas s etapas do tratamento de incidentes (SCARFONE; GRANCE; MASONE, 2008). Por exemplo, documentar as aes tomadas para um determinado incidente e index-las de forma a facilitar sua recuperao para consulta futura, extrair informaes dos incidentes e organiz-las de forma a facilitar a gerao de novas estatsticas, permitir diferentes nveis de acesso e atualizao sobre uma noticao de incidente (importante quando equipes com privilgios diferentes trabalham em um incidente, por exemplo a equipe de helpdesk e os analistas de segurana, ou ainda o prprio usurio relacionado a um incidente), dentre outras; Aproveitar da arquitetura modular do TRAIRA e adicionar mdulos para etapas do tratamento em que as ferramentas usadas nas instituies variam com maior probabilidade. Por exemplo, uma etapa que provavelmente difere de instituio para instituio no mapeamento do endereo IP que aparece na noticao para a mquina da rede interna que gerou o incidente: caso utilize-se NAT na instituio, o endereo IP externo (rotevel) primeiramente dever ser mapeado para um endereo IP da rede privada e ento devese mapear esse IP interno para a mquina que gerou a noticao (via endereo MAC); caso a instituio no utilize NAT, mas os endereos IP roteveis sejam dinamicamente distribudos nas mquinas internas, basta localizar a mquina da rede interna (via endereo MAC) que gerou a noticao; caso a instituio no utilize NAT e suas mquinas possuem endereo IP esttico (cenrio bastante incomum), esse mapeamento no um problema. Ainda para os casos em que utiliza-se NAT, dispositivos de NAT distintos possuem formas diferentes de armazenar os logs das tradues; Implementar uma aplicao para fazer logging das tradues de NAT do IPTables/Netlter, o rewall nativo do Linux. O IPTables no faz logging das tradues NAT incluindo os endereos traduzidos (IP traduzido e porta traduzida) e muito menos a durao que uma conexo de NAT levou (ou, pelo menos, no o faz de forma direta, simples e eciente). Essas informaes so essenciais no tratamento dos incidentes, pois sem elas no ser garantido o correto tratamento de uma noticao (pode no ser possvel detectar o IP da rede interna ou detect-lo incorretamente, caso o IP/porta original seja diferente do IP/porta traduzida em uma conexo NAT); Trabalhar na etapa de tomada de aes para mitigar o problema reportado. Ao se conhecer a mquina da rede interna que gerou o incidente, necessrio aplicar uma srie de medidas para resolver o problema e evitar que a mquina gere outra noticao. Exemplos

15

de aes so: corrigir uma congurao incorreta da mquina, executar uma varredura com anti-vrus, reinstalar o sistema comprometido, etc. Dependendo do nmero de noticaes recebidas, pode ser invivel tratar cada mquina em tempo hbil de evitar que o incidente volte a ocorrer. Assim, uma abordagem alternativa isolar a mquina comprometida da rede temporariamente at que a equipe de apoio execute as medidas de mitigao; Coletar estatsticas sobre os incidentes gerados na instituio. Atualmente, o CERT.Bahia gera algumas estatsticas sobre os incidentes por instituio, porm, considerando o uso de NAT, interessante que a instituio mantenha estatsticas internas e mais detalhas sobre as noticaes. Essas estatsticas internas so importantes para direcionar a equipe de segurana a atuar em setores especcos da instituio: as estatsticas devem ajudar a detectar a VLAN mais problemtica, se existem casos de reincidncia, etc.; Documentar a utilizao do TRAIRA incluindo as boas prticas que ajudam no tratamento das noticaes de incidentes. Por exemplo, gerar ou disponibilizar documentao sobre boas prticas de congurao de rewall, sistemas de logging remoto e gerenciamento desses logs, dentre outros. Atualmente, o TRAIRA est sendo utilizado pela equipe de segurana da UFBA, recebendo todas as noticaes de incidentes de segurana reportados instituio e tratando de forma totalmente automatizada quelas do tipo host infectado com vrus/worm. A nica etapa executada manualmente no tratamento desses incidentes justamente na etapa de mitigao e recuperao, cando a cargo da equipe de segurana denir as aes a serem tomadas. Ainda, j possvel extrair uma srie de estatsticas sobre os incidentes reportados e us-las para direcionar medidas de mitigao. Por exemplo, possvel saber quais os segmentos de rede (VLANs) que mais geram incidentes, se existe reincidncia de mquinas infectadas na rede, dentre outros.

1.3

ESTRUTURA DA DISSERTAO

O restante deste trabalho est estruturado da seguinte maneira. O Captulo 2 aborda os principais conceitos e diculdades envolvidos no tratamento de incidentes de segurana, alm de alguns trabalhos correlatos. O Captulo 3 aborda todos os detalhes envolvidos na implementao da ferramenta de Tratamento de Incidentes de Rede Automatizado, o TRAIRA, proposta deste trabalho, e avalia a eccia de sua utilizao atravs de experimentos controlados e de um estudo de caso na UFBA. J o Captulo 4 apresenta o NFCT-SNATLOG, uma aplicao para registro (logging) das tradues NAT do IPTables/Netlter, e avalia o desempenho de sua

16

utilizao atravs de medio. Por m, o Captulo 5 relaciona as concluses obtidas a partir da produo deste trabalho e lista possveis trabalhos futuros.

17

FUNDAMENTOS DO TRATAMENTO DE INCIDENTES DE SEGURANA

Este captulo aborda os principais conceitos envolvidos no tratamento de incidentes de segurana, objeto de estudo deste trabalho. Ser apresentada a diferena entre evento e incidente de segurana; abordada questes relacionadas s noticaes e a importncia em respondlas, listando alguns grupos de segurana que comumente reportam incidentes; apresenta-se um exemplo de processo de tratamento de incidentes, comumente referenciado na literatura, e que serve de base para a ferramenta desenvolvida; lista-se as principais diculdades encontradas nas instituies de ensino e pesquisa para o tratamento dos incidentes; e, por m, relaciona-se alguns trabalhos correlatos.

2.1

EVENTOS E INCIDENTES DE SEGURANA

Segundo (SCARFONE; GRANCE; MASONE, 2008), um evento qualquer ocorrncia observvel em um sistema ou na rede. Por exemplo, um usurio que acessa o servidor de arquivos, um servidor web que recebe uma requisio HTTP, um usurio que inicia uma sesso SMTP para envio de e-mail, ou mesmo o rewall que bloqueia uma tentativa de conexo. Por outro lado, um evento adverso aquele que tem consequncia negativa para a instituio, por exemplo, um sistema em colapso, inundao (ooding) de pacotes na rede, uso no autorizado de sistemas, acesso no autorizado dados sensveis, execuo de cdigo malicioso para destruio de dados, dentre outros. Vale salientar que alguns eventos adversos podem ocorrer por desastres naturais ou mesmo falhas de energia, porm este trabalho se preocupa apenas com eventos adversos relacionados com a segurana do software dos computadores. Um incidente de segurana pode ser denido como qualquer evento adverso, conrmado ou sob suspeita, relacionado segurana de sistemas de computao ou de redes de computadores (CERT.BR, 2006a). Alguns exemplos de incidentes de segurana so:

18

Negao de Servio. Neste tipo de incidente o atacante torna, ou visa tornar, indisponvel um servio ou recurso. Exemplos de incidentes de negao de servio incluem: um atacante envia pacotes com contedo especial a um servidor web, causando colapso no servidor e indisponibilizando o servio; centenas de computadores infectados, distribudos pela Internet, enviam tantas mensagens ICMP echo-request quanto puderem para a rede de uma determinada instituio, congestionando e inviabilizando o uso da rede; dentre outros. Cdigo Malicioso. O atacante visa executar cdigo malicioso no host remoto para obter controle sobre o sistema ou propagar vrus/worm. Por exemplo, worms que usam sistemas de compartilhamento de arquivos abertos para infectar as estaes de trabalho de uma organizao. Tal cdigo malicioso disseminado de diversas maneiras, incluindo, por exemplo, arquivos PDF. Acesso no autorizado. Um atacante executa um exploit1 para ganhar acesso a um servidor ou aumentar seu nvel de acesso ao sistema (para o nvel de administrador, por exemplo). Uso inapropriado. Um usurio disponibiliza cpias ilegais de software ou outros recursos digitais para outros usurios atravs de compartilhamento peer-to-peer, por exemplo. Outro exemplo comum o envio de e-mail em massa no solicitado (para propaganda comercial ou disseminao de cdigo malicioso) ou e-mails falsos para obter dados condenciais dos usurios2 . Mais genericamente, um incidente de segurana uma violao, ou suspeita de violao, da poltica de segurana da informao, poltica de uso aceitvel ou padro de prticas de segurana de uma instituio (SCARFONE; GRANCE; MASONE, 2008). Por isso, importante que a instituio tenha esses documentos bem denidos e disponveis a seus usurios, principalmente a poltica de uso aceitvel, para deixar claro o que permitido e o que no no uso da rede e dos recursos computacionais da instituio. Maiores informaes sobre tais documentos podem ser obtidas em (CERT.BR, 2006a).
exploit um programa, poro de dados ou sequncia de comandos que explora vulnerabilidades conhecidas de um sistema computacional. 2 No geral esse tipo de incidente recebe uma classicao especial, por exemplo, envio de spam.
1 Um

19

2.2

NOTIFICAES DE INCIDENTES DE SEGURANA

A ocorrncia de ataques contra sistemas computacionais (incidente de segurana) geralmente est atrelada a duas situaes principais: ataques automatizados feitos por programas maliciosos que executam em sistemas comprometidos (por exemplo, um bot ou um worm); pessoas mal intencionadas que podem ou no fazer uso de ferramentas que automatizam ataques. Em ambos os casos importante alertar o(s) responsvel(eis) pela segurana da instituio envolvida no incidente para que possa-se tomar as medidas de deteco e resoluo do problema (no caso de ataques realizados por bot ou worm), evidenciar o mau comportamento de um usurio ou uma invaso de um sistema que ainda no havia sido detectada (no caso de ataques realizados por pessoas). Esses alertas so mais conhecidos por noticaes de incidentes de segurana. Alm de enviar as noticaes para os responsveis pela mquina que originou o incidente, importante tambm enviar uma cpia da noticao para os grupos de resposta a incidentes de segurana (CSIRT, do ingls Computer Security Incident Response Teams) das redes envolvidas (tanto da rede que gerou quanto da qual se est conectado, caso existam), de forma que eles possam gerar estatsticas sobre os incidentes e trabalhar estratgias de mitigao para problemas comuns. A noticao de incidente de segurana deve incluir dados sucientes para que seja possvel ao administrador da rede detectar a origem exata da atividade maliciosa, permitindo nalmente tomar as providncias cabveis. Abaixo uma lista dos dados essenciais que devem ser includos em uma noticao (CERT.BR, 2006a): logs completos. Devem ser includas todas as mensagens de logs que evidenciam a ocorrncia do incidente sempre que possvel ou com as informaes permitidas; data, horrio e timezone (fuso horrio) dos logs ou da ocorrncia sendo noticada; endereo de origem do ataque, incluindo IP e porta da conexo que causou o incidente. Acerca dos grupos de resposta a incidentes de segurana, eles podem atuar tambm como organizaes que reportam incidentes, quando i) possuem sensores para anlise do trfego de rede e descoberta automatizada de incidentes, gerando, dessa forma, noticaes aos responsveis pelas redes de forma automtica ou simplesmente ii) encaminham as noticaes recebidas aos responsveis de fato pela rede em questo. No caso dos sensores, eles podem ser baseados na anlise de uxos da rede ou em sistemas de honeypot3 .
3 Segundo

um dos lderes do Projeto Honeynet, Lance Spitzner, um honeypot um recurso computacional de

20

Nas subsees seguintes sero apresentados alguns desses grupos que atuam no Brasil e seus escopos de atuao.

2.2.1

CERT.BR

O Grupo de Resposta a Incidentes de Segurana no Brasil (CERT.br), mantido pelo Comit Gestor da Internet no Brasil (CGI.br), responsvel por tratar incidentes de segurana em computadores que envolvam redes conectadas Internet no Brasil (CERT.BR, 2010). Dentre as atribuies do CERT.br esto: ser um ponto central para noticaes de incidentes de segurana no Brasil, provendo a coordenao e o apoio no processo de resposta a incidentes, colocando as partes envolvidas em contato, quando necessrio; manter estatsticas sobre os incidentes a ele reportados; desenvolver documentao de apoio para usurios e administradores de redes Internet. Dessa forma, o CERT.br atende a qualquer rede brasileira conectada Internet, recebendo, encaminhando e gerando noticaes de incidentes de segurana aos responsveis pela rede em questo. Em especial, no que tange gerao de noticaes de incidentes, dois projetos do CERT.br tm um destaque especial: Honeynet.BR: rede brasileira de sensores distribudos baseados em honeypots com o objetivo de aumentar a capacidade de deteco de incidentes, correlao de eventos e determinao de tendncias de ataques no espao Internet brasileiro (HONEYNET.BR, 2010); Spampots: o objetivo deste projeto obter, atravs de honeypots de baixa interatividade, dados relativos ao abuso da infra-estrutura de Internet para o envio de spam (CERT.BR, 2007).

2.2.2

CAIS/RNP

O Centro de Atendimento a Incidentes de Segurana (CAIS), mantido pela Rede Nacional de Ensino e Pesquisa (RNP), atua na deteco, resoluo e preveno de incidentes de segurana
segurana, cujo valor reside em ser sondado, atacado e comprometido. A ideia bsica de um sistema de honeypot simular alguns servios, porm sem divulg-los em local algum. Com isso, todo acesso a ele suspeito e potencialmente malicioso. Geralmente esses acessos so registrados em logs e usados para o envio de noticaes s instituies de origem.

21

na rede acadmica brasileira, alm de elaborar, promover e disseminar prticas de segurana em redes (CAIS, 2010). Algumas das atribuies do CAIS so: Atendimento a incidentes de segurana; Coordenao com grupos de segurana j existentes; Fomento criao de novos grupos de segurana no pas; Disseminao de informaes na rea de segurana em redes; Divulgao de recomendaes e alertas; Testes e recomendao de ferramentas de segurana; Gerar recomendaes de polticas para a RNP, para os Pontos de Presena (PoPs) da RNP e para o backbone da RNP. O CAIS atende todas as instituies que se conectam RNP no Brasil, recebendo e encaminhando noticaes de incidentes relacionados a tais instituies. O CAIS tambm possui uma srie de sensores para gerao de noticaes, alm de parcerias nacionais e internacionais para coleta de evidncias de incidentes. No obstante, ele incentiva e apoia a criao de grupos de segurana brasileiros acadmicos, tanto nas instituies usurias da RNP quanto nos PoPs.

2.2.3

CERT.BAHIA

Grupo de Resposta a Incidentes de Segurana da Bahia/Brasil (CERT.Bahia) o grupo responsvel pelo tratamento e resposta aos incidentes de segurana relacionados comunidade baiana conectada RNP, mantido pelo Ponto de Presena da RNP na Bahia (PoP-BA/RNP) em parceria com a Universidade Federal da Bahia (UFBA) (CERT.BAHIA, 2010a). O objetivo do CERT.Bahia ajudar e guiar as organizaes na preveno, deteco e tratamento dos incidentes de segurana, bem como criar e disseminar prticas para uso e administrao seguros das Tecnologias de Informao (TI). O CERT.Bahia hospeda um dos sensores do projeto Honeynet.BR e utiliza os dados coletados no sensor para gerao de estatsticas (CERT.BAHIA, 2010b) e para noticao de incidentes de segurana cuja origem um cliente da RNP. Alm de enviar noticaes s instituies, o CERT.Bahia acompanha e apoia o processo de resposta aos incidentes, fornecendo treinamento, documentao e dicas de boas prticas,

22

alm de desenvolver (ou ajudar no desenvolvimento) ferramentas para atender a demandas de automatizao de subprocessos do tratamento dos incidentes de segurana. Em particular, este trabalho fruto de uma demanda observada pelo CERT.Bahia no tratamento dos incidentes pelas instituies clientes do PoP-BA/RNP (descrito na Seo 2.4).

2.3

TRATAMENTO DE INCIDENTES DE SEGURANA

O tratamento de incidentes de segurana envolve trs funes: noticao do incidente, anlise do incidente e resposta ao incidente (CERT/CC, 2010). Conforme discutido na Seo 2.2, a noticao do incidente importante para que um CSIRT possa centralizar e correlacionar os incidentes de segurana a m de determinar tendncias e padres das atividades maliciosas, gerando recomendaes de estratgias preventivas s instituies envolvidas. A anlise do incidente, alm da correlao dos eventos, envolve tambm estudar a noticao e as atividades do incidente para determinar seu escopo, prioridade e ameaas, pesquisando por respostas a incidentes anteriores que sejam semelhantes ao atual e montando estratgias de mitigao. A resposta ao incidente consiste de uma metodologia organizada para gerir as consequncias de uma violao de segurana da informao, onde um CSIRT pode enviar recomendaes para recuperao, conteno e preveno, instituio envolvida no incidente. Nesse sentido, faz-se necessria a denio de um processo de resposta a incidentes de segurana, cujo objetivo minimizar o impacto de um incidente e permitir o restabelecimento dos sistemas o mais rpido possvel (CERON et al., 2009). A denio de tal processo deve observar alguns princpios que norteiam a concepo de um sistema de tratamento de incidentes de segurana. Segundo (SCARFONE; GRANCE; MASONE, 2008), o processo de resposta a incidentes composto principalmente de quatro fases, conforme ilustrado na Figura 2.1 e descrito a seguir:

Figura 2.1: Ciclo de vida da resposta a incidentes - adaptado de (SCARFONE; GRANCE; MASONE, 2008)

Preparao: esta fase inicial envolve o estabelecimento e treinamento de um grupo de resposta a incidentes, alm da aquisio de ferramentas e recursos necessrios. Durante a

23

preparao, a organizao tambm tenta limitar o nmero de incidentes que iro ocorrer, selecionando e implementando um conjunto de controles baseados no resultado de uma anlise de riscos na organizao. No entanto, alguns riscos inevitavelmente persistiro mesmo depois dos controles serem implementados, ou seja, a possibilidade de ocorrncia de incidentes permanecer. Algumas medidas so essenciais de serem adotadas nessa fase para o sucesso do tratamento do incidente nas fases seguintes, dentre elas: armazenamento seguro dos logs dos sistemas; atualizao dos sistemas operacionais e aplicaes nos computadores da organizao (por exemplo, atualizao das assinaturas de anti-vrus, aplicao de patches de segurana, etc); Deteco e Anlise: nesta etapa deve-se detectar ou identicar de fato a existncia de um incidente. Os incidentes podem ser detectados por diferentes maneiras, com nveis variados de detalhes e delidade ao fato real. A deteco automatizada inclui sistemas de deteco e preveno de intruso (IDPS) baseados na rede ou no host, softwares anti-vrus e analisadores de logs. A deteco manual geralmente ocorre atravs do recebimento de noticaes de incidentes enviadas por outros usurios. A equipe de resposta a incidentes deve ento concentrar-se em identicar os sintomas do ataque e suas caractersticas, observando a severidade do incidente, ou seja, o quanto a estrutura de negcios da instituio foi afetada. Ainda, importante que o time de resposta a incidentes mantenha uma base de conhecimento sobre os incidentes reportados no passado. Essa base pode ser confrontada com dados de novos incidentes, a m de levantar informaes como sintomas e caractersticas do ataque; Conteno, Mitigao e Recuperao: assim que o incidente detectado e analisado, fundamental iniciar mecanismos de conteno para evitar que ele se propague ou afete outros recursos da rede (o isolamento pode ser feito, por exemplo, desligando-se o sistema, desconectando-o da rede, desabilitando certas funes, bloqueando sua porta em um equipamento de rede mais prximo, etc). Inicia-se ento o trabalho para mitigao e recuperao dos sistemas afetados. Por exemplo, para mquinas infectadas com vrus/worm, deve-se executar os softwares anti-vrus ou mesmo reinstalar o sistema. Para a recuperao, importante que a organizao tenha uma poltica de backup ecaz, pois a depender do incidente pode ser necessrio refazer todo o sistema afetado; Aes Ps-Incidente: esta etapa consiste em avaliar o processo de tratamento de incidentes e vericar a eccia das solues adotadas. Deve-se relacionar as falhas e os recursos que faltaram ou no foram sucientes, para que possam ser providenciados nas prximas ocasies. As lies aprendidas devem ser propagadas para toda a equipe, descrevendo

24

formas de obter melhores resultados e at mesmo recomendaes aos usurios. Finalizado o tratamento do incidente, importante responder noticao enviada, para que a organizao que reportou o incidente possa atualizar seus registros locais. Essa resposta especialmente importante quando trata-se de CSIRTs que reportam incidentes com frequncia sua rede, pois geralmente eles geram estatsticas sobre tais incidentes e usam essas estatsticas para criar ou direcionar atividades de apoio s instituies envolvidas.

2.4

PRINCIPAIS DIFICULDADES DO TRATAMENTO DE INCIDENTES

O processo de tratamento de incidentes, descrito na seo anterior, envolve a tomada de uma srie de aes que dependem da fase do tratamento em questo. Por exemplo, na fase de deteco e anlise, deve-se listar quais os recursos que foram afetados (no caso de incidentes contra a organizao) ou qual foi a origem do incidente (no caso de incidentes originados na organizao); na fase de conteno e mitigao deve-se isolar os sistemas diretamente relacionados ao incidente e efetuar o tratamento do recurso em questo (desinfeco de uma mquina contaminada com vrus/worm, remoo de um artefato malicioso, recuperao de uma pgina web modicada, etc). Este trabalho se preocupa principalmente com a fase de deteco/anlise para incidentes de segurana que so gerados na organizao. Essa fase apresenta uma srie de diculdades que sero apresentadas nas subsees seguintes. As principais diculdades aqui listadas esto relacionadas utilizao de NAT e DHCP na rede das instituies e diculdade na anlise de logs que contenham informaes sobre a origem real de um incidente (a mquina da rede interna que gerou ou foi alvo do incidente).

2.4.1

NAT E O IMPACTO DE ESCONDER AS MQUINAS DA REDE INTERNA

A tcnica de traduo de endereos de rede (NAT) foi desenvolvida pelo IETF (Internet Engineering Task Force) como uma medida paliativa para resolver o problema do esgotamento de endereos IPv4. Denida na RFC 1631 (EGEVANG; FRANCIS, 1994) (atualizada pela RFC 3022), tem como ideia bsica permitir que, com um nico IP rotevel na Internet, ou um pequeno conjunto deles, vrios hosts possam trafegar na Internet. Na rede interna, cada host recebe um endereo IP privado no rotevel na Internet, denido na RFC 1918 (REKHTER et al.,

25

1996), que utilizado apenas no roteamento interno. Quando o pacote precisa ser roteado para fora da rede interna, uma traduo de endereo precisa ser realizada, convertendo os endereos IP privados em endereos IP pblicos roteveis globalmente. Na verdade, a ideia anterior descreve um dos vrios tipos de NAT possveis, o SNAT (source NAT, tambm conhecido como mascaramento, do ingls masquerading), que efetua a traduo da origem do pacote. Uma outra possibilidade traduzir o destino do pacote, usando o DNAT (destination NAT ), til para implantao de estratgias de balanceamento de carga ou para esconder a rede dos servidores de uma instituio, por exemplo. Ainda sobre o SNAT, para realmente permitir que vrios hosts compartilhem um nico endereo IP, preciso diferenciar os pacotes baseado no nmero da porta TCP/UDP. Essa variao do NAT conhecida por Traduo de Endereos de Rede e de Portas (NAPT, do ingls Network Address Port Translation), porm ao longo deste documento NAT e NAPT tero o mesmo signicado. Por exemplo, suponha que os hosts da rede interna 192.168.0.2 e 192.168.0.3 enviam pacotes a partir da porta de origem 1108. Um dispositivo SNAT poder traduzir estes pacotes para um nico endereo IP pblico, digamos 200.128.0.1, e duas portas de origem diferentes, digamos 61001 e 61002. O trfego de resposta recebido para a porta 61001 ser roteado de volta para 192.168.0.2:1108, enquanto o trfego da porta 61002 ser roteado de volta para 192.168.0.3:1108. Caso a porta original esteja disponvel no dispositivo de NAT, a traduo desnecessria, utilizando-se a mesma porta de origem que foi enviada pelo host da rede interna. A utilizao de NAT mostrou-se eciente no que diz respeito economia de endereos IP, alm de apresentar alguns aspectos positivos, como facilitar a numerao interna das redes, ocultar a topologia das redes e s permitir a entrada de pacotes gerados em resposta a um pedido da rede. No obstante, a utilizao de NAT tambm traz uma srie de inconvenientes que, para alguns, anulam suas vantagens. No que tange ao tratamento de incidentes de segurana, a principal diculdade est em determinar com preciso o endereo IP interno que foi traduzido no endereo externo. Esse mapeamento (aqui, o mapeamento refere-se ao inverso da traduo original) depende primeiramente do suporte do dispositivo de NAT realizao de registro (logging) das tradues e de uma busca nos arquivos de logs para correlacionar o IP, porta e data/horrio com os dados da mensagem de log.

2.4.2

ATRIBUIO DINMICA DE ENDEREOS IP VIA DHCP

O Protocolo de Congurao Dinmica de Hosts (DHCP, do ingls Dynamic Host Conguration Protocol) permite a um host obter um endereo IP automaticamente, alm de outros

26

parmetros de congurao da rede (mscara de sub-rede, roteador padro, servidor DNS, etc). O DHCP foi denido na RFC 2131 (DROMS, 1997) pelo IETF, tambm como soluo paliativa problemtica do esgotamento dos endereos IP verso 4. O DHCP tem sido muito usado pelos provedores de acesso para permitir a atribuio de endereos temporrios a seus clientes, eliminando, dessa forma, a necessidade de mapeamento um para um entre os IPs roteveis e os clientes do provedor (essa ttica tem como hiptese que nem todos os clientes acessaro a rede ao mesmo tempo). Outra utilizao, ainda mais comum que a anterior, para a congurao automtica de mquinas na rede interna das instituies. Nesse caso, ao conectar um novo dispositivo rede, lhe ser automaticamente atribudo o prximo endereo IP disponvel no servidor DHCP, juntamente com alguns parmetros de congurao da rede. Como consequncia desta ltima utilizao do DHCP, possvel que um mesmo dispositivo possua diferentes endereos IP ao longo do dia, da semana ou do ms, a depender do tempo de concesso (lease time). Esse parmetro congurvel no servidor DHCP e depende de cada ambiente, variando de acordo com as demandas da rede em questo. Com isso, importante perceber que na fase de deteco do tratamento de um incidente de segurana, pode no ser suciente saber o IP interno que gerou a noticao. Faz-se necessrio um endereo que identique unicamente o host em questo na rede. Esse identicador ser o endereo MAC (Media Access Control), um endereo de 48 bits escrito na forma de 12 dgitos hexadecimais agrupados dois a dois (os grupos so separados por dois pontos). Metade do endereo utilizado para identicar o fabricante do dispositivo de rede em questo e o restante fornecido pelo fabricante, de forma que no devem existir dois dispositivos com o mesmo endereo MAC.

2.4.3

FALTA DE GERENCIAMENTO DOS LOGS DE DISPOSITIVOS

Um log um registro dos eventos que ocorrem nos sistemas ou na rede de uma organizao (SOUPPAYA; KENT, 2006). Esses registros, gerados pelos sistemas operacionais, servios, aplicaes ou dispositivos de rede, geralmente so de grande valor quando um incidente ocorre, pois muitos deles incluem dados relacionados segurana dos sistemas (contas que acessaram o sistema, aes executadas, uxos de rede, dentre outros). No obstante, a quantidade, volume e variedade dos logs de segurana dos sistemas tm crescido bastante, evidenciando a necessidade pelo seu gerenciamento um processo que envolve a gerao, transmisso, armazenamento, anlise e descarte dos logs (SOUPPAYA; KENT,

27

2006). O correto gerenciamento dos logs fundamental para a eccia do tratamento de incidentes. Infelizmente, em muitos incidentes, os logs no contm as evidncias necessrias, pois o logging do sistema em questo ou estava desabilitado ou congurado inadequadamente. Assim, ainda na fase de preparao do processo de tratamento de incidentes, a instituio deve atentarse congurao do logging de seus equipamentos e sistemas, enviando-os para um servidor remoto que centralize essas informaes. Para mais informaes e recomendaes sobre o gerenciamento dos logs de segurana, aconselha-se a leitura de Guide to Computer Security Log Management, um documento de recomendaes do NIST (SOUPPAYA; KENT, 2006). No caso dos incidentes de segurana que so gerados por uma instituio, seu tratamento geralmente inclui buscar nos logs do dispositivo de NAT por uma ocorrncia do IP e porta listados na noticao e cuja data e hora estejam em concordncia com os dados da noticao (levando-se em considerao a eventual falta de sincronismo entre os horrios da noticao e dos logs). Os sistemas operacionais incluem uma srie de ferramentas que ajudam nesse desao (no GNU/Linux, por exemplo, existem as ferramentas grep, awk, dentre outras), porm ainda assim esse um processo bastante trabalhoso e, em muitos casos, invivel de ser feito manualmente (principalmente considerando o volume de logs gerado e a insucincia de recursos de segurana nas instituies pessoal e ferramentas j discutidos anteriormente). Todavia, o tratamento dos logs uma etapa totalmente passvel de automatizao desde que o sistema de logging remoto da instituio esteja bem congurado.

2.5

TRABALHOS CORRELATOS

Os incidentes de segurana trazem prejuzos nanceiros e administrativos s instituies envolvidas. No caso dos incidentes gerados por uma instituio, por exemplo, alm do mau uso dos recursos computacionais para realizao de atividades maliciosas, a rede da instituio pode sofrer sanes em outras redes atravs de bloqueios e ltragem dos pacotes originados naquela instituio. Atividades preventivas so importantes para evitar os incidentes de segurana, porm, nem todos eles podem ser evitados. Assim, a capacidade de tratar e responder aos incidentes reportados a uma instituio fundamental para detectar e mitigar as atividades maliciosas, reduzir os gastos e perdas, e prover um retorno organizao que reportou o incidente de que aquelas atividades esto sendo monitoradas e trabalhadas (evitando, assim, que a instituio sofra sanes pela pouca importncia dada noticao ou recorrncia da mesma). No entanto, dado o volume de noticaes recebidas por uma instituio e a falta de recursos humanos para trat-las (em tempo hbil), faz-se necessria a utilizao de ferramentas

28

que automatizem ao mximo o tratamento dos incidentes de segurana, ou, no mnimo, aqueles mais simples. A literatura apresenta uma srie de trabalhos sobre a denio de polticas de segurana e tratamento dos incidentes (CERON et al., 2009; SCARFONE; GRANCE; MASONE, 2008; WERLINGER; BOTTA; BEZNOSOV, 2007; LUNDELL, 2009), porm poucos deles tm se preocupado com a automatizao do tratamento dos incidentes. (SCARFONE; GRANCE; MASONE, 2008) fornece um guia completo para o tratamento de incidentes de segurana, direcionado a times de segurana novos e j estabelecidos. Ele apresenta diretivas para organizao da capacidade de resposta a incidentes de segurana, incluindo a denio das polticas e procedimentos necessrios ao processo de tratamento dos incidentes, informaes para estruturao de um time de resposta a incidentes, aes envolvidas nas fases de tratamento do incidente (desde a preparao at a fase de lies aprendidas) e instrues para tratamento de tipos especcos de incidentes (DoS, cdigo malicioso, acesso no autorizado, dentre outros). Esse guia importante no estabelecimento e manuteno da equipe de segurana de uma instituio, fornecendo uma fundamentao essencial para ecincia e eccia do tratamento de incidentes. Os autores citam a necessidade de automatizao da fase de anlise dos incidentes, recomendando softwares de correlao de eventos e logging remoto, porm no abordam a utilizao de uma nica ferramenta para este m. Em (KAISER et al., 2006) os autores propem um gerenciamento semi-automatizado dos incidentes de segurana, onde aqueles menos importantes devem ser tratados pelo prprio usurio envolvido, ao passo que os incidentes mais srios deveriam ser encaminhados para uma equipe de segurana qualicada. Nesse sentido, para possibilitar ao usurio no especializado tratar um incidente, a instituio deve prover documentao suciente e de forma compreensvel abordando as questes tcnicas e organizacionais relacionadas. Neste trabalho, os autores propem um sistema de gerenciamento de incidentes, o PRISM (Portal for Reporting Incidents and Solution Management), que consiste dos seguintes componentes: um componente que recebe as noticaes no formato IDMEF4 , um componente contendo a lgica para tratamento de incidentes e medidas corretivas relacionadas, e um componente para gerao de pginas web dinmicas apresentando ao usurio as solues indicadas para o incidente reportado. A principal desvantagem dessa soluo exatamente no componente que recebe as noticaes, pois ele est preparado para receber apenas noticaes internas, no preocupando-se, por exemplo, com as questes de mapeamento entre os NATs e as mquinas internas de uma instituio.
4 Motivado pela necessidade de se denir um padro de arquitetura e comunicao para Sistemas de Deteco de Intruso (IDS, do ingls Intrusion Detection System), o IETF, atravs do grupo de trabalho IDWG (Intrusion Detection Working Group) especicou um protocolo, o IDXP (Intrusion Detection Exchange Protocol) (FEINSTEIN; MATTHEWS, 2007), e um formato para troca de alertas entre IDSs, o IDMEF (Intrusion Detection Message Exchange Format) (DEBAR; CURRY; FEINSTEIN, 2007). Apesar de originalmente pensados para sistemas IDS, esses padres tambm so bastante utilizados para noticaes de incidentes de segurana.

29

J (FARNHAM, 2009) apresenta uma soluo proprietria da Cisco, o Cisco Security Agent (CSA) e seu impacto nas vrias fases do tratamento de incidentes. O CSA um sistema de preveno de intruso baseado em hosts (HIPS, do ingls Host Intrusion Prevention System), que pode ser usado tanto em servidores quanto em mquinas clientes. A ideia do CSA ter um agente em cada host e um centro de gerenciamento, que dene as polticas de segurana do host e centraliza o registro de eventos (logging). O software baseado em regras, examinando as atividades do sistema (no agente) e o trfego de rede a m de determinar quais comportamentos so normais e quais podem indicar um ataque. No artigo, o autor analisa a adequao do CSA nas etapas de tratamento de um incidente, usando como estudo de caso o software malicioso Concker5 . Alguns pontos negativos dessa soluo esto relacionados principalmente ao custo de implantao e de sua adequao ambientes heterogneos, como no caso das instituies de ensino e pesquisa. A maioria dos CSIRTs usa sistemas de helpdesk (tambm conhecidos como sistemas de chamados) para tratar seus incidentes, alguns deles com modicaes para melhor atender s demandas do processo de tratamento de incidentes (KAISER et al., 2006). Dois sistemas bem conhecidos so o Request Tracker (RT) (BESTPRACTICAL, 2010a) e o Open Source Ticket Request System (OTRS) (OTRS, 2010). Existe ainda uma extenso para o RT chamada Request Tracker for Incident Response (RTIR) (BESTPRACTICAL, 2010b), que se concentra no tratamento de incidentes de segurana. Uma outra alternativa para o gerenciamento de incidentes o SIRIOS (KLINGMLLER, 2005), que inclui algumas funcionalidades interessantes, como a de gerenciamento de contatos de segurana de uma instituio e a possibilidade de troca de informaes de segurana com outros CSIRTs. Nenhum deles, no entanto, se preocupa especicamente com a automatizao do processo de tratamento e resposta a incidentes.

Concker, tambm conhecido como Downadup ou Kido, um worm que cou bastante conhecido pelo nmero de sistemas que conseguiu infectar ao redor do mundo. Ele explora uma vulnerabilidade conhecida do MS Windows Server (MS08-067) e pode comprometer uma srie de verses do Windows (CWG, 2010).

5O

30

TRAIRA: UMA FERRAMENTA PARA TRATAMENTO DE INCIDENTES DE REDE AUTOMATIZADO

Neste captulo sero apresentados os detalhes envolvidos na implementao da ferramenta de Tratamento de Incidentes de Rede Automatizado, o TRAIRA, proposta deste trabalho. Para isso, inicialmente, ser mostrada uma viso geral sobre a ferramenta, listando seus objetivos e principais funcionalidades; em seguida, apresenta-se a arquitetura do TRAIRA e seu uxo de funcionamento, analisando cada uma das etapas do tratamento de incidentes que executada automaticamente na ferramenta; apresenta-se uma avaliao da eccia do TRAIRA, mostrando, atravs de experimentos controlados, a capacidade do software em tratar e responder aos incidentes reportados; e, por m, sero listados alguns requisitos para a implantao do TRAIRA em uma organizao, abordando desde os recursos necessrios (servidor de logs centralizado, base de informaes sobre os hosts da rede incluindo seus endereos MAC, etc) at sua instalao propriamente dita.

3.1

VISO GERAL DO TRAIRA

O TRAIRA (Tratamento de Incidentes de Rede Automatizado) um software que atua nas duas primeiras fases do tratamento de incidentes de segurana (SCARFONE; GRANCE; MASONE, 2008), a saber, na fase de preparao e na fase de deteco e anlise, de forma a automatizar as atividades trabalhosas que so executadas nessas fases. Na fase de preparao destacam-se duas principais recomendaes de boas prticas: i) a congurao do servio de logging remoto do equipamento de NAT e ii) a utilizao de um sistema de registro sobre a atribuio de IPs, associando-os aos endereos fsicos dos dispositivos de rede: os endereos MAC.

31

J na fase de deteco e anlise, o TRAIRA utiliza os recursos congurados anteriormente para automaticamente extrair as informaes relevantes de uma noticao; buscar por evidncias nos logs do dispositivo de NAT que informem o(s) IP(s) interno(s) responsvel(veis) pela noticao recebida; associar o endereo IP interno um endereo de MAC da mquina, de forma que sua identicao seja nica; gerar relatrios e estatsticas sobre os incidentes recebidos; e responder organizao que reportou o incidente. Ainda, sua arquitetura de funcionamento prev uma extenso desse processo at a fase de conteno, pois permite que a mquina (representada pelo seu endereo MAC) seja bloqueada no switch gerencivel (ou roteador) mais prximo. Essa extenso, no entanto, no est disponvel na primeira verso do TRAIRA, pois no processo de desenvolvimento foram encontrados alguns desaos em sua modelagem que inviabilizaram sua implementao nesse primeiro momento (uma discusso detalhada sobre isso ser fornecida na Subseo 3.2.1 seguinte). Ao nal do tratamento de uma noticao, o TRAIRA gera uma resposta automtica organizao que reportou o incidente e tambm um relatrio detalhado para a equipe de apoio a m de que as medidas cabveis possam ser aplicadas. Durante seu desenvolvimento, o TRAIRA foi idealizado para integrar-se a alguma ferramenta que j fosse utilizada nas instituies, ao invs de ser mais uma ferramenta e um servio a ser mantido (evitando todas as implicaes que isso traz sistema de autenticao, backup, segurana da prpria aplicao, atualizao, etc). Obviamente, muito difcil encontrar uma ferramenta que seja comumente utilizada pelas instituies e ainda permita a integrao com um sistema externo, como o TRAIRA. No caso das instituies de ensino e pesquisa clientes da RNP, uma ferramenta bastante utilizada o Request Tracker (RT), como sistema de helpdesk. O RT permite a adio de novas funcionalidades atravs de extenses, disponibilizando, inclusive, uma extenso para o gerenciamento dos incidentes de segurana, o Request Tracker for Incident Response (RTIR) discutido em mais detalhes na Subseo 3.2.3 a seguir. Na seo seguinte, a arquitetura de funcionamento do TRAIRA ser apresentada em maiores detalhes.

3.2

ARQUITETURA DO TRAIRA

A arquitetura do TRAIRA apresentada na Figura 3.1. Nessa gura, os componentes em formato de elipse (na cor azul) representam os mdulos que foram desenvolvidos como parte do TRAIRA e os componentes em formato de retngulo (na cor cinza) representam softwares ou recursos externos necessrios ao funcionamento do TRAIRA. O software desenvolvido como uma extenso do RT, permitindo que o tratamento dos incidentes de segurana seja feito tanto

32

Figura 3.1: Viso geral da arquitetura do TRAIRA pela interface web, onde o usurio fornece manualmente a noticao do incidente, quanto via e-mail quando a organizao que reporta o incidente envia uma mensagem para um endereo de e-mail especialmente designado para este m. A linguagem de programao utilizada o Perl1 , com a qual o prprio RT escrito. Em sua primeira verso, possui aproximadamente 2.500 linhas de cdigo entre interfaces de usurio, ncleo da aplicao, mdulos de interface com recursos externos (logs, tabela de endereos MACi, etc) e demais componentes, sendo implementado por 01 desenvolvedor em cerca de 30 dias. O TRAIRA distribudo sob a licena GPLv2 ou superior2 e encontra-se disponvel para download em (TRAIRA, 2010). O TRAIRA composto por cinco mdulos (objetos em formato de elipse com preenchimento azul na Figura 3.1), conforme listado abaixo e detalhado a seguir (na Subseo 3.2.1): Parser: o mdulo responsvel pelo recebimento da noticao e pela extrao das informaes essenciais ao tratamento do incidente: endereo IP e porta de origem, data e horrio. NAT Mapping: este mdulo utiliza as informaes extradas pelo parser e realiza uma busca nos logs do dispositivo de NAT para associar a tupla <data, hora, IP, porta> a um endereo IP interno, responsvel de fato pelo incidente. IP2MAC: aqui feita a associao do IP interno ao endereo MAC da mquina. Esse passo importante em instituies que utilizam o DHCP, pois um IP pode ter sido usado por mais de uma mquina ao longo do tempo.
uma linguagem de programao interpretada, multiplataforma e bastante usada no processamento de cadeias de caracteres (strings), manipulao de texto e casamento de padres (atravs de expresses regulares) (PERL.ORG, 2010). 2 GPL uma sigla usada para GNU Public License, uma licena de software livre especicada pela Free Software Foundation.
1 Perl

33

Post-Detection: Este mdulo responsvel pela extrao de dados da noticao e do tratamento realizado a m de gerar estatsticas sobre os incidentes, gerar relatrios equipe de helpdesk (para, por exemplo, efetuar o isolamento e desinfeco da mquina) e responder instituio que reportou o incidente. Containment: Neste mdulo feito o isolamento do host que causou o incidente para evitar que ele continue com a atividade maliciosa na rede ou afete outros recursos. Dessa forma, o tratamento de incidentes que podem ser automatizados pelo TRAIRA segue o seguinte uxo de trabalho: 1. Uma entidade submete uma noticao ao TRAIRA reportando um problema de segurana. Essa noticao deve conter evidncias sucientes para comprovar a atividade maliciosa, incluindo, no mnimo, o endereo IP e porta de origem, data e hora que ocorreu o incidente (alm do timezone). A entidade que reporta incidentes pode ser materializada nos CSIRTs (CAIS, CERT.Bahia, CERT.br, etc), em sensores de monitoramento de atividades maliciosas (IDSs, honeypots, etc) ou at mesmo em usurios que submetem incidentes atravs da interface web; 2. O TRAIRA verica se existe um parser denido para aquela noticao e, caso exista, extrai os dados importantes da noticao e passa para a etapa de deteco da mquina interna. Caso no exista um parser denido, a noticao permanecer em aberto no RT aguardando pelo tratamento manual da equipe de segurana; 3. Usando os dados extrados da noticao (tupla <data, hora, IP, porta>) feita uma busca nos logs do dispositivo de NAT para determinar qual o IP interno utilizou o IP e porta reportados; 4. Uma nova busca feita; agora para mapear o IP interno em um endereo MAC da mquina que causou o incidente; 5. De posse do endereo MAC, o TRAIRA notica a equipe de helpdesk para que possa tomar as medidas cabveis; 6. Uma resposta automtica enviada instituio que reportou o incidente informando que a mquina foi detectada e que os procedimentos de desinfeco j foram iniciados (no caso de mquinas infectadas com vrus/worm, por exemplo). Como se pode perceber, o TRAIRA automatiza todo o processo inicial de tratamento de incidentes de segurana. No obstante, o tratamento de um incidente ainda no est completo

34

com os passos acima, e o TRAIRA deixa a cargo do administrador denir a prxima providncia a ser tomada (por exemplo, desinfectar uma mquina contaminada com vrus/worm ou aplicar as medidas administrativas cabveis uma violao de copyright). Vale destacar, no entanto, que, dado o volume de noticaes que uma instituio recebe e a falta de equipe suciente para responder s noticaes, essa etapa de deteco muitas vezes nem chega a ser iniciada. Assim, o TRAIRA proporciona uma importante contribuio para o processo de tratamento e resposta aos incidentes de segurana de uma instituio. As etapas descritas acima so executadas de forma on-line, ou seja, assim que um incidente reportado ao TRAIRA, o tratamento iniciado. A durao do tratamento vai depender da capacidade computacional (processador e acesso a disco) do servidor em que o TRAIRA esteja instalado. Na subseo seguinte, sero apresentados os mdulos do TRAIRA listados anteriormente.

3.2.1

MDULOS DO TRAIRA

Nesta subseo sero apresentados em detalhes os mdulos do TRAIRA, representados na Figura 3.1 pelos componentes em formato de elipse (na cor azul), e o papel de cada um deles no tratamento dos incidentes de segurana. PARSER O parser o mdulo responsvel pelo recebimento da noticao e pela extrao das informaes essenciais ao tratamento do incidente: endereo IP e porta de origem, data e horrio. Este mdulo pode ser iniciado de duas formas: quando da chegada de uma nova noticao de incidente de segurana no RT (via e-mail ou pela interface web) ou quando um usurio privilegiado do TRAIRA fornece manualmente a noticao. Caso a noticao seja fornecida manualmente, o usurio dever informar tambm qual parser dever ser usado; caso a noticao tenha sido criada no RT via e-mail ou pela interface web, o TRAIRA selecionar automaticamente um dos parsers previamente cadastrados para trat-la. A escolha do parser relativo uma noticao feita a partir de uma conjuno considerandose os campos remetente (From) e assunto (Subject) da noticao. Assim, caso a noticao tenha sido reportada por um certo e-mail e siga um certo padro no assunto, o parser ser aplicado sobre essa noticao. Caso contrrio, o processo de tratamento automatizado do incidente abortado e a noticao ca em um estado pendente no RT, para tratamento manual da equipe de segurana. O cadastro de novos parsers e a denio do cdigo de extrao dos

35

dados da noticao so feitos na prpria interface do TRAIRA (RT), e devem ser escritas na linguagem Perl. Como exemplo de utilizao desse mdulo, considere uma noticao de incidente de segurana reportada pelo CERT.Bahia instituio InstituicaoTeste. Essa noticao, enviada por e-mail, segue um certo padro de formatao por parte da equipe do CERT.Bahia, que pode ser observado na Listagem 3.1. Listagem 3.1: Exemplo de noticao enviada pelo CERT.Bahia para InstituicaoTeste
S u b j e c t : A v i s o de d e t e c c a o de V i r u s / Worm com o r i g e m em 2 0 0 . 1 2 8 . 9 9 . 1 ( I n s t i t u i c a o T e s t e ) From : PoPBA S e c u r i t y Team < i n c i d e n t e s @ p o p ba . r n p . br > To : I n s t i t u i c a o T e s t e CSIRT < s e c u r i t y @ i n s t i t u i c a o t e s t e . edu . br > Prezado ( a ) responsavel pela I n s t i t u i c a o T e s t e , O e n d e r e c o I P 2 0 0 . 1 2 8 . 9 9 . 1 f o i d e t e c t a d o como p o s s i v e l m e n t e i n f e c t a d o e p r o p a g a n d o v i r u s . Abaixo seguem a l g u m a s e v i d e n c i a s c o l e t a d a s : 53164 | 2 0 0 . 1 2 8 . 9 9 . 1 | 2010 03 31 2 2 : 5 0 : 2 0 s r c p o r t 51774 | (GMT 3) | PoPBA/ RNP 53164 | 2 0 0 . 1 2 8 . 9 9 . 1 | 2010 04 01 1 0 : 3 8 : 1 1 s r c p o r t 59441 | (GMT 3) | PoPBA/ RNP 53164 | 2 0 0 . 1 2 8 . 9 9 . 1 | 2010 04 01 1 0 : 5 8 : 0 0 s r c p o r t 59441 | (GMT 3) | PoPBA/ RNP 53164 | 2 0 0 . 1 2 8 . 9 9 . 1 | 2010 04 01 1 3 : 1 0 : 3 0 s r c p o r t 24475 | (GMT 3) | PoPBA/ RNP Pedimos a g e n t i l e z a de v e r i f i c a r . Caso t e n h a alguma d u v i d a , f a v o r e n t r a r em c o n t a t o . Atenciosamente , CERT . B a h i a : : Grupo de R e s p o s t a a I n c i d e n t e s de S e g u r a n c a da B a h i a / B r a s i l PoPBA/ RNP : : P o n t o de P r e s e n c a da RNP na B a h i a T e l . : +55 71 3283 6098

A Tabela 3.1 mostra um exemplo de denio de parser que pode ser utilizado para as noticaes que atendem quele padro. Na criao do chamado no RT para a noticao acima, o mdulo Traira::Parser tentar fazer a correspondncia dos campos From e Subject com o denido no parser. Note que os valores denidos no parser so, na verdade, expresses regulares e portanto toleram pequenas variaes entre as noticaes (endereo IP no Subject, por exemplo). Em seguida, para cada linha da noticao, o cdigo do parser executado, retornando a tupla <data, hora, IP, porta> que ser usada na prxima etapa da noticao. Note ainda a utilizao do mtodo Traira::Parser->AdjustTimezone, cujo objetivo ajustar a data e hora enviados na noticao com aquelas conguradas no sistema. Por exemplo, no caso das noticaes enviadas pelo CERT.Bahia, o timezone usado o GMT-3 (ou BRT ). Suponha agora que a instituio que recebeu o incidente armazena os logs do dispositivo de NAT no formato GMT. Nessa situao, a data/horrio reportados na noticao devero ser somados de trs horas para que os registros de eventos estejam sincronizados. O timezone

36

Tabela 3.1: Parser para noticaes enviadas pelo CERT.Bahia

From Subject

incidentes@pop-ba.rnp.br Aviso de deteccao de Virus/Worm com origem em [0-9.]{7,15} \(InstituicaoTeste\) my my my my $IP = '[0-9.]{7,15}'; $DATE = '[0-9-]{10}'; $TIME = '[0-9:]{8}'; $PORT = '[0-9]+';

Cdigo do parser

if ($line =~ /^53164 \| ($IP) \| ($DATE) ($TIME) srcport ($PORT)\b.*$/) { my ($date, $time) = $self->AdjustTimezone($2, $3, '-0300'); return ($date, $time, $1, $4); } return undef;

utilizado pela instituio congurvel pela interface web do TRAIRA (RT). O resultado da execuo do mdulo Traira::Parser sobre aquela noticao (Listagem 3.1) mostrado na Tabela 3.2. Observe, por exemplo, os ajustes de horrios que foram necessrios devido diferena de timezone utilizada, inclusive modicando o dia da ocorrncia de um dos eventos. Tabela 3.2: Resultado da execuo do mdulo Traira::Parser sobre a noticao da Listagem 3.1 # 1 2 3 4 Data 2010-04-01 2010-04-01 2010-04-01 2010-04-01 Hora 01:50:20 13:38:11 13:48:00 16:10:30 IP externo Porta externa 200.128.99.1 51774 200.128.99.1 59441 200.128.99.1 59441 200.128.99.1 24475

A denio de parsers especializados permite tratar um grande nmero de incidentes de forma automatizada, pois a maioria deles inclui as informaes necessrias j listadas. Nesse sentido, pode-se armar que o TRAIRA adaptvel para novos tipos de incidentes, sendo necessrio, apenas, denir um novo parser para a noticao recebida. NAT MAPPING Apesar de suas desvantagens (EGEVANG; FRANCIS, 1994, Seo 4), o NAT uma tcnica bastante utilizada pelas instituies de ensino e pesquisa conectadas Internet, principalmente pela possibilidade de economia de endereos IPv4 e ocultao da topologia da rede interna. Por outro lado, sua utilizao traz implicaes no tratamento de incidentes de segurana, uma vez que o endereo listado na noticao no representa diretamente a mquina da rede interna que realmente causou o incidente. Nesse caso, faz-se necessrio um mapeamento entre o IP e porta

37

listados na noticao e o IP interno que causou o incidente. Para esse mapeamento, o mdulo

Traira::NATMapping utiliza as informaes extradas pelo parser e as correlaciona aos logs

do(s) dispositivo(s) de NAT, retornando o(s) IP(s) internos responsveis pela noticao. O processo de correlacionar essas duas entradas, no entanto, no uma tarefa simples, pois deve-se levar em considerao a grande diversidade de dispositivos de NAT disponveis (e cada um deles gera os logs de forma particular), o grande volume de dados a serem processados e, ainda pior, a correspondncia entre a data/horrio que listado na noticao e aqueles listados nos logs. No caso da data/horrio, dois pontos exigem maior ateno: i) difcil, na prtica, manter relgios sincronizados (principalmente porque a entidade que reporta incidentes no tem essa obrigao); ii) uma traduo NAT possui durao temporal e seu registro nos logs do servidor no representa diretamente o momento em que ela ocorreu sabe-se, todavia, que foi no instante em que o evento foi registrado no log menos a durao do NAT (por exemplo, se o log foi registrado s 16:31:11 e o NAT possui durao de 120 segundos, ento a traduo ocorreu s 16:29:11, considerando o horrio do servidor de logs). Listagem 3.2: Exemplos de logs de tradues NAT no rewall ASA da Cisco
1 2 3 4 Apr Apr Apr Apr 1 0 1 : 5 0 : 5 4 1 7 2 . 1 6 . 2 5 4 . 1 %ASA 0 305012: Teardown dynamic UDP t r a n s l a t i o n from int_in :10.1.0.8/51386 to int_out :200.128.99.1/51774 duration 0:00:30 1 1 3 : 3 9 : 5 6 1 7 2 . 1 6 . 2 5 4 . 1 %ASA 0 305012: Teardown dynamic TCP t r a n s l a t i o n from int_in :192.168.0.37/60523 to int_out :200.128.99.1/59441 duration 0:02:30 1 1 3 : 5 0 : 5 7 1 7 2 . 1 6 . 2 5 4 . 1 %ASA 0 305012: Teardown dynamic TCP t r a n s l a t i o n from int_in :10.2.0.44/50071 to int_out :200.128.99.1/59441 duration 0:03:00 1 1 6 : 1 2 : 2 8 1 7 2 . 1 6 . 2 5 4 . 1 %ASA 0 305012: Teardown dynamic UDP t r a n s l a t i o n from int_in :10.1.10.9/60818 to int_out :200.128.99.1/24475 duration 0:02:21

Como exemplo para o problema supracitado, considere os logs exibidos na Listagem 3.2 (com timezone em GMT ) extrados de um ambiente experimental da instituio InstituicaoTeste, que utiliza o rewall ASA da Cisco (CISCO, 2005). Nesse ambiente, todas as mquinas da rede interna acessam a Internet atravs de um nico IP de NAT (200.128.99.1). Aps receber uma noticao de incidente de segurana do CERT.Bahia, Listagem 3.1, e extrair as informaes mais importantes desta noticao (atravs do parser), Tabela 3.2, necessrio buscar nos arquivos de logs pelo endereo IP interno que gerou cada um dos incidentes. Nesse exemplo, ca claro que no suciente ltrar pelo endereo IP e porta nos logs, pois o endereo

200.128.99.1:59441, por exemplo, aparece listado duas vezes tanto na noticao quanto nos
logs, inviabilizando a distino entre os eventos apenas com esse ltro simples. preciso considerar tambm a data e horrio em que a conexo aconteceu. Analisando, por exemplo, a tupla 3 da Tabela 3.2, os logs apresentam dois candidatos a responsvel por aquele incidente: uma traduo que terminou s 13:39:56 e teve durao de 00:02:30, ou seja, iniciou s 13:37:26 e terminou s 13:39:56, e uma segunda traduo que reaproveitou a porta de origem ante-

38

rior porm nalizou s 13:50:57, com durao de 00:03:00, ou seja, iniciou s 13:47:57 e terminou s 13:50:57. A partir do clculo e anlise desses intervalos, possvel identicar

10.2.0.44 como o endereo IP interno responsvel pelo incidente.

Ainda sobre o exemplo anterior, encontra-se nele uma situao em que a falta de sincronismo entre os relgios pode prejudicar o tratamento de incidentes. Tomando a tupla 1 da Tabela 3.2 e buscando por ocorrncias daquele IP/porta nos logs a nica entrada retornada ser referente a uma conexo NAT que iniciou-se 01:50:24 e terminou 01:50:54. Contudo, o horrio reportado na noticao informa que o incidente ocorreu 01:50:20. Nesse caso, no se pode simplesmente invalidar a ocorrncia do incidente, deve-se levar em considerao a falta de sincronismo entre os relgios. Para resolver esse problema, preciso adicionar uma tolerncia temporal ao intervalo de durao do NAT listado nos logs. O Traira::NATMapping atualmente utiliza uma tolerncia de 10 segundos para mais ou para menos. A denio do valor de tolerncia temporal mais adequado para uma instituio vai depender das caractersticas da rede. Um fator obrigatrio a ser observado nessa denio a relao de mquinas da rede interna por IP de NAT: quanto mais mquinas so associadas a um nico NAT, maior ser a taxa de reaproveitamento de portas e, consequentemente, menor poder ser a tolerncia diferena nos relgios. Para tratar da diversidade na utilizao de dispositivos de NAT nas instituies, e at mesmo internamente uma instituio (com diferentes dispositivos de NAT por segmento de rede), o mdulo Traira::NATMapping foi desenvolvido de forma que seja possvel denir um dispositivo de NAT para cada segmento de rede (levando-se em considerao a sobreposio entre segmentos) e um dispositivo padro a ser usado caso no haja uma denio especca para determinado segmento de rede. Por exemplo, o administrador pode denir que a rede

200.128.99.0/24 utiliza o ASA/Cisco, j a rede 200.128.196.0/23 utiliza IPTables/Netlter com exceo da sub-rede 200.128.197.0/28 que tambm utiliza ASA/Cisco e, nalmente, a rede 200.128.199.0/24 no utiliza NAT. Note que o mapeamento acima sobre uma viso externa ou, mais especicamente, considerando os dados da noticao. Essa exibilidade de congurao permite, por exemplo, denir as redes privadas (REKHTER et al., 1996) como sem NAT, o que viabiliza tambm o tratamento de incidentes internos (sensores na rede interna). O tratamento dos logs de NAT de cada dispositivo no Traira::NATMapping feito atravs de handlers (manipuladores), que so sub-mdulos especcos por dispositivo. Os handlers so responsveis pelas operaes de busca nos logs e pela denio do formato de alguns campos de um registro de log. Por exemplo, o formato do par IP/porta externo (ou traduzido) no ASA/Cisco IP/porta, ao passo que no NFCT-SNATLOG/IPTables (Captulo 4)

39

t-src=IP t-spt=porta.
Na congurao do TRAIRA, o administrador dever informar, para cada segmento de rede que est sujeito a receber noticao (redes externas para sensores externos e redes internas para sensores internos), o dispositivo de NAT daquela rede e a localizao do arquivo de log no sistema de arquivos. Por exemplo, retomando o cenrio citado acima, teramos a congurao mostrada na Tabela 3.3. Os caracteres especiais %Y, %m e %d na denio do arquivo de log sero expandidos para o ano (formato YYYY), ms (01..12) e dia (01..31) do incidente reportado, respectivamente. Tabela 3.3: Exemplo de congurao do mdulo NATMapping do TRAIRA
Rede 200.128.99.0/24 200.128.196.0/23 200.128.197.0/28 200.128.199.0/24 NATMapping Traira::NATMapping::asa_cisco Traira::NATMapping::iptables Traira::NATMapping::asa_cisco Traira::NATMapping::none Arquivo de log /var/log/local4-%Y%m%d.log /var/log/nfct-snatlog-%Y-%m-%d.log /var/log/local4-%Y%m%d.log

O resultado da execuo do mdulo Traira::NATMapping mostrado na Tabela 3.4, que consiste dos dados iniciais extrados pelo parser substituindo-se o par IP-externo/porta-externa pelo respectivo IP interno associado cada incidente. Tabela 3.4: Resultado da execuo do mdulo Traira::NATMapping sobre os incidentes da Tabela 3.2 # 1 2 3 4 Data 2010-04-01 2010-04-01 2010-04-01 2010-04-01 Hora IP interno 01:50:20 10.1.0.8 13:38:11 192.168.0.37 13:48:00 10.2.0.44 16:10:30 10.1.10.9

IP2MAC O protocolo DHCP permite a atribuio de endereos IP dinamicamente s mquinas da rede. Ao receber tal endereo, o host recebe tambm um parmetro de tempo, denindo o perodo de validade daquele endereo (tempo de concesso, do ingls, lease time). Vencido o lease time, o host deve inutilizar o endereo ou renov-lo junto ao servidor DHCP. Como consequncia, possvel que um mesmo host possua diferentes endereos IP ao longo do dia, da semana ou do ms, dependendo do lease time congurado. Como essa uma funcionalidade bastante til e comum nas instituies, usar somente o IP para identicar um host pode produzir resultados inconsistentes. Faz-se necessrio um mecanismo nico de identicao do dispositivo, no

40

mnimo, no contexto da rede interna da instituio. A identicao utilizada pelo TRAIRA o endereo MAC, escolhido pela unicidade terica que oferece e pela facilidade de mapeamento entre endereos IP e MAC (PLUMMER, 1982). O mecanismo utilizado atualmente para esse mapeamento entre endereos IP e MAC atravs do Address Resolution Protocol (ARP) (PLUMMER, 1982). Em linhas gerais, o funcionamento do protocolo ARP baseia-se no envio de requisies em broadcast contendo o endereo IP do host alvo e resposta em unicast com o respectivo endereo MAC. Para diminuir o nmero de mensagens desse tipo na rede, utiliza-se um mecanismo de cache, conhecido como cache da tabela ARP. Assim, bastaria consultar a tabela ARP dos equipamentos de roteamento da rede para saber o endereo MAC associado a cada endereo IP em uso. Entretanto, a tabela ARP dinmica e, dessa forma, no mantm o histrico de utilizao da rede. Faz-se necessrio, ento, um software que mantenha o histrico sobre a resoluo de endereos IP para MAC da rede, a m de salvaguardar a informao do endereo IP em uso por determinado endereo MAC em determinado momento. O esquema de resoluo de IPs para MACs utilizado pelo TRAIRA vem de um software desenvolvido pela UFBA, em parceria com o CERT.Bahia, para o gerenciamento e documentao dos endereos de camada 2: o Layer 2 Manager (L2M) (BEZERRA, 2009). Ele permite, atravs de uma interface web, realizar uma srie de consultas para um host (tanto via endereo IP quanto via endereo MAC) e obter o histrico de acesso desse host na rede, com horrio de entrada e sada. Alm disso, pode-se consultar quantas mquinas utilizam a rede em determinado momento ou, por exemplo, nos ltimos 15 dias. possvel tambm realizar consultas diretamente ao banco de dados do L2M, com algumas funes SQL disponibilizadas com o software. Dessa forma, o mdulo Traira::IP2MAC recebe uma lista de endereos IP internos com data e horrio de acesso rede e retorna o endereo MAC que estava associado quele endereo IP naquele momento. Para isso, o Traira::IP2MAC consulta o banco de dados do L2M ou verica uma tabela esttica de IPs/MACs congurada no prprio TRAIRA. Recomenda-se, no entanto, a utilizao do L2M nesse processo, pois o valor agregado com aquela ferramenta bem maior, alm da dinamicidade que esse mapeamento pode exigir (entrada de novos hosts na rede) e que coberto pelo L2M. Voltando ao exemplo de noticao de incidente de segurana usado anteriormente, aps a execuo do mdulo Traira::IP2MAC, obtm-se o resultado apresentado na Tabela 3.5, que contm agora o endereo MAC da mquina que causou cada incidente e a VLAN a que ela pertence (caso esta informao esteja disponvel).

41

Tabela 3.5: Resultado da execuo do mdulo Traira::IP2MAC sobre os endereos internos listados na Tabela 3.4 # 1 2 3 4 Data 2010-04-01 2010-04-01 2010-04-01 2010-04-01 Hora 01:50:20 13:38:11 13:48:00 16:10:30 IP interno 10.1.0.8 192.168.0.37 10.2.0.44 10.1.10.9 MAC VLAN 00:16:3e:ef:dc:6b Rede_Lab1 00:16:3e:ad:1c:6e Rede_InstA 00:16:3e:bb:2a:3b Rede_Wireless 00:16:3e:fa:ca:1a Rede_Lab2

POST-DETECTION Aps o processo de deteco e anlise do incidente de segurana, detalhado nas subsees anteriores, a etapa seguinte consiste em extrair dados da noticao e do tratamento que facilitem gerar de estatsticas, gerar relatrios para a equipe de helpdesk que ser responsvel, por exemplo, pelo processo de isolamento e desinfeco das mquinas, e responder organizao que reportou o incidente, atualizando-a sobre o sucesso ou falha no tratamento da noticao enviada. A Listagem 3.3 ilustra um exemplo de e-mail enviado equipe de helpdesk sobre um dos incidentes dos exemplos anteriores (tupla 1 da Tabela 3.5). De posse dessa noticao, a equipe poder efetuar o bloqueio do MAC no switch gerencivel ou roteador mais prximo do host e proceder com sua desinfeco. Listagem 3.3: Exemplo de e-mail enviado equipe de helpdesk para bloqueio/desinfeco do host
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Atenciosamente , TRAIRA : : T r a t a m e n t o de I n c i d e n t e s de Rede A u t o m a t i z a d o . I n s t i t u i c a o T e s t e CSIRT 1 0 . 1 . 0 . 8 | 0 0 : 1 6 : 3 e : e f : dc : 6 b | Rede_Lab1 Segue a b a i x o uma r e l a c a o < I P | MAC | VLAN> d a s m a q u i n a s d e t e c t a d a s como p o s s i v e l m e n t e c o m p r o m e t i d a s com v i r u s / worm . F a v o r r e a l i z a r o t r a t a m e n t o d a s m a q u i n a s ( ex : a n t i v i r u s , e t c . ) . Prezados , S u b j e c t : S o l i c i t a c a o de b l o q u e i o / d e s i n f e c c a o de maquina com v i r u s / worm From : I n s t i t u i c a o T e s t e CSIRT < s e c u r i t y @ i n s t i t u i c a o t e s t e . edu . br > To : H e l p d e s k I n s t i t u i c a o T e s t e < h e l p d e s k @ i n s t i t u i c a o t e s t e . edu . br >

Em seguida, o TRAIRA atualiza o chamado de incidente de segurana que foi aberto no RT, informando organizao que o reportou sobre o estado atual do tratamento da noticao. Esse

42

passo naliza a interao com a organizao que reportou o incidente; as aes seguintes tero interesse apenas para o controle interno da instituio (medidas tomadas, lies aprendidas, etc). CONTAINMENT Este mdulo prev que seja feito um isolamento do host infectado para evitar que ele continue com a atividade maliciosa na rede ou comprometa outros recursos. O isolamento pode se dar de vrias maneiras: desligamento da mquina, remoo do cabo de rede, desabilitando certos recursos do sistema, ou ainda bloqueando-a no dispositivo de rede gerencivel mais prximo. Essa ltima alternativa mais interessante do ponto de vista de automatizao do processo. Uma outra abordagem, ainda mais atrativa, proposta em (KAISER et al., 2006), , em vez de simplesmente bloquear a mquina no switch ou roteador da rede, direcion-la uma VLAN de quarentena, onde todas as requisies do usurio seriam direcionadas para uma pgina web com uma nota de que a mquina est possivelmente comprometida e apresentando recomendaes para desinfeco. Durante o desenvolvimento do TRAIRA, optou-se inicialmente apenas por bloquear o host no equipamento de rede gerencivel mais prximo, porm essa abordagem apresentou uma srie de desaos, o principal deles foi no que tange diversidade de equipamentos encontrados na UFBA, instituio usada como piloto para a implantao. A diversidade concretizada, por exemplo, nos comandos a serem executados no switch para bloquear um MAC. Essa diversidade, no entanto, uma caracterstica que provavelmente ser encontrada em outras instituies que utilizarem o TRAIRA, portanto, faz-se necessria uma soluo que seja adaptvel e extensvel a novos ambientes. Por esse motivo, deniu-se como trabalho futuro utilizar uma linguagem de comandos de switches que abstraia a sintaxe especca da cada equipamento, usando-a para efetuar o isolamento dos hosts.

3.2.2

GERAO DE ESTATSTICAS

Um recurso fundamental aos grupos de resposta a incidentes de segurana (CSIRTs) so as estatsticas (ARVIDSSON et al., 2001). Elas ajudam os CSIRTs a detectar tendncias, prever futuros ataques em grande escala, direcionar atividades, dentre outros.

43

Figura 3.2: Tela do TRAIRA para exibio de relatrios/estatsticas A implementao atual do TRAIRA fornece algumas estatsticas geradas automaticamente a partir de informaes retiradas da noticao recebida e do tratamento efetuado. A Figura 3.2 mostra a tela do TRAIRA para exibio de estatsticas (relatrios), baseadas em dados experimentais. Naquela gura tem-se as seguintes estatsticas: Grco de incidentes por VLAN. Esse grco ressalta as VLANs que mais impactam na gerao de incidentes de segurana, o que permite direcionar medidas de preveno especcas; Quantidade de incidentes por dia. Esse um grco quantitativo que pode ser usado para medir a efetividade do tratamento de incidentes de segurana na instituio. Ele lista os incidentes que so reportados versus aqueles que foram resolvidos. O esperado que a linha de incidentes resolvidos se aproxime da linha dos incidentes reportados e elas tendam a cair (a menos que haja implantao de novos sensores); MACs reincidentes. Esta estatstica pode ser usada como indicador qualitativo do tratamento de incidentes, quando observa-se reincidncia na gerao de incidentes em determinado host. A interpretao desse dado pode levar a uma srie de hipteses, por exemplo: a fase de isolamento e desinfeco no est sendo ecaz; no caso dos inciden-

44

tes de vrus/worm pode indicar inexperincia do usurio no uso do recurso, propiciando novas infeces com facilidade; dentre outros.

3.2.3

INTEGRAO COM O RT

O Request Tracker (RT) um sistema de chamados, de distribuio livre, que permite interao via e-mail e via interface web. Bastante utilizado para gerncia de problemas (funcionando como um sistema de gesto de chamados para helpdesk) ou para gerncia de bugs, o RT tambm possui uma extenso para gerncia de incidentes de segurana: o Request Tracker for Incident Response (RTIR). Alm das funcionalidades bsicas de controle de acesso e agrupamento de chamados por categorias atravs de las, o RT possibilita denir campos personalizados que so teis para indexar informaes mais importantes de um chamado, facilitando a gerao de buscas para composio de estatsticas. Essas caractersticas, em conjunto com outras no listadas aqui, foram decisivas na escolha do RT como ferramenta base para o TRAIRA. Para habilitar o TRAIRA no RT basta, a partir de uma instalao funcional do RT, instalar a extenso RT::Extension::Traira (disponvel em (TRAIRA, 2010)) e congur-lo via interface web. A congurao consiste basicamente em denir uma la do RT que ser usada especicamente para os incidentes de segurana (o que viabiliza utilizar o RT no somente para o tratamento de incidentes de segurana, mas tambm para outras categorias, ou mesmo aproveitar um ambiente j em produo da instituio); denir a congurao do dispositivo NAT (qual dispositivo de NAT usado por rede e a localizao do arquivo de log daquele dispositivo); denir o timezone que usado no sistema; denir a forma de mapeamento dos IPs e MACs (e os parmetros de acesso ao L2M, se for o caso); registrar os parsers; dentre outras conguraes opcionais. Finalizada a congurao, o TRAIRA estar preparado para efetuar o tratamento automtico dos incidentes de segurana criados na la denida anteriormente e que sejam atendidos por um determinado parser. Todavia, o tratamento de um incidente de segurana no se restringe s etapas cobertas pelo TRAIRA (deteco e anlise, e isolamento): necessrio ainda um gerenciamento sobre tais incidentes. Gerenciar um incidente, nesse contexto, est atrelado todo o uxo de trabalho e processo de resposta a incidente que os CSIRTs devem seguir (SCARFONE; GRANCE; MASONE, 2008). Nesse sentido, acredita-se que o TRAIRA pode integrar-se facilmente ao RTIR, utilizando as recursos desse ltimo aps o tratamento inicial que o TRAIRA realiza. Um trabalho futuro consiste, portanto, em avaliar a integrao entre essas duas ferramentas e as vantagens dessa abordagem.

45

Figura 3.3: Cenrio utilizado nos experimentos do TRAIRA

3.3

AVALIAO EXPERIMENTAL

Para medir a eccia da proposta, foram realizados alguns experimentos na rede do Departamento de Cincia da Computao da UFBA (DCC/UFBA). O objetivo dos experimentos foi gerar uma srie de incidentes de segurana em um ambiente controlado e vericar se eles seriam corretamente tratados pelo TRAIRA. Dessa forma, tratando-se de um ambiente controlado, saberia-se a priori as mquinas que deveriam ser listadas em cada incidente que fosse tratado. Para realizao dos testes, fez-se uma parceria com o CERT.Bahia para atacar propositalmente alguns de seus sensores e receber as noticaes de incidentes, nesse caso simulando mquinas infectadas com vrus/worm. As noticaes no CERT.Bahia so agrupadas por endereo IP de origem. Portanto, para que fosse possvel gerar mais de uma noticao, o endereo IP do NAT variou entre dez endereos possveis. A Figura 3.3 ilustra o cenrio utilizado nos experimentos. Naquela gura, cada uma das mquinas da rede interna (sete mquinas: host 1..host 7) ataca as portas 445 (Compartilhamento do Windows), 139 (NetBIOS) e 22 (SSH) dos sensores (na Internet). A escolha das portas foi baseada naquelas mais utilizadas por atacantes, segundo estatsticas do CERT.Bahia (CERT.BAHIA, 2010b). O ataque foi feito utilizando o utilitrio nmap, atravs do comando nmap -p 445,139,22 xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx so os IPs dos sensores, omitidos por questes de segurana). Como resultado do suposto ataque, dez noticaes de incidentes de segurana (uma para cada IP de NAT) foram enviados pelo CERT.Bahia para o e-mail do responsvel pela rede em questo (security@dcc.ufba.br). O e-mail security@dcc.ufba.br foi congurado para redirecionar as mensagens ao RT, a m de que o tratamento dos incidentes de segurana fossem realizados pelo TRAIRA. Analisando os resultados do tratamento efetuado pelo TRAIRA, ele foi capaz de detectar,

46

em cada noticao recebida, sete mquinas da rede interna como responsveis pelos incidentes e identicar cada uma dessas mquinas. Foram enviados dez e-mails ao CERT.Bahia, em resposta a cada uma das noticaes, e dez e-mails para a equipe de operao, solicitando a desinfeco de sete mquinas (cada um dos e-mails continha as mesmas mquinas, gerando duplicidade nesse caso especco). Assim, pode-se considerar que o TRAIRA foi ecaz no tratamento dos incidentes de segurana reportados. Entretanto, caso o TRAIRA no fosse capaz de tratar um determinado incidente de forma automtica, a equipe de segurana no teria perda alguma: a noticao continuaria pendente de tratamento manual no RT. Alm dos experimentos realizados, o TRAIRA encontra-se em fase de homologao na UFBA, onde ser usado como base para o processo de tratamento de incidentes de segurana da instituio. Na verdade, antes da adoo do TRAIRA, a UFBA j utilizava uma srie de scripts que tratavam os incidentes de vrus/worm enviados pelo CERT.Bahia, porm estend-los para tratar outros tipos de incidentes (ou incidentes em outro formato) no era uma tarefa simples e, ainda, no existia gerao de relatrios automatizada. Atualmente, para tratar outros incidentes, basta cadastrar um novo parser no TRAIRA. Sobre os relatrios, a interface do TRAIRA j apresenta alguns relatrios pr-congurados, mas tambm possvel denir novos grcos a partir de buscas conguradas no RT.

3.4

REQUISITOS PARA IMPLANTAO DO TRAIRA

Como j foi discutido nas sees anteriores, o TRAIRA necessita que alguns recursos sejam congurados na rede antes do incio do tratamento de incidentes de segurana, ainda na fase de preparao. No obstante, alguns desses recursos j deveriam fazer parte da infraestrutura de segurana da instituio ou, do contrrio, seria impossvel tratar os incidentes reportados (com exceo de alguns casos especcos e incomuns como, por exemplo, da no utilizao de NAT e distribuio esttica de endereos na rede interna). Abaixo uma listagem dos recursos necessrios ao correto funcionamento do TRAIRA. Registro remoto dos eventos de traduo de NAT (SNAT). Para as instituies que utilizam NAT para traduo de endereos da rede interna no acesso Internet (SNAT), necessrio que o dispositivo de NAT faa o registro (logging) das tradues incluindo informaes sobre: endereos IP e portas de origem originais (antes da traduo), endereos IP e portas de origem traduzidos (aps a traduo) e durao do SNAT (mais

47

detalhes sobre a importncia desses campos podem ser obtidos nas Subsees 2.4.1 e 3.2.1, tpico NAT Mapping). Alguns dispositivos de NAT suportam o registro das tradues de NAT (por exemplo, o ASA/Cisco (CISCO, 2005)), sendo necessrio apenas habilit-lo no dispositivo e enviar os logs a um servidor de logging remoto (atravs do protocolo syslog (GERHARDS, 2009), por exemplo), onde ser instalado o TRAIRA. Outros dispositivos no suportam nativamente esse recurso, a exemplo do Netlter/IPTables (rewall usado em sistemas GNU/Linux). Tendo em vista que o iptables usado em muitas instituies clientes da RNP na Bahia, este trabalho prope tambm uma soluo integrada que ser discutida no Captulo 4. Em qualquer caso, uma questo que deve chamar a ateno dos administradores consiste no espao em disco ocupado pelos logs do NAT: o tamanho do arquivo de logs ser proporcional ao uxo de rede afetado pelas tradues NAT. Recomenda-se, assim, a denio de uma poltica de gerenciamento dos logs (SOUPPAYA; KENT, 2006) que, no mnimo, deve especicar por quanto tempo o log ser mantido; Histrico sobre a associao entre endereos IP e MAC dos hosts. Sempre que houver atribuio dinmica de endereos IP na rede (DHCP), ser necessrio manter um histrico do mapeamento entre esses endereos e o endereo MAC de cada host (mais informaes sobre esse problema podem ser obtidas nas Subsees 2.4.2 e 3.2.1, tpico IP2MAC). Nesse trabalho, recomenda-se a utilizao do L2M, um software desenvolvido pela UFBA em parceria com o CERT.Bahia para o gerenciamento de recursos da camada 2 (modelo TCP/IP) de uma instituio; Request Tracker (RT). O TRAIRA foi desenvolvido como um mdulo do RT, demandando uma instalao mnima do RT para sua utilizao. Contudo, o TRAIRA no requer exclusividade na utilizao do RT, o que possibilita adoo de uma instncia do RT que j esteja em utilizao pela instituio; Banco de dados. Tanto o RT quanto o L2M necessitam de um banco de dados para registro de suas informaes. O RT suporta uma srie de sistemas de gerenciamento de banco de dados, porm o L2M suporta somente MySQL. Assim, pode-se usar uma instalao MySQL compartilhada para as duas ferramentas. Como exposto acima, a implantao do TRAIRA requer baixo investimento e tempo de instalao. Alguns de seus pr-requisitos, inclusive, so facilmente encontrados em um ambiente de produo de uma instituio. Por conseguinte, acredita-se que vivel sua implantao em diversos tipos de instituies com baixo nvel de investimento e espao.

48

NFCT-SNATLOG: UMA FERRAMENTA PARA REGISTRO DAS TRADUES SNAT DO IPTABLES/NETFILTER

O Netlter um componente do kernel do Linux que permite a ltragem de pacotes, traduo de endereos de rede (e portas) (NAT/NAPT) e outras manipulaes de pacotes (NETFILTER, 2010b). Ele est disponvel como mdulo do kernel. O iptables uma aplicao cliente, que permite a criao de regras de rewall e NAT, manipulando alguns dos subsistemas do Netlter. Embora o iptables seja robusto e bastante utilizado nas instituies, ele no dispe de funcionalidades que permitam o registro das tradues SNAT realizadas, o que pode comprometer o tratamento de um incidente de segurana gerado por uma mquina da rede interna. Diante dessa importante limitao, este captulo detalha o desenvolvimento de uma aplicao que permite monitorar conexes do tipo SNAT e registrar nos logs informaes sobre IP e porta de origem originais, IP e porta de origem traduzidas e durao da conexo. A aplicao foi chamada NFCT-SNATLOG, uma abreviao para Netlter Connection Tracking SNAT Logging. O restante deste captulo est estruturado da seguinte maneira. A Seo 4.1 mostra porque o iptables no est preparado nativamente para o registros das tradues de SNAT. Em seguida, na Seo 4.2, ser apresentada a ferramenta desenvolvida para o registro das tradues de NAT de origem criadas pelo IPTables/Netlter. Por m, a Seo 4.3 apresenta alguns cenrios de avaliao de desempenho do NFCT-SNATLOG, mostra os experimentos realizados e os resultados alcanados, e discute estes resultados a m de propor solues aos problemas encontrados ou simplesmente evidenci-los.

49

4.1

O PROBLEMA DO REGISTRO DE TRADUES NAT NO IPTABLES/NETFILTER

O NAT de origem (Source NAT, ou simplesmente SNAT) ocorre quando o endereo de origem de um determinado pacote alterado. Isso serve, por exemplo, para mascarar a topologia de rede interna de uma instituio. Um outro tipo de NAT o NAT de destino (Destination NAT, ou simplesmente DNAT), onde o endereo de destino do pacote alterado. Uma utilizao do DNAT reside na construo de proxy transparente, por exemplo. O IPTables/Netlter no faz, nativamente, registro das tradues SNAT, ou pelo menos no de forma que se possa usar os logs gerados em auditorias do sistema. Para auditoria de um sistema, importante que os logs apresentem tanto o par IP/porta de origem internos (aqueles antes da traduo SNAT, ou originais) quanto o par IP/porta de origem externos (aqueles resultantes da traduo, ou traduzidos). Tal caracterstica inerente forma de funcionamento do iptables e ser explicada e exemplicada nos pargrafos seguintes. Para entender melhor o problema, sero mostrados os passos de criao de regras SNAT no Netlter.

Figura 4.1: Esquema de chains da tabela NAT (MOTA FILHO, 2003) O primeiro passo para criar regras de SNAT no Netlter informar ao kernel quais conexes sero traduzidas e como alter-las. Para isso, utiliza-se o comando iptables com a opo

-t nat, informando ao kernel que deseja-se alterar a tabela NAT do Netlter. O Netlter
divido em tabelas (filter, nat, mangle e raw) e cada tabela concentra funcionalidades especcas do sistema a tabela filter concentra a funcionalidade de ltro de pacotes, ao passo que a tabela nat a traduo de endereos de rede e portas. Cada tabela contm las, mais conhecidas como chains, que categorizam os pacotes (pacotes que chegam ao rewall, pacotes gerados internamente, pacotes prestes a deixar o rewall, pacotes sendo roteados, etc). A Figura 4.1 ilustra o esquema de chains para a tabela NAT. Aquela gura mostra qual chain se aplica a um pacote, baseado em seu uxo no kernel: PREROUTING, quando o pacote est prestes

50

Figura 4.2: Cenrio para utilizao de SNAT no IPTables/Netlter iniciar o processo de roteamento do kernel (usado para DNAT); POSTROUTING, logo aps a deciso de roteamento ter sido tomada (usado para SNAT) ou OUTPUT (para pacotes gerados localmente antes do roteamento (usado para DNAT). Cada chain consiste de uma lista ordenada de regras. Uma regra, por sua vez, composta de ltros e aes. Os ltros denem critrios a que um pacote deve corresponder (ltro por origem, destino, protocolo etc.). Aes denem o que fazer com o pacote (aceitar, descartar, etc). Cada regra na chain examinada em ordem, at que uma delas corresponda ao pacote analisado, quando a ao denida na regra aplicada. As aes possveis para a tabela NAT so: modicar o endereo IP (e porta) de origem do pacote (SNAT) ou modicar o endereo IP (e porta) de destino do pacote (DNAT)1 . A ttulo de exemplo, considere a topologia de rede da Figura 4.2. Nesse cenrio, deseja-se que as mquinas na rede A e na rede B acessem a rede C atravs do IP 192.168.5.253. A Listagem 4.1 mostra os comandos executados na mquina firewall para congurar tal cenrio (considerando que as conguraes de rede j foram efetuadas). O parmetro -A POSTROUTING adiciona uma regra ao nal da chain POSTROUTING, o parmetro -o eth3 dene um ltro para pacotes que sairo pela interface eth3, o parmetro -s REDE ltra pela REDE de origem do pacote e, nalmente, o parmetro -j SNAT --to-source IP dene a ao SNAT modicando a origem dos pacotes para o IP especicado. Listagem 4.1: Comandos do iptables para implementar o cenrio de SNAT da Figura 4.2
1 2 i p t a b l e s t n a t A POSTROUTING o e t h 3 s 1 7 2 . 1 6 . 0 . 0 / 2 4 j SNAT t o s o u r c e 1 9 2 . 1 6 8 . 5 . 2 5 3 i p t a b l e s t n a t A POSTROUTING o e t h 3 s 1 0 . 1 0 . 1 0 . 0 / 2 4 j SNAT t o s o u r c e 1 9 2 . 1 6 8 . 5 . 2 5 3

Aps a execuo desses comandos, a chain POSTROUTING da tabela NAT do iptables encontra-se conforme mostrado na Tabela 4.1.
1 Uma terceira ao possvel na tabela NAT a MASQUERADE, uma especializao da SNAT usado em conexes que atribuem dinamicamente o endereo IP.

51

Tabela 4.1: Lista de regras instaladas na chain POSTROUTING da tabela NAT do iptables aps a execuo dos comandos da Listagem 4.1 #Regra 1 2 Prot. In Out Orig. Dest. Ao all * eth3 172.16.0.0/24 0.0.0.0/0 SNAT (to:192.168.5.253) all * eth3 10.10.10.0/24 0.0.0.0/0 SNAT (to:192.168.5.253)

Deseja-se agora registrar as tradues de SNAT realizadas na mquina firewall para ns de auditoria futura. Uma soluo simplria encontrada em muitas listas de discusso para esse objetivo adicionar uma regra imediatamente antes da regra de SNAT desejada, cuja ao seja fazer o registro dos pacotes (logging). Para tanto, utiliza-se a ao LOG (-j LOG) com os mesmos ltros da regra que deseja-se registrar2 . Os comandos para implementar essa proposta so mostrados na Listagem 4.2. Listagem 4.2: Comandos do iptables para implementar um falso logging das regras SNAT denidas na Figura 4.2
1 2 i p t a b l e s t n a t I POSTROUTING 1 o e t h 3 s 1 7 2 . 1 6 . 0 . 0 / 2 4 j LOG l o g p r e f i x SNAT i p t a b l e s t n a t I POSTROUTING 3 o e t h 3 s 1 0 . 1 0 . 1 0 . 0 / 2 4 j LOG l o g p r e f i x SNAT

O resultado dos comandos da Listagem 4.2 mostrado na Tabela 4.2. Tabela 4.2: Lista de regras instaladas na chain POSTROUTING da tabela NAT do iptables aps a execuo dos comandos da Listagem 4.2 #Regra 1 2 3 4 Prot. In Out Orig. Dest. Ao all * eth3 172.16.0.0/24 0.0.0.0/0 LOG (prexo SNAT ) all * eth3 172.16.0.0/24 0.0.0.0/0 SNAT (to:192.168.5.253) all * eth3 10.10.10.0/24 0.0.0.0/0 LOG (prexo SNAT ) all * eth3 10.10.10.0/24 0.0.0.0/0 SNAT (to:192.168.5.253)

A m de vericar o funcionamento das regras denidas pelos comandos anteriores, usando o cenrio da Figura 4.2, executa-se duas conexes simultneas, uma da mquina HostA e outra da mquina HostB, para a mquina Srv01 com porta de origem 40000/TCP e porta de destino 80/TCP. Para iniciar essas conexes, pode-se utilizar a ferramenta netcat3 no HostA e no HostB da seguinte forma: nc -p 40000 192.168.5.99 80. Adicionalmente, na mquina Srv01 inicia-se um monitoramento do trfego na interface com o IP 192.168.5.99 (tap0) a m de vericar os endereos que acessaram aquele host. Esse monitoramento feito com o
como DNAT, SNAT etc., a ao LOG no bloqueante. Ou seja, o iptables continuar processando a tabela de regras at encontrar outra que tambm corresponda ao pacote. 3 Netcat um utilitrio de rede capaz de ler e escrever dados atravs de conexes de rede, usando o protocolo TCP/IP.
2 Diferente de outras aes (targets),

52

utilitrio tcpdump4 atravs do seguinte comando:

sudo tcpdump -i tap0 -n src host 192.168.5.253 and dst port 80

A mensagem de log enviada pelo iptables como consequncia das conexes anteriormente estabelecidas mostrada na Listagem 4.3. A sada do tcpdump mostrada na Listagem 4.4. Listagem 4.3: Sada do log do iptables para as conexes iniciadas pelo comando nc (netcat) executado nas mquinas HostA e HostB.
1 Nov 20 0 9 : 4 7 : 0 7 f i r e w a l l k e r n e l : [ 3 2 3 8 5 . 7 5 3 4 5 4 ] SNAT IN= OUT= e t h 3 SRC = 1 7 2 . 1 6 . 0 . 1 DST = 1 9 2 . 1 6 8 . 5 . 9 9 LEN=60 TOS=0 x00 PREC=0 x00 TTL=63 ID =52200 DF PROTO=TCP SPT=40000 DPT=80 WINDOW=5840 RES=0 x00 SYN URGP=0 2 Nov 20 0 9 : 4 7 : 0 8 f i r e w a l l k e r n e l : [ 3 2 3 8 6 . 4 7 9 4 6 2 ] SNAT IN= OUT= e t h 3 SRC = 1 0 . 1 0 . 1 0 . 1 DST = 1 9 2 . 1 6 8 . 5 . 9 9 LEN=60 TOS=0 x00 PREC=0 x00 TTL=63 ID =18925 DF PROTO=TCP SPT=40000 DPT=80 WINDOW=5840 RES=0 x00 SYN URGP=0

Listagem 4.4: Sada do monitoramento com tcpdump em Srv01 para as conexes iniciadas com o netcat de HostA e HostB
1 2 3 4 5 0 9 : 4 7 : 0 7 . 6 1 5 0 5 1 I P 1 9 2 . 1 6 8 . 5 . 2 5 3 . 4 0 0 0 0 > 1 9 2 . 1 6 8 . 5 . 9 9 . 8 0 : F l a g s [ S ] , s e q 3 4 2 8 3 4 6 0 5 7 , win 5 8 4 0 , o p t i o n s [ mss 1 4 6 0 , sackOK , TS v a l 9478945 e c r 0 , nop , w s c a l e 2 ] , l e n g t h 0 0 9 : 4 7 : 0 7 . 6 2 7 1 1 6 I P 1 9 2 . 1 6 8 . 5 . 2 5 3 . 4 0 0 0 0 > 1 9 2 . 1 6 8 . 5 . 9 9 . 8 0 : F l a g s [ . ] , a c k 1 2 8 2 3 6 5 4 4 , win 1 4 6 0 , o p t i o n s [ nop , nop , TS v a l 9478948 e c r 4 6 7 2 7 6 2 5 ] , l e n g t h 0 0 9 : 4 7 : 0 8 . 4 3 9 3 1 4 I P 1 9 2 . 1 6 8 . 5 . 2 5 3 . 1 0 2 4 > 1 9 2 . 1 6 8 . 5 . 9 9 . 8 0 : F l a g s [ S ] , s e q 2 2 3 7 5 2 0 9 1 0 , win 5 8 4 0 , o p t i o n s [ mss 1 4 6 0 , sackOK , TS v a l 9475555 e c r 0 , nop , w s c a l e 2 ] , l e n g t h 0 0 9 : 4 7 : 0 8 . 4 4 5 4 9 3 I P 1 9 2 . 1 6 8 . 5 . 2 5 3 . 1 0 2 4 > 1 9 2 . 1 6 8 . 5 . 9 9 . 8 0 : F l a g s [ . ] , a c k 1 2 2 2 3 4 3 3 9 , win 1 4 6 0 , o p t i o n s [ nop , nop , TS v a l 9475555 e c r 4 6 7 2 7 8 3 1 ] , l e n g t h 0 ...

Cabe notar que as portas listadas na sada do tcpdump (192.168.5.253.40000 e

192.168.5.253.1024) so diferentes daquelas listadas nos logs do iptables ( SRC=172.16.0.1 ... SPT=40000 e SRC=10.10.10.1 ... SPT=40000), o que inviabilizaria o processo de auditoria para uma conexo de origem 192.168.5.253:1024, por exemplo. Isso acontece pois quando a regra do LOG (regra 1 ou 3 da Tabela 4.2) aplicada, a traduo ainda no aconteceu, da o endereo registrado no log o par IP/porta originais e no os traduzidos. Ainda, no h como adicionar uma regra logo aps a ao SNAT (logo aps 2 ou 4 na Tabela 4.2), pois essa regra nunca seria executada (lembre-se que a nica ao no bloqueante a LOG). Destaca-se, novamente, que os resultados apresentados acima implicam que mesmo os administradores que acreditam terem habilitado o monitoramento sobre as tradues NAT no iptables (via, por exemplo, passos descritos na Listagem 4.2) sero impossibilitados de tratar alguns incidentes de segurana reportados sua instituio. Mesmo considerando-se a criticidade
4O

tcpdump um utilitrio de linha de comando para captura e anlise de trfego de rede.

53

desse resultado, no foi encontrado nenhum trabalho que aborde o problema com a importncia merecida. Faz-se necessria, assim, uma ferramenta complementar ao iptables que monitore as conexes de SNAT do kernel e informe os dados relevantes dessa conexo quando necessrio. Nas pesquisas realizadas para esse trabalho, a ferramenta que mais se aproxima desses requisitos o conntrack-tools (NETFILTER, 2010a) um subprojeto do Netlter cujo objetivo prover uma interface em espao de usurio para monitorar e gerenciar a tabela de rastreamento de conexes do kernel (Connection Tracking System, comumente abreviado para conntrack). Para o exemplo anterior, poder-se-ia iniciar o monitoramento das conexes de NAT com o seguinte comando:

conntrack -E -e NEW,DESTROY -n -o timestamp. Esse comando inicia o monitoramento

de eventos do tipo NEW e DESTROY (-E -e NEW,DESTROY, discutidos em mais detalhes na Seo 4.2), cuja conexo seja relacionada um SNAT (-n) e listando o tempo em que o evento ocorreu (-o timestamp). O resultado do comando acima para a mesma conexo dos exemplos anteriores mostrado na Listagem 4.5. Listagem 4.5: Sada do monitoramento com conntrack no rewall para as conexes iniciadas com o netcat de HostA e HostB
1 [1290257227.849654] s p o r t =80 d p o r t =40000 2 [1290257228.571181] s p o r t =80 d p o r t =1024 3 [1290257357.613241] [DESTROY] t c p 6 s r c = 1 7 2 . 1 6 . 0 . 1 d s t = 1 9 2 . 1 6 8 . 5 . 9 9 s p o r t =40000 d p o r t =80 p a c k e t s =4 b y t e s =228 s r c = 1 9 2 . 1 6 8 . 5 . 9 9 d s t = 1 9 2 . 1 6 8 . 5 . 2 5 3 s p o r t =80 d p o r t =40000 p a c k e t s =3 b y t e s =164 4 [1290257358.505345] [DESTROY] t c p 6 s r c = 1 0 . 1 0 . 1 0 . 1 d s t = 1 9 2 . 1 6 8 . 5 . 9 9 s p o r t =40000 d p o r t =80 p a c k e t s =4 b y t e s =228 s r c = 1 9 2 . 1 6 8 . 5 . 9 9 d s t = 1 9 2 . 1 6 8 . 5 . 2 5 3 s p o r t =80 d p o r t =1024 p a c k e t s =3 b y t e s =164 [NEW] t c p 6 t i m e o u t =120 SYN_SENT s r c = 1 0 . 1 0 . 1 0 . 1 d s t = 1 9 2 . 1 6 8 . 5 . 9 9 s p o r t =40000 d p o r t =80 [ UNREPLIED ] s r c = 1 9 2 . 1 6 8 . 5 . 9 9 d s t = 1 9 2 . 1 6 8 . 5 . 2 5 3 [NEW] t c p 6 t i m e o u t =120 SYN_SENT s r c = 1 7 2 . 1 6 . 0 . 1 d s t = 1 9 2 . 1 6 8 . 5 . 9 9 s p o r t =40000 d p o r t =80 [ UNREPLIED ] s r c = 1 9 2 . 1 6 8 . 5 . 9 9 d s t = 1 9 2 . 1 6 8 . 5 . 2 5 3

A partir dos logs acima pode-se obter os tempos de incio e trmino de uma conexo. Ainda, cada linha do log composta por um par de campos do tipo src, dst, sport, dport, onde o primeiro deve condizer com o envio do pacote e o segundo com a resposta esperada pelo kernel. Em outras palavras, os valores da primeira ocorrncia dos campos src e sport representam o par IP/porta originais, ao passo que os valores dos campos dst e dport na segunda ocorrncia representam o par IP/porta traduzidos. Tais informaes resolvem parcialmente o problema do logging do iptables. Porm, mesmo essa abordagem, ainda no a ideal para o cenrio proposto. As principais desvantagens de utilizar o conntrack diretamente no logging das conexes SNAT do iptables so as seguintes:

54

O escopo de atuao do conntrack bem mais amplo que simplesmente fazer logging de conexes SNAT. Por isso, uma srie de campos so registrados desnecessariamente junto ao log de uma conexo SNAT. Em ambientes com um grande nmero de logs sendo gravados no servidor, esses campos adicionais podem elevar a carga e os requisitos de armazenamento do sistema; O conntrack no gera sada via syslog, somente na sada padro. Assim, para integr-lo um servidor de logs remoto seria necessrio um terceiro processo que redirecionasse a sada padro do conntrack para o servidor de logs remoto, gerando mais carga ao sistema; Inferir a durao de uma conexo a partir de duas mensagens de log muito mais custoso que com apenas uma mensagem (tanto em termos de processamento e armazenamento na gravao, quanto de processamento na recuperao sendo mais crtica a questo do armazenamento). Os aspectos listados nessa seo motivaram a criao de uma ferramenta para o logging de conexes SNAT do iptables o NFCT-SNATLOG objeto de estudo da seo seguinte.

4.2

NFCT-SNATLOG: REGISTRO DAS TRADUES DE SNAT NO IPTABLES/NETFILTER

A Seo 4.1 descreveu as limitaes do IPTables/Netlter no registro das conexes de SNAT, enfatizando a insucincia de informaes para auditorias ou tratamento de incidentes de segurana no sistema. Alm disso, uma segunda ferramenta que resolveria esse problema (o conntrack-tools) tambm apresenta desvantagens, principalmente por no ter foco especco no problema em questo. Esses fatores, atrelados grande taxa de utilizao do iptables nas instituies de ensino e pesquisa clientes da RNP, motivaram a criao de uma ferramenta para o logging das conexes SNAT do iptables, o NFCT-SNATLOG, que ser detalhado nesta seo. Os principais requisitos necessrios tal ferramenta incluem: Dada uma conexo de SNAT no kernel do Linux (iptables), os seguintes dados devem ser registrados sobre tal conexo (agrupados em uma nica mensagem de log): endereo IP e porta de origem originais, endereo IP e porta de origem traduzidos, protocolo de transporte utilizado (TCP ou UDP), data e horrio do m da conexo, durao da conexo;

55

Deve ser possvel gravar as mensagens de log via protocolo syslog, permitindo o logging remoto da aplicao; Deve ser possvel executar a aplicao como daemon do sistema. Um daemon (ou servio) um processo que executa em segundo plano (background) de forma autnoma do restante das aplicaes e com pouca ou nenhuma interao com o usurio. A principal vantagem em executar uma aplicao como daemon est em torn-la independente de outros processos de usurio, liberando, assim, recursos do sistema que no sero necessrios (por exemplo, descritores de entrada padro, sada padro, etc). O Netlter Conntrack SNAT Logging (NFCT-SNATLOG) um software desenvolvido para a gerao dos logs de SNAT do iptables atendendo aos requisitos acima. Baseado no conntracktools, o NFCT-SNATLOG foi programado usando a biblioteca libnetfilter_conntrack (NETFILTER, 2010c), que prov uma interface de programao (API) para acessar a tabela de rastreamento de conexes do kernel em espao de usurio. Por meio dessa biblioteca, possvel monitorar a pilha de rede do kernel e registrar funes (callbacks) que sero chamadas na ocorrncia de eventos especcos (AYUSO, 2006). Exemplos de eventos de interesse incluem: criao de novas conexes (NEW), atualizao de uma conexo existente (UPDATE) ou ainda a destruio (DESTROY) de uma conexo cujo tempo limite (timeout) foi ultrapassado. Alm disso, uma conexo pode ser ltrada pelo tipo de protocolo de transporte (TCP ou UDP), traduo NAT de origem ou destino, dentre outras. O NFCT-SNATLOG foi desenvolvido em C, possui cerca de 500 linhas de cdigo, distribudo sob a licena GPLv2 ou superior5 e encontra-se disponvel para download em (NFCTSNATLOG, 2010).

4.2.1

ARQUITETURA DO NFCT-SNATLOG

A Figura 4.3 mostra o uxograma de execuo do NFCT-SNATLOG. As principais etapas de sua execuo podem ser sumarizadas nos seguintes itens: 1. Monitorar os eventos NEW e DESTROY das conexes no kernel do Linux; 2. Filtrar as conexes que sejam do tipo SNAT e cujo protocolo de transporte seja TCP ou UDP;
uma sigla usada para GNU Public License, uma licena de software livre especicada pela Free Software Foundation.
5 GPL

56

3. Calcular a diferena de tempo entre os eventos NEW e DESTROY de determinada conexo; 4. Salvaguardar as informaes relevantes dessa conexo no log do sistema; 5. Repassar a informao do estado da conexo ao conntrack, para que ele possa chamar a prxima callback registrada.

Figura 4.3: Viso geral de funcionamento do NFCT-SNATLOG

4.2.2

QUESTES DE IMPLEMENTAO

A Listagem 4.6 apresenta a principal funo do NFCT-SNATLOG (nfct_snatlog_cb), responsvel pelo tratamento dos eventos do conntrack. Listagem 4.6: Cdigo da funo do NFCT-SNATLOG responsvel pelo tratamento dos eventos do conntrack
1 2 3 4 5 6 7 / / we a r e i n t e r e s t e d o n l y i n SNAT c o n n e c t i o n s s t a t i c i n t n f c t _ s n a t l o g _ c b ( enum n f _ c o n n t r a c k _ m s g _ t y p e t y p e , s t r u c t nf_conntrack ct , void d a ta ) { s t r u c t c o n n t r a c k _ l i s t no ; u_int8_t l4proto ;

57
8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 } r e t u r n NFCT_CB_CONTINUE ; } } break ; default : break ; switch ( type ) { c a s e NFCT_T_NEW : no = ( s t r u c t c o n n t r a c k _ l i s t ) m a l l o c ( s i z e o f ( s t r u c t c o n n t r a c k _ l i s t ) ) ; no > i d = n f c t _ g e t _ a t t r _ u 3 2 ( c t , ATTR_ID ) ; no > o r i g _ i p v 4 _ s r c = n f c t _ g e t _ a t t r _ u 3 2 ( c t , ATTR_ORIG_IPV4_SRC ) ; no > o r i g _ p o r t _ s r c = n f c t _ g e t _ a t t r _ u 1 6 ( c t , ATTR_ORIG_PORT_SRC ) ; t i m e (&no >t i m e s t a m p ) ; l i s t _ a d d (& c t _ l i s t , no ) ; break ; c a s e NFCT_T_DESTROY : no = l i s t _ f i n d ( c t _ l i s t , n f c t _ g e t _ a t t r _ u 3 2 ( c t , ATTR_ID ) , n f c t _ g e t _ a t t r _ u 3 2 ( c t , ATTR_ORIG_IPV4_SRC ) , n f c t _ g e t _ a t t r _ u 1 6 ( c t , ATTR_ORIG_PORT_SRC ) ) ; i f ( no ) { p r i n t _ s n a t l o g ( c t , &no >t i m e s t a m p , p r o t o _ s t r ( l 4 p r o t o ) ) ; l i s t _ d e l (& c t _ l i s t , no ) ; } i f ( debug_flag ) { p r i n t _ d e b u g ( ct , type , p r o t o _ s t r ( l 4 p r o t o ) ) ; / / We a r e i n t e r e s t e d o n l y i n TCP /UDP L4 p r o t o c o l s . . . l 4 p r o t o = n f c t _ g e t _ a t t r _ u 8 ( c t , ATTR_ORIG_L4PROTO ) ; i f ( l 4 p r o t o ! = IPPROTO_TCP && l 4 p r o t o ! = IPPROTO_UDP ) r e t u r n NFCT_CB_CONTINUE ; i f ( ! n f c t _ g e t o b j o p t ( c t , NFCT_GOPT_IS_SNAT ) ) r e t u r n NFCT_CB_CONTINUE ;

Essa funo registrada como callback para monitorar os eventos de criao de nova conexo (NEW) e encerramento de uma conexo existente (DESTROY). Na ocorrncia de algum desses eventos, a funo ser chamada e receber os seguintes parmetros: enum nf_conntrack_msg_type type: uma constante que dene o evento ocorrido (NEW, UPDATE, DESTROY, etc); struct nf_conntrack *ct: um apontador para a regio de memria contendo a estrutura de dados do mdulo conntrack que armazena informaes sobre a conexo. As informaes so armazenadas na forma de tuplas de hash (para otimizar a consulta) (AYUSO, 2006). Cada tupla contm o endereo IP de origem e destino, nmero da porta

58

de origem e destino, tipos dos protocolos, estado e timeout. Existem duas tuplas de hash para cada conexo (AYUSO, 2006): uma para a direo original do pacote (isto , os pacotes vindos do ponto que iniciou a conexo) e uma para direo da resposta (isto , pacotes de resposta indo para o ponto que iniciou a conexo); void *data: um apontador para uma regio de memria que pode ser usada internamente pela callback (no ser utilizada pelo NFCT-SNATLOG). As linhas 7 a 14 da Listagem 4.6 so responsveis pelo primeiro passo na execuo do NFCT-SNATLOG: ltrar as conexes do tipo SNAT e cujo protocolo de transporte seja TCP ou UDP. Em seguida, para calcular a diferena de tempo entre os eventos (durao do SNAT), foi necessrio manter uma estrutura de dados interna que armazenasse o instante em que a conexo foi iniciada (evento NEW), pois o kernel no armazena tal informao na estrutura

conntrack. A estrutura de dados utilizada foi uma lista duplamente encadeada, chamada ct_list, indexada pelo identicador da conexo (nfct_get_attr_u32(ct,ATTR_ID)), endereo IP de origem (nfct_get_attr_u32(ct,ATTR_ORIG_IPV4_SRC)) e porta de origem (nfct_get_attr_u16(ct,ATTR_ORIG_PORT_SRC))6 . Assim, caso trate-se de uma nova conexo, as linhas 22 a 27 sero responsveis por armazenar o momento em que o evento ocorreu (adicionando um novo n lista ct_list). J em se tratando do encerramento de uma conexo, recupera-se a informao sobre o instante de criao da conexo da lista ct_list (linhas 30 a 33), calcula-se a diferena de tempo e registra-se os dados da conexo (linha 35) e, nalmente, remove-se tal entrada da lista ct_list (linha 36). Deve-se notar que, como a conexo no ser modicada pelo NFCT-SNATLOG, a callback sempre retorna a constante NFCT_CB_CONTINUE, simplesmente informando ao mdulo

conntrack para chamar a prxima callback registrada.

Com relao forma como os logs de SNAT so registrados no sistema, o NFCT-SNATLOG utiliza a biblioteca syslog.h que fornece funes para envio de mensagens ao log do sistema via protocolo syslog (GERHARDS, 2009). possvel tambm escrever os logs na sada padro, porm o comportamento padro utilizar o syslog.
esses campos foram usados invs de simplesmente o identicador da conexo pois, segundo Pablo Neira Ayuso (um dos desenvolvedores do Netlter e principal desenvolvedor do conntracktools), em algumas condies de corrida do kernel, o identicador pode no ser suciente. Fonte: http://marc.info/?l=netlter&m=128725256809325&w=2, ltimo acesso em 27 de Novembro de 2010
6 Todos

59

4.2.3

EXEMPLO DE UTILIZAO

Para mostrar um exemplo de uso do NFCT-SNATLOG ser retomado o mesmo cenrio proposto na Seo 4.1. Antes de iniciar os testes preciso instalar e executar o NFCT-SNATLOG. O site do projeto j fornece a documentao necessria para sua instalao e execuo (NFCTSNATLOG, 2010). A Listagem 4.7 apresenta as mensagens extradas dos logs do sistema na mquina rewall para as conexes dos hosts HostA e HostB ao host Srv01, considerando o monitoramento com o NFCT-SNATLOG (foram adotadas as mesmas conguraes propostas na Seo 4.1). Listagem 4.7: Sada do monitoramento com NFCT-SNATLOG no rewall para as conexes iniciadas com o netcat de HostA e HostB, conforme descrito na Seo 4.1
1 2 Nov 20 0 9 : 4 9 : 1 7 f i r e w a l l n f c t s n a t l o g : [SNAT_LOG] p r o t o = t c p o s r c = 1 7 2 . 1 6 . 0 . 1 o s p t =40000 t s r c = 1 9 2 . 1 6 8 . 5 . 2 5 3 t s p t =40000 d u r a t i o n =130 s Nov 20 0 9 : 4 9 : 1 8 f i r e w a l l n f c t s n a t l o g : [SNAT_LOG] p r o t o = t c p o s r c = 1 0 . 1 0 . 1 0 . 1 o s p t =40000 t s r c = 1 9 2 . 1 6 8 . 5 . 2 5 3 t s p t =1024 d u r a t i o n =130 s

Como pode-se notar na Listagem 4.7, os logs enviados pelo NFCT-SNATLOG contm as informaes necessrias ao tratamento dos incidentes de segurana, e somente elas. Os campos

o-src e o-spt armazenam o par IP/porta de origem originais, enquanto que os campos t-src
e t-spt armazenam o par IP/porta de origem traduzidos; o campo duration, por sua vez, armazena o tempo em que a conexo permaneceu armazenada na tabela de conexes do kernel. Dessa forma, pode-se considerar que o NFCT-SNATLOG atende aos requisitos propostos anteriormente e, portanto, pode ser usado em conjunto com o iptables para atender demanda de logging das conexes SNAT no atendida pelo iptables. Na seo seguinte, ser apresentada uma anlise de desempenho e impacto frente a um sistema em produo do NFCT-SNATLOG.

4.3

AVALIAO DE DESEMPENHO DA PROPOSTA

Esta seo apresenta uma avaliao de desempenho do NFCT-SNATLOG, a m de vericar o impacto que sua utilizao pode trazer a um sistema de rewall em produo. Vale ressaltar que j se espera alguma queda no desempenho do sistema, quando da utilizao do NFCTSNATLOG em relao ao ambiente original. Porm, o objetivo fundamental medir a taxa de degradao que o sistema vai sofrer para aferir a viabilidade de ser usado em ambientes reais. Em outras palavras, o objetivo desses experimentos apresentar resultados de desempenho de

60

um rewall que no faz logging das tradues SNAT, comparando-os com um ambiente em que essa funcionalidade habilitada atravs do NFCT-SNATLOG. Por m, apresentam-se algumas concluses observadas durante a realizao dos experimentos.

4.3.1

CENRIOS PARA A AVALIAO DE DESEMPENHO

Na realizao de experimentos para avaliao de desempenho, pode-se utilizar uma das trs tcnicas seguintes: modelagem analtica, simulao ou medio (JAIN, 1991). A escolha por uma dessas tcnicas deve levar em considerao o tempo necessrio para realizao dos experimentos em cada uma delas, a disponibilidade de ferramentas de suporte, preciso, custo e, principalmente, estgio de desenvolvimento da proposta. Assim, vrios fatores devem ser levados em considerao na escolha da tcnica de avaliao. Este tpico discutido com mais detalhes em (JAIN, 1991, Seo 3.1). Neste trabalho optou-se por usar medio pois j dispese do cdigo da proposta implementado e tem-se acesso fcil a um ambiente de experimentao (cenrio sem o logging das conexes SNAT e cenrio com o logging de tais conexes atravs do NFCT-SNATLOG). Dessa forma, possvel a obteno de resultados mais prximos da realidade. A Figura 4.4 mostra a topologia de rede utilizada para realizao dos experimentos de medio. Neste cenrio, todas as mquinas executam o sistema Debian GNU/Linux (kernel 2.6.32). As mquinas clientes (rede A) e servidores (rede B) so do tipo Intel Pentium Dual Core E2160 1.800GHz, 1GB de memria DDR2 667MHz, HD Sata 160GB 5400rpm e placa de rede FastEthernet. A mquina do rewall um AMD Athlon 64 2800+ 1.800GHz, 2 x 256MB de memria DDR400, HD IDE 80GB 5400rpm e 3 x placa de rede FastEthernet. A escolha das mquinas foi baseada na disponibilidade dos equipamentos no momento da execuo dos experimentos. As mquinas na rede A e na rede B esto conectadas por dois switches FastEthernet (um switch em cada rede). Para o monitoramento do rewall optou-se pela utilizao do software Zabbix7 , pela facilidade de instalao, congurao e coleta dos dados. Para evitar que o monitoramento inuencie no trfego de rede dos experimentos, a coleta era feita por um enlace ponto-a-ponto entre o rewall e o servidor zabbix, dedicado a este m. A escolha do intervalo de medio outro fator importante no experimento de avaliao de desempenho, pois intervalos grandes podem causar a perda de eventos importantes, ao passo que intervalos muito curtos provocam rudo e carga excessiva, impactando diretamente nos resultados obtidos. O intervalo de coleta dos dados escolhido foi de 30 segundos, denido aps
7 Zabbix um software para monitoramento de rede,

que possui um agente na estao monitorada e um servidor

responsvel por coletar os dados dos agentes.

61

Figura 4.4: Cenrio para experimentos de avaliao de desempenho do NFCT-SNATLOG a realizao de algumas medies e avaliao dos grcos gerados. Usando a topologia da Figura 4.4 como base dos experimentos, foram avaliadas trs conguraes diferentes no rewall (objeto de observao): 1. O rewall realiza tradues SNAT da rede A para a rede B sem o logging das tradues; 2. O rewall realiza tradues SNAT da rede A para a rede B com o logging das tradues atravs do NFCT-SNATLOG e escreve os logs localmente (syslog apenas local); 3. O rewall realiza tradues SNAT da rede A para a rede B com o logging das tradues atravs do NFCT-SNATLOG e escreve os logs remotamente (syslog apenas remoto, instalado na mquina servidor zabbix); As mtricas de desempenho observadas no experimento foram: utilizao de CPU, utilizao de memria e operaes de entrada e sada no disco. A escolha dessas mtricas est relacionada natureza de funcionamento do NFCT-SNATLOG: utilizao de CPU para o processamento da lista de conexes que ele gerencia e clculo da diferena de tempos; utilizao de memria para armazenamento da lista de conexes ct_list; operaes de entrada e sada no disco para avaliar a escrita dos logs. Ainda considerando a natureza de funcionamento do NFCT-SNATLOG, importante perceber que a carga de trabalho adicionada ao rewall devido sua utilizao independe do tamanho dos pacotes transmitidos, sendo limitada, ento, pela quantidade de pacotes por segundo que devem ser tratados pelo NFCT-SNATLOG. Nesse sentido, a carga de trabalho gerada nos experimentos visou aumentar o nmero de pacotes por segundo que o rewall deveria tratar ao longo do tempo, permitindo, inclusive, ter uma noo acerca da escalabilidade da ferramenta. A Tabela 4.3 mostra a carga de trabalho submetida ao rewall por perodo de tempo. A variao da carga por perodo de tempo (denidos em 10 minutos) ocasionada exclusivamente

62

pelo aumento da taxa de envio de pacotes nas mquinas clientes (rede A). Os dados da tabela foram medidos diretamente no rewall, atravs da interface que o conecta rede B. A escolha do valor inicial, incremento e nal foram baseadas em experimentos anteriores realizados: a mquina utilizada era incapaz de tratar valores maiores. Tabela 4.3: Carga de trabalho gerada no rewall para experimentos de Avaliao de desempenho do NFCT-SNATLOG Intervalo (min) Trfego gerado (Pkts/sec) 0 - 10 840.47 10 - 20 1247.52 20 - 30 1623.06 30 - 40 1961.51 40 - 50 2313.77 50 - 60 2694.24 Para gerar o trfego mostrado na Tabela 4.3 foram necessrias as conguraes listadas a seguir. Cada um dos servidores (mquinas na rede B) executa o servidor iperf, aceitando conexes na porta 5001/TCP (os servidores foram iniciados a partir do comando

iperf -p 5001 -s), e um servidor UDP (construdo com a biblioteca socket.h8 ) que apenas
aceita conexes na porta 6001, recebe os dados transferidos e aguarda por uma nova conexo. Cada mquina cliente (mquinas na rede A), inicia vrias conexes em paralelo com as mquinas servidoras (dois clientes por servidor) para transferncia de 2 KBytes via UDP (usando o utilitrio netcat) e 64 KBytes via TCP (usando o iperf como cliente). As transferncias so feitas de forma sucessiva e o nmero de conexes em paralelo inicia em 4 e incrementado de 2 a cada 10 minutos. O cdigo-fonte dos programas utilizados est disponvel no Apndice A. A seo seguinte apresenta os dados obtidos a partir das medies realizadas no cenrio de experimentao proposto acima.

4.3.2

RESULTADOS OBTIDOS

As guras 4.5, 4.6 e 4.7 apresentam os grcos de utilizao de CPU, memria e disco, respectivamente, para a primeira congurao do cenrio de experimentos proposto na subseo anterior: o rewall realiza tradues SNAT para conexes da rede A para a rede B, sem fazer log das tradues. Como pode-se observar, a utilizao de CPU (Figura 4.5) permaneceu baixa ao longo do tempo (lembrando que o trfego aumenta com o tempo, conforme Tabela 4.3). A
por construir tal servio ao invs de usar ferramentas prontas, pois as ferramentas testadas todas apresentaram problema com relao ao timeout das conexes abertas quando muitas delas eram iniciadas simultaneamente. O cdigo-fonte do servidor UDP construdo encontra-se disponvel no Apndice A.
8 Optou-se

63

memria livre (Figura 4.6) diminuiu cerca de 3.6MB (0.75% do total), dos quais cerca de 3MB (0.62% do total) foram destinadas aos buffers e aproximadamente 600KB (0.12% do total) s outras aplicaes do sistema. As operaes de entrada/sada no disco (Figura 4.7) tambm permaneceram em taxas baixas. Note que, apesar do experimento ter durado uma hora, o grco abrange um intervalo de uma hora e quatro minutos. Essa margem de tempo foi propositalmente inserida baseando-se nos seguintes critrios: um minuto antes e no m do experimento para evidenciar a carga gerada no sistema e mais dois minutos no nal, pois esse o tempo limite que o kernel aguarda at declarar que uma conexo TCP deve ser destruda9 .

Figura 4.5: Grcos de utilizao de CPU do rewall com tradues SNAT sem logging.

Figura 4.6: Grcos de utilizao de memria do rewall com tradues SNAT sem logging. A prxima congurao avaliada foi com o rewall realizando tradues SNAT para conexes da rede A para a rede B, com o logging das tradues atravs do NFCT-SNATLOG e escrevendo os logs localmente (syslog apenas local). As guras 4.8, 4.9 e 4.10 apresentam os grcos de utilizao de CPU, memria e disco, respectivamente, para esse cenrio. Esses grcos, se comparados aqueles produzidos para a primeira congurao, mantm a caracterstica
conexes TCP esse tempo limite (timeout) de 120 segundos, j para UDP o timeout 30 segundos. Esses tempos podem ser ajustados atravs de parmetros no /proc.
9 Para

64

Figura 4.7: Grcos de utilizao de disco do rewall com tradues SNAT sem logging. de baixo consumo de CPU porm evidenciam o consumo de memria e disco medida que o trfego aumenta. No caso da memria livre (Figura 4.9) houve uma diminuio de aproximadamente 36.5MB (7.65%), dos quais cerca de 27MB (5.66%) passaram a ser usados como cache e 5.8MB (1.22%) como buffers, contabilizando cerca de 3.7MB (0.78%) de pico no uso de memria. Comparando esse valor diretamente com o obtido no experimento anterior podese inferir um pico de consumo de 3MB memria pelo NFCT-SNATLOG e pelo servio syslog (nicas aplicaes no presentes na primeira congurao), um valor aceitvel considerando-se a carga mxima que foi atribuda ao sistema. Obviamente, essa comparao simplria imprecisa, porm acredita-se que a falta de rigor nesse caso no tem grande relevncia. Acerca das operaes de entrada e sada no disco (Figura 4.10), essa segunda congurao tambm evidencia uma utilizao razovel do disco se comparado ao cenrio anterior, porm, ainda assim em valores baixos.

Figura 4.8: Grcos de utilizao de CPU do rewall com tradues SNAT e logging local. Na terceira e ltima congurao do cenrio de experimentos tem-se o rewall realizando tradues SNAT para conexes da rede A para a rede B, com o logging das tradues via NFCTSNATLOG sendo enviado um servidor de logs remoto (sem escrita no disco local). As guras

65

Figura 4.9: Grcos de utilizao de memria do rewall com tradues SNAT e logging local.

Figura 4.10: Grcos de utilizao de disco do rewall com tradues SNAT e logging local. 4.11, 4.12 e 4.13 apresentam os grcos de utilizao de CPU, memria e disco, respectivamente, nesse cenrio. A utilizao de CPU (Figura 4.11) continua praticamente desprezvel ao longo do experimento, porm nota-se claramente uma diferena na utilizao de memria e escrita em disco comparado ao ambiente com logging local (com os valores aproximando-se, inclusive, dos grcos onde o logging das tradues estava desabilitado).

Figura 4.11: Grcos de utilizao de CPU do rewall com tradues SNAT e logging remoto.

66

A memria livre (Figura 4.12), diminuiu cerca de 4.4MB (0.92%), dos quais cerca de 3MB (0.63%) foram destinados aos buffers e os 1.4MB (0.29%) restantes s outras aplicaes do sistema. Novamente comparando esses valores diretamente aos obtidos na primeira congurao, pode-se inferir um pico de consumo de 800KB (0.16%) de memria pelo NFCT-SNATLOG e pelo servio syslog (nicas aplicaes que no estavam executando na primeira congurao). J se comparados diretamente aos obtidos na segunda congurao, pode-se inferir que provavelmente o servio syslog teve uma forte contribuio para o consumo de memria do sistema no segundo cenrio. Por conseguinte, observa-se bons nveis de consumo de memria do NFCT-SNATLOG em funo da carga a que o sistema foi submetido. O grco de operaes de entrada e sada no disco (Figura 4.13) apresenta praticamente o mesmo comportamento do observado no cenrio sem logging das tradues, um resultado esperado.

Figura 4.12: Grcos de utilizao de memria do rewall com tradues SNAT e logging remoto.

Figura 4.13: Grcos de utilizao de disco do rewall com tradues SNAT e logging remoto. A Tabela 4.4 sumariza os resultados obtidos nos experimentos realizados. Nessa tabela as informaes sobre utilizao de CPU so omitidas, pois praticamente no houve variao nos experimentos realizados; pelo mesmo motivo, considera-se apenas a escrita em disco. As informaes sobre memria so obtidas da comparao com o cenrio sem logging.

67

Tabela 4.4: Resumo dos resultados obtidos no experimento de avaliao de desempenho do NFCT-SNATLOG Memria Escrita em disco Livre Buffers Cache Min Mdia Max Logging local -7.65% 1.22% 5.66% 6.14 KB/s 23.9 KB/s 41.47 KB/s Logging remoto -0.92% 0.63% 6.14 KB/s 9.33 KB/s 26.62 KB/s Cenrio

4.3.3

ANLISE DOS RESULTADOS

A partir da anlise dos resultados para os experimentos apresentados nesta seo, alguns pontos importantes merecem destaque: O registro das tradues SNAT do iptables atravs do NFCT-SNATLOG mostra-se vivel levando-se em considerao a possibilidade de auditoria do sistema quando de sua utilizao. No que tange carga inserida no sistema, acredita-se que ela no ser o fator limitante da capacidade de processamento do rewall; Embora este trabalho no tenha avaliado diretamente as questes relativas ao espao para armazenamento dos logs das tradues, os resultados dos experimentos com logging local e logging remoto apontam para maiores vantagens na adoo do segundo cenrio, onde um terceiro servidor ser responsvel pelo armazenamento dos logs (permitindo, assim, planejar a utilizao de espao em disco nesse servidor); Utilizar um nmero grande de mquinas por endereo IP de NAT no uma boa prtica para o tratamento de incidentes de segurana (ou qualquer outro processo investigativo que necessite realizar buscas nos logs das tradues). Recomenda-se, ento, aprimorar a distribuio de endereos internos da instituio para os endereos globais que sero usados no NAT. Por exemplo, para instituies que possuem um esquema de segmentao da rede em VLANs bem denido, uma possibilidade atribuir um endereo IP de NAT por VLAN. No entanto, cada cenrio necessita de avaliao particular.

68

CONCLUSO

O crescimento atual da Internet tem inuenciado diretamente no aumento do nmero de incidentes de segurana. Como consequncia direta desses incidentes pode-se listar as perdas nanceiras decorrentes dos gastos com anlise e remoo de malwares, perda de produtividade, queda de receita devido indisponibilidade de sistemas, alm da utilizao indevida de recursos da instituio para atividade maliciosa. Uma vez que nem todos os incidentes podem ser prevenidos (SCARFONE; GRANCE; MASONE, 2008), faz-se necessrio o desenvolvimento da capacidade de tratar e responder aos incidentes de segurana reportados uma instituio. Entretanto, a identicao e tratamento de um incidente de segurana no uma tarefa simples. Pelo contrrio, exige que uma srie de medidas seja tomada para identicar, isolar e tratar a origem real do incidente. Em particular, nas instituies de ensino e pesquisa, o tratamento e resposta aos incidentes reportados so ainda mais complicados. Essa diculdade inerente utilizao de tcnicas como NAT e DHCP, e ao grande volume de dados a serem manipulados no tratamento de uma noticao. Alm disso, deve-se perceber que a maior parte dos incidentes reportados a uma instituio so causados por ferramentas que comprometem a mquina de forma automatizada; a prpria noticao de incidente de segurana geralmente automatizada. Dessa maneira, tratar manualmente um incidente que foi gerado e reportado de forma automatizada invivel. Faz-se necessria a utilizao de ferramentas que automatizem o processo de tratamento de incidentes, ou, pelo menos, parte dele. Nesse sentido, duas etapas com grande possibilidade de automatizao so a deteco e isolamento da origem do incidente. Este trabalho apresenta uma ferramenta para automatizar o processo de tratamento de incidentes de segurana, o TRAIRA (um acrnimo para Tratamento de Incidentes de Rede Automatizado), que atua nas etapas de deteco e isolamento da origem do incidente, deixando a cargo da equipe de segurana apenas as prximas medidas a serem tomadas. Com a utilizao do TRAIRA, reserva-se o time de segurana da instituio (cujo custo de contratao comumente alto) para o tratamento de incidentes mais importantes ou complexos e para as outras atividades de segurana, como atividades preventivas, por exemplo.

69

Desenvolvido como extenso do RT, o TRAIRA permite integrao com outras ferramentas de resposta a incidentes, especialmente o RTIR (extenso do RT para Resposta a Incidentes), permitindo uma gerncia completa sobre um incidente de segurana. Atualmente, o TRAIRA encontra-se em fase de homologao na Universidade Federal da Bahia (UFBA), j permitindo o tratamento automatizado de todos os incidentes do tipo vrus/worm. Para seu correto funcionamento, o TRAIRA depende que alguns recursos bsicos de segurana estejam habilitados na instituio, dentre os quais destaca-se o registro (logging) das tradues SNAT realizadas no acesso Internet. Alguns dispositivos de NAT j possuem essa funcionalidade nativamente, como o caso do rewall ASA da CISCO; outros no possuem. O IPTables/Netlter, o rewall nativo do Linux, por exemplo, no capaz de registrar as tradues NAT. Por ser uma ferramenta bastante utilizada, principalmente nas instituies de ensino e pesquisa, este trabalho prope, implementa e avalia uma aplicao que adiciona tal funcionalidade ao iptables, o NFCT-SNATLOG. O NFCT-SNATLOG uma aplicao em espao de usurio que monitora a tabela de rastreamento de conexes do kernel do Linux e registra em log (via syslog) as tradues do tipo SNAT (NAT de origem) ocorridas no sistema, incluindo apenas informaes relevantes ao tratamento de incidentes de segurana (IP e porta de origem originais, IP e porta de origem traduzidos, protocolo e durao do NAT). O fato de registrar os logs via syslog importante pois permite a implementao de um servidor de logs remoto, diminuindo o impacto que essa funcionalidade pode adicionar ao rewall. Apresenta-se tambm uma avaliao de desempenho sobre o NFCT-SNATLOG, mostrando que sua utilizao afeta muito pouco o desempenho do rewall e, portanto, sua implantao bastante vivel considerando-se a capacidade de monitoramento das conexes SNAT que ela acrescenta ao iptables. Por m, acredita-se que os resultados obtidos com esse trabalho trazem uma contribuio importante no processo de tratamento de incidentes de segurana, principalmente no que tange s instituies de ensino e pesquisa e como elas tm impactado o cenrio de (in)segurana da Internet. No obstante, alguns aspectos discutidos neste trabalho so passveis de explorao futura, os quais so listados a seguir: Estudar e comparar tcnicas de armazenamento dos logs em bancos de dados. A utilizao de um banco de dados para armazenamento dos logs em detrimento de arquivos texto pode trazer ganhos signicativos no que tange ao desempenho das consultas. Porm, deve-se levar em considerao a questo de compresso dos dados: usando-se arquivos

70

de texto do sistema de arquivos muito fcil comprimi-los e gerenciar o espao em disco ocupado pelos logs. Alguns bancos de dados tambm oferecem mecanismos para compresso dos dados. Assim, vale a pena iniciar um trabalho investigativo e comparativo entre as duas abordagens de armazenamento, a m de recomendar a utilizao de uma ou outra abordagem; Ainda sobre o armazenamento dos dados, uma abordagem que pode ser explorada sobre os campos fundamentais ao tratamento dos incidentes de segurana (ou processos de auditoria, no geral): talvez seja possvel, por exemplo, mapear o par IP/porta em um hash e, dessa forma, economizar espao de armazenamento. No entanto, deve-se considerar a expressividade do mapeamento realizado, pois no futuro pode ser necessrio obter exatamente aquele par IP/porta; Vericar de forma mais detalhada a integrao do TRAIRA com o RTIR a m de prover um ambiente mais completo de gerncia de incidentes de segurana; Avaliar os impactos das caractersticas dessa nova Internet do futuro (j presente em alguns aspectos), como mobilidade, utilizao de IPv6 e m terico da necessidade de NAT, dentre outros aspectos, no processo de tratamento de incidentes de segurana. No caso da mobilidade, por exemplo, detectar e isolar um dispositivo mvel na rede muito mais complicado que uma estao de trabalho xa de uma unidade. Com relao utilizao de IPv6, deve-se observar se o NAT no ser mesmo utilizado como atualmente ou ainda se o mapeamento IPv6 global para mquina interna ser na proporo um para um, como espera-se.

71

APNDICE A -- FERRAMENTAS PARA AVALIAO DE DESEMPENHO DO NFCT-SNATLOG

Listagem A.1: Servidor UDP para transferncia de dados usado nos experimentos do NFCTSNATLOG
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 } p e r r o r ( " bind " ) ; exit (1) ; } my_addr . s i n _ f a m i l y = AF_INET ; my_addr . s i n _ p o r t = h t o n s ( a t o i ( a r g v [ 1 ] ) ) ; my_addr . s i n _ a d d r . s _ a d d r = INADDR_ANY ; memset (&( my_addr . s i n _ z e r o ) , \ 0 , 8 ) ; i f ( b i n d ( s o c k f d , ( s t r u c t s o c k a d d r )&my_addr , s i z e o f ( s t r u c t s o c k a d d r ) ) == 1) { } i f ( ( s o c k f d = s o c k e t ( AF_INET , SOCK_DGRAM, 0 ) ) == 1) { perror ( " socket " ) ; exit (1) ; # include # include # include # include # include # include # include # include # include < s t d i o . h> < s t d l i b . h> < u n i s t d . h> < e r r n o . h> < s t r i n g . h> < s y s / t y p e s . h> < s y s / s o c k e t . h> < n e t i n e t / i n . h> < a r p a / i n e t . h>

# d e f i n e MAXBUFLEN 1024 / / 1MB i n t main ( i n t a r g c , char a r g v ) { int sockfd ; s t r u c t s o c k a d d r _ i n my_addr ; struct sockaddr_in their_addr ; i n t addr_len , numbytes ; char b u f [MAXBUFLEN ] ; i f ( argc < 1) { p r i n t f ( " Usage : %s < P o r t t o l i s t e n > \ n " , a r g v [ 0 ] ) ; exit (1) ;

72
35 36 37 38 39 40 41 42 43 44 45 } } close ( sockfd ) ; return 0; } p r i n t f ( " g o t p a c k e t from %s :%d \ n " , i n e t _ n t o a ( t h e i r _ a d d r . s i n _ a d d r ) , n t o h s ( t h e i r _ a d d r . s i n _ p o r t ) ) ; w h i l e ( 1 ) { / / main a c c e p t ( ) l o o p addr_len = sizeof ( struct sockaddr_in ) ; i f ( ( n u m b y t e s = r e c v f r o m ( s o c k f d , buf , MAXBUFLEN 1 , 0 , ( s t r u c t s o c k a d d r )&t h e i r _ a d d r , &a d d r _ l e n ) ) == 1) { p e r r o r ( " recvfrom " ) ; continue ;

Listagem A.2: Aplicao para execuo de mltiplicas conexes em paralelo, usando o netcat e iperf
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 } s p r i n t f ( comando_tcp , " i p e r f c %s p 5001 n 64K" , a r g v [ 1 ] ) ; / / f o r t h e UDP c o n n e c t i o n we t r a n s f e r o u r own d a t a ! : ) s p r i n t f ( comando_udp , " nc u %s 6001 q 0 < %s " , a r g v [ 1 ] , a r g v [ 0 ] ) ; f o r ( t = 0 ; t < a t o i ( a r g v [ 2 ] ) ; t ++) { p r i n t f ( " I n main : c r e a t i n g t h r e a d %l d \ n " , t ) ; r c = p t h r e a d _ c r e a t e (& t h r e a d s [ t ] , NULL, r u n _ t h r e a d , ( v o i d ) t ) ; i f ( rc ) { p r i n t f ( "ERROR ; r e t u r n c o d e from p t h r e a d _ c r e a t e ( ) i s %d \ n " , r c ) ; i n t main ( i n t a r g c , char a r g v [ ] ) { p t h r e a d _ t t h r e a d s [MAX_THREADS ] ; int rc ; long t ; i f ( argc < 2) { p r i n t f ( " Usage : %s <Remote IP > <Number o f T h r e a d s > \ n " , a r g v [ 0 ] ) ; exit (1) ; } } p t h r e a d _ e x i t (NULL) ; } i f ( s y s t e m ( comando_udp ) ) { p e r r o r ( " f a i l e d t o r u n i p e r f UDP" ) ; void r u n _ t h r e a d ( void t h r e a d i d ) { i f ( system ( comando_tcp ) ) { p e r r o r ( " f a i l e d t o r u n i p e r f TCP" ) ; char c o m a n d o _ t c p [ 1 0 2 4 ] ; char comando_udp [ 1 0 2 4 ] ; # i n c l u d e < p t h r e a d . h> # i n c l u d e < s t d i o . h> # i n c l u d e < s t d l i b . h> # i n c l u d e < u n i s t d . h> # d e f i n e MAX_THREADS 100

73
38 39 40 41 42 } } p t h r e a d _ e x i t (NULL) ; } e x i t ( 1) ;

74

REFERNCIAS BIBLIOGRFICAS
ARVIDSSON, J. et al. TERENAS Incident Object Description and Exchange Format Requirements. IETF, fev. 2001. RFC 3067 (Informational). (Request for Comments, 3067). Disponvel em: <http://www.ietf.org/rfc/rfc3067.txt>. AYUSO, P. Netlters connection tracking system. LOGIN: The USENIX magazine, v. 31, p. 3439, 2006. BESTPRACTICAL. RT: Request Tracker. 2010. ltimo acesso em 23 de Novembro de 2010. Disponvel em: <http://www.bestpractical.com/rt/>. BESTPRACTICAL. RTIR: RT for Incident Response. 2010. ltimo acesso em 03 de Dezembro de 2010. Disponvel em: <http://www.bestpractical.com/rtir/>. BEZERRA, J. A. Relatrio de atividades - Operao e Segurana - parte II. [S.l.], 2009. CAIS. CAIS - Centro de Atendimento a Incidentes de Segurana. 2010. ltimo acesso em 14 de Novembro de 2010. Disponvel em: <http://www.rnp.br/cais/>. CERON, J. et al. O processo de tratamento de incidentes de segurana. IV Workshop de TI das IFES, 2009. CERT.BAHIA. CERT.Bahia - Grupo e Resposta a Incidentes de Segurana na Bahia/Brasil. 2010. ltimo acesso em 14 de Novembro de 2010. Disponvel em: <http://www.certbahia.popba.rnp.br>. CERT.BAHIA. Estatsticas do CERT.Bahia. 2010. ltimo acesso em 03 de Dezembro de 2010. Disponvel em: <http://www.certbahia.pop-ba.rnp.br/Estatisticas>. CERT.BR. Cartilha de Segurana para Internet. Parte VII: Incidentes de Segurana e Uso Abusivo da Rede. 2006. ltimo acesso em 14 de Novembro de 2010. Disponvel em: <http://cartilha.cert.br/download/cartilha-07-incidentes.pdf>. CERT.BR. Cartilha de Segurana para Internet. Parte VIII: Cdigos Maliciosos (Malware). 2006. ltimo acesso em 14 de Novembro de 2010. Disponvel em: <http://cartilha.cert.br/download/cartilha-08-malware.pdf>. CERT.BR. Resultados Preliminares do Projeto SpamPots. 2007. ltimo acesso em 03 de Dezembro de 2010. Disponvel em: <http://www.cert.br/docs/whitepapers/spampots/>. CERT.BR. CERT.br - Grupo Resposta a Incidentes de Segurana no Brasil. 2010. ltimo acesso em 14 de Novembro de 2010. Disponvel em: <http://www.cert.br>. CERT/CC. Computer Segurity Incident Response Team FAQ. 2010. ltimo acesso em 14 de Novembro de 2010. Disponvel em: <http://www.cert.org/csirts/csirt_faq.html>.

75

CISCO, A. 5500 Series Adaptive Security Appliances. Cisco Systems, Inc, 2005. CWG. Concker Working Group. 2010. ltimo acesso em 03 de Dezembro de 2010. Disponvel em: <http://www.conckerworkinggroup.org/wiki/>. DEBAR, H.; CURRY, D.; FEINSTEIN, B. The Intrusion Detection Message Exchange Format (IDMEF). IETF, mar. 2007. RFC 4765 (Experimental). (Request for Comments, 4765). Disponvel em: <http://www.ietf.org/rfc/rfc4765.txt>. DROMS, R. Dynamic Host Conguration Protocol. IETF, mar. 1997. RFC 2131 (Draft Standard). (Request for Comments, 2131). Updated by RFCs 3396, 4361, 5494. Disponvel em: <http://www.ietf.org/rfc/rfc2131.txt>. EGEVANG, K.; FRANCIS, P. The IP Network Address Translator (NAT). IETF, maio 1994. RFC 1631 (Informational). (Request for Comments, 1631). Obsoleted by RFC 3022. Disponvel em: <http://www.ietf.org/rfc/rfc1631.txt>. FARNHAM, G. Cisco Security Agent and Incident Handling. SANS Institute InfoSec Reading Room, 2009. FEINSTEIN, B.; MATTHEWS, G. The Intrusion Detection Exchange Protocol (IDXP). IETF, mar. 2007. RFC 4767 (Experimental). (Request for Comments, 4767). Disponvel em: <http://www.ietf.org/rfc/rfc4767.txt>. GERHARDS, R. The Syslog Protocol. IETF, mar. 2009. RFC 5424 (Proposed Standard). (Request for Comments, 5424). Disponvel em: <http://www.ietf.org/rfc/rfc5424.txt>. HONEYNET.BR. Brazilian Honeypots Alliance. 2010. ltimo acesso em 03 de Dezembro de 2010. Disponvel em: <http://www.honeypots-alliance.org.br/>. JAIN, R. The art of computer systems performance analysis: techniques for experimental design, measurement, simulation, and modeling. [S.l.]: Wiley New York, 1991. KAISER, J. et al. Automated resolving of security incidents as a key mechanism to ght massive infections of malicious software. In: CITESEER. GI SIDAR International Conference on IT-Incident Management and IT-Forensics (IMF 2006), volume LNI P-97. [S.l.], 2006. p. 92103. KLINGMLLER, T. SIRIOS: A Framework for CERTs. FIRST Conference on Computer Security Incident Handling, 2005. LUNDELL, M. Incident Handling as a Service. SANS Institute InfoSec Reading Room, 2009. MOTA FILHO, J. Firewall com iptables. 2003. ltimo acesso em 03 de Dezembro de 2010. Disponvel em: <http://www.eriberto.pro.br/iptables/>. NETFILTER. conntrack-tools: Netlters connection tracking userspace tools. 2010. ltimo acesso em 03 de Dezembro de 2010. Disponvel em: <http://conntrack-tools.netlter.org/>. NETFILTER. Netlter: rewalling, NAT and packet mangling for linux. 2010. ltimo acesso em 27 de Novembro de 2010. Disponvel em: <http://www.netlter.org/>.

76

NETFILTER. The netlter.org libnetlter_conntrack project. 2010. ltimo acesso em 03 de Dezembro de 2010. Disponvel em: <http://www.netlter.org/projects/libnetlter_conntrack/index.html>. NFCT-SNATLOG. NFCT-SNATLOG - Netlter Conntrack SNAT Logging Tool. 2010. ltimo acesso em 27 de Novembro de 2010. Disponvel em: <http://github.com/italovalcy/nfctsnatlog>. OTRS. Open Source Trouble Ticket System. 2010. ltimo acesso em 23 de Novembro de 2010. Disponvel em: <http://www.otrs.org/>. PERL.ORG. The Perl Programming Language. 2010. ltimo acesso em 14 de Novembro de 2010. Disponvel em: <http://www.perl.org>. PLUMMER, D. Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware. IETF, nov. 1982. RFC 826 (Standard). (Request for Comments, 826). Updated by RFCs 5227, 5494. Disponvel em: <http://www.ietf.org/rfc/rfc826.txt>. REKHTER, Y. et al. Address Allocation for Private Internets. IETF, fev. 1996. RFC 1918 (Best Current Practice). (Request for Comments, 1918). Disponvel em: <http://www.ietf.org/rfc/rfc1918.txt>. RNP. A rede Ip. 2007. ltimo acesso em 22 de Novembro de 2010. Disponvel em: <http://www.rnp.br/ipe/>. RNP. Rede Ip: Poltica de Uso. 2007. ltimo acesso em 29 de Setembro de 2010. Disponvel em: <http://www.rnp.br/conexao/>. SCARFONE, K.; GRANCE, T.; MASONE, K. Computer Security Incident Handling Guide. NIST Special Publication, v. 80061, 2008. SOUPPAYA, M.; KENT, K. Guide to Computer Security Log Management. NIST Special Publication, p. 80092, 2006. TRAIRA. TRAIRA - Tratamento de Incidentes de Rede Automatizado. 2010. ltimo acesso em 03 de Dezembro de 2010. Disponvel em: <http://www.pop-ba.rnp.br/arquivos/RT-ExtensionTraira.tgz>. WERLINGER, R.; BOTTA, D.; BEZNOSOV, K. Detecting, analyzing and responding to security incidents: a qualitative analysis. In: ACM. Proceedings of the 3rd symposium on Usable privacy and security. [S.l.], 2007. p. 149150.