Técnicas de evasão de atacantes

Seja coletando informações ou lançando um ataque, geralmente é esperado que o atacante evite a detecção. Embora alguns endereços IP e verificações de porta sejam instáveis e facilmente detectáveis, mais invasores astutos usam uma variedade de meios para ocultar sua atividade. Técnicas como o uso de exames FIN em vez de syn scans — que os invasores sabem que a maioria dos firewalls e programas de detecção de intrusões detectam — indicam uma evolução das técnicas de reconhecimento e exploração para detecção de evasão e realização com sucesso de suas tarefas.

Uma verificação fin envia segmentos de TCP com a bandeira FIN definida na tentativa de provocar uma resposta (um segmento de TCP com o conjunto de bandeira RST) e, assim, descobrir um host ativo ou uma porta ativa em um host. Os invasores podem usar essa abordagem em vez de realizar uma varredura de endereços com solicitações de eco do ICMP ou uma verificação de endereço com segmentos SYN, porque sabem que muitos firewalls normalmente se protegem contra as duas últimas abordagens, mas não necessariamente contra segmentos FIN. O uso de segmentos de TCP com o conjunto de bandeiras FIN pode escapar da detecção e, assim, ajudar os invasores a ter sucesso em seus esforços de reconhecimento.

Por padrão, o Junos OS verifica as bandeiras SYN no primeiro pacote de uma sessão e rejeita qualquer segmento de TCP com bandeiras não-SYN tentando iniciar uma sessão. Você pode deixar esse fluxo de pacote como está ou alterá-lo para que o Junos OS não aplique a verificação da bandeira SYN antes de criar uma sessão. A Figura 1 ilustra as sequências de fluxo de pacotes, tanto quando a verificação da bandeira SYN é ativada quanto quando ela é desativada.

Figura 1: Verificação da bandeira SYN

Quando o Junos OS com a verificação da bandeira SYN habilitada recebe um segmento de TCP não-SYN que não pertence a uma sessão existente, ele derruba o pacote. Por padrão, o Junos OS não envia um TCP RST para o host de origem ao receber o segmento não-SYN. Você pode configurar o dispositivo para enviar o TCP RST para o host de origem usando o set security zones security-zone trust tcp-rst comando. Se o bit de código do pacote inicial não SYN TCP for RST, o dispositivo não enviará um TCP-RST.

Não verificar a bandeira SYN nos primeiros pacotes oferece as seguintes vantagens:

• NSRP com roteamento assimétrico — Em uma configuração NSRP ativa/ativa em um ambiente de roteamento dinâmico, um host pode enviar o segmento TCP inicial com a bandeira SYN definida para um dispositivo (Dispositivo-A), mas o SYN/ACK pode ser roteado para o outro dispositivo no cluster (Dispositivo-B). Se esse roteamento assimétrico ocorrer após o Dispositivo A ter sincronizado sua sessão com o Dispositivo B, tudo está bem. Por outro lado, se a resposta SYN/ACK chegar ao Dispositivo B antes que o Dispositivo A sincroniza a sessão e a verificação do SYN estiver habilitada, o Dispositivo B rejeitará o SYN/ACK e a sessão não poderá ser estabelecida. Com a verificação do SYN desabilitada, o Dispositivo B aceita a resposta SYN/ACK — embora não haja nenhuma sessão existente à qual ela pertence — e cria uma nova entrada na tabela de sessão para ele.

• Sessões ininterruptas — Se você redefinir o dispositivo ou mesmo alterar um componente na seção central de uma política e a verificação SYN for habilitada, todas as sessões existentes ou as sessões às quais a mudança de política se aplica são interrompidas e devem ser reiniciadas. A desativação da verificação do SYN evita essas interrupções nos fluxos de tráfego da rede.

  Nota:

  Uma solução para este cenário é instalar o dispositivo com a verificação SYN desativada inicialmente. Em seguida, após algumas horas — quando as sessões estabelecidas estão sendo executadas pelo dispositivo — habilitar a verificação do SYN. A seção central de uma política contém os seguintes componentes principais: zonas de origem e destino, endereços de origem e destino, um ou mais serviços e uma ação.

No entanto, as vantagens anteriores exigem os seguintes sacrifícios de segurança:

