Se a sua empresa transmite ou recebe dados pessoais e outras informações confidenciais que devem ser protegidas de acordo com a legislação, é necessário aplicar a criptografia conforme o padrão GOST. Hoje, vamos contar como implementamos essa criptografia com base no gateway criptográfico (GK) S-Terra em um dos clientes. Esta história será interessante para especialistas em segurança da informação, bem como para engenheiros, projetistas e arquitetos. Não iremos nos aprofundar nas nuances da configuração técnica neste post – vamos nos concentrar nos pontos-chave da configuração básica. Há uma enorme quantidade de documentação sobre a configuração de demônios do sistema operacional Linux, que serve de base para o GK S-Terra, disponível gratuitamente na internet. A documentação sobre a configuração do software proprietário S-Terra também está disponível publicamente em do fabricante.
Algumas palavras sobre o projeto
A topologia da rede do cliente era típica - full mesh entre o centro e as filiais. Era necessário implementar a criptografia dos canais de troca de informações entre todos os locais, que totalizavam 8.
Normalmente, em projetos semelhantes, tudo é estático: rotas estáticas na rede local dos GK são configuradas, listas de endereços IP (ACL) são especificadas para a criptografia. No entanto, neste caso, não há gerenciamento centralizado nos locais, e dentro de suas redes locais tudo pode acontecer: redes podem ser adicionadas, removidas e modificadas de diversas maneiras. Para evitar a necessidade de reconfigurar a roteamento e ACL nos GK com a alteração da endereçamento das redes locais, foi tomada a decisão de utilizar tunelamento GRE e roteamento dinâmico OSPF, no qual estão incluídos todos os GK e a maioria dos roteadores de núcleo nas filiais (em alguns locais, os administradores da infraestrutura preferiram usar SNAT em direção ao GK nos roteadores de núcleo).
O tunelamento GRE resolveu duas questões:
1. Usar no ACL para criptografia o endereço IP da interface externa do GK, na qual todo o tráfego que está sendo encapsulado é direcionado a outros locais.
2. Organizar túneis ponto-a-ponto entre os GKs, que permitem configurar o roteamento dinâmico (neste caso, foi configurado um MPLS L3VPN de provedor entre os locais).
O cliente solicitou a implementação de criptografia como serviço. Caso contrário, ele não apenas precisaria manter gateways de criptografia ou terceirizar para alguma organização, mas também monitorar o ciclo de vida dos certificados de criptografia, renovando-os a tempo e instalando novos.
Agora, o próprio lembrete – como e o que configuramos
Nota para o sujeito do KII: configuramos o gateway de criptografia
Configuração básica da rede
Primeiramente, iniciamos o novo GCE e acessamos o console de administração. Comece alterando a senha do administrador integrado – o comando change user password administrator. Em seguida, é necessário realizar o procedimento de inicialização (comando initialize) no qual são inseridos os dados da licença e o gerador de números aleatórios (GNA) é inicializado.
Atenção! Durante a inicialização do GCE S-Terra, é estabelecida uma política de segurança segundo a qual as interfaces do gateway de segurança não permitem o tráfego de pacotes. É necessário criar uma política própria ou, com o comando run csconf_mgr activate , executar a ativação da política de permissão pré-configurada.
A seguir, é necessário configurar os endereços das interfaces externas e internas, bem como a rota padrão. O trabalho com a configuração de rede do GCE e a configuração de criptografia deve ser preferencialmente realizado através do console Cisco-like. Este console foi projetado para inserir comandos semelhantes aos comandos Cisco IOS. A configuração formada por meio do console Cisco-like é, por sua vez, convertida em arquivos de configuração correspondentes, com os quais operam os demônios do sistema operacional. Para acessar o console Cisco-like a partir do console de administração, use o comando configure.
Mudamos as senhas do usuário integrado cscons e enable:
>enable
Password: csp (pré-configurado)
#configure terminal
#username cscons privilege 15 secret 0 #enable secret 0 Настраиваем базовую сетевую конфигурацию:
#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 Cisco-like e entramos no shell debian com o comando system. Definimos uma senha própria para o usuário root com o comando passwd.
Em cada GCE, configura-se um túnel separado para cada site. A configuração da interface do túnel é feita no arquivo /etc/network/interfaces. A criação da própria interface é responsabilidade da utilidade IP tunnel, que faz parte do pacote pré-instalado iproute2. O comando para criar a interface deve ser adicionado na opção pre-up.
Exemplo de configuração de uma interface de túnel típica:
auto site1
iface site1 inet static
address 192.168.1.4
netmask 255.255.255.254
pre-up ip tunnel add site1 mode gre local 10.111.21.3 remote 10.111.22.3 key hfLYEg^vCh6p
Atenção! É importante notar que as configurações das interfaces de túnel devem estar localizadas fora da seção
###netifcfg-begin###
*****
###netifcfg-end###
Caso contrário, essas configurações serão sobrescritas ao modificar as configurações das interfaces físicas através do console semelhante ao Cisco.
Roteamento dinâmico
No S-Terra, o roteamento dinâmico é implementado com o pacote de programas Quagga. Para configurar o OSPF, precisamos ativar e configurar os demônios zebra e ospfd. O daemon zebra é responsável pela interação entre os demônios de roteamento e o SO. O daemon ospfd, como o nome sugere, é responsável pela implementação do protocolo OSPF.
A configuração do OSPF pode ser feita através do console do daemon ou diretamente através do arquivo de configuração /etc/quagga/ospfd.conf. O arquivo deve incluir todas as interfaces físicas e de túnel envolvidas no roteamento dinâmico, e também declarar as redes que serão anunciadas e aceitar anúncios.
Exemplo de configuração que precisa ser adicionada ao ospfd.conf:
interface eth0
!
interface eth1
!
interface site1
!
interface site2
router ospf
ospf router-id 192.168.2.21
network 192.168.1.4/31 area 0.0.0.0
network 192.168.1.16/31 area 0.0.0.0
network 192.168.2.4/30 area 0.0.0.0
Neste caso, os endereços 192.168.1.x/31 são reservados para redes PTP de túnel entre locais, enquanto os endereços 192.168.2.x/30 são usados para redes de trânsito entre as centrais e os roteadores de núcleo.
Atenção! Para reduzir a tabela de roteamento em grandes instalações, é possível filtrar o anúncio das próprias redes de trânsito com as instruções no redistribute connected ou redistribute connected route-map.
Após configurar os demônios, é necessário alterar o status de inicialização dos demônios em /etc/quagga/daemons. Nas opções, substitua no por yes. Inicie o daemon quagga e configure para que inicie automaticamente ao dar boot na central com o comando zebra e ospfd update-rc.d quagga enable Se a configuração dos túneis GRE e do OSPF estiver correta, as rotas para as redes dos outros locais devem aparecer na central e nos roteadores de núcleo, criando assim conectividade entre as redes locais..
Criptografamos o tráfego transmitido
Codificamos o tráfego transmitido
Como já mencionado, normalmente, ao criptografar entre sites, indicamos intervalos de endereços IP (ACL) entre os quais o tráfego é criptografado: se os endereços de origem e destino estiverem dentro desses intervalos, o tráfego entre eles será criptografado. No entanto, neste projeto, a estrutura é dinâmica e os endereços podem mudar. Como já configuramos o tunelamento GRE, podemos usar endereços externos do CH como endereços de origem e destino para a criptografia do tráfego — pois o tráfego que chega já está encapsulado pelo protocolo GRE. Em outras palavras, tudo que chega ao CH da rede local de um site em direção às redes que foram anunciadas por outros sites é criptografado. E já dentro de cada um dos sites, qualquer redirecionamento pode ser realizado. Assim, com qualquer alteração nas redes locais, o administrador precisa apenas modificar os anúncios que vão de sua rede em direção ao CH, e este se tornará acessível para outros sites.
A criptografia no CH S-Terra é realizada através do protocolo IPSec. Utilizamos o algoritmo "Grasshopper" de acordo com o GOST R 34.12-2015, e para compatibilidade com versões antigas, pode-se aplicar o GOST 28147-89. A autenticação pode ser tecnicamente realizada tanto por chaves pré-definidas (PSK), quanto por certificados. No entanto, em aplicações industriais é necessário usar certificados emitidos segundo o GOST R 34.10-2012.
O trabalho com certificados, contêineres e CRL é realizado com a ferramenta cert_mgr. Primeiro, com o comando cert_mgr create , é necessário formar um contêiner de chave privada e uma solicitação de certificado, que será enviada ao Centro de Gerenciamento de Certificados. Após receber o certificado, ele deve ser importado junto com o certificado raiz da CA e o CRL (se utilizado) com o comando cert_mgr import. Para garantir que todos os certificados e CRL foram instalados, pode-se usar o comando cert_mgr show.
. Após a instalação bem-sucedida dos certificados, vamos para o console semelhante ao Cisco para configurar o IPSec.
Criamos uma política IKE, na qual especificamos os algoritmos e parâmetros desejados para o canal seguro que serão propostos ao parceiro para negociação.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#authentication sign
#group vko2
#lifetime 3600
Essa política é aplicada na construção da primeira fase do IPSec. O resultado bem-sucedido da primeira fase é o estabelecimento do SA (Associação de Segurança).
Em seguida, precisamos determinar a lista de endereços IP de origem e destino (ACL) para criptografia, formar um conjunto de transformações (transform set), criar um mapa criptográfico (crypto map) e vinculá-lo à interface externa do dispositivo.
Definindo a ACL:
#ip access-list extended site1
#permit gre host 10.111.21.3 host 10.111.22.3
Conjunto de transformações (como na primeira fase, usamos o algoritmo de criptografia "Grasshopper" utilizando o modo de produção de HMAC):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Criamos o mapa criptográfico, especificando a ACL, o conjunto de transformações e o endereço do peer:
#crypto map MAIN 100 ipsec-isakmp
#match address site1
#set transform-set GOST
#set peer 10.111.22.3
Vinculamos o mapa criptográfico à interface externa do dispositivo:
#interface GigabitEthernet0/0
#ip address 10.111.21.3 255.255.255.0
#crypto map MAIN
Para criptografar canais com outros locais, é necessário repetir o procedimento de criação da ACL e do mapa criptográfico, alterando o nome da ACL, os endereços IP e o número do mapa criptográfico.
Atenção! Caso não seja utilizada a verificação de certificados por CRL, isso deve ser especificado explicitamente:
#crypto pki trustpoint s-terra_technological_trustpoint
#revocation-check none
Com isso, a configuração pode ser considerada concluída. No resultado dos comandos do console estilo Cisco show crypto isakmp sa e show crypto ipsec sa deve refletir as fases um e dois do IPSec construídas. Essa mesma informação pode ser obtida usando o comando sa_mgr show, executado do shell Debian. Na saída do comando cert_mgr show devem aparecer os certificados dos locais remotos. O status desses certificados será remoto. Caso os túneis não sejam construídos, é necessário conferir o log VPN-do serviço, que é armazenado no arquivo /var/log/cspvpngate.log. Uma lista completa de arquivos de log, com a descrição de seu conteúdo, está disponível na documentação.
Monitorando a "saúde" do sistema
No dispositivo S-Terra, utiliza-se o daemon padrão snmpd para monitoramento. Além dos parâmetros típicos do Linux, o S-Terra "out-of-the-box" suporta a entrega de dados sobre túneis IPSec de acordo com o CISCO-IPSEC-FLOW-MONITOR-MIB, que utilizamos para rastrear o estado dos túneis IPSec. Funcionalidades de OIDs personalizados também são suportadas, retornando como valores os resultados da execução de scripts. Esta funcionalidade nos permite monitorar os prazos de expiração dos certificados. O script escrito analisa a saída do comando cert_mgr show e, como resultado, retorna a quantidade de dias até a expiração dos certificados local e raiz. Este método é indispensável na administração de um grande número de dispositivos.
Qual é a essência dessa criptografia?
Todo a funcionalidade descrita acima é suportada 'out of the box' pelo KSH S-Terra. Ou seja, não foi necessário instalar nenhum módulo adicional que pudesse afetar a certificação dos gateways criptográficos e a certificação de todo o sistema de informação. Os canais entre sites podem ser quaisquer, até mesmo pela internet.
Graças ao fato de que, ao mudar a infraestrutura interna, não é necessário reconfigurar os gateways criptográficos, o sistema opera como um serviço, o que é muito conveniente para o cliente: ele pode hospedar seus serviços (client-side e server-side) em quaisquer endereços, e todas as mudanças serão transmitidas dinamicamente entre o equipamento de criptografia.
Sem dúvida, a criptografia devido a sobrecargas (overhead) afeta a velocidade de transmissão de dados, mas de forma insignificante - a largura de banda do canal pode ser reduzida no máximo em 5 a 10%. Nesse sentido, a tecnologia foi testada e apresentou bons resultados mesmo em canais via satélite, que são bastante instáveis e possuem baixa largura de banda.
Igor Vinokhodov, engenheiro da 2ª linha de administração da 'Rostelecom-Solar'
Fonte: habr.com
