Kryptering enligt GOST: en guide för inställning av dynamisk trafikdirigering

Om ditt företag överför eller tar emot personuppgifter och annan konfidentiell information som skyddas enligt lag, krävs det att du använder kryptering enligt GOST. I dag kommer vi att berätta hur vi implementerade sådan kryptering baserad på kryptogatewayen (KG) S-Terra för en av våra kunder. Denna historia kommer att vara intressant för informationssäkerhetsspecialister samt ingenjörer, designers och arkitekter. Vi kommer inte att gå djupt in i nyanserna av teknisk konfiguration i detta inlägg - vi kommer att fokusera på de viktigaste punkterna i grundinställningen. Det finns enorma mängder dokumentation för att ställa in Linux-operativsystemets tjänster, som KG S-Terra baseras på, fritt tillgängliga på internet. Dokumentationen för att ställa in den proprietära programvaran S-Terra finns också tillgänglig. portal tillverkaren.

Några ord om projektet

Nätverkstopologin hos kunden var typisk - full mesh mellan centralen och filialerna. Det krävdes att implementera kryptering av informationsutbytena mellan alla platser, vilka var 8 stycken.

Vanligtvis är allt statiskt i sådana projekt: kryptogatewayarna (KG) ställer in statiska rutter i den lokala nätverksplatsen, IP-adresslista (ACL) för kryptering skrivs in. Men i det här fallet finns det ingen centraliserad förvaltning av platserna, och inom deras lokala nätverk kan allt hända: nätverk kan läggas till, tas bort och modifieras på olika sätt. För att undvika omkonfigurering av routing och ACL på KG vid förändringar av adresseringen av de lokala nätverken på platserna, fattades beslutet att använda GRE-tunneling och dynamisk routing OSPF, där alla KG och de flesta kärnrutrar i nätverken på platserna är inkluderade (på vissa platser föredrog infrastrukturen administratörer att använda SNAT mot KG på kärnrutrarna).

GRE-tunneling möjliggjorde att lösa två uppgifter:
1. Använda externa IP-adressen för KG:ns gränsnitt i ACL för kryptering, där all trafik som går till andra platser kapslas in.
2. Organisera p-t-p tunnlar mellan KG, som möjliggör att ställa in dynamisk routing (i vårt fall organiserades en leverantörs MPLS L3VPN mellan platserna).

Kunden har beställt implementering av kryptering som en tjänst. Annars skulle de behöva inte bara hantera kryptogateways eller outsourca till någon organisation, utan också själv följa livscykeln för krypteringscertifikat, förlänga dem i tid och installera nya.

Och nu för själva anteckningen – hur och vad vi har konfigurerat

Till KIIs subjekt: vi konfigurerar kryptogateway

Grundläggande nätverksinställning

Först startar vi den nya KG och kommer in i administrationskonsolen. Det första steget är att ändra lösenordet för den inbyggda administratören — kommandot change user password administrator. Sedan måste vi genomföra initieringsproceduren (kommandot initialize) under vilken licensdata anges och en slumpgenerator (RNG) initieras.

Observera! Vid initiering av KG S-Terra ställs en säkerhetspolicy in, där säkerhetsgatewayens gränssnitt inte släpper igenom paket. Antingen måste man skapa en egen policy, eller använda kommandot run csconf_mgr activate för att aktivera den förinstallerade tillåtande policyn.
Därefter måste vi konfigurera adresseringen för externa och interna gränssnitt, samt standardrutt. Arbetet med nätverkskonfigurationen av KG och krypteringsinställningar bör helst utföras via Cisco-liknande konsol. Denna konsol är avsedd för att ange kommandon som liknar de i Cisco IOS. Konfigurationen, som skapas med hjälp av den Cisco-liknande konsolen, omvandlas i sin tur till motsvarande konfigurationsfiler, som OS-demoner arbetar med. För att gå till Cisco-liknande konsol från administrationskonsolen kan man använda kommandot konfigurera.

Ändra lösenord för den inbyggda användaren cscons och enable:

>enable
Lösenord: csp (standardinställd)
#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

