Hvis din virksomhed transmitterer eller modtager personlige data og andre fortrolige oplysninger over netværket, der er underlagt beskyttelse i henhold til loven, er det påkrævet at bruge GOST-kryptering. I dag vil vi fortælle dig, hvordan vi implementerede en sådan kryptering baseret på S-Terra crypto gateway (CS) hos en af kunderne. Denne historie vil være af interesse for informationssikkerhedsspecialister såvel som ingeniører, designere og arkitekter. Vi vil ikke dykke dybt ned i nuancerne af den tekniske konfiguration i dette indlæg; vi vil fokusere på nøglepunkterne i den grundlæggende opsætning. Enorme mængder af dokumentation om opsætning af Linux OS-dæmoner, som S-Terra CS er baseret på, er frit tilgængelig på internettet. Dokumentation for opsætning af proprietær S-Terra-software er også offentligt tilgængelig på fabrikant.
Et par ord om projektet
Kundens netværkstopologi var standard - fuld mesh mellem center og filialer. Det var nødvendigt at indføre kryptering af informationsudvekslingskanaler mellem alle websteder, hvoraf der var 8.
Normalt i sådanne projekter er alt statisk: statiske ruter til webstedets lokale netværk indstilles på kryptogateways (CG'er), lister over IP-adresser (ACL'er) til kryptering registreres. Men i dette tilfælde har webstederne ikke centraliseret kontrol, og alt kan ske inde i deres lokale netværk: netværk kan tilføjes, slettes og ændres på alle mulige måder. For at undgå at omkonfigurere routing og ACL på KS'en ved ændring af adresseringen af lokale netværk på webstederne, blev det besluttet at bruge GRE tunneling og OSPF dynamisk routing, som omfatter alle KS og de fleste routere på netværkets kerneniveau på webstederne ( på nogle websteder foretrak infrastrukturadministratorer at bruge SNAT mod KS på kerneroutere).
GRE-tunnelering gjorde det muligt for os at løse to problemer:
1. Brug IP-adressen på CS'ens eksterne grænseflade til kryptering i ACL'en, som indkapsler al trafik sendt til andre websteder.
2. Organiser ptp-tunneler mellem CS'er, som giver dig mulighed for at konfigurere dynamisk routing (i vores tilfælde er udbyderens MPLS L3VPN organiseret mellem webstederne).
Klienten bestilte implementering af kryptering som en tjeneste. Ellers skulle han ikke kun vedligeholde krypto-gateways eller outsource dem til en eller anden organisation, men også uafhængigt overvåge krypteringscertifikaternes livscyklus, forny dem til tiden og installere nye.
Og nu selve notatet - hvordan og hvad vi konfigurerede
Bemærkning til CII-emnet: opsætning af en krypto-gateway
Grundlæggende netværksopsætning
Først og fremmest lancerer vi en ny CS og kommer ind i administrationskonsollen. Du bør starte med at ændre den indbyggede administratoradgangskode - kommando ændre brugeradgangskodeadministrator. Derefter skal du udføre initialiseringsproceduren (kommando initialisere), hvor licensdataene indtastes, og tilfældigt talsensoren (RNS) initialiseres.
Vær opmærksom! Når S-Terra CC initialiseres, etableres en sikkerhedspolitik, hvor sikkerhedsgateway-grænsefladerne ikke tillader pakker at passere igennem. Du skal enten oprette din egen politik eller bruge kommandoen kør csconf_mgr activate aktivere en foruddefineret tilladelsespolitik.
Dernæst skal du konfigurere adresseringen af eksterne og interne grænseflader samt standardruten. Det er at foretrække at arbejde med CS-netværkskonfigurationen og konfigurere kryptering gennem en Cisco-lignende konsol. Denne konsol er designet til at indtaste kommandoer svarende til Cisco IOS-kommandoer. Den konfiguration, der genereres ved hjælp af den Cisco-lignende konsol, konverteres til gengæld til de tilsvarende konfigurationsfiler, som OS-dæmonerne arbejder med. Du kan gå til den Cisco-lignende konsol fra administrationskonsollen med kommandoen konfigurere.
Skift adgangskoder til de indbyggede bruger cscons og aktiver:
> aktivere
Adgangskode: csp (forudinstalleret)
#konfigurer terminal
#brugernavn cscons privilegium 15 hemmelighed 0 #aktiver hemmelighed 0 Opsætning af den grundlæggende netværkskonfiguration:
#interface GigabitEthernet0/0
#ip-adresse 10.111.21.3 255.255.255.0
#ingen nedlukning
#interface GigabitEthernet0/1
#ip-adresse 192.168.2.5 255.255.255.252
#ingen nedlukning
#ip-rute 0.0.0.0 0.0.0.0 10.111.21.254
GRE
Afslut den Cisco-lignende konsol og gå til debian-skallen med kommandoen systemet. Indstil din egen adgangskode til brugeren rod hold passwd.
Ved hvert kontrolrum er der konfigureret en separat tunnel for hvert sted. Tunnelgrænsefladen er konfigureret i filen / etc / network / interfaces. IP-tunnelværktøjet, der er inkluderet i det forudinstallerede iproute2-sæt, er ansvarligt for at skabe selve grænsefladen. Kommandoen til oprettelse af grænseflade er skrevet ind i pre-up-indstillingen.
Eksempel på konfiguration af en typisk tunnelgrænseflade:
auto site1
iface site1 inet statisk
adresse 192.168.1.4
netmask 255.255.255.254
pre-up ip tunnel tilføje site1 mode gre lokal 10.111.21.3 fjernbetjening 10.111.22.3 nøgle hfLYEg^vCh6p
Vær opmærksom! Det skal bemærkes, at indstillingerne for tunnelgrænseflader skal placeres uden for strækningen
###netifcfg-begin###
*****
###netifcfg-end###
Ellers vil disse indstillinger blive overskrevet, når netværksindstillingerne for fysiske grænseflader ændres gennem en Cisco-lignende konsol.
Dynamisk routing
I S-Terra implementeres dynamisk routing ved hjælp af Quagga-softwarepakken. For at konfigurere OSPF skal vi aktivere og konfigurere dæmoner zebra и ospfd. Zebra-dæmonen er ansvarlig for kommunikationen mellem routing-dæmonerne og OS. Ospfd-dæmonen, som navnet antyder, er ansvarlig for implementering af OSPF-protokollen.
OSPF konfigureres enten gennem dæmonkonsollen eller direkte gennem konfigurationsfilen /etc/quagga/ospfd.conf. Alle fysiske og tunnelgrænseflader, der deltager i dynamisk routing, føjes til filen, og de netværk, der vil blive annonceret og modtage meddelelser, er også deklareret.
Et eksempel på den konfiguration, der skal tilføjes ospfd.conf:
grænseflade eth0
!
grænseflade eth1
!
interface site1
!
interface site2
ospf router
ospf router-id 192.168.2.21
netværk 192.168.1.4/31 område 0.0.0.0
netværk 192.168.1.16/31 område 0.0.0.0
netværk 192.168.2.4/30 område 0.0.0.0
I dette tilfælde er adresser 192.168.1.x/31 reserveret til tunnel-ptp-netværk mellem steder, adresser 192.168.2.x/30 er tildelt til transitnetværk mellem CS og kerneroutere.
Vær opmærksom! For at reducere rutetabellen i store installationer kan du filtrere annonceringen af selve transitnetværkene ved hjælp af konstruktionerne ingen omfordeling forbundet eller redistribuere forbundet rute-kort.
Efter at have konfigureret dæmonerne, skal du ændre opstartsstatus for dæmonerne i /etc/quagga/daemons. I muligheder zebra и ospfd ingen ændring til ja. Start quagga-dæmonen og indstil den til autorun, når du starter KS-kommandoen update-rc.d quagga aktivere.
Hvis konfigurationen af GRE-tunneler og OSPF udføres korrekt, så bør ruter i netværket af andre websteder vises på KSh og kerne-routere, og dermed opstår der netværksforbindelse mellem lokale netværk.
Vi krypterer overført trafik
Som det allerede er skrevet, angiver vi normalt IP-adresseintervaller (ACL'er), mellem hvilke trafikken krypteres: hvis kilde- og destinationsadresserne falder inden for disse områder, så er trafikken mellem dem krypteret. I dette projekt er strukturen dog dynamisk, og adresser kan ændre sig. Da vi allerede har konfigureret GRE-tunneling, kan vi angive eksterne KS-adresser som kilde- og destinationsadresser til kryptering af trafik - trods alt kommer trafik, der allerede er indkapslet af GRE-protokollen, til kryptering. Med andre ord er alt, hvad der kommer ind i CS fra det lokale netværk på et websted til netværk, der er blevet annonceret af andre websteder, krypteret. Og inden for hvert af webstederne kan enhver omdirigering udføres. Således, hvis der er nogen ændring i lokale netværk, behøver administratoren kun at ændre de meddelelser, der kommer fra hans netværk til netværket, og de vil blive tilgængelige for andre websteder.
Kryptering i S-Terra CS udføres ved hjælp af IPSec-protokollen. Vi bruger "Grasshopper" -algoritmen i overensstemmelse med GOST R 34.12-2015, og for kompatibilitet med ældre versioner kan du bruge GOST 28147-89. Autentificering kan teknisk set udføres på både foruddefinerede nøgler (PSK'er) og certifikater. Men i industriel drift er det nødvendigt at bruge certifikater udstedt i overensstemmelse med GOST R 34.10-2012.
Arbejdet med certifikater, containere og CRL'er udføres ved hjælp af værktøjet cert_mgr. Først og fremmest ved at bruge kommandoen cert_mgr oprette det er nødvendigt at generere en privat nøglebeholder og en certifikatanmodning, som sendes til Certificate Management Center. Efter modtagelse af certifikatet skal det importeres sammen med rod-CA-certifikatet og CRL (hvis brugt) med kommandoen cert_mgr import. Du kan sikre dig, at alle certifikater og CRL'er er installeret med kommandoen cert_mgr show.
Når du har installeret certifikaterne, skal du gå til den Cisco-lignende konsol for at konfigurere IPSec.
Vi opretter en IKE-politik, der specificerer de ønskede algoritmer og parametre for den sikre kanal, der oprettes, og som vil blive tilbudt partneren til godkendelse.
#crypto isakmp politik 1000
#encr gost341215k
#hash gost341112-512-tc26
#godkendelsestegn
#gruppe vko2
#livstid 3600
Denne politik anvendes ved opbygning af den første fase af IPSec. Resultatet af en vellykket gennemførelse af den første fase er etableringen af SA (Security Association).
Dernæst skal vi definere en liste over kilde- og destinations-IP-adresser (ACL) til kryptering, generere et transformationssæt, oprette et kryptografisk kort (kryptokort) og binde det til CS'ens eksterne grænseflade.
Indstil ACL:
#ip adgangsliste udvidet websted1
#permit gre vært 10.111.21.3 vært 10.111.22.3
Et sæt transformationer (samme som for den første fase, vi bruger "Grasshopper"-krypteringsalgoritmen ved hjælp af simuleringsindsætningsgenereringstilstanden):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Vi opretter et kryptokort, specificerer ACL, transformationssæt og peer-adresse:
#crypto map HOVED 100 ipsec-isakmp
#match adresse site1
#set transform-set GOST
#sæt peer 10.111.22.3
Vi binder kryptokortet til kasseapparatets eksterne grænseflade:
#interface GigabitEthernet0/0
#ip-adresse 10.111.21.3 255.255.255.0
#kryptokort HOVED
For at kryptere kanaler med andre websteder, skal du gentage proceduren for at oprette et ACL- og kryptokort, ændre ACL-navnet, IP-adresserne og kryptokortnummeret.
Vær opmærksom! Hvis certifikatbekræftelse af CRL ikke anvendes, skal dette udtrykkeligt angives:
#crypto pki trustpoint s-terra_technological_trustpoint
#tilbagekaldelse-tjek ingen
På dette tidspunkt kan opsætningen betragtes som afsluttet. I Cisco-lignende konsol kommando output vis krypto isakmp sa и vis krypto ipsec sa Den konstruerede første og anden fase af IPSec bør afspejles. Den samme information kan fås ved hjælp af kommandoen sa_mgr show, udført fra debian shell. I kommandoudgangen cert_mgr show Certifikaterne for fjernwebstedet skulle vises. Status for sådanne certifikater vil være fjern. Hvis der ikke bygges tunneler, skal du se på VPN-tjenesteloggen, som er gemt i filen /var/log/cspvpngate.log. En komplet liste over logfiler med en beskrivelse af deres indhold er tilgængelig i dokumentationen.
Overvågning af systemets "sundhed".
S-Terra CC bruger standard snmpd-dæmonen til overvågning. Ud over typiske Linux-parametre understøtter S-Terra ud af boksen udstedelse af data om IPSec-tunneler i overensstemmelse med CISCO-IPSEC-FLOW-MONITOR-MIB, som er det, vi bruger, når vi overvåger status for IPSec-tunneler. Funktionaliteten af brugerdefinerede OID'er, der udsender resultaterne af scriptudførelse som værdier, understøttes også. Denne funktion giver os mulighed for at spore certifikatets udløbsdatoer. Det skrevne script analyserer kommandoens output cert_mgr show og giver som et resultat antallet af dage, indtil lokal- og rodcertifikatet udløber. Denne teknik er uundværlig ved administration af et stort antal CABG'er.
Hvad er fordelen ved en sådan kryptering?
Al funktionaliteten beskrevet ovenfor understøttes ud af boksen af S-Terra KSh. Det vil sige, at der ikke var behov for at installere yderligere moduler, der kunne påvirke certificeringen af krypto-gateways og certificeringen af hele informationssystemet. Der kan være alle kanaler mellem websteder, selv via internettet.
På grund af det faktum, at når den interne infrastruktur ændres, er der ikke behov for at omkonfigurere krypto-gateways, systemet fungerer som en service, hvilket er meget bekvemt for kunden: han kan placere sine tjenester (klient og server) på alle adresser, og alle ændringer vil blive dynamisk overført mellem krypteringsudstyr.
Kryptering på grund af overheadomkostninger (overhead) påvirker naturligvis dataoverførselshastigheden, men kun lidt - kanalgennemstrømningen kan maksimalt falde med 5-10%. Samtidig er teknologien testet og vist gode resultater selv på satellitkanaler, som er ret ustabile og har lav båndbredde.
Igor Vinokhodov, ingeniør i 2. administrationslinje for Rostelecom-Solar
Kilde: www.habr.com