Se sua empresa transmite ou recebe dados pessoais e outras informações confidenciais pela rede que estão sujeitas a proteção de acordo com a lei, é necessário o uso de criptografia GOST. Hoje contaremos como implementamos essa criptografia baseada no gateway criptográfico S-Terra (CS) em um dos clientes. Esta história será do interesse de especialistas em segurança da informação, bem como de engenheiros, designers e arquitetos. Não vamos nos aprofundar nas nuances da configuração técnica neste post; vamos nos concentrar nos pontos-chave da configuração básica. Enormes volumes de documentação sobre a configuração de daemons do sistema operacional Linux, nos quais o S-Terra CS é baseado, estão disponíveis gratuitamente na Internet. A documentação para configurar o software proprietário S-Terra também está disponível publicamente em fabricante.
Algumas palavras sobre o projeto
A topologia de rede do cliente era padrão – full mesh entre centro e filiais. Foi necessário introduzir criptografia nos canais de troca de informações entre todos os sites, dos quais eram 8.
Normalmente, nesses projetos, tudo é estático: rotas estáticas para a rede local do site são definidas em gateways criptográficos (CGs), listas de endereços IP (ACLs) são registradas para criptografia. Porém, neste caso, os sites não têm controle centralizado e tudo pode acontecer dentro de suas redes locais: redes podem ser adicionadas, excluídas e modificadas de todas as formas possíveis. Para evitar a reconfiguração do roteamento e ACL no KS ao alterar o endereçamento das redes locais nos sites, foi decidido usar o tunelamento GRE e o roteamento dinâmico OSPF, que inclui todos os KS e a maioria dos roteadores no nível do núcleo da rede nos sites ( em alguns sites, os administradores de infraestrutura preferem usar SNAT em vez de KS em roteadores de kernel).
O tunelamento GRE nos permitiu resolver dois problemas:
1. Utilize o endereço IP da interface externa do CS para criptografia na ACL, que encapsula todo o tráfego enviado para outros sites.
2. Organize túneis ptp entre CSs, que permitem configurar o roteamento dinâmico (no nosso caso, o MPLS L3VPN do provedor é organizado entre os sites).
O cliente solicitou a implementação da criptografia como serviço. Caso contrário, ele teria que não apenas manter gateways criptográficos ou terceirizá-los para alguma organização, mas também monitorar de forma independente o ciclo de vida dos certificados de criptografia, renová-los dentro do prazo e instalar novos.
E agora o memorando real - como e o que configuramos
Nota ao assunto CII: configurando um crypto gateway
Configuração básica de rede
Em primeiro lugar, lançamos um novo CS e entramos no console de administração. Você deve começar alterando a senha do administrador integrada - comando alterar senha do usuário administrador. Então você precisa realizar o procedimento de inicialização (comando inicializar) durante o qual os dados da licença são inseridos e o sensor de números aleatórios (RNS) é inicializado.
Preste atenção! Quando o S-Terra CC é inicializado, é estabelecida uma política de segurança na qual as interfaces do gateway de segurança não permitem a passagem de pacotes. Você deve criar sua própria política ou usar o comando execute csconf_mgr ativar ativar uma política de permissão predefinida.
A seguir, é necessário configurar o endereçamento das interfaces externas e internas, bem como a rota padrão. É preferível trabalhar com a configuração da rede CS e configurar a criptografia através de um console tipo Cisco. Este console foi projetado para inserir comandos semelhantes aos comandos do Cisco IOS. A configuração gerada usando o console do tipo Cisco é, por sua vez, convertida nos arquivos de configuração correspondentes com os quais os daemons do sistema operacional funcionam. Você pode acessar o console semelhante ao Cisco no console de administração com o comando configurar.
Altere as senhas do usuário integrado cscons e habilite:
>ativar
Senha: csp (pré-instalada)
#configurar terminal
#username cscons privilégio 15 segredo 0 #enable segredo 0 Definindo a configuração básica da rede:
#interfaceGigabitEthernet0/0
#endereço IP 10.111.21.3 255.255.255.0
#sem desligamento
#interfaceGigabitEthernet0/1
#endereço IP 192.168.2.5 255.255.255.252
#sem desligamento
#ip rota 0.0.0.0 0.0.0.0 10.111.21.254
GRE
Saia do console tipo Cisco e vá para o shell debian com o comando .. Defina sua própria senha para o usuário raiz a equipe passwd.
Em cada sala de controle, um túnel separado é configurado para cada local. A interface do túnel está configurada no arquivo / etc / network / interfaces. O utilitário de túnel IP, incluído no conjunto iproute2 pré-instalado, é responsável pela criação da própria interface. O comando de criação de interface está escrito na opção pré-up.
Exemplo de configuração de uma interface de túnel típica:
site automático1
iface site1 inet estático
endereço 192.168.1.4
máscara de rede 255.255.255.254
túnel ip pré-up adicionar modo site1 gre local 10.111.21.3 remoto 10.111.22.3 chave hfLYEg^vCh6p
Preste atenção! Deve-se observar 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 substituídas ao alterar as configurações de rede das interfaces físicas por meio de um console semelhante ao Cisco.
Roteamento dinâmico
No S-Terra, o roteamento dinâmico é implementado usando o pacote de software Quagga. Para configurar o OSPF precisamos habilitar e configurar daemons zebra и ospfd. O daemon zebra é responsável pela comunicação entre os daemons de roteamento e o sistema operacional. O daemon ospfd, como o nome sugere, é responsável pela implementação do protocolo OSPF.
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 que participam do roteamento dinâmico são adicionadas ao arquivo, e as redes que serão anunciadas e receberão anúncios também são declaradas.
Um exemplo da configuração que precisa ser adicionada ao ospfd.conf:
interface eth0
!
interface eth1
!
interface site1
!
interface site2
roteador ospf
ID do roteador ospf 192.168.2.21
rede 192.168.1.4/31 área 0.0.0.0
rede 192.168.1.16/31 área 0.0.0.0
rede 192.168.2.4/30 área 0.0.0.0
Neste caso, os endereços 192.168.1.x/31 são reservados para redes ptp de túnel entre sites, os endereços 192.168.2.x/30 são alocados para redes de trânsito entre CS e roteadores de kernel.
Preste atenção! Para reduzir a tabela de roteamento em grandes instalações, você pode filtrar o anúncio das próprias redes de trânsito usando as construções nenhuma redistribuição conectada ou redistribuir mapa de rotas conectado.
Depois de configurar os daemons, você precisa alterar o status de inicialização dos daemons em /etc/quagga/daemons. Em opções zebra и ospfd nenhuma mudança para sim. Inicie o daemon quagga e configure-o para execução automática ao iniciar o comando KS update-rc.d quagga ativar.
Se a configuração dos túneis GRE e OSPF for feita corretamente, então as rotas na rede de outros sites deverão aparecer no KSh e nos roteadores centrais e, assim, surge a conectividade de rede entre as redes locais.
Criptografamos o tráfego transmitido
Como já foi escrito, geralmente ao criptografar entre sites, especificamos intervalos de endereços IP (ACLs) 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. Porém, neste projeto a estrutura é dinâmica e os endereços podem mudar. Como já configuramos o tunelamento GRE, podemos especificar endereços KS externos como endereços de origem e destino para criptografia de tráfego - afinal, o tráfego que já está encapsulado pelo protocolo GRE é recebido para criptografia. Em outras palavras, tudo o que entra no CS da rede local de um site para redes que foram anunciadas por outros sites é criptografado. E dentro de cada um dos sites qualquer redirecionamento pode ser realizado. Assim, caso haja alguma alteração nas redes locais, o administrador só precisa modificar os anúncios vindos de sua rede para a rede, e eles ficarão disponíveis para outros sites.
A criptografia no S-Terra CS é realizada utilizando o protocolo IPSec. Usamos o algoritmo “Grasshopper” de acordo com GOST R 34.12-2015 e, para compatibilidade com versões mais antigas, você pode usar GOST 28147-89. A autenticação pode ser tecnicamente realizada em chaves predefinidas (PSKs) e certificados. Porém, na operação industrial é necessário utilizar certificados emitidos de acordo com GOST R 34.10-2012.
Trabalhar com certificados, contêineres e CRLs é feito usando o utilitário certificado_mgr. Primeiro de tudo, usando o comando cert_mgr criar é necessário gerar 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 CA raiz e CRL (se usado) com o comando importação cert_mgr. Você pode ter certeza de que todos os certificados e CRLs estão instalados com o comando cert_mgr mostrar.
Depois de instalar os certificados com sucesso, vá para o console semelhante ao Cisco para configurar o IPSec.
Criamos uma política IKE que especifica os algoritmos e parâmetros desejados do canal seguro criado, que será oferecido ao parceiro para aprovação.
#crypto política isakmp 1000
#encr gosto341215k
#hash gosto341112-512-tc26
#sinal de autenticação
#grupo vko2
#vida 3600
Esta política é aplicada na construção da primeira fase do IPSec. O resultado da conclusão bem sucedida da primeira fase é a criação da SA (Associação de Segurança).
Em seguida, precisamos definir uma lista de endereços IP de origem e destino (ACL) para criptografia, gerar um conjunto de transformações, criar um mapa criptográfico (mapa criptográfico) e vinculá-lo à interface externa do CS.
Definir ACL:
#ip lista de acesso estendida site1
#permit gre host 10.111.21.3 host 10.111.22.3
Um conjunto de transformações (igual à primeira fase, utilizamos o algoritmo de criptografia “Grasshopper” utilizando o modo de geração de inserção de simulação):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Criamos um mapa criptográfico, especificamos a ACL, o conjunto de transformações e o endereço do peer:
#crypto mapa PRINCIPAL 100 ipsec-isakmp
#match endereço site1
#set conjunto de transformação GOST
#definir ponto 10.111.22.3
Vinculamos o cartão criptográfico à interface externa da caixa registradora:
#interfaceGigabitEthernet0/0
#endereço IP 10.111.21.3 255.255.255.0
#crypto mapa PRINCIPAL
Para criptografar canais com outros sites, você deve repetir o procedimento de criação de ACL e cartão criptográfico, alterando o nome da ACL, endereços IP e número do cartão criptográfico.
Preste atenção! Se a verificação de certificado por CRL não for usada, isso deverá ser especificado explicitamente:
#crypto pki trustpoint s-terra_technological_trustpoint
#revogação-verifique nenhum
Neste ponto, a configuração pode ser considerada concluída. Na saída de comando do console semelhante à Cisco mostrar criptografia isakmp sa и mostrar criptografia ipsec sa A primeira e a segunda fases construídas do IPSec devem ser refletidas. A mesma informação pode ser obtida usando o comando show sa_mgr, executado a partir do shell debian. Na saída do comando cert_mgr mostrar Os certificados do site remoto devem aparecer. O status de tais certificados será remoto. Se os túneis não estiverem sendo construídos, você precisará consultar o log do serviço VPN, que está 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.
Monitorando a “saúde” do sistema
O S-Terra CC usa o daemon snmpd padrão para monitoramento. Além dos parâmetros típicos do Linux, o S-Terra oferece suporte imediato à emissão de dados sobre túneis IPSec de acordo com o CISCO-IPSEC-FLOW-MONITOR-MIB, que é o que usamos ao monitorar o status dos túneis IPSec. A funcionalidade de OIDs personalizados que exibem os resultados da execução do script como valores também é suportada. Este recurso nos permite rastrear as datas de expiração dos certificados. O script escrito analisa a saída do comando cert_mgr mostrar e, como resultado, fornece o número de dias até que os certificados local e raiz expirem. Esta técnica é indispensável na administração de um grande número de revascularizações miocárdicas.
Qual é o benefício dessa criptografia?
Todas as funcionalidades descritas acima são suportadas imediatamente pelo S-Terra KSh. Ou seja, não houve necessidade de instalação de módulos adicionais que pudessem afetar a certificação dos crypto gateways e a certificação de todo o sistema de informação. Pode haver qualquer canal entre sites, até mesmo via Internet.
Devido ao fato de que quando a infraestrutura interna muda, não há necessidade de reconfigurar gateways criptográficos, 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 serão transferidas dinamicamente entre os equipamentos de criptografia.
É claro que a criptografia devido a custos indiretos (sobrecargas) afeta a velocidade de transferência de dados, mas apenas ligeiramente - a taxa de transferência do canal pode diminuir em no máximo 5 a 10%. Ao mesmo tempo, a tecnologia foi testada e apresentou bons resultados mesmo em canais de 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