ptguard: Desenvolvimento de um Software para Detecção e Controle de Aplicações Ponto a Ponto

Transcrição

1 ptguard: Desenvolvimento de um Software para Detecção e Controle de Aplicações Ponto a Ponto Gustavo Beltrami Rossi Instituto Nacional de Pesquisas Espaciais Laboratório Associado de Computação e Matemática Aplicada São José dos Campos SP rossi@lac.inpe.br Antonio Montes Filho Instituto Nacional de Pesquisas Espaciais Laboratório Associado de Computação e Matemática Aplicada São José dos Campos SP montes@lac.inpe.br Resumo Este artigo apresenta uma metodologia para o desenvolvimento de um software com capacidade de análise de tráfego de rede em camada de aplicação, permitindo a criação de regras de bloqueio, controle de utilização de banda de rede e emissão de relatórios estatísticos de protocolos ponto a ponto. Isso auxiliará os administradores de rede a implementar políticas de segurança e de uso adequado de forma mais eficaz. 1. Introdução O conceito de comunicação ponto a ponto, referenciado neste artigo simplesmente como P2P (peerto-peer), foi utilizado inicialmente para definir um modelo de comunicação onde ambos os nós são iguais e ambos podem inicializar uma sessão. Atualmente, P2P pode ser definido como um compartilhamento de recursos e serviços computacionais com a troca direta entre os hosts participantes da rede. Os recursos e serviços incluem a troca de informação, ciclos de processamento, poder de armazenamento e conectividade, permitindo que os participantes elevem seu poder coletivo para beneficiar toda a rede [6]. Os software P2P permitem que computadores individuais troquem mensagens e compartilhem vários tipos de arquivos e informações, conectando computadores sem a utilização de um servidor central utilizando comunicação ponto a ponto real. A ausência de servidor central cria uma rede parecida com uma malha, onde todos os nós da rede estão interligados uns aos outros, e cada nó atua como cliente e servidor de informações, simultaneamente. Os software de comunicação ponto a ponto elevam a idéia de que a Internet é uma rede de compartilhamento a novos patamares, onde seus desenvolvedores pregam a livre distribuição de informação sem qualquer tipo de restrição Cenário atual Os software P2P estiveram em evidência nos noticiários devido às atuais e potenciais leis sobre direitos autorais. A Napster [9], companhia que criou um software para compartilhamento de arquivos do tipo MP3, foi condenada por infringir os direitos autorais de artistas e gravadoras ao permitir a troca de músicas entre os seus usuários. Já atualmente, os software P2P não só incluem a funcionalidade de compartilhamento de todos os tipos de arquivos, mas também mensagens instantâneas, computação distribuída e poderosas ferramentas de buscas, devendo atingir rapidamente uma popularidade ainda maior do que o Napster conseguiu. Este crescimento e popularidade podem ser facilmente observados verificando os software mais procurados em sites de download. 2. Descrição do problema Mesmo com as restrições impostas pelos órgãos responsáveis pelos direitos autorais, como RIAA (Recording Industry Association of America) [12] e MPAA (Motion Picture Association of America) [8], a utilização dos software P2P vem crescendo. Uma análise da companhia WebNoize estimou que 3.05 bilhões de arquivos foram transferidos utilizando a rede FastTrack [18] e Gnutella [19] durante agosto de Este valor é muito similar aos 2.79 bilhões de arquivos que foram transferidos utilizando a rede Napster em fevereiro de 2001 no pico de sua popularidade. Porém, tão importante quanto a preocupação com os direitos autorais envolvidos nos arquivos compartilhados por esses software, está o potencial relacionado a problemas de segurança para corporações e usuários domésticos. Dessa forma, os software P2P ameaçam, entre outras coisas, com consumo da largura de banda, violação das responsabilidades e uso aceitável, distribuição de vírus e cavalos de tróia e exposição de informações confidenciais [11].

