ISSN 1518-5974Klaubert Herr da Silveira <ksilveira@iss.net>
Internet Security Systems
Resumo
1. Introdução
2. IDS x SSL, IPSec e outros
2.1 SSL
2.2 IPSec
3. IDS em redes com switches
3.1 Port SPAN
3.2 Splitting Wire/Optical Tap
3.3 Port Mirror
4. IDS em redes de alta velocidade
5. Conclusão
Agradecimentos
Referências bibliográficas
Resumo
As tecnologias de infra-estrutura, de serviços e protocolos para redes de computadores evoluem com velocidades impressionantes e tornam-se cada vez mais complexas. Podemos citar, como exemplos de novos protocolos, o SSL (Secure Socket Layers), o IPSec (extensões de segurança para o protocolo IP) – utilizado na implementação de VPN’s. Como exemplos de novas tecnologias de interconexão e infra-estrutura, temos as redes comutadas, redes de altas velocidades etc. Estas novas tecnologias, algumas criadas com o objetivo de oferecer maior segurança nas comunicações digitais, acabam por criar dificuldades na implantação de sistemas de detecção de intrusos (IDS - Intrusion Detection System). Tais dificuldades incluem, por exemplo, a limitação de análise de tráfego dos atuais IDS’s em redes com taxas de transmissão maior que 100 Mbps e a falta de suporte a tecnologias como ATM. Para a implementação adequada de um IDS, muitas vezes são necessárias alterações estruturais na topologia destas redes, mas, sobretudo, é necessário o completo conhecimento do ambiente em questão. Uma das soluções para os problemas apresentados acima e outros descritos ao longo deste artigo é a utilização de IDS’s baseados na monitoração individual dos sistemas, conhecidos como host-based IDS (ou IDS’s híbridos), que agregam checagens do tráfego de rede destinado a tais sistemas individualmente à monitoração das atividades ocorridas no sistema analisado.
1. Introdução
Nas organizações modernas, os ambientes de redes, locais ou distribuídas, têm evoluído tecnologicamente a uma velocidade muito rápida. Em contra partida, os controles de segurança precisam ser adequados às novas tecnologias empregadas.
Para tanto, este artigo não busca a exaustão do assunto; pelo contrário, procura somente abordar algumas características dos ambientes de redes que hoje representam dificuldades na implantação de sistemas de detecção de intrusos (IDS).
Ao discutir as implementações de IDS em VPN’s – onde todo o tráfego é criptografado –, redes comutadas ou de alta velocidade (como ATM e Gigabit Ethernet), a intenção não é a de apresentar novas visões ou abordagens, mas espera-se que, de alguma forma, as idéias aqui propostas possam contribuir para aqueles que estão trabalhando ou pesquisando a implementação de IDS nos vários ambientes existentes hoje. Um artigo publicado na revista eletrônica Phrack #56 1 aborda de forma sintética o tema aqui discutido. Entretanto, a intenção deste documento é a de discorrer mais amplamente sobre o assunto, que o artigo resume da seguinte forma: "A infra-estrutura física de redes está evoluindo rapidamente; no futuro – criptografia, redes de altas velocidades e redes comutadas praticamente eliminarão os IDS’s de rede que se utilizarem da análise passiva de protocolos através capturas em modo promíscuo." 2
1 - A Phrack Magazine é uma e-zine (revista eletrônica) hacker. Nela, surgiram diversas inovações sobre segurança, como IP spoofing etc.
2 - Sasha e Beetle, 2000 [5] - "The physical network infrastructure is rapidly evolving; in the future - encryption, high wire speeds, and switched networks will practically kill those NIDS which utilize promiscuous-mode passive protocol analysis."
2. IDS x SSL, IPSec e outros
As ferramentas de IDS baseadas em rede fazem suas monitorações nos cabeçalhos dos pacotes e também em seu campo de dados, possibilitando a verificação de ataques no nível de aplicação (para pacotes TCP e UDP).
Entretanto, a necessidade de sigilo e privacidade nas transações pela Web ou em redes privadas torna o uso de sistemas de criptografia cada vez mais comuns e necessários.
A criptografia, como elemento de segurança do tráfego de informações, acaba por prejudicar outros elementos como os sistemas de detecção de intrusos (IDS). Uma vez que, em algumas tecnologias, o campo de dados é criptografado, em outras, o pacote inteiro o é (cabeçalhos e dados). Neste ambiente, uma ferramenta de IDS não será efetiva, pois os dados de um ataque podem ser encobertos pela criptografia existente no mesmo.
2.1 SSL
"O protocolo é composto de duas camadas. No nível mais baixo, sobre algum protocolo de transporte confiável (como TCP[TCP]), está o SSL Record Protocol, que é usado para o encapsulamento de vários protocolos de maior nível." 3
Conforme pode ser visto na Figura 1, o SSL é executado entre a camada de transporte e de aplicação.
Figura 1 - Representação do SSL nas camadas do TCP/IP
A criptografia da porção de dados do pacote TCP faz com que todo o conteúdo (dados) das conexões (inclusive as URLs) seja criptografado, impossibilitando a análise dos pacotes por IDS’s.
Tomemos como exemplo o ataque ao servidor Web IIS para Windows NT como o "Source Fragment Disclosure Vulnerability", publicado recentemente 4 . Quando o servidor Web possuir o protocolo SSL habilitado – comum especialmente em sites de comércio eletrônico e, muitas vezes, de uso obrigatório para acesso a qualquer diretório – os dados do ataque não serão identificados por um IDS.
Abaixo, nas Figuras 2 e 3, podemos ver uma demonstração deste ataque feito sobre o protocolo HTTP e o mesmo ataque sobre o protocolo HTTPS, resultando na exibição do conteúdo de um script ASP.
Figura 2 – Pacote HTTP com a requisição "Source Fragment Disclosure Vulnerability"
Um IDS pode facilmente detectar este tipo de ataque. O mesmo não acontece se o protocolo SSL for utilizado.
Figura 3 – Pacote HTTPS com a requisição "Source Fragment Disclosure Vulnerability"
Neste caso, um IDS não tem como detectar este tipo de ataque.
Os ataques que ocorrem no nível de aplicação podem ser usados, tanto para uma invasão, como para indisponibilização do serviço (DoS). Dessa forma, os sistemas de detecção de intrusos não terão como registrar o ataque, nem como terminar uma conexão (enviando um pacote TCP Reset para ambos os participantes) 5 , ou mesmo interagir com um firewall 6 para que este bloqueie a conexão.
3 - Freier, Karlton & Kocher (1996) [1]: "The protocol is composed of two layers. At the lowest level, layered on top of some reliable transport protocol (e.g., TCP[TCP]), is the SSL Record Protocol. The SSL Record Protocol is used for encapsulation of various higher level protocols."
4 - A página http://www.securityfocus.com/vdb/bottom.html?vid=1488 dá detalhes a respeito do ataque sobre o servidor Web IIS, que revela o código-fonte de uma página ASP, que pode conter senhas ou outras informações críticas.
5 - Como podem fazer alguns softwares de IDS, por exemplo, o Real Secure ( www.iss.net ), o BlackIce Sentry ( www.networkice.com ) etc. Esta característica somente é possível em tráfego TCP, pois trata-se de um protocolo orientado à conexão, diferente de protocolos como UDP e ICMP que não possibilitam o uso deste tipo de reação.
6 - Alguns IDS’s, principalmente comerciais, podem interagir com firewalls dinamicamente, bloqueando endereços ou portas, conforme configurado pelo administrador.
2.2 IPSec
O IPSec é uma extensão do protocolo IP que tem sido bastante empregado na implementação de soluções de VPN’s por oferecer confidencialidade (criptografia) e integridade (assinatura digital) dos pacotes IP processados. Em suas especificações, existem dois modos de funcionamento, o modo transporte (transport mode) e o modo túnel (tunnel mode), descritos na RFC2401 de Kent, Atkinson (1998) [2], que explicam:
"Cada protocolo [ESP e AH7] suporta dois modos de uso: o modo transporte e o modo túnel. No modo transporte, o protocolo provê proteção primariamente para os protocolos de camada superior; no modo túnel, os protocolos são empregados como um túnel de pacotes IP." 8
Podemos observar a diferença nas ilustrações abaixo:
Figura 4 - IPSec em Modo Transporte
Figura 5 - IPSec em Modo Túnel
Como se pode observar, o funcionamento no modo transporte é similar ao do SSL, protegendo ou autenticando apenas a porção de dados do pacote IP, entretanto ele pode encapsular outros protocolos de camada de transporte, como o UDP. Já no modo túnel, o pacote IP inteiro é criptografado, dessa forma nem o cabeçalho do pacote original pode ser verificado por um IDS.
Devemos ainda considerar as topologias em que VPN’s com IPSec podem ser implementadas, uma vez que esse tipo de tráfego é relevante para a correta implantação de sistemas de detecção de intrusos. O IPSec pode ser implementado máquina-a-máquina ou gateway-a-gateway. Este último modo é geralmente utilizado para interconexão de duas redes (com dois roteadores, por exemplo), mas não se restringe a ela. Podemos observar nas Figuras 6 e 7 as duas formas:
Figura 6 - IPSec máquina-a-máquina
Atente para o fato de que, no esquema representando pela figura acima, o monitoramento e análise não possível com IDS baseado em rede.
Figura 7 - IPSec gateway-a-gateway
No caso representado acima, a monitoração e análise são possíveis com IDS baseado em rede após os dispositivos IPSec.
De forma semelhante ao SSL, um sistema de IDS não terá como verificar possíveis ataques sobre uma conexão com IPSec. No modo transporte, pode-se verificar somente o cabeçalho dos pacotes; no modo túnel, nem o cabeçalho pode ser verificado. E como descrevem Kent, Atkinson (1998), na RFC2401: "Porque estes serviços são providos na camada IP, eles podem ser usados por qualquer protocolo de camada superior, ex.: TCP, UDP, ICMP, RIP, etc." 9 Assim, os ataques podem ser efetivados em qualquer protocolo sobre IP.
Pode-se questionar a validade do estudo de possíveis ataques feitos sobre IPSec, uma vez que as VPNs devem idealmente ter autenticação forte de seus usuários. Entretanto, muitas organizações têm criado VPNs para uso anônimo, sem autenticação; outras ainda possuem autenticação, mas esta pode ser roubada ou inferida; é possível, ainda, que um usuário legítimo faça um ataque, estes fatores fazem com que a autenticação não seja um fator limitante a um ataque.
Uma exceção ocorre quando é utilizada uma VPN gateway-a-gateway e um IDS é posicionado imediatamente após o gateway, onde o tráfego de saída da VPN ainda não foi processado e o tráfego entrante já foi restaurado. Nesta posição não há barreiras a uma verificação completa. Podemos vislumbrar algumas soluções para o uso de IDS’s com SSL e IPSec, por exemplo, a adição de agentes de IDS nas aplicações. Mais que clientes no host ou no sistema operacional, muitos destes serviços de criptografia (notadamente o SSL) fazem parte da própria aplicação (ex.: servidores Web, servidores IMAP, etc), tornando a implantação de módulos de IDS na aplicação necessária. Outra solução pode ser a utilização de front-end de descriptografia, o que torna a solução semelhante ao IPSec gateway-a-gateway 10 . Desta forma, é possível novamente a utilização de IDS baseados em rede para a monitoração.
7 - O protocolo AH (Authentication Header), como definido na RFC 2402, provê integridade sem conexão, autenticação da origem dos dados, e um serviço opcional para prevenção de reenvio de pacotes.
O protocolo ESP (Encapsulating Security Payload), como definido na RFC 2406, pode prover confidencialidade (criptografia) e limitado fluxo de tráfego confidencial. Ele pode também prover integridade sem conexão, autenticação da origem dos dados e um serviço de prevenção de reenvio de pacotes. A diferença entre os dois protocolos é que o ESP não atua no cabeçalho dos pacotes IP, só no campo de dados.
8 - Kent, Atkinson (1998) [2]: "Each protocol [ESP and AH] supports two modes of use: transport mode and tunnel mode. In transport mode the protocols provide protection primarily for upper layer protocols; in tunnel mode, the protocols are applied to tunneled IP packets."
9 - Kent, Atkinson (1998): "Because these services are provided at the IP layer, they can be used by any higher layer protocol, e.g., TCP, UDP, ICMP, RIP, etc.",
10 - Existem produtos que fazem o off-load de SSL. Eles podem ser posicionados antes ou junto a servidores Web e entregam o tráfego já decriptografado aos servidores, permitindo o uso de IDS em rede ou em host. O iSD-SSL Accelerator da Alteon e o Intel Netstructure 7110 são exemplos deles.
3. IDS em redes com switches
A implementação de IDSs em redes baseadas em switching, também conhecidas como redes comutadas, tem sido bastante discutida, uma vez que as soluções de IDS começaram a ser mais utilizadas simultaneamente à adoção em maior escala dos ambientes comutados.
Os switches permitem a comunicação direta, não compartilhada, entre dois dispositivos. Embora esta característica permita um ganho muito alto em desempenho, ela introduz dificuldades para a implementação de IDSs. Desta forma, algumas medidas são necessárias para eliminar esta limitação.
As sub-seções seguintes tratam das três formas de implementar IDS em redes comutadas.
3.1 Port SPAN
Esta parece ser uma das soluções mais utilizadas (ou a mais desejada) em switches, onde os dispositivos de rede (servidores, roteadores etc) estão conectados, por exemplo, a portas de 10 Mbps, e um IDS é conectado à porta SPAN 11 de 100 Mbps, recebendo todo o tráfego do switch. Desta maneira, obtém-se uma monitoração completa do tráfego, simulando um ambiente compartilhado.
Alguns switches 12 possuem características avançadas de monitoração, por exemplo, de VLANs específicas, portas em trunking 13 , distribuição da monitoração para várias portas de destino ou até de portas de outros switches da rede.
Neste caso, é possível monitorar com IDS’s o tráfego tratado por um switch inteiro ou apenas o tráfego pertencente a alguns subconjuntos específicos de sistemas, como as VLAN’s. É necessário observar, entretanto, que a utilização de uma porta SPAN pode causar Trata-se de é um detalhe que deve ser estudado para cada equipamento implantado numa solução de IDS.
11 - Analisador de porta comutada (do inglês, Switched Port ANalyzer).
12 - Por exemplo, a família de switch Catalyst 6000 da Cisco.
13 - Trunking é a característica de agregar duas ou mais conexões lógicas a fim de obter uma conexão lógica de alta velocidade. Exemplo disto é uma conexão lógica entre dois switches com a utilização de três conexões Fast Ethernet.
3.2 Splitting Wire/Optical Tap
Outra possibilidade é a utilização de um splitting tap que se define pela colocação de uma "escuta" para a monitoração do tráfego que está passando por ele.
Existem alguns dispositivos que podem ser posicionados entre um switch e um equipamento de rede e que, de forma não intrusiva, enviam uma cópia de todo o tráfego que passa por ele para um equipamento de monitoração, como um IDS. Na prática, para Ethernet e Fast Ethernet, um mero hub, como o mostrado na Figura 8, realizará este trabalho. Pode-se utilizar este tipo de recurso tanto para cabos de cobre (UTP), utilizados principalmente em redes Ethernet, como para fibras ópticas, onde se pode monitorar o tráfego ATM por exemplo. Neste caso, pode-se utilizar um dispositivo chamado de optical tap (ver Figura 9).
Figura 8 - Monitoração de pacotes em rede Ethernet, utilizando hubs ou wire tap
Figura 9 - Representação de um optical tap
3.3 Port Mirror
Em alguns switches 14 (principalmente os mais antigos), esta é a única opção para a monitoração e consiste no espelhamento do tráfego de uma única porta para uma outra, usada para o monitoramento, permitindo assim a coleta do tráfego para a monitoração de um único dispositivo por IDS. Este esuqema é semelhante a colocar um hub ou wire tap.
Esta opção torna a implementação de IDS, em uma rede puramente comutada, muito cara, embora existam produtos que permitem a monitoração de mais de um segmento simultaneamente, o que reduz o seu custo de implementação.
Provavelmente, uma abordagem baseada em sistema (também conhecida como host based ou híbrido) seja mais adequada e prática neste caso, tanto com relação ao custo, como também com relação ao esforço para a implantação neste tipo de cenário. Faz mais sentido a utilização de espelhamento de porta (também conhecido como port mirroring) em redes hierárquicas, como pode ser visto no esquema apresentado na Figura 10.
Figura 10 - Switch com port mirror numa estrutura hierárquica de switches sem port span
Percebe-se que as três abordagens apresentam dificuldades para a implementação, seja por característica do switch, seja pelo custo elevado etc. Por isso, a adoção de IDS em redes comutadas deve ser cuidadosamente estudada, levando em consideração os recursos e limitações dos equipamentos de rede.
Entretanto, podemos ver algumas alternativas no caso de nenhuma acima ser adequada ou executável.
Uma forma de resolver as dificuldades de implementação IDS em redes comutadas é utilizar IDS’s baseados nos sistemas finais (host based). Nesta abordagem, eliminaríamos os IDS’s de monitoração de tráfego de rede e distribuiríamos uma série de agentes nos sistemas finais, que irão monitorar as conexões e atividades dirigidas aos equipamentos alvo.
Existem duas variações de host based: detecção de anomalia/atividade suspeita e a detecção de ataque baseado em rede. Podemos encontrar produtos que agregam as duas abordagens ou, embora separados, podem conviver juntos, permitindo um maior controle do ambiente, uma vez que podemos monitorar o funcionamento da máquina do ponto de vista de sistema operacional (alteração em arquivos, registry, análise de log em tempo real, atividade de usuários etc.) e também do ponto de vista de rede, avaliando o tráfego destinado àquele equipamento.
Num plano mais amplo abordagem híbrida é a mais interessante e mais completa, entretanto poucos são os produtos que contemplam as duas de forma integrada, muitos só atuam em um dos pontos (tráfego ou anomalias).
14 - Como exemplo, temos o Xylan OmniSwitch (agora Alcatel), Intel® Express 500 e vários outros.
4. IDS em redes de alta velocidade
Este é um dos problemas recentemente surgidos na área de IDS e, de uma maneira geral, está diretamente ligado aos ambientes comutados mencionados acima. Assim como afirmam Sasha e Beetle [5] "Atualmente os sistemas de detecção de intrusos de rede baseados em análise passiva de protocolos pode meramente monitorar 100 Mb/s em Ethernet, e é um pouco duvidoso que eles possam ser habilitados a monitorar ATM, FDDI, etc." 15
A largura de banda tem crescido rapidamente – hoje temos Fast Ethernet, ATM, Gigabit Ethernet e, em breve, 10Gigabit Ethernet para as LANs. Para WANs, temos ATM, agregação de links seriais, SMDS etc. – as soluções de IDS não têm acompanhado esta evolução, seja sob plataformas Intel, SUN ou outras proprietárias como alguns sistemas dedicados (appliances 16 ).
Muitas pessoas defendem que hoje este não é um problema, pois ninguém possui um tráfego tão intenso como 1 Gb constantemente. Entretanto, a banda utilizada tem se tornado cada vez maior (tomemos como exemplo a grande procura e oferta das conexões xDSL, vídeo, mega-provedores de acesso etc.) e muitos tem buscado estruturas de backbone em altas velocidades, como ATM e Gigabit Ethernet, todos comutados, naturalmente.
Vários fabricantes de IDS possuem versões que suportam adaptadores de rede Gigabit Ethernet e alguns suportam também adaptadores ATM 17 . Entretanto, eles têm, em sua grande maioria, suportado somente o adaptador, não a taxa de transferência destes adaptadores, o que muitas vezes causa uma falsa impressão de poderem lidar com estas velocidades.
É possível, ainda, que a maioria dos IDS’s não possa suportar tráfegos até menores, uma vez que o tamanho dos pacotes a serem processados tem grande influência no desempenho dos mesmos. Pacotes pequenos causam uma maior carga na análise que deve ser realizada. Uma rede com tráfego médio de 100 Mbps e tamanho dos pacotes de 1500 bytes 18 irá gerar uma carga muito menor do que outra com os mesmos 100 Mbps e pacotes de 576 bytes 19 , por exemplo, pois teremos aproximadamente 3 vezes mais pacotes no segundo caso. Estes detalhes muitas vezes não são levados em conta no momento do projeto e da implantação ou da escolha de IDS’s nestas redes de alto tráfego, mas são fatores muitas vezes decisivos sobre a escolha de um ou outro produto, de uma ou outra tecnologia.
Nas redes ATM, será necessária uma maior adaptação dos IDS’s, já que a própria tecnologia (ATM) não possui padrões universais para a camada 2, onde temos: IPoATM, LANE, MPOA etc. Alguns permeiam também a camada 3. Dependendo de como o IDS for implementado, o que na grande maioria dos casos exigirá um optical tap será necessária a emulação da porção ATM, por exemplo de um LEC (Lan Emulation Client) quando usando LANE, uma vez que o IDS não terá comunicação com o LECS (Lan Emulation Configuration Server). Isto torna a implantação trabalhosa e provavelmente cara para o desenvolvedor.
Soluções têm sido buscadas para preencher esta lacuna nas tecnologias de IDS. Uma abordagem que pode ser aplicada é a separação de tráfego através de switches de balanceamento de tráfego para IDS’s. Os switches Toplayer 20 , por exemplo, podem dividir o tráfego de uma porta Gigabit-Ethernet em várias portas Fast-Ethernet, permitindo a distribuição do tráfego entre vários IDS’s (ver Figura 11), conforme é citado no manual do produto:
"Os grupos CC (Carbon Copy) são usados pelo AppSwitch para enviar (em ambas as direções) uma cópia de todos os pacotes em uma dada sessão para outra porta designada como membro de um grupo CC. Esta característica, conhecida como flow mirroring, é útil para ampliar a capacidade de sistemas dedicados na detecção de intrusos, ao permitir que múltiplos sistemas sejam dispostos em paralelo para balancear o tráfego da sessão." 21
Figura 11 - O tráfego entre os switches gigabit é distribuído entre vários IDSs
Esta abordagem requer um cuidado adicional do fabricante de IDS, uma vez que será necessário fazer uma consolidação dos vários eventos gerados pelos sensores, já que estes terão uma visão parcial do tráfego da rede. Assumindo que um IDS tenha mecanismos para detectar alguns tipos de ataques, - por exemplo varreduras de portas (port-scanning) distribuídos/coordenados como o descrito pelo projeto Shadow (1998): "[…] ataques e sondagens que têm sido recentemente observados, nos quais múltiplos atacantes estão claramente trabalhando juntos em direção a um objetivo comum, a partir de diferentes endereços IP. Muitas vezes estes endereços IP são também separados fisicamente, em diferentes países ou mesmo em diferentes continentes." 22 - num ambiente fragmentado como o proposto, dificilmente haverá um alerta sobre este evento, que provavelmente não será detectado. Um ataque distribuído/coordenado será diluído no ambiente de detectores e poderá facilmente passar desapercebido.
Sem dúvida, outras formas para contornar os problemas com as altas velocidades serão buscadas, com o aumento do poder de processamento dos equipamentos, notadamente equipamentos Intel e Sun Sparc, e a utilização de arquiteturas SMP 23 , que é pouco explorada até o momento. É preciso cuidar para não confundir os IDS’s que podem funcionar em arquitetura SMP, com aqueles que realmente aproveitam esses recursos. Paralelamente ao uso de SMP, a adoção de barramentos de I/O mais rápidos, como PCI 64bit, permitirá o uso mais efetivo de interfaces de rede como Gigabit, ATM (OC-12) etc.
Outra abordagem possível é a utilização de Target IDS 24 – monitoração de alguns elementos da rede que são do interesse do administrador (por exemplo, monitoração dos roteadores apenas) – implementado por alguns fabricantes e que pode ser também simulado através da utilização de recursos de filtragem do IDS ou através do direcionamento do tráfego por um switch de aplicação como o Toplayer. Pode-se reduzir a carga imposta ao IDS, direcionando para ele somente parte do tráfego, o que permite o tratamento adequado de um maior volume. Torna-se possível, por exemplo, separar a rede em duas partes e utilizar dois IDS’s - cada um monitorando uma destas partes.
A segregação de IDS por serviço, discutida na lista FOCUS-IDS, é uma variação da abordagem anterior. Ela é implementada de forma que um IDS é configurado, por exemplo, para somente analisar eventos relativos a e-mail, outro analisa somente eventos HTTP, e ainda outro analisa os demais eventos. Desta forma, também é possível minimizar o volume de tráfego de cada um destes IDS.
Como se pode observar, algumas destas soluções/proposições são dependentes dos fabricantes de IDS, outras são baseadas na arquitetura estabelecida para o ambiente. Entretanto, o ponto relevante é que já existem soluções para este problema que irá atingir principalmente os grandes provedores de conteúdo, comércio eletrônico etc.
15 - Sasha e Seetle (2000) [5]: "Current NIDS based upon passive protocol analysis can barely monitor 100 Mb/s Ethernet, and it is somewhat doubtful that they will be able to monitor ATM, FDDI, etc."
16 - Tipo de equipamento que, diferentemente dos PC’s que são de uso genérico, tem uma função específica e é otimizado para ela. Por exemplo: roteadores, switch, IDS’s, Web-Cache etc.
17 - Até o momento parece que somente a SecurityWizards, com o Dragon Sensor Appliance, possui interfaces ATM (OC-3) ( www.securitywizards.com )
18 - Valor padrão do MTU para interfaces Ethernet e PPP.
19 - Valor padrão do MTU para interfaces X.25
20 - O Appswitch 3500 da Toplayer ( www.toplayer.com ) possui duas interfaces Gigabit Ethernet e permite a distribuição de forma espelhada (usando a característica Carbon Copy do produto) do tráfego para portas Fast Ethernet.
21 - Do manual do TopLayer AppSwitch [6]: "CC (Carbon Copy) Groups are used by the AppSwitch to send (in both directions) a copy of all packets in a given session to another port designated as a member of the CC Group. This feature, known as flow mirroring, is useful in expanding the capacity of Intrusion Detection appliances by allowing multiple appliances to be placed in parallel to balance the session traffic."
22 - Shadow (1998) [3]: "[…] attacks and probes that have been recently observed in which multiple attackers are clearly working together toward a common goal from different IP addresses. Often these IP addresses are also physically separated, in different countries or even different continents."
23 - symmetric multiprocessing: sistema de multi-processamento simétrico.
24 - Target IDS foi discutido recentemente na lista FOCUS-IDS e pode ser pesquisado em http://www.securityfocus.com/focus/ids/menu.html?fm=9&action=fold .
5. Conclusão
Vimos aqui três desafios para a implantação de IDS: os sistemas de criptografia SSL e IPSec, as redes comutadas e as redes de alta-velocidade. Para poder implementar uma solução de IDS de forma completa nestes ambientes, será necessário um planejamento adequado, revisão das topologias das redes e eventualmente novos equipamentos, bem como – e talvez principalmente – um bom conhecimento do ambiente onde será implementado o IDS.
De uma maneira geral, parece que a abordagem baseada em host atende, de forma mais efetiva, todos os problemas apontados aqui. Resta agora aos fabricantes fornecerem soluções de monitoração baseada nesta estratégia, tanto do tráfego de rede para ele enviado, como das atividades realizadas internamente no sistema (monitoração de logs, de registry etc.) que possam fornecer o desempenho requerido. Esta é uma tendência que já pode ser observada pelos lançamentos de produtos por alguns fabricantes.
Estes desafios podem ser encontrados e abordados de forma isolada, mas parece que a existência de ambientes onde todos estejam presentes será cada vez mais crescente, o que faz com que uma solução única não seja adequada.
Comprar um IDS e instalá-lo não resolverá problema algum, seja qual for o tamanho da rede. Somente fará diferença ter um IDS quando for implementado de forma cuidadosa e sobretudo com um contínuo acompanhamento e monitoramento.
Agradecimentos
Agradecimentos especiais ao Sr. Gustavo Albuquerque, da Nortel Networks, pela correção e aprimoramento do artigo.
Referências bibliográficas
[1] FREIER, Alan O.; KARLTON, Philip; KOCHER, Paul C., ``The SSL Protocol - Version 3.0'', Netscape, 1996.
http://home.netscape.com/eng/ssl3/draft302.txt
[2] KENT S.; ATKINSON, R. Security Architecture for the Internet Protocol – RFC2401, The Internet Society, 1998.
http://www.ietf.cnri.reston.va.us/rfc/rfc2401.txt
[3] SHADOW Indications Technical Analysis Coordinated Attacks and Probes, Naval Surface Warfare Center Dahlgren Division, 14 de dezembro de 1998.
http://www.nswc.navy.mil/ISSEC/CID/co-ordinated_analysis.txt
[4] SASHA; LIFELINE. Distributed tools, Phrack magazine, 2000, v.10, n.56.
http://www.phrack.com/search.phtml?view&article=p56-12
[5] SASHA; BEETLE. A strict anomoly detection model for ids, Phrack magazine, 2000, v.10, n.56.
http://www.phrack.com/search.phtml?view&article=p56-12
[6] Toplayer AppSwitch™ User Guide, Toplayer, 2000.
www.toplayer.com
[7] DIERKS, T.; ALLEN, C. The TLS Protocol Version 1.0 – RFC2246. The Internet Society, 1999.
http://www.ietf.org/rfc/rfc2246.txt
[8] Introduction to SSL, Netscape Corporation, 1998.
http://developer.netscape.com/docs/manuals/security/sslin/index.htm
[9] Intel® Express Gigabit Switch - Users Guide, Intel Corporation, 1998.
http://www.intel.com/support/express/switches/1gb/es1000s.htm
[10] Intel® Express 500 Series Switches User Guide, Intel corporation, 1999.
ftp://download.intel.com/support/express/switches/500/550f_ug.pdf
[11] 3com Switch 4007 User Guides - Command Reference Guide, 3com, 2000.
http://support.3com.com/infodeli/tools/switches/4000/4007/13693/index.htm
[12] AppSwitch and Intrusion Detection Systems (IDS), Toplayer, 1999.
http://www.toplayer.com/application_notes/ids.shtml
[13] FOCUS-IDS Mailing-list: http://www.securityfocus.com/focus/ids/menu.html?fm=9&action=fold
[14] AppSwitchTM 3500 Family Datasheet, Toplayer, 2000.
http://www.toplayer.com/products/3500_datasheet.shtml
[15] Deploying IPSec, Cisco systems, 1999, http://www.cisco.com/warp/public/cc/so/neso/sqso/eqso/dplip_in.pdf
[16] OmniSwitch OmniSwitch/Router User Manual, Xylan.
NewsGeneration, um serviço oferecido pela RNP – Rede Nacional de Ensino e Pesquisa
Copyright © RNP, 1997 – 2004