Compreender e configurar perfis IPsec na Sophos Firewall

Um perfil IPsec determina com que segurança e em que condições é negociado um túnel IPsec. Define a versão IKE, a encriptação, a integridade, o grupo DH, PFS, lifetimes, rekeying e Dead Peer Detection. Se estes valores não corresponderem aos do peer, o túnel não fica ativo ou falha apenas num rekey posterior.

Recomendação breve para novas ligações Site-to-Site: utilizar IKEv2, disponibilizar apenas as propostas robustas realmente necessárias, ativar PFS e a renovação de chaves e configurar DPD de acordo com a função de cada lado. Se ambos os peers suportarem estas definições, AES256GCM16 com o grupo 19 (ecp256) para DH e PFS é o ponto de partida moderno da Avanet. Não é uma predefinição da Sophos nem uma recomendação geral do fabricante; prevalecem os requisitos do peer.

Este artigo explica o perfil. A ligação propriamente dita, com gateway, IDs, redes, regras, NAT e routing, é descrita em Configurar uma VPN IPsec Site-to-Site na Sophos Firewall. Se um túnel existente não estabelecer a ligação ou não transportar tráfego, consulte Troubleshooting de VPN IPsec na Sophos Firewall.

O que controla um perfil IPsec

O perfil reúne os parâmetros de segurança comuns a Phase 1 e Phase 2 e pode ser atribuído a várias ligações. Antes de qualquer alteração, deve verificar-se quais as ligações que o utilizam. Em vez de modificar diretamente um perfil de sistema ou de produção partilhado, deve cloná-lo e testar primeiro a cópia apenas com a ligação prevista.

Não fazem parte do perfil:

endereço público do peer ou FQDN
Preshared Key, certificado ou RSA Key
Local ID e Remote ID
redes locais e remotas ou Traffic Selectors
regras de firewall, NAT e routing
endereço XFRM, SD-WAN Route ou caminho de failover

Estes valores são configurados na ligação IPsec ou nas regras de rede correspondentes. Por isso, um estado verde em Phase 1 não confirma que Phase 2 esteja correta nem que o tráfego útil seja encaminhado e permitido corretamente.

Authentication não é o mesmo que Authentication type

Num perfil IPsec, Authentication designa o algoritmo de integridade, como SHA2 256. Na ligação IPsec, Authentication type determina se os peers se autenticam com Preshared Key, certificado ou RSA Key.

Estes dois campos têm funções diferentes. Um SHA2 256 correto não resolve um PSK incorreto, e um certificado adequado não compensa uma proposta incompatível em Phase 1.

Compreender Phase 1 e Phase 2

Phase 1 estabelece a IKE Security Association protegida. Através deste canal de controlo, os peers autenticam-se e negociam outras chaves e parâmetros. Para isso, têm de ser compatíveis pelo menos a versão IKE, a encriptação, a integridade e o grupo DH.

Phase 2 cria as Child ou IPsec Security Associations para o tráfego útil. Nesta fase aplicam-se a encriptação de Phase 2, a integridade, PFS e os Traffic Selectors. Por isso, um túnel pode concluir Phase 1 com êxito sem criar uma Child SA devido a um valor PFS incorreto ou a uma combinação diferente em Phase 2.

Com IKEv2, a primeira Child SA pode ser criada juntamente com a IKE SA. Consoante o peer, um problema de PFS ou de renovação pode, por isso, surgir apenas quando a Child SA for renovada através de CREATE_CHILD_SA. A Avanet recomenda observar pelo menos uma renovação de Phase 2 durante os testes de aceitação.

Alinhar os parâmetros com o peer

Antes da configuração, os administradores de ambos os lados devem acordar os valores por escrito. Uma captura de ecrã muitas vezes não é suficiente, porque os fabricantes usam nomes diferentes para a mesma função.

É necessário documentar, no mínimo:

função: Initiator, Responder ou estabelecimento por ambos os lados
versão IKE e, com IKEv1, Main ou Aggressive Mode
Phase 1-Encryption, Authentication e grupo DH
Phase 1-Key Life, Re-key Margin e randomização
Phase 2-Encryption, Authentication, PFS e Key Life
rekeying baseado em tempo e o lado que o inicia
intervalo DPD e ação quando o peer não responde
limitações conhecidas do fornecedor e propostas permitidas

O nome do perfil não tem de ser igual nos dois dispositivos. O importante é que pelo menos uma combinação completa seja compatível em ambos os lados. Propostas desnecessárias dificultam o alinhamento e podem aumentar inutilmente os pacotes IKE. O impacto específico do problema conhecido NC-136352 no SFOS é explicado abaixo, nos campos de Phase 1.

