IPSec difícil com Linux

Desenvolvendo uma infraestrutura de TI, mais cedo ou mais tarde, a tarefa vem para integrar-se a qualquer serviço de uma grande organização. Pode ser, por exemplo, um banco ou uma operadora de telecomunicações. Como regra, as grandes organizações têm políticas de segurança da informação bem estabelecidas, que exigem, em particular, a implementação de um serviço com uma infraestrutura externa a eles através de canais criptografados - IPSec. Ao mesmo tempo, em pequenas organizações iniciantes , não há experiência na organização de tais esquemas e, a partir do equipamento, existe apenas VDS com Linux a bordo. Além disso, para minha surpresa, praticamente não há materiais no Runet descrevendo as ferramentas de solução de problemas do Linux. Vamos tentar eliminar essa lacuna e descrever a parte prática das configurações.

O esquema geral do serviço é apresentado abaixo. Como regra, nas grandes organizações tudo já está padronizado, colocado em operação, todos os tipos de criptografia possível e outras partes da rede são feitas em equipamentos separados (tsiska-junipers e outros como eles) e, mais importante, por indivíduos (talvez cada caixa azul no diagrama abaixo) servido por pessoas diferentes). Você tem uma máquina virtual com a qual o serviço será iniciado e o IPSec será organizado.



Observe que o próprio IPSec é organizado entre um endereço IP (no meu exemplo 10.0.255.1 <-> 10.0.1.1 ) e o próprio serviço é organizado entre outros ( 192.168.255.1<-> 192.168.1.1 ). Esses esquemas também são chamados de rede de rede IPSec .

Um exemplo simples é que você trabalha em uma empresa jovem, mas muito ambiciosa, SuperService , e precisa organizar a interação com a API fechada do MegaTelecom . Sua infraestrutura é um servidor VDS, sua infraestrutura de parceiro é um monte de equipamentos de rede e servidor. A tarefa é dividida em duas etapas:

1. Organizar o transporte (como a interoperabilidade ocorrerá).
2. Configure o serviço (execute aplicativos diretamente nos servidores).

Portanto, o gerente do SuperService decidiu organizar uma conexão com alguma organização grande para resolver um problema de negócios. Ele se voltou para a MegaTelecom , para a qual eles lhe enviaram especificações técnicas para a conexão. Uma dessas condições é o IPSec . Essa condição veio na forma de uma placa de excel , um exemplo do qual apresentei abaixo. Na imagem, destaquei parâmetros tecnicamente significativos em amarelo. O formato pode variar, mas a essência permanece a mesma.



Inicialmente, ele não é preenchido por sua parte, deve ser preenchido e enviado para aprovação do parceiro. Depois de concordar, você pode sentar e tentar ajustar sua máquina Linux.

Conceito IPSec

A seguir, apresentarei um pouco de teoria para pessoas que não estão familiarizadas com a tecnologia. Tudo o que descreverei se refere a Ethernet e IPv4 puros. Não vou entrar em criptografia, algoritmos de troca de chaves, mas focar na parte da rede.

IPSec - um conjunto de técnicas e protocolos para organizar uma conexão segura.

Diferente de outras tecnologias de encapsulamento (GRE, PPP, L2TP e até MPLS-TE), nenhuma interface de encapsulamento explícita é criada para o IPSec através do qual o tráfego pode ser roteado. Em vez disso, o IPSec fornece o conceito das chamadas Security Assotiations (SA) . SA é o túnel de um dispositivo de rede para outro. Mas não esqueça que o SA não é uma interface de rede no sentido normal da palavra, o roteamento clássico não funciona aqui. Em vez da tabela de roteamento, o conceito de Política de Segurança (SP) funciona aqui. Nós prescrevemos explicitamente algo como uma lista de acesso (ACL) para passar o tráfego por uma SA específica. Todas essas coisas são definidas na estrutura chamada ISAKMP .

