Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Nesta página
 

Monitoramento do tráfego de VPN

O monitoramento de VPN permite que você determine a acessibilidade dos dispositivos peer enviando solicitações do Protocolo de Mensagem de Controle de Internet (ICMP) para os pares.

Entenda os alarmes e auditorias de VPN

Configure o comando a seguir para permitir o registro de eventos de segurança durante a configuração inicial do dispositivo. Esse recurso tem suporte para dispositivos SRX300, SRX320, SRX340, SRX345, SRX550HM e SRX1500 e instâncias de firewall virtual vSRX.

set security log cache

Os administradores (auditoria, criptográfica, IDS e segurança) não podem modificar a configuração de registro de eventos de segurança se o comando acima estiver configurado e cada função de administrador estiver configurada para ter um conjunto distinto e único de privilégios além de todas as outras funções administrativas.

Os alarmes são acionados por uma falha de VPN. Um alarme VPN é gerado quando o sistema monitora qualquer um dos seguintes eventos auditados:

  • Authentication failures— Você pode configurar o dispositivo para gerar um alarme do sistema quando as falhas de autenticação de pacotes atingirem um número especificado.

  • Encryption and decryption failures— Você pode configurar o dispositivo para gerar um alarme do sistema quando falhas de criptografia ou descriptografia excedem um número especificado.

  • IKE Phase 1 and IKE Phase 2 failures— As negociações da Fase 1 da Internet Key Exchange (IKE) são usadas para estabelecer associações de segurança IKE (SAs). Esses SAs protegem as negociações da Fase 2 da IKE. Você pode configurar o dispositivo para gerar um alarme de sistema quando as falhas da Fase 1 ou IKE da Fase 2 excedem um número especificado.

  • Self-test failures— Os autotestes são testes que um dispositivo executa com base ou reinicialização para verificar se o software de segurança é implementado corretamente em seu dispositivo.

    Os auto-testes garantem a correção dos algoritmos criptográficos. A imagem do Junos-FIPS realiza auto-testes automaticamente após a ativação, e continuamente para a geração de pares chave. Em imagens domésticas ou FIPS, os auto-testes podem ser configurados para serem realizados de acordo com um cronograma definido, sob demanda ou imediatamente após a geração chave.

    Você pode configurar o dispositivo para gerar um alarme de sistema quando ocorre uma falha auto-teste.

  • IDP flow policy attacks— Uma política de detecção e prevenção de invasões (IDP) permite que você aplique várias técnicas de detecção e prevenção de ataques no tráfego de rede. Você pode configurar o dispositivo para gerar um alarme do sistema quando ocorrem violações da política de fluxo de IDP.

  • Replay attacks— Um ataque de repetição é um ataque de rede no qual uma transmissão de dados válida é maliciosa ou fraudulentamente repetida ou adiada. Você pode configurar o dispositivo para gerar um alarme de sistema quando ocorre um ataque de repetição.

As mensagens de syslog estão incluídas nos seguintes casos:

  • Geração de chave simétrica com falha

  • Geração de chave assimétrica falha

  • Distribuição de chave manual com falha

  • Distribuição de chave automatizada com falha

  • Falha na destruição de chave

  • Manuseio e armazenamento de chave com falha

  • Criptografia ou descriptografia de dados com falha

  • Assinatura com falha

  • Acordo-chave fracassado

  • Hashing criptográfico com falha

  • Falha no IKE

  • Autenticação falha dos pacotes recebidos

  • Erro de descriptografia devido ao conteúdo de preenchimento inválido

  • Incompatibilidade no comprimento especificado no campo alternativo de assunto do certificado recebido de um dispositivo vpn peer remoto.

Os alarmes são levantados com base em mensagens de syslog. Cada falha é registrada, mas um alarme é gerado apenas quando um limite é atingido.

Para visualizar as informações do alarme, execute o show security alarms comando. A contagem de violações e o alarme não persistem nas reinicializações do sistema. Após uma reinicialização, a contagem de violações é redefinida para zero, e o alarme é liberado da fila de alarme.

