If your company transmits or receives personal data and other confidential information over the network that is subject to protection in accordance with the law, it is required to use GOST encryption. Today we will tell you how we implemented such encryption based on the S-Terra crypto-gateway (CS) at one of the customers. This story will be of interest to information security specialists, as well as engineers, designers and architects. We will not dive deep into the nuances of the technical configuration in this post - we will dwell on the key points of the basic setup. Huge volumes of documentation on setting up Linux daemons, on which S-Terra is based, are freely available on the Internet. Documentation for configuring the proprietary S-Terra software is also publicly available at manufacturer.
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: static routes to the local area network of the site are set on crypto gateways (KSH), lists of IP addresses (ACLs) for encryption are prescribed. However, in this case, the sites do not have centralized control, and anything can happen inside their local networks: networks can be added, removed, and modified in every possible way. In order to avoid reconfiguring routing and ACLs on KS when changing local network addressing at sites, it was decided to use GRE tunneling and OSPF dynamic routing, which includes all KSs and most network core routers at sites (in some sites, infrastructure administrators preferred use SNAT towards KSh on core routers).
GRE tunneling solved two problems:
1. Use in the ACL for encryption the IP address of the external interface of the KSh, in which all traffic directed to other sites is encapsulated.
2. Organize ptp tunnels between KS, which allow you to configure dynamic routing (in our case, a provider MPLS L3VPN is organized between sites).
The client ordered the implementation of encryption as a service. Otherwise, he would not only have to maintain crypto-gateways or outsource them to some organization, but also independently monitor the life cycle of encryption certificates, renew them in time and install new ones.
And now the actual memo - how and what we set up
Note to the CII subject: setting up a crypto-gateway
Basic network setup
First of all, we launch a new KSh and get into the administration console. You should start by changing the password of the built-in administrator - the command change user password administrator. Then it is necessary to carry out the initialization procedure (command initialize) during which the license data is entered and the random number generator (RNG) is initialized.
Pay attention! When initializing the S-Terra KSh, a security policy is set in which the interfaces of the Security Gateway do not pass packets. You must either create your own policy or use the command run csconf_mgr activate activate the pre-installed permissive policy.
Next, you need to configure the addressing of external and internal interfaces, as well as the default route. It is preferable to work with the KSh network configuration and encryption settings through a Cisco-like console. This console is for entering commands similar to Cisco IOS commands. The configuration generated using the Cisco-like console is, in turn, converted into the appropriate configuration files that the OS daemons work with. You can go to the Cisco-like console from the administration console with the command configure.
Change passwords for the built-in user cscons and enable:
>enable
Password: csp(preset)
#configureterminal
#username cscons privilege 15 secret 0 #enable secret 0 Set up 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 command system. Set your own password for the user root the team Passwd.
On each KSh, a separate tunnel is configured for each site. The tunnel interface is configured in the file / etc / network / interfaces. The IP tunnel utility, included in the iproute2 preinstalled set, is responsible for creating the interface itself. The interface creation command is written in the pre-up option.
Typical tunnel interface configuration example:
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
Pay attention! It should be noted that the settings of tunnel interfaces must be located outside the section
###netifcfg-begin###
*****
###netifcfg-end###
Otherwise, these settings will be overwritten 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 daemons zebra ΠΈ ospfd. The zebra daemon is responsible for the interaction between the 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 configuration file /etc/quagga/ospfd.conf. All physical and tunnel interfaces participating in dynamic routing are added to the file, and networks are declared that will be advertised and receive announcements.
An example of the configuration to be added to ospfd.conf:
interface eth0
!
interface eth1
!
interface site1
!
interface site2
ospf router
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 reserved for tunnel ptp networks between sites, addresses 192.168.2.x/30 are reserved for transit networks between KSh and core routers.
Pay attention! To reduce the routing table in large installations, you can filter the announcement of the transit networks themselves using the constructs no redistribute connected or redistribute connected route-map.
After configuring the daemons, you need to change the startup status of the daemons to /etc/quagga/daemons. In Options zebra ΠΈ ospfd no change to yes. Start the quagga daemon and set it to autostart when KSh starts with the command update-rc.d quagga-enable.
If the GRE tunnels and OSPF are configured correctly, then routes in the network of other sites should appear on the KSh and core routers and, thus, network connectivity between local networks arises.
We encrypt transmitted traffic
As already mentioned, when encrypting between sites, we usually specify ranges of IP addresses (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 addresses can change. Since we have already configured GRE tunneling, we can specify external KSh addresses as source and destination addresses for traffic encryption - after all, traffic already encapsulated by the GRE protocol comes for encryption. In other words, everything that enters the KSh from the local network of one site is encrypted in the direction of networks that were announced by other sites. And already inside each of the sites any redirection can be performed. Thus, in case of any change in local networks, it is enough for the administrator to modify the announcements coming from his network towards the KSh, and it will become available to other sites.
Encryption in the S-Terra KSh 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 pre-shared keys (PSK) 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 utility cert_mgr. First of all, with the command cert_mgr create it is necessary to generate a private key container and a certificate request, which will be sent to the Certificate Management Center. After receiving the certificate, it, along with the CA root certificate and CRL (if used), must be imported with the command cert_mgr import. You can make sure that all certificates and CRLs are installed with the command cert_mgr show.
After successfully installing the certificates, go to the Cisco-like console to configure IPSec.
We create an IKE policy that specifies the desired algorithms and parameters of the created secure channel, which will be offered to the partner for negotiation.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#authentication sign
#group vko2
#lifetime 3600
This policy is applied when building the first phase of IPSec. The result of 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 (ACL) for encryption, form a transform set, create a cryptographic map (crypto map) and bind it to the external interface of the KSh.
Set 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 insertion generation 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 bind the cryptomap 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, you must repeat the procedure for creating an ACL and a crypto map, changing the ACL name, IP addresses, and crypto map number.
Pay attention! 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. In the output of Cisco-like console commands show crypto isakmp sa ΠΈ show crypto ipsec sa the constructed first and second phases of IPSec should be reflected. The same information can be obtained using the command sa_mgr showexecuted from debian shell. In the command output cert_mgr show the remote site certificates should appear. The status of such certificates will be remote. In the event that the tunnels are not built, you need to look into the VPN service log, which is stored in the file /var/log/cspvpngate.log. A complete list of log files with a description of their content is available in the documentation.
We monitor the "health" of the system
The S-Terra KSh uses the standard snmpd daemon for monitoring. In addition to typical Linux parameters, S-Terra out of the box supports issuing data on IPSec tunnels according to CISCO-IPSEC-FLOW-MONITOR-MIB, which we use to monitor the status of IPSec tunnels. It also supports the functionality of custom OIDs that return the results of script execution as values. This feature allows us to keep track of certificate expiration dates. Written script parses command output cert_mgr show and returns the number of days until the local and root certificates expire. This technique is indispensable when administering a large number of KSh.
What is the cimus of such encryption
All the functionality described above is supported out of the box by KSh 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 through 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 address, and all changes will be dynamically transferred between the encryption equipment.
Of course, encryption at the expense of overhead costs (overhead) affects the data transfer rate, but only slightly - the channel throughput can be reduced by a maximum of 5-10%. At the same time, the technology has been 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
Source: habr.com