2 As aplicações P2P podem fazer uso de portas conhecidas de outros serviços, como HTTP, FTP, etc ou até mesmo trocar automaticamente de porta, buscando uma porta aberta para trafegar suas mensagens. Dessa maneira as aplicações P2P podem passar por servidores proxy e firewalls, transformando o bloqueio e controle dessas aplicações em uma tarefa difícil e complicada. Figura 1. Modelo cliente/servidor e P2P identificada, o módulo de controle é acionado. Com os dados da sessão P2P, o módulo de controle é responsável pelo controle do tráfego na interface de saída do gateway. Ambos módulos de análise e controle fornecem informações e dados para o módulo de relatório. Nas sessões a seguir será melhor descrito o funcionamento de cada módulo. 3. Metodologia O objetivo desse artigo é descrever uma aplicação capaz de analisar o conteúdo do tráfego de rede através da busca por padrões ou assinaturas, e assim identificar o protocolo P2P utilizado. A partir dessa informação, tomar decisões sobre restrições ou bloqueio da aplicação utilizando uma configuração pré-estabelecida. Esse sistema deve operar em tempo real e deve ser otimizado para permitir sua aplicação em redes de alta velocidade. Para o correto funcionamento da aplicação, é necessário seu posicionamento em um ponto de passagem de tráfego, normalmente em um gateway da rede interna para a Internet. A aplicação foi dividida em quatro grandes módulos: módulo principal: responsável pela inicialização e controle dos demais módulos; módulo de análise: responsável pela captura e análise do tráfego de rede; módulo de controle: responsável pelo controle de banda e qualidade de serviço de rede; módulo de relatório: responsável pela criação de relatórios contendo a utilização de banda por aplicação. A relação entre os módulos ocorre de acordo com o esquema proposto na Figura 1. O módulo de análise atua na interface de rede interna do gateway ou em uma máquina sensor dedicado, fazendo análise do tráfego de rede, buscando por assinaturas de protocolos P2P configurados. Quando uma assinatura é 4. Módulo de análise O módulo de análise é responsável pela captura e análise do tráfego de rede, buscando padrões ou assinaturas. Para se configurar corretamente esses padrões, um profundo conhecimento do protocolo P2P desejado é necessário, e na maioria dos casos, o protocolo é proprietário, fechado e não documentado. Nesses casos são utilizados software de captura de pacotes com capacidade de remontagem de sessão [17] em um ambiente de laboratório controlado voltado para análise do tráfego de rede. Técnicas de engenharia reversa são aplicadas na sessão capturada com a finalidade de se encontrar padrões que identifiquem a utilização do protocolo P2P Criação das assinaturas A fim de exemplificar a criação de assinaturas, será utilizado o protocolo Gnutella [4]. O protocolo Gnutella estabelece um sistema distribuído simples e confiável para compartilhamento de arquivos baseado na arquitetura ponto a ponto descentralizada. A rede é formada por nós que cooperam independentemente. Toda comunicação é realizada utilizando o protocolo TCP/IP. Cada pedaço de informação é chamado de pacote, assim como nos termos da Internet. Um servent 1 1 Host participante da rede Gnutella