Escolher uma configuração inicial segura

Os exemplos seguintes são pontos de partida da Avanet para novas ligações Site-to-Site. Não substituem os requisitos do Azure, da AWS, de um operador ou de uma firewall de outro fabricante. Mostram deliberadamente apenas a seleção de propostas e funções, não um perfil completo: os tempos de vida, a Re-key Margin, o intervalo e a ação DPD dependem do peer e da função de Initiator ou Responder.

Perfil moderno para peers controlados

Se ambos os lados suportarem métodos atuais:

Key exchange: IKEv2
Phase 1: AES256GCM16, 19 (ecp256)
Phase 2: AES256GCM16, 19 (ecp256)
Re-key connection: On
Use strict profile: On
Compression: Off
SHA2 96-bit truncation: Off
Dead peer detection: On

AES256GCM16 é um método AEAD: encripta e protege a integridade num só passo. Nesta combinação, o SFOS não seleciona um algoritmo Authentication adicional, como SHA2.

A Pseudo-Random Function para gerar as chaves IKE não pode ser selecionada separadamente no SFOS. A firewall deriva-a dos métodos de integridade disponibilizados e negoceia-a com o peer.

O grupo 19 (ecp256) utiliza uma curva elíptica. Para peers atuais e controlados, a Avanet prefere-o aos grupos MODP mais antigos. AES128GCM16 é igualmente um método atual. A política criptográfica aplicável e o componente mais fraco do perfil determinam a combinação admissível.

Perfil de compatibilidade sem AES-GCM ou ECP

Se o peer não suportar AES-GCM ou não suportar um grupo ECP, a Avanet utiliza esta combinação mais difundida como ponto de partida compatível:

Key exchange: IKEv2
Phase 1: AES256, SHA2 256, DH14
Phase 2: AES256, SHA2 256, PFS14
Re-key connection: On
Dead peer detection: On

Ao contrário das entradas AES-GCM, no SFOS o AES256 é configurado com o algoritmo Authentication separado SHA2 256. DH14 e PFS14 são opções de compatibilidade da Avanet, não a variante moderna preferida quando ambos os peers suportam o grupo 19 (ecp256).

Evitar em novos perfis

O DES não consta da lista de algoritmos IPsec suportados no SFOS 22. IKEv1, Aggressive Mode, 3DES, Blowfish, MD5, SHA1 e os grupos DH 1, 2 e 5 continuam selecionáveis, mas não devem ser utilizados em perfis novos. PFS: None também deve permanecer apenas como exceção documentada para peers que não suportem PFS.

Apesar de aparecer no campo Encryption de Phase 2, AES-GMAC não é encriptação: fornece apenas autenticação e integridade. Num túnel Site-to-Site normal que exija confidencialidade, deve utilizar-se AES-GCM ou AES com um método SHA2 adequado.

No SFOS 22 e 23, as opções documentadas dependem da versão IKE e da fase:

AES128GCM16, AES192GCM16 e AES256GCM16: em Phase 1 de IKEv2 e em Phase 2 de ambas as versões IKE, não em Phase 1 de IKEv1.
AES128GMAC, AES192GMAC e AES256GMAC: apenas em Phase 2 de ambas as versões IKE, não em Phase 1.
TwoFish e Serpent: em Phase 1 e Phase 2 de IKEv1, não de IKEv2.

São algoritmos selecionáveis, não combinações associadas a grupos DH ou algoritmos de hash específicos, nem recomendações para perfis novos.

As exceções legacy devem ser documentadas com o motivo, o peer afetado, o risco, o owner e a data prevista para a substituição. Uma combinação fraca não deve permanecer ao lado de propostas robustas apenas porque o túnel também estabelece ligação com ela. Como orientação técnica podem consultar-se a BSI TR-02102-3 sobre IPsec e IKEv2 e o NIST Guide to IPsec VPNs.

Quando um ambiente tem de cumprir requisitos criptográficos formais, o procedimento dedicado explica como o modo FIPS 140-3 na Sophos Firewall afeta plataformas, perfis, certificados, backups e HA. A conformidade FIPS não substitui a escolha consciente de uma proposal moderna e comum.

Limites da documentação antiga da API VPNProfile

