IDS no MS-DPC

Configuração da direção de correspondência para regras de IDS

Cada regra deve incluir uma match-direction instrução que especifique se a correspondência é aplicada no lado de entrada ou saída da interface. Para configurar onde a correspondência é aplicada, inclua a match-direction (input | input-output | output) declaração no nível da [edit services ids rule rule-name] hierarquia:

Se você configurar match-direction input-outputa criação de regras bidirecionais .

A direção da correspondência é usada em relação ao fluxo de tráfego pelo AS ou pelo PIC multisserviços. Quando um pacote é enviado ao PIC, as informações de direção são transportadas junto com ele.

Com um conjunto de serviços de interface, a direção do pacote é determinada pelo fato de um pacote estar entrando ou saindo da interface na qual o conjunto de serviços é aplicado.

Com um conjunto de serviços next-hop, a direção do pacote é determinada pela interface usada para rotear o pacote para o AS ou o PIC multisserviços. Se a interface interna for usada para rotear o pacote, a direção do pacote será a entrada. Se a interface externa for usada para direcionar o pacote para o PIC, a direção do pacote será a saída. Para obter mais informações sobre interfaces internas e externas, consulte Configurando conjuntos de serviços a serem aplicados a interfaces de serviços.

No PIC de AS ou Multisserviços, uma pesquisa de fluxo é executada. Se nenhum fluxo for encontrado, o processamento da regra será executado. Todas as regras no conjunto de serviços são consideradas. Durante o processamento da regra, a direção do pacote é comparada com as direções da regra. Somente as regras com informações de direção que correspondem à direção do pacote são consideradas.

Configuração de condições de correspondência em regras de IDS

Para configurar condições de correspondência de IDS, inclua a from declaração no nível da [edit services ids rule rule-name term term-name] hierarquia:

Se você omitir a from instrução, o software aceitará todos os eventos e os colocará no cache IDS para processamento.

O endereço de origem e o endereço de destino podem ser IPv4 ou IPv6. Você pode usar o endereço de destino, um intervalo de endereços de destino, um endereço de origem ou um intervalo de endereços de origem como uma condição de correspondência, da mesma forma que configuraria um filtro de firewall; para obter mais informações, consulte o Guia do usuário de políticas de roteamento, filtros de firewall e policiais de tráfego.

Como alternativa, você pode especificar uma lista de prefixos de origem ou destino incluindo a prefix-list instrução no nível da [edit policy-options] hierarquia e, em seguida, incluindo a destination-prefix-list instrução or source-prefix-list na regra IDS. Para obter um exemplo, consulte Exemplos: Configuração de regras de Firewall com estado.

Você também pode incluir definições de protocolo de aplicativo que você configurou no nível de [edit applications] hierarquia; para obter mais informações, consulte Configurando propriedades do aplicativo.

• Para aplicar uma ou mais definições específicas de protocolo de aplicativo, inclua a applications instrução no nível de [edit services ids rule rule-name term term-name from] hierarquia.

• Para aplicar um ou mais conjuntos de definições de protocolo de aplicativo que você definiu, inclua a application-sets instrução no nível de [edit services ids rule rule-name term term-name from] hierarquia.

  Observação:

  Se você incluir uma das declarações que especifica protocolos de aplicação, o roteador deriva informações de porta e protocolo da configuração correspondente no [edit applications] nível de hierarquia; você não pode especificar essas propriedades como condições de correspondência.

Se ocorrer uma correspondência em um aplicativo, o protocolo de aplicativo será exibido separadamente na saída do show services ids comando. Para obter mais informações, consulte o CLI Explorer.

Configuração de ações em regras de IDS

Para configurar ações do IDS, inclua a then declaração no nível da [edit services ids rule rule-name term term-name] hierarquia:

Você pode configurar as seguintes ações possíveis:

