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 rekeying e configurar DPD de acordo com a função de cada lado. Se ambos os peers suportarem estes valores, AES256GCM16 com DH19 e PFS19 é um ponto de partida moderno. No entanto, os requisitos do fornecedor e do peer têm sempre prioridade.

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 contém os parâmetros de segurança comuns a Phase 1 e Phase 2. Um perfil pode ser atribuído a várias ligações. É precisamente por isso que um perfil de sistema ou de produção em utilização não deve ser alterado sem planeamento: a alteração pode afetar todos os túneis associados na próxima ligação ou no próximo rekey.

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. Assim, um problema de PFS ou rekey pode surgir apenas horas mais tarde, quando for necessário renovar a Child SA. A validação só fica concluída depois de se observar pelo menos um rekey sem interrupçã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. Mais propostas não são automaticamente melhores: aumentam a superfície de ataque e de erro e podem tornar os pacotes IKE suficientemente grandes para que a fragmentação se torne um problema.

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.

Perfil moderno para peers controlados

Se ambos os lados suportarem métodos atuais:

Key exchange: IKEv2
Phase 1: AES256GCM16, DH19
Phase 2: AES256GCM16, PFS19
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 não se seleciona um método Authentication adicional, como SHA2. GCM16 designa o Authentication Tag de 16 bytes, não uma encriptação de 16 bits.

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.

DH19 utiliza uma curva elíptica e oferece um bom equilíbrio entre nível de segurança, tamanho dos pacotes e carga de processamento. AES128GCM16 também é um método atual e não é automaticamente inseguro para um nível de segurança normal de 128 bits. A segurança global depende sempre do componente mais fraco do perfil.

Perfil de compatibilidade para sistemas atuais de outros fabricantes

Se o peer não suportar AES-GCM ou um grupo ECP, esta combinação é um ponto de partida com maior compatibilidade:

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

Neste caso, o AES funciona em modo CBC e, por isso, necessita da proteção de integridade separada SHA2 256. DH14 e PFS14 são opções de compatibilidade, não a variante moderna preferida quando ambos os peers suportam DH19.

Evitar em novos perfis

Em novos projetos já não se devem utilizar IKEv1, Aggressive Mode, DES, 3DES, Blowfish, MD5, SHA1 nem os grupos DH 1, 2 e 5. 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.

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.

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 as informações de autenticação são transmitidas com menor proteção.
Key negotiation tries: 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.
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: Deixar normalmente desativado. Ativar apenas se o benefício e o suporte em ambos os lados estiverem comprovados.
SHA2 with 96-bit truncation: Ativar apenas devido a um requisito de compatibilidade documentado, não como melhoria geral de segurança.

Use strict profile reduz fallbacks inesperados e pode ajudar quando as propostas IKE são 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.

O SFOS aceita valores entre 120 e 86400 segundos para Key Life, entre 30 e 999 segundos para Re-key Margin e entre 0 e 100 por cento para a randomização. Um valor formalmente permitido não é automaticamente adequado: a Margin tem de ser claramente inferior à Key Life e corresponder ao comportamento do peer.

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.

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.

A Phase 2-Key Life deve ser inferior à 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.

Filial ou Initiator: Re-initiate, para que a firewall tente imediatamente restabelecer a ligação após um DPD timeout.
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.

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 indica 86400 segundos para a IKE SA e 28800 segundos para a IPsec SA como referências comuns. A Sophos e os fornecedores cloud utilizam valores diferentes consoante a função e a plataforma. Estes números não constituem, por isso, um perfil SFOS universal.

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. O exemplo documentado da AWS utiliza na Sophos Firewall aproximadamente Phase 1 28000, Re-key Margin 360, randomização 50 e Phase 2 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.

Depois de estabelecer a ligação, o estado e as últimas mensagens IKE são verificados de forma exclusivamente informativa na Advanced Shell:

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 um rekey de Phase 2; só assim ficam realmente validados lifetimes, PFS e o comportamento de rekey.

Associação típica de erros:

O túnel permanece totalmente down: 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. Um rollback normal do perfil não requer alterações a services, bases de dados ou configurações da Advanced Shell.