Após as ações apropriadas terem sido tomadas, você pode limpar o alarme. O alarme permanece na fila até você liberá-lo (ou até que você reinicialize o dispositivo). Para limpar o alarme, execute o clear security alarms comando.

Consulte também

Entendendo os métodos de monitoramento de VPN

Read this topic to understand multiple ways in which you can monitor VPN tunnels in SRX Series Firewalls.

Monitorar VPNs é uma necessidade, pois a maioria dos serviços críticos de sua empresa são executados nesses túneis de VPN. Esperamos que os túneis VPN funcionem de forma ideal o tempo todo. Mas dificilmente é o caso em um cenário do mundo real. Um túnel VPN pode ser desativado por vários motivos. Por exemplo: o peer IKE pode ser inalcançável, a VPN subjacente pode estar baixa, o túnel pode estar batendo e várias outras razões. O Junos OS resolve esses problemas.

Entendendo a detecção de peers mortos

Dead Peer Detection (DPD) é um protocolo baseado em padrões que usa o tráfego de rede para detectar a vida de um peer IKE em uma conexão IPsec. Durante a criação de túneis IPsec, os pares de VPN negociam para decidir se usam ou não o método DPD. Se os pares concordarem em usar o protocolo DPD, o firewall verifica ativamente a vida dos pares. Quando não há tráfego ativo, o firewall envia mensagens periódicas para o peer e aguarda uma resposta. Se o peer não responder às mensagens, o firewall assume que o peer não está mais disponível. O comportamento do protocolo DPD é o mesmo para os protocolos IKEv1 e IKEv2. Os timers DPD estão ativos assim que o firewall estabelece a IKE Phase 1 Security Association (SA). Os firewalls da Série SRX usam o protocolo DPD para detectar a vida dos pares em uma conexão VPN IPsec.

Figura 1: Troca de mensagens no protocolo DPDTroca de mensagens no protocolo DPD

Figura 1 mostra a troca de mensagens DPD entre os pares IKE em um túnel VPN IPsec. Os eventos a seguir ocorrem quando o dispositivo executa DPD:

  1. O SRX-A aguarda até o intervalo de DPD especificado para verificar se ele recebeu algum tráfego do peer, SRX-B.

  2. Se o SRX-A não receber nenhum tráfego do SRX-B durante o intervalo de DPD especificado, ele envia uma carga de notificação IKE Phase 1 criptografada — uma mensagem R-U-THERE — para o SRX-B.

  3. O SRX-A aguarda o reconhecimento de DPD — uma mensagem R-U-THERE-ACK — do SRX-B.

    1. Se o SRX-A receber uma mensagem R-U-THERE-ACK do SRX-B durante este intervalo, ele considera o peer vivo. Em seguida, o SRX-A reinicia seu contador de mensagens R-U-THERE para esse túnel e inicia um novo intervalo.

    2. Se o SRX-A não receber uma mensagem R-U-THERE-ACK durante o intervalo, ele considera o peer, SRX-B, desativado. O SRX-A então remove a SA da Fase 1 e todos os SAs da Fase 2 para esse peer.

