The protocol operates at the network layer of the OSI model and, accordingly, it is "transparent" to applications. In other words, applications (such as web server, browser , DBMS, etc.) does not affect whether the transmitted data is protected by IPSec or not.
Operating systems of the Windows 2000 family and higher have built-in support for the IPSec protocol. From the point of view of the layered security model, this protocol is a means of securing the network layer.
Rice. 5.9.
The IPSec architecture is open, which, in particular, allows the use of new cryptographic algorithms and protocols to protect transmitted data, for example, those corresponding to national standards. This requires that the communicating parties support these algorithms, and they would be standardly registered in the description of the connection parameters.
The process of secure data transfer is governed by the security rules adopted in the system. The parameters of the tunnel being created are described by an information structure called a security context or security association (from the English Security association, abbr. SA). As noted above, IPSec is a set of protocols, and SA composition may vary depending on the specific protocol. SA includes:
- recipient's IP address;
- an indication of the security protocols used in data transfer;
- the keys needed to encrypt and generate an imitation insert (if required);
- an indication of the formatting method that determines how the headers are created;
- security parameters index (from English Security Parameter Index, abbr. SPI) - an identifier that allows you to find the desired SA.
Usually, the security context is unidirectional, and two SAs are used to transfer data through the tunnel in both directions. Each host has its own SA base, from which the desired element is selected either based on SPI or by the recipient's IP address.
The two protocols that make up IPSec are:
- authentication header protocol- AH (from the English. Authentication Header), which provides integrity checks and authentication of transmitted data; the latest version of the protocol is described in RFC 4302 (previous - RFC 1826, 2402);
- Encapsulating Data Protection Protocol (ESP) Encapsulating Security Payload) - provides confidentiality and, optionally, can provide integrity checking and authentication, described in RFC 4303 (previous - RFC 1827, 2406).
Both of these protocols have two modes of operation - transport and tunnel, the latter is defined as the main one. tunnel mode used if at least one of the connecting nodes is a Security Gateway. In this case, a new IP header is created, and the original IP packet is completely encapsulated in a new one.
Transport mode host-to-host connection oriented. When using ESP in transport mode, only the data of the IP packet is protected, the header is not affected. When using AH, protection extends to the data and part of the header fields. The modes of operation are described in more detail below.
AH Protocol
In IP ver .4, the authentication header is placed after the IP header. Imagine the original IP packet as a combination of the IP header, the next level protocol header (usually TCP or UDP, in Figure 5.10 it is designated as ULP - from the English Upper-Level Protocol) and data.
Rice. 5.10.
Consider the ESP header format (Figure 5.13). It starts with two 32-bit values - SPI And SN. Their role is the same as in the AH protocol - SPI identifies the SA used to create this tunnel; SN- allows you to protect yourself from packet repetition. SN And SPI are not encrypted.
The next field contains the encrypted data. After them - a placeholder field, which is needed in order to align the length of the encrypted fields to a value that is a multiple of the size of the encryption algorithm block.
Rice. 5.12.
Rice. 5.13.
The placeholder is followed by fields containing the length of the placeholder and an indication of the higher level protocol. The four listed fields (data, placeholder, length, next protocol) are encrypted.
If ESP is also used for data authentication, then the packet ends with a variable length field containing the ICV. Unlike AH, in ESP, when calculating the insertion value, the fields of the IP header (new - for tunnel mode, modified old - for transport) are not taken into account.
When AH and ESP protocols are used together, after the IP header comes AH, after it - ESP. In this case, ESP solves the problems of ensuring confidentiality, AH - ensuring the integrity and authentication of the connection source.
Let's consider a number of additional issues related to the use of IPSec. Let's start with where the information about the connection parameters comes from - SA. The creation of the SA base can be done in various ways. In particular, it can be created security administrator manually, or formed using special protocols - SKIP, ISAKMP (Internet Security Association and Key Management Protocol) and IKE (Internet Key Exchange).
IPSec and NAT
When connecting networks of organizations to the Internet, the mechanism of network address translation - NAT (Network Address Translation) is often used. This allows you to reduce the number of registered IP addresses used on a given network. Inside the network, unregistered addresses are used (as a rule, from ranges specially allocated for this purpose, for example, addresses like 192.168.x.x for class C networks). If a packet from such a network is sent to the Internet, then the router, whose external interface is assigned at least one registered ip address, modifies the ip headers network packets, substituting the registered address for private addresses. The way the substitution is made is recorded in a special table. Upon receipt of a response, in accordance with the table, a reverse replacement is made and the packet is forwarded to the internal network.
Consider an example of using NAT in Fig. 5.14. In this case, the private addresses 192.168.0.x are used on the internal network. From the computer with the address 192.168.0.2, they access the external network to the computer with the address 195.242.2.2. Let this be a connection to a web server (HTTP protocol that uses TCP port 80).
When a packet passes through a router that performs address translation, the sender's IP address (192.168.0.2) will be replaced with the address external interface router (195.201.82.146), and an entry similar to the one shown in
IPsec (IP security)- a set of protocols for the secure transmission of traffic over an IP network. Perhaps the most complex and branched protocol stack supported by the VPNKI system.
Includes three main protocols:
- AH (Authentication Header) - integrity management of transmitted data and authentication
- ESP (Encapsulating Security Payload) - data encryption
- ISAKMP (Internet Security Association and Key Management Protocol) - management of connection establishment, mutual authentication by end nodes of each other and exchange of secret keys
Main used ports and protocol numbers
- UDP protocol, port 500 (IKE, key management)
- Protocol UDP, port 4500 (IPSEC NAT-Traversal mode)
- ESP protocol, value 50 (for IPSEC)
- Protocol AH, value 51 (for IPSEC)
In general, the IPsec protocol suite is not simple in terms of its uses, which are quite multifaceted. However, the basic feature of all interaction over this protocol is the concept of SA (Security Association) - this is a set of parameters about how the parties will continue to use certain properties of protocols from IPsec.
It is also worth mentioning the two main modes of IPsec operation - tunnel and transport. Roughly speaking, in transport mode, only the payload of an IP packet is encrypted, while in tunnel mode, all data is encrypted, including IP headers.
Authentication
The interaction of two nodes begins with the establishment of SA. More precisely, from two associations - for the AH and ESP protocol, and in one direction and the other. SA starts with authentication and then the parties agree on future session parameters:
- for the AH protocol - the authentication algorithm used, keys, key lifetime and other parameters,
- for the ESP protocol - encryption and authentication algorithms, keys, initialization parameters, key lifetime and other parameters.
Here, the parties agree on the tunnel or transport mode of IPsec.
By the end of the process, you should have several SAs installed, but ... a little more about how it really is.
Phase 1 and Phase 2
In IPsec, everything happens in Phases.
In phase 1, the SA of the first phase is established. In the first phase, the parties agree on the identification method, encryption algorithm, hashing algorithm and the Diffie Hellman group. This phase can be done by exchanging three unencrypted packets (aggressive mode) or six unencrypted packets - standard mode. If all goes well, then a phase 1 SA called IKE SA is created and the transition to the second phase is made.
In phase 2, the parties agree on a policy and the keys themselves are created. This phase, unlike the first one, is completely encrypted and it occurs only in case of successful completion of the first phase. Because the traffic in this phase is fully encrypted, it becomes difficult to troubleshoot, but if all goes well, a phase 2 SA called IPSec SA is created. At this point, we can say that the tunnel is established.
Data compression
IPsec does not have its own data compression mechanism, but you can use the IPcomp mechanism to compress the contents of an IP packet before it is passed to the IPsec process. Some IPsec daemons support enabling this mechanism from ipsec.conf configuration files (eg Strongswan package)
Automatic VPN connection health check
Inside IPsec, there is no standard tool for checking the health of the connection (such as ping), so the operation of the tunnel can be checked by external means.
Terminate VPN connection and change keys
Keys agreed upon in two phases must work for the time specified by the policy. This means that the parties may have to survive the rekeying procedure, otherwise the negotiated SAs will fall apart. As mentioned above, the parties have keys as part of the Phase 1 (IKE) and Phase 2 (IPsec) process. The procedures for changing them are different, as are the timers that are responsible for this. In order to avoid communication interruption during the rekeying process, the parties first agree on the parameters of the new SA and only after this successful procedure destroy the old SA.
In IPsec, there are several ways to change keys at each of the phases - with or without authentication, but we will not focus too much on this. There are simply too many nuances for this procedure, which depend on software versions and the ratio of timers - for IKE and IPsec.
pre-shared key: Two racoon daemons connect to each other, confirm they are who they say they are (using the default private key you set in /etc/racoon/psk.txt). The daemons then generate a new private key and use it to encrypt traffic over the VPN. They change this key periodically, so that even if the attacker breaks one of the keys (which is theoretically almost impossible) it won't give him too much - he has broken the key that two daemons have already changed to another. The pre-shared key is not used to encrypt traffic over the VPN connection, it's just a token that allows key daemons to trust each other. The permissions on the psk.txt file must be 0600 (i.e. write and read only for root).
IPsec consists of two protocols:
Encapsulated Security Payload (ESP), which protects IP packet data from third party interference by encrypting the content using symmetric cryptographic algorithms(such as Blowfish, 3DES, AES).
Authentication Header (AH), which protects the IP packet header from third party interference and forgery by computing a cryptographic checksum and hashing the IP packet header fields with a secure hashing function. An additional hash header is added to the packet to allow authentication of the packet information.
ESP and AH may be used together or separately, depending on the circumstances.
esp and ah are ipsec packets, generated by the kernel after the hosts, with the help of racoon, agree on a key using the isakmp (500/udp) protocol.
IPsec operating modes (transport, tunnel)
There are two modes of IPsec operation: transport mode and tunnel mode (when only routers operate in transport mode).
IPsec can either be used to directly encrypt traffic between two hosts (transport mode); or to build "virtual tunnels" between two subnets that can be used to secure connections between two corporate networks (tunnel mode). Tunnel mode is commonly referred to as a virtual private network (Virtual Private Network, What is a VPN).
IN transport mode only the informative part of the IP packet is encrypted (or signed). Routing is not affected because the IP header of the packet is not changed (not encrypted). Transport mode is typically used to establish a connection between hosts. It can also be used between gateways to protect tunnels organized in some other way (IP tunnel, GRE tunnels, etc.).
IN tunnel mode The entire IP packet is encrypted. In order for it to be transmitted over the network, it is placed in another IP packet. Essentially, this is a secure IP tunnel. Tunnel mode can be used to connect remote computers to a virtual private network or to organize secure data transmission over open communication channels (for example, the Internet) between gateways to connect different parts of a virtual private network. Tunnel mode encapsulates the entire original IP packet and adds a new IP header.
If IPsec is used in conjunction with GRE tunnels, which encapsulates the original packet and adds a new IP header, it is logical to use transport mode.
IPsec modes are not mutually exclusive. On the same host, some SAs may use transport mode, while others may use tunnel mode.
Security Associations (SA). To be able to carry out encapsulation / decapsulation, the parties involved in the exchange process must be able to store secret keys, algorithms and IP addresses. All this information is stored in the Security Associations (SA), SAs are in turn stored in the Security Associations Database (SAD). Configuring the Security Association , allows you to set for example mode transport | tunnel | ro | in_trigger | beet- secure association mode. Accordingly, it can take one of the values meaning transport, tunnel, beet (Bound End-to-End Tunnel), route optimization (route optimization) or in_trigger modes. (the last two are used in the context of mobile ipv6).
Security Policy (SP)- security policy, stored in SPD (Security Policy Database). SA specifies how IPsec is supposed to protect traffic, SPD in turn stores Additional information needed to determine which traffic to protect and when. SPD can specify one of three actions for a data packet: discard the packet, do not process the packet using IPSec, process the packet using IPSec. In the latter case, the SPD also specifies which SA to use (assuming a suitable SA has already been created, of course) or specifies with what parameters a new SA should be created. SPD is a very flexible control mechanism that allows for very good management processing each packet. Packets are classified by a large number of fields, and the SPD may check some or all of the fields to determine the appropriate action. This can result in all traffic between two machines being sent using a single SA, or separate SAs being used for each application, or even for each TCP connection.
IPSec (net-to-net) between FreeBSD servers
Set up both cores with device gif . In FreeBSD, gif support is included in the kernel.
Edit /etc/rc.conf on the routers and add the following lines (substituting IP addresses where necessary). A.B.C.D is the real IP of the first router, W.X.Y.Z is the real IP of the second router. # IPsec #1 gateway > ee /etc/rc.conf ... # IPsec to S through ISP_V gif_interfaces="gif0" # gifconfig_gif0="local-ip(A.B.C.D) remote-ip (W.X.Y.Z)" gifconfig_gif0="194.x.x.x 91.x.x.x" ifconfig_gif0="inet 10.26.95.254 192.168.1.254 netmask 255.255.255.255" static_routes="vpn vpn1" route_vpn="-net 192.168.1.0/24 192.168.1.254" route_vpn1="-net 192.168.35.0/24 192.168 .1.254" # IPsec #2 gateway > ee /etc/rc.conf ... # IPsec na G through ISPGate gif_interfaces="gif0" # gifconfig_gif0="W.X.Y.Z A.B.C.D" gifconfig_gif0="91.x.x.x 194.x.x.x" ifconfig_gif0=" inet 192.168.1.254 10.26.95.254 netmask 255.255.255.255" static_routes="vpn" route_vpn="-net 10.26.95.0/24 10.26.95.254"
Edit the firewall script on both routers and add # IPFW ipfw add 1 allow ip from any to any via gif0 # PF set skip on gif0
Step 1: Create and test a "virtual" network connection.
Now ping should go between networks.
Configure both kernels: > sysctl -a | grep ipsec
if the command did not output anything, then you need to rebuild the kernels on both routers with the parameters
# IPSEC for FreeBSD 7.0 and above options IPSEC options IPSEC_FILTERTUNNEL device crypto # IPSEC for FreeBSD 6.3 options IPSEC # IP security options IPSEC_ESP # IP security (crypto; define w/ IPSEC) options IPSEC_DEBUG # Optional. debug for IP security
Set the ipsec-tools port. > cd /usr/ports/security/ipsec-tools > make config > make install clean > ee /etc/rc.conf racoon_enable="YES" ipsec_enable="YES" > mkdir -p /usr/local/etc/racoon/ cert > cp /usr/local/share/examples/ipsec-tools/racoon.conf /usr/local/etc/racoon/racoon.conf > cd /usr/local/etc/racoon/cert/
We create SSL certificates on each host. We copy files *.public from one to another. In principle, the names of the keys are unimportant, you can also call them by IP, with the appropriate extensions.
> openssl req -new -nodes -newkey rsa:1024 -sha1 -keyform PEM -keyout your.key1.private -outform PEM -out your.key1.pem > openssl x509 -req -in your.key1.pem -signkey your. key.private -out your.key1.public
Securing a connection with IPsec
Step 2: Secure connection with IPsec
We create the ipsec.conf file. Setting on gateway #1 (where A.B.C.D's public IP address is) to enable encryption of all traffic destined to W.X.Y.Z. A.B.C.D/32 and W.X.Y.Z/32 are IP addresses and netmasks that define the networks or hosts to which the this policy. In this case, we want to apply them to the traffic between these two hosts. The ipencap option tells the kernel that this policy should only apply to packets that encapsulate other packets. The -P out option tells that this policy applies to outgoing packets, and ipsec that the packets will be encrypted.
The rest of the line determines how these packets will be encrypted. The esp protocol will be used, and the tunnel parameter indicates that the packet will be encapsulated in an IPsec packet later on. The reuse of A.B.C.D and W.X.Y.Z is to select which security options to use, and finally the require option allows encryption of packets that fall under this rule.
This rule only matches outgoing packets. You will need a similar rule to match incoming packets.
> ee /etc/ipsec.conf spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;
The setting on gateway #2 is similar, only the IPs are reversed.
Setting up the racoon utility
> ee /usr/local/etc/racoon/racoon.conf path include "/usr/local/etc/racoon"; path certificate "/usr/local/etc/racoon/cert/"; # following line activates logging & should deactivated later log debug; # if no listen directive is given, racoon listens on all available # interface addresses. listen ( #isakmp::1 ; isakmp 202.249.11.124 ; #admin ; # administrative port for racoonctl. #strict_address; # requires that all addresses must be bound. ) # describe the remote host (on the second machine - identical, # current another IP and keys) remote 217.15.62.200 ( exchange_mode aggressive,main; my_identifier asn1dn; peers_identifier asn1dn; # certificates of this machine certificate_type x509 "via.epia.public" "via.epia.private"; # certificate of the remote machine peers_certfile x509 "test.su .public"; proposal ( encryption_algorithm 3des; hash_algorithm sha1; authentication_method rsasig; dh_group 2 ; ) ) sainfo anonymous ( pfs_group 2; encryption_algorithm 3des; authentication_algorithm hmac_sha1; compression_algorithm deflate; )
Setting the PF packet filter, where esp_peers is the gateway with which the encrypted tunnel is created. We allow the passage of ESP and IPENCAP packets in both directions.
We look at the logs /var/log/security and /var/log/messages.
Once the security options are set, you can view them using setkey(8). Run
> /etc/rc.d/ipsec start > /usr/local/etc/rc.d/racoon start > setkey -D # list created secure channels > setkey -DP # show list of security policies
on any of the hosts to view information about security settings.
Health check:
ping between networks should work
We start to listen to the physical interface on which the tunnel is built (and not the virtual gif0). In another window, for example, ping a remote gray network (for example, ping 192.168.1.11) tcpdump -i em0 -n host 91 .x.x.81 ... 16:15:54.419117 IP x.x.x.x >
tcpdump Linux usage examples should show ESP packets.
IPSec (site-to-site) between Linux servers
# aptitude install ipsec-tools racoon
IPsec Configuration Algorithm
Setting up the racoon package
Create a security policy
virtual interfaces. They are needed for routing networks located in local networks. Two connected servers will see themselves without interfaces (sometimes it won't start without them between servers, it's strange, actually).
Below are the configs for the case with predefined keys.
> nano /etc/racoon/racoon.conf path include "/etc/racoon"; path pre_shared_key "/etc/racoon/psk.txt"; #path certificate "/etc/racoon/certs"; remote 10.5.21.23 ( exchange_mode aggressive,main; doi ipsec_doi; situation identity_only; my_identifier address; #Defines the identity method to be used when authenticating nodes. lifetime time 2 min; initial_contact on; proposal ( encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key ;# Specifies the authentication method used when negotiating nodes dh_group 2;) proposal_check strict;) sainfo anonymous # Indicates that the SA can automatically initialize a connection to any peer when IPsec credentials match. ( pfs_group 2; lifetime time 2 min ; encryption_algorithm 3des, blowfish 448, des, rijndael ; authentication_algorithm hmac_sha1, hmac_md5 ; compression_algorithm deflate ; )
Let's create a security policy
> nano pol.cfg #!/sbin/setkey -f flush; spdflush; spdadd 10.5.21.24 10.5.21.23 any -P out ipsec esp/transport//require; spdadd 10.5.21.23 10.5.21.24 any -P in ipsec esp/transport//require; > chmod +x pol.cfg > ./pol.cfg
Let's create an executable file for creating interfaces and run it.
>nano tun.sh #!/bin/sh ip tunnel del tun0 ip tunnel add tun0 mode ipip remote 10.5.21.23 local 10.5.21.24 dev eth0 # create tun0 interface and establish tunnel # between hosts (here you need to use real IP addresses of network interfaces ). ifconfig tun0 10.0.9.1 pointopoint 10.0.9.2 # assign IP addresses to the interface, for the current host and for the other end # of the tunnel (optional). ifconfig tun0 mtu 1472 ifconfig tun0 up # below you can specify the routes we need, for example, route add -net ... netmask 255.255.255.0 gw ... route add -net ... netmask 255.255.255.0 gw ... > ./ tun.sh
For automatic download rules, the tun.sh file should be correctly placed for Debian in the /etc/network/if-up.d directory
All IPSec tunnel between networks is configured.
iptables IPSec
$IPT -A INPUT -p udp -m udp -s xxx.xxx.xxx.xxx -d xxx.xxx.xxx.xx --dport 500 -j ACCEPT $IPT -A INPUT -p esp -j ACCEPT $IPT - A INPUT -p ah -j ACCEPT $IPT -A INPUT -p ipencap -j ACCEPT $IPT -A INPUT -p udp -m udp -s xxx.xxx.xxx.xxx -d xxx.xxx.xxx.xx -- dport 4500 -j ACCEPT
IPsec host-to-host without virtual interfaces
Task. Use IPSec (pre_shared_key) to connect two servers (Debian 5 and Debian 7). Both have real IP. No networks need to be forwarded. Traffic between these IPs must be encrypted. That is, we build a transport mode (between two hosts).
Setting comes down to two points
Setting up the racoon package
Security policy creation: need to specify transport mode and any spdadd x.x.x.x/32 y.y.y.y/32 any -P out ipsec esp/transport//require; spdadd y.y.y.y/32 x.x.x.x/32 any -P in ipsec esp/transport//require;
IPSec (GRE) (host-to-network) between Debian and Cisco
Task: build IPsec in tunnel mode. Protocol RFC Description SIP signaling between provider (Cisco) and client (Debian 5) is encrypted with IPsec, and RTP bypasses the tunnel by the shortest route through the regular Internet.
Client tunnel-endpoint is: 193.xxx.xxx.xxx
Server tunnel-endpoint is: 62.xxx.xxx.xxx
Sip Server client is: 193.xxx.xxx.xxx
SIP Servers are: 62.xxx.237.xxx/26 and 62.xxx.246.xxx/26
and before setting up the tunnel (before auto tun0), pre-up modprobe ip_gre
# modprobe ip_gre
Script to create GRE tunnels in Debian:
#!/bin/sh -e modprobe ip_gre #ip tunnel del tun0 ip tunnel add tun0 mode gre remote 62.xxx.xxx.xxx local 193.xxx.xxx.xxx dev eth0 ifconfig tun0 mtu 1472 ifconfig tun0 up route add -net 62.xxx.237.xxx netmask 255.255.255.192 dev tun0 route add -net 62.xxx.246.xxx netmask 255.255.255.192 dev tun0
Utilities
For control, you can use the racoonctl utility racoonctl show-sa esp
List of created secure channels > setkey -D
security policy list > setkey -DP
IPsec Monitoring
IPsec monitoring in Debian 5.0 2.6.26-2-686-bigmem i686. The verbosity level of log notify or log debug is set in the racoon.conf file.
# tail -F /var/log/syslog | grep racoon
IPSec Openswan
OpenSWAN began to be developed as a fork of the now defunct FreeS/WAN (Free Secure Wide-Area Networking) project, releases continue to be released under the free GNU General Public License. Unlike the FreeS/WAN project, OpenSWAN is not only developed specifically for the GNU/Linux operating system. OpenSWAN provides the IpSec: AH and ESP protocol stack for the Linux kernel and the tools to manage them.
OpenSWAN for the 2.6 kernel branch provides a built-in, NETKEY implementation of IpSec, as well as its own KLIPS.
CentOS 6.6 only supports Openswan in core packages.
Task. Create an encrypted tunnel between CentOS 6.6 and Debian 7.8 Wheezy. GRE tunnels + Openswan (type=transport)
Openswan will encrypt our traffic in transport mode (host-to-host) without interfering with routing. Install packages on both servers yum install openswan aptitude install openswan
At both ends of the tunnel, set up iptables Rules. Open port 500 for the exchange of certificates and keys. iptables -A INPUT -p udp --dport 500 -j ACCEPT iptables -A INPUT -p tcp --dport 4500 -j ACCEPT iptables -A INPUT -p udp --dport 4500 -j ACCEPT # More strictly write the rules for IPSec IPT ="/sbin/iptables" $IPT -A INPUT -p udp -s x.x.x.x -d x.x.x.x --dport 500 -m comment --comment"IpSec" -j ACCEPT $IPT -A INPUT -p tcp -s x.x.x.x -d x.x.x.x --dport 4500 -m comment --comment "IpSec" -j ACCEPT $IPT -A INPUT -p udp -s x.x.x.x -d x.x.x.x --dport 4500 -m comment --comment "IpSec" -j ACCEPT
Preparing configuration files. Files and directories used / etc/ ipsec.d/ / etc/ ipsec.conf
Checking the system for the correct environment for IPsec ipsec verify
Add to the end of the sysctl.conf file
# IPSec Verify Compliant # Allow packet forwarding between interfaces for IPv4 net.ipv4.ip_forward = 1 # disable icmp redirect net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.default.accept_redirects = 0Apply kernel options without reboot
The first configuration file is /etc/ipsec.conf. Set explicitly in the section config setup config setup protostack =netkey plutoopts ="--perpeerlog" dumpdir =/ var/ run/ pluto/ nat_traversal =yes virtual_private =% v4:10.0.0.0/ 8 ,% v4:192.168.0.0/ 16 , % v4:172.16.0.0/ 12 ,% v4:25.0.0.0/ 8 ,% v6:fd00::/ 8 ,% v6:fe80::/ 10 oe =off #plutostderrlog=/dev/null
First of all, you need to generate the keys used by the gateways for authentication. On Debian, this key can be created during installation. We run ipsec newhostkey on both systems, generating the keys we need. ipsec newhostkey --output / etc/ ipsec.secrets ipsec showhostkey --left ipsec showhostkey --right
Regardless of how you configure the server, always think of your subnet as being on the "left" (left) and the subnet accessed remotely, the site, as being on the "right" (right). The following configuration is done on VPN server on the left side. The other server should have exactly the same settings for this connection. conn gagahost-to-miraxhost auto =start left =188 .x.x.x leftrsasigkey =0sN4vI6ooUyMyL ... right =91 .x.x.x rightrsasigkey =0sfAhuo4SQ0Qt ... type =transport scp / etc/ ipsec.conf [email protected] 192.168.35.254:/home/admin/
IPSec Openswan Diagnostics
Starting the service and troubleshooting.
Openwan logs (pluto): /var/log/auth.log /var/log/syslog /var/log/pluto/peer/a/b/c/d/a.b.c.d.log
If there are no errors on both servers, then the tunnel should now go up. You can test the tunnel using the ping command with the following. If the tunnel is not up, then the private subnet on side B should not be accessible from side A, i.e. the ping command should not work. After the tunnel is up, try the ping command to access the private subnet on side B from side A. This should work.
In addition, routes to the private subnet should appear in the server's routing table.
# ip route via dev eth0 src default via dev eth0
Connection status check commands: ipsec verify service ipsec status ip xfrm state list - SAD management, more options than setkey ipsec addconn --checkconfig - check ipsec configuration auto --status - detailed status ip xfrm monitor
ipsec policies that decide which traffic to send to the tunnel ip xfrm pol show
tcpdump Linux usage examples run to sniff the physical interface on which the tunnel is built (not the virtual GRE). In another window, for example, ping a remote gray network (for example, ping 192.168.1.11). tcpdump should show ESP packets. tcpdump -i em0 -n host 91 .x.x.81 ... 16 :15 :54.419117 IP x.x.x.x > 91 .x.x.81: ESP(spi =0x01540fdd,seq =0xa20) , length 92 ...
Links
In the late sixties, the American Defense Advanced Research Agency (DARPA) decided to create an experimental network called ARPANet. In the 1970s, ARPANet came to be considered the operating network of the USA, and through this network it was possible to get access to the leading universities and scientific centers of the USA. In the early eighties, the standardization of programming languages began, and then the protocols for network interaction. The result of this work was the development of a seven-layer model of network interaction ISO / OSI and a family of protocols TCP / IP, which became the basis for building both local and global networks.
The basic mechanisms for information exchange in TCP / IP networks were generally formed in the early eighties, and were aimed primarily at ensuring the delivery of data packets between different operating systems using heterogeneous communication channels. Despite the fact that the idea of creating the ARPANet network (later turned into modern internet) belonged to a government defense organization, in fact, the network originated in the research world, and inherited the tradition of openness of the academic community. Even before the commercialization of the Internet (which occurred in the mid-nineties), many respected researchers noted the problems associated with the security of the TCP / IP protocol stack. The basic concepts of the TCP / IP protocols do not fully satisfy (and in some cases contradict) modern ideas about computer security.
Until recently, the Internet was used mainly to process information using relatively simple protocols: e-mail, file transfer, remote access. Today, due to the widespread use of WWW technologies, the means of distributed processing of multimedia information are increasingly being used. At the same time, the volume of data processed in client/server environments and intended for simultaneous shared access by a large number of subscribers is growing. Several application layer protocols have been developed to provide information security applications such as email (PEM, PGP, etc.), WWW (Secure HTTP, SSL, etc.), network management (SNMPv2, etc.). However, the presence of security tools in the basic protocols of the TCP / IP family will allow information exchange between a wide range of different applications and services.
Brief historical background of the appearance of the protocol
In 1994, the Internet Architecture Board (IAB) released the report "Internet Architectural Security". This document described the main areas of application of additional security tools on the Internet, namely protection against unauthorized monitoring, packet spoofing, and data flow control. Among the priority and most important protective measures, the need to develop a concept and basic mechanisms for ensuring the integrity and confidentiality of data flows was indicated. Since a change in the basic protocols of the TCP / IP family would cause a complete restructuring of the Internet, the task was to ensure the security of information exchange in open telecommunication networks based on existing protocols. Thus, the Secure IP specification began to be created, additional to the IPv4 and IPv6 protocols.
IPSec architecture
IP Security is a suite of protocols dealing with encryption, authentication, and security in the transport of IP packets; it now includes nearly 20 standards proposals and 18 RFCs.
The IP Security specification (known today as IPsec) is being developed by the IETF's IP Security Protocol Working Group. Initially, IPsec included 3 algorithm-independent base specifications published as RFCs "IP Security Architecture", "Authentication Header (AH)", "Encrypted Data Encapsulation (ESP)" (RFC1825, 1826 and 1827). It should be noted that in November 1998, the IP Security Protocol Working Group proposed new versions of these specifications, which currently have the status of preliminary standards, these are RFC2401 - RFC2412. Note that RFC1825-27 has been considered obsolete for several years and is not really used. In addition, there are several algorithm-dependent specifications that use the MD5, SHA, DES protocols.
Rice. 1 - IPSec architecture.
The IP Security Protocol Working Group also develops key information management protocols. The task of this group is to develop the Internet Key Management Protocol (IKMP), an application layer key management protocol that is independent of the security protocols used. Key management concepts are currently being considered using the Internet Security Association and Key Management Protocol (ISAKMP) specification and the Oakley Key Determination Protocol. The ISAKMP specification describes the mechanisms for negotiating the attributes of the protocols used, while the Oakley protocol allows you to set session keys on computers on the Internet. Previously, the possibilities of using SKIP key management mechanisms were also considered, but now such possibilities are practically not used anywhere. Key information management standards that are being created will probably support Key Distribution Centers similar to those used in the Kerberos system. Key management protocols for IPSec based on Kerberos are currently being handled by a relatively new working group KINK (Kerberized Internet Negotiation of Keys).
The data integrity and confidentiality guarantees in the IPsec specification are provided through the use of authentication and encryption mechanisms, respectively. The latter, in turn, are based on the preliminary agreement of the parties on the so-called information exchange. "security context" - cryptographic algorithms used, key information management algorithms and their parameters. The IPsec specification provides for the possibility for the parties to exchange information to support various protocols and parameters for authentication and encryption of data packets, as well as various key distribution schemes. In this case, the result of negotiating the security context is the establishment of a security parameters index (SPI), which is a pointer to a certain element of the internal structure of the information exchange side that describes possible sets of security parameters.
In fact, IPSec, which will become part of IPv6, operates at the third layer, i.e. at the network layer. As a result, transmitted IP packets will be protected in a manner that is transparent to network applications and infrastructure. Unlike SSL (Secure Socket Layer), which operates at the fourth (i.e. transport) layer and is more closely associated with the higher layers of the OSI model, IPSec is designed to provide low-level security.
Rice. 2 - OSI / ISO model.
IPSec adds a header to IP data ready to be sent over a VPN to identify protected packets. Before being transmitted over the Internet, these packets are encapsulated in other IP packets. IPSec supports several types of encryption, including Data Encryption Standard (DES) and Message Digest 5 (MD5).
To establish a secure connection, both session participants must be able to quickly agree on security parameters such as authentication algorithms and keys. IPSec supports two types of key management schemes through which participants can negotiate session parameters. This dual support caused some friction in the IETF Working Group at the time.
With the current version of IP, IPv4, either the Internet Secure Association Key Management Protocol (ISAKMP) or the Simple Key Management for Internet Protocol can be used. WITH new version IP, IPv6, will have to use ISAKMP, now known as IKE, although the possibility of using SKIP is not ruled out. However, it should be kept in mind that SKIP is no longer considered a key management candidate, and was removed from the list of possible candidates as early as 1997.
AH header
The Authentication Header (AH) is a normal optional header and is usually located between the main IP packet header and the data field. The presence of AH does not affect the process of transferring information of the transport and higher layers. The main and only purpose of AH is to provide protection against attacks associated with unauthorized changes to the contents of the package, including spoofing the original address of the network layer. Higher level protocols must be modified in order to carry out verification of the authenticity of the received data.
The AH format is quite simple and consists of a 96-bit header and variable length data of 32-bit words. The field names reflect their contents quite clearly: Next Header indicates the next header, Payload Len represents the length of the packet, SPI is a pointer to the security context, and Sequence Number Field contains the sequence number of the packet.
Rice. 3 - AH header format.
The packet sequence number was introduced into the AH in 1997 during the revision process of the IPsec specification. The value of this field is generated by the sender and serves to protect against attacks related to reuse authentication process data. Since the Internet does not guarantee the order in which packets will be delivered, the recipient must keep information about the maximum sequence number of a packet that was successfully authenticated, and about receiving a certain number of packets containing previous sequence numbers (usually this number is 64).
Unlike the algorithms for calculating the checksum used in protocols for transmitting information over dial-up communication lines or over LAN channels and focused on correcting random errors in the transmission medium, data integrity mechanisms in open telecommunication networks must have means of protection against making targeted changes. One of these mechanisms is a special application of the MD5 algorithm: during the formation of AH, a hash function is sequentially calculated from the combination of the packet itself and some pre-agreed key, and then from the combination of the result and the transformed key. This mechanism applied by default in order to provide all implementations of IPv6 with at least one common algorithm that is not subject to export restrictions.
ESP header
In the case of encrypted data encapsulation, the ESP header is the last of the optional headers "visible" in the packet. Since the main purpose of ESP is to ensure data confidentiality, different types of information may require the use of significantly different encryption algorithms. Therefore, the ESP format can undergo significant changes depending on the cryptographic algorithms used. However, the following mandatory fields can be distinguished: SPI indicating the security context and Sequence Number Field containing the sequence number of the packet. The "ESP Authentication Data" (checksum) field is optional in the ESP header. The recipient of the ESP packet decrypts the ESP header and uses the parameters and data of the applied encryption algorithm to decode the transport layer information.
Rice. 4 - ESP header format.
There are two modes of application of ESP and AH (as well as their combinations) - transport and tunnel.
Transport mode
The transport mode is used to encrypt the data field of an IP packet containing transport layer protocols (TCP, UDP, ICMP), which in turn contains application service information. An example of a transport mode application is the transmission Email. All intermediate nodes on the packet's path from sender to receiver use only public network layer information and possibly some optional packet headers (in IPv6). The disadvantage of the transport mode is the lack of mechanisms for hiding the specific sender and recipient of the packet, as well as the possibility of traffic analysis. The result of such an analysis can be information about the volume and direction of information transfer, the areas of interest of subscribers, the location of managers.
tunnel mode
Tunnel mode encrypts the entire packet, including the network layer header. Tunnel mode is used when it is necessary to hide the organization's information exchange with the outside world. At the same time, the address fields of the network layer header of a packet using tunnel mode are filled by the organization's firewall and do not contain information about the specific sender of the packet. When transferring information from the outside world to the organization's local network, the network address of the firewall is used as the destination address. After the firewall decrypts the initial network layer header, the packet is sent to the recipient.
Security Associations
A Security Association (SA) is a connection that provides security services for the traffic that passes through it. The two computers on each side of the SA store the mode, protocol, algorithms, and keys used in the SA. Each SA is used in only one direction. Two SAs are required for bidirectional communication. Each SA implements one mode and protocol; thus, if two protocols (such as AH and ESP) need to be used for one packet, then two SAs are required.
Security policy
The security policy is stored in the SPD (Security Policy Database). SPD can specify one of three actions for a data packet: discard the packet, do not process the packet using IPSec, process the packet using IPSec. In the latter case, the SPD also specifies which SA to use (assuming a suitable SA has already been created, of course) or specifies with what parameters a new SA should be created.
SPD is a very flexible control mechanism that allows very good control over the processing of each packet. Packets are classified by a large number of fields, and the SPD may check some or all of the fields to determine the appropriate action. This can result in all traffic between two machines being sent using a single SA, or separate SAs being used for each application, or even for each TCP connection.
ISAKMP/Oakley
The ISAKMP protocol defines overall structure protocols that are used to establish an SA and to perform other key management functions. ISAKMP supports several Domains of Interpretation (DOI), one of which is IPSec-DOI. ISAKMP does not define a complete protocol, but provides "building blocks" for various DOIs and key exchange protocols.
The Oakley protocol is a key determination protocol that uses the Diffie-Hellman key substitution algorithm. The Oakley protocol supports Perfect Forward Secrecy (PFS). The presence of PFS means that all traffic cannot be decrypted if any key in the system is compromised.
IKE
IKE is the default key exchange protocol for ISAKMP and is currently the only one. IKE sits on top of ISAKMP and does the actual establishment of both the ISAKMP SA and the IPSec SA. IKE supports a set of different primitive functions for use in protocols. Among them are the hash function and the pseudo-random function (PRF).
A hash function is a function that is resistant to collisions. Collision resistance refers to the fact that it is impossible to find two different messages m 1 And m2, such that H(m1)=H(m2), Where H- hash function.
With regard to pseudo-random functions, currently, instead of special PRFs, a hash function is used in the HMAC design (HMAC is a message authentication mechanism using hash functions). To define HMAC, we need a cryptographic hash function (denoted as H) and a secret key K. We assume that H is a hash function where data is hashed using a compression procedure applied sequentially to a sequence of data blocks. We will denote by B the length of such blocks in bytes, and the length of the blocks obtained as a result of hashing as L (L Ipad = byte 0x36 repeated B times; To calculate HMAC from "text" data, you need to perform the following operation: H(K XOR opad, H(K XOR ipad, text)) It follows from the description that IKE uses HASH values to authenticate the parties. Note that HASH in this case refers exclusively to the Payload name in ISAKMP, and this name has nothing to do with its content. All types of attacks on IPSec components can be divided into the following groups: attacks that exploit the finiteness of system resources (a typical example is a Denial of Service attack, Denial-of-service or DOS attack), attacks that use the features and errors of a specific IPSec implementation, and and finally, attacks based on the weaknesses of the protocols themselves. AH and ESP. Purely cryptographic attacks can be ignored - both protocols define the concept of "transforms", where all cryptography is hidden. If the used cryptoalgorithm is resistant, and the transform defined with it does not introduce additional weaknesses (this is not always the case, therefore it is more correct to consider the stability of the entire system - Protocol-Transform-Algorithm), then from this side everything is fine. What remains? Replay Attack - leveled out by using the Sequence Number (in one single case this does not work - when using ESP without authentication and without AH). Further, the order of actions (first encryption, then authentication) guarantees a quick rejection of "bad" packets (moreover, according to the latest research in the world of cryptography, this is the most secure order of actions, the reverse order in some, albeit very special cases, can lead to potential security holes; fortunately, neither SSL, nor IKE, nor other common protocols with a "first authenticate, then encrypt" protocol do not belong to these special cases, and therefore do not have these holes). What remains is the Denial-Of-Service attack. As you know, this is an attack against which there is no complete protection. However, the fast rejection of bad packets and the absence of any external reaction to them (according to the RFC) make it possible to deal with this attack more or less well. In principle, most (if not all) known network attacks (sniffing, spoofing, hijacking, etc.) are successfully countered by AH and ESP when used correctly. With IKE, it's a bit more complicated. The protocol is very complex, difficult to analyze. In addition, due to typos (in the HASH_R calculation formula) when writing it and not entirely successful solutions (the same HASH_R and HASH_I), it contains several potential "holes" (in particular, not all Payloads in the message are authenticated in the first phase), however , they are not very serious and lead, at most, to a refusal to establish a connection. IKE is more or less successfully protected from attacks such as replay, spoofing, sniffing, hijacking. Cryptography is somewhat more complicated - it is not rendered, as in AH and ESP, separately, but is implemented in the protocol itself. However, when using persistent algorithms and primitives (PRF), there should be no problems. To some extent, it can be considered as a weakness of IPsec that DES is indicated as the only mandatory cryptalgorithm for implementation in the current specifications (this is true for both ESP and IKE), 56 bits of the key of which are no longer considered sufficient. Nevertheless, this is a purely formal weakness - the specifications themselves are algorithm-independent, and almost all well-known vendors have long implemented 3DES (and some have already implemented AES). Thus, if implemented correctly, Denial-Of-Service remains the most "dangerous" attack . The IPSec protocol has received mixed reviews from experts. On the one hand, it is noted that the IPSec protocol is the best among all other protocols for protecting data transmitted over the network, developed earlier (including the one developed by Microsoft PPTP). According to the other side, there is excessive complexity and redundancy of the protocol. For example, Niels Ferguson and Bruce Schneier in their work "A Cryptographic Evaluation of IPsec" note that they have found serious security problems in almost all major components of IPsec. These authors also point out that the protocol suite needs a lot of work in order to provide a good level of security. The paper describes a number of attacks that use both the weaknesses of the general data processing scheme and the weaknesses of cryptographic algorithms. In this article, we covered some of the main points regarding the IPsec network security protocol. It's worth noting that IPsec dominates most virtual private network implementations. Currently, both software implementations are presented on the market (for example, the protocol is implemented in the Microsoft Windows2000 operating system), and software and hardware implementations of IPsec are Cisco, Nokia solutions. Despite the large number of different solutions, all of them are quite well compatible with each other. The article concludes with a table that compares IPSec and the now widely used SSL. In contact with Classmates
opad = byte 0x5C repeated B times.Attacks on AH, ESP and IKE.
Protocol evaluation
Conclusion
Peculiarities
IPSec
SSL
Hardware independence
Yes
Yes
Code
No changes required for applications. May require access to the source code of the TCP/IP stack.
Application changes required. New DLLs or access to application source code may be required.
Protection
Whole IP packet. Enables protection for higher layer protocols.
Application layer only.
Packet filtering
Based on authenticated headers, sender and recipient addresses, etc. Simple and cheap. Suitable for routers.
Based on high-level content and semantics. More intelligent and more complex.
Performance
Fewer context switches and data movement.
More context switches and data movement. Large blocks of data can speed up cryptographic operations and provide better compression.
Platforms
Any systems, including routers
Basically, end systems (clients/servers), also firewalls.
Firewall/VPN
All traffic is protected.
Only application level traffic is protected. ICMP, RSVP, QoS, etc. may not be protected.
Transparency
For users and applications.
For users only.
Current status
emerging standard.
Widely used by WWW browsers, also used by some other products.
Links
Thanks
Loading...