• Buracos de reconhecimento — quando um segmento inicial de TCP com uma bandeira não SYN — como ACK, URG, RST, FIN — chega a uma porta fechada, muitos sistemas operacionais (Windows, por exemplo) respondem com um segmento de TCP que tem a bandeira RST definida. Se a porta estiver aberta, o destinatário não gera nenhuma resposta.

  Analisando essas respostas ou a falta dela, um coletor de inteligência pode realizar reconhecimento na rede protegida e também no conjunto de políticas do Junos OS. Se um segmento de TCP for enviado com um conjunto de bandeiras não-SYN e a política permitir que ele passe, o host de destino que recebe tal segmento pode deixá-lo cair e responder com um segmento de TCP que tem a bandeira RST definida. Tal resposta informa o autor da presença de um host ativo em um endereço específico e que o número de porta alvo está fechado. O coletor de inteligência também descobre que a política de firewall permite o acesso a esse número de porta naquele host.

  Ao habilitar a verificação da bandeira SYN, o Junos OS derruba segmentos de TCP sem uma bandeira SYN se eles não pertencessem a uma sessão existente. Ele não retorna um segmento TCP RST. Consequentemente, o scanner não recebe respostas, independentemente do conjunto de políticas ou se a porta está aberta ou fechada no host alvo.

• Inundações na tabela de sessão — se a verificação do SYN for desativada, um invasor pode ignorar o recurso de proteção contra enchentes Junos OS SYN inundando uma rede protegida com uma barragem de segmentos de TCP que têm bandeiras não-SYN definidas. Embora os hosts direcionados derrubem os pacotes — e possivelmente enviem segmentos de RST do TCP em resposta — tal inundação pode encher a tabela de sessão do dispositivo da Juniper Networks. Quando a tabela da sessão está cheia, o dispositivo não pode processar novas sessões para tráfego legítimo.

  Ao habilitar a verificação SYN e a proteção contra enchentes SYN, você pode impedir esse tipo de ataque. Verificar se a bandeira SYN está definida no pacote inicial em uma sessão força todas as novas sessões a começar com um segmento de TCP que tem o conjunto de bandeiraSYN. A proteção contra enchentes SYN limita o número de segmentos de SYN do TCP por segundo para que a tabela de sessão não fique sobrecarregada.

Se você não precisar de SYN verificando desabilitado, a Juniper Networks recomenda fortemente que ele seja habilitado (seu estado padrão para uma instalação inicial do Junos OS). Você pode habilitá-lo com o set flow tcp-syn-check comando. Com a verificação do SYN habilitada, o dispositivo rejeita segmentos de TCP com bandeiras não-SYN definidas a menos que pertençam a uma sessão estabelecida.

Um método de tentar obter acesso a uma área restrita da rede é inserir um endereço de origem falsa no cabeçalho do pacote para fazer com que o pacote pareça vir de uma fonte confiável. Essa técnica é chamada de spoofing de IP. O mecanismo para detectar spoofing de IP depende de entradas de tabela de roteamento. Por exemplo, se um pacote com endereço IP de origem 10.1.1.6 chegar ao ge-0/0/1, mas o Junos OS tem uma rota para 10.1.1.0/24 através do ge-0/0/0, uma verificação para spoofing de IP descobre que esse endereço chegou a uma interface inválida conforme definido na tabela de rota. Um pacote válido a partir de 10.1.1.6 só pode chegar por ge-0/0/0, não ge-0/0/1. Portanto, o Junos OS conclui que o pacote tem um endereço IP de origem falsificado e o descarta. O Junos OS detecta e derruba pacotes falsificados IPv4 e IPv6.

Este exemplo mostra como configurar uma tela para bloquear ataques falsos de IP.

Em um ataque de spoofing de IP, o invasor ganha acesso a uma área restrita da rede e insere um endereço de origem falsa no cabeçalho do pacote para fazer o pacote parecer vir de uma fonte confiável. A spoofing de IP é mais usada em ataques de negação de serviço (DoS). Quando os firewalls da Série SRX estão operando em modo transparente, o mecanismo de verificação de spoofs ip faz uso de entradas de livros de endereços. Os livros de endereços só existem no Mecanismo de Roteamento. A spoofing de IP no modo transparente de Camada 2 é realizada no Mecanismo de encaminhamento de pacotes. As informações da lista de endereços não podem ser obtidas no Mecanismo de Roteamento cada vez que um pacote é recebido pelo Mecanismo de encaminhamento de pacotes. Portanto, os livros de endereços anexados às zonas de Camada 2 devem ser empurrados para o Mecanismo de encaminhamento de pacotes.

Quando um pacote é recebido pelo Mecanismo de encaminhamento de pacotes, o endereço IP de origem do pacote é verificado para determinar se ele está na lista de endereços da zona de entrada. Se o endereço IP de origem do pacote estiver na lista de endereços da zona de entrada, esse endereço IP será permitido na interface e o tráfego será aprovado.

Se o endereço IP de origem não estiver presente na lista de endereços da zona de entrada, mas exista em outras zonas, então o endereço IP é considerado um IP falsificado. Dessa forma, ações como quedas e registro podem ser tomadas dependendo da configuração da tela (alarme sem queda).

Se o endereço IP de origem de um pacote não estiver presente na lista de endereços da zona de entrada ou em outras zonas, então você não pode determinar se o IP é falsificado ou não. Nesses casos, o pacote é passado.

