Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Monitoramento do tráfego VPN

O monitoramento de VPN permite determinar a acessibilidade dos dispositivos peer, enviando solicitações do Protocolo de Mensagem de Controle de Internet (ICMP) aos pares.

Entender alarmes e auditorias de VPN

Configure o comando a seguir para habilitar o registro de eventos de segurança durante a configuração inicial do dispositivo. Esse recurso é compatível com os dispositivos SRX300, SRX320, SRX340, SRX345, SRX550HM e SRX1500 e instâncias vSRX.

set security log cache

Os administradores (auditoria, criptografia, 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 do Internet Key Exchange (IKE) são usadas para estabelecer associações de segurança (SAs) de IKE. Esses SAs protegem as negociações da Fase 2 do IKE. Você pode configurar o dispositivo para gerar um alarme do sistema quando falhas de Fase 1 ou IKE fase 2 excederem um número especificado.

  • Self-test failures— Auto-testes são testes de que um dispositivo é executado com energia 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 o power-on 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 do 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 atrasada. Você pode configurar o dispositivo para gerar um alarme do sistema quando um ataque de repetição ocorre.

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

  • Geração de chave simétrica falha

  • Geração de chave assimétrica falha

  • Distribuição de chave manual falha

  • Distribuição de chave automatizada falha

  • Falha na destruição de chave

  • Falha no tratamento e armazenamento de chaves

  • Criptografia ou descriptografia de dados falha

  • Assinatura falha

  • Acordo-chave falhou

  • Hashing criptográfico falhou

  • Falha no IKE

  • Autenticação falha dos pacotes recebidos

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

  • Incompatibilidade no comprimento especificado no campo de assunto alternativo 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 só é gerado 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.

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

Entender o monitoramento de VPN

O monitoramento de VPN usa solicitações de eco de ICMP (ou pings) para determinar se um túnel VPN está ativo. Quando o monitoramento de VPN é ativado, o dispositivo de segurança envia pings pelo túnel VPN para o gateway peer ou para um destino especificado na outra extremidade do túnel. Os pings são enviados por padrão em intervalos de 10 segundos por até 10 vezes consecutivas. Se nenhuma resposta for recebida após 10 pings consecutivos, a VPN será considerada baixa e a associação de segurança IPsec (SA) for liberada.

O monitoramento de VPN é habilitado para uma VPN especificada, configurando a opção vpn-monitor no nível [edit security ipsec vpn vpn-nameda hierarquia]. O endereço IP do gateway peer é o destino padrão; no entanto, você pode especificar um endereço IP de destino diferente (como um servidor) na outra extremidade do túnel. O endpoint do túnel local é a interface de origem padrão, mas você pode especificar um nome de interface diferente.

O monitoramento de VPN de um dispositivo conectado externamente (como um PC) não é compatível com dispositivos SRX5400, SRX5600 e SRX5800. O destino para o monitoramento de VPN deve ser uma interface local no dispositivo SRX5400, SRX5600 ou SRX5800.

A opção de monitoramento optimized de VPN envia pings apenas quando há tráfego de saída e sem tráfego recebido através do túnel VPN. Se houver tráfego recebido pelo túnel VPN, o dispositivo de segurança considera o túnel ativo e não envia pings para o peer. A configuração da opção optimized pode economizar recursos no dispositivo de segurança porque os pings só são enviados quando a vivência do peer precisa ser determinada. O envio de pings também pode ativar links de backup dispendiosos que, de outra forma, não seriam usados.

Você pode configurar o intervalo em que os pings são enviados e o número de pings consecutivos que são enviados sem resposta antes que a VPN seja considerada baixa. Estes estão configurados com as interval opções e threshold , respectivamente, no nível [edit security ipsec vpn-monitor-options] de hierarquia.

O monitoramento de VPN pode causar o flapping de túnel em alguns ambientes VPN 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 do IPsec SA, 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 é 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, de site para local.

Se houver um dispositivo NAT na frente do endpoint do túnel de peer, o endereço IP do endpoint do túnel de peer é traduzido para o endereço IP do dispositivo NAT. Para que a solicitação de ICMP do monitor VPN chegue ao endpoint do túnel de peer, você precisa especificar explicitamente o endereço IP original e 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 do datapath IPsec é o endpoint do túnel local.

Quando você habilita a verificação do 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 não oferecem suporte a endereços IPv6, de modo que a verificação do datapath IPsec não pode 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 VPN globais:

  • SPI — Os pares de uma associação de segurança (SA) podem ficar sem sincronização quando um dos pares falha. Por exemplo, se um dos pares reinicializar, 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 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 é alcançável.

Entender o monitoramento de VPN e o DPD

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

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

O monitoramento de VPN é um mecanismo do Junos OS que monitora apenas as associações de segurança (SAs) da Fase 2. O monitoramento de VPN é habilitado por VPN com a vpn-monitor declaração no nível [edit security ipsec vpn vpn-name] da 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 de vivenciamento de 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 de 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 para detectar pares de troca de chaves de internet mortas (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 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 recebido 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).

Entendendo a detecção de peer morto

A detecção de peer morto (DPD) é um método que os dispositivos de rede usam para verificar a existência atual e a disponibilidade de outros dispositivos peer.

Você pode usar o DPD como uma alternativa ao monitoramento de VPN. O monitoramento de VPN se aplica a uma VPN IPsec individual, enquanto o DPD é configurado apenas em um contexto de gateway IKE individual.

Um dispositivo realiza a verificação de DPD enviando cargas de notificação de Fase 1 de IKE criptografadas (mensagens R-U-THERE) para um peer e esperando reconhecimentos de DPD (mensagens R-U-THERE-ACK) do peer. O dispositivo só envia uma mensagem R-U-THERE se ele não tiver recebido nenhum tráfego do peer durante um intervalo DPD especificado. Se o dispositivo receber uma mensagem R-U-THERE-ACK do peer durante este intervalo, ele considera o peer vivo. Se o dispositivo receber tráfego no túnel do peer, ele reinicia seu contador de mensagens R-U-THERE para esse túnel, iniciando assim um novo intervalo. Se o dispositivo não receber uma mensagem R-U-THERE-ACK durante o intervalo, ele considerará o peer morto. Quando o dispositivo muda o status de um dispositivo peer para estar morto, o dispositivo remove a associação de segurança fase 1 (SA) e todos os SAs de Fase 2 para esse peer.

Os seguintes modos DPD são suportados nos dispositivos da Série SRX:

  • Otimizado — as mensagens R-U-THERE são acionadas se não houver tráfego IKE ou IPsec em um intervalo configurado após o dispositivo enviar pacotes de saída para o peer. Este é o modo padrão.

  • Túnel ocioso de sonda — as mensagens R-U-THERE são acionadas se não houver tráfego IKE ou IPsec de entrada ou saída em um intervalo configurado. As mensagens R-U-THERE são enviadas periodicamente ao peer até que haja atividade de tráfego. Esse modo ajuda na detecção precoce de um peer abatido e disponibiliza o túnel para tráfego de dados.

    Quando vários seletores de tráfego são configurados para uma VPN, vários túneis podem ser estabelecidos para o mesmo IKE SA. Nesse cenário, o modo de túnel ocioso da sonda aciona as mensagens R-U-THERE a serem enviadas se algum túnel associado ao IKE SA ficar ocioso, mesmo que possa haver tráfego em outro túnel para o mesmo IKE SA.

  • Envie sempre — as mensagens R-U-THERE são enviadas em intervalos configurados, independentemente da atividade de tráfego entre os pares.

    Recomendamos que o modo de túnel ocioso da sonda seja usado em vez do always-send modo.

Os temporizadors DPD estão ativos assim que a FASE 1 SA for estabelecida. O comportamento do DPD é o mesmo para protocolos IKEv1 e IKEv2.

Você pode configurar os seguintes parâmetros DPD:

  • O parâmetro de intervalo especifica a quantidade de tempo (expressa em segundos) que o dispositivo espera pelo tráfego de seus colegas antes de enviar uma mensagem R-U-THERE. O intervalo padrão é de 10 segundos. Começando com o Junos OS Release 15.1X49-D130, a faixa de parâmetro de intervalo permissível na 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 de limite mínimo deve ser 3, quando o parâmetro de intervalo DPD for definido em menos de 10 segundos.

  • O parâmetro de limiar especifica o número máximo de vezes para enviar a mensagem R-U-THERE sem uma resposta do peer antes de considerar o peer morto. O número padrão de transmissões é cinco vezes, com uma faixa permissível de 1 a 5 retries.

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

  • Quando uma configuração DPD é adicionada a um gateway existente com túneis ativos, as mensagens R-U-THERE são iniciadas sem limpar os SAs de Fase 1 ou Fase 2.

  • Quando uma configuração DPD é excluída de um gateway existente com túneis ativos, as mensagens R-U-THERE são interrompidas para os túneis. Os SAs IKE e IPsec não são afetados.

  • Modificar qualquer opção de configuração DPD, como o modo, intervalo ou valores de limiar, atualiza a operação DPD sem eliminar os SAs de Fase 1 ou Fase 2.

  • Se o gateway IKE estiver configurado com monitoramento de DPD e VPN, mas a opção de estabelecer túneis imediatamente não estiver configurada, o DPD não iniciará a negociação da Fase 1. Quando o DPD está configurado, a opção de túneis estabelecidos imediatamente também deve ser configurada ao mesmo tempo para derrubar a interface st0 quando não houver SAs de fase 1 e fase 2 disponíveis.

  • Se o gateway IKE estiver configurado com vários endereços IP peer e DPD, mas a Fase 1 SA não for estabelecida para o primeiro endereço IP peer, uma SA de Fase 1 é tentada com o próximo endereço IP peer. O DPD só está ativo depois que uma SA da Fase 1 for estabelecida.

  • Se o gateway IKE estiver configurado com vários endereços IP de peer e DPD, mas o DPD falhar com o endereço IP do peer atual, os SAs de Fase 1 e Fase 2 são liberados e um failover para o próximo endereço IP peer é acionado.

  • Mais de uma Sa fase 1 ou Fase 2 pode existir com o mesmo peer por causa de negociações simultâneas. Neste caso, as mensagens R-U-THERE são enviadas em todos os SAs da Fase 1. A falha em receber respostas DPD pelo número configurado de vezes consecutivas elimina a Fase 1 SA e a SA da Fase 2 associada (apenas para IKEv2).

Entendendo 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 aumente. Assim, em vez de rastrear apenas o status do túnel, problemas de túnel para baixo 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 rastreados junto 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 o 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 desligado.

Os seguintes eventos especiais se enquadram nesta categoria:

  • Vida útil em kilobytes expirado para IPsec SA

  • Dura vida útil do IPsec SA expirou

  • IPsec SA excluir payload recebido 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 do sistema é usado para depuração.

Exemplo: Configuração de um alerta audível como notificação de um alarme de segurança

Este exemplo mostra como configurar um dispositivo para gerar um bipe de alerta do sistema quando um novo evento de segurança ocorre. Por padrão, os alarmes não são audíveis. Esse recurso é compatível com os dispositivos SRX300, SRX320, SRX340, SRX345, SRX550HM e SRX1500 e instâncias 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 você deseja ser notificado de alarmes de segurança com um bipe audível.

  3. Se terminar de configurar o dispositivo, comprometa a configuração.

Verificação

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

Exemplo: Gerando alarmes de segurança em resposta a possíveis violações

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 é compatível com os dispositivos SRX300, SRX320, SRX340, SRX345, SRX550HM e SRX1500 e instâncias 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 de CLI

Para configurar este exemplo rapidamente, 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 sua configuração de rede, copiar e colar os comandos no 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, consulte o uso do 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 uma falha de auto-teste criptográfica ocorrer.

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

  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 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.

Tabela de histórico de liberação
Versão
Descrição
15.1X49-D130
Começando com o Junos OS Release 15.1X49-D130, a faixa de parâmetro de intervalo permissível na 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 de limite mínimo deve ser 3, quando o parâmetro de intervalo DPD for definido em 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.