Ha a vállalata hálózaton személyes adatokat vagy más védendő bizalmas információkat továbbít vagy fogad, amelyeket a jogszabályok védelmét igénylik, akkor kötelező a GOST szerinti titkosítás alkalmazása. Ma arról fogunk beszélni, hogy miként valósítottuk meg ezt a titkosítást az S-Terra kriptoátjárónál (КШ) egy megrendelőnél. Ez a történet érdekes lesz a biztonsági szakemberek, mérnökök, tervezők és architektek számára. A technikai konfiguráció részleteibe nem fogunk mélyen belemenni — a főbb alapbeállítási pontokra fogunk koncentrálni. Óriási mennyiségű dokumentáció áll rendelkezésre az S-Terra KШ által használt Linux operációs rendszer démonjainak beállításáról, amely szabadon hozzáférhető az interneten. Az S-Terra tulajdonosi szoftverének beállítási dokumentációja szintén nyilvánosan elérhető. a gyártó.
Néhány szó a projektről
A megrendelő hálózati topológiája tipikus volt — teljes mesh a központ és a fiókok között. Szükséges volt a kommunikációs csatornák titkosításának bevezetése az összes helyszín között, amelyek száma 8 volt.
Hasonló projektekben általában minden statikus: a kriptoátjárókon (КШ) statikus útvonalakat állítanak be a helyi hálózatra, IP-címlistákat (ACL) írnak elő a titkosításhoz. Azonban ebben az esetben a helyszíneknek nincs központosított irányítása, és a helyi hálózatokon belül bármi megtörténhet: hálózatok adhatók hozzá, távolíthatók el és mindenféleképpen módosíthatók. Annak érdekében, hogy elkerüljük az útvonalbeállítás és az ACL újrakonfigurálását a helyi hálózatokról érkező címek megváltozása esetén, a GRE-alagút alkalmazása és az OSPF dinamikus útvonalválasztás bevezetése mellett döntöttek, amelybe minden КШ és a helyszínek többségének gerinc routerei beletartoznak (néhány helyszínen az infrastruktúra rendszergazdái a KШ felé irányuló SNAT használatát részesítették előnyben a gerinc routereken).
A GRE-alagút lehetővé tette két feladat megoldását:
1. Az ACL-ben a titkosításhoz használt IP-cím az КШ külső interfésze, amelyben minden olyan forgalom kapszulázódik, amely más helyekre irányul.
2. P-t-p alagutak létrehozása a КШ-k között, amelyek lehetővé teszik a dinamikus útvonalválasztás beállítását (a mi esetünkben a helyszínek között szolgáltatói MPLS L3VPN-t szerveztek meg).
Az ügyfél titkosítási megoldás beszerzését kérte. Különben nemcsak a kriptográfiai átjárók fenntartásával, vagy valamilyen szervezetre való kiszervezéssel kellett volna foglalkoznia, hanem saját maga kellett volna nyomon követnie a titkosítási tanúsítványok életciklusát, időben megújítani őket és újakat telepíteni.
Most pedig itt az emlékeztető – hogyan és mit állítottunk be
KII szempontjából: kriptográfiai átjáró beállítása
Alap hálózati beállítás
Mindenekelőtt elindítjuk az új KÁ-t, és belépünk az adminisztrációs konzolra. A jelszó megváltoztatásával érdemes kezdeni, az integrált adminisztrátoréra — parancs: change user password administrator. Ezt követően el kell végezni az inicializálási eljárást (parancs: initialize), amely során beírásra kerülnek a licencek adatai, valamint inicializálódik a véletlenszám-generátor (VRG).
Felhívjuk a figyelmet! A KÁ inicializálásakor S-Terra biztonsági irányelvek kerülnek beállításra, amely alapján a biztonsági átjáró interfészei nem engednek át csomagokat. Szükséges saját irányelvet létrehozni, vagy a következő parancs segítségével: run csconf_mgr activate elvégezni az előre meghatározott engedélyezési irányelv aktiválását.
Ezután be kell állítani a külső és belső interfészek címzését, valamint az alapértelmezett útvonalat. A KÁ hálózati konfigurációjával és titkosítási beállításaival a Cisco-szerű konzolon keresztül érdemes foglalkozni. Ez a konzol a Cisco IOS parancsaihoz hasonló parancsok bevitelére szolgál. A Cisco-szerű konzolon keresztül létrehozott konfiguráció megfelelő konfigurációs fájlokká alakul, amelyeket az operációs rendszer démonjai használnak. A Cisco-szerű konzolra az adminisztrációs konzolból a következő parancs segítségével lehet átváltani: configure.
Megváltoztatjuk a beépített cscons és enable felhasználók jelszavát:
>enable
Jelszó: csp(gyári)
#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
Kilépünk a Cisco-szerű konzolból, és a debian shellbe lépünk a következő parancs segítségével: system. Beállítjuk a saját jelszavunkat a felhasználóhoz , felhasználó nevében fut, mivel alapvető rendszerbeállításokat módosítanak, de a WordPress közvetlenül egy normál felhasználóként működik. parancsot passwd.
Minden KÁ-n külön alagutat kell beállítani minden helyszínhez. Az alagútfelület beállítása a fájlban történik /etc/network/interfaces. Az alagút interface létrehozásáért az iproute2 előre telepített csomagjában található IP tunnel segédprogram felel. Az interfész létrehozó parancs a pre-up opcióban kerül megadásra.
Tipikus alagútfelület konfiguráció példa:
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
Felhívjuk a figyelmet! Meg kell jegyezni, hogy a tunnel interfészek beállításait a szekción kívül kell elhelyezni
###netifcfg-begin###
*****
###netifcfg-end###
Ellenkező esetben ezek a beállítások felülíródnak a fizikai interfészek hálózati beállításainak módosításakor a Cisco-szerű konzolon.
Dinamikus útválasztás
Az S-Terra-ban a dinamikus útválasztás a Quagga programcsomag segítségével valósul meg. Az OSPF beállításához szükségünk lesz a démonok engedélyezésére és konfigurálására zebra és ospfd. A zebra démon felelős a routing démonok és az operációs rendszer közötti interakcióért. Az ospfd démon, amint azt a neve is sugallja, az OSPF protokoll megvalósításáért felel.
Az OSPF beállítása történhet a démon konzolon keresztül, vagy közvetlenül a konfigurációs fájlban /etc/quagga/ospfd.conf. A fájlba minden résztvevő fizikai és tunnel interfészt be kell írni, valamint meg kell hirdetni azokat a hálózatokat, amelyek bejelentésre kerülnek és fogadják a bejelentéseket.
Konfigurációs példa, amelyet hozzá kell adni a ospfd.conf:
interface eth0
!
interface eth1
!
interface site1
!
interface site2
router ospf
ospf router-id 192.168.2.21
network 192.168.1.4/31 area 0.0.0.0
network 192.168.1.16/31 area 0.0.0.0
network 192.168.2.4/30 area 0.0.0.0
Ebben az esetben a 192.168.1.x/31 címek a telephelyek közötti ptp tunnelekhez vannak allokálva, míg a 192.168.2.x/30 címek a tranzit hálózatokhoz a core routerek és a KSH között.
Felhívjuk a figyelmet! A routing táblázat csökkentéséhez nagyméretű telepítésekben a tranzit hálózatok hirdetése kiszűrhető a következő konstrukciókkal no redistribute connected vagy redistribute connected route-map.
A démonok beállítása után meg kell változtatni a démonok indítási státuszát a /etc/quagga/daemons. A lehetőségekben zebra és ospfd a no-t yes-re kell javítani. Indítsuk el a quagga démon-t és állítsuk be automatikus indítást a KSH indításakor a következő paranccsal update-rc.d quagga enable.
Ha a GRE tunnel és az OSPF beállítása helyesen történt, akkor a KSH-n és a core routereken megjelennek a többi telephely hálózatának útvonalai, ezzel hálózati kapcsolat létesül a helyi hálózatok között.
Titkosítjuk az átvitt forgalmat
Ahogy már említettük, általában a helyek közötti titkosítás során megadjuk az IP-címek tartományait (ACL), amelyek között titkosítva van a forgalom: ha a forrás- és fogadó címek ezekbe a tartományokba esnek, akkor a közöttük lévő forgalom titkosítva van. Azonban ebben a projektben a struktúra dinamikus, és a címek változhatnak. Mivel már beállítottuk a GRE-alagút-titkosítást, a forgalom titkosításához használhatjuk a külső KSH címeket – hiszen a titkosításra érkező forgalom már GRE protokollal van kapszulázva. Más szavakkal, minden titkosítva van, ami eljut a KSH-hoz az egyik hely lokális hálózatából a másik helyek által bejelentett hálózatok felé. És már minden helyen tetszőleges továbbirányítás végezhető. Így ha a helyi hálózatok valamilyen módon változnak, az adminisztrátor számára elegendő, ha módosítja a KSH irányába küldött bejelentéseket, és az elérhetővé válik más helyek számára.
A KSH-ban az S-Terra titkosítása az IPSec protokoll segítségével történik. A "Kuznyec" algoritmust használjuk a GOST R 34.12-2015 norma szerint, a régebbi verziókkal való kompatibilitás érdekében pedig a GOST 28147-89 alkalmazható. Az autentikáció technikailag megvalósítható előre meghatározott kulcsokkal (PSK) vagy tanúsítványokkal. Mindazonáltal ipari környezetben mindenképpen tanúsítványokat kell használni, amelyeket a GOST R 34.10-2012 szerint adtak ki.
A tanúsítványokkal, tartályokkal és CRL-el való munka a következő segédprogram segítségével történik cert_mgr. Először a parancs segítségével cert_mgr create létre kell hozni a privát kulcs tartályt és a tanúsítványra vonatkozó kérést, amelyet a Tanúsítványkezelő Központba kell benyújtani. A tanúsítvány megkapásakor azt együtt a gyökértanúsítvánnyal és CRL-lel (ha használják) be kell importálni a következő parancs segítségével cert_mgr import. Annak biztosítása érdekében, hogy minden tanúsítvány és CRL telepítve legyen, a következő parancsot használhatjuk cert_mgr show.
. A tanúsítványok sikeres telepítése után át kell térni a Cisco-szerű konzolra az IPSec beállításához.
IKE-politikát hozunk létre, amelyben megadjuk a kívánt algoritmusokat és a létrehozott védett csatorna paramétereit, amelyeket a partnernek javaslunk a megállapodás érdekében.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#authentication sign
#group vko2
#lifetime 3600
Ez a politika az IPSec első fázisának felépítésekor alkalmazandó. Az első fázis sikeres teljesítésének eredménye egy SA (Security Association) létrehozása.
Ezután meg kell határoznunk a forrás- és cél IP-címek (ACL) listáját a titkosításhoz, létre kell hozni egy átalakítási halmazt (transform set), egy kriptográfiai térképet (crypto map), és azt a külső KSH interfészhez kell rendelni.
Beállítjuk az ACL-t:
#ip access-list extended site1
#permit gre host 10.111.21.3 host 10.111.22.3
Átalakítási halmaz (ugyanúgy, mint az első fázisban, a 'Kuznyec' titkosítási algoritmus használatával, imitációs beinjektálási módban):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Létrehozzuk a kriptotérképet, megadva az ACL-t, az átalakítási halmazt és a peer címét:
#crypto map MAIN 100 ipsec-isakmp
#match address site1
#set transform-set GOST
#set peer 10.111.22.3
Rendeljük a kriptotérképet a külső KSH interfészhez:
#interface GigabitEthernet0/0
#ip address 10.111.21.3 255.255.255.0
#crypto map MAIN
Más platformokkal való csatornák titkosításához meg kell ismételni az ACL és a kriptotérkép létrehozási eljárását, módosítva az ACL nevét, az IP-címeket és a kriptotérkép számát.
Felhívjuk a figyelmet! Amennyiben nem használják a tanúsítványok CRL általi ellenőrzését, ezt kifejezetten jelezni kell:
#crypto pki trustpoint s-terra_technological_trustpoint
#revocation-check none
Ezzel a beállítás befejezettnek tekinthető. A Cisco-szerű parancssori kimenetben show crypto isakmp sa és show crypto ipsec sa meg kell jelenniük az IPSec első és második fázisának létrehozott információinak. Ugyanezt az információt megkaphatjuk a sa_mgr showparancs végrehajtásával a debian shellből. A parancs kimenetén cert_mgr show meg kell jelenniük a távoli platformok tanúsítványainak. Az ilyen tanúsítványok állapota remote. Ha a tunnellek nem épülnek fel, érdemes megnézni a naplókat VPN-szolgáltatás, amely a /var/log/cspvpngate.logfájlban található. A naplófájlok teljes listáját a tartalmuk leírásával a dokumentáció tartalmazza.
Monitorozzuk a rendszer 'egészségét'
A KSH S-Terra rendszerében standard snmpd démon használható a monitorozásra. A Linuxra jellemző paraméterek mellett az S-Terra 'dobozból' támogatja az IPSec-alagutak adatainak kiadását a CISCO-IPSEC-FLOW-MONITOR-MIB szerint, amit használunk az IPSec-alagutak állapotának nyomon követésére. Továbbá támogatott a testreszabott OID-ok funkciója, amelyek a szkriptek végrehajtásának eredményét adják vissza értékként. Ez a lehetőség lehetővé teszi számunkra a tanúsítványok lejárati idejének nyomon követését. Az íróskripttel elemezzük a parancs kimenetét cert_mgr show és ennek eredményeként megadja, hány nap van a helyi és a gyökér tanúsítványok lejáratáig. Ez a módszer nélkülözhetetlen nagy számú KSH adminisztrálásakor.
Miben rejlik ennek a titkosításnak az értelme?
A fent említett összes funkció alapértelmezés szerint támogatott az S-Terra KSH esetében. Ezért nem szükséges különböző modulokat telepíteni, amelyek befolyásolhatják a kriptográfiai átjárók és az egész információs rendszer tanúsítását. A csatornák a helyszínek között lehetnek bármilyenek, akár az interneten keresztül is.
Mivel a belső infrastruktúra változtatásakor nem szükséges újra konfigurálni a kriptográfiai átjárókat, a rendszer szolgáltatásként működik, ami nagyon kényelmes a megrendelő számára: a saját szolgáltatásait (ügyfél- és szerveroldali) bármilyen címre elhelyezheti, és minden változást dinamikusan átadnak a titkosító berendezések között.
Kétségtelen, hogy a titkosítás a többletterhelés (overhead) miatt befolyásolja az adatátviteli sebességet, de ez elhanyagolható — a csatorna áteresztőképessége legfeljebb 5-10%-kal csökkenhet. Emellett a technológiát tesztelték, és jó eredményeket mutatott, még az elég instabil és alacsony áteresztőképességű műholdas csatornákon is.
Igor Vinokhodov, a 2. szintű adminisztrátor „Rosztelkom-Szolar”
Forrás: habr.com