O Junos OS leva em conta as seguintes condições de correspondência enquanto pesquisa endereços IP de origem na lista de endereços:

• Host-match— A correspondência de endereço IP encontrada na lista de endereços é um endereço sem prefixo.

• Prefix-match— A correspondência de endereço IP encontrada na lista de endereços é um endereço com um prefixo.

• Any-match— A correspondência de endereço IP encontrada na lista de endereços é "qualquer", "any-IPv4" ou "any-IPv6".

• No-match— Nenhuma correspondência de endereço IP é encontrada.

O roteamento de origem foi projetado para permitir que os usuários na fonte de uma transmissão de pacotes IP especifiquem os endereços IP dos dispositivos (também chamados de "hops" ) ao longo do caminho que eles querem que um pacote IP leve em seu caminho até seu destino. A intenção original das opções de rota de origem IP era fornecer ferramentas de controle de roteamento para ajudar na análise de diagnóstico. Se, por exemplo, a transmissão de um pacote para um determinado destino for atendida com sucesso irregular, você pode primeiro usar a rota de registro ou a opção de IP do temporizantes para descobrir os endereços dos dispositivos ao longo do caminho ou caminhos que o pacote toma. Em seguida, você pode usar a opção de rota de origem frouxa ou rigorosa para direcionar o tráfego por um caminho específico, usando os endereços que você aprendeu com os resultados que a rota de registro ou as opções de data e hora produziram. Ao alterar os endereços dos dispositivos para alterar o caminho e enviar vários pacotes por diferentes caminhos, você pode notar mudanças que melhoram ou reduzem a taxa de sucesso. Através da análise e do processo de eliminação, você pode ser capaz de deduzir onde está o problema. Veja a Figura 2.

Figura 2: Roteamento de fonte IP

Embora os usos de opções de rota de origem IP fossem originalmente benignos, os invasores aprenderam a colocá-los em usos mais desonestos. Eles podem usar opções de rota de origem IP para ocultar seu endereço verdadeiro e acessar áreas restritas de uma rede especificando um caminho diferente. Por exemplo, mostrando como um atacante pode usar ambas as fraudes, considere o cenário a seguir ilustrado na Figura 3.

Figura 3: Opção de rota de origem IP frouxa para engano

O Junos OS só permite o tráfego 2.2.2.0/24 se ele passar pela ethernet1, uma interface vinculada a zone_external. Os dispositivos 3 e 4 aplicam controles de acesso, mas os dispositivos 1 e 2 não. Além disso, o dispositivo 2 não verifica se há spoofing de IP. O invasor falsifica o endereço de origem e, usando a opção de rota de origem frouxa, direciona o pacote através do dispositivo 2 para a rede 2.2.2.0/24 e a partir daí o dispositivo 1. O dispositivo 1 o encaminha para o dispositivo 3, que o encaminha para o dispositivo da Juniper Networks. Como o pacote veio da sub-rede 2.2.2.0/24 e tem um endereço fonte dessa sub-rede, parece ser válido. No entanto, um remanescente da chicanery anterior permanece: a opção de rota de origem frouxa. Neste exemplo, você permitiu negar a opção de tela de rota de origem IP para zone_external. Quando o pacote chega à ethernet3, o dispositivo o rejeita.

Você pode permitir que o dispositivo bloqueie quaisquer pacotes com opções de rota de origem frouxas ou rigorosas, definir ou detectar tais pacotes e, em seguida, registrar o evento na lista de contadores para a interface de entrada. As opções de tela são as seguintes:

• Negue a opção de rota de origem IP — habilite essa opção de bloquear todo o tráfego IP que emprega a opção de rota de origem frouxa ou rigorosa. Opções de rota de origem podem permitir que um invasor insira uma rede com um endereço IP falso.

• Detecte a opção de rota de origem frouxa ip — o dispositivo detecta pacotes onde a opção IP é 3 (roteamento de fonte solta) e registra o evento na lista de contadores de tela para a interface de entrada. Essa opção especifica uma lista parcial de rotas para um pacote realizar sua jornada de origem a destino. O pacote deve prosseguir na ordem dos endereços especificados, mas ele pode passar por outros dispositivos entre os especificados.

• Detecte a opção de rota de origem rigorosa de IP — o dispositivo detecta pacotes onde a opção de IP é 9 (Roteamento rigoroso de fonte) e registra o evento na lista de contadores de tela para a interface de entrada. Essa opção especifica a lista de rotas completa para um pacote realizar sua jornada de origem ao destino. O último endereço da lista substitui o endereço no campo de destino. Atualmente, essa opção de tela é aplicável apenas ao IPv4.

Este exemplo mostra como bloquear pacotes com uma opção de rota de origem frouxa ou rigorosa.

Este exemplo mostra como detectar pacotes com uma opção de rota de origem frouxa ou rigorosa.