Connection protection.

To establish a secure connection, both session participants must be able to quickly agree on security parameters such as authentication algorithms and keys. The IPsec protocol supports two types of key management schemes through which participants can negotiate session parameters.
With the current version of IP, IPv4, either the Internet Secure Association Key Management Protocol (ISAKMP) or Simple Key Management for Internet Protocol can be used.
The AH header.
The optional header (AH) is a common authentication header and is most often located between the main header of the IP packet and the data field. The presence of this header does not affect the transmission of information at transport and higher levels. The main and only purpose of AH is to provide protection against attacks related to unauthorized modification of the packet contents, including from substitution of the source address of the network layer. Higher-level protocols should be modified in order to verify the authenticity of the received data.
Let's look at the values of each of these fields.
Next Header (8 bits) is the type of protocol header following the AH header. Using this field, the receiving IP-sec module learns about the protected top-level protocol. The values of this field for different protocols can be found in RFC 1700.
Payload Len (8 bits) - this field defines the total size of the header in 32-bit words minus 2. Nevertheless, when using IPv6, the header length must be a multiple of 8 bytes.
Reserved (16 bits) – reserved. Filled with zeros.
Security Parameters Index (32 bits) - the index of security parameters. The value of this field, along with the recipient's IP address and the Security Protocol (AN-protocol), uniquely determines the secure virtual connection (SA) for this packet. The range of SPI values 1...255 is reserved by the IANA.
Sequence Number (32 bits) - sequential number. It is used to protect against retransmission. The field contains a monotonously increasing parameter value. Although the recipient may opt out of the packet retransmission protection service, it is mandatory and is always present in the AH header. The transmitting IPsec module always uses this field, but the recipient may not process it.
Integrity Check Value - a checksum. It must be a multiple of 8 bytes for IPv6 and 4 bytes for IPv4.
The AH protocol is used for authentication, that is, to confirm that we are contacting exactly who we expect to contact, and that the data we receive is not distorted during transmission.
The ESP header.
When using encrypted data encapsulation, the ESP header is the last in a series of optional headers "visible" in the packet. Since the main purpose of ESP is to ensure data confidentiality, different types of information may require significantly different encryption algorithms. For this reason, the ESP format can undergo significant changes depending on the cryptographic algorithms used. Nevertheless, the following mandatory fields can be distinguished: SPI, indicating the security context, and Sequence Number Field, containing the sequential package number. The "ESP Authentication Data" field (checksum) optional in the ESP header. The recipient of the ESP packet decrypts the ESP header and uses the parameters and data of the encryption algorithm used to decode the transport layer information.
Security Parameters Index (32 bits) – the index of security parameters. The value of this field, along with the recipient's IP address and the Security Protocol (AN-protocol), uniquely determines the secure virtual connection (SA) for this packet. The range of SPI values 1...255 is reserved by the IANA for future use.
Sequence Number (32 bits) - sequential number. It is used to protect against retransmission. The field contains a monotonously increasing parameter value. Despite the fact that the recipient may refuse the packet retransmission protection service, it is always present in the AH header. The sender (transmitting IPsec module) should always use this field, but the recipient may not need to process it.
Payload data (variable) – this field contains data according to the "Next Header" field. This field is mandatory and consists of an integer number of bytes. If the algorithm used to encrypt this field requires data to synchronize cryptographic processes (for example, the Initialization Vector), then this field may contain this data explicitly.
Padding (0-255 octets) is an extension. This is necessary, for example, for algorithms that require the plaintext to be a multiple of a certain number of bytes, such as the block size for a block cipher.
Pad Length (8 bits) - pad size (in bytes).
Next Header (8 bits) - This field defines the type of data contained in the "Payload data" field.
Integrity Check Value – a checksum. It must be a multiple of 8 bytes for IPv6 and 4 bytes for IPv4.
There are two modes of application of ESP and AH (as well as their combinations) - transport and tunnel.
Transport mode is used to encrypt the data field of an IP packet containing transport layer protocols (TCP, UDP, ICMP), which, in turn, contains information about application services. An example of the use of transport mode is the transmission of e-mail. All intermediate nodes on the packet route from sender to receiver use only open network layer information and possibly some optional packet headers (in IPv6). The disadvantage of the transport mode is the lack of mechanisms to hide the specific sender and recipient of the packet, as well as the ability to analyze traffic. The result of such an analysis may be information about the volume and directions of information transmission, the area of interest of subscribers, and the location of managers.
Tunnel mode, unlike transport mode, involves encrypting the entire packet, including the network layer header. Tunnel mode is used when it is necessary to hide the information exchange of an organization with the outside world. In this case, the address fields of the network layer header of a packet using tunnel mode are filled in by the organization's firewall and do not contain information about the specific sender of the packet. When transmitting information from the outside world to the organization's local network, the network address of the firewall is used as the destination address. After decryption by the firewall of the initial network layer header, the packet is sent to the recipient.
Security Associations.
A Security Association (SA) is a type of connection that provides services to ensure the security of the traffic transmitted through it. For example, when two computers on each side of the SA store the mode, protocol, algorithms, and keys used in the SA, then each SA is applied in only one direction. Bidirectional communication requires two SA's. Each SA implements one mode and protocol; thus, if two protocols need to be used for one packet (such as AH and ESP), then two SA are required.
Today, the IPsec protocol is supported by almost all modern network devices. Therefore, I will not give examples of configuring this protocol for the equipment of a particular developer. In previous posts, only theoretical information was provided to understand how the protocol works. If you need to configure IPsec on specific hardware models, you need to use the documentation provided by the hardware developer.
Having considered the theoretical foundations of functioning, let's move on to the practical setup. As an example, we will set up an IPsec policy prohibiting all data exchange over HTTP and HTTPS protocols, and we will use Windows 7. It is worth noting that if you use the Windows 2008 server operating system, they may differ, but only slightly.
So, open the MMC console (Windows – Run – mmc icon).
In the menu that opens, select the Console command, then Add or Remove a snap-in. In the dialog that opens, also click Add, select IP Security Policy Management from the list that opens.
In the computer selection dialog that appears, specify the Local Computer. We close the windows sequentially by clicking Done, Close, OK. Now, in the left panel of the console, we will have an IP Security Policy node for the ‘Local Computer’. Right-click on it and select the Manage IP Filter Lists command.
In the dialog that opens, click the Add button. Another window opens - a list of filters. In order to make it easier to navigate the filter lists in the future, we will set a name for the new filter by typing
in the Name field, for example, TRAFFIC_NTTR_NTTRS. Click the Add button to start creating the filter itself.
On the second page, you can specify a description of the filter. So that you don't get confused: one filter can consist of many others. As we indicated in the previous step in the description of TRAFFIC_TTTTTPS, now we will create two filters sequentially: one for HTTP, the other for HTTPS. The resulting filter will combine these two filters. So, we specify HTTP in the description field. We leave the Reflected flag on - this will allow us to extend the filter rules both in one direction of packet forwarding and in the opposite direction with the same parameters. Click Next.
Now you need to specify the source address of the IP packets. As you can see in the picture, the choice of address is quite wide. Now we will specify My IP address and click Next. In the next window, we set the destination address. Select any IP address and click Next. Now you should specify the protocol type. Select TCP from the list. Go ahead and set the port numbers.
We leave the upper switch in the Packets from any port position, and turn on the Packets to this port mode with the lower switch and enter the HTTP port value 80 in the field. Click Done, close the wizard. Now click the Add button again and do all the previous operations again, but already specifying the port value 443 (for HTTPS). The list of the lower window should contain both created packet filtering rules.
Click OK. Our filter is ready, but now it is necessary to determine the actions that it will perform. Switch to the Manage Filter actions tab and click Add. The wizard dialog opens again, click Next. We specify a name, for example Block, and move on. As an action, select the Block switch, click Next and that's it. The filter has been created, the action for it has been defined, all we have to do is create a policy and assign it. In the MMC console window, right-click the IP Security Policy node and select Create IP Security Policy. In the wizard window that opens, click Next, then specify a name for the policy, for example, POLICY_TT_TTTPS, click Next. Uncheck the Use Default rule checkbox, click Next, and you're done. In the policy properties window, click Add.
Click Next, leave the switch in the position This rule does not define a tunnel, and move on. Network type - specify All network connections, click Next. Now you need to select a filter from the list.
Select the TRAFFIC_NTTR_NTTRS filter we created (a dot in a circle should appear on the left), click Next. In the same way, select the action for the filter - POLICY_TT_TTTPS, click Next and you're done. Now, in the right panel of the MMC console, a created policy will appear with the name POLICY_NTTR_NTTRS.
All that's left to do is appoint her. To do this, right-click on the name and select the Assign command. To check, it remains to launch the browser. If everything was done correctly, the picture should be like this.
As a result of the actions performed earlier, we have banned the use of web traffic. Now let's add a filter that will allow connections to some Internet nodes. For example, we will allow the browser to view
node www.microsoft.com . To do this, in our MMC console, double-click the policy name policy_nttrs_nttrs. In the properties window, click the Add button, then double-click the TRAFFIC_NTTR_NTTRS filter. On the Filter List tab, click Add. We specify a name for the new filter, for example www.microsoft.com , click Add, Next, leave My IP address as the packet source, click Next. Select a Specific DNS name as the destination address, and enter in the Host Name field www.microsoft.com . Click Next.
A warning will appear stating that instead of the DNS name in the filter www.microsoft.com the IP address 207.46.197.32 will be used. We agree by clicking Yes, then specify the protocol type - TCP, select the switch To this port and specify its number - 80. Click Next, Done, and OK. Now we define the filter action - go to the tab of the same name and select the Allow option.
Currently, the filter consists of two filters: one prohibits all http traffic, the other allows connections to a specific IP address.
This example also shows one of the significant differences between using a "normal" firewall and IPsec filtering: using IPsec does not allow you to set the order or priority of the filter. However, it will still work. It remains to close all the dialog boxes and check it.
Now when switching to www.microsoft.com (and only him!) the browser should display the contents of this node. Please note that resources located on another host (for example, banner ads) are not displayed, as they are also filtered by the IPsec policy applied.
Similarly, you can create your own necessary filters and apply them.
Oleg Petukhov, lawyer in the field of international law and personal data protection, information security specialist security, protection of information and personal data.
Telegram channel: https://t.me/protectioninformation Telegram Group: https://t.me/informationprotection1 Website: https://legascom.ru Email: online@legascom.ru #informationprotection #informationsecurity