Hvis din bedrift overfører eller mottar personopplysninger og annen konfidensiell informasjon over nettverket som er underlagt beskyttelse i henhold til loven, er det pålagt å bruke GOST-kryptering. I dag skal vi fortelle deg hvordan vi implementerte slik kryptering basert på S-Terra crypto gateway (CS) hos en av kundene. Denne historien vil være av interesse for informasjonssikkerhetsspesialister, så vel som ingeniører, designere og arkitekter. Vi vil ikke dykke dypt inn i nyansene til den tekniske konfigurasjonen i dette innlegget; vi vil fokusere på hovedpunktene i det grunnleggende oppsettet. Enorme mengder dokumentasjon om å sette opp Linux OS-demoner, som S-Terra CS er basert på, er fritt tilgjengelig på Internett. Dokumentasjon for oppsett av proprietær S-Terra-programvare er også offentlig tilgjengelig på produsenten.
Noen få ord om prosjektet
Kundens nettverkstopologi var standard - full mesh mellom senteret og grenene. Det var nødvendig å innføre kryptering av informasjonsutvekslingskanaler mellom alle nettsteder, hvorav det var 8.
Vanligvis i slike prosjekter er alt statisk: statiske ruter til det lokale nettverket på nettstedet er satt på kryptoporter (CG), lister over IP-adresser (ACL) for kryptering er registrert. Men i dette tilfellet har ikke nettstedene sentralisert kontroll, og alt kan skje i deres lokale nettverk: nettverk kan legges til, slettes og endres på alle mulige måter. For å unngå rekonfigurering av ruting og ACL på KS ved endring av adressering av lokale nettverk på lokalitetene, ble det besluttet å bruke GRE tunneling og OSPF dynamisk ruting, som inkluderer alle KS og de fleste rutere på nettverkskjernenivå på lokalitetene ( på noen nettsteder foretrakk infrastrukturadministratorer å bruke SNAT mot KS på kjernerutere).
GRE-tunnelering tillot oss å løse to problemer:
1. Bruk IP-adressen til det eksterne grensesnittet til CS for kryptering i ACL, som innkapsler all trafikk som sendes til andre nettsteder.
2. Organiser ptp-tunneler mellom CS-er, som lar deg konfigurere dynamisk ruting (i vårt tilfelle er leverandørens MPLS L3VPN organisert mellom nettstedene).
Klienten bestilte implementering av kryptering som en tjeneste. Ellers må han ikke bare vedlikeholde kryptoporter eller sette dem ut til en eller annen organisasjon, men også uavhengig overvåke livssyklusen til krypteringssertifikater, fornye dem i tide og installere nye.
Og nå selve notatet - hvordan og hva vi konfigurerte
Merknad til CII-emnet: sette opp en kryptogateway
Grunnleggende nettverksoppsett
Først av alt lanserer vi en ny CS og kommer inn i administrasjonskonsollen. Du bør begynne med å endre det innebygde administratorpassordet - kommandoen endre brukerpassordadministrator. Deretter må du utføre initialiseringsprosedyren (kommando initialisere) hvor lisensdataene legges inn og tilfeldig tallsensor (RNS) initialiseres.
Vær oppmerksom! Når S-Terra CC initialiseres, etableres en sikkerhetspolicy der grensesnittene for sikkerhetsporten ikke tillater pakker å passere gjennom. Du må enten lage din egen policy eller bruke kommandoen kjør csconf_mgr activate aktivere en forhåndsdefinert tillatelsespolicy.
Deretter må du konfigurere adresseringen av eksterne og interne grensesnitt, samt standardruten. Det er å foretrekke å jobbe med CS-nettverkskonfigurasjonen og konfigurere kryptering gjennom en Cisco-lignende konsoll. Denne konsollen er designet for å legge inn kommandoer som ligner Cisco IOS-kommandoer. Konfigurasjonen som genereres ved hjelp av den Cisco-lignende konsollen, blir på sin side konvertert til de tilsvarende konfigurasjonsfilene som OS-demonene fungerer med. Du kan gå til den Cisco-lignende konsollen fra administrasjonskonsollen med kommandoen konfigurere.
Endre passord for de innebygde bruker-cscons og aktiver:
>aktiver
Passord: csp (forhåndsinstallert)
#configure terminal
#brukernavn cscons privilegium 15 hemmelig 0 #aktiver hemmelig 0 Sette opp den grunnleggende nettverkskonfigurasjonen:
#interface GigabitEthernet0/0
#ip-adresse 10.111.21.3 255.255.255.0
#ingen nedleggelse
#interface GigabitEthernet0/1
#ip-adresse 192.168.2.5 255.255.255.252
#ingen nedleggelse
#ip-rute 0.0.0.0 0.0.0.0 10.111.21.254
GRE
Gå ut av den Cisco-lignende konsollen og gå til debian-skallet med kommandoen system. Sett ditt eget passord for brukeren root team passwd.
Ved hvert kontrollrom er det konfigurert en egen tunnel for hvert sted. Tunnelgrensesnittet er konfigurert i filen / etc / network / grensesnitt. IP-tunnelverktøyet, inkludert i det forhåndsinstallerte iproute2-settet, er ansvarlig for å lage selve grensesnittet. Kommandoen for opprettelse av grensesnitt skrives inn i forhåndsalternativet.
Eksempel på konfigurasjon av et typisk tunnelgrensesnitt:
autoside1
iface site1 inet statisk
adresse 192.168.1.4
nettmaske 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 oppmerksom! Det gjøres oppmerksom på at innstillingene for tunnelgrensesnitt må ligge utenfor strekningen
###netifcfg-begin###
*****
###netifcfg-end###
Ellers vil disse innstillingene bli overskrevet når nettverksinnstillingene til fysiske grensesnitt endres gjennom en Cisco-lignende konsoll.
Dynamisk ruting
I S-Terra implementeres dynamisk ruting ved hjelp av programvarepakken Quagga. For å konfigurere OSPF må vi aktivere og konfigurere demoner zebra и ospfd. Sebrademonen er ansvarlig for kommunikasjonen mellom rutingdemonene og operativsystemet. Ospfd-demonen, som navnet antyder, er ansvarlig for å implementere OSPF-protokollen.
OSPF konfigureres enten gjennom daemon-konsollen eller direkte gjennom konfigurasjonsfilen /etc/quagga/ospfd.conf. Alle fysiske og tunnelgrensesnitt som deltar i dynamisk ruting legges til filen, og nettverkene som vil bli annonsert og motta kunngjøringer er også deklarert.
Et eksempel på konfigurasjonen som må legges til ospfd.conf:
grensesnitt eth0
!
grensesnitt eth1
!
grensesnittside1
!
grensesnittside2
ruter ospf
ospf ruter-id 192.168.2.21
nettverk 192.168.1.4/31 område 0.0.0.0
nettverk 192.168.1.16/31 område 0.0.0.0
nettverk 192.168.2.4/30 område 0.0.0.0
I dette tilfellet er adressene 192.168.1.x/31 reservert for tunnel-PTP-nettverk mellom nettsteder, adressene 192.168.2.x/30 er reservert for transittnettverk mellom CS og kjernerutere.
Vær oppmerksom! For å redusere rutetabellen i store installasjoner kan du filtrere kunngjøringen av selve transittnettverket ved å bruke konstruksjonene ingen redistribuering tilkoblet eller omfordele tilkoblet rutekart.
Etter å ha konfigurert demonene, må du endre oppstartsstatusen til demonene i /etc/quagga/daemons. I alternativer zebra и ospfd ingen endring til ja. Start quagga-demonen og sett den til autorun når du starter KS-kommandoen update-rc.d quagga aktivere.
Hvis konfigurasjonen av GRE-tunneler og OSPF gjøres riktig, bør ruter i nettverket til andre nettsteder vises på KSh og kjerneruterne, og dermed oppstår nettverkstilkobling mellom lokale nettverk.
Vi krypterer overført trafikk
Som allerede skrevet, vanligvis ved kryptering mellom nettsteder, spesifiserer vi IP-adresseområder (ACL) mellom hvilke trafikk krypteres: hvis kilde- og destinasjonsadressene faller innenfor disse områdene, blir trafikken mellom dem kryptert. Men i dette prosjektet er strukturen dynamisk og adresser kan endres. Siden vi allerede har konfigurert GRE-tunnelering, kan vi spesifisere eksterne KS-adresser som kilde- og destinasjonsadresser for kryptering av trafikk - tross alt kommer trafikk som allerede er innkapslet av GRE-protokollen for kryptering. Med andre ord, alt som kommer inn i CS fra det lokale nettverket til ett nettsted til nettverk som har blitt annonsert av andre nettsteder, er kryptert. Og innenfor hvert av nettstedene kan enhver omdirigering utføres. Således, hvis det er noen endring i lokale nettverk, trenger administratoren bare å endre kunngjøringene som kommer fra nettverket hans mot nettverket, og det vil bli tilgjengelig for andre nettsteder.
Kryptering i S-Terra CS utføres ved hjelp av IPSec-protokollen. Vi bruker "Grasshopper" -algoritmen i samsvar med GOST R 34.12-2015, og for kompatibilitet med eldre versjoner kan du bruke GOST 28147-89. Autentisering kan teknisk sett utføres på både forhåndsdefinerte nøkler (PSK-er) og sertifikater. I industriell drift er det imidlertid nødvendig å bruke sertifikater utstedt i samsvar med GOST R 34.10-2012.
Arbeid med sertifikater, containere og CRL-er gjøres ved hjelp av verktøyet cert_mgr. Først av alt, ved å bruke kommandoen cert_mgr opprette det er nødvendig å generere en privat nøkkelbeholder og en sertifikatforespørsel, som sendes til Certificate Management Center. Etter å ha mottatt sertifikatet, må det importeres sammen med rot-CA-sertifikatet og CRL (hvis brukt) med kommandoen cert_mgr import. Du kan sørge for at alle sertifikater og CRL-er er installert med kommandoen cert_mgr show.
Etter å ha installert sertifikatene, gå til den Cisco-lignende konsollen for å konfigurere IPSec.
Vi lager en IKE-policy som spesifiserer de ønskede algoritmene og parametrene for den sikre kanalen som opprettes, som vil bli tilbudt partneren for godkjenning.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#autentiseringsskilt
#gruppe vko2
#livstid 3600
Denne policyen brukes når den første fasen av IPSec bygges. Resultatet av vellykket gjennomføring av den første fasen er etableringen av SA (Security Association).
Deretter må vi definere en liste over kilde- og destinasjons-IP-adresser (ACL) for kryptering, generere et transformasjonssett, lage et kryptografisk kart (kryptokart) og binde det til det eksterne grensesnittet til CS.
Sett ACL:
#ip tilgangsliste utvidet nettsted1
#permit gre vert 10.111.21.3 vert 10.111.22.3
Et sett med transformasjoner (samme som for den første fasen, vi bruker "Grasshopper"-krypteringsalgoritmen ved å bruke simuleringsinnsettingsgenereringsmodusen):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Vi lager et kryptokart, spesifiserer ACL, transformasjonssett og peer-adresse:
#kryptokart HOVED 100 ipsec-isakmp
#match adresse nettsted1
#sett transform-set GOST
#sett peer 10.111.22.3
Vi binder kryptokortet til det eksterne grensesnittet til kassaapparatet:
#interface GigabitEthernet0/0
#ip-adresse 10.111.21.3 255.255.255.0
#kryptokart HOVED
For å kryptere kanaler med andre nettsteder, må du gjenta prosedyren for å opprette et ACL- og kryptokort, endre ACL-navnet, IP-adressene og kryptokortnummeret.
Vær oppmerksom! Hvis sertifikatverifisering av CRL ikke brukes, må dette spesifiseres eksplisitt:
#crypto pki trustpoint s-terra_technological_trustpoint
#opphevelse-sjekk ingen
På dette tidspunktet kan oppsettet anses som fullført. I Cisco-lignende konsoll kommandoutgang vis krypto isakmp sa и vis krypto ipsec sa Den konstruerte første og andre fasen av IPSec bør reflekteres. Den samme informasjonen kan fås ved å bruke kommandoen sa_mgr show, utført fra debian shell. I kommandoutgangen cert_mgr show De eksterne nettstedsertifikatene skal vises. Status for slike sertifikater vil være fjernkontroll. Hvis det ikke bygges tunneler, må du se på VPN-tjenesteloggen, som er lagret i filen /var/log/cspvpngate.log. En fullstendig liste over loggfiler med en beskrivelse av innholdet er tilgjengelig i dokumentasjonen.
Overvåking av "helsen" til systemet
S-Terra CC bruker standard snmpd daemon for overvåking. I tillegg til typiske Linux-parametere, støtter S-Terra ut av esken utstedelse av data om IPSec-tunneler i samsvar med CISCO-IPSEC-FLOW-MONITOR-MIB, som er det vi bruker når vi overvåker statusen til IPSec-tunneler. Funksjonaliteten til egendefinerte OID-er som sender ut resultatene av skriptutførelse som verdier, støttes også. Denne funksjonen lar oss spore sertifikatets utløpsdatoer. Det skrevne skriptet analyserer kommandoutgangen cert_mgr show og gir som et resultat antall dager til det lokale sertifikatet og rotsertifikatet utløper. Denne teknikken er uunnværlig ved administrering av et stort antall CABG-er.
Hva er fordelen med slik kryptering?
All funksjonaliteten beskrevet ovenfor støttes ut av esken av S-Terra KSh. Det vil si at det ikke var behov for å installere noen tilleggsmoduler som kunne påvirke sertifiseringen av kryptoporter og sertifiseringen av hele informasjonssystemet. Det kan være alle kanaler mellom nettsteder, selv via Internett.
På grunn av det faktum at når den interne infrastrukturen endres, er det ikke nødvendig å rekonfigurere kryptoporter, systemet fungerer som en tjeneste, som er veldig praktisk for kunden: han kan plassere sine tjenester (klient og server) på alle adresser, og alle endringer vil bli dynamisk overført mellom krypteringsutstyr.
Selvfølgelig påvirker kryptering på grunn av overheadkostnader (overhead) dataoverføringshastigheten, men bare litt - kanalgjennomstrømningen kan reduseres med maksimalt 5-10%. Samtidig har teknologien blitt testet og vist gode resultater selv på satellittkanaler, som er ganske ustabile og har lav båndbredde.
Igor Vinokhodov, ingeniør for den andre administrasjonslinjen til Rostelecom-Solar
Kilde: www.habr.com