Vamos ver quais parâmetros de DPD você precisará configurar:

  • Modo — Com base na atividade de tráfego, você pode configurar o DPD em um dos seguintes modos:

    • Otimizado — No modo otimizado , quando o dispositivo de iniciação envia pacotes de saída para o peer, se não houver tráfego IKE ou IPsec de entrada do peer dentro do intervalo configurado, o dispositivo de iniciação aciona mensagens R-U-THERE. O DPD opera neste modo padrão a menos que você especifique um modo por meio da configuração.

    • Sondar túnel ocioso — No modo de túnel ocioso da sonda , o dispositivo aciona mensagens R-U-THERE se não houver tráfego IKE ou IPsec de entrada ou saída em um intervalo configurado. O dispositivo envia mensagens R-U-THERE periodicamente para o peer até que haja atividade de tráfego. Esse modo ajuda na detecção antecipada de um peer que está desativado, garantindo a disponibilidade do túnel durante o fluxo de tráfego ativo.



      Nota:

      Se você configurou vários seletores de tráfego para uma VPN, você pode estabelecer vários túneis para o mesmo IKE SA. Neste cenário, quando você configura o modo de túnel ocioso de sonda, ele aciona mensagens R-U-THERE se um túnel ficar ocioso, independentemente do tráfego em outro túnel para a mesma SA IKE.

    • Sempre enviar — No modo de sempre enviar , o dispositivo envia mensagens R-U-THERE em um intervalo configurado, independentemente da atividade de tráfego entre os pares. Recomendamos que você prefira usar o modo de túnel ocioso de sondagem em vez do modo de envio sempre.

  • Intervalo — Use o parâmetro de intervalo para especificar a quantidade de tempo (em segundos) que o dispositivo espera pelo tráfego de seus pares antes de enviar uma mensagem R-U-THERE. O intervalo padrão é de 10 segundos. Começando pelo Junos OS Release 15.1X49-D130, reduzimos o intervalo de parâmetros de intervalo permitido no qual as mensagens R-U-THERE são enviadas ao dispositivo peer de 10 segundos a 60 segundos para 2 segundos a 60 segundos. Recomendamos que você defina o parâmetro limite mínimo para 3, quando o parâmetro de intervalo de DPD for definido para menos de 10 segundos.

  • Limiar — Use o parâmetro limiar para especificar o número máximo de vezes que o dispositivo envia a mensagem R-U-THERE sem receber uma resposta do peer, antes que ele considere o peer para baixo. O número padrão de transmissões é de cinco, com uma faixa permissível de 1 a 5 retries.

Observe as seguintes considerações antes de configurar o DPD:

  • Depois de adicionar a configuração de DPD a um gateway existente com túneis ativos, o dispositivo começa a acionar mensagens R-U-THERE sem limpar os SAs da Fase 1 ou Fase 2.

  • Ao excluir a configuração de DPD de um gateway existente com túneis ativos, o dispositivo para de acionar mensagens R-U-THERE para os túneis. Mas isso não afeta os SAs IKE e IPsec.

  • Quando você modifica parâmetros de configuração de DPD, como valores de modo, intervalo ou limiar, o IKE atualiza a operação DPD sem limpar os SAs da Fase 1 ou Fase 2.

  • Se você configurar o gateway IKE com monitoramento de DPD e VPN sem especificar a opção de estabelecer túneis imediatamente, a IKE não inicia a negociação da Fase 1. Ao configurar o DPD, você também deve configurar a opção establish-tunnels immediately no nível [edit services ipsec-vpn] de hierarquia para derrubar a interface st0 quando não houver SAs de fase 1 e fase 2 disponíveis. Veja estabelecer túneis imediatamente.

  • Se você configurar o gateway IKE com vários endereços IP peer e DPD, mas não estabelecer a Fase 1 SA com o primeiro endereço IP peer, o IKE tenta estabelecer com o próximo endereço IP peer. O DPD só está ativo após o IKE estabelecer a Fase 1 SA. Veja a detecção inigualável.

  • Se você configurar o gateway IKE com vários endereços IP peer e DPD, mas a conexão falhar com o endereço IP do peer atual, o IKE libera os SAs e DPD da Fase 1 e fase 2 e o DPD faz um failover para o próximo endereço IP peer. Veja gateway (Security IKE).

  • Mais de uma Fase 1 ou AA fase 2 podem existir com os mesmos pares por causa de negociações simultâneas. Neste caso, o DPD envia mensagens R-U-THERE para todos os SAs da Fase 1. Se o gateway não receber respostas DPD pelo número configurado de vezes consecutivas, ele limpará a Fase 1 SA e a FASE 2 SA associada (apenas para IKEv2).

Nota:

Para obter mais detalhes sobre a implementação do DPD, consulte RFC 3706, um método baseado em tráfego de detecção de peers de troca de chaves de Internet (IKE).

Se o peer IKE estiver em alta, isso significa que a VPN subjacente está ativa?

Dica:

Pense se o DPD garante a liveness do IPsec SA.

Entendendo o monitoramento de VPN