Ao automatizar perfis, não se deve tratar a documentação XML antiga de Add VPN Policy / Edit VPN Policy (VPNProfile) como uma tradução direta deste guia da interface. Em KeyingMethod, distingue entre Automatic e Manual. O ramo manual com LocalSPI, RemoteSPI e chaves de encriptação e autenticação de entrada/saída é uma variante legacy distinta de gestão de chaves: estas chaves não são campos PSK da ligação IPsec nem uma receita alternativa para o exemplo moderno de IKEv2. O antigo exemplo DES/MD5 e a lista de algoritmos não comprovam nem o suporte atual nem a aprovação para perfis novos.

A descrição da API para SFOS 22 e 23 também contém contradições que têm de ser esclarecidas para a compilação específica antes da automatização:

PerfectForwardSecrecy indica Enable como predefinição, mas a lista de valores permitidos admite apenas y/n e o campo está ausente do exemplo XML. Isto não permite deduzir uma serialização fiável; não se deve simplesmente converter Enable em y.
PFSGroup apresenta SameAsPhase1 no exemplo, mas SameasPhase-I na lista de valores permitidos. Não se deve deduzir a grafia a partir da etiqueta da interface nem tratar os dois literais como intercambiáveis.
AuthenticationAlgorithm1 está marcado como obrigatório em ambas as fases, embora a lista Encryption inclua GCM. Isto não esclarece o caso AEAD na API: não se deve forçar um hash adicional com GCM apenas para preencher o campo obrigatório.
KeyLife é definido como um inteiro em segundos, enquanto o exemplo contém 3600 seconds. Não se deve serializar o sufixo textual como parte do valor da API.

Até estes detalhes da API serem esclarecidos para a compilação instalada, o procedimento suportado na interface em Profiles > IPsec profiles continua a ser a via segura. Mantêm-se as propostas robustas, a clonagem antes das alterações, a verificação após uma renovação e a reposição do perfil anterior documentado. Não é fornecido aqui nenhum payload XML executável para os campos contraditórios.

Eliminar um perfil: verificar o nome e conhecer os limites

O resumo da API antiga inclui Delete VPN Policy além de Add/Edit. Esta tarefa visa o perfil IPsec identificado pelo nome, não a desconexão de uma ligação VPN. A descrição de Delete para SFOS 22 e 23 exige Name como parâmetro obrigatório do tipo SCALAR e tipo de dados STRING; as palavras do nome podem ser separadas por espaços. Trata-se do nome do perfil a eliminar, não do endereço do peer nem do nome da ligação.

Antes de eliminar um perfil, deve verificar-se o nome exato e todas as atribuições, incluindo Site-to-Site, Remote Access e L2TP. Os valores e as atribuições atuais devem ser documentados para permitir planear uma recuperação. Se o perfil ainda estiver em uso ou as atribuições não forem claras, não se elimina; primeiro esclarece-se a migração prevista das ligações afetadas. Não se elimina um perfil apenas para desligar um túnel ou reverter uma alteração de perfil mal sucedida: continua a aplicar-se o procedimento de recuperação descrito acima, através do perfil anterior.

A documentação sucinta de Delete não fornece um pedido XML completo e executável nem explica como a firewall trata perfis ainda em uso ou qual o efeito da eliminação nas ligações ativas. Enumera 200 e 500, mas o texto disponível não contém os textos das mensagens. Não se deduzem daí respostas concretas nem regras de sucesso, erro ou dependências. A eliminação automatizada permanece, por isso, suspensa até se esclarecerem o formato do pedido e o comportamento para a compilação instalada; não é fornecido aqui nenhum payload Delete.

Clonar ou criar um perfil

Caminho do menu:

Profiles > IPsec profiles

Para ligações entre firewalls Sophos, os perfis de sistema emparelhados são um modelo claro:

Branch office (IKEv2) para a filial que inicia a ligação
Head office (IKEv2) para a sede que responde

O perfil adequado é clonado e recebe um nome inequívoco, por exemplo Branch-Zurich-IKEv2. Assim, o perfil de sistema permanece inalterado e, num rollback, o perfil anterior pode voltar a ser atribuído ao túnel existente.

General settings

