Wenn Ihr Unternehmen personenbezogene Daten und andere vertrauliche Informationen, die gesetzlich geschützt sind, über das Netzwerk überträgt oder empfängt, muss eine Verschlüsselung gemäß GOST angewendet werden. Heute werden wir Ihnen bei einem der Kunden erzählen, wie wir eine solche Verschlüsselung basierend auf dem S-Terra Crypto-Gateway (KS) eingeführt 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 werden uns mit den wichtigsten Punkten der Grundeinstellung befassen. Eine umfangreiche Dokumentation zur Konfiguration der Linux-Betriebssystem-Daemons, auf denen die S-Terra-Datenbank basiert, ist im Internet frei verfügbar. Die proprietäre Software-Konfigurationsdokumentation von S-Terra ist auch
im Herstellerportal öffentlich verfügbar.
Ein paar Worte zum Projekt
Die Netzwerktopologie des Kunden war typisch - vollständige Vernetzung zwischen dem Zentrum und den Niederlassungen. Es war erforderlich, die Verschlüsselung von Informationsaustauschkanälen zwischen allen Standorten einzuführen, von denen es 8 Teile gab.
In solchen Projekten ist normalerweise alles statisch: Auf Crypto-Gateways (KS) werden statische Routen zum lokalen Netzwerk der Site festgelegt und Listen mit IP-Adressen (ACLs) für die Verschlüsselung geschrieben. In diesem Fall verfügen Sites jedoch nicht über eine zentralisierte Verwaltung, und in ihren lokalen Netzwerken kann alles passieren: Netzwerke können auf jede Weise hinzugefügt, gelöscht und geändert werden. Um eine Neukonfiguration von Routing und ACLs zum KS beim Ändern der Adressierung lokaler Netzwerke an den Standorten zu vermeiden, wurde beschlossen, GRE-Tunneling und dynamisches Routing OSPF zu verwenden, das alle KS und die meisten Router der Netzwerkkernebene an den Standorten umfasst (an einigen Standorten bevorzugten Infrastrukturadministratoren Verwenden Sie SNAT in Richtung KS auf Kernel-Routern.
GRE-Tunneling löste zwei Probleme:
1. Verwenden Sie in der ACL zur Verschlüsselung die IP-Adresse der externen KS-Schnittstelle, in der der gesamte an andere Standorte gesendete Datenverkehr gekapselt ist.
2. Organisieren Sie PTP-Tunnel zwischen dem KS, mit denen Sie dynamisches Routing konfigurieren können (in unserem Fall ist der Anbieter MPLS L3VPN zwischen den Standorten organisiert).
Der Client hat die Implementierung der Verschlüsselung als Service angeordnet. Andernfalls müsste er nicht nur Krypto-Gateways unterstützen oder eine Organisation auslagern, sondern auch den Lebenszyklus von Verschlüsselungszertifikaten unabhängig überwachen, diese rechtzeitig erneuern und neue installieren.
Und jetzt das Memo selbst - wie und was haben wir eingerichtet?
KII Betreff Hinweis: Wir konfigurieren ein Krypto-Gateway
Grundlegende Netzwerkeinrichtung
Zunächst starten wir einen neuen Cache und gelangen in die Administrationskonsole. Sie sollten zunächst das Kennwort des integrierten Administrators
ändern - den Befehl zum
Ändern des Benutzerkennwortadministrators . Anschließend muss der Initialisierungsvorgang (der
Initialisierungsbefehl ) ausgeführt werden, bei dem die Lizenzdaten eingegeben und der Zufallszahlensensor (DSN) initialisiert werden.
Beachten Sie! Bei der Initialisierung von S-Terra KS wird eine Sicherheitsrichtlinie erstellt, in der die Security Gateway-Schnittstellen keine Pakete weiterleiten. Sie müssen entweder Ihre eigene Richtlinie erstellen oder den
Befehl run csconf_mgr enable verwenden , um eine vordefinierte Berechtigungsrichtlinie zu aktivieren.
Als Nächstes müssen Sie die Adressierung der externen und internen Schnittstellen sowie die Standardroute konfigurieren. Es ist vorzuziehen, mit der Netzwerkkonfiguration des Caches zu arbeiten und die Verschlüsselung über die Cisco-ähnliche Konsole zu konfigurieren. Diese Konsole dient zur Eingabe von Befehlen, die den Cisco IOS-Befehlen ähneln. Die mit der Cisco-ähnlichen Konsole erstellte Konfiguration wird wiederum in die entsprechenden Konfigurationsdateien konvertiert, mit denen die Betriebssystem-Daemons arbeiten. Mit dem Befehl
configure können Sie von der Administrationskonsole aus zur Cisco-ähnlichen Konsole
wechseln .
Ändern Sie die Kennwörter für die integrierten Benutzer-cscons und aktivieren Sie:
> aktivieren
Passwort: csp (vordefiniert)
# Terminal konfigurieren
#Benutzername cscons Privileg 15 geheim 0 # Geheimnis aktivieren 0 Richten Sie die grundlegende Netzwerkkonfiguration ein:
#interface GigabitEthernet0 / 0
#IP-Adresse 10.111.21.3 255.255.255.0
#kein Herunterfahren
#interface GigabitEthernet0 / 1
# IP-Adresse 192.168.2.5 255.255.255.252
#kein Herunterfahren
#ip route 0.0.0.0 0.0.0.0 10.111.21.254
GRE
Wir verlassen die Cisco-ähnliche Konsole und gehen mit dem
Systembefehl zur Debian-Shell. Legen Sie mit dem Befehl
passwd Ihr eigenes Kennwort für den
Root-Benutzer fest .
Auf jedem KSh wird ein separater Tunnel für jeden Standort konfiguriert. Die Tunnelschnittstelle wird in der Datei
/ etc / network / interfaces konfiguriert. Das IP-Tunnel-Dienstprogramm, das Teil des vordefinierten Satzes von iproute2 ist, ist für die Erstellung der Schnittstelle selbst verantwortlich. Der Befehl zum Erstellen einer Schnittstelle wird in die Pre-Up-Option geschrieben.
Beispielkonfiguration einer typischen Tunnelschnittstelle:
auto site1
iface site1 inet statisch
Adresse 192.168.1.4
Netzmaske 255.255.255.254
Pre-Up IP-Tunnel Site1-Modus hinzufügen gre local 10.111.21.3 remote 10.111.22.3 Schlüssel hfLYEg ^ vCh6p
Beachten Sie! Es ist zu beachten, dass sich die Einstellungen der Tunnelschnittstelle außerhalb des Abschnitts befinden müssen
### netifcfg-begin ###
*****
### netifcfg-end ###
Andernfalls werden diese Einstellungen gelöscht, wenn die Netzwerkeinstellungen der physischen Schnittstellen über die Cisco-ähnliche Konsole geändert werden.
Dynamisches Routing
In S-Terra wird dynamisches Routing mithilfe des Quagga-Softwarepakets implementiert. Um OSPF zu konfigurieren, müssen wir die
Zebra- und
OSPFD-Dämonen aktivieren und konfigurieren. Der Zebra-Daemon ist für die Interaktion zwischen Routing-Daemons und dem Betriebssystem verantwortlich. Der ospfd-Daemon ist, wie der Name schon sagt, für die Implementierung des OSPF-Protokolls verantwortlich.
OSPF wird entweder über die Daemon-Konsole oder direkt über die Konfigurationsdatei
/etc/quagga/ospfd.conf konfiguriert. Alle physischen und Tunnelschnittstellen, die am dynamischen Routing beteiligt sind, werden der Datei hinzugefügt, und Netzwerke werden angekündigt, die angekündigt werden und Ankündigungen erhalten.
Eine Beispielkonfiguration zum Hinzufügen zu
ospfd.conf :
Schnittstelle eth0
!
Schnittstelle eth1
!
Schnittstelle site1
!
Schnittstelle 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 PTP-Tunnelnetzwerke zwischen Standorten reserviert, die Adressen 192.168.2.x / 30 sind für Transitnetzwerke zwischen dem KS und den Kernel-Routern zugewiesen.
Beachten Sie! Um die Routing-Tabelle in großen Installationen zu reduzieren, können Sie die Ansage der Transitnetzwerke selbst filtern, indem Sie die Konstrukte "
Keine Neuverteilung verbunden" oder "
Neu verteilt" verwenden.
Nach dem Einrichten der Daemons müssen Sie den Startstatus des Daemons in
/ etc / quagga / daemons ändern. In den Optionen
zebra und
ospfd nein fix auf ja. Führen Sie den Quagga-Daemon aus und legen Sie seine Autorun fest, wenn Sie den Cache mit dem Befehl
update-rc.d quagga enable starten .
Wenn die GRE-Tunnel und OSPF korrekt konfiguriert sind, sollten Routen zum Netzwerk anderer Standorte auf den KS- und Kernel-Routern angezeigt werden, sodass eine Netzwerkkonnektivität zwischen lokalen Netzwerken entsteht.
Wir verschlüsseln den übertragenen Verkehr
Wie bereits geschrieben, geben wir beim Verschlüsseln zwischen Standorten normalerweise die IP-Adressbereiche (ACLs) 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 das GRE-Tunneling bereits eingerichtet haben, können wir externe KS-Adressen als Quell- und Zieladresse für die Verkehrsverschlüsselung angeben, da für die Verschlüsselung der bereits vom GRE-Protokoll gekapselte Verkehr kommt. Mit anderen Worten, alles, was vom lokalen Netzwerk eines Standorts in die von anderen Standorten angekündigten Netzwerke in den Cache gelangt, wird verschlüsselt. Und bereits innerhalb jeder Site kann eine Weiterleitung durchgeführt werden. Daher reicht es für den Administrator bei jeder Änderung in lokalen Netzwerken aus, die Ansagen zu ändern, die von seinem Netzwerk zur Seite des Netzwerks gehen, und sie werden für andere Sites verfügbar.
Die Verschlüsselung im S-Terra KS erfolgt über das IPSec-Protokoll. Wir verwenden den Grasshopper-Algorithmus gemäß GOST R 34.12-2015. Aus Gründen der Kompatibilität mit älteren Versionen kann GOST 28147-89 verwendet werden. Die Authentifizierung kann technisch sowohl für vordefinierte Schlüssel (PSKs) als auch für Zertifikate durchgeführt werden. Im industriellen Betrieb müssen jedoch Zertifikate verwendet werden, die gemäß GOST R 34.10-2012 ausgestellt wurden.
Die Arbeit mit Zertifikaten, Containern und CRLs wird mit dem Dienstprogramm
cert_mgr ausgeführt . Zunächst müssen Sie mit dem Befehl
cert_mgr create einen privaten Schlüsselcontainer und eine Zertifikatanforderung
erstellen , die an das Certificate Management Center gesendet werden. Nach Erhalt des Zertifikats muss es mit dem
Importbefehl cert_mgr zusammen mit dem
Stammzertifikat der Zertifizierungsstelle und der CRL (falls verwendet) importiert werden. Mit dem Befehl
cert_mgr show können Sie
überprüfen, ob alle Zertifikate und CRLs installiert sind.
Wechseln Sie nach erfolgreicher Installation der Zertifikate zur Cisco-ähnlichen Konsole, um IPSec zu konfigurieren.
Wir erstellen eine IKE-Richtlinie, die die gewünschten Algorithmen und Parameter des erstellten sicheren Kanals angibt, die dem Partner zur Genehmigung angeboten werden.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#Authentifizierungszeichen
#group vko2
#Lebenszeit 3600
Diese Richtlinie gilt für die Erstellung der ersten Phase von IPSec. Der erfolgreiche Abschluss der ersten Phase ist die Gründung der SA (Security Association).
Als Nächstes müssen wir eine Liste der Quell- und Ziel-IP-Adressen (ACLs) für die Verschlüsselung definieren, einen Transformationssatz bilden, eine kryptografische Zuordnung (Crypto Map) erstellen und diese an die externe Schnittstelle des CAB binden.
Legen Sie die ACL fest:
#ip access-list erweiterte site1
#permit gre host 10.111.21.3 host 10.111.22.3
Eine Reihe von Transformationen (sowie für die erste Phase verwenden wir den Grasshopper-Verschlüsselungsalgorithmus im Simulationsmodus):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Erstellen Sie eine Krypto-Map, geben Sie 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 hängen die Kryptokarte an die externe Schnittstelle des CABG an:
#interface GigabitEthernet0 / 0
#IP-Adresse 10.111.21.3 255.255.255.0
#crypto map MAIN
Um Kanäle mit anderen Sites zu verschlüsseln, müssen Sie den Vorgang zum Erstellen von ACLs und Kryptokarten wiederholen und den Namen der ACL, die IP-Adressen und die Kryptokartennummer ändern.
Beachten Sie! Wenn die Überprüfung des CRL-Zertifikats nicht verwendet wird, muss dies explizit angegeben werden:
#crypto pki trustpoint s-terra_technological_trustpoint
# Widerrufsprüfung keine
Diese Einstellung kann als abgeschlossen betrachtet werden. Die Ausgabe der Cisco-ähnlichen Konsolenbefehle
show crypto isakmp sa und
show crypto ipsec sa sollte die konstruierte erste und zweite Phase von IPSec widerspiegeln. Die gleichen Informationen können mit dem Befehl
sa_mgr show abgerufen werden, der von der
Debian- Shell ausgeführt wird. Die Ausgabe des
Befehls cert_mgr show sollte Zertifikate für
Remotestandorte anzeigen . Der Status solcher Zertifikate ist
remote . Falls keine Tunnel erstellt werden, müssen Sie das VPN-Dienstprotokoll
überprüfen , das in der Datei
/var/log/cspvpngate.log gespeichert ist. Eine vollständige Liste der Protokolldateien mit einer Beschreibung ihres Inhalts finden Sie in der Dokumentation.
Überwachen Sie den "Zustand" des Systems
S-Terra KS verwendet zur Überwachung den Standard-snmpd-Daemon. Zusätzlich zu den typischen Linux-Parametern unterstützt S-Terra die Ausgabe von IPSec-Tunneln gemäß CISCO-IPSEC-FLOW-MONITOR-MIB, mit der wir den Status von IPSec-Tunneln überwachen. Die Funktionalität von benutzerdefinierten OIDs wird ebenfalls unterstützt, wobei die Ergebnisse des Skripts als Werte angegeben werden. Mit dieser Funktion können wir das Ablaufdatum von Zertifikaten verfolgen. Das geschriebene Skript analysiert die Ausgabe des
Befehls cert_mgr show und gibt als Ergebnis die Anzahl der Tage vor dem Ablauf des lokalen Zertifikats und des
Stammzertifikats an . Diese Technik ist bei der Verabreichung einer großen Anzahl von CABGs unverzichtbar.
Was ist der Cimus einer solchen Verschlüsselung?
Alle oben beschriebenen Funktionen werden "out of the box" KS S-Terra unterstützt. Das heißt, es mussten keine zusätzlichen Module installiert werden, die sich auf die Zertifizierung von Krypto-Gateways und die Zertifizierung des gesamten Informationssystems auswirken könnten. Kanäle zwischen Websites können beliebig sein, auch über das Internet.
Aufgrund der Tatsache, dass beim Ändern der internen Infrastruktur keine Neukonfiguration von Krypto-Gateways erforderlich ist, arbeitet das
System als Dienst , der für den Kunden sehr praktisch ist: Er kann seine Dienste (Client und Server) an beliebigen Adressen platzieren und alle Änderungen werden dynamisch zwischen den Verschlüsselungsgeräten übertragen.
Natürlich wirkt sich die Verschlüsselung aufgrund von Overhead auf die Datenübertragungsrate aus, jedoch nicht wesentlich - die Kanalbandbreite kann um maximal 5-10% verringert werden. Darüber hinaus wurde die Technologie getestet und zeigte auch auf Satellitenkanälen, die eher instabil sind und eine geringe Bandbreite aufweisen, gute Ergebnisse.
Igor Vinokhodov, Ingenieur der 2. Verwaltungslinie von Rostelecom Solar