Vi lämnar den Cisco-liknande konsolen och går till Debian-skalet med kommandot system. Vi ställer in ett eget lösenord för användaren root med kommandot passwd.
För varje KG skapas en separat tunnel för varje plats. Konfigurationen av tunnelgränssnittet utförs i filen /etc/network/interfaces. För skapandet av själva gränssnittet ansvarar verktyget IP tunnel, som ingår i den förinstallerade uppsättningen iproute2. Kommandot för att skapa gränssnittet anges i alternativet pre-up.

Exempel på konfiguration av ett typiskt tunnelgränssnitt:
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

Observera! Det bör noteras att inställningar för tunnelgränssnitt måste placeras utanför sektionen

###netifcfg-begin###
*****
###netifcfg-end###

Annars kommer dessa inställningar att raderas vid ändring av nätverksinställningar för fysiska gränssnitt via en Cisco-liknande konsol.

Dynamisk routing

I S-Terra implementeras dynamisk routing med programvarupaketet Quagga. För att konfigurera OSPF behöver vi aktivera och ställa in demonerna zebra och ospfd. Demon zebra ansvarar för interaktionen mellan routingdemoner och operativsystemet. Demon ospfd, som namnet antyder, ansvarar för implementeringen av OSPF-protokollet.
Konfiguration av OSPF görs antingen via demonens konsol eller direkt genom konfigurationsfilen /etc/quagga/ospfd.conf. Filen måste inkludera alla fysiska och tunnelgränssnitt som deltar i dynamisk routing samt de nätverk som ska annonseras och ta emot annonseringar.

Exempelkonfiguration som måste läggas till i 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

I detta fall är adresserna 192.168.1.x/31 avsedda för tunnel-ptp-nätverk mellan platserna, adresserna 192.168.2.x/30 — för transitnät mellan KSH och kärnrouter.

Observera! För att minska routingtabellen i stora installationer kan annonsering av själva transitnäten filtreras med hjälp av konstruktionerna no redistribute connected eller redistribute connected route-map.

Efter att demonerna har konfigurerats måste startstatus ändras i /etc/quagga/daemons. I alternativen zebra och ospfd ändra no till yes. Starta demon quagga och ställ in dess automatisk start vid systemstart med kommandot update-rc.d quagga enable.

Om inställningen av GRE-tunnlar och OSPF har genomförts korrekt, kommer rutter i nätverket för de andra platserna att visas på KSH och kärnroutrarna och därmed uppnås nätverksanslutning mellan de lokala näten.

Vi krypterar den överförda trafiken

Som redan nämnts, anger vi vanligtvis IP-adressintervall (ACL) mellan plattformar vid kryptering, för att trafik ska krypteras: om käll- och mottagaradresserna faller inom dessa intervaller, krypteras trafiken mellan dem. Men i detta projekt är strukturen dynamisk och adresserna kan ändras. Eftersom vi redan har konfigurerat GRE-tunneling, kan vi använda externa adresser till KSH som käll- och mottagaradresser för att kryptera trafiken — eftersom trafiken som anländer redan är inkapslad med GRE-protokollet. Med andra ord krypteras allt som går in i KSH från det lokala nätverket på en plattform mot nätverket som har annonserats av andra plattformar. Inom varje plattform kan dock vilken omdirigering som helst utföras. Därför, om några lokala nätverk ändras, räcker det för administratören att modifiera annonserna som går från hans nätverk till KSH, och den blir tillgänglig för andra plattformar.

Kryptering i KSH S-Terra utförs via protokollet IPSec. Vi använder algoritmen "Kuznechik" enligt GOST R 34.12-2015, och för kompatibilitet med äldre versioner kan GOST 28147-89 användas. Autentisering kan tekniskt sett utföras både med fördefinierade nycklar (PSK) och med certifikat. I praktisk användning är det dock nödvändigt att använda certifikat som utfärdats enligt GOST R 34.10-2012.

Arbetet med certifikat, containrar och CRL utförs med hjälp av verktyget cert_mgr. Först och främst, med hjälp av kommandot cert_mgr create är det nödvändigt att skapa en behållare för den privata nyckeln och en begäran om certifikat som kommer att skickas till certifikathanteringscentralen. Efter att certifikatet har mottagits ska det tillsammans med rotcertifikatet från CA och CRL (om det används) importeras med kommandot cert_mgr import. För att vara säker på att alla certifikat och CRL har installerats kan kommandot användas cert_mgr show.