3 T 2003/05/26 15:03: : > :6346 [AP] 47 4e c 4c f 4e 4e GNUTELLA CONNECT 2f 30 2e 36 0d 0a /0.6.. T 2003/05/26~15:03: :6346 -> :33077 [AP] 47 4e c 4c 41 2f 30 2e GNUTELLA/ f 4b 0d 0a OK.. Figura 2. Captura do tráfego Gnutella no momento em que um servent se conecta a rede se conecta na rede Gnutella estabelecendo uma conexão com outro servent já previamente conectado. Uma vez que o endereço de um servent é obtido, uma conexão TCP é criada, e a seguinte cadeia de caracteres de requisição de conexão é enviada: GNUTELLA CONNECT/0.6\r\n O servent desejando aceitar a requisição de conexão deve responder com a cadeia de caracteres: GNUTELLA/ <string>\n\r\n\n A Figura 2 mostra o conteúdo dos pacotes relevantes capturados do tráfego de rede no momento em que um servent se conecta a rede Gnutella Sistema detector de intrusão De posse das assinaturas, o sistema detector de intrusão (NIDS Network Intrusion Detection System) Snort [13,14] é utilizado para realizar a análise do tráfego de rede. O Snort é alimentado com as regras referentes as assinaturas encontradas em cada protocolo. Desta forma, as seguintes regras podem ser configuradas para a assinatura descrita na seção 4.1: alert tcp $HOME NET any -> $EXT NET any (msg:"gnutella connect request"; flow:to server,established; content:"gnutella CONNECT/"; nocase; offset:0; depth:17; sid: ; rev:1; classtype:misc-activity;) No momento que o sistema detector de intrusão encontra a assinatura configurada, um relatório de alerta como o exemplificado abaixo é emitido. 05/15-11:44: [**] [1: :1] GNUTella connect request [**] [Classification: Misc activity] [Priority: 3] TCP a.b.c.d:f -> z.y.x.w:v O sistema de processamento de logs do Snort Barnyard faz a análise dos dados do alerta e através do desenvolvimento de um plugin de saída é responsável por extrair somente os dados relevantes de cada alerta, fazendo o preenchimento da estrutura ptguardalertdata: typedef struct _ptguardalertdata{ u_int32_t sid; struct timeval ts; u_int32_t sip; u_int32_t dip; u_int16_t sp; u_int16_t dp; u_int32_t protocol; } ptguardalertdata; Assim, a estrutura contendo as informações de protocolo, IPs e portas dos hosts participantes, juntamente com o identificador e o timestamp gerado da regra acionada são enviadas ao módulo principal através de datagrama UDP não bloqueante, que faz o acionamento do módulo de controle. Desta maneira, o processamento dos alertas não irá impactar no correto funcionamento do NIDS, além de possibilitar a instalação do módulo de análise em uma máquina sensor dedicada, diferente da máquina onde os demais módulos do programa são executados. 5. Módulo de controle Com alocação de banda e modelagem de tráfego baseada em uma política pré-estabelecida, o módulo de controle permite que os administradores de rede atuem com inteligência na classificação, análise e outras funções de monitoração da rede. Assim aplicações críticas podem ser protegidas com garantia de banda. O software utilizado na implementação do módulo foi o ALTQ [2]. ALTQ é uma estrutura para sistemas operacionais Unix/BSD que implementa várias disciplinas de enfileiramento e componentes relacionados a qualidade de serviço [3] (QoS Quality of Service). Desde o lançamento da versão 3.3 do OpenBSD, o ALTQ foi incorporado ao filtro de pacotes PF [10]. Para se fazer uso das propriedades de controle de banda e prioridade de tráfego é utilizado a disciplina de enfileiramento CBQ. Assim as informações passadas pelo módulo de análise são inseridas da seguinte forma na configuração do PF: class ROOT ne1 NULL pbandwidth 100 class cbq ne1 <name> ROOT \ priority <pri> \ exactbandwidth <bandwidth> \ [borrow] onde a prioridade é definida em pri podendo variar de 0 a 7. Números maiores tem maior prioridade. A configuração da largura de banda disponível para a classe é definida em bandwidth, onde o valor deve ser expresso em bps. O parâmetro borrow pode ser utilizado para permitir que banda sobressalente seja emprestada pela classe pai, no caso da classe configurada estar com o

