Melhorando a Segurança com Filtros de Pacote 

Por: Verdade @bsoluta
 
  1. Introdução
  2. Visão geral sobre filtros
  3. TCP SYN (DoS)
  4. UDP Portas de Diagnóstico (DoS)
  5. Configurando TCP Intercept (Prevenção contra DoS)
  6. TCP Loopback (DoS)
  7. Smurfing (DoS)
1 - Introdução
Sabemos que existem várias formas de ataques, o estabelecimento de filtros de pacotes pode ser uma boa medida para ajudar na proteção de servidores internos de acessos indevidos. O uso de filtros é recomendado em situações simples e como complemento de outros mecanismos de segurança, que proporcionem maior flexibilidade e controle. Os filtros de pacotes são muito úteis mas não devem ser a única forma de defesa. 

Este artigo trata em especial da implementação de filtros em roteadores CISCO, mas acredito que a idéia básica pode ser útil em outros tipos de roteadores (bay network, 3Com, etc). 

Após a aplicação dos filtros é recomendável que o administrador da rede fique atento ao desempenho da mesma que pode sofre um pequeno impacto levando-se em conta alguns fatores como volume do tráfego, número de filtros entre outros; o bom senso deve prevalecer para achar a melhor medida que garanta um certo nível de segurança e bom desempenho da rede. 

2 - Visão geral sobre filtros
 A filtragem de pacotes consiste na análise dos pacotes, conforme o conteúdo de determinados campos que fazem parte do cabeçalho do pacote, este análise permite a passagem ou descarte do pacote conforme os filtros. 

O filtro é composto de várias regras que levam em conta principalmente:

  • Endereço IP de origem e destino - Todo pacote possui um endereço de origem e um endereço de destino. O endereço de origem é o da máquina (interface) que estabeleceu a comunicação, enquanto o endereço de destino corresponde à máquina de destino final. Quando o pacote trafega pela rede estes endereços não são alterados. A filtragem por endereço pode ser feita pela origem e/ou destino, no endereço completo (host) ou em parte dele (net ou bloco).
  • Protocolo - As regras podem ser montadas para bloquear totalmente um determinado protocolo (UDP, TCP, ICMP ou RCP) ou especificar um serviço, que assume características diferentes dependendo da combinação protocolo/porta.
  • Portas de origem e destino - O acesso a serviços Internet é feito com base nos números de portas. Assim como os endereços IP, as portas podem ser modificadas no caso de um ataque para tentar contornar os filtros.
  • Outros campos dos cabeçalhos TCP/IP como Type-of-service (TOS) e Flags (bit ACK),  podem ser utilizados para as regras de filtragem.
Abordagens para aplicação de filtros:
  • Bloquear alguns acessos e permitir todos os demais - este tipo de regra é simples de implementar, mas pode dar uma falsa sensação de segurança, já que o mesmo serviço pode ser ativado em uma porta completamente diferente.
  • Permitir alguns acesso e bloquear todos os demais - este tipo de filtro possui uma implementação mais complexa e exige um maior entendimento do funcionamento dos protocolos, mas oferece um maior nível de segurança.
  • Sentido da aplicação do filtro - O sentido da aplicação dos filtros é fundamental para seu funcionamento, e pode ser aplicados na entrada da interface (inbound) ou saída (outbound). Dependendo do sentido, os endereços IP e as portas mudam completamente.
Filtros em roteadores CISCO
  • A implementação de filtros de pacotes em roteadores CISCO é feita por meio de listas de acesso (access-list). Existem dois tipos de access-list:
  1. standard: onde somente o endereço de origem é informado, a identificação destas listas variam de 1 a 99. - access-list # {deny/permit} origem máscara
  2. extended: onde o controle é feito levando-se em consideração endereços, portas com algumas opções adicionais, a identificação destas listas variam de 100 a 199. - access-list # {deny/permit} protocolo origem máscara porta destino máscara porta established log
