Om ditt företag överför eller tar emot personuppgifter och annan konfidentiell information över nätverket som är föremål för skydd i enlighet med lagen, är det skyldigt att använda GOST-kryptering. Idag kommer vi att berätta hur vi implementerade sådan kryptering baserad på S-Terra crypto gateway (CS) hos en av kunderna. Den här historien kommer att vara av intresse för informationssäkerhetsspecialister, såväl som ingenjörer, designers och arkitekter. Vi kommer inte att dyka djupt in i nyanserna i den tekniska konfigurationen i det här inlägget; vi kommer att fokusera på nyckelpunkterna i den grundläggande installationen. Enorma volymer av dokumentation om att installera Linux OS-demoner, som S-Terra CS är baserad på, är fritt tillgängliga på Internet. Dokumentation för att sätta upp proprietär S-Terra-programvara är också allmänt tillgänglig på tillverkaren.
Några ord om projektet
Kundens nätverkstopologi var standard - full mesh mellan centrum och grenar. Det var nödvändigt att införa kryptering av informationsutbyteskanaler mellan alla sajter, av vilka det fanns 8.
Vanligtvis i sådana projekt är allt statiskt: statiska rutter till webbplatsens lokala nätverk ställs in på kryptogateways (CG), listor över IP-adresser (ACL) för kryptering registreras. Men i det här fallet har webbplatserna ingen central kontroll, och allt kan hända i deras lokala nätverk: nätverk kan läggas till, tas bort och modifieras på alla möjliga sätt. För att undvika omkonfigurering av routing och ACL på KS vid ändring av adressering av lokala nätverk på platserna, beslöts att använda GRE-tunneling och OSPF dynamisk routing, som inkluderar alla KS och de flesta routrar på nätverkets kärnnivå på platserna ( på vissa platser föredrog infrastrukturadministratörer att använda SNAT mot KS på kärnroutrar).
GRE-tunnling tillät oss att lösa två problem:
1. Använd IP-adressen för det externa gränssnittet för CS för kryptering i ACL, som kapslar in all trafik som skickas till andra webbplatser.
2. Organisera ptp-tunnlar mellan CS:er, som låter dig konfigurera dynamisk routing (i vårt fall är leverantörens MPLS L3VPN organiserad mellan webbplatserna).
Kunden beordrade implementering av kryptering som en tjänst. Annars skulle han inte bara behöva underhålla krypto-gateways eller lägga ut dem till någon organisation, utan också självständigt övervaka livscykeln för krypteringscertifikat, förnya dem i tid och installera nya.
Och nu själva memo - hur och vad vi konfigurerade
Anmärkning till CII-ämnet: inrätta en krypto-gateway
Grundläggande nätverksinstallation
Först och främst lanserar vi en ny CS och kommer in i administrationskonsolen. Du bör börja med att ändra det inbyggda administratörslösenordet - kommandot ändra administratör för användarlösenord. Sedan måste du utföra initieringsproceduren (kommando initialisera) under vilken licensdata matas in och slumptalssensorn (RNS) initieras.
Var uppmärksam! När S-Terra CC initieras upprättas en säkerhetspolicy där säkerhetsgateway-gränssnitten inte tillåter paket att passera igenom. Du måste antingen skapa din egen policy eller använda kommandot kör csconf_mgr activate aktivera en fördefinierad tillåtande policy.
Därefter måste du konfigurera adresseringen av externa och interna gränssnitt, såväl som standardrutten. Det är att föredra att arbeta med CS-nätverkskonfigurationen och konfigurera kryptering via en Cisco-liknande konsol. Den här konsolen är utformad för att ange kommandon som liknar Cisco IOS-kommandon. Konfigurationen som genereras med den Cisco-liknande konsolen konverteras i sin tur till motsvarande konfigurationsfiler som OS-demonerna arbetar med. Du kan gå till den Cisco-liknande konsolen från administrationskonsolen med kommandot konfigurera.
Ändra lösenord för de inbyggda användarens cscons och aktivera:
>aktivera
Lösenord: csp (förinstallerat)
#configure terminal
#username cscons privilegium 15 hemlighet 0 #aktivera hemlighet 0 Konfigurera den grundläggande nätverkskonfigurationen:
#interface GigabitEthernet0/0
#ip-adress 10.111.21.3 255.255.255.0
#ingen avstängning
#interface GigabitEthernet0/1
#ip-adress 192.168.2.5 255.255.255.252
#ingen avstängning
#ip-rutt 0.0.0.0 0.0.0.0 10.111.21.254
GRE
Avsluta den Cisco-liknande konsolen och gå till debianskalet med kommandot system. Ställ in ditt eget lösenord för användaren rot team passwd.
Vid varje kontrollrum är en separat tunnel konfigurerad för varje plats. Tunnelgränssnittet konfigureras i filen / etc / network / interfaces. IP-tunnelverktyget, som ingår i den förinstallerade iproute2-uppsättningen, är ansvarig för att skapa själva gränssnittet. Kommandot för att skapa gränssnitt skrivs in i pre-up-alternativet.
Exempelkonfiguration av ett typiskt tunnelgränssnitt:
auto webbplats1
iface site1 inet statisk
adress 192.168.1.4
nätmask 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
Var uppmärksam! Det bör noteras att inställningarna för tunnelgränssnitt måste placeras utanför sträckan
###netifcfg-begin###
*****
###netifcfg-end###
Annars kommer dessa inställningar att skrivas över när nätverksinställningarna för fysiska gränssnitt ändras via en Cisco-liknande konsol.
Dynamisk routing
I S-Terra implementeras dynamisk routing med Quaggas mjukvarupaket. För att konfigurera OSPF måste vi aktivera och konfigurera demoner zebra и ospfd. Zebrademonen är ansvarig för kommunikationen mellan routingdemonerna och operativsystemet. Ospfd-demonen, som namnet antyder, är ansvarig för att implementera OSPF-protokollet.
OSPF konfigureras antingen via demonkonsolen eller direkt via konfigurationsfilen /etc/quagga/ospfd.conf. Alla fysiska och tunnelgränssnitt som deltar i dynamisk routing läggs till i filen, och de nätverk som kommer att annonseras och ta emot meddelanden deklareras också.
Ett exempel på konfigurationen som behöver läggas till ospfd.conf:
gränssnitt eth0
!
gränssnitt eth1
!
gränssnittsplats1
!
gränssnittsplats2
ospf router
ospf router-id 192.168.2.21
nätverk 192.168.1.4/31 område 0.0.0.0
nätverk 192.168.1.16/31 område 0.0.0.0
nätverk 192.168.2.4/30 område 0.0.0.0
I det här fallet är adresserna 192.168.1.x/31 reserverade för tunnel-PTP-nätverk mellan platser, adresserna 192.168.2.x/30 tilldelas för transitnätverk mellan CS och kärnroutrar.
Var uppmärksam! För att minska routingtabellen i stora installationer kan du filtrera meddelandet om själva transitnäten med hjälp av konstruktionerna ingen omfördelning ansluten eller omfördela ansluten ruttkarta.
Efter att ha konfigurerat demonerna måste du ändra startstatusen för demonerna i /etc/quagga/daemons. I alternativ zebra и ospfd ingen ändring till ja. Starta quagga-demonen och ställ in den på autorun när du startar KS-kommandot update-rc.d quagga aktivera.
Om konfigurationen av GRE-tunnlar och OSPF görs korrekt, bör rutter i nätverket för andra webbplatser visas på KSh och kärnroutrarna och därmed uppstår nätverksanslutning mellan lokala nätverk.
Vi krypterar överförd trafik
Som redan har skrivits, vanligtvis vid kryptering mellan webbplatser, anger vi IP-adressintervall (ACL) mellan vilka trafiken krypteras: om käll- och destinationsadresserna faller inom dessa intervall, är trafiken mellan dem krypterad. Men i detta projekt är strukturen dynamisk och adresser kan ändras. Eftersom vi redan har konfigurerat GRE-tunnling kan vi ange externa KS-adresser som käll- och destinationsadresser för kryptering av trafik - trots allt kommer trafik som redan är inkapslad av GRE-protokollet för kryptering. Med andra ord, allt som kommer in i CS från det lokala nätverket på en webbplats till nätverk som har meddelats av andra webbplatser är krypterat. Och inom var och en av webbplatserna kan vilken omdirigering som helst utföras. Således, om det sker någon förändring i lokala nätverk, behöver administratören bara ändra meddelandena som kommer från hans nätverk mot nätverket, och det kommer att bli tillgängligt för andra webbplatser.
Kryptering i S-Terra CS utförs med IPSec-protokollet. Vi använder "Grasshopper" -algoritmen i enlighet med GOST R 34.12-2015, och för kompatibilitet med äldre versioner kan du använda GOST 28147-89. Autentisering kan tekniskt sett utföras på både fördefinierade nycklar (PSK) och certifikat. Men i industriell drift är det nödvändigt att använda certifikat utfärdade i enlighet med GOST R 34.10-2012.
Arbetet med certifikat, behållare och CRL:er görs med hjälp av verktyget cert_mgr. Först och främst använder du kommandot cert_mgr skapa det är nödvändigt att generera en privat nyckelbehållare och en certifikatbegäran, som kommer att skickas till Certificate Management Center. Efter att ha mottagit certifikatet måste det importeras tillsammans med rot-CA-certifikatet och CRL (om det används) med kommandot cert_mgr import. Du kan se till att alla certifikat och CRL:er är installerade med kommandot cert_mgr show.
När du har installerat certifikaten, gå till den Cisco-liknande konsolen för att konfigurera IPSec.
Vi skapar en IKE-policy som specificerar de önskade algoritmerna och parametrarna för den säkra kanalen som skapas, som kommer att erbjudas partnern för godkännande.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#autentiseringstecken
#grupp vko2
#livstid 3600
Denna policy tillämpas när man bygger den första fasen av IPSec. Resultatet av framgångsrikt slutförande av den första fasen är inrättandet av SA (Security Association).
Därefter måste vi definiera en lista över käll- och destinations-IP-adresser (ACL) för kryptering, generera en transformeringsuppsättning, skapa en kryptografisk karta (kryptokarta) och binda den till CS:s externa gränssnitt.
Ställ in ACL:
#ip access-list utökad webbplats1
#permit gre värd 10.111.21.3 värd 10.111.22.3
En uppsättning transformationer (samma som för den första fasen använder vi krypteringsalgoritmen "Grasshopper" med hjälp av simuleringsinsättningsgenereringsläget):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Vi skapar en kryptokarta, anger ACL, transformeringsuppsättning och peer-adress:
#kryptkarta MAIN 100 ipsec-isakmp
#match adress webbplats1
#set transform-set GOST
#set peer 10.111.22.3
Vi binder kryptokortet till kassaregistrets externa gränssnitt:
#interface GigabitEthernet0/0
#ip-adress 10.111.21.3 255.255.255.0
#kryptokarta HUVUDSAK
För att kryptera kanaler med andra webbplatser måste du upprepa proceduren för att skapa ett ACL- och kryptokort, ändra ACL-namn, IP-adresser och kryptokortnummer.
Var uppmärksam! Om certifikatverifiering av CRL inte används måste detta uttryckligen anges:
#crypto pki trustpoint s-terra_technological_trustpoint
#återkallelse-kontrollera ingen
Vid denna tidpunkt kan installationen anses vara klar. I Cisco-liknande konsol kommandoutgång visa krypto isakmp sa и visa krypto ipsec sa Den konstruerade första och andra fasen av IPSec bör återspeglas. Samma information kan erhållas med kommandot sa_mgr visa, körs från debians skal. I kommandoutgången cert_mgr show Fjärrplatscertifikaten bör visas. Statusen för sådana certifikat kommer att vara avlägsen. Om tunnlar inte byggs måste du titta på VPN-tjänstloggen, som lagras i filen /var/log/cspvpngate.log. En komplett lista över loggfiler med en beskrivning av deras innehåll finns i dokumentationen.
Övervakning av systemets "hälsa".
S-Terra CC använder standarddemonen snmpd för övervakning. Utöver typiska Linux-parametrar, stöder S-Terra direkt utfärdande av data om IPSec-tunnlar i enlighet med CISCO-IPSEC-FLOW-MONITOR-MIB, vilket är vad vi använder när vi övervakar statusen för IPSec-tunnlar. Funktionaliteten hos anpassade OID som matar ut resultaten av skriptkörning som värden stöds också. Den här funktionen låter oss spåra certifikatets utgångsdatum. Det skrivna skriptet analyserar kommandoutgången cert_mgr show och som ett resultat anger antalet dagar tills det lokala certifikatet och rotcertifikatet löper ut. Denna teknik är oumbärlig vid administrering av ett stort antal CABG.
Vad är fördelen med sådan kryptering?
All funktionalitet som beskrivs ovan stöds direkt av S-Terra KSh. Det vill säga att det inte fanns något behov av att installera några ytterligare moduler som kunde påverka certifieringen av kryptogateways och certifieringen av hela informationssystemet. Det kan finnas vilka kanaler som helst mellan webbplatser, även via Internet.
På grund av det faktum att när den interna infrastrukturen förändras, finns det inget behov av att konfigurera om krypto-gateways, systemet fungerar som en tjänst, vilket är mycket bekvämt för kunden: han kan placera sina tjänster (klient och server) på alla adresser, och alla ändringar kommer att överföras dynamiskt mellan krypteringsutrustning.
Kryptering på grund av overheadkostnader (overhead) påverkar förstås dataöverföringshastigheten, men endast något - kanalgenomströmningen kan minska med max 5-10%. Samtidigt har tekniken testats och visat bra resultat även på satellitkanaler som är ganska instabila och har låg bandbredd.
Igor Vinokhodov, ingenjör för den andra administrationslinjen för Rostelecom-Solar
Källa: will.com