Als uw bedrijf persoonsgegevens en andere vertrouwelijke informatie via het netwerk overdraagt of ontvangt die bescherming vereist volgens de wetgeving, is encryptie volgens de GOST-standaard noodzakelijk. Vandaag vertellen we hoe we dergelijke encryptie hebben geïmplementeerd op basis van de crypto gateway (KSH) S-Terra bij een van onze klanten. Dit verhaal zal interessant zijn voor experts in informatiebeveiliging, evenals voor ingenieurs, ontwerpers en architecten. We zullen ons in deze post niet diep in de nuances van de technische configuratie verdiepen, maar ons concentreren op de belangrijkste punten van de basisinstellingen. Er is een enorme hoeveelheid documentatie beschikbaar over het configureren van demonen op Linux, het besturingssysteem waarop KSH S-Terra is gebaseerd. Documentatie over het configureren van de propriëtaire software S-Terra is ook openbaar beschikbaar op van de fabrikant.
Een paar woorden over het project
De netwerktopologie bij de klant was standaard: full mesh tussen het hoofdkwartier en de filialen. Er was behoefte aan het implementeren van encryptie voor de informatie-uitwisselingskanalen tussen alle locaties, die in totaal 8 waren.
Normaal gesproken is alles in dergelijke projecten statisch: op crypto gateways (KSH) worden statische routes naar het lokale netwerk van de locatie ingesteld en worden IP-adressenlijsten (ACL) voor encryptie gedefinieerd. In dit geval is er echter geen centrale controle over de locaties, en binnen hun lokale netwerken kan van alles gebeuren: netwerken kunnen worden toegevoegd, verwijderd en op verschillende manieren worden gemodificeerd. Om te voorkomen dat de routering en ACL op de KSH moeten worden opnieuw ingesteld bij wijzigingen in de adressering van de lokale netwerken op de locaties, is besloten om GRE-tunneling en dynamische routering met OSPF te gebruiken, waarbij alle KSH en de meeste kernrouters op de locaties zijn opgenomen (op sommige locaties gaven infrastructuurbeheerders de voorkeur aan SNAT richting KSH op de kernrouters).
GRE-tunneling maakte het mogelijk om twee taken op te lossen:
1. Gebruik IP-adressen van de externe interface van de KSH in de ACL voor encryptie, waarin al het verkeer wordt ingekapseld dat naar andere locaties gaat.
2. P-t-p tunnels tussen de KSH's opzetten, die het mogelijk maken om dynamische routering in te stellen (in ons geval is er tussen de locaties een provider MPLS L3VPN georganiseerd).
De klant heeft de implementatie van encryptie als een dienst besteld. Anders zou hij niet alleen crypto-gates moeten onderhouden of uitbesteden aan een organisatie, maar ook zelf de levenscyclus van encryptie-certificaten moeten volgen, deze tijdig verlengen en nieuwe installeren.
En nu de memo zelf - hoe en wat we hebben ingesteld
Opmerking voor KII-subject: we configureren de crypto-gate
Basisnetwerkconfiguratie
Allereerst starten we de nieuwe CG en komen we in de administratconsole. Begin met het wijzigen van het wachtwoord van de ingebouwde administrator — de opdracht change user password administrator. Vervolgens moet de initialisatieprocedure worden uitgevoerd (de opdracht initialize) waarin licentiegegevens worden ingevoerd en de random number generator (RNG) wordt geïnitialiseerd.
Let op! Bij de initialisatie van de CG S-Terra wordt er een beveiligingsbeleid ingesteld waarbij de interfaces van de beveiligingsgateway geen pakketten doorlaten. Het is noodzakelijk om ofwel een eigen beleid te creëren, of met behulp van de opdracht run csconf_mgr activate de vooraf ingestelde toestemming te activeren.
Daarna moet de adressering van de externe en interne interfaces worden ingesteld, evenals de standaardroute. Het werken met de netwerkinstellingen van de CG en de encryptie-configuratie heeft de voorkeur om via de Cisco-achtige console te worden uitgevoerd. Deze console is bedoeld voor het invoeren van opdrachten die vergelijkbaar zijn met de opdrachten van Cisco IOS. De configuratie die met behulp van de Cisco-achtige console is gevormd, wordt vervolgens geconverteerd naar de bijbehorende configuratiebestanden waarmee de daemon van het besturingssysteem werkt. Je kunt naar de Cisco-achtige console gaan vanuit de administratconsole met de opdracht configure.
Laten we de wachtwoorden voor de ingebouwde gebruiker cscons en enable wijzigen:
>enable
Wachtwoord: csp (voorgesteld)
#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
We verlaten de Cisco-achtige console en gaan naar de debian shell met het commando system. We stellen een wachtwoord in voor de gebruiker root met het commando passwd.
Op elke CG wordt een afzonderlijke tunnel voor elke site ingesteld. De configuratie van de tunnelinterface gebeurt in het bestand /etc/network/interfaces. De IP tunnel-tool, die deel uitmaakt van de standaard iproute2-software, is verantwoordelijk voor het creëren van de interface. De opdracht voor het creëren van de interface wordt in de pre-up optie geschreven.
Voorbeeldconfiguratie voor een typische tunnelinterface:
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
Let op! Het is belangrijk op te merken dat de instellingen van tunnelinterfaces buiten de sectie moeten worden geplaatst.
###netifcfg-begin###
*****
###netifcfg-end###
Anders zullen deze instellingen worden overschreven bij het wijzigen van de netwerkinstellingen van fysieke interfaces via een Cisco-achtige console.
Dynamische routering
In S-Terra wordt dynamische routering geïmplementeerd met behulp van de Quagga softwarepakket. Voor de configuratie van OSPF hebben we inschakeling en configuratie van de demonen nodig. zebra en ospfd. De zebra demon is verantwoordelijk voor de interactie tussen de routeringsdemonen en het besturingssysteem. De ospfd demon, zoals de naam al aangeeft, is verantwoordelijk voor de implementatie van het OSPF-protocol.
De configuratie van OSPF kan plaatsvinden via de console van de demon of rechtstreeks via het configuratiebestand. /etc/quagga/ospfd.conf. In het bestand worden alle fysieke en tunnelinterfaces opgenomen die deelnemen aan de dynamische routering, evenals de netwerken die zullen worden aangekondigd en de aankondigingen die worden ontvangen.
Voorbeeld configuratie die moet worden toegevoegd aan 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
In dit geval zijn de adressen 192.168.1.x/31 gereserveerd voor point-to-point tunnelnetwerken tussen locaties, terwijl de adressen 192.168.2.x/30 gereserveerd zijn voor transitnetwerken tussen de KSH en de kernrouter.
Let op! Om de routeringstabel in grote installaties te verkleinen, kan de aankondiging van de transitnetwerken worden gefilterd met behulp van constructies. no redistribute connected of redistribute connected route-map.
Na het configureren van de demonen, moet de startstatus van de demonen in /etc/quagga/daemons. In de opties moet zebra en ospfd no worden gewijzigd naar yes. Start de quagga demon en zorg ervoor dat deze automatisch opstart bij het opstarten van de KSH met de opdracht. update-rc.d quagga enable.
Als de configuratie van GRE-tunnels en OSPF correct is uitgevoerd, moeten er routes verschijnen op de KSH en de kernrouters in de netwerken van andere locaties, waardoor netwerkconnectiviteit tussen lokale netwerken ontstaat.
We versleutelen het verzonden verkeer.
Zoals al eerder vermeld, geven we doorgaans de IP-adresbereiken (ACL) aan tussen platforms voor versleuteling van verkeer: als de bron- en bestemmingsadressen binnen deze bereiken vallen, wordt het verkeer tussen hen versleuteld. In dit project is de structuur echter dynamisch en kunnen de adressen veranderen. Aangezien we al GRE-tunneling hebben ingesteld, kunnen we externe adressen van het KSH opgeven als bron- en bestemmingsadressen voor de versleuteling van verkeer — immers, het verkeer dat moet worden versleuteld, is al ingekapseld met de GRE-protocol. Met andere woorden, alles wat van het lokale netwerk van het ene platform naar de netwerken die door andere platforms zijn aangekondigd, naar het KSH komt, wordt versleuteld. Binnen elk van de platforms kan ondertussen elke vorm van doorsturen plaatsvinden. Bij enige wijziging van lokale netwerken hoeft de beheerder alleen de aankondigingen vanuit zijn netwerk naar het KSH te modificeren, en het zal toegankelijk worden voor andere platforms.
Versleuteling in het KSH S-Terra wordt uitgevoerd via het IPSec-protocol. We gebruiken het algoritme 'Caterpillar' volgens GOST R 34.12-2015, en voor compatibiliteit met oudere versies kan GOST 28147-89 worden toegepast. Authenticatie kan technisch worden uitgevoerd met zowel vooraf gedefinieerde sleutels (PSK) als met certificaten. In industriële toepassingen moeten echter certificaten worden gebruikt die zijn uitgegeven volgens GOST R 34.10-2012.
Het werken met certificaten, containers en CRL gebeurt met behulp van de tool cert_mgr. Allereerst moet met behulp van de opdracht cert_mgr create een container voor de privésleutel en een certificaataanvraag worden aangemaakt, die naar het Certificaatbeheercentrum zal worden gestuurd. Na ontvangst van het certificaat moet dit samen met het rootcertificaat van de CA en de CRL (indien gebruikt) worden geïmporteerd met de opdracht cert_mgr import. Om te controleren of alle certificaten en CRL zijn geïnstalleerd, kan de opdracht cert_mgr show.
worden gebruikt. Na succesvolle installatie van de certificaten gaan we naar de Cisco-achtige console voor het instellen van IPSec.
We creëren een IKE-beleid waarin de gewenste algoritmen en parameters van de te creëren beveiligde tunnel worden aangegeven, die aan de partner voor onderhandeling worden aangeboden.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#authentication sign
#group vko2
#lifetime 3600
Dit beleid wordt toegepast bij het opbouwen van de eerste fase van IPSec. Het resultaat van een succesvolle afronding van de eerste fase is het tot stand brengen van een SA (Security Association).
Vervolgens moeten we de lijst van bron- en bestemmings-IP-adressen (ACL) voor de encryptie bepalen, een transformatieset (transform set) vormen, een cryptografische kaart (crypto map) aanmaken en deze aan de externe interface van de KSH koppelen.
Stel de ACL in:
#ip access-list extended site1
#permit gre host 10.111.21.3 host 10.111.22.3
Transformatieset (net als in de eerste fase gebruiken we de encryptie-algoritme "Grasshopper" met gebruik van de imitatietoevoegmodus):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Maak de cryptokaart aan, geef de ACL, transformatieset en het adres van de peer op:
#crypto map MAIN 100 ipsec-isakmp
#match address site1
#set transform-set GOST
#set peer 10.111.22.3
Koppel de cryptokaart aan de externe interface van de KSH:
#interface GigabitEthernet0/0
#ip address 10.111.21.3 255.255.255.0
#crypto map MAIN
Voor de encryptie van kanalen met andere sites moet de procedure voor het aanmaken van de ACL en de cryptokaart herhaald worden, waarbij de naam van de ACL, de IP-adressen en het nummer van de cryptokaart gewijzigd worden.
Let op! Als er geen certificaatverificatie via CRL wordt gebruikt, moet dit expliciet worden aangegeven:
#crypto pki trustpoint s-terra_technological_trustpoint
#revocation-check none
Met de configuratie kan nu worden aangenomen dat deze is afgerond. In de uitvoer van de Cisco-achtige console show crypto isakmp sa en show crypto ipsec sa moeten de voltooide eerste en tweede fasen van IPSec worden weergegeven. Deze informatie kan ook worden verkregen met het commando sa_mgr show, uitgevoerd vanuit de debian shell. In de uitvoer van het commando cert_mgr show moeten de certificaten van de externe sites verschijnen. De status van dergelijke certificaten zal zijn remote. In het geval dat er geen tunnels worden opgebouwd, is het nodig om in de log te kijken VPN-service, die in het bestand wordt opgeslagen /var/log/cspvpngate.log. Een complete lijst van logbestanden met hun beschrijvingen staat in de documentatie.
We monitoren de 'gezondheid' van het systeem
In de KSH S-Terra wordt de standaard daemon snmpd gebruikt voor monitoring. Naast de typische parameters voor Linux ondersteunt S-Terra "out of the box" het verstrekken van gegevens over IPSec-tunnels volgens CISCO-IPSEC-FLOW-MONITOR-MIB, wat we gebruiken om de status van IPSec-tunnels te volgen. Tevens wordt functionaliteit van aangepaste OID's ondersteund die als waarden de resultaten van scriptuitvoeringen opgeven. Deze mogelijkheid stelt ons in staat om de vervaldatums van certificaten te volgen. Het geschreven script parseert de uitvoer van het commando cert_mgr show en levert als resultaat het aantal dagen tot de vervaldatum van de lokale en rootcertificaten. Deze aanpak is onmisbaar bij het beheer van een groot aantal KSH's.
Wat is het voordeel van deze encryptie?
Alle bovengenoemde functionaliteiten worden standaard ondersteund door de S-Terra crypto-gateway. Dit betekent dat er geen extra modules hoeven te worden geïnstalleerd die de certificering van de crypto-gateways en de goedkeuring van het hele informatiesysteem zouden kunnen beïnvloeden. De kanalen tussen de locaties kunnen elk zijn, zelfs via internet.
Dankzij het feit dat er bij wijzigingen in de interne infrastructuur geen herconfiguratie van de crypto-gateways nodig is, werkt het systeem als een dienst, wat zeer handig is voor de klant: ze kunnen hun services (klant- en serverzijde) op elke locatie plaatsen en alle wijzigingen worden dynamisch doorgegeven tussen de encryptieapparatuur.
Zonder twijfel heeft encryptie door overhead invloed op de snelheid van gegevensoverdracht, maar dit is minimaal - de doorvoersnelheid van het kanaal kan maximaal met 5-10% afnemen. Deze technologie is getest en heeft goede resultaten laten zien, zelfs op satellietverbindingen, die vrij onbetrouwbaar zijn en een lage doorvoersnelheid hebben.
Igor Vinokhodov, tweede lijns administrator bij 'Rostelecom-Solar'
Bron: habr.com