3 - TCP SYN (DoS) 
  • Visão geral - O "atacante" envia um grande número de conexões  que não podem ser completadas. Isso causa um enfileiramento das conexões e consequentemente negação de serviços para os os usuários legítimos.
    Descrição do Problema
    • Quando uma conexão normal de TCP é iniciada, o hosts destino recebe um pacote SYN (synchronize/start) do hosts de origem e envia de volta um pacote SYN ACK (synchronize acknowledge). O hosts de destino aguarda por uma pacote ACK (acknowledge) em resposta ao pacote SYN ACK enviado, somente após o recebimento do pacote ACK a conexão é estabelecida. Isso é referenciado como TCP three-way handshake.
    • Enquanto o destino aguarda pelo pacote ACK começa a formação de uma fila de pacotes :) que aguardam pelos pacotes SYN ACK para completarem a conexão. Geralmente o pacote ACK chega após alguns milesegundos do envio do pacote SYN ACK. 
    • O ataque TCP SYN baseia-se nesta característica do protocolo, o host de origem geral uma série de pacotes com origem randomica e envia para o host vitima. O host vitima envia pacotes SYC ACK para os hosts de origem (gerados randomicamente) e adiciona uma entrada na fila de conexões. Note que se um pacote SYN ACK é enviado para um host incorreto ou inexistente, a ultima parte do tree-way handshake nunca será completada e a entrada fica na fila de conexões até expirar por timeout, tipicamente um minuto. Com a geração de centenas de pacotes randomicos é possível lotar a fila de espera de conexões do host destino iniciando um processo de negação dos serviços legítimos (e-mail, ftp ou WWW).
    • O rastreamento do originador dos pacotes não é um processo muito fácil, uma vez que os pacotes de origem são gerados de forma randomica ou seja são forjados.
    • A manifetação externa do problema inclui a impossibilidade de pegar e-mail, impossibilidade de conexões a serviços WWW ou FTP ou um grande número de conexões no seu  host com o status SYN_RCVD.
  • Defendendo-se do ataque

  •  
    • Hosts protegidos por firewall - O ataque TCP SYN é caracterizado pelo envio de um grande número de pacotes SYN com IP de origem randomicos. Qualquer host que esteja atraz de um firewall que bloqueia na entrada (inbound) pacotes SYN estão protegidos desta modalidade de ataque e nnbhuma providência é requerida.
    • Hosts que oferecem serviços públicos (servidor de e-mail, servidor web público) - Prevenir o ataque TCP SYN em hosts que estão atrás de um firewall é relativamente simples uma vez que você pode implementar regras que limitam o acesso (inbound) a um determinado range de IP. Mas no caso de servidores web públicos ou servidores de e-mail, não há como determinar quais endereços de origem são amigos ou inimigos. Então não existe uma forma limpa de proteçãao contra IP gerado randomicamente. Algumas medidas paliativas podem ser tomadas:

    •  
      • Aumente o tamanho da fila de conexões (SYN ACK queue).
      • Diminua o tempo de timeout do three-way handshake.
      • Adquira um programa que detecta o padrão do ataque e contorne o problema.
    • Você deve entrar contato com o fornecedor do seu equipamento para ver se ele desenvolveu algum patch para o ataque TCP SYN.
    • Note que filtrar o endereço IP torna-se ineficiente, pois o "atacante" pode variar o IP de origem, e o endereço pode ser ou não um endereço válido.
  • Prevenindo contra endereços inválidos - note que o mecanismo primário deste tipo de ataque (DoS) é a geração de trafego com origem randomica, uma medida seria a filtragem do tráfego para a Internet. O conceito básico é impedir que pacotes com endereços inválidos entrem na Internet. Isto não impede  um ataque de DoS a sua rede, mas ajuda a prevenir que alguém de dentro da sua rede tente atacar usando endereços inválidos.E consequentemente torna sua rede menos atrativa para a montagem de uma base para este tipo de ataque. 

  •  
    • Prevenindo-se contra o envio de endereços inválidos - você pode colocar filtros que permitam somente a saída de endereços válidos com destino a Internet. Por exemplo, se sua sua rede for 172.16.0.0, e seu roteador conecta-se com seu ISP usando a interface serial 0/1, você pode aplicar a seguinte lista de acesso:

    •  
      • access-list  111  permit  ip  172.16.0.0   0.0.255.255   any
      • access-list  111  deny  ip  any  any  log
      • interface serial 0/1
      • ip access-group 111 out
    • Note que a última regra (access-list) bloquei o envio de endereços inválidos para a Internet além de registra a ação em arquivos de log (sobre como registar a ação em arquivos de log utilizando o syslog do UNIX vou escrever/traduzir outro artigo). A última regra não é fundamental, mas pode ajudar na localização da origem no caso de um ataque.
    • Prevenindo-se contra a entrada de endereços inválidos - Para ISP que provêem serviço final de redes para clientes é  fortemente recomendável a validação dos pacotes de entrada para os clientes através da utilização de filtos na entrada (inbound) do seu roteador principal. Por  exemplo, se seu cliente tem um rang de IP conectados ao seu roteador via interface serial 1/0, você pode criar a seguinte regra: ( Os números de rede são 192.168.0.0 a 192.168.15.0 e 172.18.0.0 )
       
      • access-list  111  permit  ip  192.168.0.0   0.0.15.255   any
      • access-list  111  permit  ip  172.18.0.0   0.0.255.255   any
      • access-list  111  deny  ip  any  any  log
      • interface serial 1/0
      • ip access-group 111 in

      •  
    • Note que a última regra (access-list) bloquei a entrada de endereços inválidos vindos da Internet além de registra a ação em arquivos de log (sobre como registar a ação em arquivos de log utilizando o syslog do UNIX vou escrever/traduzir outro artigo). A última regra não é fundamental, mas pode ajudar na localização da origem no caso de um ataque. 
    • Prevenindo-se contra a entrada de endereços inválidos RFC 1918 - Outra regra que pode ser aplica é a prevenção contra a entrada de endereços das classes privadas RFC 1918 (vale apena ler, é pequena são somente dez folhas), vamos direto as regras:

    •  
      • access-list  111  deny ip  10.0.0.0    255.255.255.255  any
      • access-list  111  deny ip  172.16.0.0     0.15.255.255  any
      • access-list  111  deny ip  192.168.0.0     0.0.255.255  any
      • interface serial 0
      • ip access-group 111 in