. Efter att certifikaten har installerats framgångsrikt går vi vidare till Cisco-liknande konsol för att konfigurera IPSec.
Vi skapar en IKE-politik där önskade algoritmer och parametrar för den skyddade kanalen anges, som kommer att föreslås för partnern för överenskommelse.

#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#authentication sign
#group vko2
#lifetime 3600

Denna policy tillämpas vid uppbyggnaden av den första fasen av IPSec. Resultatet av en framgångsrik genomgång av den första fasen är etableringen av SA (Security Association).
Nästa steg är att ange en lista med IP-adresser för källan och mottagaren (ACL) för kryptering, skapa en transformationsuppsättning (transform set), skapa en kryptografisk karta (crypto map) och koppla den till den externa gränssnittet av KG.

Ange ACL:
#ip access-list extended site1
#permit gre host 10.111.21.3 host 10.111.22.3

Transformationsuppsättning (precis som i den första fasen, använder vi krypteringsalgoritmen "Kuznets" med imitskapsläge):

#crypto ipsec transform-set GOST esp-gost341215k-mac

Vi skapar kryptokartan, anger ACL, transform set och peer-adressen:

#crypto map MAIN 100 ipsec-isakmp
#match address site1
#set transform-set GOST
#set peer 10.111.22.3

Vi kopplar kryptokartan till den externa gränssnittet av KG:

#interface GigabitEthernet0/0
#ip address 10.111.21.3 255.255.255.0
#crypto map MAIN

För att kryptera kanaler med andra platser måste proceduren för att skapa ACL och kryptokartan upprepas, med ändrade namn på ACL, IP-adresser och nummer på kryptokartan.

Observera! Om certifikatkontroll via CRL inte används, måste detta anges uttryckligen:

#crypto pki trustpoint s-terra_technological_trustpoint
#revocation-check none

Nu kan inställningen anses vara slutförd. I utskriften av Cisco-liknande konsol show crypto isakmp sa och show crypto ipsec sa bör de uppbyggda första och andra faserna av IPSec återspeglas. Denna information kan också erhållas med kommandot sa_mgr show, utförd från debian shell. I utskriften av kommandot cert_mgr show bör certifikaten för de fjärran platserna visas. Statusen för sådana certifikat kommer att vara remote. Om tunnlarna inte byggs måste man titta i loggen VPN-tjänsten, som lagras i filen /var/log/cspvpngate.log. En fullständig lista över loggfiler med beskrivning av deras innehåll finns i dokumentationen.

Övervaka "hälsan" hos systemet

I KG S-Terra används den standardmässiga demon snmpd för övervakning. Förutom typiska Linux-parametrar stöder S-Terra "out of the box" att ge data om IPSec-tunnlar enligt CISCO-IPSEC-FLOW-MONITOR-MIB, som vi använder för att övervaka tillståndet för IPSec-tunnlar. Funktionaliteten för anpassade OID:er stöds också, som returnerar resultat från körningen av skriptet som värden. Denna funktion gör att vi kan övervaka utgångstiderna för certifikat. Det skrivna skriptet analyserar utskriften av kommandot cert_mgr show och ger som resultat antalet dagar kvar till utgång av lokala och rotcertifikat. Denna metod är ovärderlig vid administrationen av ett stort antal KG.

Vad är syftet med sådan kryptering?

All the functionality described above is supported out of the box by the S-Terra Crypto Gateway. This means that no additional modules had to be installed that could affect the certification of the crypto gateways and the accreditation of the entire information system. The channels between sites can be anything, even via the internet.

Thanks to the fact that internal infrastructure changes do not require reconfiguring the crypto gateways, the system operates as a service, which is very convenient for the client: they can place their services (both client and server) at any addresses, and all changes will be dynamically transmitted between the encryption equipment.

Certainly, encryption due to overhead impacts the speed of data transmission, but only slightly — the bandwidth of the channel may decrease by a maximum of 5-10%. At the same time, the technology has been tested and has shown good results even on satellite channels, which are rather unstable and have low bandwidth.

Igor Vinokhodov, second-line administration engineer at "Rostelecom-Solar"

Källa: habr.com