If your company transmits or receives over the network personal data and other confidential information that is subject to protection in accordance with the law, it is required to use encryption in accordance with GOST. Today we will tell you how we introduced such encryption based on the S-Terra crypto-gateway (KS) at one of the customers. This story will be interesting to information security professionals, as well as engineers, designers and architects. We will not dive deeply into the nuances of the technical configuration in this post - we will dwell on the key points of the basic setup. A huge amount of documentation on configuring the Linux OS daemons, on which the S-Terra KS is based, is freely available on the Internet. S-Terra proprietary software configuration documentation is also publicly available on the manufacturer’s portal .
A few words about the project
The customer’s network topology was typical - full mesh between the center and branches. It was required to introduce encryption of information exchange channels between all sites, of which there were 8 pieces.
Usually, in such projects everything is static: on crypto-gateways (KS), static routes are set to the local area network of the site, lists of IP addresses (ACLs) for encryption are written. However, in this case, the sites do not have centralized management, and anything can happen inside their local networks: networks can be added, deleted and modified in every way. In order to avoid reconfiguring routing and ACLs to the KS when changing the addressing of local networks on the sites, it was decided to use GRE tunneling and dynamic routing OSPF, which includes all KS and most routers of the network core level on the sites (at some sites, infrastructure administrators preferred use SNAT in the direction of KS on kernel routers).
GRE tunneling solved two problems:
1. Use in the ACL for encryption the IP address of the external KS interface, in which all traffic directed to other sites is encapsulated.
2. Organize ptp tunnels between the KS, which allow you to configure dynamic routing (in our case, the provider MPLS L3VPN is organized between the sites).
The client ordered the implementation of encryption as a service. Otherwise, he would have to not only support crypto-gateways or outsource some organization, but also independently monitor the life cycle of encryption certificates, renew them in time and install new ones.
And now the memo itself - how and what did we set up
KII subject note: we configure a crypto-gateway
Basic network setup
First of all, we launch a new cache and get into the administration console. Start by changing the password for the built-in administrator - the change user password administrator command. Then it is necessary to carry out the initialization procedure (the initialize command) in the process of which the license data is entered and the random number sensor (DSN) is initialized.
Note! When S-Terra KS is initialized, a security policy is established in which the Security Gateway interfaces do not pass packets. You must either create your own policy, or use the run csconf_mgr activate command to activate a predefined permission policy.
Next, you need to configure the addressing of the external and internal interfaces, as well as the default route. It is preferable to work with the network configuration of the cache and configure encryption through the Cisco-like console. This console is for entering commands similar to Cisco IOS commands. The configuration created using the Cisco-like console, in turn, is converted into the corresponding configuration files that the OS daemons work with. You can go to the Cisco-like console from the administration console with the configure command.
Change the passwords for the built-in user cscons and enable:
> enable
Password: csp (predefined)
#configure terminal
#username cscons privilege 15 secret 0 #enable secret 0 Set up the basic network configuration:
#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 exit the Cisco-like console and go to the debian shell with the system command. Set your own password for the root user with the passwd command.
A separate tunnel for each site is configured on each KSh. The tunnel interface is configured in the / etc / network / interfaces file. The IP tunnel utility, which is part of the predefined set of iproute2, is responsible for creating the interface itself. The command to create an interface is written into the pre-up option.
Example configuration of a typical tunnel interface:
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
Note! It should be noted that the tunnel interface settings must be located outside the section
### netifcfg-begin ###
*****
### netifcfg-end ###
Otherwise, these settings will be erased when changing the network settings of physical interfaces through the Cisco-like console.
Dynamic routing
In S-Terra, dynamic routing is implemented using the Quagga software package. To configure OSPF, we need to enable and configure the zebra and ospfd daemons . The zebra daemon is responsible for the interaction between routing daemons and the OS. The ospfd daemon, as the name implies, is responsible for implementing the OSPF protocol.
OSPF is configured either through the daemon console or directly through the /etc/quagga/ospfd.conf configuration file. All physical and tunnel interfaces involved in dynamic routing are added to the file, and networks are announced that will be announced and receive announcements.
An example configuration to add to 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 this case, the addresses 192.168.1.x / 31 are reserved for ptp tunnel networks between sites, the addresses 192.168.2.x / 30 are allocated for transit networks between the KS and the kernel routers.
Note! To reduce the routing table in large installations, you can filter the announcement of the transit networks themselves using the no redistribute connected or redistribute connected route-map constructs.
After setting up the daemons, you need to change the daemon launch status in / etc / quagga / daemons . In the options zebra and ospfd no fix to yes. Run the quagga daemon and set its autorun when starting the cache with the update-rc.d quagga enable command.
If the GRE tunnels and OSPF are configured correctly, then routes to the network of other sites should appear on the KS and kernel routers, and thus network connectivity between local networks arises.
We encrypt the transmitted traffic
As already mentioned, when encrypting between sites, we usually specify the IP address ranges (ACLs) between which traffic is encrypted: if the source and destination addresses fall into these ranges, then the traffic between them is encrypted. However, in this project, the structure is dynamic and the addresses can change. Since we have already configured GRE tunneling, we can specify external KS addresses as the source and destination addresses for traffic encryption - because for encryption comes traffic already encapsulated by the GRE protocol. In other words, everything that enters the cache from the local area network of one site to the networks that were announced by other sites is encrypted. And already within each of the sites any forwarding can be performed. Thus, with any change in local networks, it is enough for the administrator to modify the announcements going from his network to the direction of the secondary school, and it will become available for other sites.
Encryption in the S-Terra KS is performed using the IPSec protocol. We use the Grasshopper algorithm in accordance with GOST R 34.12-2015, and for compatibility with older versions, GOST 28147-89 can be used. Authentication can technically be performed on both predefined keys (PSKs) and certificates. Nevertheless, in industrial operation it is necessary to use certificates issued in accordance with GOST R 34.10-2012.
Work with certificates, containers and CRLs is performed using the cert_mgr utility. First of all, using the cert_mgr create command, you need to create a private key container and a certificate request, which will be sent to the Certificate Management Center. After receiving the certificate, it must be imported with the cert_mgr import command along with the root certificate of the CA and CRL (if used). You can verify that all certificates and CRLs are installed with the cert_mgr show command.
After successfully installing the certificates, go to the Cisco-like console to configure IPSec.
We create an IKE policy, which indicates the desired algorithms and parameters of the created secure channel, which will be offered to the partner for approval.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#authentication sign
#group vko2
#lifetime 3600
This policy applies when building the first phase of IPSec. The successful completion of the first phase is the establishment of SA (Security Association).
Next, we need to define a list of source and destination IP addresses (ACLs) for encryption, form a transform set, create a cryptographic map (crypto map) and bind it to the external interface of the CAB.
Set the ACL:
#ip access-list extended site1
#permit gre host 10.111.21.3 host 10.111.22.3
A set of transformations (as well as for the first phase, we use the Grasshopper encryption algorithm using the simulation mode):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Create a crypto map, specify ACL, transform set and peer address:
#crypto map MAIN 100 ipsec-isakmp
#match address site1
#set transform-set GOST
#set peer 10.111.22.3
We attach the crypto map to the external interface of the CABG:
#interface GigabitEthernet0 / 0
#ip address 10.111.21.3 255.255.255.0
#crypto map MAIN
To encrypt channels with other sites, you must repeat the procedure for creating ACLs and crypto cards, changing the name of the ACL, IP addresses and crypto card number.
Note! In the event that certificate verification by CRL is not used, this must be explicitly specified:
#crypto pki trustpoint s-terra_technological_trustpoint
# revocation-check none
On this setting can be considered complete. The output of the Cisco-like console commands show crypto isakmp sa and show crypto ipsec sa should reflect the constructed first and second phases of IPSec. The same information can be obtained using the sa_mgr show command executed from debian shell. The output of the cert_mgr show command should display remote site certificates. The status of such certificates will be remote . In case tunnels are not built, you need to look into the VPN service log, which is stored in the /var/log/cspvpngate.log file. A full list of log files with a description of their contents is available in the documentation.
Monitor the "health" of the system
S-Terra KS uses the standard snmpd daemon for monitoring. In addition to the typical Linux parameters, S-Terra out of the box supports the output of IPSec tunnels according to CISCO-IPSEC-FLOW-MONITOR-MIB, which we use to monitor the status of IPSec tunnels. The functionality of custom OIDs is also supported, giving the results of the script as values. This feature allows us to track the expiration dates of certificates. The written script parses the output of the cert_mgr show command and as a result gives the number of days before the expiration of the local and root certificates. This technique is indispensable when administering a large number of CABGs.
What is the cimus of such encryption
All the functionality described above is supported "out of the box" KS S-Terra. That is, it was not necessary to install any additional modules that could affect the certification of crypto-gateways and the certification of the entire information system. Channels between sites can be any, even via the Internet.
Due to the fact that when changing the internal infrastructure it is not necessary to reconfigure crypto-gateways, the system works as a service , which is very convenient for the customer: he can place his services (client and server) at any addresses, and all changes are dynamically transferred between the encryption equipment.
Of course, encryption due to overhead affects the data transfer rate, but not significantly - the bandwidth of the channel can decrease by a maximum of 5-10%. At the same time, the technology was tested and showed good results even on satellite channels, which are rather unstable and have low bandwidth.
Igor Vinokhodov, engineer of the 2nd line of administration of Rostelecom Solar