Wenn Ihr Unternehmen personenbezogene Daten und andere vertrauliche Informationen über das Netzwerk überträgt oder empfängt, die gemäß den gesetzlichen Bestimmungen geschützt werden müssen, ist es erforderlich, die Verschlüsselung nach GOST anzuwenden. Heute erzählen wir, wie wir eine solche Verschlüsselung basierend auf dem Kryptoschreiber (KS) S-Terra bei einem unserer Kunden implementiert haben. Diese Geschichte wird für IT-Sicherheitsspezialisten, Ingenieure, Designer und Architekten von Interesse sein. Wir werden nicht tief in die technischen Konfigurationsdetails eintauchen — wir konzentrieren uns auf die Schlüsselmomente der Grundeinstellung. Es gibt eine riesige Menge an Dokumentation zur Einrichtung von Daemons unter Linux, auf dem der KS S-Terra basiert, die im Internet frei verfügbar ist. Die Dokumentation zur Konfiguration der proprietären Software S-Terra ist ebenfalls öffentlich zugänglich auf des Herstellers.
Ein paar Worte zum Projekt
Die Netzwerktopologie beim Kunden war typisch — Full Mesh zwischen dem Zentrum und den Filialen. Es war erforderlich, die Verschlüsselung der Informationsaustauschkanäle zwischen allen 8 Standorten zu implementieren.
In der Regel ist bei ähnlichen Projekten alles statisch: Auf den Kryptoschreibern (KS) werden statische Routen zum lokalen Netzwerk des Standorts konfiguriert, und IP-Adresslisten (ACL) für die Verschlüsselung werden festgelegt. In diesem Fall gibt es jedoch keine zentrale Verwaltung der Standorte, und innerhalb ihrer lokalen Netzwerke kann alles Mögliche geschehen: Netzwerke können hinzugefügt, gelöscht und in jeglicher Hinsicht modifiziert werden. Um eine Neuanpassung der Routen und ACL auf den KS bei Änderungen der Adressierung der lokalen Netzwerke an den Standorten zu vermeiden, wurde beschlossen, GRE-Tunneling und die dynamische OSPF-Routenplanung zu verwenden, an der alle KS und die meisten Kernnetzwerk-Router an den Standorten beteiligt sind (an einigen Standorten bevorzugten die Infrastrukturadministratoren, SNAT in Richtung KS auf den Kern-Routern zu verwenden).
GRE-Tunneling erlaubte es, zwei Aufgaben zu lösen:
1. Die Verwendung der IP-Adresse der externen Schnittstelle des KS in der ACL für die Verschlüsselung, in der der gesamte Verkehr eingekapselt wird, der an andere Standorte gerichtet ist.
2. Die Organisation von Punkt-zu-Punkt-Tunneln zwischen den KS, die die dynamische Routenplanung ermöglichen (in unserem Fall wurde zwischen den Standorten ein Anbieter-MPLS L3VPN eingerichtet).
Der Kunde hat die Implementierung von Verschlüsselung als Dienstleistung bestellt. Andernfalls müsste er nicht nur Crypto-Gateways unterstützen oder eine externe Organisation beauftragen, sondern auch selbst den Lebenszyklus der Verschlüsselungszertifikate überwachen, sie rechtzeitig verlängern und neue installieren.
Und nun tatsächlich die Anleitung – wie und was wir konfiguriert haben
Hinweis für die kritische Informationsinfrastruktur: Konfigurieren eines Crypto-Gateways
Grundkonfiguration des Netzwerks
Zuerst starten wir das neue CG und gelangen in die Administrationskonsole. Es ist ratsam, das Passwort des integrierten Administrators zu ändern – der Befehl change user password administrator. Danach muss das Initialisierungsverfahren durchgeführt werden (Befehl initialize), bei dem die Lizenzdaten eingegeben und der Zufallszahlengenerator (Zufallszahlengenerator) initialisiert wird.
Bitte beachten Sie! Bei der Initialisierung des CG S-Terra wird eine Sicherheitsrichtlinie festgelegt, bei der die Schnittstellen des Sicherheitsgateways keine Pakete durchlassen. Es ist notwendig, entweder eine eigene Richtlinie zu erstellen oder mit dem Befehl run csconf_mgr activate die Aktivierung der vorinstallierten Erlauben-Richtlinie durchzuführen.
Dann müssen die Adressierung der externen und internen Schnittstellen sowie die Standardroute konfiguriert werden. Die Arbeit mit der Netzwerkkonfiguration des CG und der Einrichtung der Verschlüsselung sollte vorzugsweise ü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 wiederum in die entsprechenden Konfigurationsdateien konvertiert, mit denen die Betriebssystem-Dämonen arbeiten. Um zur Cisco-ähnlichen Konsole von der Administrationskonsole zu wechseln, kann der Befehl configure.
Ändern wir die Passwörter für den integrierten Benutzer cscons und enable:
>enable
Passwort: csp (vorinstalliert)
#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
Wir verlassen die Cisco-ähnliche Konsole und wechseln mit dem Befehl Systemin die Debian-Shell. root Wir setzen ein eigenes Passwort für den Benutzer passwd.
Auf jedem CG wird ein separater Tunnel für jeden Standort konfiguriert. Die Konfiguration des Tunnel-Interfaces erfolgt in der Datei /etc/network/interfaces. Für die Erstellung des Interfaces ist das IP-Tunnel-Utility zuständig, das im vorinstallierten Set von iproute2 enthalten ist. Der Befehl zur Erstellung des Interfaces wird in der Option pre-up festgelegt.
Beispielkonfiguration eines typischen Tunnel-Interfaces:
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 Sie! Es ist zu beachten, dass die Einstellungen der Tunnel-Interfaces außerhalb des Abschnitts liegen müssen.
###netifcfg-begin###
*****
###netifcfg-end###
Andernfalls werden diese Einstellungen beim Ändern der Netzwerkeinstellungen der physischen Interfaces über die Cisco-ähnliche Konsole überschrieben.
Dynamisches Routing
In S-Terra wird dynamisches Routing mit dem Quagga-Softwarepaket realisiert. Um OSPF zu konfigurieren, müssen die Daemons eingeschaltet und eingestellt werden. zebra und ospfd. Der Daemon zebra ist für die Interaktion zwischen den Routing-Daemons und dem Betriebssystem verantwortlich. Der Daemon ospfd ist, wie aus dem Namen ersichtlich, für die Implementierung des OSPF-Protokolls zuständig.
Die OSPF-Konfiguration erfolgt entweder über die Konsole des Daemons oder direkt über die Konfigurationsdatei. /etc/quagga/ospfd.conf. In die Datei werden alle physischen und Tunnel-Interfaces eingefügt, die am dynamischen Routing beteiligt sind, sowie die Netzwerke deklariert, die angekündigt werden und Ankündigungen empfangen werden.
Beispielkonfiguration, die in ospfd.conf:
interface eth0
!
interface eth1
!
interface site1
!
interface site2
router 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
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 dienen Transitnetzwerken zwischen der Steuerungseinheit und den Kernroutern.
Bitte beachten Sie! Um die Routingtabelle in großen Installationen zu reduzieren, können die Ankündigungen der Transitnetzwerke mit Hilfe von Konstruktionen gefiltert werden. no redistribute connected oder redistribute connected route-map.
Nach der Konfiguration der Daemons muss der Startstatus der Daemons in /etc/quagga/daemons. In den Optionen muss zebra und ospfd no in yes geändert werden. Starten Sie den Daemon quagga und stellen Sie sicher, dass er beim Start der Steuerungseinheit automatisch startet mit dem Befehl. update-rc.d quagga enable.
Wenn die Konfiguration von GRE-Tunneln und OSPF korrekt durchgeführt wurde, sollten auf der Steuerungseinheit und den Kernroutern Routen im Netzwerk der anderen Standorte erscheinen und somit eine Netzwerkverbindung zwischen den lokalen Netzwerken hergestellt werden.
Verschlüsseln Sie den übertragenen Datenverkehr
Wie bereits erwähnt, geben wir beim Verschlüsseln zwischen den Standorten normalerweise die IP-Adressbereiche (ACL) an, innerhalb derer 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 für die Verschlüsselung des Datenverkehrs externe Adressen von KSH angeben — denn der Datenverkehr, der verschlüsselt werden soll, kommt bereits kapsuliert im GRE-Protokoll. Mit anderen Worten, es wird alles verschlüsselt, was von einem lokalen Netzwerk eines Standorts in Richtung der von anderen Standorten angekündigten Netzwerke in KSH gelangt. Innerhalb jedes Standorts kann dann jede Art der Weiterleitung erfolgen. Bei Änderungen der lokalen Netzwerke muss der Administrator lediglich die Ankündigungen anpassen, die aus seinem Netzwerk in Richtung KSH gehen, und sie wird für andere Standorte verfügbar sein.
Die Verschlüsselung in KSH S-Terra erfolgt über das IPSec-Protokoll. Wir verwenden den Algorithmus „Grashüpfer“ gemäß GOST R 34.12-2015, für die Kompatibilität mit älteren Versionen kann GOST 28147-89 angewendet werden. Die Authentifizierung kann technisch sowohl mit vorab festgelegten Schlüsseln (PSK) als auch mit Zertifikaten durchgeführt werden. In der industriellen Nutzung müssen jedoch Zertifikate verwendet werden, die gemäß GOST R 34.10-2012 ausgestellt wurden.
Die Arbeit mit Zertifikaten, Containern und CRL erfolgt mit dem 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 Zertifizierungsstelle gesendet wird. Nach Erhalt des Zertifikats müssen dieses zusammen mit dem Stammzertifikat der CA und der CRL (falls verwendet) mit dem Befehl cert_mgr importimportiert werden. Um sicherzustellen, dass alle Zertifikate und die CRL installiert sind, kann der Befehl cert_mgr show.
verwendet werden. Nach erfolgreicher Installation der Zertifikate wechseln wir zu einer Cisco-ähnlichen Konsole zur Konfiguration von IPSec.
Wir erstellen eine IKE-Policy, in der die gewünschten Algorithmen und Parameter des zu erstellenden geschützten Kanals angegeben werden, die dem Partner zur Vereinbarung angeboten werden.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#authentication sign
#group vko2
#lifetime 3600
Diese Richtlinie wird beim Aufbau der ersten Phase von IPSec angewendet. Das erfolgreiche Bestehen der ersten Phase führt zur Einrichtung einer SA (Security Association).
Als Nächstes müssen wir die Liste der Quell- und Ziel-IP-Adressen (ACL) für die Verschlüsselung festlegen, eine Transformationssatz (transform set) erstellen, eine kryptografische Karte (crypto map) anlegen und sie an das externe Interface der KSH binden.
Wir definieren die ACL:
#ip access-list extended site1
#permit gre host 10.111.21.3 host 10.111.22.3
Transformationensatz (genau wie in der ersten Phase verwenden wir den Verschlüsselungsalgorithmus "Käfer" im Modus der Erzeugung von MAC-Einfügungen):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Wir erstellen die kryptografische Karte, geben die ACL, den Transformationssatz 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 kryptografische Karte an das externe Interface der KSH:
#interface GigabitEthernet0/0
#ip address 10.111.21.3 255.255.255.0
#crypto map MAIN
Um Kanäle mit anderen Sites zu verschlüsseln, muss das Verfahren zur Erstellung von ACL und kryptografischen Karten wiederholt werden, wobei die ACL-Bezeichnung, IP-Adressen und die Nummer der kryptografischen Karte geändert werden müssen.
Bitte beachten Sie! Falls kein Zertifikatsprüfungsdienst (CRL) genutzt wird, muss dies ausdrücklich angegeben werden:
#crypto pki trustpoint s-terra_technological_trustpoint
#revocation-check none
Damit kann die Konfiguration als abgeschlossen betrachtet werden. In der Ausgabe der Cisco-ähnlichen Konsole show crypto isakmp sa und show crypto ipsec sa sollten die erstellten ersten und zweiten IPSec-Phasen 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 Sites erscheinen. Der Status dieser Zertifikate wird remote. Falls Tunnel nicht aufgebaut werden, sollte das Protokoll überprüft werden VPN-des Dienstes, das in der Datei gespeichert ist /var/log/cspvpngate.log. Eine vollständige Liste der Logdateien mit ihren Inhalten findet sich in der Dokumentation.
Wir überwachen die "Gesundheit" des Systems
In der KSH S-Terra wird der Standard-Daemon snmpd zur Überwachung verwendet. Neben typischen Linux-Parametern unterstützt S-Terra „out of the box“ die Bereitstellung von Daten zu IPSec-Tunneln gemäß CISCO-IPSEC-FLOW-MONITOR-MIB, was wir nutzen, um den Status der IPSec-Tunnel zu verfolgen. Es wird auch die Funktionalität von benutzerdefinierten OIDs unterstützt, die als Werte Ergebnisse der Ausführung eines Skripts ausgeben. Diese Möglichkeit erlaubt es uns, die Ablauffristen der Zertifikate zu überwachen. Das geschriebene Skript analysiert die Ausgabe des Befehls cert_mgr show und liefert als Ergebnis die Anzahl der Tage bis zum Ablauf der lokalen und der Stammzertifikate. Diese Methode ist unverzichtbar bei der Verwaltung einer großen Anzahl von KSH.
Was ist der Sinn dieser Verschlüsselung?
Die oben beschriebene Funktionalität wird „out of the box“ von der KSH S-Terra unterstützt. Das bedeutet, dass keine zusätzlichen Module installiert werden mussten, die die Zertifizierung der Kryptowallets und die Zulassung des gesamten Informationssystems beeinträchtigen könnten. Die Kanäle zwischen den Plattformen können beliebig sein, auch über das Internet.
Dank der Tatsache, dass bei Änderungen der internen Infrastruktur keine erneute Konfiguration der Kryptowallets erforderlich ist, funktioniert das System als Dienstleistung, was für den Auftraggeber sehr praktisch ist: Er kann seine Dienste (Client- und Serverdienste) an beliebigen Adressen platzieren, und alle Änderungen werden dynamisch zwischen den Verschlüsselungsgeräten übertragen.
Natürlich hat die Verschlüsselung aufgrund von Overhead Einfluss auf die Geschwindigkeit der Datenübertragung, jedoch im geringen Maße – die Bandbreite des Kanals kann sich maximal um 5–10 % verringern. Diese Technologie wurde getestet und hat selbst auf Satellitenkanälen, die ziemlich instabil sind und eine niedrige Bandbreite aufweisen, gute Ergebnisse gezeigt.
Igor Vinokhodov, Ingenieur der 2. Linie der Administration von „Rostelecom-Solar“
Quelle: habr.com
