Ha az Ön cége személyes adatokat és egyéb bizalmas információkat továbbít vagy fogad a hálózaton keresztül, amely a törvény értelmében védelem alá esik, akkor GOST titkosítást kell alkalmaznia. Ma elmondjuk, hogyan valósítottuk meg az S-Terra crypto gateway-n (CS) alapuló titkosítást az egyik ügyfélnél. Ez a történet érdekelni fogja az információbiztonsági szakembereket, valamint a mérnököket, tervezőket és építészeket. Ebben a bejegyzésben nem merülünk el mélyen a műszaki konfiguráció árnyalataiban, hanem az alapbeállítás legfontosabb pontjaira összpontosítunk. Az S-Terra CS alapját képező Linux OS démonok beállításáról szóló hatalmas mennyiségű dokumentáció ingyenesen elérhető az interneten. A szabadalmaztatott S-Terra szoftver beállításához szükséges dokumentáció nyilvánosan is elérhető a következő címen: gyártó.
Néhány szó a projektről
Az ügyfél hálózati topológiája szabványos volt - teljes háló a központ és az ágak között. Szükség volt az információcsere-csatornák titkosításának bevezetésére az összes oldal között, amelyből 8 volt.
Általában az ilyen projektekben minden statikus: a webhely helyi hálózatához vezető statikus útvonalakat titkosítási átjárókon (CG-k) állítják be, az IP-címek (ACL) listáit a titkosításhoz regisztrálják. Ebben az esetben azonban az oldalak nem rendelkeznek központi vezérléssel, és a helyi hálózatukon belül bármi megtörténhet: a hálózatok minden lehetséges módon hozzáadhatók, törölhetők, módosíthatók. Annak érdekében, hogy elkerüljük az útválasztás és az ACL újrakonfigurálását a KS-en a helyi hálózatok címeinek megváltoztatásakor a helyszíneken, úgy döntöttünk, hogy GRE tunnelinget és OSPF dinamikus útválasztást használnak, amely magában foglalja az összes KS-t és a legtöbb útválasztót a hálózati mag szintjén a helyeken ( egyes helyeken az infrastruktúra-adminisztrátorok előnyben részesítették a SNAT használatát a KS-sel szemben a kernel útválasztókon).
A GRE alagút két probléma megoldását tette lehetővé:
1. Használja a CS külső interfészének IP-címét a titkosításhoz az ACL-ben, amely magában foglalja a más webhelyekre küldött összes forgalmat.
2. Ptp alagutak szervezése a CS-k között, amelyek lehetővé teszik a dinamikus útválasztás konfigurálását (esetünkben a szolgáltató MPLS L3VPN-je a helyek között van szervezve).
Az ügyfél megrendelte a titkosítás megvalósítását szolgáltatásként. Ellenkező esetben nemcsak karban kell tartania a titkosítási átjárókat, vagy ki kell adnia azokat valamilyen szervezetnek, hanem önállóan is figyelnie kellene a titkosítási tanúsítványok életciklusát, időben meg kell újítania és újakat telepítenie.
És most a tényleges feljegyzés – hogyan és mit konfiguráltunk
Megjegyzés a CII témakörhöz: kriptográfiai átjáró beállítása
Alapvető hálózati beállítások
Először is elindítunk egy új CS-t, és belépünk az adminisztrációs konzolba. Kezdje a beépített rendszergazdai jelszó módosításával - parancs módosítsa a felhasználói jelszót rendszergazda. Ezután végre kell hajtania az inicializálási eljárást (parancs inicializálni), amely során a licencadatok bevitele és a véletlenszám-érzékelő (RNS) inicializálása megtörténik.
Figyelj! Az S-Terra CC inicializálása során létrejön egy biztonsági szabályzat, amelyben a biztonsági átjáró interfészek nem engedik át a csomagokat. Létre kell hoznia saját házirendjét, vagy használnia kell a parancsot futtassa a csconf_mgr activate parancsot aktiváljon egy előre meghatározott engedélyezési házirendet.
Ezután konfigurálnia kell a külső és belső interfészek címzését, valamint az alapértelmezett útvonalat. Célszerű a CS hálózati konfigurációval dolgozni, és a titkosítást Cisco-szerű konzolon keresztül konfigurálni. Ez a konzol a Cisco IOS parancsaihoz hasonló parancsok bevitelére szolgál. A Cisco-szerű konzol segítségével generált konfigurációt pedig a megfelelő konfigurációs fájlokká alakítják, amelyekkel az operációs rendszer démonjai működnek. Az adminisztrációs konzolról a paranccsal a Cisco-szerű konzolra léphet configure.
Módosítsa a beépített felhasználói cscons jelszavakat, és engedélyezze:
> engedélyezze
Jelszó: csp (előre telepítve)
#terminál konfigurálása
#username cscons privilege 15 secret 0 #enable secret 0 Az alapvető hálózati konfiguráció beállítása:
#interface GigabitEthernet0/0
#ip-cím 10.111.21.3 255.255.255.0
#nincs leállás
#interface GigabitEthernet0/1
#ip-cím 192.168.2.5 255.255.255.252
#nincs leállás
#ip útvonal 0.0.0.0 0.0.0.0 10.111.21.254
GRE
Lépjen ki a Cisco-szerű konzolból, és lépjen a debian shell-re a paranccsal rendszer. Állítsa be saját jelszavát a felhasználó számára gyökér csapat passwd.
Minden vezérlőteremben külön alagút van konfigurálva minden telephelyhez. Az alagút interfész a fájlban van konfigurálva / Etc / network / interfaces. Az előre telepített iproute2 készletben található IP tunnel segédprogram maga az interfész létrehozásáért felelős. Az interfész létrehozása parancs a pre-up opcióba van írva.
Példa egy tipikus alagút interfész konfigurációjára:
auto site1
iface site1 inet static
cím 192.168.1.4
netmaszk 255.255.255.254
pre-up ip tunnel add site1 mode gre helyi 10.111.21.3 távoli 10.111.22.3 kulcs hfLYEg^vCh6p
Figyelj! Megjegyzendő, hogy az alagút interfészek beállításait a szakaszon kívül kell elhelyezni
###netifcfg-begin###
*****
###netifcfg-end###
Ellenkező esetben ezek a beállítások felülíródnak, amikor a fizikai interfészek hálózati beállításait Cisco-szerű konzolon keresztül módosítják.
Dinamikus útválasztás
Az S-Terrában a dinamikus útválasztás a Quagga szoftvercsomag segítségével valósul meg. Az OSPF konfigurálásához engedélyeznünk és konfigurálnunk kell a démonokat zebra и ospfd. A zebra démon felelős az útválasztó démonok és az operációs rendszer közötti kommunikációért. Az ospfd démon, ahogy a neve is sugallja, az OSPF protokoll megvalósításáért felelős.
Az OSPF vagy a démonkonzolon keresztül, vagy közvetlenül a konfigurációs fájlon keresztül állítható be /etc/quagga/ospfd.conf. A fájlhoz hozzáadódik a dinamikus útválasztásban részt vevő összes fizikai és alagút interfész, és deklarálva vannak a hirdetett és értesítéseket fogadó hálózatok is.
Példa arra a konfigurációra, amelyet hozzá kell adni ospfd.conf:
interfész eth0
!
interfész eth1
!
interfész site1
!
interfész site2
ospf router
ospf router-id 192.168.2.21
hálózat 192.168.1.4/31 terület 0.0.0.0
hálózat 192.168.1.16/31 terület 0.0.0.0
hálózat 192.168.2.4/30 terület 0.0.0.0
Ebben az esetben a 192.168.1.x/31 címek a helyek közötti alagút ptp hálózatok számára, a 192.168.2.x/30 címek a CS és a kernel útválasztók közötti tranzithálózatok számára vannak lefoglalva.
Figyelj! A nagy telepítéseknél az útválasztási tábla csökkentése érdekében a konstrukciók segítségével szűrheti a tömegközlekedési hálózatok hirdetéseit. nincs újraelosztás csatlakoztatva vagy a csatlakoztatott útvonal-térkép újraosztása.
A démonok konfigurálása után módosítania kell a démonok indítási állapotát /etc/quagga/daemons. Az opciókban zebra и ospfd nincs változás igenre. Indítsa el a quagga démont, és állítsa automatikus indításra, amikor elindítja a KS parancsot update-rc.d quagga enable.
Ha a GRE alagutak és az OSPF konfigurálása helyesen történik, akkor más helyek hálózatában lévő útvonalaknak meg kell jelenniük a KSh-n és a központi útválasztókon, és így létrejön a hálózati kapcsolat a helyi hálózatok között.
Titkosítjuk az átvitt forgalmat
Ahogy már írtuk, az oldalak közötti titkosításkor általában IP-címtartományokat (ACL) adunk meg, amelyek között a forgalom titkosításra kerül: ha a forrás- és célcímek ebbe a tartományba esnek, akkor a közöttük lévő forgalom titkosításra kerül. Ebben a projektben azonban a struktúra dinamikus, és a címek változhatnak. Mivel a GRE tunnelinget már beállítottuk, a forgalom titkosításának forrás- és célcímeként külső KS-címeket is megadhatunk – elvégre a GRE protokoll által már beágyazott forgalom érkezik titkosításra. Más szóval, minden, ami az egyik webhely helyi hálózatából a CS-be kerül a más oldalak által bejelentett hálózatok felé, titkosítva van. És az egyes webhelyeken belül bármilyen átirányítás végrehajtható. Így ha a helyi hálózatokban változás történik, akkor az adminisztrátornak csak módosítania kell a hálózatáról a hálózat felé érkező közleményeket, és az elérhetővé válik más oldalak számára.
Az S-Terra CS titkosítása az IPSec protokoll használatával történik. A „Grasshopper” algoritmust a GOST R 34.12-2015 szerint használjuk, és a régebbi verziókkal való kompatibilitás érdekében használhatja a GOST 28147-89-et. A hitelesítés technikailag végrehajtható előre meghatározott kulcsokon (PSK) és tanúsítványokon is. Az ipari üzemben azonban a GOST R 34.10-2012 szerint kiállított tanúsítványokat kell használni.
A tanúsítványokkal, tárolókkal és CRL-ekkel való munka a segédprogram segítségével történik cert_mgr. Először is a parancs használatával cert_mgr létrehozása létre kell hozni egy privát kulcs tárolót és egy tanúsítványkérést, amely elküldésre kerül a Tanúsítványkezelő Központnak. A tanúsítvány kézhezvétele után importálni kell a gyökér CA-tanúsítvánnyal és a CRL-lel (ha van ilyen) a paranccsal együtt cert_mgr import. Győződjön meg arról, hogy az összes tanúsítvány és CRL telepítve van a paranccsal cert_mgr show.
A tanúsítványok sikeres telepítése után lépjen a Cisco-szerű konzolra az IPSec konfigurálásához.
Létrehozunk egy IKE szabályzatot, amely meghatározza a létrehozott biztonságos csatorna kívánt algoritmusait és paramétereit, amelyet jóváhagyásra felajánlunk a partnernek.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#hitelesítési jel
#csoport vko2
#élettartam 3600
Ezt a házirendet alkalmazzuk az IPSec első fázisának elkészítésekor. Az első szakasz sikeres befejezésének eredménye az SA (Security Association) megalakulása.
Ezután meg kell határoznunk a titkosításhoz szükséges forrás- és cél IP-címek (ACL) listáját, létrehoznunk kell egy transzformációs készletet, létre kell hoznunk egy kriptográfiai térképet (kriptotérkép), és össze kell kötnünk a CS külső interfészével.
ACL beállítása:
#ip hozzáférési lista kiterjesztett webhely1
#permit gre host 10.111.21.3 host 10.111.22.3
Transzformációk halmaza (ugyanúgy, mint az első fázisban, a „Grasshopper” titkosítási algoritmust használjuk a szimulációs beillesztési módot használva):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Létrehozunk egy titkosítási térképet, megadjuk az ACL-t, a transzformációs készletet és a társcímet:
#crypto map MAIN 100 ipsec-isakmp
#egyezik a címe webhely1
#set transform-set GOST
#set peer 10.111.22.3
A kriptokártyát a pénztárgép külső interfészéhez kötjük:
#interface GigabitEthernet0/0
#ip-cím 10.111.21.3 255.255.255.0
#kriptotérkép FŐ
A csatornák más webhelyekkel való titkosításához meg kell ismételnie az ACL és a titkosítási kártya létrehozásának folyamatát, módosítania kell az ACL nevét, IP-címeit és titkosítási kártya számát.
Figyelj! Ha nem alkalmazzák a CRL általi tanúsítvány-ellenőrzést, ezt kifejezetten meg kell adni:
#crypto pki trustpoint s-terra_technological_trustpoint
#revocation-check nincs
Ezen a ponton a beállítás befejezettnek tekinthető. A Cisco-szerű konzol parancskimenetében show crypto isakmp sa и mutasd meg a crypto ipsec sa Az IPSec felépített első és második fázisát tükrözni kell. Ugyanezt az információt kaphatjuk meg a paranccsal sa_mgr show, debian shellből végrehajtva. A parancs kimenetében cert_mgr show Meg kell jelenniük a távoli webhely tanúsítványainak. Az ilyen tanúsítványok állapota a következő lesz távoli. Ha nem építenek alagutak, meg kell néznie a VPN-szolgáltatásnaplót, amely a fájlban található /var/log/cspvpngate.log. A naplófájlok teljes listája a tartalmuk leírásával a dokumentációban található.
A rendszer „egészségének” figyelése
Az S-Terra CC a szabványos snmpd démont használja a megfigyeléshez. A tipikus Linux-paramétereken kívül az S-Terra már készen is támogatja az IPSec alagutak adatainak kiadását a CISCO-IPSEC-FLOW-MONITOR-MIB szerint, amit az IPSec alagutak állapotának figyelésekor használunk. Az egyéni OID-k funkciói is támogatottak, amelyek a parancsfájl-végrehajtás eredményeit értékként adják ki. Ezzel a funkcióval nyomon követhetjük a tanúsítványok lejárati dátumát. Az írott szkript elemzi a parancs kimenetét cert_mgr show és ennek eredményeként megadja a napok számát a helyi és a gyökértanúsítvány lejártáig. Ez a technika nélkülözhetetlen nagyszámú CABG beadásakor.
Mi az előnye az ilyen titkosításnak?
A fent leírt összes funkciót az S-Terra KSh már a dobozból is támogatja. Azaz nem volt szükség további olyan modulok telepítésére, amelyek a kriptoátjárók tanúsítását és a teljes információs rendszer tanúsítását befolyásolhatták. Az oldalak között bármilyen csatorna lehet, akár az interneten keresztül is.
Mivel a belső infrastruktúra megváltozásakor nincs szükség a titkosítási átjárók újrakonfigurálására, a rendszer szolgáltatásként működik, ami nagyon kényelmes az ügyfél számára: szolgáltatásait (kliens és szerver) bármilyen címen elhelyezheti, és minden változás dinamikusan átkerül a titkosító berendezések között.
Természetesen a rezsiköltségek (overhead) miatti titkosítás befolyásolja az adatátviteli sebességet, de csak kis mértékben - a csatorna átviteli sebessége maximum 5-10%-kal csökkenhet. Ugyanakkor a technológiát tesztelték, és még a meglehetősen instabil és alacsony sávszélességű műholdas csatornákon is jó eredményeket mutatott.
Igor Vinokhodov, a Rostelecom-Solar 2. igazgatási vonalának mérnöke
Forrás: will.com