4 - UDP Portas de Diagnóstico (DoS)
  • Visão geral - O "atacante" transmite um grande volume de requisições UDP  para o serviço de diagnósticos do roteador, que consome todos os recursos da CPU tentando atender as requisições, este tipo de ataque também é conhecido como ataque "pepsi".
    Descrição do Problema
    • Por default, o roteador CISCO possui uma série de portas de diagnóstico que permitem alguns serviços UDP e TCP inclusive echo, chargen e discard. Quando um host  conecta-se a estas portas, uma pequena porção da CPU e comsumida para servir a requisição .
    • Se um "atacante" enviar um grande volume de requisições com endereço de IP origem gerado randomicamente, é possível que o roteador CISCO sofra uma sobre carga e fique lento ou até mesmo falhar. 
    • A manifestação externa para este problema reflete-se na tabela de processo que ficará cheia de mensagens de erro (%SYS-3 NOPROC) ou uma super utilização da CPU. O comando show process listará vários processo com o mesmo nome, por exmplo, UDP Echo.
  • Defendendo-se do ataque

  •  
    • Desabilitando as portas UDP de diagnósticos - Qualquer dispositivo de rede que possuem  serviços de diagnóstico UDP e TCP podem ser protegidos por um firewall ou desativando os serviços. Em roteadores CISCO, isto pode ser feito usando-se os comandos globais de configuração:
       
      • no  service  udp-small-servers
      • no  service  tcp-small-servers
    • Estes comandos estão disponíveis nas seguintes versções do Cisco IOS: 10.2(9), 10.3(7), 11.0(2) e em todas as verções posteriores a estas.
  • Descrição dos small servers - Os small servers são servidores (no UNIX são daemons) que rodam no roteador que são uteis para diagnósticos. E por default eles estão ativos. Os comandos para TCP e UDP small servers são:

  •  
    • service  udp-small-servers
    • service  tcp-small-servers
  • Você pode desabilitar este serviços usando a sintaxe no antes do comando, veja acima.
  • Os small servers TCP são: 

  •  
    • Echo: Replica tudo que você digita. Para ver em funcionamento entre com o seguinte comando: telnet x.x.x.x echo .
    • Chargem: Gera um conjunto de caracteres ASCII. Para ver em funcionamento entre com o seguinte comando: telnet x.x.x.x chargem . 
    • Discard: Joga fora tudo o que você digita. Para ver em funcionamento entre com o seguinte comando: telnet x.x.x.x discard .
    • Daytime: Retorna a data e hora do sistema, se estiver correta. Ela está correta se você estiver rodando NTP ou tiver ajustado manualmente a data e hora. Para ver em funcionamento entre com o seguinte comando: telnet x.x.x.x daytime . 
  • Os small servers UDP são: 

  •  
    • Echo: Mostra o payload do datagrama que você enviar.
    • Discard: Silenciosamente descarta o datagrama que você enviar.
    • Chargem: Descarta o datagrama que você enviar e responde com uma string de 72 caracteres ASCII os caracteres terminam com CR+LF.
5 - Configurando TCP Intercept (Prevenção contra DoS) 
 

6 - TCP Loopback (DoS) 
 

7 - Smurfing (DoS) 
 
 
 
 

Referências

  • http://www.rnp.br/newsgen/9803/filtros.shtml (Autor: Carlos A. Campana Pinheiro)
  • http://www.cisco.com

<=

http://www.absoluta.org      ---oOo---      verdade@absoluta.org

Copyright © 1998 - 1999  Verdade @bsoluta