• aggregation— O roteador agrega o tráfego rotulado com os prefixos de origem ou destino especificados antes de passar os eventos para o processamento de IDS. Isso é útil se você quiser examinar todo o tráfego conectado a um host de origem ou destino específico. Para coletar tráfego com algum outro marcador, como um aplicativo ou porta específico, configure esse valor nas condições de correspondência.

  Para configurar prefixos de agregação, inclua a aggregation declaração no nível da [edit services ids rule rule-name term term-name then] hierarquia e especifique valores para source-prefix, destination-prefix source-prefix-ipv6ou destination-prefix-ipv6:

  O valor de source-prefix e destination-prefix deve ser um número inteiro entre 1 e 32. O valor de source-prefix-ipv6 e destination-prefix-ipv6 deve ser um número inteiro entre 1 e 128.

• (force-entry | ignore-entry)—force-entry fornece um local permanente nos caches IDS para eventos subsequentes após um evento ser registrado. Por padrão, o software IDS não registra informações sobre pacotes "bons" que não exibem comportamento suspeito. Você pode usar a instrução para registrar todo o tráfego de um host suspeito, mesmo o force-entry tráfego que de outra forma não seria contado.

  ignore-entry garante que todos os eventos IDS sejam ignorados. Você pode usar essa declaração para desconsiderar todo o tráfego de um host confiável, incluindo quaisquer anomalias temporárias que, de outra forma, o IDS contaria como eventos.

  Para configurar um comportamento de entrada diferente do padrão, inclua a force-entry instrução or ignore-entry no nível da [edit services ids rule rule-name term term-name then] hierarquia:

• logging— O evento é registrado no arquivo de log do sistema.

  Para configurar o registro, inclua a logging declaração no nível da [edit services ids rule rule-name term term-name then] hierarquia:

  Opcionalmente, você pode incluir uma taxa de limite para disparar a geração de mensagens de log do sistema. A taxa de limite é especificada em eventos por segundo. Os logs do IDS são gerados uma vez a cada 60 segundos para cada anomalia relatada. Os logs são gerados enquanto os eventos continuam.

• session-limit— O roteador limita sessões abertas quando o limite especificado é atingido.

  Para configurar um limite, inclua a session-limit declaração no nível da [edit services ids rule rule-name term term-name then] hierarquia:

  Você configura os limites para limitação de fluxo com base na direção do tráfego:

  • Para limitar o número de sessões de saída de um host interno ou sub-rede, configure a by-source declaração.

  • Para limitar o número de sessões entre um par de endereços IP, sub-redes ou aplicativos, configure a by-pair declaração.

  • Para limitar o número de sessões de entrada a um endereço IP público externo ou sub-rede, configure a by-destination declaração.

  Para cada direção, você pode configurar os seguintes valores limite:

  • hold-time seconds— Quando a medição ou rate packets atingir o valor limite, interrompa todos os novos fluxos pelo número especificado de segundos. Uma vez hold-time em vigor, o tráfego é bloqueado pelo tempo especificado, mesmo que a taxa diminua abaixo do limite especificado. Por padrão, hold-time tem um valor de 0; o intervalo é de 0 a 60 segundos.

  • maximum number— Número máximo de sessões abertas por endereço IP ou sub-rede por aplicativo. O intervalo é de 1 a 32.767.

  • packets number— Número máximo de pacotes por segundo (pps) por endereço IP ou sub-rede por aplicativo. O intervalo é de 4 a 2.147.483.647.

  • rate number— Número máximo de sessões por segundo por endereço IP ou sub-rede por aplicativo. O intervalo é de 4 a 32.767.

    Se você incluir mais de um endereço de origem nas condições de correspondência configuradas no nível da hierarquia, os [edit services ids rule rule-name term term-name from] limites serão aplicados a cada endereço de origem de forma independente. Por exemplo, a configuração a seguir permite 20 conexões de cada endereço de origem (10.1.1.1 e 10.1.1.2), não 20 conexões no total. A mesma lógica se aplica às condições e applications destination-address correspondem.

    Observação:

    Os limites de IDS são aplicados a pacotes que são aceitos por regras de firewall stateful. Eles não são aplicados a pacotes descartados ou rejeitados por regras de firewall stateful. Por exemplo, se o firewall stateful aceitar 75 por cento do tráfego de entrada e os 25 por cento restantes forem rejeitados ou descartados, o limite de IDS se aplicará apenas a 75 por cento do tráfego.

