Si votre entreprise transmet ou reçoit sur le réseau des données personnelles et d'autres informations confidentielles soumises à une protection conformément à la loi, elle est tenue d'utiliser le cryptage GOST. Aujourd'hui, nous allons vous expliquer comment nous avons mis en œuvre un tel cryptage basé sur la passerelle cryptographique S-Terra (CS) chez l'un des clients. Cette histoire intéressera les spécialistes de la sécurité de l'information, ainsi que les ingénieurs, designers et architectes. Nous n’entrerons pas profondément dans les nuances de la configuration technique dans cet article ; nous nous concentrerons sur les points clés de la configuration de base. D'énormes volumes de documentation sur la configuration des démons du système d'exploitation Linux, sur lesquels est basé le S-Terra CS, sont disponibles gratuitement sur Internet. La documentation pour la configuration du logiciel propriétaire S-Terra est également disponible publiquement sur fabricant.
Quelques mots sur le projet
La topologie du réseau du client était standard : un maillage complet entre le centre et les succursales. Il a fallu introduire le cryptage des canaux d'échange d'informations entre tous les sites, au nombre de 8.
Habituellement, dans de tels projets, tout est statique : les routes statiques vers le réseau local du site sont définies sur des passerelles cryptographiques (CG), des listes d'adresses IP (ACL) sont enregistrées pour le cryptage. Cependant, dans ce cas, les sites n'ont pas de contrôle centralisé 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 possibles. Afin d'éviter de reconfigurer le routage et l'ACL sur le KS lors de la modification 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 incluent tous les KS et la plupart des routeurs au niveau du cœur de réseau sur les sites ( sur certains sites, les administrateurs d'infrastructure ont préféré utiliser SNAT plutôt que KS sur les routeurs du noyau).
Le tunneling GRE nous a permis de résoudre deux problèmes :
1. Utilisez l'adresse IP de l'interface externe du CS pour le chiffrement dans l'ACL, qui encapsule tout le trafic envoyé vers d'autres sites.
2. Organisez des tunnels ptp entre CS, qui permettent de configurer un routage dynamique (dans notre cas, le MPLS L3VPN du fournisseur est organisé entre les sites).
Le client a ordonné la mise en œuvre du chiffrement en tant que service. Sinon, il devrait non seulement entretenir les passerelles cryptographiques ou les sous-traiter à 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 proprement dit : comment et ce que nous avons configuré
Note au sujet CII : mise en place d'une passerelle crypto
Configuration réseau de base
Tout d'abord, nous lançons un nouveau CS et entrons dans la console d'administration. Vous devriez commencer par modifier le mot de passe de l'administrateur intégré - commande changer le mot de passe de l'utilisateur administrateur. Ensuite, vous devez effectuer la procédure d'initialisation (commande initialiser) au cours de laquelle les données de licence sont saisies et le capteur de nombres aléatoires (RNS) est initialisé.
Faites attention! Lorsque S-Terra CC est initialisé, une politique de sécurité est établie dans laquelle les interfaces de la passerelle de sécurité ne permettent pas le passage des paquets. Vous devez soit créer votre propre politique, soit utiliser la commande exécutez csconf_mgr activer activer une politique 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 CS et de configurer le cryptage via une console de type Cisco. Cette console est conçue pour saisir des commandes similaires aux commandes Cisco IOS. La configuration générée à l'aide de la console de type Cisco est, à son tour, convertie en fichiers de configuration correspondants avec lesquels les démons du système d'exploitation fonctionnent. Vous pouvez accéder à la console de type Cisco depuis la console d'administration avec la commande configurer.
Modifiez les mots de passe des cscons utilisateur intégrés et activez :
>activer
Mot de passe : csp (préinstallé)
#configurer le terminal
#username cscons privilège 15 secret 0 #enable secret 0 Configuration de la configuration réseau de base :
#interface GigabitEthernet0/0
#adresse IP 10.111.21.3 255.255.255.0
#Pas d'extinction
#interface GigabitEthernet0/1
#adresse IP 192.168.2.5 255.255.255.252
#Pas d'extinction
#iproute 0.0.0.0 0.0.0.0 10.111.21.254
GRE
Quittez la console de type Cisco et accédez au shell Debian avec la commande combustion propre. Définissez votre propre mot de passe pour l'utilisateur racine l'équipe passwd.
Au niveau de chaque salle de contrôle, un tunnel distinct est configuré pour chaque site. L'interface du tunnel est configurée dans le fichier / etc / network / interfaces. L'utilitaire de tunnel IP, inclus dans l'ensemble iproute2 préinstallé, est responsable de la création de l'interface elle-même. La commande de création d'interface est écrite dans l'option de pré-installation.
Exemple de configuration d'une interface tunnel typique :
site automobile1
iface site1 inet statique
adresse 192.168.1.4
masque de réseau 255.255.255.254
tunnel ip préalable ajouter le mode site1 gre local 10.111.21.3 distant 10.111.22.3 clé hfLYEg^vCh6p
Faites attention! A noter que les paramétrages des interfaces tunnel doivent être situés en dehors de la section
###netifcfg-begin###
*****
###netifcfg-end###
Sinon, ces paramètres seront écrasés lors de la modification des paramètres réseau des interfaces physiques via une 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 zèbre и ospfd. Le démon Zebra est responsable de la communication 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.
OSPF est configuré soit via la console du démon, soit directement via le fichier de configuration /etc/quagga/ospfd.conf. Toutes les interfaces physiques et tunnel participant au routage dynamique sont ajoutées au fichier, et les réseaux qui seront annoncés et recevront des annonces sont également déclarés.
Un exemple de configuration qui doit être ajoutée à ospfd.conf:
interface eth0
!
interface eth1
!
site d'interface1
!
site d'interface2
routeur ospf
ID de routeur ospf 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 tunnel ptp entre sites, les adresses 192.168.2.x/30 sont allouées aux réseaux de transit entre CS et routeurs noyau.
Faites attention! Pour réduire la table de routage dans les grandes installations, vous pouvez filtrer la publicité des réseaux de transit eux-mêmes à l'aide des constructions aucune redistribution connectée ou redistribuer la feuille de route connectée.
Après avoir configuré les démons, vous devez modifier l'état de démarrage des démons dans /etc/quagga/démons. Dans les options zèbre и ospfd aucun changement en oui. Démarrez le démon quagga et configurez-le pour qu'il s'exécute automatiquement lorsque vous démarrez KS avec la commande update-rc.d quagga activer.
Si la configuration des tunnels GRE et OSPF est effectuée correctement, les routes du réseau des autres sites devraient apparaître sur les routeurs KSh et principaux et, ainsi, une connectivité réseau entre les réseaux locaux apparaît.
Nous chiffrons le trafic transmis
Comme déjà écrit, généralement lors du chiffrement entre sites, nous spécifions des plages d'adresses IP (ACL) entre lesquelles le trafic est chiffré : si les adresses source et de destination se situent 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 - après tout, le trafic déjà encapsulé par le protocole GRE arrive pour le chiffrement. En d'autres termes, tout ce qui entre dans le CS depuis le réseau local d'un site vers les réseaux annoncés par d'autres sites est crypté. Et au sein de chacun des sites, toute redirection peut être effectuée. Ainsi, s'il y a un changement dans les réseaux locaux, l'administrateur n'a qu'à modifier les annonces provenant de son réseau vers le réseau, et elles deviendront disponibles pour les autres sites.
Le cryptage dans S-Terra CS 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, vous pouvez utiliser GOST 28147-89. L'authentification peut techniquement être effectuée à la fois sur des clés prédéfinies (PSK) et sur des certificats. Cependant, en exploitation industrielle, il est nécessaire d'utiliser des certificats délivrés conformément à GOST R 34.10-2012.
Travailler avec des certificats, des conteneurs et des CRL se fait à l'aide de l'utilitaire cert_mgr. Tout d'abord, en utilisant la commande cert_mgr créer il est nécessaire de générer un conteneur de clé privée et une demande de certificat, qui seront envoyées au Centre de gestion des certificats. Après avoir reçu le certificat, il doit être importé avec le certificat racine de l'autorité de certification et la CRL (si utilisée) avec la commande importation cert_mgr. Vous pouvez vous assurer que tous les certificats et CRL sont installés avec la commande spectacle cert_mgr.
Après avoir installé avec succès les certificats, accédez à la console de type Cisco pour configurer IPSec.
Nous créons une politique IKE qui spécifie les algorithmes et paramètres souhaités du canal sécurisé en cours de création, qui sera proposé au partenaire pour approbation.
#crypto isakmp politique 1000
#encr gost341215k
#hash gost341112-512-tc26
#signe d'authentification
#groupe vko2
#durée de vie 3600
Cette politique est appliquée lors de la construction de la première phase d'IPSec. Le résultat de la réussite de la première phase est la création de la SA (Security Association).
Ensuite, nous devons définir une liste d'adresses IP source et de destination (ACL) pour le cryptage, générer un ensemble de transformations, créer une carte cryptographique (crypto map) et la lier à l'interface externe du CS.
Définir la liste de contrôle d'accès :
Site étendu de liste d'accès #ip1
#permit gre hôte 10.111.21.3 hôte 10.111.22.3
Un ensemble de transformations (comme pour la première phase, nous utilisons l'algorithme de chiffrement « Grasshopper » utilisant le mode de génération d'insertion de simulation) :
#crypto ipsec transformation-set GOST esp-gost341215k-mac
Nous créons une carte de chiffrement, spécifions l'ACL, l'ensemble de transformations et l'adresse homologue :
#crypto map PRINCIPAL 100 ipsec-isakmp
#correspondre à l'adresse du site1
#set transformation-set GOST
#set homologue 10.111.22.3
Nous lions la carte crypto à l'interface externe de la caisse enregistreuse :
#interface GigabitEthernet0/0
#adresse IP 10.111.21.3 255.255.255.0
#crypto map PRINCIPAL
Pour crypter les chaînes avec d'autres sites, vous devez répéter la procédure de création d'une ACL et d'une carte cryptée, en modifiant le nom de l'ACL, les adresses IP et le numéro de la carte cryptée.
Faites attention! Si la vérification des certificats par CRL n'est pas utilisée, cela doit être explicitement précisé :
#crypto pki point de confiance s-terra_technological_trustpoint
#revocation-check aucun
À ce stade, la configuration peut être considérée comme terminée. Dans la sortie de commande de la console de type Cisco afficher crypto isakmp sa и montrer crypto ipsec sa Les première et deuxième phases construites d'IPSec doivent être reflétées. Les mêmes informations peuvent être obtenues en utilisant la commande spectacle sa_mgr, exécuté à partir du shell Debian. Dans la sortie de la commande spectacle cert_mgr Les certificats du site distant devraient apparaître. Le statut de ces certificats sera éloigné. Si 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.
Surveillance de la « santé » du système
Le S-Terra CC utilise le démon snmpd standard pour la surveillance. En plus des paramètres Linux typiques, S-Terra prend en charge la transmission de données sur les tunnels IPSec conformément au CISCO-IPSEC-FLOW-MONITOR-MIB, que nous utilisons pour surveiller l'état des tunnels IPSec. La fonctionnalité des OID personnalisés qui génèrent les résultats de l'exécution du script sous forme de valeurs est également prise en charge. Cette fonctionnalité nous permet de suivre les dates d'expiration des certificats. Le script écrit analyse le résultat de la commande spectacle 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 PAC.
Quel est l’intérêt d’un tel cryptage ?
Toutes les fonctionnalités décrites ci-dessus sont prises en charge dès le départ par le S-Terra KSh. Autrement dit, il n'était pas nécessaire d'installer des modules supplémentaires pouvant affecter la certification des passerelles cryptographiques et la certification de l'ensemble du système d'information. Il peut y avoir n'importe quel canal entre les sites, même via Internet.
Étant donné que lorsque l'infrastructure interne change, il n'est pas nécessaire de reconfigurer les passerelles cryptographiques, le système fonctionne comme un service, ce qui est très pratique pour le client : il peut placer ses services (client et serveur) à n'importe quelle adresse, et toutes les modifications seront transférées dynamiquement entre les équipements de chiffrement.
Bien entendu, le cryptage dû aux frais généraux (overhead) affecte la vitesse de transfert des données, mais seulement légèrement - le débit du canal peut diminuer d'un maximum de 5 à 10 %. Dans le même temps, la technologie a été testée et a montré de bons résultats même sur les chaînes satellite, qui sont assez instables et ont une faible bande passante.
Igor Vinokhodov, ingénieur de la 2e ligne d'administration de Rostelecom-Solar
Source: habr.com