ISAKMP - uma descrição dos procedimentos IPSec, na literatura eles chamam de estrutura. Ele descreve os termos SA, SP, SAD (banco de dados de associações de segurança), SPD (banco de dados de políticas de segurança), a necessidade de instalar túneis auxiliares ... O ISAKMP foi projetado para não depender de tecnologias de encapsulamento, algoritmos de autenticação e criptografia. Ele simplesmente introduz as definições necessárias.

IKE (v1 / 2) - protocolo de autenticação direta. Ele já implementa algoritmos de troca de chaves e sua aplicação.

Graças ao conceito da Cisco, ISAKMP e IKE agora são considerados sinônimos.

Antes de criptografar o tráfego, as partes devem concordar com os parâmetros (e chaves) dessa criptografia. Para fazer isso, um túnel auxiliar surge entre os dois lados (também é chamado de túnel ISAKMP), que opera o tempo todo. Esse túnel bidirecional é uma conexão UDP (por padrão na porta 500). Para organizar esse túnel auxiliar, as partes devem se autenticar (a senha deve corresponder). Isso é feito pelo protocolo IKEv1 / 2 (Internet Key Exchange) . E já no túnel organizado do ISAKMP , as partes concordam em criptografar diretamente o tráfego do usuário.

A própria organização IPSec é dividida em duas fases:

1. Criando um túnel auxiliar ISAKMP
2. Criando um túnel de dados do usuário

Como escrevi, no conceito IPSec (ou melhor, no conceito ISAKMP ), os túneis são chamados SA .

A primeira fase (organização ISAKMP SA) pode ser realizada de dois modos:

1. partes principais trocam alternadamente parâmetros de negociação. É considerado mais seguro, é usado para canais permanentes (nosso caso).
2. agressivo - em uma mensagem, o iniciador envia todos os parâmetros de coordenação necessários; é usado ao conectar um usuário remoto para uma sessão temporária (para torná-lo mais rápido).

Você deve entender que os principais túneis de SA são unidirecionais . Para transmissão de dados bidirecional pelo canal IPSec, deve haver dois túneis: origem (src) → receptor (dst) e vice-versa.

Em todos os métodos de criptografia, cabeçalhos adicionais são adicionados ao pacote IP original, o encapsulamento ocorre. Existem dois métodos para esse encapsulamento - AH (cabeçalho de autenticação) e ESP (carga de segurança de encapsulamento) . O AH autentica apenas o pacote (assinado digitalmente pelo remetente), o ESP e autentica (sinais) e criptografa. Hoje, o AH quase nunca é usado, tudo está embalado em ESP.

Você pode criptografar e autenticar o pacote IP de origem sem levar em consideração o cabeçalho IP (modo de transporte) ou com ele (modo de encapsulamento). O transporte é usado quando se planeja organizar seus túneis usando outras tecnologias (não o IPSec / ESP). Por exemplo, GRE, l2tp, ppp. Com o objetivo de conectar algum serviço à infraestrutura interna de uma grande organização, ele praticamente não é usado. Usei esse cenário para combinar vários escritórios em uma VPN por meio do IPSec. Estamos mais interessados ​​no modo de túnel . Como você pode ver na figura, um cabeçalho IP adicional é adicionado aqui.

A propósito, há um exemplo real do uso do encapsulamento AH. Suponha que tenhamos duas redes conectadas a roteadores diferentes. Os hosts devem transmitir informações com uma MTU de 1500 bytes sem fragmentação, mas temos uma seção intermediária que suporta apenas 1380 bytes. Toda a faixa é confiável. Podemos tirar vantagem do fato de o IPSec não criar interfaces de encapsulamento, no sentido clássico através do qual o tráfego não é roteado. Criaremos um túnel SA do tipo AH (não precisamos criptografar) e o tráfego será direcionado para ele. Somente pacotes IP externos (de acordo com cabeçalhos IP externos) serão fragmentados no tráfego, os internos serão remontados sem alterações.

Observe que o cabeçalho ESP aumenta antes do transporte TCP / UDP . Lembra que o campo IP possui um campo Protocolo? Com base nesse campo, o equipamento de rede (e os hosts finais) processam corretamente os pacotes IP. Portanto, para ESP, seu número é 50. Uma lista completa de protocolos para esse campo pode ser visualizada no wiki , e pode ser muito útil.

