Negociações de VPN IPSec
Os dispositivos nas extremidades de um túnel VPN IPSec são pares IPSec. Para construir o túnel VPN, os pares IPSec trocam uma série de mensagens sobre criptografia e autenticação e tentam chegar a um acordo sobre muitos parâmetros diferentes. Este processo é conhecido como negociações VPN. Um dispositivo na sequência de negociação é o iniciador e o outro dispositivo é o respondedor.
As negociações de VPN acontecem em duas fases distintas: Fase 1 e Fase 2 .
- Fase 1: O objetivo é configurar um canal criptografado seguro por meio do qual os dois pares podem negociar a Fase 2. Quando a Fase 1 termina com sucesso, os pares passam rapidamente para as negociações da Fase 2. Se a Fase 1 falhar, os dispositivos não podem iniciar a Fase 2.
- Fase 2: O objetivo é que os dois pares concordem em um conjunto de parâmetros que definem qual tráfego pode passar pela VPN e como criptografar e autenticar o tráfego. Este contrato é denominado Associação de Segurança.
As configurações da Fase 1 e da Fase 2 devem corresponder aos dispositivos em uma das extremidades do túnel.
Fase 1 Negociações
Nas negociações da Fase 1, os dois dispositivos de gateway VPN trocam credenciais. Os dispositivos se identificam e negociam para encontrar um conjunto comum de configurações da Fase 1 para usar. Quando as negociações da Fase 1 são concluídas, os dois dispositivos têm uma Associação de Segurança de Fase 1 (SA). Este SA é válido por um período de tempo especificado. Se os dois gateways VPN não concluírem as negociações da Fase 2 antes que o SA da Fase 1 expire, eles deverão concluir as negociações da Fase 1 novamente.
O processo de negociação da Fase 1 depende de qual versão do IKE os pontos de extremidade do gateway usam. O IKE autentica pares IPSec e negocia SAs IKE durante esta fase, configurando um canal de comunicação seguro para negociar SAs IPSec na Fase 2.
As negociações da Fase 1 incluem estas etapas:
- Os dispositivos concordam com a versão IKE a ser usada (IKEv1 ou IKEv2). Cada dispositivo pode usar IKEv1 ou IKEv2. A versão IKE para ambos os dispositivos deve corresponder.
- Os dispositivos trocam credenciais.As credenciais podem ser um certificado ou uma chave pré-compartilhada. Ambos os nós de extremidade do gateway devem usar o mesmo método de credencial e as credenciais devem corresponder.
- Os dispositivos se identificam.Cada dispositivo fornece um identificador de Fase 1, que pode ser um endereço IP, nome de domínio, informações de domínio ou um nome X500. A configuração VPN em cada dispositivo especifica o identificador de Fase 1 do dispositivo local e remoto. As configurações devem corresponder.
- Para IKEv1, os gateways VPN decidem se usarão o modo principal(main) ou o modo agressivo para as negociações da fase 1.O gateway de VPN que inicia as negociações IKE envia uma proposta de modo principal ou uma proposta de modo agressivo. O outro gateway VPN pode rejeitar a proposta se não estiver configurado para usar esse modo.
- O Modo Principal(main) garante a identidade de ambos os gateways VPN, mas pode ser usado apenas se ambos os dispositivos tiverem um endereço IP estático. O Modo Principal valida o endereço IP e o ID do gateway.
- O modo agressivo é mais rápido, mas menos seguro do que o modo principal, porque requer menos trocas entre dois gateways VPN. No modo agressivo, a troca depende principalmente dos tipos de ID usados na troca por ambos os gateways VPN. O modo agressivo não garante a identidade do gateway VPN. A vulnerabilidade do modo agressivo IKEv1 descrita em CVE-2002-1623 significa que o modo agressivo é menos seguro do que o modo principal, a menos que você configure um certificado.
- Os gateways VPN concordam com os parâmetros da Fase 1.
- Se deve usar NAT transversal
- Se deve usar IKE Keep-Alive (apenas entre Fireboxes)
- Se deve usar a detecção de ponto morto (RFC 3706)
- Os gateways VPN concordam com as configurações de transformação da fase 1. As configurações na transformação da Fase 1 em cada dispositivo IPSec devem corresponder exatamente ou as negociações IKE falham.
Os itens que você pode definir na transformação da Fase 1 são:
- Autenticação – o tipo de autenticação (SHA-2, SHA-1 ou MD5)
- Criptografia – O tipo de algoritmo de criptografia (DES, 3DES ou AES) e o comprimento da chave
- Vida SA – A quantidade de tempo até que a Associação de Segurança da Fase 1 expire
- Grupo de chave – O grupo de chave Diffie-Hellman
IKE Keep-Alive é uma configuração obsoleta. Em vez disso, recomendamos DPD. Para IKEv2, NAT Traversal e DPD estão sempre ativados e IKE Keep-Alive não é compatível.
Fase 2 Negociações
Depois que os dois gateways IPSec VPN concluem com êxito as negociações da Fase 1, as negociações da Fase 2 começam. O objetivo das negociações da Fase 2 é estabelecer a SA da Fase 2 (às vezes chamada de IPSec SA). O IPSec SA é um conjunto de especificações de tráfego que informam ao dispositivo qual tráfego enviar pela VPN e como criptografar e autenticar esse tráfego.
As negociações da Fase 2 incluem estas etapas:
- Os gateways VPN usam o SA da Fase 1 para proteger as negociações da Fase 2. Os gateways VPN concordam sobre o uso do Perfect Forward Secrecy (PFS).As chaves de criptografia VPN são alteradas no intervalo especificado pela configuração Forçar expiração de chave . O intervalo é de oito horas por padrão. Para evitar que os SAs usem as chaves da Fase 1 para a Fase 2, o PFS força o cálculo DH a ocorrer uma segunda vez. Isso significa que a Fase 1 e a Fase 2 sempre têm chaves diferentes, que são mais difíceis de quebrar, a menos que você selecione um grupo DH inferior a 14.
Recomendamos que você use o PFS para manter seus dados seguros. Se você deseja usar o PFS, ele deve ser habilitado em ambos os gateways VPN e ambos os gateways devem usar os mesmos grupos de chaves Diffie-Hellman. - Os gateways VPN concordam com uma proposta da Fase 2.A proposta da Fase 2 inclui o algoritmo a ser usado para autenticar dados, o algoritmo a ser usado para criptografar dados e com que freqüência fazer novas chaves de criptografia da Fase 2.Os itens que você pode definir em uma proposta da Fase 2 incluem:
- Type – Para um BOVPN manual, você pode selecionar o tipo de protocolo a ser usado: Authentication Header (AH) ou Encapsulating Security Payload (ESP). Tanto o AH quanto o ESP criptografam os dados e protegem contra falsificação e manipulação de pacotes (detecção de repetição). Recomendamos que você use o ESP, porque você pode se proteger contra spoofing de outras maneiras. BOVPNs gerenciados, VPN móvel com IKEv2, VPN móvel com IPSec e VPN móvel com L2TP sempre usam ESP.
- Autenticação – a autenticação garante que as informações recebidas sejam exatamente iguais às informações enviadas. Você pode usar SHA-1, SHA-2 ou MD5 como o algoritmo que os gateways VPN usam para autenticar mensagens IKE entre si. SHA-2 é a única opção segura.
- Criptografia – A criptografia mantém os dados confidenciais. Você pode selecionar DES, 3DES ou AES ou AES-GCM. As variantes AES e AES-GCM são as únicas opções seguras.
- Forçar expiração de chave – para garantir que as chaves de criptografia da Fase 2 mudem periodicamente, especifique um intervalo de expiração de chave. A configuração padrão é 8 horas. Quanto mais tempo uma chave de criptografia da Fase 2 está em uso, mais dados um invasor pode coletar para usar para montar um ataque à chave. Recomendamos que você não selecione a opção Tráfego porque causa alta carga do Firebox, problemas de taxa de transferência, perda de pacotes e interrupções frequentes e aleatórias. A opção Traffic não funciona com a maioria dos dispositivos de terceiros.
- Os gateways VPN trocam seletores de tráfego da Fase 2 (rotas de túnel).Você pode especificar os seletores de tráfego da Fase 2 para o gateway VPN local e remoto como um endereço IP de host, um endereço IP de rede ou um intervalo de endereços IP. Os seletores de tráfego da Fase 2 são sempre enviados como um par em uma proposta da Fase 2: um indica quais endereços IP por trás do dispositivo local podem enviar tráfego pela VPN e o outro indica quais endereços IP por trás do dispositivo remoto podem enviar tráfego pela VPN. Isso também é conhecido como rota de túnel.
Algoritmos e protocolos IPSec
IPSec é uma coleção de serviços baseados em criptografia e protocolos de segurança que protegem a comunicação entre dispositivos que enviam tráfego por meio de uma rede não confiável. Como o IPSec é construído em uma coleção de protocolos e algoritmos amplamente conhecidos, você pode criar uma VPN IPSec entre seu Firebox e muitos outros dispositivos ou terminais baseados em nuvem que suportam esses protocolos padrão.
Algoritmos de criptografia
Os algoritmos de criptografia protegem os dados para que não possam ser lidos por terceiros durante o trânsito. O Fireware oferece suporte a três algoritmos de criptografia:
- AES (Advanced Encryption Standard) – AES é o algoritmo de criptografia mais forte disponível. O Fireware pode usar chaves de criptografia AES com os seguintes comprimentos: 128, 192 ou 256 bits. AES é mais rápido que 3DES.
-
3DES (Triple-DES) – Um algoritmo de criptografia baseado em DES que usa o algoritmo de criptografia DES três vezes para criptografar os dados. A chave de criptografia é de 168 bits. 3DES é mais lento do que AES.
A vulnerabilidade Sweet32 afeta 3DES. - DES (Data Encryption Standard) – Usa uma chave de criptografia de 56 bits. DES é o mais fraco dos três algoritmos e é considerado inseguro.
Algoritmos de autenticação
Os algoritmos de autenticação verificam a integridade dos dados e a autenticidade de uma mensagem. O Fireware oferece suporte a três algoritmos de autenticação:
- HMAC-MD5 (código de autenticação de mensagem hash – algoritmo 5 do resumo da mensagem)
- O MD5 produz um resumo da mensagem de 128 bits (16 bytes), o que o torna mais rápido do que SHA1 ou SHA2. Este é o algoritmo menos seguro.
- HMAC-SHA1 (código de autenticação de mensagem hash – algoritmo de hash seguro 1)
- SHA1 produz um resumo da mensagem de 160 bits (20 bytes). Embora mais lento que o MD5, esse tamanho de digestão maior o torna mais forte contra ataques de força bruta. O SHA-1 é considerado principalmente inseguro devido a uma vulnerabilidade.
- HMAC-SHA2 (código de autenticação de mensagem hash – algoritmo de hash seguro 2)
- SHA2 é o algoritmo mais seguro. O Fireware v11.8 e superior oferece suporte a três variantes de SHA2 com diferentes comprimentos de resumo de mensagem.
- SHA2-256 – produz um resumo da mensagem de 265 bits (32 bytes)
- SHA2-384 – produz um resumo da mensagem de 384 bits (48 bytes)
- SHA2-512 – produz um resumo da mensagem de 512 bits (64 bytes)
- SHA2 é o algoritmo mais seguro. O Fireware v11.8 e superior oferece suporte a três variantes de SHA2 com diferentes comprimentos de resumo de mensagem.
SHA2 é mais forte do que SHA1 ou MD5. Recomendamos que você especifique uma variante SHA2.
Protocolo IKE
IKE (Internet Key Exchange) é um protocolo usado para configurar associações de segurança para IPSec. Essas associações de segurança estabelecem segredos de sessão compartilhada a partir dos quais as chaves são derivadas para criptografia de dados encapsulados. O IKE também é usado para autenticar os dois pares IPSec.
- IKEv1 é definido no RFC 2409.
- IKEv2 é definido no RFC 7296.
Algoritmo de troca de chaves Diffie-Hellman
O algoritmo de troca de chave Diffie-Hellman (DH) é um método usado para disponibilizar uma chave de criptografia compartilhada para duas entidades sem a troca da chave. A chave de criptografia para os dois dispositivos é usada como uma chave simétrica para criptografar dados. Apenas as duas partes envolvidas na troca de chave DH podem deduzir a chave compartilhada, e a chave nunca é enviada pela rede.
Um grupo de chaves Diffie-Hellman é um grupo de inteiros usados para a troca de chaves Diffie-Hellman, veja a seguir.
Os grupos Diffie-Hellman (DH) determinam a força da chave usada no processo de troca de chave. Números de grupo mais altos são mais seguros, mas requerem mais tempo para calcular a chave.
- Grupo DH 1: grupo de 768 bits
- Grupo DH 2: grupo de 1024 bits
- Grupo DH 5: grupo de 1536 bits
- Grupo DH 14: grupo de 2048 bits
- Grupo DH 15: grupo de 3072 bits
- Grupo DH 19: grupo de curva elíptica de 256 bits
- Grupo DH 20: grupo de curva elíptica de 384 bits
Ambos os pares em uma troca VPN devem usar o mesmo grupo DH, que é negociado durante a Fase 1 do processo de negociação IPSec.
Grupos DH e Perfect Forward Secrecy (PFS)
Além da Fase 1, você também pode especificar o grupo Diffie-Hellman para usar na Fase 2 de uma conexão IPSec. A configuração da fase 2 inclui configurações para uma associação de segurança (SA), ou como os pacotes de dados são protegidos quando são passados entre dois terminais. Você especifica o grupo Diffie-Hellman na Fase 2 apenas quando seleciona Perfect Forward Secrecy (PFS).
O PFS torna as chaves mais seguras porque as novas chaves não são feitas a partir das chaves anteriores. Se uma chave for comprometida, as novas chaves de sessão ainda estarão seguras. Quando você especifica o PFS durante a Fase 2, uma troca Diffie-Hellman ocorre cada vez que um novo SA é negociado.
O grupo DH escolhido para a Fase 2 não precisa corresponder ao grupo escolhido para a Fase 1.
AH
Definido no RFC 2402, AH (Authentication Header) é um protocolo que você pode usar em negociações manuais de VPN de Fase 2 do BOVPN. Para fornecer segurança, o AH adiciona informações de autenticação ao datagrama IP. A maioria dos túneis VPN não usa AH porque não fornece criptografia.
ESP
Definido na RFC 2406, ESP (Encapsulating Security Payload) fornece autenticação e criptografia de dados. O ESP pega a carga original de um pacote de dados e a substitui por dados criptografados. Ele adiciona verificações de integridade para garantir que os dados não sejam alterados em trânsito e que tenham vindo da fonte adequada. Recomendamos que você use ESP nas negociações Fase 2 porque ESP é mais seguro do que AH. VPN móvel com IPSec sempre usa ESP.