Embora o protocolo Dead Peer Detection (DPD) verifique a vida de um peer IKE, ele não garante a vida da VPN subjacente. Não há um método baseado em padrões para verificar se a VPN subjacente está ativa. O monitoramento de VPN é um mecanismo do Junos OS para verificar a vida de uma associação de segurança IPsec (SA). O monitoramento de VPN usa solicitações de eco (ou pings) do Protocolo de Mensagem de Controle de Internet (ICMP) e dados de assinatura, como iD de túnel, no pacote ICMP para determinar se o túnel VPN está funcionando.

Quando você habilita o monitoramento de VPN, o dispositivo envia pings pelo túnel VPN para o gateway peer ou para um destino especificado na outra extremidade do túnel. O dispositivo envia pings por padrão em intervalos de 10 segundos por até 10 vezes consecutivas. Se o dispositivo não receber nenhuma resposta após 10 pings consecutivos, ele considera a VPN baixa e a associação de segurança IPsec (SA) liberada.

O monitoramento de DPD e VPN se complementam. O monitoramento de VPN se aplica a uma VPN IPsec individual, enquanto o DPD é configurado em um contexto de gateway IKE individual.

Você pode usar os seguintes modos de operação para monitorar túneis VPN:

  • Modo de envio sempre — Neste modo, o dispositivo envia um pacote de monitoramento vpn assim que cada intervalo configurado, independentemente do tráfego no túnel. Depois de habilitar o monitoramento de VPN, o Junos OS usa o modo sempre enviado como o modo padrão se você não especificar um.

  • Modo otimizado — Neste modo, o dispositivo envia um pacote de monitoramento vpn uma vez que cada intervalo configurado somente se houver tráfego de saída e sem tráfego de entrada pelo túnel durante o intervalo. Se houver tráfego de entrada pelo túnel VPN, o dispositivo considera o túnel ativo e não envia pings para o peer. Você pode usar o modo otimizado para economizar recursos no dispositivo , pois neste modo o dispositivo envia pings apenas quando precisa para determinar a vida dos pares. O envio de pings também pode ativar links de backup caros que de outra forma não seriam usados. O dispositivo opera no modo de envio sempre padrão se você não configurar o modo otimizado explicitamente.

Para configurar o monitoramento de VPN nos firewalls da Série SRX:

  1. Habilite o monitoramento de VPN para um túnel VPN específico, incluindo a opção vpn-monitor no nível deedit security ipsec vpn vpn-name hierarquia. Veja o vpn-monitor.

  2. Configure o modo de monitoramento de VPN conforme otimizado.

  3. Especifique o endereço IP de destino. O endereço IP do gateway peer é o destino padrão; no entanto, você pode especificar um endereço IP de destino diferente (como o de um servidor) que está na outra extremidade do túnel.

  4. Especifique o source-interface endereço. O endpoint do túnel local é a interface de origem padrão, mas você pode especificar um nome de interface diferente.

  5. Configure o intervalo em que o dispositivo envia os pings e o número de pings consecutivos que ele envia com o e threshold as interval opções, respectivamente, no nível [edit security ipsec vpn-monitor-options] de hierarquia. Se você não configurar essas opções, o dispositivo envia pings no intervalo padrão de 10 segundos até 10 vezes consecutivas. Se ele não receber uma resposta, ele considera a VPN baixa. Em seguida, o dispositivo libera a associação de segurança IPsec.

Nota:

Os firewalls de SRX5400, SRX5600 e SRX5800 não suportam o monitoramento vpn de um dispositivo conectado externamente (como um PC). Nesses dispositivos, odestino dele para o monitoramento de VPN deve ser uma interface local.

CUIDADO:

O monitoramento de VPN pode causar flapping de túnel em algunsambientes se os pacotes de ping não forem aceitos pelo peer com base no endereço IP de origem ou destino do pacote.

Entendendo a verificação do datapath IPsec

Visão geral

Por padrão, o estado das interfaces de túnel seguro (st0) configuradas no modo ponto a ponto em VPNs baseadas em rota é baseada no estado do túnel VPN. Logo após a criação da SA IPsec, as rotas associadas à interface st0 são instaladas na tabela de encaminhamento do Junos OS. Em determinadas topologias de rede, como onde um firewall de trânsito está localizado entre os endpoints do túnel VPN, o tráfego de dados IPsec que usa rotas ativas para um túnel VPN estabelecido na interface st0 pode ser bloqueado pelo firewall de trânsito. Isso pode resultar em perda de tráfego.

