Kui teie ettevõte edastab või saab võrgus isikuandmeid ja muud konfidentsiaalset teavet, mida tuleb kaitsta seadusandluse kohaselt, tuleb rakendada GOST-iga krüptimist. Täna räägime, kuidas rakendasime sellist krüptimist S-Terra krüptoülevaate (KÜ) põhjal ühe kliendi juures. See lugu on huvitav IT-turbe spetsialistidele, aga ka inseneridele, projekteerijatele ja arhitektidele. Me ei süvene tehnilise konfiguratsiooni nüanssidesse — peatume ainult põhiparameetrite seadistamisvõimalustes. Suured kogused dokumentatsiooni Linuxi OS demonite seadistamiseks, millel S-Terra KÜ põhineb, on internetis vabalt kättesaadavad. Dokumentatsioon S-Terra patenteeritud tarkvara seadistamiseks on samuti avatud. tootjalt.
Projektist paari sõnaga
Kliendi võrgutopoloogia oli tüüpiline — full mesh keskuse ja filiaalide vahel. Vaja oli rakendada krüptimine teabevahetuse kanalites kõikide 8 objekti vahel.
Tavaliselt on sarnastes projektides kõik staatiline: krüptoülevaates (KÜ) seadistatakse staatilised marsruudid objekti kohalikus võrgus, määratakse IP-aadresside nimekirjad (ACL) krüptimise jaoks. Kuid antud juhul ei ole objektidel tsentraliseeritud haldust ning nende kohalikes võrkudes võib toimuda kõike: võrke saadakse lisada, eemaldada ja igasuguseid muudatusi teha. Selleks, et vältida marsruutimise ja ACL-i seadistamise ümberseadistamist KÜ-s kohalike võrkude aadresside muutmisel, otsustati kasutada GRE-tunnelit ja dünaamilist OSPF marsruutimist, kuhu on kaasatud kõik KÜd ning enamus tuumaruute objekti võrkudes (mõnedel objektidel eelistasid infrastruktuuri administraatorid KÜ suunas SNAT-i tuumaruuterites).
GRE-tunnelimine võimaldas lahendada kaks ülesannet:
1. Kasutada ACL-is krüptimiseks KÜ välise liidese IP-aadressi, kuhu on kapseldatud kogu liiklus, mis suundub teistele objektidele.
2. Korraldada p-t-p tunnelid KÜde vahel, mis võimaldavad seadistada dünaamilist marsruutimist (meie puhul on objektide vahel korraldatud teenusepakkuja MPLS L3VPN).
Kliendi tellimus oli rakendada krüpteerimist teenusena. Vastasel juhul oleks tal tulnud mitte ainult hallata krüptoväravaid või anda see mingile organisatsioonile allhankesse, vaid ka iseseisvalt jälgida krüptimissertifikaatide elutsüklit, neid õigel ajal pikendada ja uusi paigaldada.
Nüüd, milline on siis meeldetuletus – kuidas ja mida me seadistasime
KII subjekti tähelepanu: seadistame krüptovärava
Võrguhalduse põhiseaded
Esiteks käivitame uue KŠ ja jõuame halduskonsooli. Alustada tasub sisseehitatud administraatori parooli muutmisest - käsk change user password administrator. Seejärel tuleb läbi viia initsialiseerimisprotseduur (käsk initialize) mille käigus sisestatakse litsentsiandmed ja initsialiseeritakse juhuslike arvude generaator (JAG).
Pange tähele! Krüptovärava S-Terra initsialiseerimise käigus kehtestatakse turvapoliitika, mille kohaselt ei luba turvavärava liidesed pakette. On vajalik kas luua enda poliitika või aktiveerida eelnevalt määratud lubav poliitika, kasutades käsku run csconf_mgr activate .
Järgmiseks tuleb seadistada väliste ja sisemiste liideste aadressid ning vaikimisi marsruut. Krüptovärava võrgukonfiguratsiooniga ja krüpteerimise seadistamisega on soovitatav töötada Cisco-sarnases konsoolis. See konsool on mõeldud käskude sisestamiseks, mis on sarnased Cisco IOS-i käskudele. Cisco-sarnases konsoolis vormistatud konfiguratsioon konverteeritakse seejärel vastavatesse konfiguratsioonifailidesse, millega töötavad operatsioonisüsteemi demonid. Cisco-sarnasesse konsolisse saab minna halduskonsoolist käsu kaudu konfigureeri.
Muudame paroolid integreeritud kasutajale cscons ja enable:
>enable
Parool: csp(eelnevalt määratud)
#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
Väljuge Cisco-sarnasest konsoolist ja minge debiani shelli käsuga system. Seame sisseehitatud kasutajale oma parooli root käsklusega passwd.
Iga KŠ jaoks seadistatakse iga asukoha jaoks eraldi tunnel. Tunneliliidese seadistamine toimub failis /etc/network/interfaces. Tunneliliidese loomise eest vastutab IP tunnel utiliit, mis kuulub eelnevalt määratud iproute2 komplekti. Tunneliliidese loomise käsk kirjutatakse pre-up valikusse.
Näide tüüpilise tunneliliidese konfiguratsioonist:
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
Pange tähele! Oluline on märkida, et tunnelite seadistused tuleb paigutada väljapoole sektsiooni
###netifcfg-begin###
*****
###netifcfg-end###
Vastasel juhul kirjutatakse need seadistused üle füüsiliste liideste võrguseadete muutmisel Cisco-taolises konsoolis.
Dünaamiline suunamine
S-Terras on dünaamiline suunamine rakendatud Quagga tarkvarapaketi abil. OSPF-i seadistamiseks on vajalik demonite aktiveerimine ja seadistamine zebra ja ospfd. Zebra demon vastutab suunamisdemonite ja operatsioonisüsteemi vahelise suhtluse eest. Ospfd demon, nagu üldiselt nimest järeldada, vastutab OSPF-protokolli rakendamise eest.
OSPF seadistamine toimub kas demoni konsooli kaudu või otse konfiguratsioonifaili kaudu /etc/quagga/ospfd.conf. Faili lisatakse kõik füüsilised ja tunnelite liidesed, mis osalevad dünaamilises suunamises, samuti kuulutatakse välja võrgud, mis saavad kuulutusi edastada ja vastu võtta.
Konfiguratsiooni näide, mille tuleb lisada ospfd.conf:
liides eth0
!
liides eth1
!
liides site1
!
liides site2
ruuter ospf
ospf ruuter-id 192.168.2.21
võrk 192.168.1.4/31 ala 0.0.0.0
võrk 192.168.1.16/31 ala 0.0.0.0
võrk 192.168.2.4/30 ala 0.0.0.0
Antud juhul on aadressid 192.168.1.x/31 eraldatud tunnelite ptp-võrkude jaoks kohtade vahel, aadressid 192.168.2.x/30 — transiidivõrkude jaoks kesksete ruuterite ja ruutrite vahel.
Pange tähele! Suuremõõtmelistes paigutustes saab marsruutide tabeli vähendamiseks filtreerida transiidivõrkude kuulutamise no redistribute connected või redistribute connected route-map.
Pärast demonite seadistamist peab muutma demonite käivitamise staatust /etc/quagga/daemons. Valikutes zebra ja ospfd no asenda yes-iga. Käivita quagga demon ja seadista selle automaatne käivitamine KŠ käsklusega update-rc.d quagga enable.
Kui GRE-tunnelite ja OSPF seadistamine on õigesti tehtud, siis peaks KŠ-l ja kesksetel ruutritel olema marsruudid teiste kohtade võrkudesse, seega tekib võrgu ühenduvus kohalike võrkude vahel.
Krüpteerime edastatavat liiklust
Nagu juba öeldud, näitame tavaliselt IP-aadresside vahemikke (ACL), mille vahel krüpteeritakse liiklus: kui alg- ja sihtadresse ei pea nende vahemike sisse, siis liiklus nende vahel krüpteeritakse. Kuid selles projektis on struktuur dünaamiline ja aadressid võivad muutuda. Kuna oleme juba seadistanud GRE-tunnelimise, saame krüpteerimise jaoks kasutada väliseid aadresse KSH — sest krüpteerimisele tuleb liiklus, mis on juba GRE-protokolliga kapseldatud. Teisisõnu, krüpteeritakse kõik, mis siseneb KSH-st ühes kohas kohaliku võrgu kaudu teistele võrkudele, mis on reklaamitud teistes kohtades. Ja igas kohas võib toimuda mis tahes adresseerimine. Seega, kui mõni kohalike võrkude muutus toimub, peab administraator lihtsalt kohandama reklaame, mis tulevad tema võrgust KSH suunas, ja see muutub teistele kohtadele kätte saadavaks.
KSH S-Terra krüpteerimine toimub IPSec-protokolli kaudu. Kasutame algoritmi „Kuznechik“ vastavalt GOST R 34.12-2015, ning ühilduvuse tagamiseks vanemate versioonidega võib kasutada GOST 28147-89. Ahituvus võib tehniliselt toimuda kas eeldefineeritud võtmete (PSK) või sertifikaatide alusel. Siiski, tööstuslikuks kasutamiseks on vaja kasutada sertifikaate, mis on välja antud GOST R 34.10-2012 alusel.
Sertifikaatidega, konteineritega ja CRL-iga töötamine toimub utiliidi cert_mgr. Esmalt tuleb käsuga cert_mgr create luua privaatvõtme konteiner ja sertifikaadi taotlus, mis saadetakse sertifikaatide halduskeskusesse. Sertifikaadi saamisel tuleb see koos juursertifikaadi ja CRL-iga (kui see on kasutusel) importida käsuga cert_mgr import. Veenduge, et kõik sertifikaadid ja CRL on installitud, kasutades käsku cert_mgr show.
. Pärast sertifikaatide edukat installimist liigume Cisco-like konsooli, et seadistada IPSec.
Loome IKE-poliitika, milles määratakse soovitud algoritmid ja parameetrid, mida pakkuda partnerile kokkuleppeks.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#authentication sign
#group vko2
#lifetime 3600
Seda poliitikat rakendatakse IPSec esimese etapi loomisel. Esimese etapi eduka läbimise tulemus on SA (Security Association) loomine.
Next, we need to define the list of source and destination IP addresses (ACL) for encryption, create a transformation set, create a crypto map, and attach it to the external interface of the gateway.
Setting the ACL:
#ip access-list extended site1
#permit gre host 10.111.21.3 host 10.111.22.3
Transformation set (as with the first phase, we use the "Grasshopper" encryption algorithm with the MAC mode):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Creating the crypto map, specifying the ACL, transformation set, and peer address:
#crypto map MAIN 100 ipsec-isakmp
#match address site1
#set transform-set GOST
#set peer 10.111.22.3
Attaching the crypto map to the external interface of the gateway:
#interface GigabitEthernet0/0
#ip address 10.111.21.3 255.255.255.0
#crypto map MAIN
To encrypt channels with other sites, it is necessary to repeat the process of creating an ACL and a crypto map, changing the ACL name, IP addresses, and crypto map number.
Pange tähele! If certificate validation via CRL is not used, it must be explicitly stated:
#crypto pki trustpoint s-terra_technological_trustpoint
#revocation-check none
At this point, the configuration can be considered complete. In the output of Cisco-like console commands show crypto isakmp sa ja show crypto ipsec sa the established first and second phases of IPSec should be displayed. This information can also be obtained using the command sa_mgr show, executed from the Debian shell. The output of the command cert_mgr show should show the certificates of remote sites. The status of such certificates will be remote. If tunnels are not built, it is necessary to look into the log VPN-service, which is stored in the file /var/log/cspvpngate.log. A complete list of log files with descriptions of their contents is available in the documentation.
Monitoring the system's 'health'
In the gateway S-Terra, the standard daemon snmpd is used for monitoring. In addition to typical Linux parameters, S-Terra 'out of the box' supports outputting data on IPSec tunnels according to CISCO-IPSEC-FLOW-MONITOR-MIB, which we use to monitor the state of IPSec tunnels. It also supports custom OIDs that output the results of script execution as values. This capability allows us to track the expiration dates of certificates. The script parses the output of the command cert_mgr show and ultimately provides the number of days until the expiration of local and root certificates. This approach is indispensable when administering a large number of gateways.
What is the essence of such encryption?
Kõik ülaltoodud funktsionaalsus on KSH S-Terra juures „kastist välja“ toetatud. See tähendab, et ei olnud vaja installida mingeid lisamooduleid, mis võiksid mõjutada krüptogateide sertifitseerimist ja kogu infosüsteemi atesteerimist. Kanaleid erinevate platvormide vahel võib olla kõike, isegi interneti kaudu.
Tänu sellele, et siseinfrastruktuuri muutmisel ei ole vaja krüptogateid uuesti seadistada. süsteem töötab teenusena, mis on tellija jaoks väga mugav: ta saab oma teenuseid (klient- ja serveriteenused) paigutada mistahes aadressidele ning kõik muudatused edastatakse dünaamiliselt krüpteerimisseadmete vahel.
Ilma igasuguste kahtlusteta mõjutab krüptimine juhtidekulude (overhead) tõttu andmete edastamise kiirus, kuid mitte märkimisväärselt — kanali läbilaskevõime võib langeda maksimaalselt 5–10%. Sellegipoolest on tehnoloogiat testitud ja see on näidanud häid tulemusi isegi satelliitkanalites, mis on üsna ebastabiilsed ja mille läbilaskevõime on madal.
Igor Vinokhodov, 2. taseme halduse insener „Rostelecom-Solar“
Allikas: habr.com