4 limite estourado. Nessa configuração a classe pai é definida pela classe ROOT e possui 100% da banda disponível definido na interface. Ainda na configuração do PF, o programa utiliza o conceito de ancoras definindo em que ponto da configuração do firewall serão inseridas as regras de filtragem com os valores coletados pelo módulo de análise. As regras de filtragem utilizam as classes de controle de banda CBQ criadas Inicialização do módulo Embora a maioria dos sistemas ponto a ponto, tem um protocolo que possibilita a configuração da porta em que o nó irá se comunicar na rede, muitos usuários não alteram o seu valor padrão. Uma vez que no filtro de pacotes PF a busca por hosts em tabelas de endereços são mais rápidas e otimizadas que a busca em regras de filtragem, quando o módulo de controle é inicializado, uma tabela de endereços e uma regra para os valores padrão de porta são criados. O filtro de pacotes é controlado pelo kernel. O pseudo dispositivo /dev/pf permite que processos de usuários controlem o comportamento do filtro de pacotes através da interface ioctl. Assim, para a criação da tabela de endereços, é necessário o correto preenchimento das estruturas prf_table e pfioc_table. As estruturas são preenchidas com o nome do protocolo tname e a opção PFR_TFLAG_PERSIST é utilizada para persistência da tabela mesmo quando estiver vazia. struct pfr_table tbl; strlcpy(tbl.pfrt_name, tname, sizeof(tbl.pfrt_name)); struct pfioc_table ptbl ptbl.pfrio_flags = PFR_TFLAG_PERSIST; ptbl.pfrio_buffer = &tbl; ptbl.pfrio_size = 1; ioctl(dev, DIOCRADDTABLES, &ptbl)) A tabela é inserida no kernel pela interface ioctl DIOCRADDTABLES. De maneira semelhante, para a criação da regra de filtragem, as estruturas pf_rule e pfioc_rule devem ser preenchidas, de forma adicionar uma regra com a seguinte sintaxe: pass out quick on <ifname> inet \ proto <proto> from any to <table> port <portno> \ keep state queue <qname> onde table é o nome da tabela, portno é o valor padrão da porta e qname é o nome da classe CBQ configurada para o protocolo P2P. O preenchimento da estrutura e a utilização da interface ioctl serão descritos na seção Adicionar regras de controle Ao receber a estrutura de alerta definida na Seção 4.2, o módulo principal verifica se o identificador sid pertence a algum protocolo P2P configurado e em seguida verifica se a porta utilizada é a padrão. Em caso afirmativo, o novo host é adicionado a tabela de endereços através da interface ioctl DIOCADDRADDRS: struct pfioc_table io; struct pfr_addr addr; addr.pfra_af = AF_INET; addr.pfra_ip4addr.s_addr = a_addr.s_addr; addr.pfra_net = 32; io.pfrio_buffer = &addr; io.pfrio_size = 1; ioctl(dev, DIOCRADDADDRS, &io)) onde a_addr.s_addr contém o endereço do host a ser adicionado. Caso contrário, uma nova regra de filtragem é criada, utilizando os endereços IPs e portas como parâmetros para preencher a estrutura pf_rule: struct pf_rule r; r.action = PF_PASS; r.direction = PF_OUT; r.log = 0; r.quick = 1; strlcpy(r.ifname, ifname, sizeof(r.ifname)); r.af = AF_INET; r.keep_state = PF_STATE_NORMAL; r.proto = alert.proto; strlcpy(r.qname, qname, sizeof(r.qname)); r.src.addr.type = PF_ADDR_ADDRMASK; r.src.addr.v.a.addr.v4.s_addr = htonl(alert.sip); r.src.addr.v.a.mask.addr32[0] = 0xFFFFFFFF; r.src.port_op = PF_OP_EQ; r.src.port[0] = htons(alert.sp); r.dst.addr.type = PF_ADDR_ADDRMASK; r.dst.addr.v.a.addr.v4.s_addr = htonl(alert.dip); r.dst.addr.v.a.mask.addr32[0] = 0xFFFFFFFF; r.dst.port_op = PF_OP_EQ; r.dst.port[0] = htons(alert.dp); formando a seguinte regra do PF: pass out quick on <ifname> inet \ proto <alert.proto> \ from <alert.sip> port <alert.sp> \ to <alert.dip> port <alert.dp> \ keep state queue <qname> Para adicionar a regra é utilizado a interface ioctl DIOCADDRULE: struct pfioc_rule prule; memcpy(&prule.rule, &r, sizeof(struct pf_rule));