Quando você habilita a verificação do datapath IPsec, a interface st0 não é criada e ativada até que o datapath seja verificado. A verificação está configurada com a set security ipsec vpn vpn-name vpn-monitor verify-path declaração para túneis VPN dinâmicos de endpoint, baseados em rota, site para site e de endpoint dinâmico.

Se houver um dispositivo NAT na frente do endpoint do túnel peer, o endereço IP do endpoint do túnel peer é traduzido para o endereço IP do dispositivo NAT. Para que a solicitação do ICMP do monitor VPN chegue ao endpoint do túnel de peer, você precisa especificar explicitamente o endereço IP original não traduzido do endpoint do túnel de peer atrás do dispositivo NAT. Isso está configurado com a set security ipsec vpn vpn-name vpn-monitor verify-path destination-ip configuração.

A partir do Junos OS Release 15.1X49-D120, você pode configurar o tamanho do pacote que é usado para verificar um datapath IPsec antes que a st0 interface seja criada. Use a set security ipsec vpn vpn-name vpn-monitor verify-path packet-size configuração. O tamanho do pacote configurável varia de 64 a 1350 bytes; o padrão é de 64 bytes.

Advertências

A interface de origem e os endereços IP de destino que podem ser configurados para a operação do monitor VPN não têm efeito na verificação do datapath IPsec. A fonte para as solicitações de ICMP na verificação de datapath IPsec é o endpoint local do túnel.

Quando você habilita a verificação de datapath IPsec, o monitoramento de VPN é ativado automaticamente e usado após a interface st0 ser criada. Recomendamos que você configure a opção otimizada do monitor VPN com o set security ipsec vpn vpn-name vpn-monitor optimized comando sempre que habilitar a verificação do datapath IPsec.

Se um failover de cluster de chassi ocorrer durante a verificação do datapath IPsec, o novo nó ativo inicia a verificação novamente. A interface st0 não é ativada até que a verificação seja bem sucedida.

Nenhuma verificação de datapath IPsec é realizada para rekeys IPsec SA, porque o estado da interface st0 não muda para rekeys.

A verificação do datapath IPsec não é suportada em interfaces st0 configuradas no modo ponto a multiponto que são usadas com AutoVPN, Auto Discovery VPN e vários seletores de tráfego. O monitoramento de VPN e a verificação de datapath IPsec oferecem suporte a endereços IPv6, para que a verificação do datapath IPsec possa ser usada com túneis IPv6.

Entender os recursos globais de monitoramento de SPI e VPN

Você pode monitorar e manter a operação eficiente de sua VPN usando os seguintes recursos globais de VPN:

  • SPI — Os pares em uma associação de segurança (SA) podem ficar sem sincronização quando um dos pares falha. Por exemplo, se um dos pares reiniciar, ele pode enviar um índice de parâmetro de segurança (SPI) incorreto. Você pode permitir que o dispositivo detecte tal evento e ressincronize os pares configurando o recurso de resposta a SPI ruim.

  • Monitoramento de VPN — você pode usar o recurso global de monitoramento de VPN para enviar periodicamente solicitações do Protocolo de Mensagem de Controle de Internet (ICMP) ao peer para determinar se o peer é acessível.

Comparando o monitoramento de VPN e DPD

Monitoramento de VPN e detecção de peer inativos (DPD) são recursos disponíveis em firewalls da Série SRX para verificar a disponibilidade de dispositivos peer VPN. Esta seção compara a operação e a configuração desses recursos.

O firewall da Série SRX responde às mensagens DPD enviadas por pares de VPN mesmo que o DPD não esteja configurado no dispositivo. Você pode configurar o firewall da Série SRX para iniciar mensagens DPD aos pares de VPN. Você também pode configurar o monitoramento de DPD e VPN para operar simultaneamente no mesmo firewall da Série SRX, embora o número de pares que podem ser monitorados com ambos os métodos seja reduzido.