A ausência de um cabeçalho da camada de transporte (TCP / UDP / ICMP já está criptografado!) Impõe uma limitação em tecnologias como NAT. Lembre-se, o NAT com tradução de porta (sobrecarga, PAT, MASQARADE, tem muitos nomes) funciona com base nas portas do protocolo de transporte. E no túnel IPSec criptografado eles não são! Para superar esse problema, existe uma tecnologia como IPSec NAT-Traversal (NAT-T) . Durante a primeira fase, as partes concordam com o uso do NAT-T. Se os dois lados suportarem NAT-T (e mesmo nas mesmas portas UDP), o cabeçalho UDP será adicionado aos túneis resultantes para o tráfego, com os quais os pacotes já passarão por roteadores com conversão de endereço de rede.

O túnel em si não vai subir, é preciso direcionar o tráfego para lá. Como escrevi acima, as regras de roteamento não funcionam aqui, você precisa escrever Políticas de Segurança (SP) .

As políticas consistem no endereço de origem, endereço de destino, direção (entrada, saída, destino) e parâmetros do túnel do usuário (aqui o ESP será descrito apenas se será AH, versão de túnel ou transporte). É mais como organizar regras para o NAT. O NAT também não possui entradas de tabela de roteamento suficientes. E também são indicadas as regras onde, onde e como , e não onde e através do quê . E também com o movimento da mão errada, você pode bloquear toda a comunicação no servidor remoto.

Todas as manipulações IPSec adicionam cabeçalhos aéreos. Pelo menos eles comerão outros 40 bytes do pacote original. Assim, por exemplo, com uma MTU padrão para PPPoE de 1380 bytes de conexões, a MTU real será <1340.

IPSec no Linux

Vamos praticar usando o exemplo de distribuições DEB. Considerarei apenas o caso com autorização baseada em chave pré-compartilhada (PSK) ; configuraremos o esquema desde o início do artigo.

O próprio IPSec é suportado pelo kernel, mas esse suporte é muito limitado. Na verdade, os módulos vigorosos estão preocupados apenas com a criptografia e as chaves (processamento de pacotes) que já foram recebidas (transferidas para o kernel). E para passar para lá os parâmetros e regras com os quais você precisa processar o tráfego, precisa de um software separado. Como tal, existem várias soluções:

1. KAME migrou do BSD
2. xSWAN (strongswan, freeswan, libreswan, etc)
3. shorewall

Pareceu-me a versão mais simples (mais previsível) do KAME, e continuaremos a distorcer.

 # deb-       root@localhost: ~# apt-get install racoon ipsec-tools 

Tradicionalmente, o KAME consistia em dois componentes

1. O daemon de guaxinim para controlar o túnel ISAKMP .
2. Utilitários Setkey para gerenciar túneis SA com dados.

Vamos começar com o primeiro. Racoon é responsável pelas configurações de autorização do túnel em IKE. Este é um daemon, está configurado com um arquivo de configuração ( /etc/racoon.conf ), é iniciado por um script init regular ( /etc/init.d/racoon <start|stop|restart> ).



Como sempre, detalhes em man 5 racoon.conf

Em seguida, usaremos o utilitário setkey . Ele também inicia como um daemon ( /etc/init.d/setkey <start|stop|restart> ), mas na verdade ele executa o script /etc/ipsec-tools.conf . Como eu disse, ele já define cria túneis para o tráfego do usuário. Ou seja, define SA e SP para eles. Isto é algo como um mapa criptográfico no ASA. A opção mais fácil para nós é adicionar apenas SP. Em seguida, o SA será construído automaticamente com base nos parâmetros da segunda fase especificados nas configurações de guaxinim .

Mas é possível não usar os parâmetros da segunda fase do guaxinim , mas definir o SA através deste utilitário. Detalhes e sintaxe podem ser encontrados no man 8 setkey . Mas vou dar um exemplo da configuração mais simples.