• syn-cookie— O roteador ativa mecanismos defensivos SYN-cookie.

  Para configurar valores de cookie SYN, inclua a syn-cookie declaração no nível da [edit services ids rule rule-name term term-name then] hierarquia:

  Se você habilitar defesas de cookie SYN, deverá incluir uma taxa de limite para disparar a atividade de cookie SYN e um valor de tamanho máximo de segmento (MSS) do Protocolo de Controle de Transmissão (TCP) para vinculação atrasada de TCP. A taxa limite é especificada em ataques SYN por segundo. Por padrão, o valor TCP MSS é 1500; o intervalo é de 128 a 8192.

  Tratamento de ataques de inundação SYN e proteção contra cookies SYN

  O principal objetivo de um ataque de inundação SYN é consumir todas as novas conexões de rede em um local e, assim, impedir que usuários autorizados e legítimos consigam se conectar aos recursos da rede. O pacote SYN (sincronizar número de sequência) é a primeira solicitação de conexão enviada a um sistema. O pacote SYN contém um ID ao qual o receptor é obrigado a responder. Se o pacote contiver uma ID ilegal, o sistema receptor receberá uma confirmação de conexão quando responder ao iniciador de conexão pretendido. Eventualmente, essa conexão semiaberta atinge o tempo limite e o canal de entrada no receptor fica disponível novamente para lidar normalmente com outra solicitação. Um ataque de inundação SYN envia tantas dessas solicitações que todas as conexões de entrada são continuamente amarradas aguardando confirmações que nunca são recebidas. Essa condição faz com que o servidor fique indisponível para usuários legais (exceto nos casos em que uma sessão de usuário é estabelecida exatamente no momento em que uma das conexões vinculadas expira). Um ataque de inundação SYN é um ataque sem conexão. Ele não requer endereços IP de origem reais e, por usar endereços IP ou de porta de destino legítimos, é praticamente impossível distinguir de pacotes legítimos. Portanto, é muito difícil evitar esse tipo de ataque usando apenas filtros ou regras de firewall stateful. Basicamente, existem apenas três métodos para se proteger desse tipo de ataque:

  • Intercept (ligação atrasada) — O firewall intercepta solicitações de sincronização TCP de entrada e estabelece uma conexão com o cliente em nome do servidor e com o servidor em nome do cliente. Se ambas as conexões forem bem-sucedidas, o firewall mesclará as duas conexões de forma transparente. O firewall geralmente tem tempos limite agressivos para evitar que seus próprios recursos sejam consumidos por um ataque SYN. Esta é a solução mais intensiva em termos de requisitos de processamento e memória.

  • Assistir (defesa SYN) — O firewall observa passivamente conexões semiabertas e fecha ativamente as conexões no servidor após um período de tempo configurável.

  • Cookie SYN — cookies SYN são opções específicas para o número de sequência TCP inicial escolhido pelo servidor TCP. Um host que solicita uma conexão deve responder com o cookie para se conectar a um soquete TCP aberto enquanto uma inundação SYN foi detectada como em andamento pelo IDS.

  Os roteadores da Juniper Networks oferecem suporte à combinação de mecanismos de firewall stateful e IDS para oferecer suporte aos métodos de cookie and watch (defesa SYN). A chave para o ataque de inundação SYN é o preenchimento da fila SYN da vítima ou do elemento de rede atacado. O método de defesa contra cookies SYN permite que a vítima continue aceitando solicitações de conexão quando a fila SYN estiver cheia ou, no caso de aplicativos de firewall ou IDS, quando um determinado limite for atingido. Depois que o limite é atingido, um cookie criptográfico (um número de 32 bits) é criado a partir de informações no segmento SYN e o segmento SYN é descartado. O cookie é usado como o número de sequência inicial no SYN-ACK enviado ao cliente. O cookie (mais um) é retornado ao firewall ou aplicativo IDS como o número de confirmação no ACK de um cliente legítimo. O cookie retornado pode ser validado e as partes mais importantes do segmento SYN podem ser reconstruídas a partir do cookie, permitindo assim que uma conexão seja estabelecida. Como os clientes falsificados da inundação SYN nunca enviam ACKs, nenhum recurso é alocado para eles em qualquer estado quando os cookies SYN estão em uso. É preferível que você use contramedidas de inundação SYN apenas para hosts sob ataque. A tabela de anomalias pode ser usada para reconhecimento confiável de ataques ou pode ser habilitada dentro do firewall stateful. Esse tipo de configuração também ajuda a evitar o esgotamento dos recursos do sistema (especialmente a tabela de fluxo) em caso de ataques.

  Ao combinar vários serviços, o caminho geral é um fator importante a ser considerado nas direções para frente e para trás. Isso é especialmente verdadeiro quando o NAT é implantado para determinar se o endereço pré-NAT ou pós-NAT deve ser usado para corresponder a uma regra. No caminho de encaminhamento de uma interface LAN para uma interface WAN, o IDS e o firewall stateful são executados primeiro, depois o NAT e, finalmente, o IPSec. Essa sequência de processamento de serviços indica que o firewall stateful deve corresponder em um endereço pré-NAT, enquanto o túnel IPSec corresponde ao endereço pós-NAT. No caminho de retorno, o pacote IPSec é processado primeiro, depois o NAT e, por fim, o firewall stateful. Essa ordem de processamento ainda permite que o IPSec corresponda a um endereço público e que o firewall stateful corresponda a um endereço privado. Você deve configurar separadamente os serviços de firewall, NAT e IDS. O processamento de pacotes se torna muito mais complicado quando o IPSec sobre GRE é implementado no roteador com outros serviços ativados. Esse comportamento ocorre porque o Junos OS trata os pacotes GRE de maneira única após o encapsulamento GRE. Depois que um pacote é encapsulado em um pacote GRE, ele é marcado com uma interface de entrada como a interface de saída do próximo salto. Esse método de marcação faz com que os pacotes GRE sejam bloqueados se algum filtro de entrada ou serviço de entrada não permitir esse serviço.

  Os serviços do Junos OS oferecem suporte a um conjunto limitado de regras de IDS para ajudar a detectar ataques, como varredura de portas e anomalias nos padrões de tráfego. Ele também oferece suporte a alguma prevenção de ataques, limitando o número de fluxos, sessões e taxas. Além disso, ele protege contra ataques SYN implementando um mecanismo de cookie SYN. Como o serviço de Intrusion Detection and Prevention (IDP) não oferece suporte a assinaturas de aplicativos de camada superior, uma abordagem eficaz contra ataques é que a proteção contra um ataque SYN possa ser configurada. A solução IDP é em grande parte uma ferramenta de monitoramento e não uma ferramenta de prevenção essencial. Para evitar um ataque SYN, o roteador operará como um tipo de "proxy" SYN e utilizará valores de cookie. Quando esse recurso é ativado, o roteador responde ao pacote SYN inicial com um pacote SYN-ACK que contém um valor de cookie exclusivo no campo de número de sequência. Se o iniciador responder com o mesmo cookie no campo de sequência, o fluxo TCP será aceito; Se o respondente não responder ou se responder com o cookie errado, o fluxo será descartado. Para acionar essa defesa, você deve configurar um limite de cookie SYN. Para habilitar a defesa do cookie SYN, uma ação de regra IDS deve conter um limite que indique quando o recurso deve ser habilitado e um valor MSS para evitar que o roteador gerencie fragmentos segmentados ao atuar como um proxy SYN: