If your company transmits or receives personal data and other confidential information that is subject to protection under the law, encryption according to GOST standards is required. Today, we will discuss how we implemented such encryption based on the S-Terra crypto gateway for one of our clients. This story will be of interest to information security specialists, as well as engineers, designers, and architects. We will not delve deeply into the nuances of the technical configuration in this post — we will focus on the key points of the basic setup. There is a vast amount of documentation available online for configuring Linux OS daemons, which underpin the S-Terra crypto gateway. Documentation for setting up the proprietary software S-Terra is also publicly accessible. of the manufacturer.
A few words about the project
The client’s network topology was typical — a full mesh between the headquarters and the branches. It was necessary to implement encryption for information exchange channels among all the sites, of which there were 8.
Typically, in such projects, everything is static: static routes to the local network of the site are set on the crypto gateways, and IP address lists (ACL) for encryption are defined. However, in this case, the sites do not have centralized management, and within their local networks, anything can happen: networks can be added, removed, and modified in various ways. To avoid reconfiguring the routing and ACL on the crypto gateways when the addressing of local networks at the sites changes, a decision was made to use GRE tunneling and dynamic routing with OSPF, which includes all crypto gateways and most core network routers at the sites (on some sites, infrastructure administrators preferred to use SNAT towards the crypto gateways on the core routers).
GRE tunneling allowed us to solve two tasks:
1. To use the external interface IP address of the crypto gateway in the ACL for encryption, which encapsulates all traffic directed to other sites.
2. To establish point-to-point tunnels between the crypto gateways, allowing for dynamic routing configuration (in our case, a provider MPLS L3VPN was set up between the sites).
The client requested the implementation of encryption as a service. Otherwise, they would not only have to maintain cryptogates or outsource to an organization but also independently track the lifecycle of encryption certificates, renew them in a timely manner, and install new ones.
Now, here’s a memo on how and what we configured.
Note to CIIs: Configuring the cryptogate.
Basic network setup.
First, we start the new CG and enter the administration console. We should begin by changing the password of the built-in administrator — the command is change user password administrator. Then, we need to carry out the initialization procedure (command initialize) during which the license information is entered and the random number generator (RNG) is initialized.
Note! During the initialization of the CG S-Terra, a security policy is established, in which the security gateway interfaces do not allow packets through. It is necessary to either create your own policy or activate the pre-installed allowing policy using the command run csconf_mgr activate .
Next, we 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 CG and the encryption setup via a Cisco-like console. This console is designed for entering commands similar to those of Cisco IOS. The configuration formed using the Cisco-like console is converted into the appropriate configuration files used by the OS demons. You can switch to the Cisco-like console from the administration console using the command configure.
We change the passwords for the built-in user cscons and enable:
>enable
Password: csp (default)
#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 exit the Cisco-like console and switch to the Debian shell with the command system. Set your own password for the user. root with the command passwd.
A separate tunnel is configured for each site on each CG. The tunnel interface is configured in the file /etc/network/interfaces. The utility IP tunnel, which is part of the pre-installed iproute2 set, is responsible for creating the interface. The command for creating the interface is specified in 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 tunnel interface settings must be placed outside the section
###netifcfg-begin###
*****
###netifcfg-end###
Otherwise, these settings will be overwritten when changing the network settings of physical interfaces through a 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 demons zebra and ospfd. The zebra daemon is responsible for the interaction between the routing daemons and the operating system. The ospfd daemon, as the name suggests, is responsible for implementing the OSPF protocol.
OSPF configuration is performed either through the daemon console or directly through the configuration file /etc/quagga/ospfd.conf. The file includes all physical and tunnel interfaces participating in dynamic routing, as well as the networks that will be advertised and that will receive advertisements.
An example configuration to be added 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, addresses 192.168.1.x/31 are allocated for point-to-point tunnel networks between sites, while addresses 192.168.2.x/30 are for transit networks between the control server and core routers.
Note! To reduce the routing table in large installations, it is possible to filter the advertisement of the transit networks using the constructs no redistribute connected or redistribute connected route-map.
After configuring the demons, it is necessary to change the startup status of the demons in /etc/quagga/daemons. In the options, change zebra and ospfd no to yes. Start the quagga daemon and set it to autostart when the control server boots with the command update-rc.d quagga enable.
If the GRE tunnel and OSPF configuration is done correctly, routes to the networks of other sites should appear on the control server and core routers, thus establishing network connectivity between local networks.
Encrypt the transmitted traffic.
As already mentioned, when encrypting between sites, we typically specify the ranges of IP addresses (ACL) through which traffic is encrypted: if the source and destination addresses fall within these ranges, traffic between them is encrypted. However, in this project, the structure is dynamic and addresses can change. Since we have already configured GRE tunneling, we can specify the external addresses of the KS as the source and destination addresses for traffic encryption—because the traffic coming in is already encapsulated by the GRE protocol. In other words, everything that goes into the KS from the local network of one site towards the networks announced by other sites is encrypted. Inside each site, any forwarding can take place. Thus, if there are changes in the local networks, the administrator simply needs to modify the announcements going from their network towards the KS, and it will become available to other sites.
Encryption in the KS S-Terra is performed using the IPSec protocol. We use the "Grasshopper" algorithm according to GOST R 34.12-2015, and for compatibility with older versions, GOST 28147-89 can be applied. Authentication can technically be performed using either pre-defined keys (PSK) or certificates. However, in industry practice, it is necessary to use certificates issued according to GOST R 34.10-2012.
Working with certificates, containers, and CRL is done using the utility cert_mgr. First, using the command cert_mgr create , it is necessary to create a private key container and a certificate request that will be sent to the Certificate Management Center. After obtaining the certificate, it, along with the root CA certificate and CRL (if used), needs to be imported using the command cert_mgr import. You can verify that all certificates and CRLs have been installed using the command cert_mgr show.
. After successfully installing the certificates, we proceed to the Cisco-like console to configure IPSec.
We create an IKE policy that specifies the desired algorithms and parameters for the protected channel being created, which will be proposed to the partner for negotiation.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#authentication sign
#group vko2
#lifetime 3600
This policy applies during the establishment of the first phase of IPSec. The result of successfully completing the first phase is the establishment of an SA (Security Association).
Next, we need to identify the list of source and destination IP addresses (ACL) for encryption, form a set of transformations (transform set), create a cryptographic map (crypto map), and bind it to the external interface of the KSH.
Set the ACL:
#ip access-list extended site1
#permit gre host 10.111.21.3 host 10.111.22.3
Set of transformations (similarly to the first phase, we will use the 'Grasshopper' encryption algorithm in the message authentication code mode):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Create the crypto map, specifying the 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
Bind the crypto map to the external interface of the KSH:
#interface GigabitEthernet0/0
#ip address 10.111.21.3 255.255.255.0
#crypto map MAIN
To encrypt channels with other sites, it is necessary to repeat the process of creating the ACL and the crypto map, changing the ACL name, IP addresses, and crypto map number.
Note! If certificate verification via CRL is not used, this must be specified explicitly:
#crypto pki trustpoint s-terra_technological_trustpoint
#revocation-check none
At this point, the configuration can be considered complete. In the output of the Cisco-like console commands show crypto isakmp sa and show crypto ipsec sa the first and second phases of IPSec should be reflected. This same information can be obtained with the command sa_mgr show, executed from the debian shell. The output of the command cert_mgr show should display certificates of remote sites. The status of such certificates will be remote. In case the tunnels are not being constructed, it is necessary to check the log VPN-service, which is stored in the file /var/log/cspvpngate.log. A complete list of log files with descriptions of their contents is available in the documentation.
Monitor the 'health' of the system
In the KSH S-Terra, the standard daemon snmpd is used for monitoring. In addition to typical Linux parameters, S-Terra 'out of the box' supports outputting data about IPSec tunnels according to CISCO-IPSEC-FLOW-MONITOR-MIB, which we utilize to track the status of IPSec tunnels. It also supports the functionality of custom OIDs that return execution results of scripts as values. This capability allows us to monitor certificate expiration dates. The written script parses the output of the command cert_mgr show and ultimately displays the number of days until the expiration of local and root certificates. This approach is invaluable when administering a large number of KSHs.
What is the essence of such encryption?
All the functionality described above is supported out of the box by the S-Terra KSH. This means there is no need to install any additional modules that might affect the certification of crypto gateways and the accreditation of the entire information system. The channels between sites can be any, even through the internet.
Thanks to the fact that when altering the internal infrastructure, there is no need to reconfigure the crypto gateways, the system operates as a service, which is very convenient for the client: they can host their services (client and server) at any addresses, and all changes will be dynamically transmitted between the encryption equipment.
Certainly, encryption due to overhead affects data transfer speeds, but minimally—the channel capacity may decrease by a maximum of 5-10%. Moreover, the technology has been tested and has shown good results even on satellite channels, which are quite unstable and have low capacity.
Igor Vinokhodov, 2nd Line Administration Engineer at Rostelecom-Solar
Source: habr.com
