Hvis din virksomhed overfører eller modtager personoplysninger og anden fortrolig information, som skal beskyttes i henhold til lovgivningen, er det nødvendigt at anvende kryptering i henhold til GOST. I dag vil vi fortælle, hvordan vi implementerede en sådan kryptering baseret på en kryptogate (KG) S-Terra hos en af vores kunder. Denne historie vil være interessant for informationssikkerhedsspecialister, samt ingeniører, designere og arkitekter. Vi vil ikke dykke dybt ned i nuancerne i den tekniske konfiguration i dette indlæg - vi vil fokusere på nøglepunkterne i den grundlæggende opsætning. Der er store mængder dokumentation tilgængelig online om opsætning af dæmoner i Linux, som KG S-Terra er baseret på. Dokumentation til opsætning af den proprietære software S-Terra findes også frit tilgængelig. producentens side.
Et par ord om projektet
Netværkstopologien hos kunden var typisk - full mesh mellem hovedkontoret og filialerne. Det var nødvendigt at implementere kryptering af informationsudvekslingskanaler mellem alle lokationer, som var 8 i alt.
Normalt er alt statisk i sådanne projekter: der angives statiske ruter i kryptogate (KG) til det lokale netværk på lokationen, og der oprettes IP-adresse lister (ACL) til krypteringen. Men i dette tilfælde har lokationerne ikke centraliseret styring, og der kan ske alt muligt inden for deres lokale netværk: netværk kan tilføjes, fjernes og ændres på forskellige måder. For at undgå omkonfiguration af routing og ACL på KG ved ændringer i adresseringen af de lokale netværk på lokationerne, blev det besluttet at anvende GRE-tunneling og dynamisk routing via OSPF, som inkluderer alle KG'er og de fleste kerneroutere i netværket på lokationerne (på nogle lokaliteter foretrak infrastrukturadministratorerne at bruge SNAT hen mod KG på kernerouterne).
GRE-tunneling løste to opgaver:
1. Brug IP-adressen på KG's eksterne interface i ACL til kryptering, hvori al trafik, der er rettet mod andre lokationer, er indkapslet.
2. Organisere p-t-p tunneler mellem KG'er, som gør det muligt at indstille dynamisk routing (i vores tilfælde er der oprettet en leverandør MPLS L3VPN mellem lokationerne).
Kunden har bestilt implementeringen af kryptering som en tjeneste. Ellers ville han skulle vedligeholde kryptogateways eller outsource til et firma, samt selv overvåge livscyklussen for krypteringscertifikater, forny dem til tiden og installere nye.
Og nu selve huskereglen – hvordan og hvad vi har konfigureret
Hvordan man konfigurerer kryptogatewayen for KII-subjektet
Grundlæggende netværkskonfiguration
Først starter vi den nye KG og kommer ind i administrationskonsollen. Vi skal starte med at ændre adgangskoden for den indbyggede administrator – kommandoen change user password administrator. Derefter skal vi udføre initialiseringsproceduren (kommandoen initialize) hvori licensoplysningerne indtastes og den tilfældige talgenerator (RNG) initialiseres.
Vær opmærksom på! Ved initialisering af KG S-Terra bliver sikkerhedspolitikken fastlagt, hvor interfaces for sikkerhedsgatewayen ikke tillader pakker at passere. Det er nødvendigt enten at oprette sin egen politik eller aktivere den forudindstillede tilladelsespolitik ved hjælp af kommandoen run csconf_mgr activate .
Derefter skal vi konfigurere adresseringen af de eksterne og interne interfaces samt standardruten. Arbejdet med netværkskonfigurationen af KG og krypteringsindstillingen anbefales at blive udført gennem en Cisco-lignende konsol. Denne konsol er designet til at indtaste kommandoer, der minder om Cisco IOS-kommandoer. Konfigurationen, der er dannet ved hjælp af Cisco-lignende konsol, bliver konverteret til de tilsvarende konfigurationsfiler, som operativsystemets dæmoner arbejder med. Man kan skifte til Cisco-lignende konsol fra administrationskonsollen med kommandoen configure.
Ændrer adgangskoderne for den indbyggede bruger cscons og enable:
>enable
Adgangskode: csp (forudindstillet)
#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 forlader den Cisco-lignende konsol og går over til debian shell med kommandoen system. Vi opretter en ny adgangskode for brugeren root med kommandoen passwd.
Der oprettes en separat tunnel for hver placering på hver KG. Konfigurationen af tunnelinterface sker i filen /etc/network/interfaces. Oprettelsen af selve interfacet håndteres af værktøjet IP tunnel, der er en del af det forudindstillede iproute2-sæt. Kommandoen til at oprette interfacet skrives ind i pre-up-optionen.
Eksempel på konfiguration af et typisk tunnelinterface:
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
Vær opmærksom på! Det er vigtigt at bemærke, at indstillingerne for tunnelgrænseflader skal placeres uden for sektionen
###netifcfg-begin###
*****
###netifcfg-end###
Ellers vil disse indstillinger blive overskrevet ved ændringer af netværksindstillinger for de fysiske grænseflader via en Cisco-lignende konsol.
Dynamisk routing
I S-Terra implementeres dynamisk routing ved hjælp af softwarepakken Quagga. For at konfigurere OSPF kræver vi aktivering og opsætning af dæmonerne zebra og ospfd. Dæmonen zebra håndterer kommunikationen mellem routingdæmonerne og operativsystemet. Dæmonen ospfd, som navnet antyder, er ansvarlig for implementeringen af OSPF-protokollen.
Konfigurationen af OSPF udføres enten gennem dæmonens konsol eller direkte via konfigurationsfilen /etc/quagga/ospfd.conf. Filen tilføjer alle fysiske og tunnelgrænseflader, der deltager i den dynamiske routing, samt netværk, der vil blive annonceret og modtage annonceringer.
Eksempel på konfiguration, der skal tilføjes til 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 dette tilfælde er adresserne 192.168.1.x/31 tildelt til punkt-til-punkt tunnel netværk mellem lokationerne, mens adresserne 192.168.2.x/30 er til transitnetværk mellem switchene og kernerouterne.
Vær opmærksom på! For at reducere routingtabellen i større installationer kan annoncering af selve transitnetværkene filtreres med konstruktionerne no redistribute connected eller redistribute connected route-map.
Efter opsætning af dæmonerne skal status for opstart af dæmonerne ændres i /etc/quagga/daemons. Under indstillingerne zebra og ospfd skal no ændres til yes. Start dæmonen quagga og indstil dens automatisk opstart ved systemstart med kommandoen update-rc.d quagga enable.
Hvis opsætningen af GRE-tunneler og OSPF er korrekt udført, skal der vises ruter på switchen og kernerouterne til de øvrige lokationers netværk, hvilket dermed skaber netværksforbindelse mellem de lokale netværk.
Vi krypterer den overførte trafik
Som allerede nævnt, angiver vi normalt IP-adresseområder (ACL) til kryptering mellem platforme, hvor trafikken krypteres: hvis kilde- og destinationsadresser falder inden for disse områder, krypteres trafikken mellem dem. Dog er strukturen i dette projekt dynamisk, og adresserne kan ændre sig. Da vi allerede har opsat GRE-tunneling, kan vi bruge de eksterne adresser fra KSH som kilde- og destinationsadresser til kryptering af trafikken — da trafikken, der krypteres, allerede er indkapslet i GRE-protokollen. Med andre ord, krypteres alt, der kommer ind i KSH fra det lokale netværk af en platform mod netværk, der er annonceret af andre platforme. Inden for hver af platformene kan enhver omdirigering derimod finde sted. Dermed, ved ændringer af lokale netværk, er det tilstrækkeligt for administratoren at ændre annoncerne fra hans netværk mod KSH, og den vil være tilgængelig for andre platforme.
Krypteringen i KSH S-Terra udføres ved hjælp af IPSec-protokollen. Vi bruger algoritmen 'Græshoppe' i overensstemmelse med GOST R 34.12-2015, og for at sikre kompatibilitet med ældre versioner kan GOST 28147-89 anvendes. Autentificering kan teknisk set udføres både på foruddefinerede nøgler (PSK) og på certifikater. Det er dog nødvendigt i industriel drift at anvende certifikater, der er udstedt i henhold til GOST R 34.10-2012.
Arbejdet med certifikater, containere og CRL udføres ved hjælp af værktøjet cert_mgr. Først skal vi bruge kommandoen cert_mgr create til at oprette en container for den private nøgle og en certifikatforespørgsel, der vil blive sendt til Certifikatstyringscentret. Efter modtagelsen af certifikatet skal det importeres sammen med rodcertifikatet fra CA og CRL (hvis det anvendes) ved hjælp af kommandoen cert_mgr import. For at bekræfte, at alle certifikater og CRL er installeret, kan man bruge kommandoen cert_mgr show.
. Efter en vellykket installation af certifikaterne går vi videre til Cisco-lignende konsolen for at konfigurere IPSec.
Vi opretter en IKE-politik, hvor de ønskede algoritmer og parametre for den oprettede sikre kanal angives, som vil blive foreslået til partneren for godkendelse.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#authentication sign
#group vko2
#lifetime 3600
Denne politik anvendes ved opbygningen af den første fase af IPSec. Resultatet af en vellykket gennemførelse af første fase er etableringen af SA (Sikkerhedsforening).
Derefter skal vi definere listen over IP-adresser for kilde og modtager (ACL) til kryptering, danne et sæt af transformationer (transform set), skabe et kryptografisk kort (crypto map) og knytte det til den eksterne interface af KSH.
Vi definerer ACL:
#ip access-list extended site1
#permit gre host 10.111.21.3 host 10.111.22.3
Sæt af transformationer (ligesom for den første fase, bruger vi krypteringsalgoritmen "Græshoppe" i imiteringsindførelsestilstand):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Vi opretter et kryptografisk kort, angiver ACL, transform set og peer-adresse:
#crypto map MAIN 100 ipsec-isakmp
#match address site1
#set transform-set GOST
#set peer 10.111.22.3
Vi knytter det kryptografiske kort til den eksterne interface af KSH:
#interface GigabitEthernet0/0
#ip address 10.111.21.3 255.255.255.0
#crypto map MAIN
For at kryptere kanaler med andre steder skal proceduren til oprettelse af ACL og det kryptografiske kort gentages, ændre navnet på ACL, IP-adresserne og nummeret på det kryptografiske kort.
Vær opmærksom på! I tilfælde af, at der ikke anvendes certifikatkontrol via CRL, skal dette angives eksplicit:
#crypto pki trustpoint s-terra_technological_trustpoint
#revocation-check none
Nu kan konfigurationen betragtes som afsluttet. I output fra Cisco-lignende konsol show crypto isakmp sa og show crypto ipsec sa bør de opbyggede første og anden faser af IPSec afspejles. Disse oplysninger kan også opnås ved hjælp af kommandoen sa_mgr show, udført fra debian shell. I outputtet fra kommandoen cert_mgr show bør certifikaterne for de fjerne placeringer fremgå. Status for sådanne certifikater vil være fjern. I tilfælde af at tunneler ikke opbygges, er det nødvendigt at tjekke loggen VPN-tjenesten, der opbevares i filen /var/log/cspvpngate.log. En komplet liste over logfiler med beskrivelse af deres indhold findes i dokumentationen.
Vi overvåger systemets "sundhed"
I KSH S-Terra bruges den standard daemon snmpd til overvågning. Udover typiske Linux-parametre understøtter S-Terra "out of the box" at udlevere data om IPSec-tunneler i henhold til CISCO-IPSEC-FLOW-MONITOR-MIB, hvilket vi bruger til at overvåge tilstanden af IPSec-tunneler. Der understøttes også funktionalitet til brugerdefinerede OID'er, der returnerer resultatet af scriptudførelse som værdier. Denne funktion giver os mulighed for at overvåge udløbsdatoerne for certifikater. Det skrevne script parser output fra kommandoen cert_mgr show og giver os antallet af dage til udløbet af de lokale og rodcertifikater. Denne tilgang er uundgåelig ved administration af et stort antal KSH.
Hvad er essensen af denne kryptering
Al den beskrevne funktionalitet understøttes "out of the box" i S-Terra CSG. Det vil sige, der var ikke behov for at installere nogen ekstra moduler, der kunne have påvirket certificeringen af kryptogateways og hele informationssystemets attestation. Kanalerne mellem platformene kan være alle slags, selv gennem internettet.
Takket være, at der ikke er behov for at omkonfigurere kryptogateways ved ændringer i den interne infrastruktur, arbejder systemet som en service, hvilket er meget praktisk for kunden: han kan placere sine tjenester (kliente og servere) på enhver adresse, og alle ændringer vil blive overført dynamisk mellem krypteringsudstyret.
Uden tvivl påvirker kryptering på grund af overhead hastigheden for dataoverførsel, men ikke nævneværdigt — båndbredden kan maksimalt falde med 5–10 %. Desuden er teknologien blevet testet og har vist gode resultater, selv på satellitkanaler, som er ret ustabile og har lav båndbredde.
Igor Vinokhodov, 2. linje administrator i "Rostelecom-Solar"
Kilde: habr.com