Atualmente, o utilitário setkey é duplicado pelo módulo iproute2 .
Como parte disso, existem duas equipes de gerenciamento de registros SA e SP.

1. estado xfrm ip
2. política xfrm ip

Além de gerenciar esse utilitário, você pode ver o estado das SAs e SPs organizadas aplicadas ao tráfego. Mais detalhes em man 8 ip-xfrm .

Dê uma outra olhada no tablet original. Existem endereços IP diferentes para IPSec e serviço. O endereço IP interno está sendo filtrado dentro da infraestrutura da Megatelecom . Mas nós temos apenas uma máquina virtual. De algum modo, um endereço IP interno deve aparecer nele e os pacotes no túnel devem sair dele. Existem várias opções para alcançar esse cenário:

1. Uma rota estática sem detectar uma parada, mas com uma indicação explícita da interface de saída e do endereço IP.
2. Definindo rotas com base no roteamento baseado em políticas (PBR no Linux, aka regra de ip ).
3. Tradução de endereços ( NAT / MASQARADE ).

Do meu ponto de vista, a primeira opção é adequada aqui.

Podemos adicionar um endereço IP (secundário) adicional à nossa interface, embora seja melhor criar um alias para essa interface.
root@localhost: ~# ip addr add 192.168.1.1/32 dev eth1 label eth1:1
e configure a rota para o servidor Megatelecom a partir desse endereço IP.
root@localhost: ~# ip route add 192.168.255.1/32 dev eth1:1 src 192.168.1.1
Mas se você fizer isso, nada começará. O fato é que, ao adicionar uma rota neste formulário, a estação Linux tentará determinar o endereço MAC do destinatário, fará isso através do ARP ... O computador enviará solicitações de ARP Who has IP 192.168.255.1 . Como 192.168.255.1 não está na mesma rede que 192.168.1.1 (mask / 32!), Não haverá resposta para o ARP. Mas quando você tenta se conectar, No route to host será retornada do endereço IP local. Para derrotar isso, precisamos definir um registro ARP estático:
root@localhost: ~# arp -s 192.168.255.1 00:00:00:00:00:01 -i eth1:1
Tal vida hack. A propósito, essas manipulações podem não levar à operação correta da pilha IP do Linux. Em um dos casos, os comandos ip route não produziram o resultado desejado, foi necessário reiniciar a pilha de rede.

Verificação de integridade

Não se esqueça, o túnel só aumentará quando o tráfego entrar nele! É necessário iniciar o ping a partir de uma interface específica (endereço IP) antes do destino.
root@localhost: ~# ping -I 192.168.1.1 192.168.255.1
Com um pequeno atraso, deve haver respostas do lado inverso (a menos que o ICMP esteja fechado em qualquer lugar do site).

Podemos ver se o túnel ISAKMP aumentou.


Também podemos ver túneis com dados do usuário.


Pode ser útil no tcpdump examinar a lógica para estabelecer uma conexão. Aqui você também pode ver as fases do estabelecimento da conexão e do tráfego já transmitido criptografado para o ESP. Obviamente, existem técnicas para decifrá-lo, mas geralmente essa conclusão já é suficiente.

Ao conectar remotamente via SSH, para não produzir um monte de janelas, é conveniente executar o tcpdump em segundo plano:

root@localhost: ~# tcpdump -i eth1 -w ipsec.pcap esp &


Começamos ping, telnet, netcat ...

root@localhost: ~# killall tcpdump
root@localhost: ~# tcpdump -vr ipsec.pcap


Também nos logs, você pode ver o status de sucesso da conexão. Ele mostra o estabelecimento bem-sucedido de ambas as fases do IPSec.


Isso é tudo. Resta adicionar todas as manipulações necessárias à inicialização e você pode iniciar a integração de aplicativos.

PS: uma solicitação para relatar todos os erros ou imprecisões no artigo por mensagem pessoal. Quando eu ajustar o artigo, os comentários parecerão bobos.