Key exchange: Para novas ligações Site-to-Site, IKEv2. IKEv1 apenas para um peer legacy devidamente comprovado.
Authentication mode: Existe apenas com IKEv1. Não se utiliza Aggressive Mode porque, segundo a Sophos, as informações de autenticação são transmitidas em texto simples.
Key negotiation tries: Este campo define o número de tentativas de negociação da troca de chaves do túnel antes de a firewall parar. A Sophos recomenda 0. No entanto, num grupo de failover VPN, o SFOS define o valor efetivo como 3.
Re-key connection: Ativar para que sejam negociadas novas chaves de Phase 1 e Phase 2 antes de as atuais expirarem. O SFOS suporta apenas rekeying baseado em tempo. Desativar esta opção impede a firewall local de iniciar a renovação, mas esta pode continuar a responder a pedidos de renovação do peer. O peer tem então de iniciar a renovação; o rekeying mantém-se ativado em pelo menos um dos lados.
Use strict profile: Ativar quando as propostas do peer são conhecidas com exatidão. O SFOS disponibiliza então apenas os parâmetros configurados. Nos perfis de fornecedores, deve verificar-se primeiro a respetiva especificação; por exemplo, a opção não é utilizada no exemplo oficial da AWS.
Pass data in compressed format: A Avanet deixa normalmente esta opção desativada. Só deve ser ativada se o peer suportar IPComp e a poupança de largura de banda justificar a complexidade adicional.
SHA2 with 96-bit truncation: Esta opção encurta os valores de hash HMAC de autenticação. Ativar apenas devido a um requisito de compatibilidade documentado, não como melhoria geral de segurança.

Use strict profile exclui da troca IKE os valores predefinidos do sistema que não estejam configurados e pode ajudar com propostas IKE demasiado grandes. No entanto, não é uma opção que deva ser ativada indiscriminadamente em todos os perfis de fornecedores.

Phase 1

Phase 1 inclui Key life, Re-key margin, Randomize re-keying margin by, o grupo DH e até três pares de Encryption e Authentication. Introduzir aqui Key life e Re-key margin em segundos. Em Aggressive Mode só é possível guardar uma combinação Encryption/Authentication por fase; o aviso contra este modo mantém-se válido.

Não se deve escolher simplesmente o maior valor aceite pelo campo. A Re-key Margin tem de ser claramente mais curta do que a Key Life e corresponder ao comportamento do peer; a randomização altera apenas esta margem.

Devem ser introduzidos apenas os grupos DH e as propostas realmente necessários. O problema conhecido NC-136352 pode ocorrer quando um perfil IKEv2 predefinido disponibiliza tantos grupos DH que o pacote IKE ultrapassa 1 500 bytes. Se um componente intermédio descartar fragmentos, o Initiator continua a enviar enquanto o Responder não recebe nada. Para um peer conhecido, um único grupo DH confirmado é a configuração mais clara.

Phase 2

Phase 2 inclui PFS, Key Life, Encryption e Authentication para o tráfego útil. Esta fase também permite até três combinações Encryption/Authentication. Introduzir a sua própria Key life de Phase 2 em segundos. As definições de rekeying configuradas em Phase 1, incluindo margem e randomização, também determinam os tempos de renovação de Phase 2; Phase 2 conserva, no entanto, a sua própria Key Life.

PFS obriga a uma nova troca de chaves DH durante o rekey de Phase 2. Se uma chave de longo prazo for comprometida posteriormente, as sessões antigas gravadas não deverão poder ser desencriptadas com o mesmo material de chave. Por isso, PFS deve ser ativado e escolhido de acordo com o peer. Nos perfis modernos, o grupo PFS corresponde frequentemente ao grupo DH de Phase 1.

Em Use PFS group, Same as phase 1 utiliza os grupos DH selecionados em Phase 1 para a negociação de Phase 2. Selecionar um grupo explícito define diretamente o grupo DH de Phase 2; None desativa PFS. Herdar os mesmos grupos não significa que PFS exija um número de grupo diferente.

A Sophos recomenda que a Phase 2-Key Life seja mais curta do que a Phase 1-Key Life. Desta forma, as chaves do tráfego útil são renovadas com maior frequência do que as do canal de controlo IKE.

Dead Peer Detection

DPD deteta um peer que deixou de responder. Não substitui Gateway Monitoring nem um teste real de aplicação. Se o túnel de Phase 2 tiver permanecido inativo, DPD verifica a disponibilidade do peer antes de enviar dados.

Filial ou Initiator: Re-initiate, para que a firewall tente imediatamente restabelecer a ligação após um DPD timeout. O número de tentativas de Re-initiate depende de Key negotiation tries.
Sede ou Responder: Disconnect, para fechar a ligação desatualizada. Hold é uma alternativa deliberada quando os Traffic Selectors devem ser mantidos e só devem voltar a ser negociados quando surgir novo tráfego.
Check peer after every: intervalo de verificação em segundos.
Wait for response up to: Funciona apenas com IKEv1. Com IKEv2, o SFOS utiliza o IKE retransmission timeout interno; o valor introduzido não altera este comportamento. Com IKEv1, o número de verificações depende do tempo de resposta configurado aqui.

