Se sua empresa transmitir ou receber pela rede dados pessoais e outras informações confidenciais sujeitas a proteção de acordo com a lei, será necessário aplicar a criptografia de acordo com o GOST. Hoje, contaremos como introduzimos essa criptografia com base no S-Terra crypto-gateway (KS) em um dos clientes. Esta história será interessante para especialistas em segurança da informação, além de engenheiros, designers e arquitetos. Não vamos nos aprofundar nas nuances da configuração técnica neste post - vamos nos concentrar nos pontos principais da configuração básica. Uma quantidade enorme de documentação sobre a configuração dos daemons do SO Linux, na qual o banco de dados S-Terra se baseia, está disponível gratuitamente na Internet. A documentação de configuração do software proprietário da S-Terra também está disponível ao público no
portal do fabricante.
Algumas palavras sobre o projeto
A topologia de rede do cliente era típica - malha completa entre o centro e as filiais. Foi necessário introduzir a criptografia dos canais de troca de informações entre todos os sites, dos quais havia 8 partes.
Geralmente, nesses projetos, tudo é estático: nos gateways de criptografia (KS), as rotas estáticas são definidas para a rede local do site, as listas de endereços IP (ACLs) para criptografia são escritas. Entretanto, nesse caso, os sites não possuem gerenciamento centralizado e tudo pode acontecer dentro de suas redes locais: as redes podem ser adicionadas, excluídas e modificadas de todas as formas. Para evitar a reconfiguração de roteamento e ACLs para o KS ao alterar o endereçamento de redes locais nos sites, foi decidido usar o OSPF de encapsulamento dinâmico e roteamento dinâmico, que inclui todos os KS e a maioria dos roteadores do nível de núcleo da rede nos sites (em alguns sites, os administradores de infraestrutura preferem use SNAT na direção do KS nos roteadores do kernel).
O tunelamento GRE resolveu dois problemas:
1. Use na ACL para criptografia o endereço IP da interface KS externa, na qual todo o tráfego enviado para outros sites é encapsulado.
2. Organize túneis ptp entre os KS, que permitem configurar o roteamento dinâmico (no nosso caso, o provedor MPLS L3VPN é organizado entre os sites).
O cliente solicitou a implementação da criptografia como um serviço. Caso contrário, ele teria que não apenas oferecer suporte a gateways de criptografia ou terceirizar alguma organização, mas também monitorar independentemente o ciclo de vida dos certificados de criptografia, renová-los a tempo e instalar novos.
E agora o memorando em si - como e o que montamos
Nota de assunto do KII: configuramos um gateway criptográfico
Configuração básica de rede
Primeiro, lançamos um novo cache e entramos no console de administração. Você deve começar alterando a senha do administrador interno - o comando
change user password administrator . Em seguida, é necessário executar o procedimento de inicialização (o comando de
inicialização ) no processo em que os dados da licença são inseridos e o sensor de número aleatório (DSN) é inicializado.
Preste atenção! Quando o S-Terra KS é inicializado, é estabelecida uma política de segurança na qual as interfaces do Security Gateway não passam pacotes. Você deve criar sua própria política ou usar o
comando run csconf_mgr enable para ativar uma política de permissão predefinida.
Em seguida, você precisa configurar o endereçamento das interfaces externas e internas, bem como a rota padrão. É preferível trabalhar com a configuração de rede do cache e configurar a criptografia através do console do tipo Cisco. Este console foi projetado para inserir comandos semelhantes aos comandos do Cisco IOS. A configuração criada usando o console semelhante à Cisco, por sua vez, é convertida nos arquivos de configuração correspondentes com os quais os daemons do SO trabalham. Você pode acessar o console do tipo Cisco no console de administração com o comando
configure .
Altere as senhas do cscons do usuário interno e ative:
> ativar
Senha: csp (predefinida)
#configure terminal
#username privilégio cscons 15 secret 0 #enable secret 0 Defina a configuração básica da rede:
#interface GigabitEthernet0 / 0
#ip address 10.111.21.3 255.255.255.0
#no shutdown
#interface GigabitEthernet0 / 1
#ip address 192.168.2.5 255.255.255.252
#no shutdown
#ip route 0.0.0.0 0.0.0.0 10.111.21.254
GRE
Saímos do console do tipo Cisco e vamos para o shell debian com o comando
system Defina sua própria senha para o
usuário root com o comando
passwd .
Um túnel separado para cada site é configurado em cada KSh. A interface do túnel está configurada no arquivo
/ etc / network / interfaces . O utilitário de encapsulamento IP, que faz parte do conjunto predefinido de iproute2, é responsável por criar a própria interface. O comando para criar uma interface é gravado na opção pre-up.
Exemplo de configuração de uma interface de túnel típica:
auto site1
iface site1 inet static
endereço 192.168.1.4
máscara de rede 255.255.255.254
pré-up túnel ip adicionar modo site1 gre local 10.111.21.3 remoto 10.111.22.3 chave hfLYEg ^ vCh6p
Preste atenção! Note-se que as configurações da interface do túnel devem estar localizadas fora da seção
### netifcfg-begin ###
*****
### netifcfg-end ###
Caso contrário, essas configurações serão apagadas ao alterar as configurações de rede de interfaces físicas através do console semelhante à Cisco.
Roteamento dinâmico
No S-Terra, o roteamento dinâmico é implementado usando o pacote de software Quagga. Para configurar o OSPF, precisamos ativar e configurar os
daemons zebra e
ospfd . O daemon zebra é responsável pela interação entre os daemons de roteamento e o sistema operacional. O daemon ospfd, como o nome indica, é responsável pela implementação do protocolo OSPF.
O OSPF é configurado através do console daemon ou diretamente através do arquivo de configuração
/etc/quagga/ospfd.conf . Todas as interfaces físicas e de túnel envolvidas no roteamento dinâmico são adicionadas ao arquivo e são anunciadas redes que serão anunciadas e receberão anúncios.
Um exemplo de configuração para adicionar ao
ospfd.conf :
interface eth0
!
interface eth1
!
interface site1
!
interface site2
roteador ospf
ID do roteador ospf 192.168.2.21
área de rede 192.168.1.4/31 0.0.0.0
rede 192.168.1.16/31 área 0.0.0.0
área de rede 192.168.2.4/30 0.0.0.0
Nesse caso, os endereços 192.168.1.x / 31 são reservados para redes de encapsulamento ptp entre sites, os endereços 192.168.2.x / 30 são alocados para redes de trânsito entre o KS e os roteadores do kernel.
Preste atenção! Para reduzir a tabela de roteamento em instalações grandes, é possível filtrar o anúncio das redes de trânsito usando as construções de
mapa de rotas sem redistribuição conectada ou
redistribuída .
Depois de configurar os daemons, você precisa alterar o status de inicialização do daemon em
/ etc / quagga / daemons . Nas opções
zebra e
ospfd não há correção para sim. Execute o daemon quagga e defina sua execução automática ao iniciar o cache com o comando
update-rc.d quagga enable .
Se os túneis GRE e OSPF estiverem configurados corretamente, as rotas para a rede de outros sites deverão aparecer nos roteadores KS e kernel e, assim, surgirá a conectividade de rede entre redes locais.
Criptografamos o tráfego transmitido
Como já foi escrito, ao criptografar entre sites, geralmente especificamos os intervalos de endereços IP (ACLs) entre os quais o tráfego é criptografado: se os endereços de origem e destino se enquadram nesses intervalos, o tráfego entre eles é criptografado. No entanto, neste projeto, a estrutura é dinâmica e os endereços podem mudar. Como já configuramos o encapsulamento do GRE, podemos especificar endereços KS externos como os endereços de origem e destino para a criptografia de tráfego - porque para criptografia ocorre o tráfego já encapsulado pelo protocolo GRE. Em outras palavras, tudo o que entra no cache da rede local de um site para as redes anunciadas por outros sites é criptografado. E já em cada um dos sites qualquer encaminhamento pode ser realizado. Assim, com qualquer alteração nas redes locais, basta que o administrador modifique os anúncios que vão de sua rede para a direção da escola secundária, e ela ficará disponível para outros sites.
A criptografia no S-Terra KS é realizada usando o protocolo IPSec. Utilizamos o algoritmo Grasshopper de acordo com o GOST R 34.12-2015 e, para compatibilidade com versões mais antigas, o GOST 28147-89 pode ser usado. Tecnicamente, a autenticação pode ser realizada tanto em chaves predefinidas (PSKs) quanto em certificados. No entanto, em operação industrial, é necessário usar certificados emitidos de acordo com GOST R 34.10-2012.
O trabalho com certificados, contêineres e CRLs é realizado usando o utilitário
cert_mgr . Primeiro, usando o comando
cert_mgr create ,
você precisa
criar um contêiner de chave privada e uma solicitação de certificado, que será enviada ao Centro de Gerenciamento de Certificados. Depois de receber o certificado, ele deve ser importado com o comando
cert_mgr import junto com o certificado raiz da CA e da CRL (se usado). Você pode
verificar se todos os certificados e CRLs estão instalados com o comando
cert_mgr show .
Após a instalação bem-sucedida dos certificados, vá para o console semelhante à Cisco para configurar o IPSec.
Criamos uma política IKE que especifica os algoritmos e parâmetros desejados do canal seguro criado, que serão oferecidos ao parceiro para aprovação.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#authentication sign
#group vko2
#lifetime 3600
Esta política se aplica ao criar a primeira fase do IPSec. A conclusão bem-sucedida da primeira fase é o estabelecimento da SA (Security Association).
Em seguida, precisamos definir uma lista de endereços IP de origem e de destino (ACLs) para criptografia, formar um conjunto de transformações, criar um mapa criptográfico (mapa criptográfico) e vinculá-lo à interface externa do CAB.
Defina a ACL:
#ip site1 estendido da lista de acesso
#permit gre host 10.111.21.3 host 10.111.22.3
Um conjunto de transformações (assim como na primeira fase, usamos o algoritmo de criptografia Grasshopper usando o modo de simulação):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Crie um mapa criptográfico, especifique ACL, transforme o conjunto e o endereço do ponto:
#crypto map MAIN 100 ipsec-isakmp
#match address site1
#set conjunto de transformação GOST
#set peer 10.111.22.3
Anexamos o mapa criptográfico à interface externa do CABG:
#interface GigabitEthernet0 / 0
#ip address 10.111.21.3 255.255.255.0
#crypto map PRINCIPAL
Para criptografar canais com outros sites, você deve repetir o procedimento para criar ACLs e cartões de criptografia, alterando o nome do ACL, endereços IP e número do cartão de criptografia.
Preste atenção! Se a verificação do certificado CRL não for usada, isso deverá ser especificado explicitamente:
#crypto pki trustpoint s-terra_technological_trustpoint
# revocation-check none
Nesta configuração pode ser considerado completo. A saída dos comandos do console do tipo Cisco
mostra crypto isakmp sa e
show crypto ipsec sa deve refletir a primeira e a segunda fases construídas do IPSec. A mesma informação pode ser obtida usando o comando
sa_mgr show executado no shell debian. A saída do comando
cert_mgr show deve exibir certificados de site remoto. O status desses certificados será
remoto . Caso os túneis não sejam construídos, é necessário examinar o log do serviço VPN, armazenado no arquivo
/var/log/cspvpngate.log . Uma lista completa de arquivos de log com uma descrição de seu conteúdo está disponível na documentação.
Monitore a "integridade" do sistema
O S-Terra KS usa o daemon snmpd padrão para monitorar. Além dos parâmetros típicos do Linux, o S-Terra pronto para uso suporta a saída de túneis IPSec de acordo com CISCO-IPSEC-FLOW-MONITOR-MIB, que é o que usamos para monitorar o status dos túneis IPSec. A funcionalidade de OIDs personalizados também é suportada, fornecendo os resultados do script como valores. Esse recurso nos permite rastrear as datas de validade dos certificados. O script escrito analisa a saída do comando
cert_mgr show e, como resultado, fornece o número de dias antes da expiração dos certificados local e raiz. Essa técnica é indispensável ao administrar um grande número de CRM.
Qual é o cimus dessa criptografia
Toda a funcionalidade descrita acima é suportada KS S-Terra "pronto para uso". Ou seja, não era necessário instalar nenhum módulo adicional que pudesse afetar a certificação de gateways criptográficos e a certificação de todo o sistema de informação. Os canais entre sites podem ser quaisquer, mesmo através da Internet.
Devido ao fato de que, ao alterar a infraestrutura interna, não é necessário reconfigurar os gateways de criptografia, o
sistema funciona como um serviço , o que é muito conveniente para o cliente: ele pode colocar seus serviços (cliente e servidor) em qualquer endereço e todas as alterações são transferidas dinamicamente entre o equipamento de criptografia.
Obviamente, a criptografia devido à sobrecarga afeta a taxa de transferência de dados, mas não significativamente - a largura de banda do canal pode diminuir em um máximo de 5 a 10%. Além disso, a tecnologia foi testada e mostrou bons resultados, mesmo em canais de satélite, que são bastante instáveis e com baixa largura de banda.
Igor Vinokhodov, engenheiro da 2ª linha de administração da Rostelecom Solar