Якщо ваша компанія передає або отримує через мережу перданні та іншу конфіденційну інформацію, що підлягає захисту відповідно до законодавства, потрібно застосовувати шифрування за ГОСТом. Сьогодні ми розповімо, як запровадили таке шифрування на базі криптошлюзу (КШ) 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 командою система. Встановлюємо власний пароль для користувача корінь командою passwd.
На кожному КШ настроюється окремий тунель для кожного майданчика. Налаштування тунельного інтерфейсу здійснюється у файлі / etc / network / interfaces. За створення самого інтерфейсу відповідає утиліта 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