5 strlcpy(prule.anchor, anchorname, sizeof(anchorname)); strlcpy(prule.ruleset, rulesetname, sizeof(rulesetname)); ioctl(dev, DIOCADDRULE, &prule) onde anchorname e rulesetname especificam a ancora onde a regra deve ser inserida Remover regras de controle O módulo de controle faz o tratamento de limpeza de regras de duas maneiras: a remoção de um host inativo da tabela de endereços e a remoção de uma regra de filtragem. Para remover um host da tabela de endereços, o módulo verifica se tempo de permanência de endereços pré-estabelecido terminou, e em seguida utiliza a interface ioctl DIOCRDELADDRS, responsável pela remoção do endereço armazenado na estrutura addr da tabela: struct pfioc_table io; io.pfrio_table = tbl; io.pfrio_buffer = &addr; io.pfrio_size = 1; ioctl(dev, DIOCRDELADDRS, &io); No caso de remover uma regra de filtragem, o módulo verifica se não existe nenhum estado de sessão associado a regra: struct pfioc_rule prule; ioctl(dev, DIOCGETRULE, &prule); if (prule.rule.states <= 0) { prule.action = PF_CHANGE_GET_TICKET; ioctl(dev, DIOCCHANGERULE, &prule) prule.action = PF_CHANGE_REMOVE; ioctl(dev, DIOCCHANGERULE, &prule) } Em um primeiro momento a interface ioctl DIOCGETRULE é utilizada para carregar a regra na estrutura pfioc_rule. Caso o número de sessões associadas a regra seja zero, um ticket de requisição de mudança é recebido e finalmente tem-se a ação de remover a regra. 6. Módulo de relatório O módulo de relatório implementa um agente SNMP para disponibilizar os dados estatísticos referentes a utilização de banda de cada protocolo P2P configurado. Desta forma, qualquer software de gerência de rede que utiliza o protocolo SNMP pode ser usado para plotar os gráficos estatísticos dos objetos disponíveis do agente. Foi desenvolvido uma MIB específica contendo as definições de cada objeto encontrado no agente SNMP do programa. Cada elemento é detalhado a seguir: +-ptguard(1) +-ptgobjects(1) +-Integer32 ptgnumber(1) Range: TimeTicks ptgtablelastchange(2) +-ptgprotocol(2) +-ptgtable(1) +-ptgentry(1) Index: ptgindex +-Integer32 ptgindex(1) +-String ptgname(2) Size: String ptgdescr(3) Size: TimeTicks ptglastchange(4) +-Counter ptgbytes(5) +-Counter ptgpkts(6) +-Counter ptgeval(7) onde ptgnumber contém o número de protocolos P2P presentes no sistema. O objeto ptgtablelastchange contém o valor de sysuptime no momento da última criação ou remoção de uma entrada no objeto ptgtable. Se o número de entradas não foi alterado desde a última reinicialização do sub-sistema local de gerência de rede, então esse objeto contém o valor zero. E por fim, a definição do objeto ptgtable como uma seqüência de entradas do tipo PtgEntry, contendo informações sobre o nome e descrição do protocolo, valor de sysuptime desde a última atualização do objeto, valor do número de bytes, pacotes e número de vezes que as regras de filtragem do protocolo foram utilizadas. Para manter os valores dos objetos atualizados, o módulo de relatório extrai as informações da estrutura pfioc_rule de cada regra de filtragem dos protocolos P2P configurados, utilizando a interface ioctl DIOCGETRULE: struct pfioc_rule prule; ioctl(dev, DIOCGETRULE, &prule) bytes += prule.rule.bytes; packets += prule.rule.packets; evaluations += prule.rule.evaluations; 7. Módulo principal Como já mencionado, o módulo principal é responsável pela correta inicialização dos demais módulos e por controlar toda a comunicação entre eles. O programa ao ser inicializado, faz a carga de um arquivo de configuração padrão XML, contendo as opções gerais do programa e as informações sobre os protocolos a serem controlados. A sintaxe e os valores padrão para cada atributo são definidos pelos seguintes trechos da DTD. Inicialmente, a DTD especifica os possíveis elementos encontrados no arquivo de configuração XML, sendo os elementos pf e protocolo requeridos:

