Jeśli Twoja firma przekazuje lub otrzymuje dane osobowe oraz inne poufne informacje, które muszą być chronione zgodnie z przepisami prawa, konieczne jest zastosowanie szyfrowania według standardów GOST. Dziś opowiemy, jak wdrożyliśmy takie szyfrowanie na bazie bramki kryptograficznej (KШ) S-Terra u jednego z naszych klientów. Ta historia zainteresuje specjalistów ds. bezpieczeństwa oraz inżynierów, projektantów i architektów. Nie będziemy wnikać głęboko w szczegóły technicznej konfiguracji w tym poście — skoncentrujemy się na kluczowych elementach podstawowej konfiguracji. Znajdziesz ogromną ilość dokumentacji na temat konfiguracji demonów systemu Linux, na którym bazuje KШ S-Terra, udostępnionych publicznie w internecie. Dokumentacja dotycząca konfiguracji oprogramowania S-Terra jest również ogólnodostępna na stronie producenta.
Kilka słów o projekcie
Topologia sieci klienta była typowa — pełna siatka między centrum a oddziałami. Konieczne było wdrożenie szyfrowania kanałów wymiany informacji między wszystkimi lokalizacjami, których było 8.
W tego typu projektach wszystko zazwyczaj jest statyczne: na bramkach kryptograficznych (KШ) ustawia się statyczne trasy w lokalnej sieci lokalizacji, definiuje się listy adresów IP (ACL) do szyfrowania. Jednak w tym przypadku lokalizacje nie mają centralnego zarządzania i w ich lokalnych sieciach mogą dziać się różne rzeczy: sieci mogą być dodawane, usuwane i wszelakie modyfikowane. Aby uniknąć ponownego konfigurowania trasowania i ACL na KШ przy zmianie adresacji lokalnych sieci w lokalizacjach, podjęto decyzję o użyciu tunelowania GRE oraz dynamicznego trasowania OSPF, do którego włączono wszystkie KШ oraz większość routerów warstwy rdzenia sieci w lokalizacjach (w niektórych lokalizacjach administratorzy infrastruktury postanowili użyć SNAT w kierunku KШ na routerach rdzeń).
Tunelowanie GRE pozwoliło rozwiązać dwa zadania:
1. Użyć w ACL do szyfrowania adresu IP zewnętrznego interfejsu KШ, w którym enkapsuluje cały ruch kierowany do innych lokalizacji.
2. Zorganizować tuneli p-t-p między KШ, które pozwalają na skonfigurowanie dynamicznego trasowania (w naszym przypadku między lokalizacjami zorganizowano dostawcę MPLS L3VPN).
Klient zamówił realizację szyfrowania jako usługi. W przeciwnym razie musiałby nie tylko utrzymywać bramki kryptograficzne lub przekazywać to do outsourcingu jakiejś organizacji, ale także samodzielnie monitorować cykl życia certyfikatów szyfrowania, terminowo je odnawiać oraz instalować nowe.
A teraz przypomnienie – jak i co konfigurowaliśmy
Podmiot KII na uwadze: konfigurujemy bramkę kryptograficzną
Podstawowa konfiguracja sieci
Przede wszystkim uruchamiamy nową bramkę KŚ i trafiamy do konsoli administracyjnej. Należy zacząć od zmiany hasła wbudowanego administratora — polecenie change user password administrator. Następnie należy przeprowadzić procedurę inicjalizacji (polecenie initialize), w trakcie której wprowadza się dane licencji i inicjalizuje generator liczb losowych (GLR).
Zwróć uwagę! Podczas inicjalizacji KŚ S-Terra ustalana jest polityka bezpieczeństwa, zgodnie z którą interfejsy bramy bezpieczeństwa nie przepuszczają pakietów. Należy albo utworzyć własną politykę, albo za pomocą polecenia run csconf_mgr activate wykonać aktywację preinstalowanej polityki zezwalającej.
Następnie należy skonfigurować adresację zewnętrznych i wewnętrznych interfejsów, a także trasę domyślną. Pracę z konfiguracją sieciową KŚ oraz konfigurację szyfrowania zaleca się wykonywać przez konsolę przypominającą Cisco. Ta konsola jest przeznaczona do wprowadzania poleceń podobnych do poleceń Cisco IOS. Konfiguracja stworzona za pomocą konsoli przypominającej Cisco jest następnie konwertowana na odpowiednie pliki konfiguracyjne, z którymi pracują demony systemu operacyjnego. Można przejść do konsoli przypominającej Cisco z konsoli administracyjnej poleceniem configure.
Zmiana hasła dla wbudowanego użytkownika cscons i enable:
>enable
Hasło: csp (domyślne)
#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
Wychodzimy z konsoli przypominającej Cisco i przechodzimy do powłoki debian poleceniem system. Ustalamy własne hasło dla użytkownika root poleceniem passwd.
Na każdej KŚ konfiguruje się oddzielny tunel dla każdej lokalizacji. Konfiguracja interfejsu tunelowego odbywa się w pliku /etc/network/interfaces. Utworzenie samego interfejsu odpowiada narzędzie IP tunnel, które jest częścią preinstalowanego zestawu iproute2. Polecenie utworzenia interfejsu zapisuje się w opcji pre-up.
Przykład konfiguracji typowego interfejsu tunelowego:
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
Zwróć uwagę! Należy zauważyć, że ustawienia interfejsów tunelowych powinny znajdować się poza sekcją
###netifcfg-begin###
*****
###netifcfg-end###
W przeciwnym razie te ustawienia zostaną nadpisane przy zmianie ustawień sieciowych interfejsów fizycznych za pomocą konsoli podobnej do Cisco.
Routing dynamiczny
W S-Terra routing dynamiczny jest wdrażany za pomocą pakietu oprogramowania Quagga. Do konfiguracji OSPF potrzebne będzie włączenie i skonfigurowanie demonów zebra i ospfd. Demon zebra odpowiada za interakcję między demonami routingu a systemem operacyjnym. Demon ospfd, jak sugeruje jego nazwa, odpowiada za wdrożenie protokołu OSPF.
Konfiguracja OSPF wykonywana jest zarówno za pośrednictwem konsoli demona, jak i bezpośrednio przez plik konfiguracyjny /etc/quagga/ospfd.conf. Do pliku dodawane są wszystkie fizyczne i tunelowe interfejsy uczestniczące w routingu dynamicznym, a także ogłaszane są sieci, które będą reklamowane i przyjmować ogłoszenia.
Przykład konfiguracji, którą należy dodać do 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
W tym przypadku adresy 192.168.1.x/31 są przydzielane do tunelowych sieci ptp pomiędzy lokalizacjami, a adresy 192.168.2.x/30 — do sieci tranzytowych między KSH a rdzeniowymi routerami.
Zwróć uwagę! Aby zmniejszyć tabelę routingu w dużych instalacjach, można przefiltrować reklamy samych sieci tranzytowych za pomocą konstrukcji no redistribute connected lub redistribute connected route-map.
Po skonfigurowaniu demonów należy zmienić status uruchamiania demonów w /etc/quagga/daemons. W opcjach zebra i ospfd no należy zmienić na yes. Uruchom demon quagga i ustaw automatyczne uruchamianie przy starcie KSH za pomocą komendy update-rc.d quagga enable.
Jeśli konfiguracja tuneli GRE i OSPF została wykonana poprawnie, to na KSH i rdzeniowych routerach powinny pojawić się trasy do sieci innych lokalizacji, a tym samym powstaje łączność sieciowa między lokalnymi sieciami.
Szyfrujemy przesyłany ruch
Jak już wspomniano, zazwyczaj przy szyfrowaniu między platformami wskazujemy zakresy adresów IP (ACL), między którymi szyfrowany jest ruch: jeśli adresy źródłowe i docelowe mieszczą się w tych zakresach, ruch między nimi jest szyfrowany. Jednak w tym projekcie struktura jest dynamiczna i adresy mogą się zmieniać. Ponieważ już skonfigurowaliśmy tunel GRE, jako adresy źródłowe i docelowe do szyfrowania ruchu możemy wskazać zewnętrzne adresy KSH — ponieważ szyfrowany jest ruch, który już przychodzi z zalogowanym protokołem GRE. Innymi słowy, szyfrowane jest wszystko, co trafia do KSH z lokalnej sieci jednej platformy w kierunku sieci, które zostały ogłoszone przez inne platformy. A wewnątrz każdej z platform może być wykonywane dowolne przekierowanie. W ten sposób, w przypadku jakiejkolwiek zmiany lokalnych sieci, administrator musi tylko zmodyfikować ogłoszenia idące z jego sieci w kierunku KSH, a ta stanie się dostępna dla innych platform.
Szyfrowanie w KSH S-Terra realizowane jest za pomocą protokołu IPSec. Używamy algorytmu „Kleshch” zgodnie z GOST R 34.12-2015, a dla zgodności ze starszymi wersjami można zastosować GOST 28147-89. Uwierzytelnianie technicznie może być realizowane zarówno na ustalonych kluczach (PSK), jak i na certyfikatach. Niemniej jednak w eksploatacji przemysłowej należy korzystać z certyfikatów wydanych zgodnie z GOST R 34.10-2012.
Praca z certyfikatami, kontenerami i CRL odbywa się za pomocą narzędzia cert_mgr. Najpierw należy za pomocą polecenia cert_mgr create utworzyć kontener klucza prywatnego oraz żądanie certyfikatu, które zostanie przesłane do Centrum zarządzania certyfikatami. Po otrzymaniu certyfikatu należy go wraz z certyfikatem głównym CA i CRL (jeśli jest używane) zaimportować poleceniem cert_mgr import. Można się upewnić, że wszystkie certyfikaty i CRL zostały zainstalowane, używając polecenia cert_mgr show.
. Po pomyślnym zainstalowaniu certyfikatów przechodzimy do konsoli w stylu Cisco w celu skonfigurowania IPSec.
Tworzymy politykę IKE, w której określamy żądane algorytmy i parametry tworzonych zabezpieczonych połączeń, które zostaną zaproponowane partnerowi do uzgodnienia.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#authentication sign
#group vko2
#lifetime 3600
Ta polityka stosowana jest przy budowie pierwszej fazy IPSec. Wynikiem pomyślnego przejścia pierwszej fazy jest ustanowienie SA (Security Association).
Następnie będziemy musieli określić listę adresów IP źródła i odbiorcy (ACL) do szyfrowania, utworzyć zestaw transformacji (transform set), stworzyć mapę kryptograficzną (crypto map) i powiązać ją z zewnętrznym interfejsem KSH.
Definiujemy ACL:
#ip access-list extended site1
#permit gre host 10.111.21.3 host 10.111.22.3
Zestaw transformacji (tak jak w pierwszej fazie, używamy algorytmu szyfrowania „Grasshopper” w trybie generowania wstawki):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Tworzymy mapę kryptograficzną, określając ACL, zestaw transformacji i adres sąsiada:
#crypto map MAIN 100 ipsec-isakmp
#match address site1
#set transform-set GOST
#set peer 10.111.22.3
Powiązujemy mapę kryptograficzną z zewnętrznym interfejsem KSH:
#interface GigabitEthernet0/0
#ip address 10.111.21.3 255.255.255.0
#crypto map MAIN
Aby zaszyfrować kanały z innymi lokalizacjami, musimy powtórzyć procedurę tworzenia ACL i mapy kryptograficznej, zmieniając nazwę ACL, adresy IP i numer mapy kryptograficznej.
Zwróć uwagę! W przypadku gdy nie jest używane sprawdzanie certyfikatów przez CRL, należy to wyraźnie określić:
#crypto pki trustpoint s-terra_technological_trustpoint
#revocation-check none
Na tym można uznać konfigurację za zakończoną. W wyjściu poleceń w konsoli przypominającej Cisco show crypto isakmp sa i show crypto ipsec sa powinny być odzwierciedlone zbudowane pierwsza i druga faza IPSec. Tę samą informację można uzyskać za pomocą polecenia sa_mgr show, wykonanego z powłoki debiana. W wyjściu polecenia cert_mgr show powinny pojawić się certyfikaty zdalnych lokalizacji. Status takich certyfikatów będzie remote. W przypadku, gdy tunele się nie budują, należy zajrzeć do logu VPN-usługi, która jest przechowywana w pliku /var/log/cspvpngate.log. Pełna lista plików logów z opisem ich zawartości znajduje się w dokumentacji.
Monitorujemy „zdrowie” systemu
W KSH S-Terra używamy standardowego demona snmpd do monitorowania. Oprócz typowych parametrów dla Linuxa, S-Terra „z pudełka” wspiera wydawanie danych o tunelach IPSec zgodnie z CISCO-IPSEC-FLOW-MONITOR-MIB, z czego korzystamy, śledząc stan tuneli IPSec. Obsługiwane są również funkcjonalności niestandardowych OID, które jako wartości zwracają wyniki wykonania skryptu. Ta możliwość pozwala nam śledzić terminy wygaśnięcia certyfikatów. Napisany skrypt parsuje wyjście polecenia cert_mgr show i w rezultacie zwraca liczbę dni do wygaśnięcia lokalnego i głównego certyfikatu. Ta metoda jest niezastąpiona w administracji dużą liczbą KSH.
Na czym polega sens tego szyfrowania
Cała opisana wcześniej funkcjonalność jest wspierana «prosto z pudełka» przez KSH S-Terra. Oznacza to, że nie trzeba instalować żadnych dodatkowych modułów, które mogłyby wpłynąć na certyfikację bramek kryptograficznych i akredytację całego systemu informacyjnego. Kanały między platformami mogą być dowolne, nawet przez internet.
Dzięki temu, że przy zmianie wewnętrznej infrastruktury nie ma potrzeby ponownego konfigurowania bramek kryptograficznych, system działa jako usługa, co jest bardzo wygodne dla klienta: może umieszczać swoje usługi (klienckie i serwerowe) pod dowolnymi adresami, a wszystkie zmiany będą dynamicznie przekazywane między urządzeniami szyfrującymi.
Bez wątpienia szyfrowanie z powodu narzutów (overhead) wpływa na prędkość przesyłu danych, ale w niewielkim stopniu — przepustowość kanału może spaść maksymalnie o 5-10%. Technologia została przetestowana i wykazała dobre wyniki nawet na kanałach satelitarnych, które są dość niestabilne i mają niską przepustowość.
Igor Winokhodow, inżynier 2. linii administracji „Rosnieft-Solar”
Źródło: habr.com
