Se via kompanio transdonas aŭ ricevas personajn datumojn kaj aliajn konfidencajn informojn per la reto, kiu estas protektata laŭ la leĝo, necesas uzi GOST-ĉifradon. Hodiaŭ ni rakontos al vi kiel ni efektivigis tian ĉifradon bazitan sur la kripta enirejo S-Terra (CS) ĉe unu el la klientoj. Ĉi tiu rakonto estos interesa al specialistoj pri informa sekureco, same kiel inĝenieroj, projektistoj kaj arkitektoj. Ni ne plonĝos profunde en la nuancojn de la teknika agordo en ĉi tiu afiŝo; ni koncentriĝos pri la ĉefaj punktoj de la baza agordo. Grandegaj volumoj da dokumentaro pri starigo de Linuksaj OS-demonoj, sur kiuj baziĝas la S-Terra CS, estas libere haveblaj en la Interreto. Dokumentaro por starigo de proprieta S-Terra programaro ankaŭ estas publike havebla sur fabrikanto.
Kelkajn vortojn pri la projekto
La retotopologio de la kliento estis norma - plena maŝo inter la centro kaj branĉoj. Necesis enkonduki ĉifradon de informinterŝanĝaj kanaloj inter ĉiuj retejoj, el kiuj estis 8.
Kutime en tiaj projektoj ĉio estas senmova: statikaj itineroj al la loka reto de la retejo estas fiksitaj sur kriptaj enirejoj (CGoj), listoj de IP-adresoj (ACLs) por ĉifrado estas registritaj. Tamen, en ĉi tiu kazo, la retejoj ne havas centralizitan kontrolon, kaj io ajn povas okazi ene de siaj lokaj retoj: retoj povas esti aldonitaj, forigitaj kaj modifitaj laŭ ĉiuj eblaj manieroj. Por eviti reagordi vojigon kaj ACL sur la KS dum ŝanĝado de la adresado de lokaj retoj ĉe la ejoj, estis decidite uzi GRE-tuneladon kaj OSPF-dinamikan vojigon, kiu inkluzivas ĉiujn KS kaj la plej multajn enkursigilojn ĉe la reto-kernnivelo ĉe la ejoj ( ĉe kelkaj ejoj, infrastrukturadministrantoj preferis uzi SNAT al KS ĉe kernaj enkursigiloj).
GRE-tunelo permesis al ni solvi du problemojn:
1. Uzu la IP-adreson de la ekstera interfaco de la CS por ĉifrado en la ACL, kiu enkapsuligas la tutan trafikon senditan al aliaj retejoj.
2. Organizi ptp-tunelojn inter CS-oj, kiuj ebligas al vi agordi dinamikan vojigon (en nia kazo, MPLS L3VPN de la provizanto estas organizita inter la retejoj).
La kliento ordonis la efektivigon de ĉifrado kiel servo. Alie, li devus ne nur konservi kriptajn enirejojn aŭ subkontrakti ilin al iu organizo, sed ankaŭ sendepende monitori la vivociklon de ĉifradaj atestiloj, renovigi ilin ĝustatempe kaj instali novajn.
Kaj nun la reala noto - kiel kaj kion ni agordis
Noto al la CII-temo: starigi kriptan enirejon
Baza reta agordo
Antaŭ ĉio, ni lanĉas novan CS kaj eniras la administran konzolon. Vi devus komenci ŝanĝante la enkonstruitan administran pasvorton - komando ŝanĝi uzantan pasvorton administranto. Tiam vi devas plenumi la komencan proceduron (komando pravalorizi) dum kiu la licencdatenoj estas enigitaj kaj la hazarda nombrosensilo (RNS) estas pravigita.
Atentu! Kiam S-Terra CC estas pravigita, sekurecpolitiko estas establita en kiu la sekurecpordejinterfacoj ne permesas pakaĵetojn trapasi. Vi devas aŭ krei vian propran politikon aŭ uzi la komandon rulu csconf_mgr aktivigi aktivigi antaŭdifinitan permespolitikon.
Poste, vi devas agordi la adresadon de eksteraj kaj internaj interfacoj, same kiel la defaŭltan itineron. Estas preferinde labori kun la CS-reta agordo kaj agordi ĉifradon per Cisco-simila konzolo. Ĉi tiu konzolo estas dizajnita por enigi komandojn similajn al Cisco IOS-komandoj. La agordo generita per la Cisco-simila konzolo estas, siavice, konvertita en la respondajn agordajn dosierojn kun kiuj funkcias la OS-demonoj. Vi povas iri al la Cisco-simila konzolo de la administra konzolo kun la komando agordi.
Ŝanĝu pasvortojn por la enkonstruitaj uzantaj cscons kaj ebligu:
> ebligi
Pasvorto: csp (antaŭinstalita)
#agordi terminalon
#username cscons privilegio 15 sekreta 0 #enable secret 0 Agordi la bazan retan agordon:
#interfaco GigabitEthernet0/0
#ip-adreso 10.111.21.3 255.255.255.0
#neniu haltigo
#interfaco GigabitEthernet0/1
#ip-adreso 192.168.2.5 255.255.255.252
#neniu haltigo
#ip itinero 0.0.0.0 0.0.0.0 10.111.21.254
GRE
Eliru la Cisco-similan konzolon kaj iru al la debian-ŝelo kun la komando sistemo. Agordu vian propran pasvorton por la uzanto radikon teamo pasvorto.
Ĉe ĉiu kontrolĉambro, aparta tunelo estas agordita por ĉiu ejo. La tunela interfaco estas agordita en la dosiero / etc / network / interfaces. La IP-tunela utileco, inkluzivita en la antaŭinstalita iproute2 aro, respondecas pri kreado de la interfaco mem. La komando pri kreado de interfaco estas skribita en la antaŭ-supren opcion.
Ekzempla agordo de tipa tunela interfaco:
aŭtomata retejo1
iface ejo1 inet statika
adreso 192.168.1.4
retmasko 255.255.255.254
antaŭ-supren ip tunelo aldonu site1 reĝimon gre loka 10.111.21.3 fora 10.111.22.3 ŝlosilo hfLYEg^vCh6p
Atentu! Oni devas rimarki, ke la agordoj por tunelaj interfacoj devas troviĝi ekster la sekcio
###netifcfg-begin###
*****
###netifcfg-end###
Alie, ĉi tiuj agordoj estos anstataŭitaj kiam oni ŝanĝas la retajn agordojn de fizikaj interfacoj per Cisco-simila konzolo.
Dinamika vojigo
En S-Terra, dinamika vojigo estas efektivigita uzante la Quagga programarpakaĵon. Por agordi OSPF ni devas ebligi kaj agordi demonojn zebro и ospfd. La zebra demono respondecas pri komunikado inter la vojaj demonoj kaj la OS. La ospfd-demono, kiel la nomo sugestas, respondecas pri efektivigado de la OSPF-protokolo.
OSPF estas agordita aŭ per la demona konzolo aŭ rekte per la agorda dosiero /etc/quagga/ospfd.conf. Ĉiuj fizikaj kaj tunelaj interfacoj partoprenantaj en dinamika vojigo estas aldonitaj al la dosiero, kaj la retoj kiuj estos reklamitaj kaj ricevos anoncojn ankaŭ estas deklaritaj.
Ekzemplo de la agordo al kiu devas esti aldonita ospfd.conf:
interfaco eth0
!
interfaco eth1
!
interfaco retejo1
!
interfaco retejo2
enkursigilo ospf
ospf router-id 192.168.2.21
reto 192.168.1.4/31 areo 0.0.0.0
reto 192.168.1.16/31 areo 0.0.0.0
reto 192.168.2.4/30 areo 0.0.0.0
En ĉi tiu kazo, adresoj 192.168.1.x/31 estas rezervitaj por tunelaj ptp-retoj inter ejoj, adresoj 192.168.2.x/30 estas asignitaj por transitretoj inter CS kaj kernaj enkursigiloj.
Atentu! Por redukti la enrutigan tabelon en grandaj instalaĵoj, vi povas filtri la anoncon de la transitretoj mem uzante la konstrukciojn. neniu redistribuo konektita aŭ redistribui konektitan itinero-mapon.
Post agordo de la demonoj, vi devas ŝanĝi la komencan staton de la demonoj en /etc/quagga/daemons. En opcioj zebro и ospfd neniu ŝanĝo al jes. Lanĉu la quagga-demonon kaj agordu ĝin aŭtomate kiam vi lanĉas la KS-komandon update-rc.d quagga enable.
Se la agordo de GRE-tuneloj kaj OSPF estas farita ĝuste, tiam itineroj en la reto de aliaj retejoj devus aperi sur la KSh kaj kernaj enkursigiloj kaj, tiel, reta konektebleco inter lokaj retoj estiĝas.
Ni ĉifras transdonitan trafikon
Kiel jam estis skribita, kutime dum ĉifrado inter retejoj, ni specifas IP-adresintervalojn (ACLs) inter kiuj trafiko estas ĉifrita: se la fonto- kaj cel-adresoj falas ene de ĉi tiuj intervaloj, tiam la trafiko inter ili estas ĉifrita. Tamen, en ĉi tiu projekto la strukturo estas dinamika kaj adresoj povas ŝanĝiĝi. Ĉar ni jam agordis GRE-tuneladon, ni povas specifi eksterajn KS-adresojn kiel la fonto- kaj cel-adresojn por ĉifrado de trafiko - finfine, trafiko kiu estas jam enkapsuligita de la GRE-protokolo alvenas por ĉifrado. Alivorte, ĉio, kio eniras la CS de la loka reto de unu retejo al retoj anoncitaj de aliaj retejoj, estas ĉifrita. Kaj ene de ĉiu el la retejoj ajna alidirekto povas esti farita. Tiel, se estas iu ŝanĝo en lokaj retoj, la administranto nur bezonas modifi la anoncojn venantajn de sia reto al la reto, kaj ĝi estos disponebla al aliaj retejoj.
Ĉifrado en S-Terra CS estas farita uzante la IPSec-protokolon. Ni uzas la algoritmon "Grasshopper" laŭ GOST R 34.12-2015, kaj por kongruo kun pli malnovaj versioj vi povas uzi GOST 28147-89. Aŭtentikigo povas teknike esti farita sur kaj antaŭdifinitaj ŝlosiloj (PSKoj) kaj atestiloj. Tamen, en industria operacio necesas uzi atestojn eldonitajn laŭ GOST R 34.10-2012.
Labori kun atestiloj, ujoj kaj CRL-oj estas farita per la ilo cert_mgr. Antaŭ ĉio, uzante la komandon cert_mgr krei necesas generi privatan ŝlosilujon kaj atestilpeton, kiuj estos senditaj al la Atestila Administra Centro. Post ricevi la atestilon, ĝi devas esti importita kune kun la radika CA-atestilo kaj CRL (se uzata) kun la komando cert_mgr import. Vi povas certigi, ke ĉiuj atestiloj kaj CRL-oj estas instalitaj per la komando cert_mgr spektaklo.
Post sukcese instali la atestojn, iru al la Cisco-simila konzolo por agordi IPSec.
Ni kreas IKE-politikon, kiu specifas la deziratajn algoritmojn kaj parametrojn de la sekura kanalo kreita, kiu estos ofertita al la partnero por aprobo.
#crypto isakmp-politiko 1000
#encr gost341215k
#hash gost341112-512-tc26
#aŭtentikiga signo
#grupo vko2
#vivdaŭro 3600
Ĉi tiu politiko estas aplikata dum konstruado de la unua fazo de IPSec. La rezulto de sukcesa kompletigo de la unua fazo estas la establado de SA (Sekureco-Asocio).
Poste, ni devas difini liston de fontaj kaj celaj IP-adresoj (ACL) por ĉifrado, generi transforman aron, krei kriptan mapon (kriptomapo) kaj ligi ĝin al la ekstera interfaco de la CS.
Agordu ACL:
#ip alir-listo etendita retejo1
#permesilo gre gastiganto 10.111.21.3 gastiganto 10.111.22.3
Aro da transformoj (same kiel por la unua fazo, ni uzas la ĉifrad-algoritmon "Grasshopper" uzante la simulan enmeta generan reĝimon):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Ni kreas kriptan mapon, specifas la ACL, transforman aron kaj samranĝan adreson:
#kriptomapo ĈEFA 100 ipsec-isakmp
#kongrua adreso retejo1
#set transform-set GOST
# aro kunulo 10.111.22.3
Ni ligas la kriptan karton al la ekstera interfaco de la kaso:
#interfaco GigabitEthernet0/0
#ip-adreso 10.111.21.3 255.255.255.0
#kriptomapo MAIN
Por ĉifri kanalojn kun aliaj retejoj, vi devas ripeti la proceduron por krei ACL kaj kriptan karton, ŝanĝante la ACL-nomon, IP-adresojn kaj kriptan karton.
Atentu! Se atestilkonfirmo de CRL ne estas uzata, tio devas esti eksplicite precizigita:
#crypto pki trustpoint s-terra_technological_trustpoint
#revocation-check none
Je ĉi tiu punkto, la aranĝo povas esti konsiderata kompleta. En Cisco-simila konzolo komanda eligo montri crypto isakmp sa и montri crypto ipsec sa La konstruitaj unua kaj dua fazoj de IPSec devus esti reflektitaj. La samaj informoj povas esti akiritaj per la komando sa_mgr show, ekzekutita de debian-ŝelo. En la komanda eligo cert_mgr spektaklo La fora retejo-atestiloj devus aperi. La statuso de tiaj atestiloj estos malproksima. Se tuneloj ne estas konstruitaj, vi devas rigardi la VPN-servprotokolo, kiu estas konservita en la dosiero /var/log/cspvpngate.log. Kompleta listo de protokolaj dosieroj kun priskribo de ilia enhavo estas disponebla en la dokumentado.
Monitorante la "sanon" de la sistemo
La S-Terra CC uzas la norman snmpd-demonon por monitorado. Krom tipaj Linukso-parametroj, el la skatolo S-Terra subtenas eldonadon de datumoj pri IPSec-tuneloj konforme al la CISCO-IPSEC-FLOW-MONITOR-MIB, kio estas tio, kion ni uzas dum monitorado de la stato de IPSec-tuneloj. La funkcieco de kutimaj OID-oj, kiuj eligas la rezultojn de skripto-ekzekuto kiel valoroj, ankaŭ estas subtenata. Ĉi tiu funkcio ebligas al ni spuri atestilajn limdatojn. La skribita skripto analizas la komandan eligon cert_mgr spektaklo kaj kiel rezulto donas la nombron da tagoj ĝis la lokaj kaj radikaj atestiloj eksvalidiĝas. Ĉi tiu tekniko estas nemalhavebla dum administrado de granda nombro da CABGoj.
Kio estas la avantaĝo de tia ĉifrado?
La tuta funkcio priskribita supre estas subtenata el la skatolo de la S-Terra KSh. Tio estas, ne necesis instali pliajn modulojn, kiuj povus influi la atestadon de kriptaj enirejoj kaj la atestadon de la tuta informsistemo. Povas ekzisti iuj ajn kanaloj inter retejoj, eĉ per la Interreto.
Pro la fakto, ke kiam la interna infrastrukturo ŝanĝiĝas, ne necesas reagordi kriptajn enirejojn, la sistemo funkcias kiel servo, kio estas tre oportuna por la kliento: li povas meti siajn servojn (kliento kaj servilo) ĉe iuj adresoj, kaj ĉiuj ŝanĝoj estos dinamike translokigitaj inter ĉifrada ekipaĵo.
Kompreneble, ĉifrado pro superkostoj (superkostoj) influas la transdonon de datumoj, sed nur iomete - la kanala trairo povas malpliiĝi maksimume 5-10%. Samtempe, la teknologio estis provita kaj montris bonajn rezultojn eĉ sur satelitaj kanaloj, kiuj estas sufiĉe malstabilaj kaj havas malaltan bendolarĝon.
Igor Vinokhodov, inĝeniero de la 2-a linio de administrado de Rostelecom-Solar
fonto: www.habr.com