Jos yrityksesi lähettää tai vastaanottaa verkon kautta henkilötietoja ja muita luottamuksellisia tietoja, jotka ovat lain mukaan suojattuja, sen on käytettävä GOST-salausta. Tänään kerromme, kuinka toteutimme tällaisen salauksen S-Terra crypto gateway (CS) -yhdyskäytävän perusteella yhdellä asiakkaista. Tämä tarina kiinnostaa tietoturva-asiantuntijoita sekä insinöörejä, suunnittelijoita ja arkkitehteja. Emme sukeltaa syvälle teknisen kokoonpanon vivahteisiin tässä viestissä, vaan keskitymme perusasetuksen avainkohtiin. Internetissä on vapaasti saatavilla valtava määrä dokumentaatiota Linux-käyttöjärjestelmän demonien asettamisesta, joihin S-Terra CS perustuu. Dokumentaatio patentoidun S-Terra-ohjelmiston käyttöönottoa varten on myös julkisesti saatavilla osoitteessa valmistaja.
Muutama sana projektista
Asiakkaan verkkotopologia oli vakio – keskuksen ja haarakonttoreiden välinen verkko. Tietojenvaihtokanavien salaus oli tarpeen ottaa käyttöön kaikkien sivustojen välillä, joita oli 8.
Yleensä tällaisissa projekteissa kaikki on staattista: staattiset reitit sivuston paikallisverkkoon asetetaan salausyhdyskäytäville (CG), IP-osoitteiden (ACL) luettelot salausta varten rekisteröidään. Tässä tapauksessa sivustoilla ei kuitenkaan ole keskitettyä ohjausta, ja niiden paikallisten verkkojen sisällä voi tapahtua mitä tahansa: verkkoja voidaan lisätä, poistaa ja muokata kaikin mahdollisin tavoin. Jotta vältytään reitityksen ja ACL:n uudelleenmäärityksestä KS:ssä, kun paikallisten verkkojen osoitteita muutetaan kohteissa, päätettiin käyttää GRE-tunnelointia ja OSPF dynaamista reititystä, joka sisältää kaikki KS:t ja useimmat reitittimet verkon ydintasolla paikoissa ( Joissakin sivustoissa infrastruktuurin järjestelmänvalvojat suosivat SNAT-protokollaa KS:n sijaan ytimen reitittimissä).
GRE-tunnelointi antoi meille mahdollisuuden ratkaista kaksi ongelmaa:
1. Käytä CS:n ulkoisen liitännän IP-osoitetta salaukseen ACL:ssä, joka kapseloi kaiken muille sivustoille lähetetyn liikenteen.
2. Järjestä ptp-tunneleita CS:iden välillä, jolloin voit määrittää dynaamisen reitityksen (tässä tapauksessa palveluntarjoajan MPLS L3VPN on järjestetty sivustojen välillä).
Asiakas tilasi salauksen käyttöönoton palveluna. Muuten hänen täytyisi paitsi ylläpitää salausyhdyskäytäviä tai ulkoistaa ne jollekin organisaatiolle, myös valvoa itsenäisesti salaussertifikaattien elinkaarta, uusia ne ajoissa ja asentaa uusia.
Ja nyt varsinainen muistio - miten ja mitä määritimme
Huomautus CII-aiheelle: kryptoyhdyskäytävän luominen
Verkon perusasetukset
Ensinnäkin käynnistämme uuden CS:n ja pääsemme hallintakonsoliin. Sinun tulisi aloittaa vaihtamalla sisäänrakennettu järjestelmänvalvojan salasana - komento vaihtaa käyttäjän salasanan ylläpitäjä. Sitten sinun on suoritettava alustusmenettely (komento alustaa), jonka aikana lisenssitiedot syötetään ja satunnaislukuanturi (RNS) alustetaan.
Kiinnitä huomiota! Kun S-Terra CC alustetaan, luodaan suojauskäytäntö, jossa turvayhdyskäytävärajapinnat eivät salli pakettien kulkemista läpi. Sinun on joko luotava oma käytäntö tai käytettävä komentoa suorita csconf_mgr activate aktivoi ennalta määritetty sallimiskäytäntö.
Seuraavaksi sinun on määritettävä ulkoisten ja sisäisten liitäntöjen osoitteet sekä oletusreitti. On suositeltavaa työskennellä CS-verkkokokoonpanon kanssa ja määrittää salaus Ciscon kaltaisen konsolin kautta. Tämä konsoli on suunniteltu syöttämään Cisco IOS -komentoja vastaavia komentoja. Ciscon kaltaisella konsolilla luotu konfiguraatio puolestaan muunnetaan vastaaviksi konfiguraatiotiedostoiksi, joiden kanssa käyttöjärjestelmän demonit toimivat. Voit siirtyä Ciscon kaltaiseen konsoliin hallintakonsolista komennolla määrittää.
Vaihda sisäänrakennettujen käyttäjän csconien salasanat ja ota käyttöön:
> ottaa käyttöön
Salasana: csp (esiasennettu)
#konfiguroi pääte
#username cscons-käyttöoikeus 15 salaisuus 0 #enable secret 0 Verkon perusasetusten määrittäminen:
#interface GigabitEthernet0/0
#ip-osoite 10.111.21.3 255.255.255.0
#ei sammutusta
#interface GigabitEthernet0/1
#ip-osoite 192.168.2.5 255.255.255.252
#ei sammutusta
#ip-reitti 0.0.0.0 0.0.0.0 10.111.21.254
GRE
Poistu Ciscon kaltaisesta konsolista ja siirry debianin komentotulkkiin komennolla järjestelmä. Aseta käyttäjälle oma salasana juuri joukkue passwd.
Jokaisessa valvomossa on erillinen tunneli jokaiselle toimipaikalle. Tunnelin käyttöliittymä on määritetty tiedostossa / Etc / verkko / rajapinnat. IP-tunneliapuohjelma, joka sisältyy esiasennettuun iproute2-sarjaan, vastaa itse käyttöliittymän luomisesta. Käyttöliittymän luontikomento kirjoitetaan pre-up-vaihtoehtoon.
Esimerkki tyypillisestä tunnelirajapinnasta:
autosivusto 1
iface site1 inet staattinen
osoite 192.168.1.4
netmask 255.255.255.254
pre-up ip-tunneli lisää site1 mode gre paikallinen 10.111.21.3 kauko-10.111.22.3 avain hfLYEg^vCh6p
Kiinnitä huomiota! On huomioitava, että tunnelirajapintojen asetusten tulee sijaita osan ulkopuolella
###netifcfg-begin###
*****
###netifcfg-end###
Muuten nämä asetukset korvataan, kun fyysisten liitäntöjen verkkoasetuksia muutetaan Ciscon kaltaisen konsolin kautta.
Dynaaminen reititys
S-Terrassa dynaaminen reititys toteutetaan Quagga-ohjelmistopaketilla. OSPF:n määrittämiseksi meidän on otettava käyttöön ja määritettävä demonit seepra и ospfd. Seepradaemon on vastuussa reititysdemonien ja käyttöjärjestelmän välisestä tiedonsiirrosta. ospfd-daemon, kuten nimestä voi päätellä, on vastuussa OSPF-protokollan toteuttamisesta.
OSPF konfiguroidaan joko demon-konsolin kautta tai suoraan asetustiedoston kautta /etc/quagga/ospfd.conf. Kaikki dynaamiseen reitittämiseen osallistuvat fyysiset ja tunnelirajapinnat lisätään tiedostoon ja ilmoitetaan myös verkot, joita mainostetaan ja jotka saavat ilmoituksia.
Esimerkki kokoonpanosta, johon on lisättävä ospfd.conf:
käyttöliittymä eth0
!
käyttöliittymä eth1
!
käyttöliittymäsivusto 1
!
käyttöliittymäsivusto 2
reititin ospf
ospf-reitittimen tunnus 192.168.2.21
verkko 192.168.1.4/31 alue 0.0.0.0
verkko 192.168.1.16/31 alue 0.0.0.0
verkko 192.168.2.4/30 alue 0.0.0.0
Tässä tapauksessa osoitteet 192.168.1.x/31 on varattu paikkojen välisille tunneli-ptp-verkoille, osoitteet 192.168.2.x/30 CS:n ja ytimen reitittimien välisille siirtoverkoille.
Kiinnitä huomiota! Vähentääksesi reititystaulukkoa suurissa asennuksissa, voit suodattaa itse liikenneverkkojen ilmoitukset käyttämällä rakenteita uudelleenjakoa ei ole kytketty tai jakaa uudelleen yhdistetty reittikartta.
Kun olet määrittänyt demonit, sinun on muutettava demonien käynnistystilaa /etc/quagga/daemons. Vaihtoehdoissa seepra и ospfd ei muutosta kyllä. Käynnistä quagga-daemon ja aseta se automaattisesti käynnistymään, kun käynnistät KS-komennon update-rc.d quagga enable.
Jos GRE-tunnelien ja OSPF:n konfigurointi on tehty oikein, KSh- ja ydinreitittimissä pitäisi näkyä muiden paikkojen verkon reitit ja näin syntyy verkkoyhteys paikallisten verkkojen välillä.
Salaamme siirretyn liikenteen
Kuten on jo kirjoitettu, yleensä sivustojen välisessä salauksessa määritetään IP-osoitealueet (ACL), joiden välillä liikenne salataan: jos lähde- ja kohdeosoite ovat näillä alueilla, niiden välinen liikenne salataan. Tässä projektissa rakenne on kuitenkin dynaaminen ja osoitteet voivat muuttua. Koska olemme jo määrittäneet GRE-tunneloinnin, voimme määrittää ulkoisia KS-osoitteita liikenteen salauksen lähde- ja kohdeosoitteiksi - GRE-protokollan jo kapseloima liikenne saapuu kuitenkin salattavaksi. Toisin sanoen kaikki, mikä tulee CS:ään yhden sivuston paikallisverkosta muiden sivustojen ilmoittamiin verkkoihin, on salattu. Ja jokaisessa sivustossa voidaan suorittaa mikä tahansa uudelleenohjaus. Näin ollen, jos paikallisissa verkoissa tapahtuu muutoksia, järjestelmänvalvojan tarvitsee vain muokata verkosta verkkoon tulevia ilmoituksia, ja ne tulevat muiden sivustojen saataville.
S-Terra CS:n salaus suoritetaan käyttämällä IPSec-protokollaa. Käytämme "Grasshopper"-algoritmia GOST R 34.12-2015 mukaisesti, ja yhteensopivuuden varmistamiseksi vanhempien versioiden kanssa voit käyttää GOST 28147-89:ää. Todennus voidaan teknisesti suorittaa sekä ennalta määritetyille avaimille (PSK) että varmenteille. Teollisessa käytössä on kuitenkin käytettävä GOST R 34.10-2012:n mukaisesti myönnettyjä todistuksia.
Varmenteiden, säilöjen ja CRL-luetteloiden käsittely tapahtuu apuohjelman avulla cert_mgr. Ensinnäkin komennon avulla cert_mgr luo on tarpeen luoda yksityisen avaimen säilö ja varmennepyyntö, joka lähetetään varmenteiden hallintakeskukseen. Varmenteen vastaanottamisen jälkeen se on tuotava yhdessä CA-juurivarmenteen ja CRL:n (jos käytössä) kanssa komennolla cert_mgr tuonti. Voit varmistaa, että kaikki varmenteet ja CRL:t on asennettu komennolla cert_mgr show.
Kun sertifikaatit on asennettu onnistuneesti, siirry Ciscon kaltaiseen konsoliin ja määritä IPSec.
Luomme IKE-käytännön, joka määrittelee luotavan suojatun kanavan halutut algoritmit ja parametrit, jotka tarjotaan kumppanille hyväksyttäväksi.
#crypto isakmp Policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#todennusmerkki
#ryhmä vko2
#elinikä 3600
Tätä käytäntöä sovelletaan luotaessa IPSec:n ensimmäistä vaihetta. Ensimmäisen vaiheen onnistuneen loppuun saattamisen tulos on SA:n (Security Association) perustaminen.
Seuraavaksi meidän on määritettävä luettelo lähde- ja kohde-IP-osoitteista (ACL) salausta varten, luotava muunnosjoukko, luotava salauskartta (crypto map) ja sitova se CS:n ulkoiseen rajapintaan.
Aseta ACL:
#ip-käyttöoikeusluettelon laajennettu sivusto1
#permit gre isäntä 10.111.21.3 isäntä 10.111.22.3
Joukko muunnoksia (sama kuin ensimmäisessä vaiheessa, käytämme "Grasshopper"-salausalgoritmia käyttämällä simulaatiolisäyksen luontitilaa):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Luomme kryptokartan, määritämme ACL:n, muunnosjoukon ja vertaisosoitteen:
#crypto map MAIN 100 ipsec-isakmp
#vastaa osoitesivusto1
#set transform-set GOST
#set peer 10.111.22.3
Sidomme kryptokortin kassakoneen ulkoiseen käyttöliittymään:
#interface GigabitEthernet0/0
#ip-osoite 10.111.21.3 255.255.255.0
#crypto kartta PÄÄ
Jos haluat salata kanavat muiden sivustojen kanssa, sinun on toistettava ACL- ja salauskortin luontimenettely, muutettava ACL-nimeä, IP-osoitteita ja kryptokortin numeroa.
Kiinnitä huomiota! Jos CRL-varmennetta ei käytetä, tämä on määritettävä erikseen:
#crypto pki trustpoint s-terra_technological_trustpoint
#revocation-check ei mitään
Tässä vaiheessa asennusta voidaan pitää valmiina. Ciscon kaltaisessa konsolin komentotulosteessa näytä krypto isakmp sa и näytä krypto ipsec sa Rakennetun IPSec:n ensimmäisen ja toisen vaiheen tulisi näkyä. Samat tiedot saadaan komennolla sa_mgr show, suoritettu debian-kuoresta. Komennon ulostulossa cert_mgr show Etäsivuston varmenteiden pitäisi tulla näkyviin. Tällaisten todistusten tila on kaukosäädin. Jos tunneleita ei rakenneta, sinun on katsottava VPN-palvelulokia, joka on tallennettu tiedostoon /var/log/cspvpngate.log. Täydellinen luettelo lokitiedostoista ja niiden sisällön kuvaus on saatavilla dokumentaatiossa.
Järjestelmän "terveyden" seuranta
S-Terra CC käyttää tavanomaista snmpd-demonia valvontaan. Tyypillisten Linux-parametrien lisäksi valmis S-Terra tukee IPSec-tunneleiden tietojen antamista CISCO-IPSEC-FLOW-MONITOR-MIB:n mukaisesti, jota käytämme IPSec-tunneleiden tilan valvonnassa. Myös mukautettujen OID-tunnusten toimintoja, jotka tulostavat komentosarjan suorittamisen tulokset arvoina, tuetaan. Tämän ominaisuuden avulla voimme seurata varmenteiden vanhenemispäiviä. Kirjoitettu komentosarja jäsentää komennon tulosteen cert_mgr show ja tuloksena antaa päivien määrän paikallisten ja juurivarmenteiden vanhenemiseen. Tämä tekniikka on välttämätön annettaessa suurta määrää CABG:itä.
Mitä hyötyä tällaisesta salauksesta on?
S-Terra KSh tukee kaikkia yllä kuvattuja toimintoja. Eli ei tarvinnut asentaa lisämoduuleja, jotka voisivat vaikuttaa kryptoyhdyskäytävien ja koko tietojärjestelmän sertifiointiin. Sivustojen välillä voi olla mitä tahansa kanavia, jopa Internetin kautta.
Koska sisäinen infrastruktuuri muuttuu, kryptoyhdyskäytäviä ei tarvitse määrittää uudelleen, järjestelmä toimii palveluna, mikä on erittäin kätevä asiakkaalle: hän voi sijoittaa palvelunsa (asiakkaan ja palvelimen) mihin tahansa osoitteeseen, ja kaikki muutokset siirtyvät dynaamisesti salauslaitteiden välillä.
Tietenkin yleiskustannuksista (overhead) johtuva salaus vaikuttaa tiedonsiirtonopeuteen, mutta vain vähän - kanavan läpimenokyky voi laskea enintään 5-10%. Samaan aikaan tekniikkaa on testattu ja se on osoittanut hyviä tuloksia myös satelliittikanavilla, jotka ovat melko epävakaita ja kaistanleveys on pieni.
Igor Vinokhodov, Rostelecom-Solarin 2. hallintolinjan insinööri
Lähde: will.com