Nos grupos de failover IPsec, o SFOS desativa DPD nas ligações atribuídas e define Key negotiation tries como 3. Nesse caso, a condição do grupo assume a monitorização. O guia associado explica a ordem, Failover condition e Automatic failback; a vista do perfil, por si só, não mostra todo o comportamento efetivo de failover.

Interpretar corretamente lifetimes e rekeying

Key life não é um timeout de sessão ou inatividade. Limita a duração de uma Security Association. Antes de expirar, a negociação de novas chaves começa dentro da Re-key Margin.

Lifetimes mais curtas renovam as chaves com maior frequência, mas causam mais carga de processamento e mais oportunidades para erros de interoperabilidade ou rekey. Lifetimes mais longas reduzem esse esforço, mas utilizam o material de chave durante mais tempo. Por isso, nem o valor permitido mais curto nem o mais longo é automaticamente a melhor opção.

O NIST SP 800-77r1 recomenda 24 horas para a IKE SA e 8 horas para a IPsec SA. Estas são recomendações do NIST independentes do fabricante, não valores predefinidos do SFOS. A Sophos e os fornecedores cloud utilizam outros valores consoante a função e a plataforma.

A Sophos recomenda o seguinte para evitar colisões de rekey:

A Key Life do Initiator é inferior à do Responder.
A Phase 2-Key Life é inferior à Phase 1-Key Life em ambas as firewalls.
O rekeying está ativado em pelo menos um dos lados e, em equipamentos de outros fabricantes, está explicitamente configurado como baseado em tempo.

A randomização altera a Re-key Margin, não a Key Life completa. Com oito horas de Key Life, dez minutos de Margin e 20 por cento de randomização, segundo a Sophos, o rekey começa entre as 7 horas e 48 minutos e as 7 horas e 52 minutos.

Para fornecedores, devem ser adotados os valores exatos definidos por estes. Na Sophos Firewall, o exemplo documentado da AWS utiliza uma Key Life de Phase 1 de 28000, uma Re-key Margin de 360 e randomização de 50 por cento; Phase 2 utiliza 3600 segundos. Trata-se de um exemplo da AWS, não de uma predefinição geral da Avanet.

Atribuir o perfil e testá-lo em segurança

Durante uma janela de manutenção, o novo perfil é primeiro atribuído apenas à ligação prevista. Antes disso, devem ser documentados o nome do perfil, os valores anteriores e o rollback.

Para Site-to-Site, a atribuição é efetuada em:

Site-to-site VPN > IPsec

O Remote Access IPsec também utiliza perfis, mas tem outras limitações: a configuração atual do Sophos Connect aceita perfis IKEv1 com DPD desativado ou Disconnect. Por isso, o perfil moderno IKEv2 para Site-to-Site não deve ser reutilizado em Remote Access sem verificação. O procedimento completo está descrito em Configurar o Sophos Connect na Sophos Firewall. O caso específico de OTP/rekey está documentado em Sophos Connect termina a ligação após cerca de quatro horas.

Os perfis também se aplicam em Remote access VPN > L2TP. L2TP utiliza Preshared Key ou certificado digital e não suporta IKEv2. Por isso, o ponto de partida moderno Site-to-Site não pode ser aplicado a L2TP.

Depois de estabelecer a ligação, a Avanet utiliza na Advanced Shell apenas os seguintes comandos de leitura para verificar o estado e as últimas mensagens IKE:

ipsec statusall
tail -n 200 /log/strongswan.log

Em seguida, deve gerar-se tráfego real nos dois sentidos. Os contadores de bytes da Child SA têm de aumentar. O teste deve ser repetido depois de pelo menos uma renovação de Phase 2. Só esta etapa adicional da aceitação Avanet valida também os tempos de vida, PFS e o comportamento da renovação.

Associação típica de erros:

O túnel não chega a ser estabelecido: verificar versão IKE, Phase 1-Encryption, Authentication, DH, Strict Profile, ID e autenticação do peer.
NO_PROPOSAL_CHOSEN antes de Phase 1: comparar as propostas de Phase 1.
Phase 1 está ativa, mas não existe Child SA: verificar Phase 2-Encryption, Authentication, PFS e Traffic Selectors.
Interrupção após um período semelhante: comparar Key Life, Re-key Margin, randomização e os valores de Initiator/Responder.
O túnel está verde, mas não há tráfego: não alterar primeiro o perfil; verificar regras de firewall, NAT, routing, caminho de retorno e contadores de bytes.

Se a alteração causar problemas, o perfil anterior documentado deve voltar a ser atribuído à ligação. Esta reposição não requer alterações na Advanced Shell.