O monitoramento de VPN é um mecanismo do Junos OS que monitora apenas as associações de segurança da Fase 2 (SAs). O monitoramento de VPN é habilitado por VPN com a vpn-monitor declaração no nível [edit security ipsec vpn vpn-name] de hierarquia. O IP de destino e a interface de origem devem ser especificados. A opção optimized permite que o dispositivo use padrões de tráfego como evidência da liveliness dos peer; As solicitações de ICMP são suprimidas.

As opções de monitoramento de VPN estão configuradas com a vpn-monitor-options declaração no nível [edit security ipsec] de hierarquia. Essas opções se aplicam a todas as VPNs para as quais o monitoramento de VPN está habilitado. As opções que você pode configurar incluem o intervalo em que as solicitações do ICMP são enviadas ao peer (o padrão é de 10 segundos) e o número de solicitações de ICMP consecutivas enviadas sem receber uma resposta antes que o peer seja considerado inalcançável (o padrão é de 10 solicitações consecutivas).

DPD é uma implementação do RFC 3706, um método baseado em tráfego de detecção de peers de troca de chaves de Internet (IKE). Ele opera no nível IKE e monitora o peer com base na atividade de tráfego IKE e IPsec.

O DPD está configurado em um gateway IKE individual com a dead-peer-detection declaração no nível [edit security ike gateway gateway-name] de hierarquia. Você pode configurar os modos de operação DPD. O modo padrão (otimizado) envia mensagens DPD para o peer se não houver tráfego IKE ou IPsec de entrada em um intervalo configurado após o dispositivo local enviar pacotes de saída para o peer. Outras opções configuráveis incluem o intervalo em que as mensagens DPD são enviadas ao peer (o padrão é de 10 segundos) e o número de mensagens DPD consecutivas enviadas sem receber uma resposta antes que o peer seja considerado indisponível (o padrão é de cinco solicitações consecutivas).

Consulte também

Entendendo os eventos de túnel

Quando há um problema de rede relacionado a uma VPN, após o túnel surgir apenas o status do túnel é rastreado. Muitos problemas podem ocorrer antes que o túnel apareça. Assim, em vez de rastrear apenas o status do túnel, problemas de tunelamento ou falhas de negociação, eventos bem-sucedidos, como negociações bem-sucedidas da IPsec SA, rekey IPsec e rekeys IKE SA agora são rastreados. Esses eventos são chamados de eventos de túnel.

Para a Fase 1 e a Fase 2, os eventos de negociação de um determinado túnel são acompanhados juntamente com os eventos que ocorrem em daemons externos como AUTHD ou PKID. Quando um evento de túnel ocorre várias vezes, apenas uma entrada é mantida com o tempo atualizado e o número de vezes que esse evento ocorreu.

Ao todo, 16 eventos são acompanhados: oito eventos para a Fase 1 e oito eventos para a Fase 2. Alguns eventos podem se repetir e preencher a memória do evento, resultando na remoção de eventos importantes. Para evitar a sobreposição, um evento não é armazenado a menos que um túnel esteja desativado.

Os seguintes eventos especiais se incorporam a esta categoria:

  • Vida útil em kilobytes expirados para IPsec SA

  • Dura vida útil do IPsec SA expirada

  • IPsec SA apaga carga recebida de peer, SAs IPsec correspondentes liberados

  • Pares de SA IPsec de backup redundantes sem utilização liberados

  • SAs IPsec liberados como SA IKE correspondente excluído

Os túneis AutoVPN são criados e removidos dinamicamente e, consequentemente, os eventos de túnel correspondentes a esses túneis são de curta duração. Às vezes, esses eventos de túnel não podem ser associados a nenhum túnel, por isso o registro de sistema é usado para depuração.

Consulte também

Exemplo: Configure uma notificação de alerta audível

Este exemplo mostra como configurar um dispositivo para gerar um bipe de alerta do sistema quando ocorre um novo evento de segurança. Por padrão, os alarmes não são audíveis. Esse recurso tem suporte para dispositivos SRX300, SRX320, SRX340, SRX345, SRX550HM e SRX1500 e instâncias de firewall virtual vSRX.

Requisitos

Nenhuma configuração especial além da inicialização do dispositivo é necessária antes de configurar esse recurso.