6 <!ELEMENT ptguard (pidfile?, options?, pf, tbl?, snort?, snmpd?, protocols)> A seguir, tem-se a definição das entradas e atributos para o elemento pf, onde o elemento if especifica o nome da interface do gateway, em que o módulo de controle deve ser configurado: <!ELEMENT pf (devfile?, anchor?, if, tbladdr?)> <!ELEMENT devfile EMPTY> <!ATTLIST devfile path CDATA "/dev/pf"> <!ELEMENT anchor EMPTY> <!ATTLIST anchor anchorname CDATA "ptguard" rulesetname CDATA "ruleset"> <!ELEMENT if EMPTY> <!ATTLIST if name CDATA #REQUIRED> <!ELEMENT tbl EMPTY> <!ATTLIST tbl check CDATA "300" expire CDATA "3600"> Os atributos anchorname e rulesetname do elemento anchor especificam o nome da ancora configurada no firewall, onde as regras de controle serão inseridas. Depois, tem-se a definição dos atributos para os elementos snort e snmpd, onde é configurado o valor para a porta em que o módulo de alerta irá receber os logs do Snort processados pelo plugin de saída do Barnyard e a porta do agente SNMP do módulo de relatório, respectivamente: <!ELEMENT snort EMPTY> <!ATTLIST snort port CDATA "7000"> <!ELEMENT snmpd EMPTY> <!ATTLIST snmpd port CDATA "7161"> Por fim, a parte principal da configuração, contendo as definições para cada protocolo a ser monitorado, incluindo seu nome, descrição e porta de utilização padrão. <!ELEMENT protocols (protocol+)> <!ELEMENT protocol EMPTY> <!ATTLIST protocol name CDATA #REQUIRED description CDATA #IMPLIED port CDATA "0" sid CDATA #REQUIRED> onde o atributo sid contém os valores do campo de identificação das regras do Snort configuradas para o determinado protocolo. Com as informações carregadas, o módulo de análise e de relatório são inicializados. Para controle são criadas tabelas dinâmicas com as informações das sessões P2P identificadas pelo módulo de análise. Essas tabelas são constantemente atualizada pelos logs de alertas de utilização de programas P2P e também pelas informações de início e término das sessões. Todas essas informações são tratadas e armazenadas de forma que os dados contidos nas tabelas alimentem os módulos de controle e relatório. Referências [1] Caswell, B. et al. (2003). Snort 2.0 Intrusion Detection. Syngress. [2] Cho, K. (2001). The Design and Implementation of the ALTQ Traffic Management System. Keio University, Japão. URL ftp://ftp.csl.sony.co.jp/pub/kjc/papers/dissertation.ps.gz. [3] Cisco Systems. Internetwoking Technologies Handbook. Quality of Service Networking, Capítulo 49, pp [4] Clip2. The Gnutella Protocol Specification v0.4. Document Revision 1.2. URL [5] Comer, D. E. (2000). Internetworking With TCP/IP Volume I: Principles, Protocols and Architecture. 4. ed; Prentice Hall. [6] Kwok, S. et al. (2002). Peer-to-Peer Technology Business and Service Models: Risk and Opportunities. Electronic Markets. Julho. [7] McKean, C. (2001). Peer-to-Peer Security and Intel's Peerto-Peer Trusted Library. URL [8] Motion Picture Association. URL [9] Napster, Inc. URL [10] OpenBSD Packet Filter PF URL [11] Petruzzi, M., et al. (2000). Security Concerns for Peer-to- Peer Software. Key Technologies and Security, Inc. URL Security Concerns Peer-to-Peer KTSI.pdf [12] Recording Industry Association of America. URL [13] Roesch, M. (1999). Snort: Lightweight Intrusion Detection for Networks. USENIX LISA Conference. Novembro. [14] Snort. The Open Source Network IDS. URL [15] Stevens, R. W. (1994). TCP/IP Illustrated, Volume I: The Protocols. Addison-Wesley. [16] Tanenbaum, A. S. (1996). Computer Networks 3. ed; Prentice Hall. [17] The Ethereal Network Analyzer. URL [18] The FastTrack Protocol. URL [19] The Gnutella Network. URL