Si votre entreprise transmet ou reçoit sur le réseau des données personnelles et autres informations confidentielles soumises à protection conformément à la loi, elle est tenue d'appliquer un cryptage conformément à GOST. Aujourd'hui, nous vous expliquerons comment nous avons mis en œuvre un tel cryptage basé sur la crypto-passerelle S-Terra (KS) chez l'un des clients. Cette histoire sera intéressante pour les spécialistes de la sécurité de l'information, ainsi que pour les ingénieurs, les concepteurs et les architectes. Nous ne plongerons pas profondément dans les nuances de la configuration technique dans ce post - nous nous attarderons sur les points clés de la configuration de base. Une énorme quantité de documentation sur la configuration des démons du système d'exploitation Linux, sur laquelle la base de données S-Terra est basée, est disponible gratuitement sur Internet. La documentation de configuration du logiciel propriétaire S-Terra est également accessible au public sur
le portail du fabricant.
Quelques mots sur le projet
La topologie du réseau du client était typique - maillage complet entre le centre et les succursales. Il était nécessaire d'introduire le cryptage des canaux d'échange d'informations entre tous les sites, dont 8 éléments.
En règle générale, dans de tels projets, tout est statique: sur les crypto-passerelles (KS), les routes statiques sont définies vers le réseau local du site, des listes d'adresses IP (ACL) pour le chiffrement sont écrites. Cependant, dans ce cas, les sites n'ont pas de gestion centralisée et tout peut arriver à l'intérieur de leurs réseaux locaux: les réseaux peuvent être ajoutés, supprimés et modifiés de toutes les manières. Afin d'éviter la reconfiguration du routage et des ACL vers le KS lors du changement de l'adressage des réseaux locaux sur les sites, il a été décidé d'utiliser le tunneling GRE et le routage dynamique OSPF, qui inclut tous les KS et la plupart des routeurs du niveau de base du réseau sur les sites (sur certains sites, les administrateurs d'infrastructure préfèrent utiliser SNAT en direction de KS sur les routeurs du noyau).
Le tunneling GRE a résolu deux problèmes:
1. Utilisez dans l'ACL pour le chiffrement l'adresse IP de l'interface KS externe, dans laquelle tout le trafic envoyé vers d'autres sites est encapsulé.
2. Organisez des tunnels ptp entre le KS, qui vous permettent de configurer le routage dynamique (dans notre cas, le fournisseur MPLS L3VPN est organisé entre les sites).
Le client a ordonné la mise en œuvre du cryptage en tant que service. Sinon, il devrait non seulement prendre en charge les passerelles cryptographiques ou externaliser une organisation, mais également surveiller de manière indépendante le cycle de vie des certificats de chiffrement, les renouveler à temps et en installer de nouveaux.
Et maintenant, le mémo lui-même - comment et qu'avons-nous mis en place
Note de sujet KII: nous configurons une passerelle cryptographique
Configuration de base du réseau
Tout d'abord, nous lançons un nouveau cache et entrons dans la console d'administration. Vous devez commencer par modifier le mot de passe de l'administrateur intégré - la commande
change user password administrator . Ensuite, il est nécessaire d'effectuer la procédure d'initialisation (la commande d'
initialisation ) au cours de laquelle les données de licence sont entrées et le capteur de nombre aléatoire (DSN) est initialisé.
Faites attention! Lorsque S-Terra KS est initialisé, une politique de sécurité est établie dans laquelle les interfaces Security Gateway ne transmettent pas de paquets. Vous devez soit créer votre propre stratégie, soit utiliser la
commande run csconf_mgr activate pour activer une stratégie d'autorisation prédéfinie.
Ensuite, vous devez configurer l'adressage des interfaces externes et internes, ainsi que la route par défaut. Il est préférable de travailler avec la configuration réseau du cache et de configurer le chiffrement via la console de type Cisco. Cette console est conçue pour entrer des commandes similaires aux commandes Cisco IOS. La configuration créée à l'aide de la console de type Cisco, à son tour, est convertie dans les fichiers de configuration correspondants avec lesquels les démons du système d'exploitation fonctionnent. Vous pouvez accéder à la console de type Cisco à partir de la console d'administration avec la commande
configure .
Modifiez les mots de passe des cscons utilisateur intégrés et activez:
> activer
Mot de passe: csp (prédéfini)
#configure terminal
#username cscons privilege 15 secret 0 #enable secret 0 Configurez la configuration de base du réseau:
#interface GigabitEthernet0 / 0
# adresse IP 10.111.21.3 255.255.255.0
# no shutdown
#interface GigabitEthernet0 / 1
#ip adresse 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
Nous quittons la console de type Cisco et allons au shell Debian avec la commande
système . Définissez votre propre mot de passe pour l'
utilisateur root avec la commande
passwd .
Un tunnel distinct pour chaque site est configuré sur chaque KSh. L'interface de tunnel est configurée dans le fichier
/ etc / network / interfaces . L'utilitaire de tunnel IP, qui fait partie de l'ensemble prédéfini d'iproute2, est responsable de la création de l'interface elle-même. La commande pour créer une interface est écrite dans l'option de pré-up.
Exemple de configuration d'une interface de tunnel typique:
site auto1
iface site1 inet statique
adresse 192.168.1.4
masque de réseau 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
Faites attention! Il convient de noter que les paramètres de l'interface du tunnel doivent être situés en dehors de la section
### netifcfg-begin ###
*****
### netifcfg-end ###
Sinon, ces paramètres seront effacés lors de la modification des paramètres réseau des interfaces physiques via la console de type Cisco.
Routage dynamique
Dans S-Terra, le routage dynamique est implémenté à l'aide du progiciel Quagga. Pour configurer OSPF, nous devons activer et configurer les
démons zebra et
ospfd . Le démon zebra est responsable de l'interaction entre les démons de routage et le système d'exploitation. Le démon ospfd, comme son nom l'indique, est responsable de l'implémentation du protocole OSPF.
OSPF est configuré via la console démon ou directement via le fichier de configuration
/etc/quagga/ospfd.conf . Toutes les interfaces physiques et tunnel impliquées dans le routage dynamique sont ajoutées au fichier, et les réseaux sont annoncés qui seront annoncés et recevront des annonces.
Un exemple de configuration Ă ajouter Ă
ospfd.conf :
interface eth0
!
interface eth1
!
interface site1
!
interface site2
routeur ospf
ospf router-id 192.168.2.21
réseau 192.168.1.4/31 zone 0.0.0.0
réseau 192.168.1.16/31 zone 0.0.0.0
réseau 192.168.2.4/30 zone 0.0.0.0
Dans ce cas, les adresses 192.168.1.x / 31 sont réservées aux réseaux de tunnel ptp entre sites, les adresses 192.168.2.x / 30 sont allouées aux réseaux de transit entre le CABG et les routeurs principaux.
Faites attention! Pour réduire la table de routage dans les grandes installations, vous pouvez filtrer l'annonce des réseaux de transit eux-mêmes à l'aide des constructions
map-map no redistribute connected ou
redistribute connected .
Après avoir configuré les démons, vous devez modifier l'état de lancement du démon dans
/ etc / quagga / daemons . Dans les options
zebra et
ospfd aucun correctif à oui. Exécutez le démon quagga et définissez son exécution automatique lors du démarrage du cache avec la commande
enable-rc.d quagga enable .
Si les tunnels GRE et OSPF sont configurés correctement, les routes vers le réseau d'autres sites doivent apparaître sur les routeurs KS et du noyau, et ainsi la connectivité réseau entre les réseaux locaux se pose.
Nous chiffrons le trafic transmis
Comme déjà mentionné, lors du chiffrement entre sites, nous spécifions généralement les plages d'adresses IP (ACL) entre lesquelles le trafic est chiffré: si les adresses source et de destination tombent dans ces plages, alors le trafic entre elles est chiffré. Cependant, dans ce projet, la structure est dynamique et les adresses peuvent changer. Puisque nous avons déjà configuré le tunneling GRE, nous pouvons spécifier des adresses KS externes comme adresses source et de destination pour le chiffrement du trafic - car pour le chiffrement vient le trafic déjà encapsulé par le protocole GRE. En d'autres termes, tout ce qui entre dans le cache du réseau local d'un site aux réseaux annoncés par d'autres sites est crypté. Et déjà sur chacun des sites, tout transfert peut être effectué. Ainsi, avec tout changement de réseaux locaux, il suffit à l'administrateur de modifier les annonces allant de son réseau vers la direction du lycée, et cela deviendra disponible pour d'autres sites.
Le chiffrement dans le S-Terra KS est effectué à l'aide du protocole IPSec. Nous utilisons l'algorithme Grasshopper conformément à GOST R 34.12-2015, et pour la compatibilité avec les anciennes versions, GOST 28147-89 peut être utilisé. L'authentification peut techniquement être effectuée à la fois sur des clés prédéfinies (PSK) et des certificats. Néanmoins, en exploitation industrielle, il est nécessaire d'utiliser des certificats délivrés conformément à GOST R 34.10-2012.
Le travail avec les certificats, les conteneurs et les CRL s'effectue Ă l'aide de l'utilitaire
cert_mgr . Tout d'abord, Ă l'aide de la commande
cert_mgr create ,
vous devez
créer un conteneur de clé privée et une demande de certificat, qui seront envoyés au centre de gestion des certificats. Après avoir reçu le certificat, il doit être importé avec la commande d'
importation cert_mgr avec le certificat racine de l'autorité de certification et de la liste de révocation de certificats (le cas échéant). Vous pouvez
vérifier que tous les certificats et CRL sont installés avec la commande
cert_mgr show .
Après avoir correctement installé les certificats, accédez à la console de type Cisco pour configurer IPSec.
Nous créons une politique IKE qui spécifie les algorithmes et les paramètres souhaités du canal sécurisé créé, qui seront proposés au partenaire pour approbation.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
# signe d'authentification
#group vko2
#lifetime 3600
Cette stratégie s'applique lors de la création de la première phase d'IPSec. L'achèvement réussi de la première phase est la création de SA (Security Association).
Ensuite, nous devons définir une liste d'adresses IP source et de destination (ACL) pour le chiffrement, former un ensemble de transformations, créer une carte cryptographique (carte cryptographique) et la lier à l'interface externe du CAB.
DĂ©finissez l'ACL:
#ip access-list Ă©tendu site1
#permit gre hĂ´te 10.111.21.3 hĂ´te 10.111.22.3
Un ensemble de transformations (ainsi que pour la première phase, nous utilisons l'algorithme de cryptage Grasshopper en utilisant le mode simulation):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Créez une carte cryptographique, spécifiez ACL, transformez le jeu et l'adresse du pair:
#crypto map MAIN 100 ipsec-isakmp
#match address site1
#set transform-set GOST
#set peer 10.111.22.3
Nous attachons la carte cryptographique Ă l'interface externe du CABG:
#interface GigabitEthernet0 / 0
# adresse IP 10.111.21.3 255.255.255.0
#crypto map MAIN
Pour crypter des canaux avec d'autres sites, vous devez répéter la procédure de création d'ACL et de cartes cryptographiques, en changeant le nom de l'ACL, les adresses IP et le numéro de carte cryptographique.
Faites attention! Si la vérification du certificat CRL n'est pas utilisée, cela doit être explicitement spécifié:
#crypto pki trustpoint s-terra_technological_trustpoint
# revocation-check none
Sur ce paramètre peut être considéré comme terminé. La sortie des commandes de console de type Cisco
show crypto isakmp sa et
show crypto ipsec sa devrait refléter les première et deuxième phases construites d'IPSec. Les mêmes informations peuvent être obtenues en utilisant la commande
sa_mgr show exécutée à partir du shell Debian. La sortie de la commande
cert_mgr show doit afficher les certificats de site distant. Le statut de ces certificats sera
distant . Dans le cas où les tunnels ne sont pas construits, vous devez consulter le journal du service VPN, qui est stocké dans le fichier
/var/log/cspvpngate.log . Une liste complète des fichiers journaux avec une description de leur contenu est disponible dans la documentation.
Surveiller la «santé» du système
S-Terra KS utilise le démon snmpd standard pour la surveillance. En plus des paramètres Linux typiques, S-Terra prêt à l'emploi prend en charge la sortie des tunnels IPSec selon CISCO-IPSEC-FLOW-MONITOR-MIB, qui est ce que nous utilisons pour surveiller l'état des tunnels IPSec. La fonctionnalité des OID personnalisés est également prise en charge, donnant les résultats du script sous forme de valeurs. Cette fonctionnalité nous permet de suivre les dates d'expiration des certificats. Le script écrit analyse la sortie de la commande
show cert_mgr et donne par conséquent le nombre de jours avant l'expiration des certificats local et racine. Cette technique est indispensable lors de l'administration d'un grand nombre de CABG.
Quel est le cimus d'un tel cryptage
Toutes les fonctionnalités décrites ci-dessus sont prises en charge «prêt à l'emploi» KS S-Terra. Autrement dit, il n'était pas nécessaire d'installer de modules supplémentaires susceptibles d'affecter la certification des crypto-passerelles et la certification de l'ensemble du système d'information. Les canaux entre les sites peuvent être quelconques, même via Internet.
Étant donné que lors du changement de l'infrastructure interne, il n'est pas nécessaire de reconfigurer les crypto-passerelles, le
système fonctionne comme un service , ce qui est très pratique pour le client: il peut placer ses services (client et serveur) à toutes les adresses, et toutes les modifications sont transférées dynamiquement entre les équipements de cryptage.
Bien sûr, le cryptage dû à la surcharge affecte le taux de transfert de données, mais pas de manière significative - la bande passante du canal peut diminuer de 5 à 10% maximum. De plus, la technologie a été testée et a donné de bons résultats même sur les canaux satellites, qui sont plutôt instables et ont une faible bande passante.
Igor Vinokhodov, ingénieur de la 2ème ligne d'administration de Rostelecom Solar