Visão geral

Neste exemplo, você define um bipe audível a ser gerado em resposta a um alarme de segurança.

Configuração

Procedimento

Procedimento passo a passo

Para definir um alarme audível:

  1. Habilite alarmes de segurança.

  2. Especifique se deseja ser notificado sobre alarmes de segurança com um bipe audível.

  3. Se você terminar de configurar o dispositivo, confirme a configuração.

Verificação

Para verificar se a configuração está funcionando corretamente, insira o show security alarms detail comando.

Consulte também

Exemplo: Configure a geração de alarmes de segurança

Este exemplo mostra como configurar o dispositivo para gerar um alarme do sistema quando ocorre uma violação em potencial. Por padrão, nenhum alarme é levantado quando ocorre uma violação em potencial. Esse recurso tem suporte para dispositivos SRX300, SRX320, SRX340, SRX345, SRX550HM e SRX1500 e instâncias de firewall virtual vSRX.

Requisitos

Nenhuma configuração especial além da inicialização do dispositivo é necessária antes de configurar esse recurso.

Visão geral

Neste exemplo, você configura um alarme a ser levantado quando:

  • O número de falhas de autenticação excede 6.

  • O auto-teste criptográfico falha.

  • O auto-teste não criptográfico falha.

  • O auto-teste de geração chave falha.

  • O número de falhas de criptografia excede 10.

  • O número de falhas de descriptografia excede 1.

  • O número de falhas na Fase 1 do IKE excede 10.

  • O número de falhas na Fase 2 do IKE excede 1.

  • Ocorre um ataque de repetição.

Configuração

Procedimento

Configuração rápida da CLI

Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere todos os detalhes necessários para combinar com a configuração da sua rede, copiar e colar os comandos na CLI no nível de [edit] hierarquia e, em seguida, entrar no commit modo de configuração.

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter instruções sobre como fazer isso, veja Usando o Editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.

Configurar alarmes em resposta a possíveis violações:

  1. Habilite alarmes de segurança.

  2. Especifique se um alarme deve ser levantado quando uma falha de autenticação ocorrer.

  3. Especifique se um alarme deve ser levantado quando ocorre uma falha de auto-teste criptográfica.

  4. Especifique se um alarme deve ser levantado quando ocorre uma falha de auto-teste não criptográfica.

  5. Especifique se um alarme deve ser levantado quando ocorre uma falha de auto-teste de geração chave.

  6. Especifique se um alarme deve ser levantado quando uma falha de criptografia ocorre.

  7. Especifique se um alarme deve ser levantado quando ocorre uma falha de descriptografia.

  8. Especifique se um alarme deve ser levantado quando ocorre uma falha na Fase 1 do IKE.

  9. Especifique se um alarme deve ser levantado quando ocorre uma falha na Fase 2 do IKE.

  10. Especifique se um alarme deve ser levantado quando um ataque de repetição ocorrer.

Resultados

A partir do modo de configuração, confirme sua configuração entrando no show security alarms comando. Se a saída não exibir a configuração pretendida, repita as instruções de configuração neste exemplo para corrigi-la.

Se você terminar de configurar o dispositivo, entre no commit modo de configuração.

Verificação

Para confirmar se a configuração está funcionando corretamente, a partir do modo operacional, entre no show security alarms comando.

Consulte também

Tópicos relacionados

Tabela de histórico de alterações

A compatibillidadde com o recurso dependerá da platadorma e versão utilizada. Use o Feature Explorer para saber se o recurso é compatível com sua plataforma.

Versão
Descrição
15.1X49-D130
Começando pelo Junos OS Release 15.1X49-D130, o intervalo de intervalo permitido no qual as mensagens R-U-THERE são enviadas ao dispositivo peer é reduzida de 10 a 60 segundos para 2 segundos a 60 segundos. O parâmetro limite mínimo deve ser 3, quando o parâmetro de intervalo de DPD for definido com menos de 10 segundos.
15.1X49-D120
A partir do Junos OS Release 15.1X49-D120, você pode configurar o tamanho do pacote que é usado para verificar um datapath IPsec antes que a st0 interface seja criada.