Als uw bedrijf persoonlijke gegevens en andere vertrouwelijke informatie verzendt of ontvangt via het netwerk dat onderworpen is aan bescherming in overeenstemming met de wet, is het verplicht om GOST-codering te gebruiken. Vandaag vertellen we je hoe we een dergelijke encryptie op basis van de S-Terra crypto gateway (CS) bij een van de klanten hebben geïmplementeerd. Dit verhaal zal interessant zijn voor informatiebeveiligingsspecialisten, maar ook voor ingenieurs, ontwerpers en architecten. We zullen in dit bericht niet diep ingaan op de nuances van de technische configuratie; we zullen ons concentreren op de belangrijkste punten van de basisconfiguratie. Grote hoeveelheden documentatie over het opzetten van Linux OS-daemons, waarop de S-Terra CS is gebaseerd, zijn gratis beschikbaar op internet. Documentatie voor het opzetten van eigen S-Terra-software is ook openbaar beschikbaar op fabrikant.
Een paar woorden over het project
De netwerktopologie van de klant was standaard: volledig mesh tussen het centrum en de vestigingen. Het was noodzakelijk om encryptie van informatie-uitwisselingskanalen tussen alle sites, waarvan er acht waren, te introduceren.
Meestal is bij dergelijke projecten alles statisch: statische routes naar het lokale netwerk van de site worden ingesteld op cryptogateways (CG's), lijsten met IP-adressen (ACL's) voor codering worden geregistreerd. In dit geval hebben de sites echter geen gecentraliseerde controle en kan er van alles gebeuren binnen hun lokale netwerken: netwerken kunnen op elke mogelijke manier worden toegevoegd, verwijderd en gewijzigd. Om te voorkomen dat de routering en ACL op de KS opnieuw moeten worden geconfigureerd bij het wijzigen van de adressering van lokale netwerken op de locaties, werd besloten om GRE-tunneling en OSPF dynamische routering te gebruiken, die alle KS en de meeste routers op het netwerkkernniveau op de locaties omvat ( op sommige sites gaven infrastructuurbeheerders er de voorkeur aan om SNAT te gebruiken in plaats van KS op kernelrouters).
Met GRE-tunneling konden we twee problemen oplossen:
1. Gebruik het IP-adres van de externe interface van de CS voor codering in de ACL, die al het verkeer omvat dat naar andere sites wordt verzonden.
2. Organiseer ptp-tunnels tussen CS's, waarmee u dynamische routering kunt configureren (in ons geval is de MPLS L3VPN van de provider tussen de sites georganiseerd).
De klant gaf opdracht tot de implementatie van encryptie as a service. Anders zou hij niet alleen crypto-gateways moeten onderhouden of deze aan een organisatie moeten uitbesteden, maar ook onafhankelijk de levenscyclus van encryptiecertificaten moeten monitoren, deze op tijd moeten vernieuwen en nieuwe moeten installeren.
En nu de eigenlijke memo: hoe en wat we hebben geconfigureerd
Noot voor het CII-onderwerp: het opzetten van een cryptogateway
Basis netwerkconfiguratie
Allereerst lanceren we een nieuwe CS en komen we in de beheerconsole. U moet beginnen met het wijzigen van het ingebouwde beheerderswachtwoord - commando verander gebruikerswachtwoord beheerder. Vervolgens moet u de initialisatieprocedure uitvoeren (command initialiseren) waarbij de licentiegegevens worden ingevoerd en de Random Number Sensor (RNS) wordt geïnitialiseerd.
Let op! Wanneer S-Terra CC wordt geïnitialiseerd, wordt een beveiligingsbeleid ingesteld waarbij de beveiligingsgateway-interfaces geen pakketten doorlaten. U moet uw eigen beleid maken of de opdracht gebruiken voer csconf_mgr activatie uit activeer een vooraf gedefinieerd toestemmingsbeleid.
Vervolgens moet u de adressering van externe en interne interfaces configureren, evenals de standaardroute. Het verdient de voorkeur om met de CS-netwerkconfiguratie te werken en de encryptie te configureren via een Cisco-achtige console. Deze console is ontworpen om opdrachten in te voeren die vergelijkbaar zijn met Cisco IOS-opdrachten. De configuratie die wordt gegenereerd met behulp van de Cisco-achtige console wordt op zijn beurt omgezet in de overeenkomstige configuratiebestanden waarmee de OS-daemons werken. Met de opdracht kunt u vanuit de beheerconsole naar de Cisco-achtige console gaan configureer.
Wijzig wachtwoorden voor de ingebouwde gebruikers-cscons en schakel het volgende in:
> inschakelen
Wachtwoord: csp (vooraf geïnstalleerd)
#terminal configureren
#gebruikersnaam cscons privilege 15 geheim 0 #enable geheim 0 De basisnetwerkconfiguratie instellen:
#interface GigabitEthernet0/0
#ip-adres 10.111.21.3 255.255.255.0
#geen afsluiting
#interface GigabitEthernet0/1
#ip-adres 192.168.2.5 255.255.255.252
#geen afsluiting
#ip-route 0.0.0.0 0.0.0.0 10.111.21.254
GRE
Verlaat de Cisco-achtige console en ga met de opdracht naar de debian-shell system. Stel uw eigen wachtwoord in voor de gebruiker wortel team passwd.
Bij elke controlekamer wordt voor elke locatie een aparte tunnel geconfigureerd. De tunnelinterface wordt geconfigureerd in het bestand / Etc / network / interfaces. Het IP-tunnelhulpprogramma, opgenomen in de vooraf geïnstalleerde iproute2-set, is verantwoordelijk voor het maken van de interface zelf. De opdracht voor het maken van de interface wordt in de pre-up-optie geschreven.
Voorbeeldconfiguratie van een typische tunnelinterface:
autosite1
iface site1 inet statisch
adres 192.168.1.4
netmask 255.255.255.254
pre-up ip-tunnel site1-modus toevoegen gre lokaal 10.111.21.3 op afstand 10.111.22.3 sleutel hfLYEg^vCh6p
Let op! Opgemerkt moet worden dat de instellingen voor tunnelinterfaces zich buiten de sectie moeten bevinden
###netifcfg-begin###
*****
###netifcfg-end###
Anders worden deze instellingen overschreven bij het wijzigen van de netwerkinstellingen van fysieke interfaces via een Cisco-achtige console.
Dynamische routering
In S-Terra wordt dynamische routing geïmplementeerd met behulp van het softwarepakket Quagga. Om OSPF te configureren moeten we daemons inschakelen en configureren zebra и ospfd. De zebra-daemon is verantwoordelijk voor de communicatie tussen de routeringsdaemons en het besturingssysteem. De ospfd-daemon is, zoals de naam al doet vermoeden, verantwoordelijk voor de implementatie van het OSPF-protocol.
OSPF wordt geconfigureerd via de daemonconsole of rechtstreeks via het configuratiebestand /etc/quagga/ospfd.conf. Alle fysieke en tunnelinterfaces die deelnemen aan dynamische routering worden aan het bestand toegevoegd en de netwerken waarvoor reclame wordt gemaakt en aankondigingen worden ontvangen, worden ook aangegeven.
Een voorbeeld van de configuratie die moet worden toegevoegd ospfd.conf:
interface eth0
!
interface eth1
!
interfacesite1
!
interfacesite2
ospf-router
ospf router-id 192.168.2.21
netwerk 192.168.1.4/31 gebied 0.0.0.0
netwerk 192.168.1.16/31 gebied 0.0.0.0
netwerk 192.168.2.4/30 gebied 0.0.0.0
In dit geval zijn de adressen 192.168.1.x/31 gereserveerd voor tunnel-ptp-netwerken tussen sites, en worden de adressen 192.168.2.x/30 toegewezen voor transitnetwerken tussen CS en kernelrouters.
Let op! Om de routeringstabel in grote installaties te verkleinen, kunt u de advertenties van de transitnetwerken zelf filteren met behulp van de constructies geen herverdeling aangesloten of Verdeel de verbonden routekaart opnieuw.
Nadat u de daemons hebt geconfigureerd, moet u de opstartstatus van de daemons wijzigen in /etc/quagga/daemons. Bij opties zebra и ospfd geen verandering in ja. Start de quagga-daemon en stel deze in op autorun wanneer u de KS-opdracht start update-rc.d quagga inschakelen.
Als de configuratie van GRE-tunnels en OSPF correct wordt uitgevoerd, moeten routes in het netwerk van andere sites verschijnen op de KSh- en core-routers en ontstaat er dus netwerkconnectiviteit tussen lokale netwerken.
We coderen het verzonden verkeer
Zoals al is geschreven, specificeren we bij het coderen tussen sites meestal IP-adresbereiken (ACL's) waartussen het verkeer wordt gecodeerd: als de bron- en bestemmingsadressen binnen deze bereiken vallen, wordt het verkeer daartussen gecodeerd. In dit project is de structuur echter dynamisch en kunnen adressen veranderen. Omdat we GRE-tunneling al hebben geconfigureerd, kunnen we externe KS-adressen specificeren als bron- en bestemmingsadressen voor het versleutelen van verkeer - verkeer dat al is ingekapseld door het GRE-protocol arriveert voor versleuteling. Met andere woorden, alles wat de CS binnenkomt vanaf het lokale netwerk van de ene site naar netwerken die door andere sites zijn aangekondigd, is gecodeerd. En binnen elk van de sites kan elke omleiding worden uitgevoerd. Als er dus enige verandering plaatsvindt in lokale netwerken, hoeft de beheerder alleen maar de aankondigingen die van zijn netwerk naar het netwerk komen te wijzigen, waarna deze beschikbaar zullen worden voor andere sites.
De codering in S-Terra CS wordt uitgevoerd met behulp van het IPSec-protocol. We gebruiken het algoritme "Grasshopper" in overeenstemming met GOST R 34.12-2015, en voor compatibiliteit met oudere versies kunt u GOST 28147-89 gebruiken. Authenticatie kan technisch gezien worden uitgevoerd op zowel vooraf gedefinieerde sleutels (PSK's) als certificaten. Bij industriële exploitatie is het echter noodzakelijk om certificaten te gebruiken die zijn uitgegeven in overeenstemming met GOST R 34.10-2012.
Werken met certificaten, containers en CRL's gebeurt met behulp van het hulpprogramma cert_mgr. Allereerst gebruik je het commando cert_mgr creëren het is noodzakelijk om een privésleutelcontainer en een certificaataanvraag te genereren, die naar het Certificate Management Center worden verzonden. Na ontvangst van het certificaat moet het samen met het root-CA-certificaat en de CRL (indien gebruikt) met de opdracht worden geïmporteerd cert_mgr importeren. Met de opdracht kunt u ervoor zorgen dat alle certificaten en CRL's worden geïnstalleerd cert_mgr tonen.
Nadat u de certificaten succesvol hebt geïnstalleerd, gaat u naar de Cisco-achtige console om IPSec te configureren.
We creëren een IKE-beleid dat de gewenste algoritmen en parameters specificeert van het beveiligde kanaal dat wordt gecreëerd, dat ter goedkeuring aan de partner wordt aangeboden.
#crypto isakmp-beleid 1000
#encrgost341215k
#hashgost341112-512-tc26
#authenticatieteken
#groep vko2
#levenslang 3600
Dit beleid wordt toegepast bij het bouwen van de eerste fase van IPSec. Het resultaat van de succesvolle afronding van de eerste fase is de oprichting van SA (Security Association).
Vervolgens moeten we een lijst met bron- en bestemmings-IP-adressen (ACL) voor codering definiëren, een transformatieset genereren, een cryptografische kaart (cryptokaart) maken en deze aan de externe interface van de CS binden.
ACL instellen:
#ip-toegangslijst uitgebreide site1
#vergunning gre host 10.111.21.3 host 10.111.22.3
Een reeks transformaties (hetzelfde als voor de eerste fase, we gebruiken het coderingsalgoritme “Grasshopper” met behulp van de simulatie-invoeggeneratiemodus):
#crypto ipsec-transformatieset GOST esp-gost341215k-mac
We maken een cryptokaart, specificeren de ACL, de transformatieset en het peer-adres:
#cryptokaart MAIN 100 ipsec-isakmp
#match adres site1
#set transformatieset GOST
#set-peer 10.111.22.3
We binden de cryptokaart aan de externe interface van de kassa:
#interface GigabitEthernet0/0
#ip-adres 10.111.21.3 255.255.255.0
#cryptokaart HOOFD
Om kanalen met andere sites te versleutelen, moet u de procedure voor het aanmaken van een ACL- en cryptokaart herhalen, waarbij u de ACL-naam, IP-adressen en cryptokaartnummer wijzigt.
Let op! Als er geen gebruik wordt gemaakt van certificaatverificatie via CRL, moet dit expliciet worden aangegeven:
#crypto pki trustpoint s-terra_technological_trustpoint
#herroepingscheck geen
Op dit punt kan de installatie als voltooid worden beschouwd. In Cisco-achtige console-opdrachtuitvoer toon crypto isakmp sa и toon crypto ipsec sa De geconstrueerde eerste en tweede fase van IPSec moeten worden weerspiegeld. Dezelfde informatie kan worden verkregen met behulp van de opdracht sa_mgr tonen, uitgevoerd vanuit debian-shell. In de opdrachtuitvoer cert_mgr tonen De certificaten van de externe site zouden moeten verschijnen. De status van dergelijke certificaten zal zijn vanop. Als er geen tunnels worden gebouwd, moet u het VPN-servicelogboek bekijken, dat in het bestand is opgeslagen /var/log/cspvpngate.log. Een volledige lijst met logbestanden met een beschrijving van hun inhoud is beschikbaar in de documentatie.
Het monitoren van de “gezondheid” van het systeem
De S-Terra CC gebruikt de standaard snmpd-daemon voor monitoring. Naast de typische Linux-parameters ondersteunt S-Terra out-of-the-box het uitgeven van gegevens over IPSec-tunnels in overeenstemming met de CISCO-IPSEC-FLOW-MONITOR-MIB, die we gebruiken bij het monitoren van de status van IPSec-tunnels. De functionaliteit van aangepaste OID's die de resultaten van scriptuitvoering als waarden uitvoeren, wordt ook ondersteund. Met deze functie kunnen we de vervaldatums van certificaten volgen. Het geschreven script parseert de opdrachtuitvoer cert_mgr tonen en geeft als resultaat het aantal dagen totdat de lokale en rootcertificaten verlopen. Deze techniek is onmisbaar bij het toedienen van een groot aantal CABG’s.
Wat is het voordeel van een dergelijke encryptie?
Alle hierboven beschreven functionaliteit wordt standaard ondersteund door de S-Terra KSh. Dat wil zeggen dat het niet nodig was om extra modules te installeren die van invloed zouden kunnen zijn op de certificering van cryptogateways en de certificering van het gehele informatiesysteem. Er kunnen kanalen tussen sites zijn, zelfs via internet.
Vanwege het feit dat wanneer de interne infrastructuur verandert, het niet nodig is om cryptogateways opnieuw te configureren, het systeem werkt als een service, wat erg handig is voor de klant: hij kan zijn diensten (client en server) op elk adres plaatsen en alle wijzigingen worden dynamisch overgedragen tussen encryptieapparatuur.
Natuurlijk heeft encryptie als gevolg van overheadkosten (overhead) invloed op de gegevensoverdrachtsnelheid, maar slechts in geringe mate: de kanaaldoorvoer kan met maximaal 5-10% afnemen. Tegelijkertijd is de technologie getest en heeft goede resultaten opgeleverd, zelfs op satellietkanalen, die behoorlijk onstabiel zijn en een lage bandbreedte hebben.
Igor Vinokhodov, ingenieur van de 2e bestuurslijn van Rostelecom-Solar
Bron: www.habr.com