Калі ваша кампанія перадае або атрымлівае па сетцы перданную і іншую канфідэнцыйную інфармацыю, якая падлягае абароне ў адпаведнасці з заканадаўствам, патрабуецца ўжываць шыфраванне па Дасце. Сёння мы раскажам, як укаранілі такое шыфраванне на базе крыпташлюзу (КШ) S-Terra ў аднаго з заказчыкаў. Гэтая гісторыя будзе цікавая ИБ-спецыялістам, а таксама інжынерам, праекціроўшчыкам і архітэктарам. Глыбока апускацца ў нюансы тэхнічнай канфігурацыі ў дадзеным пасце мы не будзем - спынімся на ключавых момантах базавай налады. Велізарныя аб'ёмы дакументацыі па наладзе дэманаў АС Linux, на якой грунтуецца КШ S-Terra, ёсць у вольным доступе ў інтэрнэце. Дакументацыя па наладзе прапрыетарнага ПЗ S-Terra размяшчаецца таксама ў адкрытым доступе на вытворцы.
Пара слоў аб праекце
Тапалогія сеткі ў заказчыка была тыпавая - full mesh паміж цэнтрам і філіяламі. Патрабавалася ўкараніць шыфраванне каналаў абмену інфармацыяй паміж усімі пляцоўкамі, якіх было 8 штук.
Звычайна ў падобных праектах усё статычна: на крыпташлюзах (КШ) задаюцца статычныя маршруты ў лакальную сетку пляцоўкі, прапісваюцца спісы IP-адрасоў (ACL) для шыфравання. Аднак у дадзеным выпадку ў пляцовак няма цэнтралізаванага кіравання, і ўсярэдзіне іх лакальных сетак можа адбывацца ўсё, што заўгодна: сеткі могуць дадавацца, выдаляцца і ўсяляк мадыфікавацца. Для таго каб пазбегнуць пераналадкі маршрутызацыі і ACL на КШ пры змене адрасавання лакальных сетак на пляцоўках, было прынята рашэнне выкарыстоўваць GRE-тунэляванне і дынамічную маршрутызацыю OSPF, у якую ўключаны ўсе КШ і большасць маршрутызатараў узроўня ядра сеткі на пляцоўках (на некаторых пляцоўках адміністратары інфраструктуры ўпадабалі выкарыстоўваць SNAT у бок КШ на маршрутызатарах ядра).
GRE-тунэляванне дазволіла вырашыць дзве задачы:
1. Выкарыстоўваць у ACL для шыфравання IP-адрас вонкавага інтэрфейсу КШ, у якім інкапсулюецца ўвесь трафік, які накіроўваецца на іншыя пляцоўкі.
2. Арганізаваць ptp тунэлі паміж КШ, якія дазваляюць наладзіць дынамічную маршрутызацыю (у нашым выпадку паміж пляцоўкамі арганізаваны правайдэрскі MPLS L3VPN).
Кліент заказаў рэалізацыю шыфравання як паслугу. Інакш яму прыйшлося б не проста падтрымліваць крыпташлюзы або здаваць у аўтсорс нейкай арганізацыі, але і самастойна адсочваць жыццёвы цыкл сертыфікатаў шыфравання, своечасова іх падаўжаць і ўсталёўваць новыя.
А зараз уласна напамінак - як і што мы наладжвалі
Суб'екту КІІ на нататку: наладжваем криптошлюз
Базавая настройка сеткі
Першым чынам запускаем новую КШ і пападаем у кансоль адміністравання. Пачаць варта са змены пароля ўбудаванага адміністратара - каманда change user password administrator. Затым неабходна правесці працэдуру ініцыялізацыі (каманда ініцыялізаваць) у працэсе якой уводзяцца дадзеныя ліцэнзіі і ініцыялізуецца датчык выпадковых лікаў (ДСЧ).
Звярніце ўвагу! Пры ініцыялізацыі КШ S-Terra усталёўваецца палітыка бяспекі, пры якой інтэрфейсы шлюза бяспекі не прапускаюць пакеты. Неабходна альбо стварыць уласную палітыку, альбо з дапамогай каманды run csconf_mgr activate выканаць актывацыю прадусталяванай адрознівальнай палітыкі.
Далей неабходна наладзіць адрасаванне вонкавых і ўнутраных інтэрфейсаў, а таксама маршрут па змаўчанні. Працу з сеткавай канфігурацыяй КШ і наладу шыфравання пераважна выконваць праз Cisco-like кансоль. Дадзеная кансоль прызначаная для ўводу каманд, аналагічных камандам Cisco IOS. Канфігурацыя, сфармаваная з дапамогай Cisco-like кансолі, у сваю чаргу канвертуецца ў адпаведныя канфігурацыйныя файлы, з якімі працуюць дэманы АС. Перайсці ў Cisco-like кансоль з кансолі адміністравання можна камандай канфігураваць.
Змяняем паролі на ўбудаванага карыстальніка cscons і enable:
>enable
Password: csp(прадусталяваны)
#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
Выходзім з Cisco-like кансолі, і пераходзім у debian shell камандай сістэма. Усталеўваны ўласны пароль для карыстача корань камандай ПАРОЛЬ.
На кожным КШ наладжваецца асобны тунэль для кожнай пляцоўкі. Настройка тунэльнага інтэрфейсу робіцца ў файле / І г.д. / сетка / інтэрфейсы. За стварэнне самога інтэрфейсу адказвае ўтыліта IP tunnel, уваходная ў прадусталяваны набор iproute2. Каманда стварэння інтэрфейсу прапісваецца ў опцыю pre-up.
Прыклад канфігурацыі тыпавога тунэльнага інтэрфейсу:
auto site1
iface site1 inet static
адрас 192.168.1.4
Маска 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
Звярніце ўвагу! Трэба заўважыць, што налады тунэльных інтэрфейсаў неабходна размяшчаць па-за секцыяй.
###netifcfg-begin###
*****
###netifcfg-end###
У адваротным выпадку дадзеныя налады будуць зацёртыя пры змене сеткавых налад фізічных інтэрфейсаў праз Cisco-like кансоль.
Дынамічная маршрутызацыя
У S-Terra дынамічная маршрутызацыя рэалізуецца пры дапамозе пакета праграм Quagga. Для настройкі OSPF нам спатрэбяцца ўключэнне і настройка дэманаў зебра и ospfd. Дэман zebra адказвае за ўзаемадзеянне паміж дэманамі маршрутызацыі і АС. Дэман ospfd, як зразумела з назову, адказвае за рэалізацыю пратаколу OSPF.
Настройка OSPF ажыццяўляецца альбо праз кансоль дэмана, альбо напрамую праз канфігурацыйны файл /etc/quagga/ospfd.conf. У файл дадаюцца ўсе фізічныя і тунэльныя інтэрфейсы якія ўдзельнічаюць у дынамічнай маршрутызацыі, а таксама аб'яўляюцца сеткі, якія будуць анансавацца і прымаць анонсы.
Прыклад канфігурацыі, якую патрабуецца дадаць у ospfd.conf:
інтэрфейс eth0
!
інтэрфейс eth1
!
interface site1
!
interface site2
маршрутызатар 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
У дадзеным выпадку адрасы 192.168.1.х/31 адведзены пад тунэльныя ptp-сеткі паміж пляцоўкамі, адрасы 192.168.2.х/30 - пад транзітныя сеткі паміж КШ і маршрутызатарамі ядра.
Звярніце ўвагу! Для памяншэння табліцы маршрутызацыі ў буйных усталёўках можна адфільтраваць анансаванне саміх транзітных сетак з дапамогай канструкцый no redistribute connected або redistribute connected route-map.
Пасля наладкі дэманаў неабходна змяніць статус запуску дэманаў у /etc/quagga/daemons. У опцыях зебра и ospfd no выправіць на yes. Запусціць дэман quagga і ўсталяваць яго аўтазапуск пры запуску КШ камандай update-rc.d quagga enable.
Калі налада GRE-тунэляў і OSPF выканана дакладна, то на КШ і маршрутызатарах ядра павінны з'явіцца маршруты ў сетцы астатніх пляцовак і, такім чынам, узнікае сеткавая складнасць паміж лакальнымі сеткамі.
Шыфруем перадаваны трафік
Як ужо было напісана, звычайна пры шыфраванні паміж пляцоўкамі мы паказваем дыяпазоны IP-адрасоў (ACL), паміж якімі шыфруецца трафік: калі адрасы крыніцы і атрымальніка пападаюць у гэтыя дыяпазоны, то трафік паміж імі шыфруецца. Аднак у дадзеным праекце структура дынамічная і адрасы могуць мяняцца. Так як мы ўжо наладзілі GRE-тунэляванне, у якасці адрасоў крыніцы і атрымальніка для шыфравання трафіку можам паказаць вонкавыя адрасы КШ – бо для шыфравання прыходзіць трафік, ужо інкапсуляваным пратаколам GRE. Іншымі словамі, шыфруецца ўсё, што пападае ў КШ з лакальнай сеткі адной пляцоўкі ў бок сетак, якія былі анансаваныя іншымі пляцоўкамі. А ўжо ўнутры кожнай з пляцовак можа выконвацца любая пераадрасацыя. Такім чынам, пры якой-небудзь змене лакальных сетак адміністратару дастаткова мадыфікаваць анонсы, якія ідуць з яго сеткі ў бок КШ, і яна стане даступнай для іншых пляцовак.
Шыфраванне ў КШ S-Terra выконваецца з дапамогай пратаколу IPSec. Мы выкарыстоўваем алгарытм «Конік» у адпаведнасці з ДАСТ Р 34.12-2015, а для сумяшчальнасці са старымі версіямі можна прымяніць ДАСТ 28147-89. Аўтэнтыфікацыя тэхнічна можа выконвацца як на наканаваных ключах (PSK), так і на сертыфікатах. Тым не менш у прамысловай эксплуатацыі неабходна выкарыстоўваць сертыфікаты, выпушчаныя па ДАСТ Р 34.10-2012.
Праца з сертыфікатамі, кантэйнерамі і CRL выконваецца з дапамогай утыліты cert_mgr. Перш за ўсё з дапамогай каманды cert_mgr create неабходна сфарміраваць кантэйнер закрытага ключа і запыт на сертыфікат, які будзе накіраваны ў Цэнтр кіравання сертыфікатамі. Пасля атрымання сертыфіката яго разам з каранёвым сертыфікатам УЦ і CRL (калі выкарыстоўваецца) неабходна імпартаваць камандай cert_mgr import. Упэўніцца ў тым, што ўсе сертыфікаты і CRL усталяваліся можна камандай cert_mgr show.
Пасля паспяховай усталёўкі сертыфікатаў пераходзім у Cisco-like кансоль для налады IPSec.
Ствараем IKE-палітыку, у якой указваюцца жаданыя алгарытмы і параметры ствараемага абароненага канала, якія будуць прапанаваны партнёру для ўзгаднення.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#authentication sign
#group vko2
#lifetime 3600
Дадзеная палітыка прымяняецца пры пабудове першай фазы IPSec. Вынікам паспяховага праходжання першай фазы служыць устанаўленне SA (Security Association).
Далей нам запатрабуецца вызначыць спіс IP-адрасоў крыніцы і атрымальніка (ACL) для шыфравання, сфармаваць набор пераўтварэнняў (transform set), стварыць крыптаграфічную карту (crypto map) і прывязаць яе да вонкавага інтэрфейсу КШ.
Задаем ACL:
#ip access-list extended site1
#permit gre host 10.111.21.3 host 10.111.22.3
Набор пераўтварэнняў (гэтак жа, як і для першай фазы, выкарыстоўваем алгарытм шыфравання «Конік» з выкарыстаннем рэжыму выпрацоўкі імітаўстаўкі):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Ствараем крыптакарту, паказваем ACL, transform set і адрас балю:
#crypto map MAIN 100 ipsec-isakmp
#match address site1
#set transform-set GOST
#set peer 10.111.22.3
Прывязваем крыптакарту да знешняга інтэрфейсу КШ:
#interface GigabitEthernet0/0
#ip address 10.111.21.3 255.255.255.0
#crypto map MAIN
Для шыфравання каналаў з іншымі пляцоўкамі неабходна паўтарыць працэдуру стварэння ACL і крыптакарты, змяніўшы назву ACL, IP-адрасы і нумар крыптакарты.
Звярніце ўвагу! У тым выпадку, калі не выкарыстоўваецца праверка сертыфікатаў па CRL, гэта неабходна відавочна паказаць:
#crypto pki trustpoint s-terra_technological_trustpoint
#revocation-check none
На гэтым настройку можна лічыць завершанай. У выснове каманд Cisco-like кансолі show crypto isakmp sa и show crypto ipsec sa павінны адлюстроўвацца пабудаваныя першыя і другія фазы IPSec. Гэтую ж інфармацыю можна атрымаць з дапамогай каманды sa_mgr show, выкананай з debian shеll. У выснове каманды cert_mgr show павінны з'явіцца сертыфікаты выдаленых пляцовак. Статус такіх сертыфікатаў будзе аддалены. У тым выпадку, калі тунэлі не будуюцца, неабходна зазірнуць у лог VPN-сэрвісу, які захоўваецца ў файле. /var/log/cspvpngate.log. Поўны спіс лог-файлаў з апісаннем іх зместу прысутнічае ў дакументацыі.
Маніторым «здароўе» сістэмы
У КШ S-Terra для маніторынгу выкарыстоўваецца стандартны дэман snmpd. Акрамя тыповых для Linux параметраў, S-Terra "са скрынкі" падтрымлівае выдачу дадзеных аб IPSec-тунэлях паводле CISCO-IPSEC-FLOW-MONITOR-MIB, чым мы і карыстаемся, адсочваючы стан IPSec-тунэляў. Таксама падтрымліваецца функцыянал кастамных OID'аў якія выдаюць у якасці значэнняў вынікі выканання скрыпту. Гэтая магчымасць дазваляе нам адсочваць тэрміны заканчэння сертыфікатаў. Напісаны скрыпт парсіць выснову каманды cert_mgr show і ў выніку выдае колькасць дзён да заканчэння лакальнага і каранёвага сертыфікатаў. Дадзены прыём незаменны пры адміністраванні вялікай колькасці КШ.
У чым цымус такога шыфравання
Уся апісаная вышэй функцыянальнасць падтрымліваецца са скрынкі КШ S-Terra. Гэта значыць не прыйшлося ўсталёўваць ніякіх дадатковых модуляў, якія маглі б паўплываць на сертыфікацыю крыпташлюзаў і атэстацыю ўсёй інфармацыйнай сістэмы. Каналы паміж пляцоўкамі могуць быць любыя, хаця праз інтэрнэт.
Дзякуючы таму, што пры змене ўнутранай інфраструктуры не трэба пераналаджваць крыпташлюзы, сістэма працуе як паслуга, што вельмі зручна для заказчыка: ён можа свае сэрвісы (кліенцкія і серверныя), размяшчаць на любых адрасах, і ўсе змены дынамічна перададуцца паміж шыфравальным абсталяваннем.
Безумоўна, шыфраванне за кошт накладных выдаткаў (overhead) уплывае на хуткасць перадачы дадзеных, але нязначна – прапускная здольнасць канала можа знізіцца максімум на 5-10%. Пры гэтым тэхналогія пратэставана і паказала добрыя вынікі нават на спадарожнікавых каналах, якія даволі нестабільныя і маюць нізкую прапускную здольнасць.
Ігар Вінаходаў, інжынер 2-ой лініі адміністравання "Ростелеком-Салар"
Крыніца: habr.com