Si votre entreprise transmet ou reçoit des données personnelles et d'autres informations confidentielles qui doivent être protégées conformément à la législation, il est nécessaire d'appliquer le chiffrement selon les normes GOST. Aujourd'hui, nous allons vous expliquer comment nous avons mis en œuvre ce chiffrement basé sur un cryptogateway (CG) S-Terra pour l'un de nos clients. Cette histoire intéressera les spécialistes de la sécurité de l'information, ainsi que les ingénieurs, concepteurs et architectes. Nous n'entrerons pas dans les détails des configurations techniques dans cet article — nous nous concentrerons sur les points clés de la configuration de base. Une grande quantité de documentation sur la configuration des démons de systèmes d'exploitation Linux, sur lesquels repose le CG S-Terra, est librement accessible sur Internet. La documentation pour la configuration des logiciels propriétaires S-Terra est également accessible publiquement sur du fabricant.
Quelques mots sur le projet
La topologie réseau du client était standard — full mesh entre le centre et les filiales. Il était nécessaire de mettre en place le chiffrement des canaux d'échange d'informations entre tous les sites, au nombre de 8.
Dans ce type de projet, tout est généralement statique : des routes statiques sont définies sur les cryptogateways (CG) vers le réseau local du site, et des listes d'adresses IP (ACL) sont établies pour le chiffrement. Cependant, dans ce cas, les sites n'ont pas de gestion centralisée, et à l'intérieur de leurs réseaux locaux, tout peut se produire : des réseaux peuvent être ajoutés, supprimés et modifiés de diverses manières. Pour éviter de devoir reconfigurer le routage et les ACL sur le CG lors du changement d'adressage des réseaux locaux sur les sites, il a été décidé d'utiliser le tunneling GRE et le routage dynamique OSPF, dans lequel sont inclus tous les CG et la plupart des routeurs de niveau cœur sur les sites (dans certains sites, les administrateurs d'infrastructure ont préféré utiliser SNAT vers le CG sur les routeurs cœur).
Le tunneling GRE a permis de résoudre deux tâches :
1. Utiliser dans l'ACL pour le chiffrement l'adresse IP de l'interface externe du CG, où tout le trafic dirigé vers d'autres sites est encapsulé.
2. Organiser des tunnels p-t-p entre les CG, permettant de configurer un routage dynamique (dans notre cas, un MPLS L3VPN provider a été mis en place entre les sites).
Le client a commandé la mise en œuvre du chiffrement en tant que service. Autrement, il aurait dû non seulement maintenir des passerelles de chiffrement ou sous-traiter cela à une organisation, mais aussi surveiller lui-même le cycle de vie des certificats de chiffrement, les renouveler à temps et installer de nouveaux certificats.
Voici donc un rappel – comment et quoi nous avons configuré
À l'attention du sujet de l'Information Critique Économique (KII) : configuration de la passerelle de chiffrement
Configuration de base du réseau
Tout d'abord, nous lançons la nouvelle passerelle de chiffrement (KSh) et accédons à la console d'administration. Il convient de commencer par changer le mot de passe de l'administrateur intégré – la commande est change user password administrator. Ensuite, il est nécessaire de procéder à la procédure d'initialisation (commande initialize) au cours de laquelle les données de licence sont saisies et le générateur de nombres aléatoires (GNA) est initialisé.
Attention! Lors de l'initialisation de la KSh S-Terra, une politique de sécurité est établie, qui empêche les interfaces de la passerelle de sécurité de laisser passer des paquets. Il est nécessaire de créer soit sa propre politique, soit d'activer une politique préinstallée à l'aide de la commande run csconf_mgr activate .
Ensuite, il est nécessaire de configurer les adresses des interfaces externes et internes, ainsi que la route par défaut. Il est préférable d'effectuer la configuration réseau de la KSh et le paramétrage du chiffrement via la console de type Cisco. Cette console est destinée à la saisie de commandes similaires aux commandes Cisco IOS. La configuration ainsi formée à l'aide de la console de type Cisco est convertie en fichiers de configuration correspondants, avec lesquels les démons du système d'exploitation travaillent. On peut accéder à la console de type Cisco depuis la console d'administration avec la commande configure.
Changeons les mots de passe de l'utilisateur intégré cscons et enable :
>enable
Mot de passe : csp (par défaut)
#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
Nous sortons de la console de type Cisco et passons au shell Debian avec la commande system. Nous configurons notre propre mot de passe pour l'utilisateur root la commande passwd.
Chaque KSh configure un tunnel séparé pour chaque site. La configuration de l'interface de tunnel se fait dans le fichier /etc/network/interfaces. La création de l'interface proprement dite est assurée par l'outil IP tunnel, qui fait partie de l'ensemble préinstallé iproute2. La commande de création de l'interface est inscrite dans l'option pre-up.
Exemple de configuration d'une interface de tunnel typique :
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
Attention! Il convient de noter que les paramètres des interfaces de tunnel doivent être placés en dehors de la section
###netifcfg-begin###
*****
###netifcfg-end###
Sinon, ces paramètres seront écrasés lors de la modification des paramètres des interfaces physiques via une console de type Cisco.
Routage dynamique
Dans S-Terra, le routage dynamique est réalisé à l'aide du package logiciel Quagga. Pour configurer OSPF, nous aurons besoin d'activer et de configurer des démons zebra et ospfd. Le démon zebra gère 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 la mise en œuvre du protocole OSPF.
La configuration d'OSPF se fait soit via la console du démon, soit directement à travers le fichier de configuration /etc/quagga/ospfd.conf. Le fichier doit inclure toutes les interfaces physiques et de tunnel participant au routage dynamique, ainsi que les réseaux qui seront annoncés et qui recevront des annonces.
Exemple de configuration à ajouter dans le ospfd.conf:
interface eth0
!
interface eth1
!
interface site1
!
interface site2
routeur 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
Dans ce cas, les adresses 192.168.1.x/31 sont attribuées aux réseaux de tunnel ptp entre les sites, et les adresses 192.168.2.x/30 sont pour les réseaux de transit entre les KSH et les routeurs de cœur.
Attention! Pour réduire la table de routage dans de grandes installations, il est possible de filtrer l'annonce des réseaux de transit eux-mêmes à l'aide des constructions no redistribute connected ou redistribute connected route-map.
Après la configuration des démons, il est nécessaire de modifier le statut de lancement des démons dans /etc/quagga/daemons. Dans les options zebra et ospfd corriger no en yes. Démarrer le démon quagga et établir son auto-démarrage lors du démarrage du KSH avec la commande update-rc.d quagga enable.
Si la configuration des tunnels GRE et d'OSPF est correcte, alors les KSH et les routeurs de cœur devraient avoir des routes vers le réseau des autres sites, et ainsi une connectivité réseau entre les réseaux locaux est établie.
Chiffrer le trafic transmis
Comme déjà mentionné, lors du chiffrement entre les sites, nous indiquons généralement des plages d'adresses IP (ACL) entre lesquelles le trafic est chiffré : si les adresses source et 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 utiliser les adresses externes du KSh comme adresses source et destination pour le chiffrement du trafic — car le trafic chiffré arrive déjà encapsulé par le protocole GRE. En d'autres termes, tout ce qui entre dans le KSh depuis le réseau local d'un site vers des réseaux annoncés par d'autres sites est chiffré. Et à l'intérieur de chaque site, n'importe quelle redirection peut être effectuée. Ainsi, en cas de changement des réseaux locaux, il suffit à l'administrateur de modifier les annonces sortantes de son réseau vers le KSh, et celui-ci deviendra accessible aux autres sites.
Le chiffrement dans le KSh S-Terra se fait par le biais du protocole IPSec. Nous utilisons l'algorithme « Grasshopper » conformément à la norme GOST R 34.12-2015, et pour la compatibilité avec les anciennes versions, il est possible d'appliquer GOST 28147-89. L'authentification peut techniquement être effectuée soit sur des clés prédéfinies (PSK), soit sur des certificats. Toutefois, en exploitation industrielle, il est nécessaire d'utiliser des certificats émis selon GOST R 34.10-2012.
La gestion des certificats, des conteneurs et des CRL est effectuée à l'aide de l'outil cert_mgr. Tout d'abord, à l'aide de la commande cert_mgr create , il est nécessaire de créer un conteneur de clé privée et une demande de certificat, qui sera envoyée au Centre de gestion des certificats. Après avoir reçu le certificat, il faut l'importer avec le certificat racine de l'AC et le CRL (si utilisé) à l'aide de la commande cert_mgr import. On peut s'assurer que tous les certificats et le CRL ont été installés avec la commande cert_mgr show.
. Après une installation réussie des certificats, nous passons à la console de type Cisco pour configurer IPSec.
Nous créons une politique IKE, dans laquelle nous spécifions les algorithmes et les paramètres souhaités pour le canal sécurisé à créer, qui seront proposés à notre partenaire pour accord.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#authentication sign
#group vko2
#lifetime 3600
Cette politique s'applique lors de la construction de la première phase d'IPSec. Le résultat d'un passage réussi de la première phase est l'établissement de la SA (Security Association).
Ensuite, nous devrons déterminer la liste des adresses IP source et de destination (ACL) pour le cryptage, former un ensemble de transformations (transform set), créer une carte cryptographique (crypto map) et l'associer à l'interface externe du KSH.
Nous définissons l'ACL :
#ip access-list extended site1
#permit gre host 10.111.21.3 host 10.111.22.3
Ensemble de transformations (tout comme pour la première phase, nous utilisons l'algorithme de cryptage « Grasshopper » avec le mode de production d'insertion d'imitateur) :
#crypto ipsec transform-set GOST esp-gost341215k-mac
Nous créons la carte cryptographique, en spécifiant l'ACL, l'ensemble de transformations 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 associons la carte cryptographique à l'interface externe du KSH :
#interface GigabitEthernet0/0
#ip address 10.111.21.3 255.255.255.0
#crypto map MAIN
Pour le cryptage des canaux avec d'autres sites, il est nécessaire de répéter la procédure de création de l'ACL et de la carte cryptographique, en modifiant le nom de l'ACL, les adresses IP et le numéro de la carte cryptographique.
Attention! Dans le cas où la vérification des certificats selon la CRL n'est pas utilisée, cela doit être explicitement indiqué :
#crypto pki trustpoint s-terra_technological_trustpoint
#revocation-check none
À ce stade, nous pouvons considérer la configuration comme terminée. Dans la sortie de la console de type Cisco-like, show crypto isakmp sa et show crypto ipsec sa les premières et deuxièmes phases de l'IPSec doivent être reflétées. Cette même information peut être obtenue à l'aide de la commande sa_mgr show, exécutée à partir de la shell Debian. Dans la sortie de la commande, cert_mgr show les certificats des sites distants doivent apparaître. Le statut de ces certificats sera remote. Dans le cas où les tunnels ne se construisent pas, il est nécessaire de consulter le journal VPN-service, qui est stocké dans le fichier /var/log/cspvpngate.log. Une liste complète des fichiers de log avec une description de leur contenu est présente dans la documentation.
Nous surveillons la « santé » du système
Dans le KSH S-Terra, la surveillance utilise le démon standard snmpd. En plus des paramètres typiques de Linux, S-Terra prend en charge nativement la fourniture de données sur les tunnels IPSec selon le CISCO-IPSEC-FLOW-MONITOR-MIB, ce dont nous nous servons pour suivre l'état des tunnels IPSec. Une fonctionnalité pour les OID personnalisés émettant comme valeurs les résultats de l'exécution du script est également prise en charge. Cette possibilité nous permet de suivre les dates d'expiration des certificats. Le script écrit analyse la sortie de la commande cert_mgr show et renvoie le nombre de jours jusqu'à l'expiration des certificats local et racine. Cette méthode est inestimable lors de l'administration d'un grand nombre de KSH.
Quelle est la subtilité de ce cryptage
Toutes les fonctionnalités décrites ci-dessus sont prises en charge « nativement » par la passerelle cryptographique S-Terra. Cela signifie qu'il n'est pas nécessaire d'installer des modules supplémentaires susceptibles d'influencer la certification des passerelles cryptographiques et l'homologation de l'ensemble du système d'information. Les canaux entre les sites peuvent être de n'importe quel type, y compris par Internet.
Grâce au fait qu'il n'est pas nécessaire de reconfigurer les passerelles cryptographiques lors des modifications de l'infrastructure interne, le système fonctionne comme un service, ce qui est très pratique pour le client : il peut placer ses services (clients et serveurs) à n'importe quelle adresse, et tous les changements seront transmis dynamiquement entre les équipements de chiffrement.
Il est certain que le chiffrement, en raison des frais généraux (overhead), influence la vitesse de transmission des données, mais de manière négligeable : la bande passante du canal peut diminuer au maximum de 5 à 10 %. De plus, la technologie a été testée et a montré de bons résultats même sur des canaux satellites, qui sont assez instables et disposent d'une faible bande passante.
Igor Vinokhodov, ingénieur de la ligne 2 d'administration « Rostelecom-Solar »
Source : habr.com
