Wenn Ihr Unternehmen personenbezogene Daten und andere vertrauliche Informationen über das Netzwerk überträgt oder empfängt, die gesetzlich geschützt werden müssen, ist die Anwendung von Verschlüsselung nach GOST erforderlich. Heute erzählen wir Ihnen, wie wir eine solche Verschlüsselung mit dem Kryptoschlüssel (KSH) S-Terra bei einem unserer Kunden implementiert haben. Diese Geschichte wird für Spezialisten für Informationssicherheit sowie für Ingenieure, Designer und Architekten interessant sein. Wir werden in diesem Beitrag nicht tief in die Nuancen der technischen Konfiguration eintauchen — wir konzentrieren uns auf die Schlüsselmomente der Grundkonfiguration. Eine riesige Menge an Dokumentation zur Konfiguration von Linux-Daemons, auf denen der KSH S-Terra basiert, ist im Internet frei verfügbar. Die Dokumentation zur Konfiguration der proprietären Software S-Terra ist ebenfalls öffentlich zugänglich unter des Herstellers.
Einige Worte zum Projekt
Die Netzwerktopologie des Kunden war Standard — ein vollvernetztes Mesh zwischen dem Hauptsitz und den Filialen. Es war erforderlich, die Verschlüsselung der Kommunikationskanäle zwischen allen Standorten, von denen es 8 gab, zu implementieren.
In solchen Projekten ist normalerweise alles statisch: Auf den Kryptowährungs-Gateways (KSG) werden statische Routen für das lokale Netzwerk der Plattformen festgelegt, und es werden IP-Adressenlisten (ACL) für die Verschlüsselung definiert. In diesem Fall fehlt jedoch eine zentrale Verwaltung in den Plattformen, und innerhalb ihrer lokalen Netzwerke kann alles Mögliche geschehen: Netzwerke können hinzugefügt, entfernt und in vielfältiger Weise modifiziert werden. Um eine Neuausrichtung der Routen und ACL auf den KSG bei Änderungen der Adressierung der lokalen Netzwerke auf den Plattformen zu vermeiden, wurde beschlossen, GRE-Tunneling und dynamische OSPF-Routing zu verwenden, in die alle KSG und die meisten Kernrouter der Netzwerke auf den Plattformen integriert sind (in einigen Plattformen bevorzugten die Infrastrukturadministratoren die Verwendung von SNAT in Richtung KSG auf den Kernroutern).
GRE-Tunneling ermöglichte die Lösung zweier Aufgaben:
1. In den ACL zur Verschlüsselung die IP-Adresse des externen Interfaces der KSG zu verwenden, in dem der gesamte Verkehr, der an andere Plattformen gerichtet ist, gekapselt wird.
2. P-t-p-Tunnel zwischen den KSH einrichten, die eine dynamische Routenplanung ermöglichen (in unserem Fall wurde zwischen den Plattformen ein Anbieter-MPLS-L3VPN eingerichtet).
Der Kunde hat die Implementierung von Verschlüsselung als Dienstleistung bestellt. Andernfalls müsste er nicht nur die Krypto-Gateways selbst betreuen oder an ein Unternehmen auslagern, sondern auch den Lebenszyklus der Verschlüsselungszertifikate selbst verfolgen, rechtzeitig verlängern und neue installieren.
Und nun zum eigenen Merkblatt – wie und was wir konfiguriert haben.
Hinweis für den KII-Subjekt: Krypto-Gateway einrichten.
Grundkonfiguration des Netzwerks.
Zuerst starten wir das neue KSH und gelangen zur Administrationskonsole. Zunächst sollten wir das Passwort des integrierten Administrators ändern – Befehl: change user password administrator. Danach ist es notwendig, das Initialisierungsverfahren durchzuführen (Befehl: initialize), bei dem die Lizenzdaten eingegeben und der Zufallszahlengenerator (ZzG) initialisiert werden.
Bitte beachten! Bei der Initialisierung des KSH S-Terra wird eine Sicherheitsrichtlinie festgelegt, bei der die Schnittstellen des Sicherheitsgateways keine Pakete durchlassen. Es ist erforderlich, entweder eine eigene Richtlinie zu erstellen oder mithilfe des Befehls. csconf_mgr aktivieren die Aktivierung der vorinstallierten Erlaubenrichtlinie durchführen.
Anschließend müssen die Adressierung der externen und internen Schnittstellen sowie die Standardroute konfiguriert werden. Die Arbeit mit der Netzwerkkonfiguration des KSH und die Verschlüsselungseinstellungen sollten bevorzugt über die Cisco-ähnliche Konsole erfolgen. Diese Konsole ist für die Eingabe von Befehlen gedacht, die den Befehlen von Cisco IOS ähnlich sind. Die mit der Cisco-ähnlichen Konsole erstellte Konfiguration wird in die entsprechenden Konfigurationsdateien umgewandelt, mit denen die Betriebssystem-Demons arbeiten. Um zur Cisco-ähnlichen Konsole von der Administrationskonsole zu wechseln, verwenden Sie den Befehl configure.
Ändern Sie die Passwörter des integrierten Benutzers cscons und enable:
>enable
Passwort: csp (voreingestellt)
#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
Verlassen Sie die Cisco-ähnliche Konsole und wechseln Sie mit dem Befehl in die Debian-Shell System. Setzen Sie ein eigenes Passwort für den Benutzer root mit dem Befehl passwd.
Auf jedem KSH wird ein separater Tunnel für jede Site konfiguriert. Die Konfiguration der Tunnel-Schnittstelle erfolgt in der Datei /etc/network/interfaces. Für die Erstellung der Schnittstelle ist das IP-Tunnel-Utility verantwortlich, das Teil des vorinstallierten iproute2-Pakets ist. Der Befehl zur Erstellung der Schnittstelle wird in die Option pre-up eingetragen.
Beispielkonfiguration eines typischen Tunnelinterfaces:
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
Bitte beachten! Es ist zu beachten, dass die Einstellungen für Tunnelinterfaces außerhalb des Abschnitts angelegt werden müssen.
###netifcfg-begin###
*****
###netifcfg-end###
Andernfalls werden diese Einstellungen überschrieben, wenn die Netzwerkeinstellungen der physischen Interfaces über das Cisco-ähnliche Konsoleninterface geändert werden.
Dynamische Routing
In S-Terra wird dynamisches Routing durch das Quagga-Softwarepaket umgesetzt. Für die OSPF-Konfiguration benötigen wir die Aktivierung und Einstellung der Daemons zebra und ospfd. Daemon zebra ist für die Interaktion zwischen den Routing-Daemons und dem Betriebssystem verantwortlich. Der Daemon ospfd verantwortet, wie der Name schon sagt, die Implementierung des OSPF-Protokolls.
Die OSPF-Konfiguration erfolgt entweder über die Konsole des Daemons oder direkt über die Konfigurationsdatei. /etc/quagga/ospfd.confIn die Datei werden alle physischen und Tunnelinterfaces, die am dynamischen Routing beteiligt sind, sowie die Netzwerke, die angekündigt werden sollen und die Ankündigungen empfangen, aufgenommen.
Beispielkonfiguration, die in die ospfd.conf:
interface eth0
!
interface eth1
!
interface site1
!
interface site2
router ospf
ospf router-id 192.168.2.21
Netzwerk 192.168.1.4/31 Bereich 0.0.0.0
Netzwerk 192.168.1.16/31 Bereich 0.0.0.0
Netzwerk 192.168.2.4/30 Bereich 0.0.0.0
In diesem Fall sind die Adressen 192.168.1.x/31 für punkt-zu-punkt Tunnelnetzwerke zwischen Standorten reserviert, die Adressen 192.168.2.x/30 für Transitnetzwerke zwischen KSW und den Kernroutern.
Bitte beachten! Um die Routingtabelle in großen Installationen zu reduzieren, kann die Ankündigung der Transitnetze durch die Konstruktionen gefiltert werden no redistribute connected oder redistribute connected route-map.
Nach der Konfiguration der Daemons muss der Startstatus der Daemons in /etc/quagga/daemonsden Optionen geändert werden. Ändern Sie "no" in "yes". Starten Sie den Daemon quagga und setzen Sie dessen Autostart beim Booten der KSW mit dem Befehl zebra und ospfd update-rc.d quagga enable Wenn die Konfiguration der GRE-Tunnel und OSPF korrekt durchgeführt wurde, sollten auf der KSW und den Kernroutern Routen im Netzwerk der anderen Standorte erscheinen, wodurch Netzwerkverbindungen zwischen den lokalen Netzwerken entstehen..
Verschlüsseln Sie den übertragenden Datenverkehr.
Wir verschlüsseln den übermittelten Datenverkehr
Wie bereits erwähnt, geben wir beim Verschlüsseln zwischen den Plattformen normalerweise die IP-Adressbereiche (ACL) an, zwischen denen der Datenverkehr verschlüsselt wird: Wenn die Quell- und Zieladressen in diese Bereiche fallen, wird der Datenverkehr zwischen ihnen verschlüsselt. In diesem Projekt ist die Struktur jedoch dynamisch, und die Adressen können sich ändern. Da wir bereits GRE-Tunneling eingerichtet haben, können wir zur Verschlüsselung des Datenverkehrs die externen Adressen des KSH als Quell- und Zieladressen angeben – denn der Datenverkehr, der verschlüsselt wird, kommt bereits inkapsuliert im GRE-Protokoll. Mit anderen Worten, alles, was von einem lokalen Netzwerk einer Plattform in Richtung der von anderen Plattformen angekündigten Netzwerke in das KSH gelangt, wird verschlüsselt. Innerhalb jeder Plattform kann dann jedoch jede Art von Weiterleitung erfolgen. Im Falle einer Änderung der lokalen Netzwerke muss der Administrator lediglich die Ankündigungen anpassen, die aus seinem Netzwerk in Richtung des KSH gehen, und es wird für andere Plattformen zugänglich.
Die Verschlüsselung im KSH S-Terra erfolgt über das IPSec-Protokoll. Wir verwenden den Algorithmus "Grashopper" gemäß GOST R 34.12-2015, und für die Kompatibilität mit älteren Versionen kann GOST 28147-89 angewendet werden. Die Authentifizierung kann technisch sowohl über vordefinierte Schlüssel (PSK) als auch über Zertifikate durchgeführt werden. In der industriellen Nutzung sollten jedoch Zertifikate verwendet werden, die gemäß GOST R 34.10-2012 ausgestellt wurden.
Die Arbeit mit Zertifikaten, Containern und CRL erfolgt über das Dienstprogramm cert_mgr. Zuerst muss mit dem Befehl cert_mgr create ein Container für den privaten Schlüssel und eine Zertifikatsanfrage erstellt werden, die an die Zertifikatszentrale gesendet wird. Nach Erhalt des Zertifikats müssen es zusammen mit dem Root-Zertifikat der CA und dem CRL (falls verwendet) mit dem Befehl cert_mgr importimportiert werden. Um sicherzustellen, dass alle Zertifikate und CRL korrekt installiert sind, kann der Befehl cert_mgr show.
verwendet werden. Nach erfolgreicher Installation der Zertifikate wechseln wir zur Cisco-ähnlichen Konsole zur Konfiguration von IPSec.
Wir erstellen eine IKE-Policy, in der die gewünschten Algorithmen und Parameter des zu erstellenden gesicherten Kanals angegeben werden, die dem Partner zur Genehmigung angeboten werden.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#authentication sign
#group vko2
#lifetime 3600
Diese Policy wird bei der Erstellung der ersten Phase von IPSec angewendet. Das Ergebnis eines erfolgreichen Abschlusses der ersten Phase ist die Etablierung einer SA (Security Association).
Dann müssen wir die Liste der Quell- und Ziel-IP-Adressen (ACL) für die Verschlüsselung definieren, ein Transformationsset (transform set) bilden, eine Kryptokarte (crypto map) erstellen und sie an das externe Interface der KSH binden.
Wir legen die ACL fest:
#ip access-list extended site1
#permit gre host 10.111.21.3 host 10.111.22.3
Das Transformationsset (wie in der ersten Phase verwenden wir den Verschlüsselungsalgorithmus „Kuznetschik“ unter Verwendung des MAC-Modus):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Wir erstellen die Kryptokarte, geben die ACL, das Transformationsset und die Peer-Adresse an:
#crypto map MAIN 100 ipsec-isakmp
#match address site1
#set transform-set GOST
#set peer 10.111.22.3
Wir binden die Kryptokarte an das externe Interface der KSH:
#interface GigabitEthernet0/0
#ip address 10.111.21.3 255.255.255.0
#crypto map MAIN
Für die Verschlüsselung von Kanälen mit anderen Standorten muss das Verfahren zur Erstellung von ACL und Kryptokarte wiederholt werden, wobei die ACL-Namen, IP-Adressen und Nummern der Kryptokarten geändert werden müssen.
Bitte beachten! Falls keine Überprüfung der Zertifikate über die CRL erfolgt, muss dies ausdrücklich angegeben werden:
#crypto pki trustpoint s-terra_technological_trustpoint
#revocation-check none
Die Konfiguration kann als abgeschlossen betrachtet werden. Im Ausgabeprotokoll der Cisco-ähnlichen Konsole show crypto isakmp sa und show crypto ipsec sa sollten die aufgebauten ersten und zweiten Phasen von IPSec angezeigt werden. Diese Informationen können auch mit dem Befehl sa_mgr show, ausgeführt aus der Debian-Shell, abgerufen werden. In der Ausgabe des Befehls cert_mgr show sollten die Zertifikate der entfernten Sitze erscheinen. Der Status dieser Zertifikate wird remotesein. Falls die Tunnel nicht aufgebaut werden, sollte ins Log geschaut werden VPN-dienst, das in der Datei /var/log/cspvpngate.loggespeichert ist. Eine vollständige Liste der Logdateien mit ihren Inhaltsbeschreibungen ist in der Dokumentation enthalten.
Überwachen wir die „Gesundheit“ des Systems
Im S-Terra KSH wird der Standard-Daemon snmpd zur Überwachung verwendet. Neben typischen Linux-Parametern unterstützt S-Terra „out of the box“ die Ausgabe von Daten über IPSec-Tunnel gemäß CISCO-IPSEC-FLOW-MONITOR-MIB, die wir verwenden, um den Zustand der IPSec-Tunnel zu überwachen. Zusätzlich wird die Funktionalität von benutzerdefinierten OIDs unterstützt, die als Werte die Ergebnisse der Skriptausführung ausgeben. Diese Möglichkeit erlaubt es uns, die Ablaufdaten von Zertifikaten zu überwachen. Das geschriebene Skript parst die Ausgabe des Befehls. cert_mgr show und gibt somit die Anzahl der Tage bis zum Ablauf der lokalen und der root-Zertifikate an. Diese Methode ist unverzichtbar bei der Verwaltung einer großen Anzahl von Krypto-Systemen.
Was ist der Sinn dieser Verschlüsselung?
Die oben beschriebenen Funktionen werden "out of the box" vom Krypto-System S-Terra unterstützt. Das heißt, es müssen keine zusätzlichen Module installiert werden, die die Zertifizierung der Krypto-Gateways und die Akkreditierung des gesamten Informationssystems beeinträchtigen könnten. Die Verbindungen zwischen den Plattformen können beliebig sein, auch über das Internet.
Da bei Änderungen an der internen Infrastruktur die Krypto-Gateways nicht neu konfiguriert werden müssen, funktioniert das System als Dienstleistung, was für den Kunden sehr praktisch ist: Er kann seine Dienste (Client- und Serverdienste) an beliebigen Adressen platzieren, und alle Änderungen werden dynamisch zwischen der Verschlüsselungshardware übermittelt.
Zweifellos beeinflusst die Verschlüsselung aufgrund von Overhead die Datenübertragungsgeschwindigkeit, jedoch nur geringfügig — die Bandbreite kann um maximal 5–10 % sinken. Die Technologie wurde getestet und zeigte selbst auf Satellitenverbindungen gute Ergebnisse, die ziemlich instabil sind und eine niedrige Bandbreite aufweisen.
Igor Vinokhodov, Ingenieur der 2. Administrationsebene bei «Rostelekom-Solar»
Quelle: habr.com
