Wenn Ihr Unternehmen personenbezogene Daten und andere vertrauliche Informationen über das Netzwerk überträgt oder empfängt, die gesetzlich geschützt sind, ist die Verwendung der GOST-Verschlüsselung erforderlich. Heute erzählen wir Ihnen, wie wir eine solche Verschlüsselung auf Basis des S-Terra Crypto Gateway (CS) bei einem unserer Kunden implementiert haben. Diese Geschichte wird sowohl für Informationssicherheitsspezialisten als auch für Ingenieure, Designer und Architekten von Interesse sein. Wir werden in diesem Beitrag nicht tief auf die Nuancen der technischen Konfiguration eingehen, sondern uns auf die Kernpunkte der Grundkonfiguration konzentrieren. Riesige Dokumentationen zum Einrichten von Linux-Betriebssystem-Daemons, auf denen S-Terra CS basiert, sind im Internet frei verfügbar. Die Dokumentation zum Einrichten proprietärer S-Terra-Software ist ebenfalls öffentlich verfügbar unter hersteller.
Ein paar Worte zum Projekt
Die Netzwerktopologie des Kunden war Standard – Full Mesh zwischen dem Zentrum und den Filialen. Es war notwendig, eine Verschlüsselung der Informationsaustauschkanäle zwischen allen Standorten einzuführen, von denen es 8 gab.
Normalerweise ist in solchen Projekten alles statisch: Statische Routen zum lokalen Netzwerk des Standorts werden auf Krypto-Gateways (CGs) eingestellt, Listen von IP-Adressen (ACLs) zur Verschlüsselung werden registriert. Allerdings haben die Standorte in diesem Fall keine zentrale Kontrolle und innerhalb ihrer lokalen Netzwerke kann alles passieren: Netzwerke können auf jede erdenkliche Weise hinzugefügt, gelöscht und geändert werden. Um eine Neukonfiguration von Routing und ACL auf dem KS zu vermeiden, wenn sich die Adressierung lokaler Netzwerke an den Standorten ändert, wurde beschlossen, GRE-Tunneling und dynamisches OSPF-Routing zu verwenden, das alle KS und die meisten Router auf der Netzwerkkernebene an den Standorten umfasst ( An einigen Standorten bevorzugten Infrastrukturadministratoren die Verwendung von SNAT gegenüber KS auf Kernel-Routern.
Durch den GRE-Tunnel konnten wir zwei Probleme lösen:
1. Verwenden Sie die IP-Adresse der externen Schnittstelle des CS zur Verschlüsselung in der ACL, die den gesamten an andere Sites gesendeten Datenverkehr kapselt.
2. Organisieren Sie PTP-Tunnel zwischen CSs, mit denen Sie dynamisches Routing konfigurieren können (in unserem Fall wird das MPLS L3VPN des Anbieters zwischen den Standorten organisiert).
Der Kunde bestellte die Implementierung der Verschlüsselung als Dienstleistung. Andernfalls müsste er nicht nur Krypto-Gateways warten oder an eine Organisation auslagern, sondern auch den Lebenszyklus von Verschlüsselungszertifikaten selbstständig überwachen, diese rechtzeitig erneuern und neue installieren.
Und nun das eigentliche Memo – wie und was wir konfiguriert haben
Hinweis zum CII-Thema: Einrichten eines Krypto-Gateways
Grundlegende Netzwerkeinrichtung
Zunächst starten wir ein neues CS und gelangen in die Administrationskonsole. Sie sollten zunächst das integrierte Administratorkennwort ändern – Befehl Benutzerpasswort ändern Administrator. Anschließend müssen Sie den Initialisierungsvorgang ausführen (Befehl initialisieren), bei dem die Lizenzdaten eingegeben und der Zufallszahlensensor (RNS) initialisiert wird.
Achten Sie! Bei der Initialisierung von S-Terra CC wird eine Sicherheitsrichtlinie festgelegt, bei der die Sicherheits-Gateway-Schnittstellen die Durchleitung von Paketen nicht zulassen. Sie müssen entweder Ihre eigene Richtlinie erstellen oder den Befehl verwenden Führen Sie csconf_mgr activate aus Aktivieren Sie eine vordefinierte Zulassungsrichtlinie.
Als nächstes müssen Sie die Adressierung externer und interner Schnittstellen sowie die Standardroute konfigurieren. Es ist vorzuziehen, mit der CS-Netzwerkkonfiguration zu arbeiten und die Verschlüsselung über eine Cisco-ähnliche Konsole zu konfigurieren. Diese Konsole dient zur Eingabe von Befehlen, die den Cisco IOS-Befehlen ähneln. Die über die Cisco-ähnliche Konsole generierte Konfiguration wird wiederum in die entsprechenden Konfigurationsdateien umgewandelt, mit denen die Betriebssystem-Daemons arbeiten. Mit dem Befehl können Sie von der Verwaltungskonsole aus zur Cisco-ähnlichen Konsole wechseln konfigurieren.
Passwörter für die integrierten Benutzer-CSCONs ändern und aktivieren:
>aktivieren
Passwort: csp (vorinstalliert)
#Terminal konfigurieren
#Benutzername cscons Privileg 15 Geheimnis 0 #Enable Geheimnis 0 Einrichten der grundlegenden Netzwerkkonfiguration:
#Schnittstelle GigabitEthernet0/0
#IP-Adresse 10.111.21.3 255.255.255.0
#keine Abschaltung
#Schnittstelle GigabitEthernet0/1
#IP-Adresse 192.168.2.5 255.255.255.252
#keine Abschaltung
#IP-Route 0.0.0.0 0.0.0.0 10.111.21.254
GRE
Verlassen Sie die Cisco-ähnliche Konsole und gehen Sie mit dem Befehl zur Debian-Shell System. Legen Sie Ihr eigenes Passwort für den Benutzer fest Wurzel Team passwd.
In jedem Kontrollraum wird für jeden Standort ein separater Tunnel konfiguriert. Die Tunnelschnittstelle wird in der Datei konfiguriert / etc / Netzwerk / Schnittstellen. Für die Erstellung der Schnittstelle selbst ist das IP-Tunnel-Dienstprogramm verantwortlich, das im vorinstallierten iproute2-Set enthalten ist. Der Befehl zur Schnittstellenerstellung wird in die Pre-Up-Option geschrieben.
Beispielkonfiguration einer typischen Tunnelschnittstelle:
Auto-Site1
iface site1 inet static
Adresse 192.168.1.4
netmask 255.255.255.254
Pre-up-IP-Tunnel hinzufügen Site1-Modus Gre Local 10.111.21.3 Remote 10.111.22.3 Schlüssel hfLYEg^vCh6p
Achten Sie! Es ist zu beachten, dass die Einstellungen für Tunnelschnittstellen außerhalb des Abschnitts liegen müssen
###netifcfg-begin###
*****
###netifcfg-end###
Andernfalls werden diese Einstellungen überschrieben, wenn die Netzwerkeinstellungen physischer Schnittstellen über eine 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 Daemons aktivieren und konfigurieren Zebra и ospfd. Der Zebra-Daemon ist für die Kommunikation zwischen den 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 konfiguriert /etc/quagga/ospfd.conf. Alle physischen und Tunnelschnittstellen, die am dynamischen Routing teilnehmen, werden der Datei hinzugefügt, und die Netzwerke, die angekündigt werden und Ankündigungen empfangen, werden ebenfalls deklariert.
Ein Beispiel für die Konfiguration, die hinzugefügt werden muss 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 Tunnel-PTP-Netzwerke zwischen Standorten reserviert, die Adressen 192.168.2.x/30 sind für Transitnetzwerke zwischen CS- und Kernel-Routern reserviert.
Achten Sie! Um die Routing-Tabelle in großen Installationen zu reduzieren, können Sie die Ankündigung der Transitnetze selbst mithilfe der Konstrukte filtern keine Umverteilung verbunden oder Verteilen Sie die verbundene Routenkarte neu.
Nachdem Sie die Daemons konfiguriert haben, müssen Sie den Startstatus der Daemons in ändern /etc/quagga/daemons. In Optionen Zebra и ospfd keine Änderung zu ja. Starten Sie den Quagga-Daemon und stellen Sie ihn auf Autorun ein, wenn Sie den KS-Befehl starten update-rc.d quagga aktivieren.
Wenn die Konfiguration von GRE-Tunneln und OSPF korrekt durchgeführt wird, sollten Routen im Netzwerk anderer Standorte auf den KSh- und Core-Router erscheinen und somit eine Netzwerkkonnektivität zwischen lokalen Netzwerken entstehen.
Wir verschlüsseln den übertragenen Datenverkehr
Wie bereits geschrieben, geben wir bei der Verschlüsselung zwischen Standorten normalerweise IP-Adressbereiche (ACLs) an, zwischen denen der Datenverkehr verschlüsselt wird: Wenn die Quell- und Zieladressen innerhalb dieser Bereiche liegen, wird der Datenverkehr zwischen ihnen verschlüsselt. Allerdings ist die Struktur in diesem Projekt dynamisch und Adressen können sich ändern. Da wir das GRE-Tunneling bereits konfiguriert haben, können wir externe KS-Adressen als Quell- und Zieladressen für die Verschlüsselung des Datenverkehrs angeben – schließlich kommt zur Verschlüsselung bereits Datenverkehr an, der bereits durch das GRE-Protokoll gekapselt ist. Mit anderen Worten: Alles, was vom lokalen Netzwerk einer Site in Richtung der von anderen Sites angekündigten Netzwerke in die CS gelangt, wird verschlüsselt. Und innerhalb jeder der Sites kann jede Umleitung durchgeführt werden. Wenn es also zu einer Änderung in lokalen Netzwerken kommt, muss der Administrator nur die Ankündigungen ändern, die von seinem Netzwerk an das Netzwerk gesendet werden, und schon werden sie für andere Standorte verfügbar.
Die Verschlüsselung in S-Terra CS erfolgt über das IPSec-Protokoll. Wir verwenden den „Grasshopper“-Algorithmus gemäß GOST R 34.12-2015, und für die Kompatibilität mit älteren Versionen können Sie GOST 28147-89 verwenden. Die Authentifizierung kann technisch gesehen sowohl mit vordefinierten Schlüsseln (PSKs) als auch mit Zertifikaten durchgeführt werden. Im industriellen Betrieb ist es jedoch erforderlich, Zertifikate zu verwenden, die gemäß GOST R 34.10-2012 ausgestellt wurden.
Die Arbeit mit Zertifikaten, Containern und CRLs erfolgt über das Dienstprogramm cert_mgr. Verwenden Sie zunächst den Befehl cert_mgr erstellen Es ist notwendig, einen privaten Schlüsselcontainer und eine Zertifikatsanforderung zu generieren, die an das Certificate Management Center gesendet werden. Nach Erhalt des Zertifikats muss es zusammen mit dem Root-CA-Zertifikat und der CRL (falls verwendet) mit dem Befehl importiert werden cert_mgr-Import. Mit dem Befehl können Sie sicherstellen, dass alle Zertifikate und CRLs installiert werden cert_mgr anzeigen.
Gehen 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 zu erstellenden sicheren Kanals festlegt und dem Partner zur Genehmigung angeboten wird.
#crypto isakmp-Richtlinie 1000
#encr gost341215k
#hash gost341112-512-tc26
#Authentifizierungszeichen
#Gruppe vko2
#Lebenszeit 3600
Diese Richtlinie wird beim Aufbau der ersten Phase von IPSec angewendet. Das Ergebnis des erfolgreichen Abschlusses der ersten Phase ist die Gründung der SA (Security Association).
Als nächstes müssen wir eine Liste von Quell- und Ziel-IP-Adressen (ACL) für die Verschlüsselung definieren, einen Transformationssatz generieren, eine kryptografische Karte (Kryptokarte) erstellen und diese an die externe Schnittstelle des CS binden.
ACL festlegen:
#IP-Zugriffsliste erweiterte Site1
#permit gre Host 10.111.21.3 Host 10.111.22.3
Eine Reihe von Transformationen (wie in der ersten Phase verwenden wir den Verschlüsselungsalgorithmus „Grasshopper“ unter Verwendung des Simulations-Insert-Generierungsmodus):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Wir erstellen eine Krypto-Map, geben die ACL, den Transformationssatz und die Peer-Adresse an:
#crypto map MAIN 100 ipsec-isakmp
#match-Adresse site1
#set transform-set GOST
#Setze Peer 10.111.22.3
Wir binden die Kryptokarte an die externe Schnittstelle der Kasse:
#Schnittstelle GigabitEthernet0/0
#IP-Adresse 10.111.21.3 255.255.255.0
#Krypto-Karte MAIN
Um Kanäle mit anderen Sites zu verschlüsseln, müssen Sie den Vorgang zum Erstellen einer ACL und einer Kryptokarte wiederholen und dabei den ACL-Namen, die IP-Adressen und die Kryptokartennummer ändern.
Achten Sie! Wenn die Zertifikatsüberprüfung durch CRL nicht verwendet wird, muss dies explizit angegeben werden:
#crypto pki Trustpoint s-terra_technological_trustpoint
#revocation-check keine
An diesem Punkt kann die Einrichtung als abgeschlossen betrachtet werden. In einer Cisco-ähnlichen Konsolenbefehlsausgabe Krypto isakmp sa anzeigen и Krypto IPSec SA anzeigen Die konstruierten ersten und zweiten Phasen von IPSec sollten berücksichtigt werden. Die gleichen Informationen können mit dem Befehl abgerufen werden sa_mgr anzeigen, ausgeführt von der Debian-Shell. In der Befehlsausgabe cert_mgr anzeigen Die Remote-Site-Zertifikate sollten angezeigt werden. Der Status solcher Zertifikate wird sein entfernt. Wenn keine Tunnel aufgebaut werden, müssen Sie sich das VPN-Dienstprotokoll ansehen, das in der Datei gespeichert ist /var/log/cspvpngate.log. Eine vollständige Liste der Protokolldateien mit einer Beschreibung ihres Inhalts finden Sie in der Dokumentation.
Überwachung der „Gesundheit“ des Systems
Der S-Terra CC verwendet zur Überwachung den Standard-snmpd-Daemon. Zusätzlich zu den typischen Linux-Parametern unterstützt S-Terra standardmäßig die Ausgabe von Daten über IPSec-Tunnel gemäß der CISCO-IPSEC-FLOW-MONITOR-MIB, die wir bei der Überwachung des Status von IPSec-Tunneln verwenden. Die Funktionalität benutzerdefinierter OIDs, die die Ergebnisse der Skriptausführung als Werte ausgeben, wird ebenfalls unterstützt. Mit dieser Funktion können wir das Ablaufdatum von Zertifikaten verfolgen. Das geschriebene Skript analysiert die Befehlsausgabe cert_mgr anzeigen und gibt als Ergebnis die Anzahl der Tage an, bis das lokale Zertifikat und das Stammzertifikat ablaufen. Diese Technik ist bei der Verabreichung einer großen Anzahl von CABGs unverzichtbar.
Was ist der Vorteil einer solchen Verschlüsselung?
Alle oben beschriebenen Funktionen werden vom S-Terra KSh standardmäßig 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. Es kann beliebige Kanäle zwischen Standorten geben, auch über das Internet.
Aufgrund der Tatsache, dass bei Änderungen der internen Infrastruktur keine Neukonfiguration von Krypto-Gateways erforderlich ist, Das System arbeitet als Dienst, was für den Kunden sehr praktisch ist: Er kann seine Dienste (Client und Server) an beliebigen Adressen platzieren und alle Änderungen werden dynamisch zwischen Verschlüsselungsgeräten übertragen.
Natürlich wirkt sich die Verschlüsselung aufgrund von Overhead-Kosten (Overhead) auf die Datenübertragungsgeschwindigkeit aus, jedoch nur geringfügig – der Kanaldurchsatz kann um maximal 5-10 % sinken. Gleichzeitig wurde die Technologie getestet und zeigte selbst bei Satellitenkanälen, die ziemlich instabil sind und eine geringe Bandbreite haben, gute Ergebnisse.
Igor Vinokhodov, Ingenieur der 2. Verwaltungslinie von Rostelecom-Solar
Source: habr.com